IPv6 Pain Experiment

Mon Oct 7 17:22:48 UTC 2019

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 lists at 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.kletnieks at vt.edu>
 > wrote:
 > 
 >     On Sun, 06 Oct 2019 17:47:24 -0400, bzs at 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    | bzs at 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*