Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

[Gyan Mishra <[e-mail]>]

Brian

In-line

On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <
[e-mail]> wrote:

> Gyan,
>
> I don't think you were around for the original discussions, so there is an
> aspect that is missing from your logic below.
>
> The inclusion of a separate interface identifier field in IP addresses was
> an entirely intentional feature of IPng. If all we had wanted to do was
> IPv4 with bigger addresses, that's what we would have done and the address
> length would have undoubtedly been 64 bits. In fact there were various
> proposals to do exactly that, with a variety of associated transition and
> coexistence mechanisms.
>
> But the rough consensus was to do more than that, and to allow *extra*
> space in the address for an interface identifier that was not part of the
> subnetting mechanism. Originally it was going to be 48 bits, so the longest
> subnet prefix would have been 80; on second thoughts it was set to 64,
> which gave *exactly* the same extension to the subnettable space as we
> would have got from IPv4 with bigger addresses.
>
> That isn't inconsistent with what we now call BCP198, which says that on
> links where an interface identifier & SLAAC isn't needed, subnetting can
> extend out to /127.
>
> All that was despite the fact that we hadn't even realised the potential
> privacy benefits of a host-defined interface identifier at the time; that
> is much more recent.
>
> As far "day 1" goes, please remember that DHCPv6 is a retro-fit:
>
> RFC1971 IPv6 Stateless Address Autoconfiguration. August 1996
> RFC3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). July 2003.


    Gyan> Makes sense then that as DHCPv6 was a retrofit “add on” to the
base architecture that this issue came about afterwards.

>
>
> (In fairness, draft-ietf-addrconf-ipv6-auto-00 was dated January 1995 and
> draft-ietf-dhc-dhcpv6-00 was dated February 1995, but it advanced very
> slowly compared to SLAAC.)


    Gyan> From a problem statement perspective do you agree with the title
of this thread “Day 1 interoperability issue”?

Do you agree that one way to solve is to allow SLAAC to support longer
prefix lengths?

Do you agree that this is a major operational issue that needs to be solved?

>
>
> Regards
>    Brian Carpenter
>
> On 08-Nov-20 19:34, Gyan Mishra wrote:
> >
> > A day 1 issue that has existed with SLAAC and another critical
> operational reason as to why longer prefix should be supported by SLAAC.
> >
> > Since SLAAC only supports /64 plen due to the fixed 64 bit IID, that
> issue ends up shackling IPv6 from using longer  prefix length when other
> devices using static or DHCPV6 are configured on the same subnet.
> >
> > The major issue that exists is that their maybe devices that do not
> support DHCPV6 or static and have to use SLAAC and you have a subnet
> configured on the router with longer then /64 prefix length like a /96 for
> example.
> >
> > So now with those devices running SLAAC you end up with interoperability
> issue with remaining devices on the subnet that support longer prefix
> length via static or DHCPV6.
> >
> > The workaround has always been to not use longer prefix lengths for
> DHCPV6 and static and only use the /64 prefix length as that is only
> supported by SLAAC.
> >
> > So that hinders any and  all operators both enterprises and service
> providers from using longer prefix lengths, so you are now back to being
> stuck with the 64 bit IID boundary for all host subnets till the end of
> time using any of the three IPv6 addressing schemes.
> >
> > Gyan
> >
> >
> >
> >
> >
> > --
> >
> > <http://www.verizon.com/>
> >
> > *Gyan Mishra*
> >
> > /Network Solutions A//rchitect /
> >
> > /M 301 502-1347
> > 13101 Columbia Pike
> > /Silver Spring, MD
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD