Re: Deprecating IPv6 (Re: draft-bourbaki-6man-classless-ipv6-00)

[Erik Kline <[e-mail]>]

On 6 June 2017 at 03:47, james woodyatt <[e-mail]> wrote:

> On Jun 4, 2017, at 23:35, Mikael Abrahamsson <[e-mail]> wrote:
>
> On Sun, 4 Jun 2017, Brian E Carpenter wrote:
>
>
> If we'd been able to agree on simply removing n=64 from 4291bis, I
> wouldn't have put my name on this draft.
>
>
> My take on this (and I don't think I am alone) is that this is a slippery
> slope down to where when I in 10 years connect to a wifi, I'll get an RA
> with PIO /128 with A=1, because the ISP decided they only wanted devices
> have single address, because that's what the product people wanted because
> then people wouldn't be able to have more than a single device per
> subscription (which is false, but some people believe this can be achieved).
>
> Down that /128 path leads NAT66 and all kinds of complexity to work around
> these problems, and we'll have gained very little by introducting IPv6.
>
>
> Now is as good a time as any to repeat that I’m working on delivering
> *basically* this now. Not in ten years. Now.
>
> The only difference between what I’m working on now and what Mikael
> describes is that I’m dealing with the situation where I’m a 6LoWPAN border
> router connecting to a home Wi-Fi™ LAN segment, and I can’t get a DHCPv6
> prefix because either a) the router isn’t capable of DHCPv6-PD as RFC 7084
> recommends, b) the router doesn’t have any more subnet prefixes to delegate
> (because other routers have consumed them all, usually by cascading one or
> more RFC 7084 routers behind the ISP border), or c) the router will never
> have enough subnet prefixes to delegate because the ISP didn’t delegate the
> CPE border router enough space.
>
> We are already on the path to IPv6/NAT w/ address amplification. We had a
> chance to stop it, and we blew it. It’s time to move on from that mistake.
>

Consider ND proxy or application/CoAP proxying.

We are in fact missing some APIs on host operating systems whereby
userspace can request the kernel to get an address for its use.  This would
be the companion piece to 7934's recommendations.