RE: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

Brian, brief comment/question below:

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: Monday, November 09, 2020 1:58 PM
> To: Gyan Mishra <hayabusagsm@gmail.com>
> Cc: IPv6 IPv6 List <ipv6@ietf.org>; draft-mishra-6man-variable-slaac@ietf.org; Alexandre Petrescu <alexandre.petrescu@gmail.com>;
> Dusan Mudric <dusan.mudric@gmail.com>; Dmytro Shytyi <dmytro@shytyi.net>
> Subject: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> In line...
> 
> On 10-Nov-20 04:35, Gyan Mishra wrote:
> > Brian
> >
> > In-line
> >
> > On Sun, Nov 8, 2020 at 3:14 PM Brian E Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> 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”?
> 
> No. From the dates of the RFCs, it's a "Year 7 interoperability issue".
> 
> > Do you agree that one way to solve is to allow SLAAC to support longer prefix lengths?
> 
> That's one way, but it's the wrong way. The right way is for all operators, including mobile operators, to assign /48 or /56 to all end
> users.

Isn't that exactly what RFC6177 (BCP157) tells us? Should we be working to
reaffirm that that BCP still applies today?

Thanks - Fred

> > Do you agree that this is a major operational issue that needs to be solved?
> 
> Yes, but as Barbara says, that needs some collaboration with the SDOs and operator fora to get rid of /64 assignments.
> 
>    Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------