I've been ignoring this discussion because I feel this ship sailed many years ago, and IPv6, like it or hate it, is the best way forward we have.

But, assuming you're expanding the address space, the simplest solution is to add the additional bits addresses at the end.

I.E. every existing /32 gets an additional 64K addresses.   Or how many correspond to the additional number of bits.

You can then add this without making any changes to the core of the internet.   It's all routed just like it is today, only paying attention to the first /32 of the address.     The remaining /16 or /32 or whatever is then only handled internally by each network/ASN.     Heck, you might be able to this without changing IP at all - instead, you could probably add an extension address layer between IP and TCP.   So it's TCP/EXPADDR/IP.   

The motivation to upgrade can then come from the endpoints.   For a lot of applications, one only would have to update the customer-end software (i.e. web browsers), and the server end.   So if you're a google and are tired of trying to obtain more and more addresses, you just get the main browser vendors to add support for "IP Extended addressing" and then you add it on your servers.   The internet in the middle doesn't care.    As a host, all you need is a single /32.  At some point, eyeball networks could start handing out the extended addresses or using them for NAT, also alleviating their need for IP's.

On the other hand, this sure seems similar to what we do today with CGNAT and similar today since there are already 64K endpoints in both TCP and UDP per ./32 of IP.... 

On Sun, Oct 6, 2019 at 3:59 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Sun, 06 Oct 2019 17:47:24 -0400, bzs@theworld.com said:

> All a strictly IPv4 only host/router would need to understand in that
> case is the IHL, which it does already, and how to interpret whatever
> flag/option is used to indicate the presence of additional address
> bits mostly to ignore it or perhaps just enough to know to drop it if
> it's not implemented.

So... how would a strict IPv4 router handle the case where 8.8.4.5.13.9/40
should be routed to Cogent, but 8.8.4.5.17.168/40 should be routed via
Hurricane Electric, and no you can't just route to wherever 8.8.4.5 goes
because there's yet another peering war and nobody's baked a cake yet, so
sending packets for either route to the wrong link will cause blackholing?



--
- Forrest