RFC 5332

Okay bestie, let's get into RFC 5332: MPLS Multicast Encapsulations 🦋 It came out in August 2008 from the Network Working Group and it's giving full standards-track energy 💅 Cisco's T. Eckert and E. Rosen (who edited it 🫶) wrote it with R. Aggarwal and Y. Rekhter from Juniper Networks, and it's a Standards Track doc. It updates RFC 3032 and RFC 4023, and it doesn't obsolete anything, so nothing gets deleted 🧚

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🌸 For the current standardization state and status of this protocol, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈

Abstract 💜

RFC 3032 set up two data link layer codepoints for MPLS, used to tell whether the frame is carrying an MPLS unicast or an MPLS multicast packet. Problem is, the multicast one never got deployed 💀 This spec updates RFC 3032 by redefining what those two codepoints mean, and now both of them can carry multicast packets 🔥 The second codepoint (formerly the "multicast codepoint") is now only for multiaccess media, and it means "the top label of the following label stack is an upstream-assigned label" 🎀

RFC 3032 also doesn't say what goes in the "MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame carrying an MPLS multicast packet 🙈 This document fills that gap ✨

This document updates RFC 3032 and RFC 4023. 🫶

Table of Contents

   1. Introduction ....................................................2
   2. Specification of Requirements ...................................3
   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

1. Introduction 🌸

RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" (NHLFE) 🧠 The NHLFE for a label maps that label to a next hop (plus some other stuff). When an MPLS packet shows up, its top label gets mapped to an NHLFE, and the packet goes to whatever next hop that NHLFE says 🚀

So here's our definition: a label is a "multicast label" in a particular context if the NHLFE it maps to, in that context, lists a set of next hops, with the vibe that the packet gets replicated and a copy goes to each of them 👯 Even a set with just one member counts 🙈 What makes it multicast is the meaning attached to the set: the plan to replicate and send to every member if there's more than one 💅

RFC 3032 [RFC3032] set up two data link layer codepoints for MPLS: one for "this frame is carrying an MPLS unicast packet" and one for "this frame is carrying an MPLS multicast packet" 🦋 RFC 3032 never precisely defines "multicast packet," though you could guess the "multicast" codepoint is meant to flag the top label as a multicast label. But the multicast codepoint has never been deployed 😭 And as MPLS multicast procedures got developed, it became clear that we do need two codepoints, just not the way RFC 3032 described them 🧚

Specifically, the codepoint doesn't need to say whether the top MPLS label is a multicast label 💖 When a receiver looks up the top label, the NHLFE already says whether that label is multicast or not ✨

This document updates RFC 3032 and RFC 4023 by re-specifying how the codepoints get used 🌈 The old use of the "multicast codepoint," as specified in those two RFCs, is now deprecated 🥀

Heads up: an implementation doing MPLS multicast according to RFC 3032 and/or 4023 won't be able to interoperate with implementations doing it according to this document 😬 Some deployed platforms might support the deprecated codepoint use, but they don't support the control plane mechanisms for MPLS multicast 🙃 Without a control plane, a system using the deprecated codepoint use can't even try to interoperate with a system using the codepoints the way this document says 🫠 (If someone did build an MPLS multicast control plane on a platform that only supports the deprecated codepoint, you'd get interop problems like black holes and/or misrouting. Not likely a real-world problem, though 🤷‍♀️)

RFC 3032 lets an MPLS packet ride in an ethernet multicast frame, but it doesn't say how to set the Medium Access Layer Destination Address (MAC DA) field in that case 😤 This document fills that in 💅

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 read as described in [RFC2119] 📖 No cap, those words are doing a lot of work here 💜

3. Upstream-Assigned vs. Downstream-Assigned 🦋

Picture this: a labeled packet P gets sent from Label Switching Router (LSR) R1 to LSR R2 🚚 R1 slaps label L onto the packet's label stack, and R2 has to look up L to figure out which Forwarding Equivalence Class (FEC) it belongs to, which we'll call F 🔍

If R2 made the binding between L and F and advertised it to R1, then the label binding is called "downstream-assigned" 📣 RFC 3031 only talks about downstream-assigned label bindings 📚

If R1 made the binding between L and F and advertised it to R2, then the label binding is called "upstream-assigned" 🌸

If a third party, say R3, made the binding between L and F and then advertised it to both R1 and R2, we also call that an "upstream-assigned" label binding 🧚

Upstream-assigned labels don't have to come from the same "label space" as downstream-assigned labels 🌈 For what "label space" means, see Section 3.14 of [RFC3031], and especially [RFC5331] 🤓 The rules for correctly interpreting an upstream-assigned label are in [RFC5331] ✨

If Ru and Rd are LSP adjacencies, they send MPLS packets to each other through one of these mechanisms:

1. Put the MPLS packet in a data link layer frame and transmit the frame 📦
2. Transmit the MPLS packet through an MPLS tunnel, meaning push an additional label (or labels) onto the label stack, and then use mechanism 1 🚇
3. Transmit the MPLS packet through an IP-based tunnel (e.g., via RFC 4023 [RFC4023]), and then use mechanisms 1 and/or 2 🌐

Short version: an MPLS packet goes through a data link, an MPLS tunnel, or an IP tunnel 🛤️ In any of those cases, once the packet comes out of the tunnel, the downstream LSR must know whether the label now at the top of the label stack has an upstream-assigned or a downstream-assigned label binding 🫶 To keep things simple, we'll just say "upstream-assigned label" for a label with an upstream-assigned binding 💖

Under certain conditions, specified below, multicast labels MAY be upstream-assigned 🎀 Using upstream-assigned labels is an OPTIONAL feature 🙌 Upstream-assigned labels MUST NOT be used unless it's known that the downstream LSR supports them 🚫 How that's known is outside the scope of this document 🤷‍♀️

This document makes no changes to the procedures for unicast labels 💅

We talk about three types of data link or tunnel:

• Point-to-Point. A point-to-point data link or tunnel connects two systems, so transmissions made by one get received by the other, and only the other 💞

For a given direction of a given point-to-point data link or tunnel, the following MUST be the case: either every MPLS packet will carry an upstream-assigned label, or else every MPLS packet will carry a downstream-assigned label 🎯 How you figure out which one is being used is outside the scope of this spec 🙃 But if there's no other info, the use of downstream-assigned labels MUST be presumed by default 🌸

• Point-to-Multipoint. A point-to-multipoint link or tunnel connects n systems, so only one of them can transmit onto the link or tunnel, and the other n-1 systems may receive those transmissions 📡

The top labels (before applying the data link or tunnel encapsulation) of all MPLS packets sent on a particular point-to-multipoint data link or tunnel MUST be of the same type: either all upstream-assigned or all downstream-assigned 🧁 That means every receiver on the MPLS or IP tunnel must know ahead of time whether upstream-assigned or downstream-assigned labels are in use 👀 How they know is outside the scope of this document 🫠

• Multipoint-to-Multipoint. A multipoint-to-multipoint link or tunnel connects n systems, so any of them can transmit on the link or tunnel, and the other n-1 systems may receive those transmissions 🌊

If MPLS packets are sent on a particular multipoint-to-multipoint link or tunnel, one of these scenarios applies:

1. It's known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is downstream-assigned 🩷
2. It's known (by methods outside the scope of this document) that the top label of every MPLS packet on the link or tunnel is upstream-assigned 💜
3. Some MPLS packets on the link may have upstream-assigned top labels while others have downstream-assigned top labels 🌀

If (and only if) the third scenario applies, the data link or tunnel encapsulation MUST provide a codepoint that specifies whether the top label of the encapsulated MPLS packet is upstream-assigned or downstream-assigned 🏷️ If a particular type of data link or tunnel doesn't provide such a codepoint, then the third scenario MUST NOT be used 🚫✨

The rest of this document specifies procedures for setting the data link layer codepoints and address fields 🎀

4. Ethernet Codepoints ✨

okay so ethernet is basically the poster child for a multipoint-to-multipoint data link 🦋 everybody can talk to everybody, bestie.

Ethertype 0x8847 is the go-to whenever a unicast ethernet frame is carrying an MPLS packet 💅

Ethertype 0x8847 also shows up when a multicast ethernet frame carries an MPLS packet, EXCEPT when the top label of that MPLS packet has been upstream-assigned 🙈 that's the one exception, no cap.

Ethertype 0x8848 is the one formerly known as the "MPLS multicast codepoint" 👑 and it is only for an MPLS packet whose top label is upstream-assigned, riding inside a multicast ethernet frame. Nothing else gets this one, periodt.

5. PPP Protocol Field 🎀

PPP is the point-to-point data link queen 🌸 When a PPP frame is carrying an MPLS packet, the PPP Protocol field is always set to 0x0281. Always. Non-negotiable. 💖

6. GRE Protocol Type 🧚

so [RFC4023] got a little glow-up here, and this section tells you how 💅

If the IP destination address of the Generic Routing Encapsulation (GRE) is a unicast IP address, then the ethertype value 0x8847 MUST be used in all cases for the MPLS-in-GRE encapsulation. No exceptions, bestie.

If the IP destination address of the GRE encapsulation is a multicast IP address, then:

• the ethertype value 0x8847 MUST be used when the top label of the encapsulated MPLS packet is downstream-assigned,
• the ethertype value 0x8848 MUST be used when the top label of the encapsulated MPLS packet is upstream-assigned.

Now, through procedures that are outside the scope of this spec, it may be known that if the destination address of a GRE packet is multicast, then the top label of the GRE payload is upstream-assigned. 🌈 In that case, seeing the 8847 codepoint in a GRE packet with a multicast destination IP address MUST be considered an error, and the packet MUST be discarded. 💀 Bye bye packet.

7. IP Protocol Number 🦋

[RFC4023] is modified like this: the IPv4 Protocol Number field or the IPv6 Next Header field is always set to 137, whether or not the encapsulated MPLS packet is an MPLS multicast packet. Same number every time, iconic ✨

If the IP destination address of the IP encapsulation is an IP multicast address, the IP tunnel may be considered a point-to-multipoint tunnel or a multipoint-to-multipoint tunnel. Either way, all encapsulated MPLS packets in that particular tunnel have a downstream-assigned label at the top of the stack, OR all of them have an upstream-assigned label at the top. No mixing and matching 🙅‍♀️ How the tunnel gets sorted into one camp or the other is outside the scope of this specification, so that's a mystery for another day 🔮

8. Ethernet MAC DA for Multicast MPLS 💜

When an LSR transmits a multicast MPLS packet in a multicast ethernet 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 follows:

1. vwxyz MAY be set to 0,
2. vwxyz MAY be set to the value of one of the MPLS labels on the packet's label stack.

Which of these is the default is implementation-dependent, totally up to the LSR 🍓 BUT, and this is a big but, LSRs using the two different procedures MUST interoperate. So an LSR MUST NOT filter packets where vwxyz was set to zero, and it MUST NOT indiscriminately filter all packets where vwxyz was NOT set to zero. Friends don't block friends 🫶

If an LSR follows the second procedure (setting vwxyz to a label value), and the label stack has two or more labels, then by default vwxyz MUST be set to the value of the second MPLS label on the stack. "The second label" just means the label in the stack entry right after the topmost one 🧠 An LSR MAY, if configured to, use a label other than the second one for this. And if the MPLS packet has only one label, then that label's value gets used instead, since there's no second label to grab 🤷‍♀️

It is expected that the LSR will follow the procedures of [RFC5331], pushing on two labels: the topmost one is a "context label" that's the same for every MPLS packet the LSR puts onto the ethernet, and the second one is different for different LSPs. 🌸 So if the MAC DA is a function of the second label, more LSP-specific info shows up right in the MAC DA field. That can be used to filter multicast packets with "unexpected" non-zero vwxyz values. Further discussion of that filtering, and what it's good for, is outside the scope of this document 📚

The use of ethernet and/or IP broadcast addresses (as distinguished from multicast addresses) does not fall within the scope of this specification. Broadcast? Not my department, babe 💅

9. IANA Considerations 👑

IANA already owns the ethernet multicast addresses in the 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 when an ethernet multicast frame carries an IP multicast packet. 🎀

IANA has reserved ethernet addresses in the range 01-00-5e-80-00-00 to 01-00-5e-8f-ff-ff for when an ethernet multicast frame carries an MPLS multicast packet. Addresses in this range are valid when used with ethertype 8847 or 8848 ✨

Since this document modifies how ethertypes 8847 and 8848 are used, IANA changed their descriptions:

• Ethertype 8847 is defined as "MPLS", as defined in [RFC3032] and in this document.
• Ethertype 8848 is defined as "MPLS with upstream-assigned label", as defined in this document.

10. Security Considerations 🔥

The security considerations of [RFC3032] and [RFC4023] apply. Read them, they matter 💅

Malicious changing of the codepoint may result in loss or misrouting of packets. Yikes 😭 However, altering the codepoint without also altering the label does not result in a predictable effect, so the attacker is kind of flailing around in the dark there 🙈

Malicious alteration of the MAC DA on an ethernet can result in packets being received by a third party, rather than by the intended recipient. That is a whole vibe-killer, so keep an eye on your MAC DA 👀

11. Normative References 🌈

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
• [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
• [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 Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134

EMail: eckert@cisco.com

---

Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719

EMail: erosen@cisco.com

---

Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089

EMail: rahul@juniper.net

---

Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089

EMail: yakov@juniper.net

Full Copyright Statement 💜

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.