IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN
draft-ietf-l3vpn-mvpn-infra-addrs-05
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6515.
|
|
---|---|---|---|
Authors | Eric C. Rosen , Rahul Aggarwal | ||
Last updated | 2021-02-09 (Latest revision 2011-07-06) | ||
Replaces | draft-rosen-l3vpn-mvpn-infra-addrs | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Proposed Standard | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Ben Niven-Jenkins | ||
IESG | IESG state | Became RFC 6515 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Stewart Bryant | ||
IESG note | |||
Send notices to | (None) |
draft-ietf-l3vpn-mvpn-infra-addrs-05
L3VPN Working Group Rahul Aggarwal Internet Draft Juniper Networks, Inc. Intended Status: Proposed Standard Updates: draft ietf-l3vpn-2547bis-mcast-bgp-08.txt Eric C. Rosen Expires: January 6, 2012 Cisco Systems, Inc. July 6, 2011 IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN draft-ietf-l3vpn-mvpn-infra-addrs-05.txt Abstract To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates draft-ietf- l3vpn-2547bis-mcast-bgp-08.txt. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 Raggarwa & Rosen [Page 1] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 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 http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2011 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, as 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. Raggarwa & Rosen [Page 2] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 Table of Contents 1 Introduction .......................................... 4 1.1 Specification of requirements ......................... 4 1.2 Acronyms Used in this Document ........................ 4 1.3 IPv4 and IPv6 Addresses in MCAST-VPN Routes ........... 5 2 PE Addresses in MCAST-VPN Routes ...................... 6 3 VRF Route Import Extended Community ................... 7 4 PMSI Tunnel Attributes in I-PMSI A-D Routes ........... 7 4.1 Relationship to AFI Value ............................. 7 4.2 Relationship to Next Hop Address Family ............... 8 5 IANA Considerations ................................... 8 6 Security Considerations ............................... 8 7 Acknowledgments ....................................... 8 8 Authors' Addresses .................................... 9 9 Normative References .................................. 9 10 Informational References .............................. 9 Raggarwa & Rosen [Page 3] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 1. Introduction 1.1. 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.2. Acronyms Used in this Document This document uses a number of acronyms, mostly taken directly from the BGP and VPN specifications. - A-D Route: Auto-Discovery Route [MVPN] - AFI: Address Family Identifier [BGP-MP] - AS: Autonomous System [BGP] - I-PMSI: Inclusive PMSI [RFC4364] - MCAST-VPN: Multicast Virtual Private Network [MVPN-BGP] - 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 Raggarwa & Rosen [Page 4] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 1.3. IPv4 and IPv6 Addresses in MCAST-VPN Routes [MVPN-BGP] defines a new set of BGP route types that are used by SPs to provide Multicast Virtual Private Network service to their customers. These routes have a newly defined BGP NLRI, the "MCAST- VPN" NLRI. MCAST-VPN NLRI is carried in 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 used to identify the NLRI as being 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 indicates that any customer multicast addresses occurring in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute are IPv4 addresses; AFI 2 indicates that any such addresses are IPv6 addresses. However, some of the MCAST-VPN routes also contain addresses of PE routers in the SP network. An SP with an IPv4 network may provide MVPN service for customers that use IPv6, and an SP with an IPv6 network may provide MVPN service for customers that use IPv4. Therefore 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 purpose of this document is to make it clear that whenever a PE address occurs in an MCAST-VPN route (whether in the NLRI or in an attribute), the IP address family of that address is determined by the length of the address (a length of 4 octets for IPv4 addresses, a length of 16 octets for IPv6 addresses), NOT by the AFI field of the route. In particular, if a SP with an IPv4 core network is providing MVPN/IPv6 service to a customer, the PE addresses in the MCAST-VPN routes will be four-octet IPv4 routes, even though the AFI of those routes will have the value 2. Some previous specifications (e.g., [RFC4659] and [RFC4798]) have taken a different approach, requiring 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 use that approach. Rather, this specification uses the approach adopted in [RFC4684] and [RFC5549]. The MCAST-VPN routes contain enough information to enable 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 Raggarwa & Rosen [Page 5] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 specifies how to encode an IPv6 address in this attribute, independent of whether the attribute is attached to a VPN-IPv4 route or a VPN-IPv6 route. This document also clarifies an issue with respect to the significance of the Address Family field of an Intra-AS I-PMSI A-D route that carries a PMSI Tunnel Attribute. 2. PE Addresses in MCAST-VPN Routes PE addresses occur in MCAST-VPN routes in the following places: 1. "Network Address of Next Hop" field in the MP_REACH_NLRI attribute, as defined in section 3 of [BGP-MP]. This field is preceded by a "length of next hop address" field. Hence it is always clear whether the address is an IPv4 address (length is 4) or an IPv6 address (length is 16). If the length of 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 one-octet route type field, followed by a one-octet "NLRI length" field. In the Intra-AS I-PMSI A-D route, the length is followed by an 8-octet 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 thus 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, one 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]. Raggarwa & Rosen [Page 6] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 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, one 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 is an "IPv4 Address Specific Extended Community" of type "VRF Route Import"; hence 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. A codepoint for this type of extended community will be allocated by IANA. 4. PMSI Tunnel Attributes in I-PMSI A-D Routes When a PMSI Tunnel Attribute occurs in an I-PMSI A-D route originated by a particular PE or ASBR, it identifies a tunnel that the PE/ASBR uses by default for carrying the multicast traffic of a particular customer MVPN. The proper encoding and interpretation of the PMSI Tunnel attribute is affected by both the AFI and "Network Address of Next Hop" fields. 4.1. Relationship to AFI Value When the PMSI Tunnel Attribute occurs in a BGP Update message with a MP_REACH_NLRI attribute whose AFI is 1, the meaning is that the identified tunnel is used by default to carry IPv4 MVPN traffic for a particular customer MVPN. When the PMSI Tunnel Attribute occurs in a BGP Update message with a MP_REACH_NLRI attribute whose AFI is 2, the meaning is that the identified tunnel is used by default to carry IPv6 MVPN traffic for a particular customer MVPN. To assign both IPv4 and IPv6 MVPN traffic to an I-PMSI tunnel, two I-PMSI A-D routes MUST be used, one whose MP_REACH_NLRI has an AFI of 1, and one whose MP_REACH_NLRI has an AFI of 2. To use the same tunnel for both IPv4 and IPv6 traffic, the same value of the PMSI Tunnel attribute can be Raggarwa & Rosen [Page 7] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 used in each route. 4.2. Relationship to Next Hop Address Family If the "Network Address of Next Hop" field in the MP_REACH_NLRI attribute contains an IPv4 address, then any IP addresses appearing 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 contains an IPv6 address, then any IP addresses appearing in the "Tunnel Identifier" field of the PMSI Tunnel Attribute MUST be IPv6 addresses. If these conditions are not met, the PMSI Tunnel Attribute MUST be handled as a "malformed" PMSI Tunnel Attribute, as specified in section 5 [MVPN-BGP]. 5. IANA Considerations IANA is requested to assign a codepoint for "VRF Route Import" in the "IPv6 Address Specific Extended Community" registry. The codepoint should be assigned from the "transitive communities" portion of the namespace. We suggest assignment of the value 0x000b (to correspond to the value that is already assigned for "VRF Route Import" in the "IPv4 Address Specific Extended Community" registry). The references should be to this document and to [MVPN-BGP]. 6. Security Considerations This document does not raise any security considerations beyond those raised by [MVPN-BGP]. 7. Acknowledgments The authors wish to thank Dongling Duan, Keyur Patel, Yakov Rekhter, and Karthik Subramanian. Raggarwa & Rosen [Page 8] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 8. Authors' Addresses Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 Email: rahul@juniper.net Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 E-mail: erosen@cisco.com 9. Normative References [BGP] Rekhter, Y., Li, T., Hares, S., "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li, S. Hares, RFC 4271, January 2006 [BGP-MP] "Multiprotocol Extensions for BGP-4", T. Bates, R. Chandra, D. Katz, Y. Rekhter, RFC 4760, January 2007 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2010 [MVPN-BGP], "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, October 2009 [RFC2119] "Key words for use in RFCs to Indicate Requirement Levels.", Bradner, March 1997 10. Informational References [RFC4291] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering, RFC 4291, February 2006. [RFC4364] "BGP/MPLS IP Virtual Private Networks (VPNs)", E. Rosen, Y. Rekhter, RFC4364, February 2006 [RFC4659] "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. RFC Raggarwa & Rosen [Page 9] Internet Draft draft-ietf-l3vpn-mvpn-infra-addrs-05.txt July 2011 4659, September 2006 [RFC4798] "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. RFC 4798, February 2007 [RFC4684] "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. RFC 4684 November 2006 [RFC5549] "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop" F. Le Faucheur, E. Rosen. RFC 5549, May 2009 [RFC5701] "IPv6 Address Specific BGP Extended Community Attribute" Y. Rekhter. RFC 5701, November 2009 Raggarwa & Rosen [Page 10]