RFC 6515

IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN

📅 published February 2012, from ietf

RFC 6515 🎀 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN (February 2012) is an Internet Standards Track doc from the IETF. It was written by R. Aggarwal (Juniper Networks, Inc.) and E. Rosen (Cisco Systems, Inc.), it's ISSN 2070-1721, it updates RFC 6514, and it doesn't obsolete anything. 💖

Abstract 🎀

okay so Provider Edge routers send out BGP Update messages to make Multicast VPN (MVPN) service work, and those messages carry the "MCAST-VPN" BGP routes 🌸. They also send unicast VPN routes that carry MVPN-specific attributes. These routes include addresses from the customer's address space and addresses from the provider's address space. The two spaces are independent, and their address families (IPv4 or IPv6) might match or might not ✨. Every route has an "address family" field that says whether the customer addresses are IPv4 or IPv6, but there's no field that tells you the address family of the provider addresses 🙈. So to keep everybody interoperable, this document says provider IPv4 addresses are always encoded as 4-octet addresses, and the IPv4 vs IPv6 difference is signaled only by the length of the address field 🦋. It explains the specific cases in detail. This document updates RFC 6514. 💅

Status of This Memo 🌈

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6515 🍓.

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 📜

Table of Contents 💜

1. Introduction ....................................................2
   1.1. IPv4 and IPv6 Addresses in MCAST-VPN Routes ................2
   1.2. Specification of Requirements ..............................4
   1.3. Acronyms Used in This Document .............................4
2. PE Addresses in MCAST-VPN Routes ................................4
3. VRF Route Import Extended Community .............................5
4. PMSI Tunnel Attributes in I-PMSI A-D Routes .....................6
   4.1. Relationship to AFI Value ..................................6
   4.2. Relationship to Next Hop Address Family ....................6
5. IANA Considerations .............................................7
6. Security Considerations .........................................7
7. Acknowledgments .................................................7
8. Normative References ............................................7
9. Informative References ..........................................7

1. Introduction ✨

1.1. IPv4 and IPv6 Addresses in MCAST-VPN Routes 👑

[MVPN-BGP] defines a new set of BGP route types that service providers (SPs) use to offer Multicast Virtual Private Network service to their customers 🫶. These routes have a newly defined BGP NLRI, the "MCAST-VPN" NLRI. The MCAST-VPN NLRI rides inside the NLRI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attributes defined in [BGP-MP]. The SAFI field of the MP_REACH_NLRI/MP_UNREACH_NLRI attribute is what marks the NLRI as an MCAST-VPN NLRI.

When the SAFI field of an MP_REACH_NLRI/MP_UNREACH_NLRI attribute has the "MCAST-VPN" value, the AFI field has two defined values: 1 and 2. AFI 1 means any customer multicast addresses in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses, and AFI 2 means those addresses are IPv6 addresses. 🦋

Here's the plot twist 😭: some MCAST-VPN routes also contain addresses of Provider Edge (PE) routers in the SP network. An SP with an IPv4 network may provide MVPN service for customers using IPv6, and an SP with an IPv6 network may provide MVPN service for customers that use IPv4. So the address family of the PE addresses MUST NOT be inferred from the AFI field of the associated MP_REACH_NLRI/MP_UNREACH_NLRI attribute. ⚠️

the whole point of this doc is to make it crystal clear that whenever a PE address shows up in an MCAST-VPN route (in the NLRI or in an attribute), its IP address family is decided by the length of the address (4 octets for IPv4, 16 octets for IPv6), NOT by the AFI field of the route. 💀

For example, if an SP with an IPv4 core network is giving MVPN/IPv6 service to a customer, the PE addresses in the MCAST-VPN routes will be 4-octet IPv4 routes, even though the AFI of those routes has the value 2. 🙈

Some earlier specs (like [RFC4659] and [RFC4798]) went a different way. They required that in any routes containing IPv6 or VPN-IPv6 customer addresses, the IPv4 PE addresses be represented as IPv6-mapped IPv4 addresses [RFC4291]. This document does not do that. Instead, this specification uses the approach adopted in [RFC4684] and [RFC5549]. The MCAST-VPN routes carry enough information for the IP address family of the PE addresses to be inferred from the address lengths. 🧠

[MVPN-BGP] also defines an attribute, the "VRF Route Import Extended Community", that is attached to unicast VPN-IPv4 or VPN-IPv6 routes. This extended community contains a PE address, and this document specifies how to encode an IPv6 address in this attribute, no matter whether the attribute is attached to a VPN-IPv4 route or a VPN-IPv6 route. 💖

This document also clears up an issue about the significance of the Address Family field of an Intra-AS I-PMSI A-D route that carries a PMSI Tunnel Attribute. 🎀

1.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]. 🔥

1.3. Acronyms Used in This Document 🍓

This document uses a bunch of acronyms, mostly lifted straight from the BGP and VPN specs 🌸.

  • A-D Route: Auto-Discovery Route [MVPN]
  • AFI: Address Family Identifier [BGP-MP]
  • AS: Autonomous System [BGP]
  • I-PMSI: Inclusive PMSI [RFC4364]
  • MVPN: Multicast Virtual Private Network [MVPN]
  • MCAST-VPN routes: BGP routes of "MCAST-VPN" Subsequent Address Family, as defined in [MVPN-BGP]. The NLRI of such routes may be referred to as MCAST-VPN NLRI.
  • MP_REACH_NLRI: Multiprotocol Reachable NLRI [BGP-MP]
  • MP_UNREACH_NLRI: Multiprotocol Unreachable NLRI [BGP-MP]
  • PMSI: Provider Multicast Service Interface [MVPN]
  • NLRI: Network Layer Reachability Information [BGP]
  • PE: Provider Edge [RFC4364]
  • S-PMSI: Selective PMSI [RFC4364]
  • SAFI: Subsequent Address Field Identifier [BGP-MP]
  • SP: Service Provider

2. PE Addresses in MCAST-VPN Routes 🦋

okay so PE addresses show up in MCAST-VPN routes in these places 👀:

  1. "Network Address of Next Hop" field in the MP_REACH_NLRI attribute, as defined in Section 3 of [BGP-MP]. This field comes right after a "length of next hop address" field, so it's always clear whether the address is IPv4 (length is 4) or IPv6 (length is 16). If the length of the next hop address is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP]. 🫶
  2. "Intra-AS I-PMSI A-D route", defined in Section 4.1 of [MVPN-BGP]. All MCAST-VPN routes begin with a 1-octet route type field, followed by a 1-octet "NLRI length" field. In the Intra-AS I-PMSI A-D route, the length is followed by an 8-octet Route Distinguisher (RD), which is then followed by the "Originating Router's IP Address" field. The length of this field (4 octets for IPv4 or 16 octets for IPv6) can therefore be inferred from the NLRI length field (which will be either 12 or 24, respectively). If the inferred length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP]. 🧮
  3. "S-PMSI A-D Route", defined in Section 4.3 of [MVPN-BGP]. In this route, the "NLRI length" field is followed by an 8-octet RD, a variable-length "multicast source" field, a variable-length "multicast group" field, and an "Originating Router's IP Address" field. The two variable-length fields have their own length fields. From these two length fields and the NLRI length field, you can compute the length of the "Originating Router's IP Address" field, which again is either 4 for IPv4 or 16 for IPv6. If the computed length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP]. 🌈
  4. "Leaf A-D Route", defined in Section 4.4 of [MVPN-BGP]. In this route, the "NLRI length" field is following by a variable-length "route key", which is followed by the "Originating Router's IP Address" field. The Route Key has its own length field. From the NLRI length and the route key length, you can compute the length of the "Originating Router's IP Address" field. If the computed length of the "Originating Router's IP Address" field is neither 4 nor 16, the MP_REACH_NLRI attribute MUST be considered to be "incorrect", and MUST be handled as specified in Section 7 of [BGP-MP]. 💅

3. VRF Route Import Extended Community 🧚

The "VRF Route Import Extended Community", specified in [MVPN-BGP], is an attribute carried by unicast VPN-IPv4 or VPN-IPv6 routes. It's an "IPv4 Address Specific Extended Community" of type "VRF Route Import", so it can only carry an IPv4 address 🙃. To carry an IPv6 address, an "IPv6 Address Specific Extended Community" [RFC5701], of type "VRF Route Import", must be used. IANA has allocated a code point for this type of extended community. 👑

4. PMSI Tunnel Attributes in I-PMSI A-D Routes 🌸

When a PMSI Tunnel Attribute shows up in an I-PMSI A-D route originated by a particular PE or Autonomous System Border Router (ASBR), it identifies a tunnel that the PE/ASBR uses by default to carry the multicast traffic of a particular customer MVPN 🎀. How the PMSI Tunnel attribute is properly encoded and interpreted depends on both the AFI and "Network Address of Next Hop" fields. 🔥

more of section 4 (and everything after it) is coming up in part 2 👀🫶

4.1. Relationship to AFI Value

okay so when the PMSI Tunnel Attribute shows up in a BGP Update message whose MP_REACH_NLRI has an AFI of 1, it means the tunnel is used by default to carry IPv4 MVPN traffic for a particular customer MVPN 🌸. if the MP_REACH_NLRI has an AFI of 2 instead, the tunnel is the default for IPv6 MVPN traffic for that customer MVPN 💖.

now here's the lowkey important bit ✨: if you want BOTH IPv4 and IPv6 MVPN traffic on one I-PMSI tunnel, you MUST use two I-PMSI A-D routes, one with an AFI of 1 and one with an AFI of 2 🎀. and to use the same tunnel for both families, you can reuse the same value of the PMSI Tunnel attribute in each route 🦋. it's giving efficiency, no cap 💅.

4.2. Relationship to Next Hop Address Family

this one is about matching families 🧚.

if the "Network Address of Next Hop" field in the MP_REACH_NLRI attribute holds an IPv4 address, then any IP addresses in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be IPv4 addresses 💜.

if the "Network Address of Next Hop" field in the MP_REACH_NLRI attribute holds an IPv6 address, then any IP addresses in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be IPv6 addresses 🌈.

and if those conditions aren't met? the PMSI Tunnel Attribute MUST be handled as a "malformed" PMSI Tunnel Attribute, as specified in Section 5 of [MVPN-BGP] 😭. that's a whole vibe check, bestie 💀.

5. IANA Considerations ✨

IANA has assigned the code point 0x000b for "VRF Route Import" in the "IPv6 Address Specific Extended Community" registry, in the "transitive communities" portion of the namespace 🎀. the references for this are this document and [MVPN-BGP] 🫶.

6. Security Considerations 🔥

okay bestie, this section is short but it's SERIOUS 😭. this document does not raise any security considerations beyond those raised by [MVPN-BGP]. so everything worth worrying about is already covered over there, and nothing new shows up here 🙈.

7. Acknowledgments 🌸

the authors wanna give a huge thank you to Dongling Duan, Keyur Patel, Yakov Rekhter, and Karthik Subramanian 💖🫶. the real MVPs 👑.

8. Normative References 📚

  • [BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [BGP-MP] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
  • [MVPN] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, February 2012.
  • [MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

9. Informative References 🦋

  • [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
  • [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
  • [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
  • [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
  • [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
  • [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
  • [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, November 2009.

Authors' Addresses 💌

Rahul Aggarwal
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089
EMail: raggarwa_1@yahoo.com

Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com

the end, bestie 🌈✨💖 that's the whole spec!

📦 where this page comes from