From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5549.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc5549.txt (limited to 'doc/rfc/rfc5549.txt') diff --git a/doc/rfc/rfc5549.txt b/doc/rfc/rfc5549.txt new file mode 100644 index 0000000..dbe72f5 --- /dev/null +++ b/doc/rfc/rfc5549.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group F. Le Faucheur +Request for Comments: 5549 E. Rosen +Category: Standards Track Cisco Systems + May 2009 + + + Advertising IPv4 Network Layer Reachability Information + with an IPv6 Next Hop + +Status of This Memo + + This document specifies an Internet standards track protocol for the + 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. + +Copyright Notice + + Copyright (c) 2009 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 in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + Multiprotocol BGP (MP-BGP) specifies that the set of network-layer + protocols to which the address carried in the Next Hop field may + belong is determined by the Address Family Identifier (AFI) and the + Subsequent Address Family Identifier (SAFI). The current AFI/SAFI + definitions for the IPv4 address family only have provisions for + advertising a Next Hop address that belongs to the IPv4 protocol when + advertising IPv4 Network Layer Reachability Information (NLRI) or + VPN-IPv4 NLRI. This document specifies the extensions necessary to + allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address + that belongs to the IPv6 protocol. This comprises an extension of + the AFI/SAFI definitions to allow the address of the Next Hop for + IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the + encoding of the Next Hop in order to determine which of the protocols + the address actually belongs to, and a new BGP Capability allowing + MP-BGP Peers to dynamically discover whether they can exchange IPv4 + NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. + + + + + +Le Faucheur & Rosen Standards Track [Page 1] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Requirements Language ...........................................4 + 3. Extension of AFI/SAFI Definitions for the IPv4 Address Family ...4 + 4. Use of BGP Capability Advertisement .............................5 + 5. Operations ......................................................7 + 6. Usage Examples ..................................................7 + 6.1. IPv4 over IPv6 Core ........................................7 + 6.2. IPv4 VPN over IPv6 Core ....................................8 + 7. IANA Considerations .............................................8 + 8. Security Considerations .........................................8 + 9. Acknowledgments .................................................9 + 10. References .....................................................9 + 10.1. Normative References ......................................9 + 10.2. Informative References ....................................9 + +1. Introduction + + Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of + network-layer protocols to which the address carried in the Next Hop + field may belong is determined by the Address Family Identifier (AFI) + and the Subsequent Address Family Identifier (SAFI). A number of + existing AFI/SAFIs allow the Next Hop address to belong to a + different address family than the Network Layer Reachability + Information (NLRI). For example, the AFI/SAFI <25/65> used (as per + [L2VPN-SIG]) in order to perform L2VPN auto-discovery, allows + advertising NLRI that contains the identifier of a Virtual Private + LAN Service (VPLS) instance or that identifies a particular pool of + attachment circuits at a given Provider Edge (PE), while the Next Hop + field contains the loopback address of a PE. Similarly, the AFI/SAFI + <1/132> (defined in [RFC4684]) in order to advertise Route Target + (RT) membership information, allows advertising NLRI that contains + such RT membership information, while the Next Hop field contains the + address of the advertising router. + + Furthermore, a number of these existing AFI/SAFIs allow the Next Hop + to belong to either the IPv4 Network Layer Protocol or the IPv6 + Network Layer Protocol, and specify the encoding of the Next Hop + information in order to determine which of the protocols the address + actually belongs to. For example, [RFC4684] allows the Next Hop + address to be either IPv4 or IPv6 and states that the Next Hop field + address shall be interpreted as an IPv4 address whenever the length + of Next Hop address is 4 octets, and as an IPv6 address whenever the + length of the Next Hop address is 16 octets. + + There are situations such as those described in [RFC4925] and in + [MESH-FMWK] where carriers (or large enterprise networks acting as + + + +Le Faucheur & Rosen Standards Track [Page 2] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + carrier for their internal resources) may be required to establish + connectivity between 'islands' of networks of one address family type + across a transit core of a differing address family type. This + includes both the case of IPv6 islands across an IPv4 core and the + case of IPv4 islands across an IPv6 core. Where Multiprotocol BGP + (MP-BGP) is used to advertise the corresponding reachability + information, this translates into the requirement for a BGP speaker + to advertise Network Layer Reachability Information (NLRI) of a given + address family via a Next Hop of a different address family (i.e., + IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with IPv6 Next Hop). + + The current AFI/SAFI definitions for the IPv6 address family assume + that the Next Hop address belongs to the IPv6 address family type. + Specifically, as per [RFC2545] and [RFC3107], when the is + <2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6 + type. As per [RFC4659], when the is <2/128>, the Next Hop + address is assumed to be of IPv6-VPN type. + + However, [RFC4798] and [RFC4659] specify how an IPv4 address can be + encoded inside the Next Hop IPv6 address field when IPv6 NLRI needs + to be advertised with an IPv4 Next Hop. [RFC4798] defines how the + IPv4-mapped IPv6 address format specified in the IPv6 addressing + architecture ([RFC4291]) can be used for that purpose when the is <2/1>, <2/2>, or <2/4>. [RFC4659] defines how the IPv4- + mapped IPv6 address format as well as a null Route Distinguisher can + be used for that purpose when the is <2/128>. Thus, there + are existing solutions for the advertisement of IPv6 NLRI with an + IPv4 Next Hop. + + Similarly, the current AFI/SAFI definitions for advertisement of IPv4 + NLRI or VPN-IPv4 NLRI assume that the Next Hop address belongs to the + IPv4 address family type. Specifically, as per [RFC4760] and + [RFC3107], when the is <1/1>, <1/2>, or <1/4>, the Next + Hop address is assumed to be of IPv4 type. As per [RFC4364], when + the is <1/128>, the Next Hop address is assumed to be of + VPN-IPv4 type. There is clearly no generally applicable method for + encoding an IPv6 address inside the IPv4 address field of the Next + Hop. Hence, there is currently no specified solution for advertising + IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop. + + This document specifies the extensions necessary to do so. This + comprises an extension of the AFI/SAFI definitions to allow the + address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to belong to + either the IPv4 or the IPv6 protocol, the encoding of the Next Hop + information in order to determine which of the protocols the address + actually belongs to, and a new BGP Capability allowing MP-BGP peers + to dynamically discover whether they can exchange IPv4 NLRI and VPN- + IPv4 NLRI with an IPv6 Next Hop. The new BGP Capability allows + + + +Le Faucheur & Rosen Standards Track [Page 3] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + gradual deployment of the new functionality of advertising IPv4 + reachability via an IPv6 Next Hop, without any flag day nor any risk + of traffic black-holing. + +2. Requirements Language + + 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 RFC 2119 [RFC2119]. + +3. Extension of AFI/SAFI Definitions for the IPv4 Address Family + + As mentioned earlier, MP-BGP specifies that the set of network-layer + protocols to which the address carried in the Next Hop field may + belong is determined by the Address Family Identifier (AFI) and the + Subsequent Address Family Identifier (SAFI). The following current + AFI/SAFI definitions for the IPv4 NLRI or VPN-IPv4 NLRI (<1/1>, + <1/2>, <1/4>, and <1/128>) only have provisions for advertising a + Next Hop address that belongs to the IPv4 protocol. This document + extends the definition of the AFI/SAFI for advertisement of IPv4 NLRI + and VPN-IPv4 NLRI to extend the set of network-layer protocols to + which the Next Hop address can belong, to include IPv6 in addition to + IPv4. + + Specifically, this document allows advertising with [RFC4760] of an + MP_REACH_NLRI with: + + o AFI = 1 + + o SAFI = 1, 2, 4, or 128 + + o Length of Next Hop Address = 16 or 32 + + o Next Hop Address = IPv6 address of next hop (potentially followed + by the link-local IPv6 address of the next hop). This field is to + be constructed as per Section 3 of [RFC2545]. + + o NLRI= NLRI as per current AFI/SAFI definition + + This is in addition to the current mode of operation allowing + advertisement of NLRI for of <1/1>, <1/2> and <1/4> with a + next hop address of IPv4 type and advertisement of NLRI for of <1/128> with a next hop address of VPN-IPv4 type. + + The BGP speaker receiving the advertisement MUST use the Length of + Next Hop Address field to determine which network-layer protocol the + next hop address belongs to. When the Length of Next Hop Address + field is equal to 16 or 32, the next hop address is of type IPv6. + + + +Le Faucheur & Rosen Standards Track [Page 4] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + Note that this method of using the Length of the Next Hop Address + field to determine which network-layer protocol the next hop address + belongs to (out of the set of protocols allowed by the AFI/SAFI + definition) is the same as used in [RFC4684] and [L2VPN-SIG]. + +4. Use of BGP Capability Advertisement + + [RFC5492] defines a mechanism to allow two BGP speakers to discover + if a particular capability is supported by their BGP peer and thus + whether it can be used with that peer. This document defines a new + capability that can be advertised using [RFC5492] and that is + referred to as the Extended Next Hop Encoding capability. This + capability allows BGP speakers to discover whether, for a given NLRI + , a peer supports advertisement with a next hop whose + network protocol is determined by the value of the Length of Next Hop + Address field, as specified in Section 3. + + A BGP speaker that wishes to advertise to a BGP peer an IPv6 Next Hop + for IPv4 NLRI or for VPN-IPv4 NLRI as per this specification MUST use + the Capability Advertisement procedures defined in [RFC5492] with the + Extended Next Hop Encoding Capability to establish whether its peer + supports this for the NLRI AFI/SAFI pair(s) of interest. The fields + in the Capabilities Optional Parameter MUST be set as follows: + + o The Capability Code field MUST be set to 5 (which indicates the + Extended Next Hop Encoding capability). + + o The Capability Length field is set to a variable value that is the + length of the Capability Value field (which follows). + + o The Capability Value field has the following format: + + +-----------------------------------------------------+ + | NLRI AFI - 1 (2 octets) | + +-----------------------------------------------------+ + | NLRI SAFI - 1 (2 octets) | + +-----------------------------------------------------+ + | Nexthop AFI - 1 (2 octets) | + +-----------------------------------------------------+ + | ..... | + +-----------------------------------------------------+ + | NLRI AFI - N (2 octets) | + +-----------------------------------------------------+ + | NLRI SAFI - N (2 octets) | + +-----------------------------------------------------+ + | Nexthop AFI - N (2 octets) | + +-----------------------------------------------------+ + + + + +Le Faucheur & Rosen Standards Track [Page 5] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + where: + + * each triple indicates that + NLRI of may be advertised with a Next + Hop address belonging to the network-layer protocol of Nexthop + AFI. + + * the AFI and SAFI values are defined in the Address Family + Identifier and Subsequent Address Family Identifier registries + maintained by IANA. + + Since this document only concerns itself with the advertisement of + IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop, this specification + only allows the following values in the Capability Value field of the + Extended Next Hop Encoding capability: + + o NLRI AFI = 1 (IPv4) + + o NLRI SAFI = 1, 2, 4, or 128 + + o Nexthop AFI = 2 (IPv6) + + This specification does not propose that the Extended Next Hop + Encoding capability be used with any other combinations of . In particular, this specification does not + propose that the Extended Next Hop Encoding capability be used for + NLRI AFI/SAFIs whose definition already allows use of both IPv4 and + IPv6 next hops (e.g., AFI/SAFI = <1/132> as defined in [RFC4684]). + Similarly, it does not propose that the Extended Next Hop Encoding + capability be used for NLRI AFI/SAFIs for which there is already a + solution for advertising a next hop of a different address family + (e.g., AFI/SAFI = <2/1>, <2/2>, or <2/4> with IPv4 Next Hop as per + [RFC4798] and AFI/SAFI = <2/128> with IPv4 Next Hop as per + [RFC4659]). + + It is expected that if new AFI/SAFIs are defined in the future, their + definition will have provisions (where appropriate) for both IPv4 and + IPv6 Next Hops from the onset, with determination based on Length of + Next Hop Address field. Thus, new AFI/SAFIs are not expected to make + use of the Extended Next Hop Encoding capability. + + A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 + NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained + via BGP Capability Advertisement that the BGP peer supports the + Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. + + The Extended Next Hop Encoding capability provides information about + next hop encoding for a given AFI/SAFI, assuming that AFI/SAFI is + + + +Le Faucheur & Rosen Standards Track [Page 6] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + allowed. It does not influence whether that AFI/SAFI is indeed + allowed. Whether a AFI/SAFI can be used between the BGP peers is + purely determined through the Multiprotocol Extensions capability + defined in [RFC4760]. + + The Extended Next Hop Encoding capability MAY be dynamically updated + through the use of the Dynamic Capability capability and associated + mechanisms defined in [DYN-CAP]. + +5. Operations + + By default, if a particular BGP session is running over IPvx (where + IPvx is IPv4 or IPv6), and if the BGP speaker sending an update is + putting its own address in as the next hop, then the next hop address + SHOULD be specified as an IPvx address, using the encoding rules + specified in the AFI/SAFI definition of the NLRI being updated. This + default behavior may be overridden by policy. + + When a next hop address needs to be passed along unchanged (e.g., as + a Route Reflector (RR) would do), its encoding MUST NOT be changed. + If a particular RR client cannot handle that encoding (as determined + by the BGP Capability Advertisement), then the NLRI in question + cannot be distributed to that client. For sound routing in certain + scenarios, this will require that all the RR clients be able to + handle whatever encodings any of them may generate. + +6. Usage Examples + +6.1. IPv4 over IPv6 Core + + The extensions defined in this document may be used as discussed in + [MESH-FMWK] for the interconnection of IPV4 islands over an IPv6 + backbone. In this application, Address Family Border Routers (AFBRs; + as defined in [RFC4925]) advertise IPv4 NLRI in the MP_REACH_NLRI + along with an IPv6 Next Hop. + + The MP_REACH_NLRI is encoded with: + + o AFI = 1 + + o SAFI = 1 + + o Length of Next Hop Network Address = 16 (or 32) + + o Network Address of Next Hop = IPv6 address of Next Hop + + o NLRI = IPv4 routes + + + + +Le Faucheur & Rosen Standards Track [Page 7] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + During BGP Capability Advertisement, the PE routers would include the + following fields in the Capabilities Optional Parameter: + + o Capability Code set to "Extended Next Hop Encoding" + + o Capability Value containing + +6.2. IPv4 VPN over IPv6 Core + + The extensions defined in this document may be used for support of + IPV4 VPNs over an IPv6 backbone. In this application, PE routers + would advertise VPN-IPv4 NLRI in the MP_REACH_NLRI along with an IPv6 + Next Hop. + + The MP_REACH_NLRI is encoded with: + + o AFI = 1 + + o SAFI = 128 + + o Length of Next Hop Network Address = 16 (or 32) + + o Network Address of Next Hop = IPv6 address of Next Hop + + o NLRI = IPv4-VPN routes + + During BGP Capability Advertisement, the PE routers would include the + following fields in the Capabilities Optional Parameter: + + o Capability Code set to "Extended Next Hop Encoding" + + o Capability Value containing + +7. IANA Considerations + + This document defines, in Section 4, a new Capability Code to + indicate the Extended Next Hop Encoding capability in the [RFC5492] + Capabilities Optional Parameter. The value for this new Capability + Code is 5, which is in the range set aside for allocation using the + "IETF Review" policy defined in [RFC5226]. + +8. Security Considerations + + This document does not raise any additional security issues beyond + those of BGP-4 and the Multiprotocol extensions for BGP-4. The same + security mechanisms are applicable. + + + +Le Faucheur & Rosen Standards Track [Page 8] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + Although not expected to be the typical case, the IPv6 address used + as the BGP Next Hop Address could be an IPv4-mapped IPv6 address (as + defined in [RFC4291]). Configuration of the security mechanisms + potentially deployed by the network operator (such as security checks + on next hop address) need to keep this case in mind also. + +9. Acknowledgments + + The authors would like to thank Yakov Rekhter, Pranav Mehta, and John + Scudder for their contributions to the approach defined in this + document. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol + Extensions for IPv6 Inter-Domain Routing", RFC 2545, + March 1999. + + [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in + BGP-4", RFC 3107, May 2001. + + [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. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + + [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement + with BGP-4", RFC 5492, February 2009. + +10.2. Informative References + + [DYN-CAP] Chen, E. and S. Sangli, "Dynamic Capability for BGP-4", + Work in Progress, November 2006. + + [L2VPN-SIG] Rosen, E., "Provisioning, Autodiscovery, and Signaling + in L2VPNs", Work in Progress, May 2006. + + + + + +Le Faucheur & Rosen Standards Track [Page 9] + +RFC 5549 v4 NLRI with v6 NH May 2009 + + + [MESH-FMWK] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh + Framework", Work in Progress, February 2009. + + [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. + + [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. + + [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. + + [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire + Problem Statement", RFC 4925, July 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +Authors' Addresses + + Francois Le Faucheur + Cisco Systems + Greenside, 400 Avenue de Roumanille + Sophia Antipolis 06410 + France + + EMail: flefauch@cisco.com + + + Eric Rosen + Cisco Systems + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + + EMail: erosen@cisco.com + + + + + + + +Le Faucheur & Rosen Standards Track [Page 10] + -- cgit v1.2.3