Re: IPv6 Pain Experiment

[bzs () theworld com]

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 () 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 () 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

-- 
        -Barry Shein

Software Tool & Die    | bzs () 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*