Interdomain Routing R. White Internet-Draft Akamai Technologies Updates: 2545 (if approved) J. Tantsura Intended status: Standards Track Nvidia Expires: 1 December 2025 D. Abraitis Hostinger 30 May 2025 Link-Local Next Hop Capability for BGP draft-ietf-idr-linklocal-capability-01 Abstract BGP [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. To support IPv6 reachability, BGP relies heavily on its Multiprotocol Extensions as defined in [RFC2545], which is crucial for enabling BGP-4 to advertise IPv6 routes alongside IPv4. This extension not only permits the exchange of IPv6 routing information but also establishes the structure for IPv6 next hop handling within BGP updates. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. [RFC2545] introduced the ability to advertise a global IPv6 address as the BGP next hop. When the advertising system is directly attached, it may include both a global and an IPv6 link-local address or only a global address, when next hop length is set to 16 bytes. This document updates the specification to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 link-local address is available. This clarification applies specifically to IPv6 link-local addresses and does not pertain to IPv4 link-local addresses as defined in [RFC3927]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. White, et al. Expires 1 December 2025 [Page 1] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on 1 December 2025. Copyright Notice Copyright (c) 2025 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Link-Local Next Hop Capability . . . . . . . . . . . . . . . 4 3. Changes to BGP Next Hop Attribute to Support Link-Local on Point-to-Point . . . . . . . . . . . . . . . . . . . . . 5 4. Receiver Processing of IPv6 Link-Local Forwarding Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Inconsistency Reports . . . . . . . . . . . . . . . 9 Appendix B. Implementation Report . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 White, et al. Expires 1 December 2025 [Page 2] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 1. Introduction BGP [RFC4271], was originally designed to provide reachability between domains and between the edges of a domain. To support IPv6 reachability, BGP relies heavily on its Multiprotocol Extensions as defined in [RFC2545], which is crucial for enabling BGP-4 to advertise IPv6 routes alongside IPv4. This extension not only permits the exchange of IPv6 routing information but also establishes the structure for IPv6 next hop handling within BGP updates. As such, BGP assumes the next hop towards any reachable destination may not reside on the advertising speaker, but rather may either be through a router connected to the same subnet as the speaker, or through a router only reachable by traversing multiple hops through the network. [RFC2545] introduced the ability to advertise a global IPv6 address as the BGP next hop. When the advertising system is directly attached, it may include both a global and an IPv6 link-local address or only a global address, when next hop length is set to 16 bytes. This document updates the specification to clarify the encoding of the BGP next hop when the advertising system is directly attached and only an IPv6 link-local address is available. This clarification applies specifically to IPv6 link-local addresses and does not pertain to IPv4 link-local addresses as defined in [RFC3927]. BGP speakers are now often deployed on point-to-point links in networks where multihop reachability of any kind is not assumed or desired (all next hops are assumed to be the speaker reachable through a directly connected point-to-point link). This is common, for instance, in data center fabrics [RFC7938]. In these situations, a global IPv6 address is not required for the advertisement of reachability information; in fact, providing global IPv6 addresses in these kinds of networks can be detrimental to Zero Touch Provisioning (ZTP). Such BGP deployment models require BGP to run on each link, and any ease or simplification of BGP configuration can result in simplifying orchestration and configuration management. This proposal is a step in that direction. With this new capability, the need for a global unicast address assigned to the interfaces is eliminated. White, et al. Expires 1 December 2025 [Page 3] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 Since IPv6 link-local addresses are not required to be globally unique, implementations must ensure that they are strictly associated with a specific interface. 2. Link-Local Next Hop Capability The Link-Local Next Hop capability is a new BGP capability. A BGP speaker that supports capabilities advertisement [RFC5492] in an OPEN message should send this capability only when: 1. It is capable of sending IPv6 link-local address as the only next hop address for a route. 2. The implementation is capable of processing IPv6 link-local address next hops with the help of peer interface binding to come up with interface-specific next hops for its routing table. The presence of this capability does not affect the support of global IPv6 only (16 bytes next hop) and global IPv6 combined with IPv6 link-local (32 bytes next hop), which should continue to be supported as before. The Capability Code for this capability is 77. The Capability Length field of this capability is 0. The advantage of using this capability is that in contrast to the current situation. it can let two conforming implementations interoperate correctly without additional configuration. Existing implementations utilizing BGP next hop over an IPv6 link-local address are inconsistent, and can't readily change their behavior without negative side effects. A BGP speaker that is willing to use (send and receive) only IPv6 link-local addresses as next hops with a peer SHOULD advertise the Link-Local Next Hop Capability to the peer using BGP Capabilities advertisement. The peers have the flexibility to include both IPv6 link-local and global next hops or IPv6 link-local only next hop. In this document, all procedures described are applicable only when the capability described herein has been successfully negotiated between BGP speakers. When the capability has not been negotiated, the procedures in this document do not apply, and the resulting behavior is considered undefined and out of scope for this specification. For example, when the capability is negotiated, a BGP speaker MUST advertise only an IPv6 link-local nexthop when using such nexthops, and the next hop length field MUST be set to 16 bytes. White, et al. Expires 1 December 2025 [Page 4] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 Implementers are encouraged to consult the Appendix for currently known interoperability concerns or incompatibilities when this capability is absent or inconsistently implemented. 3. Changes to BGP Next Hop Attribute to Support Link-Local on Point-to- Point [RFC2545], section 2, notes IPv6 link-local addresses are not generally suitable for use in the Next Hop field of the MP_REACH_NLRI. In order to support the many uses of IPv6 link-local addresses, however, [RFC2545] constructs the Next Hop field in IPv6 route advertisements by setting the length of the field to 32, and including both an IPv6 link-local and global address in the resulting enlarged field. In this way, the receiving BGP speaker can use the global IPv6 address to build local forwarding information, and the IPv6 link-local address for ICMPv6 redirects, etc. [RFC2545] does not, however, provide an explanation for situations where there is only an IPv6 link-local address in the Next Hop field of the MP_REACH_NLRI. The result is each implementation that supports IPv6 link-local peering along with forwarding to an IPv6 link-local address has implemented the construction of the Next Hop field in the MP_REACH_NLRI when there is only an IPv6 link-local address available in slightly different ways. If an implementation intends to send a single IPv6 link-local forwarding address in the Next Hop field of the MP_REACH_NLRI, it MUST set the length of the Next Hop field to 16 and include only the IPv6 link-local address in the Next Hop field. If an implementation intends to send both an IPv6 link-local and global forwarding address in the Next Hop field of the MP_REACH_NLRI, it MUST set the length of the Next Hop field to 32 and include both the IPv6 link-local and global forwarding addresses in the Next Hop field. If both the IPv6 link-local and global forwarding addresses are carried in the Next Hop Field, the speaker SHOULD provide a local configuration option to determine which address should be preferred for forwarding. For iBGP peers configured as a route-reflector [RFC4456], when route- reflector isn't configured to be in the data-path, the proposed IPv6 link-local (only) next hops MUST NOT be reflected. A single (only) IPv6 link-local next hop address needs to always be reset as next hop self when passed to another link. White, et al. Expires 1 December 2025 [Page 5] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 4. Receiver Processing of IPv6 Link-Local Forwarding Addresses On receiving an MP_REACH_NLRI with a Next Hop length of 16, implementations SHOULD form the forwarding information using the IPv6 next hop contained in the Next Hop field, regardless of whether it is a link-local or globally reachable IPv6 address. 5. Error handling A BGP speaker receiving an MP_REACH_NLRI with the length of the Next Hop Field set to 32, where the update contains anything other than an IPv6 link-local address and a global address, SHOULD consider this a malformed UPDATE message, and proceed as described in the following paragraphs. In order to support backward compatibility with existing implementations, an implementation MAY ignore a second IPv6 link- local address or 0::0/0 included with an IPv6 link-local address when the length of the Next Hop Field is set to 32; in this case, the implementation SHOULD report the existence of this additional information so the operator can correct the sending BGP implementation. And if a BGP speaker receiving an MP_REACH_NLRI with the length of the Next Hop Field set to 16, where the update contains an IPv6 link- local address, SHOULD consider this a malformed UPDATE message, and handle the malformed UPDATE message using the approach of "treat-as- withdraw", as described in section 7.3 of [RFC7606]. If the Next Hop field is malformed, the implementation MUST handle the malformed UPDATE message using the approach of "treat-as- withdraw", as described in section 7.3 of [RFC7606]. If the Next Hop field is properly formed, but the IPv6 link-local next hop is not reachable (as determined by an examination of the IPv6 neighbor table), the implementation MAY handle the malformed UPDATE message using the approach of "treat-as-withdraw", as described in section 7.3 of [RFC7606] (see the note above on checking the local neighbor table for the correctness of the next hop). 6. Acknowledgements The authors would like to thank Vipin Kumar, Dinesh Dutt, Donald Sharp, Jeff Haas, and Brian Carpenter for their contributions to this draft. This document builds on prior work exploring the use of IPv6 link- local addresses as BGP next hops. Notably, [I-D.kumar-idr-link-local-nexthop] and [I-D.kato-bgp-ipv6-link-local] identified operational limitations and proposed mechanisms to enable White, et al. Expires 1 December 2025 [Page 6] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 link-local next hop propagation in BGP. These drafts laid the groundwork for defining a standardized capability-based approach, as presented in this document, to ensure interoperable signaling and safe deployment of link-local next hops across BGP sessions. 7. IANA Considerations IANA has assigned capability number 77 for the Link-Local Next Hop Capability described in this document. This registration is in the BGP Capability Codes registry. +=======+================================+ | Value | Description | +=======+================================+ | 77 | Link-Local Next Hop Capability | +-------+--------------------------------+ Table 1: Link-Local Next Hop Capability 8. Security Considerations The mechanism described in this draft can be used as a component of ZTP for building BGP peering across point-to-point links. This method, then, can be used by an attacker to form a peering session with a BGP speaker, ultimately advertising incorrect routing information into a routing domain in order to misdirect traffic or cause a denial of service. By using IPv6 link-local addresses, the attacker would be able to forego the use of a valid IPv6 address within the domain, making such an attack easier. Operators SHOULD carefully consider security when deploying link- local addresses for BGP peering. Operators SHOULD filter traffic on links where BGP peering is not intended to occur to prevent speakers from accepting BGP session requests, as well as other mechanisms described in [RFC7454]. Operators MAY also use some form of cryptographic validation on links within the network to prevent unauthorized devices from forming BGP peering sessions. Authentication, such as the TCP authentication [RFC5925], may provide some relief if it is present and correctly configured. However, the distribution and management of keys in an environment where global addresses on BGP speakers are not present may be challenging. Operators also MAY instruct a BGP peer which has received an UPDATE with an unreachable NEXT_HOP to disable the peering session over which the invalid NEXT_HOP was received pending manual intervention. White, et al. Expires 1 December 2025 [Page 7] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 9. References 9.1. Normative References [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, . [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, DOI 10.17487/RFC3927, May 2005, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, . [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, . [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, . White, et al. Expires 1 December 2025 [Page 8] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, . [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8950] Litkowski, S., Agrawal, S., Ananthamurthy, K., and K. Patel, "Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop", RFC 8950, DOI 10.17487/RFC8950, November 2020, . 9.2. Informative References [I-D.kato-bgp-ipv6-link-local] 明洋, K. and B. Manning, "BGP4+ Peering Using IPv6 Link- local Address", Work in Progress, Internet-Draft, draft- kato-bgp-ipv6-link-local-00, 24 September 2001, . [I-D.kumar-idr-link-local-nexthop] Kumar, V., Mohapatra, P., Dutt, D., and M. Valentine, "BGP Link-Local Next Hop Capability", Work in Progress, Internet-Draft, draft-kumar-idr-link-local-nexthop-02, 13 November 2014, . Appendix A. Inconsistency Reports According to [RFC7942], "This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature". FRRouting (https://github.com/frrouting/frr/ commit/606fdbb1fab98bac305dca3d19eb38b140b7c3e6) IPv6 next-hop handling when GUA/LL is set to ::/LL. White, et al. Expires 1 December 2025 [Page 9] Internet-Draft Link-Local Next Hop Capability for BGP May 2025 Bird (https://gitlab.nic.cz/labs/ bird/-/commit/17de3a023f7bde293892b41bfafe5740c8553fc8) handling LL/ LL case. Appendix B. Implementation Report According to [RFC7942], "This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature". FRRouting (https://github.com/FRRouting/frr/pull/17871) implementation. Authors' Addresses Russ White Akamai Technologies Email: russ@riw.us Jeff Tantsura Nvidia Email: jefftant.ietf@gmail.com Donatas Abraitis Hostinger Email: donatas.abraitis@gmail.com White, et al. Expires 1 December 2025 [Page 10]