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

["Templin (US), Fred L" <[e-mail]>]

I think the notion of what constitutes a “site” has advanced significantly since the
publication of RFC6177 – to the point that today even my cellphone could be seen
as a “site” in terms of the multi-addressing requirements its internal networks and
applications may require. Things that once were regarded as uni-addressed end
systems are now becoming (massively) multi-addressed IoTs. So an RFC6177-sized
IPv6 prefix for my cellphone could potentially be put to good use.

Fred

From: Gyan Mishra [mailto:[e-mail]]
Sent: Monday, November 09, 2020 2:53 PM
To: Templin (US), Fred L <[e-mail]>
Cc: Alexandre Petrescu <[e-mail]>; Brian E Carpenter <[e-mail]>; Dmytro Shytyi <[e-mail]>; Dusan Mudric <[e-mail]>; IPv6 IPv6 List <[e-mail]>; [e-mail]
Subject: Re: [EXTERNAL] Re: SLAAC, Static & DHCPv6 day 1 interoperability issue



On Mon, Nov 9, 2020 at 5:14 PM Templin (US), Fred L <[e-mail]<mailto:[e-mail]>> wrote:
Brian, brief comment/question below:

> -----Original Message-----
> From: ipv6 [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Brian E Carpenter
> Sent: Monday, November 09, 2020 1:58 PM
> To: Gyan Mishra <[e-mail]<mailto:[e-mail]>>
> Cc: IPv6 IPv6 List <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Alexandre Petrescu <[e-mail]<mailto:[e-mail]>>;
> Dusan Mudric <[e-mail]<mailto:[e-mail]>>; Dmytro Shytyi <[e-mail]<mailto:[e-mail]>>
> 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 <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[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”?
>
> 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?



   Gyan> RFC 6177 - Bottom of the intro it states that no formal recommendation is given.  It’s up to the operators to give what they feel is best.


   This document does not make a formal recommendation on what the exact

   assignment size should be.  The exact choice of how much address

   space to assign end sites is an issue for the operational community.

   The IETF's role in this case is limited to providing guidance on IPv6

   architectural and operational considerations.  This document provides

   input into those discussions.  The focus of this document is to

   examine the architectural issues and some of the operational

   considerations relating to the size of the end site assignment.


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
> [e-mail]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--

[Image removed by sender.]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD