I think we're basically on the same page. But what I described wouldn't use port numbers to fake extended addressing, just a flag and some extra IP header for the extended addr bits.
On October 6, 2019 at 21:12 li...@packetflux.com (Forrest Christian (List Account)) wrote: > 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.kletni...@vt.edu> > wrote: > > On Sun, 06 Oct 2019 17:47:24 -0400, b...@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 -- -Barry Shein Software Tool & Die | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*