It had been awhile since I attended an ARIN meeting, but I recently had the chance to catch some of ARIN 56 via remote participation. While there was some IPv6 discussion, it seemed to me the bulk of the discussions were still surrounding management of the IPv4 space.
The policy that caught my attention was Draft Policy 2024-5. The policy seeks to clarify rules around "micro-allocations", specifically talking about Internet eXchange Points. The example given in the discussion was an IXP has a /24 allocated to them, but they have outgrown it and need more space. They talked of mechanisms for obtaining a new /23, renumbering the exchange into it, then returning the old /24. I found this odd since I think that any time you are faced with having to renumber IPv4 space is a prime opportunity to migrate that network to IPv6. Let's take a look at how that would work in this scenario:
The current version of Border Gateway Protocol (version 4) was released in 1994. Even at that time IPv4 was still the only game in town, so that's all it supported. In order to support IPv6, Multiprotocol Extensions1 were created. From what I've seen, most BGP peers will set up two sessions, one for IPv4 and one for IPv6. However, these extensions allow you to send route information for any supported protocol over any session type. That is, you can send IPv6 information over an IPv4 session or, more importantly, IPv4 information over an IPv6 session. This allows us to send all our information over the single modern connection.
Now, even though we have all the data flowing over IPv6, by default we are still sending all those IPv4 routes with an IPv4 next-hop. I can hear you saying "Of course we send the next hop with the same address family. How else would we do it?" How else2, indeed? This feature is called "extended next hop" in BIRD, which is commonly used for route servers at IXPs.
I will admit, the first time I saw such a thing in my routing table it bent my brain a bit too:
192.168.40.0/21 unicast [bgp_s2 22:12:39.702] * (100) [AS4206900201i]
via fd60:e0:a0f4:f::12:1 on eth2
Let's look at what's going on here:
When you consider that a packet traversing an IXP will have neither a source or a destination within that network, what is the point of the next-hop field?
The router uses it to determine the hardware address of where to send the packet.
In IPv4 this done with ARP for the specified IP.
In IPv6, NDP.
With this example we would perform NDP for fd60:e0:a0f4:f::12:1 and then send the IPv4 packet to that MAC.
With all BGP peer connections happening over IPv6 and sending IPv6 next-hop information, there is now no need for an IPv4 address on this router and you can return it to the IXP pool.
The astute reader will note some caveats with this plan:
- This assumes the router in question is dual-stack. If you are using separate physical infrastructure for each address family then nothing changes.
- Everyone who is peering with each other will have to support extended next hop. If one end does not, both sides will still need an IPv4 address for ARP. This may be a conversation you need to have with your vendor(s).
Nevertheless, I feel this demonstrates that using IPv6 to reduce the need for IPv4 in critical infrastructure is within reach. I hope we will consider these sorts of solutions first rather than continuing to shuffle the ever dwindling IPv4 free pool.