Summary

  • A 21 July individual Internet-Draft proposes a Specific Local Address Table, or SLAT. It gives each route-server client its own IPv4 view of other members' next hops while preserving the physical MAC and IPv6 identities.
  • The route server rewrites a legacy recipient's BGP NEXT_HOP using that recipient's SLAT column. The exchange's ARP/ND proxy must resolve the same alias to the right member. A route advertisement and a working packet path depend on one maintained address book.
  • RFC 7947 normally requires a route server to pass NEXT_HOP unchanged. The draft would make this translation an explicit exception. Bilateral peers outside the server need the published mapping or another translation arrangement.

Picture four members sharing a peering fabric. One can receive an IPv6 next hop for an IPv4 route; another can receive only IPv4 next hops. The route's destination prefix is unchanged, and the packet still has to reach the member that announced it. The difference is the address each recipient needs in its BGP update and the neighbor query it sends before forwarding. A single public IPv4 address for every peer keeps the old arrangement simple. The proposed arrangement lets the exchange use client-specific local IPv4 addresses instead.

RFC 8950 permits IPv4 reachability to be advertised with an IPv6 next hop when the parties negotiate the relevant capability. That helps capable members; it does not upgrade a legacy router by declaration. The route-server draft labels three kinds of client: Legacy, which needs an IPv4 next hop for IPv4 routes; Supporting, which can use either; and Unnumbered, which uses IPv6 next hops and has no IPv4 next-hop support. The route server is where their incompatible views meet.

The draft first asks the exchange to register each client's physical MAC address, IPv6 link-local address and IPv6 global unicast address. Those unique triples form a Local Address Table, or LAT. For every Legacy or Supporting member, the exchange and that member then choose a client-specific local IPv4 prefix. The exchange adds a column for that prefix to make the SLAT. The same physical neighbor can appear as 10.0.0.10 to one receiver and 192.0.2.10 to another in the draft's illustrative table. Those numbers are local aliases, not two routers.

The route server must do more than print the right column. When a member sends an IPv4 route with an IPv4 NEXT_HOP, the server rewrites it to that sender's IPv6 address from the SLAT. When the server advertises the route to a Legacy receiver, it rewrites NEXT_HOP to the sender's IPv4 alias in that receiver's column. It leaves the IPv6 next hop alone for an Unnumbered receiver and generally for a Supporting one. A next hop that has no assignment in the SLAT must not be propagated. The table therefore decides which reachability claims can be expressed and to whom.

The second half of the mechanism runs on the peering LAN. The exchange snoops ARP and Neighbor Discovery traffic, prevents clients from passing those neighbor messages directly to one another under the proposed model, and answers each client's query from its applicable SLAT view. If the server advertises one alias and the proxy answers with a different physical neighbor, the control plane has produced a route that points somewhere other than the intended peer. The missing fact for a deployment is a paired BGP, SLAT, ARP/ND and packet trace for each recipient class, including a change of member address.

That is a deliberate change in the route server's job. RFC 7947 section 2.2.1 says a route server must pass NEXT_HOP unmodified because it does not carry the traffic. The new draft explicitly sets that rule aside for translation. The server still does not forward the packet in the main SLAT design. It becomes the keeper of the address a client will use to find the forwarding peer. The exchange's proxy must keep its own answer synchronized with that advertised address. The draft recommends one source of truth for address management and periodic checks that different next-hop representations resolve to the same destination.

The migration plan is incremental. ARP/ND snooping can be introduced first. A new server that accepts IPv6 next hops for IPv4 routes can then run beside the traditional server. Initially, every member's SLAT column may mirror the existing production IPv4 allocation. As that public pool tightens, members can be renumbered into local prefixes, including private ranges. That sequence makes rollback possible, but it also creates a mixed period in which the old and new views must be checked side by side.

Bilateral sessions expose the limit of central translation. A member trading routes directly with another member bypasses the route server's rewrite. The draft says the exchange should publish a current SLAT so those members can translate the next hop themselves. It also suggests that a looking glass display the original IPv4 value, the actual IPv6 next hop and the egress alias for a chosen receiver. Without that triple, an operator staring at one BGP field could mistake a local alias for the peer's identity.

A separate proxy-machine design in the draft would actually forward between two domains; it shifts the failure surface again and should be evaluated on its own terms.

The proposal turns an address shortage into an operations contract. The exchange can stop spending public IPv4 addresses on every peering adjacency only if it maintains the recipient-specific map that makes each advertisement and each neighbor resolution agree. The route server may speak for the map; the packets will audit it.

Route Server Next Hop Translation draft, revision 02 · RFC 7947 · RFC 8950 · RFC 9161