Global Routing Operations M. Matejka Internet-Draft CZ.NIC Updates: 6890, 7947 (if approved) 24 July 2025 Intended status: Standards Track Expires: 25 January 2026 Route Server Next Hop Translation draft-marenamat-grow-route-server-nh-translation-latest Abstract Internet Exchange BGP Route Server (RFC 7947) is an interconnection broker for three or more External BGP speakers on a shared LAN. To support IPv6 Next Hops for IPv4 NLRIs (RFC 8950) on an Internet Exchange, traditionally, all BGP speakers connected to the Route Server must support it. This document defines how to allow coexistence of speakers supporting RFC 8950 with others not supporting it. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-marenamat-grow-route-server- nh-translation/. Discussion of this document takes place on the Global Routing Operations Working Group mailing list (mailto:grow@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/grow/. Subscribe at https://www.ietf.org/mailman/listinfo/grow/. Source for this draft and an issue tracker can be found at https://github.com/marenamat/ietf-draft-marenamat-grow-route-server- nh-translation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 25 January 2026. 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 2. Conventions and Definitions 3. Providing reachability between Legacy and Unnumbered speakers 3.1. Speaker configuration 3.2. IPv4 assignment 3.3. ARP and ND Proxy configuration 3.4. NEXT_HOP Attribute management on Route Servers 4. IXP Interconnection Space 5. Operational and Management Considerations 6. Security Considerations 7. IANA Considerations 8. References 8.1. Normative References 8.2. Informative References Acknowledgments Author's Address 1. Introduction Traditionally, Internet Exchange BGP Route Servers [RFC7947] serve IPv6 NLRIs with IPv6 next hops, and IPv4 NLRIs with IPv4 next hops. Recently, there have been networks running IPv4 only on end hosts and forwarding the IPv4 traffic over IPv6-only intermediate hosts [I-D.chroboczek-intarea-v4-via-v6]. In the Internet Exchange environment, however, these networks need an IPv4 address assigned to allow routing from and to legacy-only networks where IPv6 nexthops for IPv4 NLRIs [RFC8950] are not supported. This document specifies how to extend the ARP Proxy [RFC9161] functionality to allow deployment of IPv6 next hops for IPv4 NLRIs [RFC8950] in networks where some BGP speakers do not support that, without the need to assign public IPv4 addresses to all BGP speakers. This document does not cover IPv6 NLRIs with IPv4 next hops. 2. Conventions and Definitions The terminology of [RFC9161], [RFC7947] and [RFC4271] applies. Client: A BGP speaker which is connected to the IXP's Route Server. The client may be a Legacy speaker, Supporting speaker or Unnumbered speaker. Legacy speaker: Any BGP speaker with no support for IPv4 NLRIs with IPv6 next hops in context of an IXP. Supporting speaker: Any BGP speaker with support for IPv4 NLRIs with IPv6 next hops, while still capable of producing and receiving IPv4 next hops. Unnumbered speaker: Any BGP speaker with support for IPv4 NLRIs with IPv6 next hops, with no support for IPv4 next hops. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Providing reachability between Legacy and Unnumbered speakers All IPv4 routes announced to and from Legacy speakers must have IPv4 next hops, while all IPv4 routes announced to and from Unnumbered speakers must have IPv6 next hops. To facilitate reachability between these speakers, we need to translate between IPv4 and IPv6 next hops in BGP, IPv6 ND and ARP. 3.1. Speaker configuration All speakers SHOULD have a fixed MAC address set and registered with the IXP. All speakers MUST have their IPv6 LLA and IPv6 GUA and assigned by the IXP. They do not have to set these addresses up on the respective interfaces as long as their BGP sessions are able to run. These assignments MUST be unique, such that for any two triples (MAC, IPv6 LLA, IPv6 GUA) and (MAC', LLA', GUA') it holds that MAC != MAC', LLA != LLA' and GUA != GUA'. This set of triplets is called Local Address Table (LAT). 3.2. IPv4 assignment Contrary to IPv6 where both the LLA and GUA space allow for sharing the same prefix, in IPv4 this isn't always possible as the IXP may run out of global IPv4 addresses for the number of speakers present in the local network. Therefore, the IXP, in cooperation with every Supporting Speaker and Legacy Speaker, MUST decide on an IPv4 prefix (or a set of IPv4 prefixes) short enough to accomodate the number of speakers in the IXP network. This prefix MAY be different for different clients. This prefix is called Speaker-specific local prefix. For every Supporting and Legacy Speaker, the IXP then creates a Specific Local Address Table (SLAT) by assigning a unique IPv4 address from the Speaker-specific local prefix for every triplet in the LAT. The Unnumbered Speakers need no such allocation. Legacy speakers SHOULD set up their NEXT_HOP Attribute handling so that they never propagate the SLAT IPv4 addresses. 3.3. ARP and ND Proxy configuration For each speaker, the IXP MUST set up ARP and ND snooping. The IXP MUST NOT forward any ARP nor ND traffic between speakers. The IXP MUST answer all ARP and ND requests from the speakers themselves, using the appropriate SLAT for that speaker. 3.4. NEXT_HOP Attribute management on Route Servers When the Route Server receives a route where the NEXT_HOP Attribute contains When a route with IPv4 NLRI and IPv4 NEXT_HOP Attribute is received from any speaker, the Route Server MUST rewrite the NEXT_HOP according to the sender's SLAT to the IPv6 GUA or LLA. When the Route Server sends a route to a Legacy speaker, it MUST rewrite the NEXT_HOP according to the receiver's SLAT to the assigned IPv4 address. When the Route Server sends a route to a Supporting speaker, it SHOULD NOT rewrite the NEXT_HOP. When the Route server sends a route to an Unnumbered speaker, it MUST NOT rewrite the NEXT_HOP. The Route Server MUST NOT propagate any route where the NEXT_HOP Attribute holds an address not assigned to any speaker by the appropriate SLAT. Section 2.2.1 of [RFC7947] does not apply. 4. IXP Interconnection Space This document requests an allocation of an IPv4 IXP Interconnection Space from the experimental range. By previous efforts [I-D.schoen-intarea-unicast-240], it has already been shown that these addresses are technically feasible to be used in limited environments. Here, the use is limited for local next hop resolution and possibly BGP session addressing. It is RECOMMENDED that the prefix used is the IXP Interconnection Space for every speaker supporting this allocation, to reduce the size of the SLATs. BGP speakers MUST NOT propagate any routes with IPv4 NLRI from the IXP Interconnection Space. Section 2.2.2 of [RFC6890] is updated by adding the following record: +======================+===========================+ | Attribute | Value | +======================+===========================+ | Address Block | TBD | +----------------------+---------------------------+ | Name | IXP Interconnection Space | +----------------------+---------------------------+ | RFC | TBD | +----------------------+---------------------------+ | Allocation Date | TBD | +----------------------+---------------------------+ | Termination Date | N/A | +----------------------+---------------------------+ | Source | False | +----------------------+---------------------------+ | Destination | False | +----------------------+---------------------------+ | Forwardable | False | +----------------------+---------------------------+ | Global | False | +----------------------+---------------------------+ | Reserved-by-Protocol | False | +----------------------+---------------------------+ Table 1: Shared Address Space The allocation is probably not strictly needed, as most of the Legacy Speakers will still have some of the private IPv4 addresses [RFC1918] available to use for the SLAT. Yet, these available ranges may be different between networks. To reduce complexity, this allocation will help IXPs to have a shared SLAT for most of the Legacy Speakers. Some large networks have also claimed recently Section 6.1 of [I-D.schoen-intarea-unicast-240] that they are already using the experimental range for their internal purposes because they are already out of the private IPv4 addresses. These networks would have probably needed to negotiate a custom SLAT block with the IXP anyway, with or without the allocation. 5. Operational and Management Considerations This setup should be possible to be rolled out in steps. First, the ARP and ND snooping is not dependent on anything else in this document. Then, setting up a new route server supporting IPv6 next hops for IPv4 NLRI, and allowing Supporting clients to use that server while keeping also the traditional one. The SLATs may be started as uniform for every client reflecting the current address assignment, allowing the Legacy Speakers into the new route server, and gradual renumbering may occur later, client-by- client, when the original IPv4 range starts being exhausted. The clients have to properly assess which address range is suitable for them to use for IXP interconnection. If using the IXP Interconnection Space, they also have to check whether these addresses are considered eligible as next hops by their routing equipment. The IXPs may have to rethink how they are displaying the route next hops in their human-facing interfaces (looking glasses). It may be handy to display the original next hop (if it was IPv4), the actual IPv6 next hop, and also the result of the egress translation for a selected client. 6. Security Considerations Implementing the ARP and ND snooping should improve the overall security of IXPs by blocking possible ARP or ND spoofing, both inadvertent and intended. [DE-CIX-EVPN] Mistakes in the MAC address registration and manual management of IP address assignment may lead to inadvertent invalid route announcement. It's recommended to run automated address management with a single source of truth. Mistakes in the next hop address translation may lead to inadvertent invalid route announcement. It's recommended to run periodic automated checks whether the next hops actually resolve to the same address by the appropriate SLAT. Mistakes in route announcements are contained to the route not being propagated further. Mistakes in the client setup may lead to spreading unreachable routes across their autonomous systems, causing inefficient routing. It is recommended to log rogue GARP or IPv6 DAD communication to detect possible misconfigurations. 7. IANA Considerations IANA is asked to record the allocation of an IPv4 /8 from the 240/4 range for use as IXP Interconnection Space as requested in Section 4. The IXP Interconnection Space address range is: x.0.0.0/8. _[Note to RFC Editor: this address range to be added before publication]_ 8. References 8.1. Normative References [I-D.chroboczek-intarea-v4-via-v6] Chroboczek, J., Kumari, W., and T. Høiland-Jørgensen, "IPv4 routes with an IPv6 next hop", Work in Progress, Internet-Draft, draft-chroboczek-intarea-v4-via-v6-03, 20 January 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, . [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange BGP Route Server", RFC 7947, DOI 10.17487/RFC7947, September 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC9161] Rabadan, J., Ed., Sathappan, S., Nagaraj, K., Hankins, G., and T. King, "Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks", RFC 9161, DOI 10.17487/RFC9161, January 2022, . 8.2. Informative References [DE-CIX-EVPN] King, T., "Peering LAN 2.0 — Introduction of EVPN at DE- CIX", 23 August 2023, . [I-D.schoen-intarea-unicast-240] Schoen, S. D., Gilmore, J. I., and D. M. Täht, "Unicast Use of the Formerly Reserved 240/4", Work in Progress, Internet-Draft, draft-schoen-intarea-unicast-240-09, 23 June 2025, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . Acknowledgments TODO Author's Address Maria Matejka CZ.NIC Milesovska 1136/5 13000 Praha Czechia Email: maria.matejka@nic.cz, mq@jmq.cz