Re: draft-bourbaki-6man-classless-ipv6-00

[Erik Kline <[e-mail]>]

On 14 June 2017 at 18:09, Fernando Gont <[e-mail]> wrote:

> Hi, Brian,
>
> On 06/13/2017 04:35 AM, Brian E Carpenter wrote:
> > On 12/06/2017 13:00, Fernando Gont wrote:
> >> On 06/11/2017 09:29 PM, [e-mail] wrote:
> [....]
> >>>  - Removing the constant from the addressing architecture will likely
> set these changes into motion.
> >>>    (i.e. I don't think a position where one wants to remove the 64 bit
> constant from 4291 and expect the 64 bit boundary
> >>>     to stay in IPv6 over foo is tenable.)
> >>
> >> Me, I don't think there's a reason to keep the 64 bit constant in
> >> ipv6-over-foo documents. Actually, with RFC8064 in place, there's no
> >> reason why the IID should be link-type dependent.
> >
> > I believe that is simply false unless you want to go back to the era
> > of DIP switches with instructions to users to
> > a) choose an IID length for their new subnet
> > b) set the DIP switches on every device to select that length
> > c) then plug and play.
> >
> > Otherwise LL addresses cannot be formed consistently on the
> > whole link.
> >
> > OK, that is caricature, but without a substantial reworking of
> > RFC4862 I believe that is essentially what we would need, in
> > an automated version, before SLAAC can start.
> >
> > Anway, all this is empty talk as long as the addressing architecture
> > *requires* 64 bits rather than *recommending* 64 bits.
>
> * Mandate fe80::/64 for link-local
> * RECOMMENDED /64 for subnets
> * Make SLAAC implementations flexible so that they could do SLAAC if a
> non-64 PIO is advertised.
>

128-bit IPv4, yippee.

IPv6 NAT, I cannot wait.

I propose we also change the name of the working group while we're at it,
maybe v4-128-man.