Francois Le Faucheur Dan Tappan Gargi Nalawade Cisco Systems, Inc. IETF Internet Draft Expires: May, 2002 Document: draft-lefaucheur-mp-nh-00.txt June, 2003 BGP-4 Multiprotocol Next Hop Attribute Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 http://www.ietf.org/shadow.html. Abstract This document specifies a new BGP attribute, called the BGP-4 Multiprotocol Next Hop (MP_NEXT_HOP), which can optionally be used in conjunction with the MP_REACH_NLRI defined in [MP-BGP] (or the NLRI field defined in BGP-4) to advertise next hop information associated with a different Network Layer protocol to the one associated with the NLRI. This is desirable or required in a number of environments, but is not currently possible with [MP-BGP]. In addition, the MP_NEXT_HOP provides the generic capability to advertise information (set of TLVs) associated with the next hop. Finally, provision is made for a future potential extension to allow advertisement of multiple next hops. Le Faucheur et al. 1 BGP-4 Multiprotocol Next Hop Attribute June 2003 The extensions proposed in this document are backward compatible: a router which supports the extensions can interoperate with a router that doesn't support the extensions. 1. Introduction [MP-BGP] defines extensions to BGP-4 to enable it to carry routing information for multiple Layer protocols (e.g. IPv4-VPN, IPv6, IPv6- VPN). This is achieved by associating a particular Network Layer protocol with the next hop information and with the NLRI. In [MP- BGP], the Network Layer Protocol is simultaneously associated with both the next hop information and the NLRI. Thus [MP-BGP] does not allow advertisement of next hop information from a different Network Layer protocol to the one of the NLRI. However, there are situations where the next hop information to be advertised is indeed from a different Network Layer protocol to the one of the NLRI. In a number of such situations, the [MP-BGP] limitation has been circumvented by effectively embedding the meaningful next hop information inside the next hop information field of the same Network Layer protocol as the NLRI, and somehow flagging this fact through ad-hoc padding of the unused bits of the field. [RFC2547] is an example of this since it calls for advertisement of IPv4 next hop information along with IPv4-VPN NLRI, which is achieved by prepending a Null Route Distinguisher to the IPv4 Next Hop address. [BGP-TUN] is another example of this since it calls for advertisement of IPv4 next hop information along with IPv6 NLRI, which is achieved by encoding the IPv4 next hop address as an IPv4-mapped IPv6 address. [IPv6-VPN] is yet another example of this since it calls for advertisement of IPv4 or IPv6 next hop information along with IPv6-VPN NLRI, which is achieved by prepending a Null Route Distinguisher to the next hop address and, when the meaningful next hop is IPv4, by encoding it as an IPv4-mapped IPv6 address. In a number of other situations, the [MULTI-BGP] limitation would be very difficult to circumvent in similar ways because the Network Layer protocol of the meaningful next hop information is such that the next hop address to convey cannot be aligned to the format corresponding to the Network Layer protocol of the NLRI by simple padding. Support of IPv4 VPNs over an IPv6 backbone is an example of this since it calls for advertisement of IPv6 next hop information along with IPv4-VPN NLRI. As a general solution to this problem, this document specifies a new BGP attribute, called the BGP-4 Multiprotocol Next Hop (MP_NEXT_HOP), which can optionally be used in conjunction with the MP_REACH_NLRI defined in [MP-BGP] (or with the NLRI field defined in Le Faucheur et. al 2 BGP-4 Multiprotocol Next Hop Attribute June 2003 BGP-4) to advertise next hop information associated with a different Network Layer protocol to the one associated with the NLRI. In addition, the MP_NEXT_HOP attribute provides the generic capability to advertise information (set of TLVs) associated with the next hop. Finally, provision is made for a future potential extension to allow advertisement of multiple next hops. The extensions proposed in this document are backward compatible: a router which supports the extensions can interoperate with a router that doesn't support the extensions. 2. Multiprotocol Next Hop - MP_NEXT_HOP (Type Code TBD) This is an optional non-transitive attribute that can be used for the purpose of advertising the address of any Network Layer protocol that should be used as the next hop to the destinations advertised in the BGP NLRI field, or in the MP_NLRI field of the MP_REACH_NLRI attribute. The attribute is encoded as shown below: +---------------------------------------------------------+ | Reserved-1 (1 octet) | +---------------------------------------------------------+ | Length of Next Hop (2 octets) | +---------------------------------------------------------+ | Address Family Identifier (2 octets) | +---------------------------------------------------------+ | Subsequent Address Family Identifier (1 octet) | +---------------------------------------------------------+ | Length of Next Hop Network Address (1 octet) | +---------------------------------------------------------+ | Network Address of Next Hop (variable) | +---------------------------------------------------------+ | Set of Next Hop TLVs (variable length) | +---------------------------------------------------------+ Where: "Reserved-1" (1 octet): This field MUST be set to 1. It may be used in the future to indicate the number of "sets of next hop information" carried in the attribute in case there is such a need, where each set of next hop information comprises Length of Next Hop, Address Family Identifier, Subsequent Address Family Identifier, Length of Next Hop Network Address, Network Address of Next Hop and Set of Next Hop TLVs. Le Faucheur et. al 3 BGP-4 Multiprotocol Next Hop Attribute June 2003 "Length of Next Hop" (2 octets): This field indicates the total length in octets of all the following fields related to the Next Hop (ie AFI, SAFI, Length of Network Address, Network Address and Reserved- 2). Address Family Identifier (2 octets): This field carries the identity of the Network Layer protocol associated with the Next Hop Network Address that follows. Presently defined values for this field are specified in RFC1700 (see the Address Family Numbers section). Subsequent Address Family Identifier (1 octet): This field provides additional information about the type of the Next Hop Network Address that follows. Length of Next Hop Network Address (1 octet): This field indicates the length in octets of the Next Hop Network Address field which follows. Next Hop Network Address (variable length): This field contains the Network Address of the next router on the path to the destination system(s). Set of Next Hop TLVs (variable length): This field carries zero or more TLVs associated with the Next Hop whose address is contained in the previous field. Specification of these TLVs is beyond the scope of this document. 3. Operations When a BGP Speaker supporting the MP_NEXT_HOP attribute wants to advertise itself as the router that should be used as the next hop to the destinations advertised in the NLRI field, or in the MP_NLRI field of the MP_REACH_NLRI attribute, and wants to advertise one of its Network Layer addresses for a Network Layer protocol which is different to the Network Layer protocol of the NLRI destinations, the BGP speaker SHOULD include the MP_NEXT_HOP attribute and convey this (these) Network Layer address(es) inside. A BGP Speaker supporting the MP_NEXT_HOP attribute which receives a BGP advertisement containing a MP_NEXT_HOP attribute and which does not modify the next hop information, SHOULD propagate the received MP_NEXT_HOP attribute unchanged. A BGP Speaker supporting the MP_NEXT_HOP attribute which receives a BGP advertisement containing a MP_NEXT_HOP attribute and which modifies next hop information, SHOULD include an MP_NEXT_HOP Le Faucheur et. al 4 BGP-4 Multiprotocol Next Hop Attribute June 2003 attribute in the generated advertisement with modified next hop information. In particular, in the case where the BGP speaker modifies next hop information, it MUST NOT simply propagate the received MP_NEXT_HOP unchanged. When a BGP speaker supporting the MP_NEXT_HOP attribute receives a BGP advertisement with next hop information encoded both in the MP_REACH_NLRI and in the MP_NEXT_HOP, the BGP speaker SHOULD use the next hop information encoded in the MP_NEXT_HOP, unless configured to do otherwise. 4. Usage Examples 4.1. IPv4 VPNs over IPv6 Core The MP_NEXT_HOP attribute may be used for support of IPV4 VPNs over an IPv6 backbone. In this application, PE Routers would advertise IPv4-VPN NLRI information in the MP_REACH_NLRI along with an IPv6 next hop in the MP_NEXT_HOP attribute. 4.2. IPv4 over IPv6 Core The MP_NEXT_HOP attribute may be used for support of IPv4 reachability over an IPv6 core. In this application, BGP speakers would advertise IPv4 NLRI information in the MP_REACH_NLRI along with an IPv6 next hop in the MP_NEXT_HOP attribute. 4.3. IPv6 over IPv4 Core The MP_NEXT_HOP attribute may be used for support of IPv6 reachability over an IPv4 core. In this application, BGP speakers would advertise IPv6 NLRI information in the MP_REACH_NLRI along with an IPv4 next hop in the MP_NEXT_HOP attribute. 4.4. Migration of IPv4 VPN network to use of MP_NEXT_HOP Let us consider the case where an (intra-AS) IPv4 VPN network: - (i) initially operates purely as per [2547] and thus advertises next hop information in the MP_REACH_NLRI along with VPN- IPv4 NLRI, by pre-pending a Null Route Distinguisher to the IPv4 Next Hop address and - (ii) has elected to migrate to the use of MP_NEXT_HOP attribute for advertisement of the IPv4 next hop information. Let us consider an arbitrary interim situation where some PEs have been upgraded while others haven't, and, if used, some RRs have been upgraded while others haven't. Then some VPN-IPv4 NLRIs will be generated with next hop information encoded only in the MP_REACH_NLRI (the ones generated by PEs which have not been upgraded) while some VPN-IPv4 NLRIS will be advertised Le Faucheur et. al 5 BGP-4 Multiprotocol Next Hop Attribute June 2003 with next hop information encoded both in the MP_REACH_NLRI and in the MP_NEXT_HOP attribute. If the advertisement transits via a Route Reflector which hasn't been updated, the MP_NEXT_HOP attribute, if present, will be dropped since it is non-transitive. If the advertisement transits via a Route Reflector which has been updated, the MP_NEXT_HOP attribute, if present, will be propagated. Upgraded PEs receiving an advertisement will start making use of the next hop information in the MP_NEXT_HOP attribute when present, and will use next hop information in the MP_REACH_NLRI as before otherwise. Non-upgraded PEs will ignore the MP_NEXT_HOP attribute when present (since it is non-transitive) and will use next hop information in the MP_REACH_NLRI as before. When it can be established with certainty that all BGP speakers have been upgraded to support the MP_NEXT_HOP attribute, PEs can stop advertising next hop information in the MP_REACH_NLRI. This can be achieved by setting the Length of Next Hop Network Address to zero in the MP_REACH_NLRI. Thus, the MP_NEXT_HOP attribute allows this migration to take place without any flag day and with upgrade of BGP speakers independently and in any arbitrary order. 5. 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. 6. Acknowledgments We thank Jim Guichard, Robert Raszuk and Pedro Marques for their comments and suggestions on this document. References [MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft- ietf-idr-rfc2858bis-02.txt, work in progress. [RFC2547] Rosen et al., BGP/MPLS VPNs, draft-ietf-ppvpn-rfc2547bis- 03.txt, work in progress. [BGP-TUNN] Ooms et al., Connecting IPv6 Islands across IPv4 Clouds with BGP, draft-ooms-v6ops-bgp-tunnel-00.txt, work in progress. Le Faucheur et. al 6 BGP-4 Multiprotocol Next Hop Attribute June 2003 [IPv6-VPN] De Clercq et al., BGP-MPLS VPN extension for IPv6 VPN, draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt, work in progress. [RFC1700] Postel et al., Assigned Numbers, STD2, RFC1700 (see also http://www.iana.org/iana/assignments.html) Authors' Address: Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Email: flefauch@cisco.com Dan Tappan Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, 01719, MA USA Email: tappan@cisco.com Gargi Nalawade Cisco Systems, Inc. 510 McCarthy Blvd Milpitas, 95035, CA USA Email: gargi@cisco.com Le Faucheur et. al 7