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

[Mark Andrews <[e-mail]>]

Well people where thinking at the time that a person could be a site in terms
of wearable networks.  They are now a common reality with cell phones providing
a uplink.  /48 was chosen with that concept in mind.

Mark

> On 10 Nov 2020, at 10:10, Templin (US), Fred L <[e-mail]> wrote:
> 
> 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]> wrote:
> Brian, brief comment/question below:
> 
> > -----Original Message-----
> > From: ipv6 [mailto:[e-mail]] On Behalf Of Brian E Carpenter
> > Sent: Monday, November 09, 2020 1:58 PM
> > To: Gyan Mishra <[e-mail]>
> > Cc: IPv6 IPv6 List <[e-mail]>; [e-mail]; Alexandre Petrescu <[e-mail]>;
> > Dusan Mudric <[e-mail]>; Dmytro Shytyi <[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]>> 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]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> --
> <image001.jpg>
> 
> Gyan Mishra
> Network Solutions Architect 
> 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
> --------------------------------------------------------------------

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]