]> CZ.NIC

Milesovska 1136/5 Praha 13000 Czechia maria.matejka@nic.cz mq@jmq.cz

DE-CIX

Lindleystraße 12 Frankfurt am Main 60314 Germany daniel.wagner@de-cix.net

Operations and Management Global Routing Operations coexistence of IPv4 and IPv6 ARP proxying address translation With the advent of RFC8950, Internet Exchang Points (IXPs) are enabled to rely solely on IPv6 addresses for adressing in their peering LANs. However, routers not supporting RFC8950 are a technical roadblock. It is easier to extend the capabilities of the IXP Route Server (RS) instead of those of every unsupporting router. Thus, this document introduces the concept of Specific Local Address Tables (SLATs). SLATs translate BGP next hops between all IXP members, regardless of their RFC8950 support, paving the way for IPv6-only IXPs. This document also introduces another, more transparent variant of BGP next hop translation applicable in IXPs which do not employ ARP and ND proxying. This document updates RFC 6890 by registering a special-purpose address, and RFC 7947 by specifying an allowed route modification at the route server. About This Document Status information for this document may be found at . Discussion of this document takes place on the Global Routing Operations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Traditionally, Internet Exchange Point (IXP) Border Gateway Protocol (BGP) Route Servers (RS) serve IPv6 Network Layer Reachability Information (NRLI) with IPv6 next hops, and IPv4 NLRI with IPv4 next hops to the BGP speakers in their peering LAN. On the one hand, this dual-stack operation allows both IPv4 and IPv6 supporting BGP speakers to exchange NLRI with another and the route server. On the other hand, this requires them to have next hop addresses of the same Address Familiy (AF) as well. With the depletion of available IPv4 address space, solutions have emerged to support forwarding of IPv4 traffic over IPv6-only intermediate hosts . In the IXP environment, however, these networks would still require an IPv4 address to be assigned to allow for routing from and to legacy-only networks where IPv6 next hops for IPv4 NLRIs are not supported. This document specifies how to extend the Address Resolution Protocol (ARP) Proxy and Neighbor Discovery (ND) Proxy functionality to allow deployment of IPv6 next hops for IPv4 NLRIs , without the need to assign public IPv4 addresses to any of the BGP speakers at IXPs. This document does not cover IPv6 NLRIs with IPv4 next hops.

Conventions and Definitions The terminology of , and 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 Client with no support for IPv4 NLRIs with IPv6 next hops in context of an IXP.

Supporting speaker:

Any Client with support for IPv4 NLRIs with IPv6 next hops, while still capable of producing and receiving IPv4 next hops.

Unnumbered speaker:

Any Client with support for IPv4 NLRIs with IPv6 next hops, and with no support for IPv4 next hops.

Production IPv4 prefix:

The IPv4 prefix used by the IXP operator to assign IPv4 addresses to the Clients.

Production IPv6 prefix:

The IPv6 prefix used by the IXP operator to assign IPv6 addresses to the Clients.

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 when, and only when, they appear in all capitals, as shown here.

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 Clients, we need to translate between IPv4 and IPv6 next hops in BGP, IPv6 Neighbor Discovery (ND) and ARP.

Client Address Assignment

MAC Address Assignment All Clients SHOULD have a fixed MAC address set and registered with the IXP.

IPv6 Address Assignment All Clients MUST have their IPv6 link-local address (LLA) and IPv6 globally unicast address (GUA) assigned by the IXP. They MAY set these addresses up on the respective interfaces while their already established BGP sessions are still able to run. These assignments MUST be unique, such that for any two triples (MAC, LLA, GUA) and (MAC', LLA', GUA') it holds that MAC != MAC', LLA != LLA' and GUA != GUA'. IPv6 addresses from the Production IPv6 prefix of the IXP MAY be used for GUA allocation if there are unused addresses available and the above requirement holds. The resulting set of triples is stored in a Local Address Table (LAT). This table is maintained by the IXP and used to translate next hops to MAC addresses for Unnumbered speakers. Local Address Table (LAT)

MAC Address	Link Local Address	Global Unicast Address
00-00-5E-00-53-10	FE80::10	2001:db8::10
00-00-5E-00-53-20	FE80::20	2001:db8::20
...	...	...

IPv4 Address Assignment Due to IPv4 scarcity, IXP are typically assigned much less spacious Production IPv4 prefixes than Production IPv6 prefixes. 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 accommodate the number of Clients in the IXP network. This prefix MAY be different for different Clients. This prefix is called Client-specific local prefix (CSLP). For every Supporting and Legacy Speaker, the IXP then adds another column for every CSLP to the LAT, completing it to a Specific Local Address Table (SLAT). These columns then hold a unique IPv4 address assigned from the respective CSLP for every triple in the LAT. These entries are used to translate next hops to MAC addresses for Legacy speakers. Specific Local Address Table (SLAT)

MAC Address	Link Local Address	Global Unicast Address	CSLP 1	CLSP 2	...
MAC Address	Link Local Address	Global Unicast Address	CSLP 1	CLSP 2	...
00-00-5E-00-53-10	FE80::10	2001:db8::10	10.0.0.10	192.0.2.10	...
00-00-5E-00-53-20	FE80::20	2001:db8::20	10.0.0.20	192.0.2.20	...
...	...	...	...	...	...

The Unnumbered Speakers need no such prefix negotiation and therefore have no risk of adding another CSLP to bloat the SLAT. Legacy Speakers SHOULD set up their NEXT_HOP attribute handling so that they never propagate the IPv4 addresses from the SLAT outside any communication with the RS.

ARP and ND Proxy Configuration For each Client, the IXP MUST set up ARP and ND snooping. The IXP MUST NOT forward neither ARP nor ND traffic between Clients. The IXP MUST answer all ARP and ND requests from the Clients themselves using the respective SLAT column for that Client.

NEXT_HOP Attribute Management at Route Servers When a route with IPv4 NLRI and IPv4 NEXT_HOP Attribute is announced from any Client, the RS MUST rewrite the NEXT_HOP according to the Client's IPv6 GUA or LLA entry in the SLAT. When the RS sends a route to a Legacy speaker, it MUST rewrite the NEXT_HOP according to the IPv4 address assigned for the sender in the receiver's CSLP column of the SLAT. 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 Clients in the SLAT. does not apply.

IXP Interconnection Space This document requests an allocation of an IPv4 IXP Interconnection Space from the experimental range. By previous efforts , 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 this prefix is used as the CLSP for every Client that does not use this prefix for other purposes. Having the same prefix as the IXP Interconnection Space for many Clients helps to reduce the size of the SLAT. Clients MUST NOT propagate any routes with IPv4 NLRI from the IXP Interconnection Space. is updated by adding the following record: Shared Address Space

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

The allocation is probably not strictly needed, as most of the Legacy Speakers will still have some of the private IPv4 addresses 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 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 CLSP with the IXP anyway, with or without the allocation.

Operational and Management Considerations

Step-by-Step Rollout 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 speakers to use that server while keeping also the traditional one. The SLAT may be started as uniform for every Client reflecting the current address assignment from the Production IPv4 prefix. This allows the Legacy Speakers into the new route server, and gradual renumbering may occur later, Client-by-Client, when the Production IPv4 prefix 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.

Bilateral Peerings There might be reasons why any two Clients do not want to use the IXP's RS to exchange their routing information. Hence, the information from the SLAT should be made publicly available and kept up to date. Clients can then perform the next hop translation themselves. An alternative is to introduce a new BGP community that tells the RS to exclude the routing information exchanged via such bilateral peerings from the Looking Glasses (LG). This can be useful if privacy is of a concern and no self-translation can be performed.

Address Translation Transparency 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.

Transparent Next Hop Translation Some IXPs have not deployed ARP and ND snooping, and therefore they can't directly translate between IPv4 and IPv6 next hops. Instead, an alternative approach is possible, with an actual proxy machine inbetween. The IXP maintains two separate routing and forwarding domains, one serving Legacy speakers and Supporting speakers, and another one serving Unnumbered and Supporting speakers. All nodes in each domain can reach each other easily. To enable communication between these two domains, the IXP deploys an additional proxy node with two interfaces, each facing one of the domains, and connected to the route server by two separate BGP sessions, with Add-Path enabled. This proxy node acts as an explicit translator of the next hops between these two domains. The proxy node then scrubs all nexthops to its own address, and actually performs forwarding between the two domains. The proxy node may also assign different virtual next hop addresses to the Legacy and Unnumbered speakers and handle the ARP and ND requests accordingly. It may be possible to reply to the ARP and ND requests in a way that the traffic is sent directly to its final destination. The operators should carefully evalute all risks regarding this variant of ARP and ND spoofing. The full extent of this kind of configuration is outside the scope of this document.

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 . 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.

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 . The IXP Interconnection Space address range is: x.0.0.0/8. [Note to RFC Editor: this address range to be added before publication]

References Normative References This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as IXPs, to facilitate simplified interconnection among multiple Internet routers. Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The 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 the advertising of 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 to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC 5549. This document describes the Ethernet Virtual Private Network (EVPN) Proxy ARP/ND function augmented by the capability of the ARP/ND Extended Community. From that perspective, this document updates the EVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of Internet Exchange Points, Data Centers, and other networks deal with IPv4 and IPv6 address resolution issues associated with large Broadcast Domains by reducing and even suppressing the flooding produced by address resolution in the EVPN network. IRIF, University of Paris Google, LLC Red Hat This document proposes "v4-via-v6" routing, a technique that uses IPv6 next-hop addresses for routing IPv4 packets, thus making it possible to route IPv4 packets across a network where routers have not been assigned IPv4 addresses. The document both describes the technique, as well as discussing its operational implications. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix. IPv4 Unicast Extensions Project IPv4 Unicast Extensions Project IPv4 Unicast Extensions Project This document redesignates 240/4, the region of the IPv4 address space historically known as "Experimental," "Future Use," or "Class E" address space, so that this space is no longer reserved. It asks implementers to make addresses in this range fully usable for unicast use on the Internet. DE-CIX

Acknowledgments The authors would like to thank André Grüneberg and Marian Rychtecký for valuable feedback and for designing and testing the alternative transparent next hop translation.