IPv6 Pain Experiment

Forrest Christian (List Account) lists at packetflux.com
Mon Oct 7 03:12:22 UTC 2019


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20191006/e7ceb06d/attachment.html>


More information about the NANOG mailing list