draft-ietf-mpls-multicast-encaps-10.txt   rfc5332.txt 
Network Working Group Toerless Eckert Network Working Group T. Eckert
Internet Draft Eric C. Rosen (editor) Request for Comments: 5332 E. Rosen, Ed.
Intended Status: Standards Track Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: December 2, 2008 Updates: 3032, 4023 R. Aggarwal
Updates: RFCs 3032 and 4023 Rahul Aggarwal Y. Rekhter
Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
August 2008
June 2, 2008
MPLS Multicast Encapsulations MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-10.txt Status of This Memo
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
RFC 3032 established two data link layer codepoints for MPLS, used to RFC 3032 established two data link layer codepoints for MPLS, used to
distinguish whether the data link layer frame is carrying an MPLS distinguish whether the data link layer frame is carrying an MPLS
unicast or an MPLS multicast packet. However, this usage was never unicast or an MPLS multicast packet. However, this usage was never
deployed. This specification updates RFC 3032 by redefining the deployed. This specification updates RFC 3032 by redefining the
meaning of these two codepoints. Both codepoints can now be used to meaning of these two codepoints. Both codepoints can now be used to
carry multicast packets. The second codepoint (formerly the carry multicast packets. The second codepoint (formerly the
"multicast codepoint") is now to be used only on multiaccess media, "multicast codepoint") is now to be used only on multiaccess media,
and it is to mean "the top label of the following label stack is an and it is to mean "the top label of the following label stack is an
upstream-assigned label". upstream-assigned label".
RFC 3032 does not specify the destination address to be placed in the RFC 3032 does not specify the destination address to be placed in the
"MAC DA" field of an ethernet frame which carries an MPLS multicast "MAC DA" (Medium Access Layer Destination Address) field of an
packet. This document provides that specification. ethernet frame that carries an MPLS multicast packet. This document
provides that specification.
This document updates RFC 3032 and RFC 4023. This document updates RFC 3032 and RFC 4023.
Contents Table of Contents
1 Specification of Requirements ........................... 2
2 Introduction ............................................ 3
3 Upstream-Assigned vs. Downstream-Assigned ............... 4
4 Ethernet Codepoints ..................................... 6
5 PPP Protocol Field ...................................... 7
6 GRE Protocol Type ....................................... 7
7 IP Protocol Number ...................................... 7
8 Ethernet MAC DA for Multicast MPLS ...................... 8
9 IANA Considerations ..................................... 9
10 Security Considerations ................................. 9
11 Normative References .................................... 9
12 Authors' Addresses ...................................... 10
13 Full Copyright Statement ................................ 10
14 Intellectual Property ................................... 11
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction ....................................................2
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 2. Specification of Requirements ...................................3
document are to be interpreted as described in [RFC2119]. 3. Upstream-Assigned vs. Downstream-Assigned .......................3
4. Ethernet Codepoints .............................................6
5. PPP Protocol Field ..............................................6
6. GRE Protocol Type ...............................................6
7. IP Protocol Number ..............................................7
8. Ethernet MAC DA for Multicast MPLS ..............................7
9. IANA Considerations .............................................8
10. Security Considerations ........................................8
11. Normative References ...........................................9
2. Introduction 1. Introduction
RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry"
(NHLFE). The NHLFE for a particular label maps the label into a next (NHLFE). The NHLFE for a particular label maps the label into a next
hop (among other things). When an MPLS packet is received, its top hop (among other things). When an MPLS packet is received, its top
label is mapped to an NHLFE, and the packet is sent to the next hop label is mapped to an NHLFE, and the packet is sent to the next hop
specified by the NHLFE. specified by the NHLFE.
We define a particular MPLS label to be a "multicast label" in a We define a particular MPLS label to be a "multicast label" in a
particular context if the NHLFE to which it is mapped in that context particular context if the NHLFE to which it is mapped, in that
specifies a set of next hops, with the semantics that the packet is context, specifies a set of next hops, with the semantics that the
to be replicated, and a copy of the packet sent to each of the packet is to be replicated and a copy of the packet sent to each of
specified next hops. Note that this definition accommodates the case the specified next hops. Note that this definition accommodates the
where the set of next hops contains a single member. What makes a case where the set of next hops contains a single member. What makes
label a multicast label in a particular context is the semantics a label a multicast label in a particular context is the semantics
attached to the set, i.e., the intention to replicate the packet and attached to the set, i.e., the intention to replicate the packet and
transmit to all members of the set if the set has more than one transmit to all members of the set if the set has more than one
member. member.
RFC 3032 [RFC3032] established two data link layer codepoints for RFC 3032 [RFC3032] established two data link layer codepoints for
MPLS: one to indicate that the data link layer frame is carrying an MPLS: one to indicate that the data link layer frame is carrying an
MPLS unicast packet, and the other to indicate that the data link MPLS unicast packet, and the other to indicate that the data link
layer frame is carrying an MPLS multicast packet. The term layer frame is carrying an MPLS multicast packet. The term
"multicast packet" is not precisely defined in RFC 3032, though one "multicast packet" is not precisely defined in RFC 3032, though one
may presume that the "multicast" codepoint is intended to identify may presume that the "multicast" codepoint is intended to identify
the packet's top label as a multicast label. However, the multicast the packet's top label as a multicast label. However, the multicast
codepoint has never been deployed, and further development of the codepoint has never been deployed, and further development of the
procedures for MPLS multicast have shown that, while there is a need procedures for MPLS multicast have shown that, while there is a need
for two codepoints, the use of the two codepoints is not properly for two codepoints, the use of the two codepoints is not properly
captured by RFC 3032. captured by RFC 3032.
In particular, there is no need for the codepoint to indicate whether In particular, there is no need for the codepoint to indicate whether
the top MPLS label is a multicast label. When the receiver of an the top MPLS label is a multicast label. When the receiver of an
MPLS packet looks up the top label, the NHLFE will specify whether MPLS packet looks up the top label, the NHLFE will specify whether or
the label is a multicast label or not. not the label is a multicast label.
This document updates RFC 3032 and RFC 4023 by re-specifying the use This document updates RFC 3032 and RFC 4023 by re-specifying the use
of the codepoints. The old use of the "multicast codepoint", as of the codepoints. The old use of the "multicast codepoint", as
specified in those two RFCs, is hereby deprecated. specified in those two RFCs, is hereby deprecated.
Note that an implementation that does MPLS multicast according to RFC Note that an implementation that does MPLS multicast according to RFC
3032 and/or 4023 will be unable to interoperate with implementations 3032 and/or 4023 will be unable to interoperate with implementations
that do MPLS multicast according to this document. There may be some that do MPLS multicast according to this document. There may be some
deployed platforms which support the deprecated use of the deployed platforms that support the deprecated use of the codepoints,
codepoints, but those platforms do not support the control plane but those platforms do not support the control plane mechanisms to
mechanisms to support MPLS multicast. The absence of the control support MPLS multicast. The absence of the control plane will
plane will prevent a system that implements the deprecated use of prevent a system that implements the deprecated use of codepoints
codepoints from attempting to interoperate with a system that uses from attempting to interoperate with a system that uses the
the codepoints as specified herein. (If an MPLS multicast control codepoints as specified herein. (If an MPLS multicast control plane
plane were to be implemented on a platform that only supports the were to be implemented on a platform that only supports the
deprecated codepoint, interoperability problems such as black holes deprecated codepoint, interoperability problems such as black holes
and/or misrouting would arise. This does not seem like a potential and/or misrouting would arise. This does not seem like a potential
problem in practice.) problem in practice.)
While RFC 3032 allows an MPLS packet to be carried in an ethernet While RFC 3032 allows an MPLS packet to be carried in an ethernet
multicast frame, it fails to specify how the Medium Access Layer multicast frame, it fails to specify how the Medium Access Layer
Destination Address (MAC DA) field is to be set in that case. This Destination Address (MAC DA) field is to be set in that case. This
document provides that specification. document provides that specification.
2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Upstream-Assigned vs. Downstream-Assigned 3. Upstream-Assigned vs. Downstream-Assigned
Suppose a labeled packet P is sent from LSR R1 to LSR R2, where R1 Suppose a labeled packet P is sent from Label Switching Router (LSR)
puts label L on the packet's label stack, and R2 has to look up label R1 to LSR R2, where R1 puts label L on the packet's label stack, and
L in order to determine the corresponding Forwarding Equivalence R2 has to look up label L in order to determine the corresponding
Class (FEC), call it F. Forwarding Equivalence Class (FEC), call it F.
If the binding between L and F was made by R2 and advertised to R1, If the binding between L and F was made by R2 and advertised to R1,
then the label binding is known as "downstream-assigned". RFC 3031 then the label binding is known as "downstream-assigned". RFC 3031
only discusses downstream-assigned label bindings. only discusses downstream-assigned label bindings.
If the binding between L and F was made by R1 and advertised to R2, If the binding between L and F was made by R1 and advertised to R2,
then the label binding is known as "upstream-assigned". then the label binding is known as "upstream-assigned".
If the binding between L and F was made by a third party, say R3, and If the binding between L and F was made by a third party, say R3, and
then advertised to both R1 and R2, we also refer to the label binding then advertised to both R1 and R2, we also refer to the label binding
as "upstream-assigned". as "upstream-assigned".
Upstream-assigned labels are not required to come from the same Upstream-assigned labels are not required to come from the same
"label space" as downstream-assigned labels. See [RFC3031], section "label space" as downstream-assigned labels. See Section 3.14 of
3.14, and especially [UPSTREAM] for a discussion of the notion of [RFC3031] and especially [RFC5331] for a discussion of the notion of
"label space". The procedures for properly interpreting an upstream- "label space". The procedures for properly interpreting an upstream-
assigned label are given in [UPSTREAM]. assigned label are given in [RFC5331].
If Ru and Rd are LSP adjacencies, then they transmit a MPLS packet to If Ru and Rd are LSP adjacencies, then they transmit an MPLS packet
each other through one of the following mechanisms: to each other through one of the following mechanisms:
1. by putting the MPLS packet in a data link layer frame and 1. by putting the MPLS packet in a data link layer frame and
transmitting the frame, transmitting the frame,
2. by transmitting the MPLS packet through an MPLS tunnel, i.e., 2. by transmitting the MPLS packet through an MPLS tunnel, i.e.,
by pushing an additional label (or labels) onto the label by pushing an additional label (or labels) onto the label
stack, and then invoking mechanism 1, stack, and then invoking mechanism 1, or
3. by transmitting the MPLS packet through an IP-based tunnel 3. by transmitting the MPLS packet through an IP-based tunnel
(e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1 (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1
and/or 2. and/or 2.
In short, an MPLS packet is transmitted either through a data link or In short, an MPLS packet is transmitted through a data link, through
through an MPLS tunnel or through an IP tunnel. In any of those an MPLS tunnel, or through an IP tunnel. In any of those cases, when
cases, when the packet emerges through the tunnel, the downstream LSR the packet emerges through the tunnel, the downstream LSR must know
must know whether the label that now appears at the top of the label whether the label that now appears at the top of the label stack has
stack has an upstream-assigned label binding or a downstream-assigned an upstream-assigned label binding or a downstream-assigned label
label binding. For convenience, we will speak of a label with an binding. For convenience, we will speak of a label with an
upstream-assigned label binding as an "upstream-assigned label". upstream-assigned label binding as an "upstream-assigned label".
Under certain conditions, specified below, multicast labels MAY be Under certain conditions, specified below, multicast labels MAY be
upstream-assigned. The ability to use upstream-assigned labels is an upstream-assigned. The ability to use upstream-assigned labels is an
OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless
it is known that the downstream LSR supports them. How this is known it is known that the downstream LSR supports them. How this is known
is outside the scope of this document. is outside the scope of this document.
This document makes no changes to the procedures regarding unicast This document makes no changes to the procedures regarding unicast
labels. labels.
We discuss three different types of data link or tunnel: We discuss three different types of data link or tunnel:
- Point-to-Point. A point-to-point data link or tunnel associates - Point-to-Point. A point-to-point data link or tunnel associates
two systems, such that transmissions on that link or tunnel made two systems, such that transmissions on that link or tunnel made
by the one are received by the other, and only by the other. by one are received by the other, and only by the other.
For a given direction of a given point-to-point data link or For a given direction of a given point-to-point data link or
tunnel, the following MUST be the case: either every MPLS packet tunnel, the following MUST be the case: either every MPLS
will carry an upstream-assigned label, or else every MPLS packet packet will carry an upstream-assigned label, or else every MPLS
will carry a downstream-assigned label. The procedures for packet will carry a downstream-assigned label. The procedures
determining whether upstream-assigned or downstream-assigned for determining whether upstream-assigned or downstream-assigned
labels are being used are outside the scope of this labels are being used are outside the scope of this
specification. However, in the absence of any other information, specification. However, in the absence of any other
the use of downstream-assigned labels MUST be presumed by information, the use of downstream-assigned labels MUST be
default. presumed by default.
- Point-to-Multipoint. A point-to-multipoint link or tunnel - Point-to-Multipoint. A point-to-multipoint link or tunnel
associates n systems, such that only one of them can transmit associates n systems, such that only one of them can transmit
onto the link or tunnel, and the transmissions may be received by onto the link or tunnel, and the transmissions may be received
the other n-1 systems. by the other n-1 systems.
The top labels (before applying the data link or tunnel The top labels (before applying the data link or tunnel
encapsulation) of all MPLS packets which are transmitted on a encapsulation) of all MPLS packets that are transmitted on a
particular point-to-multipoint data link or tunnel MUST be of the particular point-to-multipoint data link or tunnel MUST be of
same type; either all upstream-assigned or all downstream- the same type; either all upstream-assigned or all downstream-
assigned. This means that all the receivers on the MPLS or IP assigned. This means that all the receivers on the MPLS or IP
tunnel must know a priori whether upstream-assigned or tunnel must know a priori whether upstream-assigned or
downstream-assigned labels are being used in the tunnel. How downstream-assigned labels are being used in the tunnel. How
this is known is outside the scope of this document. this is known is outside the scope of this document.
- Multipoint-to-Multipoint. A multipoint-to-multipoint link or - Multipoint-to-Multipoint. A multipoint-to-multipoint link or
tunnel associates n systems, such that any of them can transmit tunnel associates n systems, such that any of them can transmit
on the link or tunnel, and the transmissions may be received by on the link or tunnel, and the transmissions may be received by
the other n-1 systems. the other n-1 systems.
skipping to change at page 6, line 24 skipping to change at page 5, line 46
applies: applies:
1. It is known (by methods outside the scope of this document) 1. It is known (by methods outside the scope of this document)
that the top label of every MPLS packet on the link or that the top label of every MPLS packet on the link or
tunnel is downstream-assigned. tunnel is downstream-assigned.
2. It is known (by methods outside the scope of this document) 2. It is known (by methods outside the scope of this document)
that the top label of every MPLS packet on the link or that the top label of every MPLS packet on the link or
tunnel is upstream-assigned. tunnel is upstream-assigned.
3. Some MPLS packets on the link may have upstream-assigned 3. Some MPLS packets on the link may have upstream-assigned top
top labels while some may have downstream-assigned top labels while some may have downstream-assigned top labels.
labels.
If (and only if) the third scenario applies, the data link or If (and only if) the third scenario applies, the data link or
tunnel encapsulation MUST provide a codepoint which specifies tunnel encapsulation MUST provide a codepoint that specifies
whether the top label of the encapsulated MPLS packet is whether the top label of the encapsulated MPLS packet is
upstream-assigned or downstream-assigned. If a particular type upstream-assigned or downstream-assigned. If a particular type of
of data link or tunnel does not provide such a codepoint, then data link or tunnel does not provide such a codepoint, then the
the third scenario MUST NOT be used. third scenario MUST NOT be used.
The remainder of this document specifies procedures for setting the The remainder of this document specifies procedures for setting the
data link layer codepoints and address fields. data link layer codepoints and address fields.
4. Ethernet Codepoints 4. Ethernet Codepoints
Ethernet is an example of a multipoint-to-multipoint data link. Ethernet is an example of a multipoint-to-multipoint data link.
Ethertype 0x8847 is used whenever a unicast ethernet frame carries an Ethertype 0x8847 is used whenever a unicast ethernet frame carries an
MPLS packet. MPLS packet.
skipping to change at page 7, line 16 skipping to change at page 6, line 40
5. PPP Protocol Field 5. PPP Protocol Field
PPP is an example of a point-to-point data link. When a PPP frame is PPP is an example of a point-to-point data link. When a PPP frame is
carrying an MPLS packet, the PPP Protocol field is always set to carrying an MPLS packet, the PPP Protocol field is always set to
0x0281. 0x0281.
6. GRE Protocol Type 6. GRE Protocol Type
RFC 4023 is modified as described below. RFC 4023 is modified as described below.
If the IP destination address of the GRE encapsulation is a unicast If the IP destination address of the Generic Routing Encapsulation
IP address, then the ethertype value 0x8847 MUST be used in all cases (GRE) is a unicast IP address, then the ethertype value 0x8847 MUST
for the MPLS-in-GRE encapsulation. be used in all cases for the MPLS-in-GRE encapsulation.
If the IP destination address of the GRE encapsulation is a multicast If the IP destination address of the GRE encapsulation is a multicast
IP address, then: IP address, then:
- the ethertype value 0x8847 MUST be used when the top label of the - the ethertype value 0x8847 MUST be used when the top label of
encapsulated MPLS packet is downstream-assigned, the encapsulated MPLS packet is downstream-assigned,
- the ethertype value 0x8848 MUST be used when the top label of the - the ethertype value 0x8848 MUST be used when the top label of
encapsulated MPLS packet is upstream-assigned. the encapsulated MPLS packet is upstream-assigned.
Through procedures which are outside the scope of this specification, Through procedures that are outside the scope of this specification,
it may be known that if the destination address of a GRE packet is a it may be known that if the destination address of a GRE packet is a
multicast IP address, then the top label of the GRE payload is multicast IP address, then the top label of the GRE payload is
upstream-assigned. In such a case, the occurrence of the 8847 upstream-assigned. In such a case, the occurrence of the 8847
codepoint in a GRE packet with a multicast destination IP address codepoint in a GRE packet with a multicast destination IP address
MUST be considered an error, and the packet MUST be discarded. MUST be considered an error, and the packet MUST be discarded.
7. IP Protocol Number 7. IP Protocol Number
RFC 4023 is modified as follows: the IPv4 Protocol Number field or RFC 4023 is modified as follows: the IPv4 Protocol Number field or
the IPv6 Next Header field is always set to 137, whether or not the the IPv6 Next Header field is always set to 137, whether or not the
skipping to change at page 8, line 9 skipping to change at page 7, line 30
multipoint tunnel or a multipoint-to-multipoint tunnel. In either multipoint tunnel or a multipoint-to-multipoint tunnel. In either
case, either all encapsulated MPLS packets in the particular tunnel case, either all encapsulated MPLS packets in the particular tunnel
have a downstream-assigned label at the top of the stack, or all have a downstream-assigned label at the top of the stack, or all
encapsulated MPLS packets in that tunnel have an upstream-assigned encapsulated MPLS packets in that tunnel have an upstream-assigned
label at the top of the stack. The means by which this is determined label at the top of the stack. The means by which this is determined
for a particular tunnel is outside the scope of this specification. for a particular tunnel is outside the scope of this specification.
8. Ethernet MAC DA for Multicast MPLS 8. Ethernet MAC DA for Multicast MPLS
When an LSR transmits a multicast MPLS packet in a multicast ethernet When an LSR transmits a multicast MPLS packet in a multicast ethernet
frame, it MUST set the Destination MAC Address to the value frame, it MUST set the MAC Destination Address to the value
01-00-5e-8v-wx-yz, where vwxyz is a 20-bit (five-nibble) value set as 01-00-5e-8v-wx-yz, where vwxyz is a 20-bit (five-nibble) value set as
follows: follows:
1. vwxyz MAY be set to 0 1. vwxyz MAY be set to 0,
2. vwxyz MAY be set to the value of one of the MPLS labels on the 2. vwxyz MAY be set to the value of one of the MPLS labels on the
packet's label stack. packet's label stack.
Which of these procedures is the default procedure in any particular Which of these procedures is the default procedure in any particular
LSR is implementation-dependent. However, LSRs using the two LSR is implementation-dependent. However, LSRs using the two
different procedures MUST interoperate. That is, an LSR MUST NOT different procedures MUST interoperate. That is, an LSR MUST NOT
filter packets for which vwxyz has been set to zero, and it MUST NOT filter packets for which vwxyz has been set to zero, and it MUST NOT
indiscriminately filter all packets for which vwxyz has not been set indiscriminately filter all packets for which vwxyz has not been set
to zero. to zero.
If an LSR follows the procedure of setting vwxyz to the value of one If an LSR follows the procedure of setting vwxyz to the value of one
of the MPLS labels on the packet's label stack, and if that label of the MPLS labels on the packet's label stack, and if that label
stack contains two or more labels, then by default, vwxyz MUST be set stack contains two or more labels, then by default, vwxyz MUST be set
to the value of the second MPLS label on the packet's label stack. to the value of the second MPLS label on the packet's label stack.
By "the second label", we mean the label that is in the label stack By "the second label", we mean the label that is in the label stack
entry that immediately follows the topmost label stack entry. The entry that immediately follows the topmost label stack entry. The
LSR MAY, if configured to do so, allow a a label other than the LSR MAY, if configured to do so, allow a label other than the second
second to be used for this purpose. If the MPLS packet has only one to be used for this purpose. If the MPLS packet has only one label,
label, the value of that label will be used instead of the value of the value of that label will be used instead of the value of the
the (non-existent) second label. (non-existent) second label.
It is expected that the LSR will follow the procedures of [UPSTREAM], It is expected that the LSR will follow the procedures of [RFC5331],
pushing on two labels, with the topmost label being a "context label" pushing on two labels, with the topmost label being a "context label"
that is the same for all MPLS packets being transmitted by the LSR that is the same for all MPLS packets being transmitted by the LSR
onto the ethernet, but with the second label being different for onto the ethernet, but with the second label being different for
different LSPs. Thus if the MAC DA value is a function of the second different LSPs. Thus, if the MAC DA value is a function of the
label, more of the LSP-specific information about the packet appears second label, more of the LSP-specific information about the packet
in the MAC DA field. This can be used to filter multicast packets appears in the MAC DA field. This can be used to filter multicast
with "unexpected" non-zero values of vwxyz. Further discussion of packets with "unexpected" non-zero values of vwxyz. Further
such filtering or its uses is outside the scope of this document. discussion of such filtering or its uses is outside the scope of this
document.
The use of ethernet and/or IP broadcast addresses (as distinguished The use of ethernet and/or IP broadcast addresses (as distinguished
from multicast addresses) does not fall within the scope of this from multicast addresses) does not fall within the scope of this
specification. specification.
9. IANA Considerations 9. IANA Considerations
IANA already owns the set of ethernet multicast addresses in the IANA already owns the set of ethernet multicast addresses in the
range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range
01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are already reserved for use 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are already reserved for use
when an ethernet multicast frame carries an IP multicast packet. when an ethernet multicast frame carries an IP multicast packet.
When this document is accepted, IANA shall reserve ethernet addresses IANA has reserved ethernet addresses in the range 01-00-5e-80-00-00
in the range 01-00-5e-80-00-00 to 01-00-5e-8f-ff-ff for use when an to 01-00-5e-8f-ff-ff for use when an ethernet multicast frame carries
ethernet multicast frame carries an MPLS multicast packet. Addresses an MPLS multicast packet. Addresses in this range are valid when
in this range are to be valid when used with ethertype 8847 or 8848. used with ethertype 8847 or 8848.
As this document modifies the usage of ethertypes 8847 and 8848, IANA As this document modifies the usage of ethertypes 8847 and 8848, IANA
shall change the description of these ethertypes as follows. has changed the description of these ethertypes as follows.
Ethertype 8847 shall be defined as "MPLS", as defined in RFC 3032 and Ethertype 8847 is defined as "MPLS", as defined in RFC 3032 and in
in this document. Ethertype 8848 shall be defined as "MPLS with this document. Ethertype 8848 is defined as "MPLS with upstream-
upstream-assigned label", as defined in this document. assigned label", as defined in this document.
10. Security Considerations 10. Security Considerations
The security considerations of RFC 3032 and RFC 4023 apply. The security considerations of RFC 3032 and RFC 4023 apply.
Malicious changing of the codepoint may result in loss or misrouting Malicious changing of the codepoint may result in loss or misrouting
of packets. However, altering the codepoint without also altering the of packets. However, altering the codepoint without also altering
label does not result in a predictable effect. the label does not result in a predictable effect.
Malicious alteration of the MAC DA on an ethernet can result in Malicious alteration of the MAC DA on an ethernet can result in
packets being received by a third party, rather than by the intended packets being received by a third party, rather than by the intended
recipient. recipient.
11. Normative References 11. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
[RFC3031] "Multiprotocol Label Switching Architecture", Rosen, Requirement Levels", BCP 14, RFC 2119, March 1997.
Viswanathan, Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen, [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
[UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream- Encoding", RFC 3032, January 2001.
label-05.txt, March 2008.
12. Authors' Addresses [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)", RFC
4023, March 2005.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
Authors' Addresses
Toerless Eckert Toerless Eckert
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
Email: eckert@cisco.com
EMail: eckert@cisco.com
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com
EMail: erosen@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net
EMail: rahul@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net
13. Full Copyright Statement EMail: yakov@juniper.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 48 change blocks. 
150 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/