Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

[Gyan Mishra <[e-mail]>]

On Mon, Nov 9, 2020 at 6:04 PM Mark Andrews <[e-mail]> wrote:

>
>
> > On 10 Nov 2020, at 09:43, Gyan Mishra <[e-mail]> wrote:
> >
> >
> > In-line
> >
> > On Mon, Nov 9, 2020 at 4:57 PM Brian E Carpenter <
> [e-mail]> wrote:
> > 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".
> >
> >     Gyan>  I think you meant to say 17 year interoperability issue as
> RFC 3315 is dated 2003.   This is a MAJOR issue that had shackled operators
> in deployments of longer prefixes to host subnets.  That is a fact.
> >
> >
> > > 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.
> >
> >     Gyan> If you go to the “root” of the problem the root is the
> original IPv6 specification RFC 1884 dated 1995, RFC 2373 dated 1998, RFC
> 3513 dated 2003 and now the present RFC 4291 dated 2006.  As soon EUI64 mac
> based IID become not recommendedR and obsolete the standard should have
> immediately updated RFC 4291 as the dependency on fixed IID is no longer as
> now random IID generation schema starting with RFC 4941 privacy extension
> dated 2007 soon became standard for all OS vendors and later RFC 7217
> stable IID became an alternative option to provide a “random” IID.
> >
> > Once random IID became mainstream in all Host Operating Systems it was
> at that moment that the standard should have changed to update RFC 4291 to
> permanently remove in all RFCs any mention of 64 bit boundary.
>
> No.  The point of having a “fixed” size is to make the lives of everyone
> on the planet easier.  How you fill in the last 64 bits is a orthogonal
> issue.  Having a fixed /48 for a site was made for the same reason.  To
> make everyone’s lives easier.


   Gyan> Well that is what is stated in RFC 3177 for a default /48
allocation which is obsoleted by 6177 which takes a step back and is now
not making any recommendations and is putting the onus on operators to
figure it out and do what they feel is best which would definitely not be
one size fits all approach.

Please read the summary section in RFC 6177 below

5 <https://tools.ietf.org/html/rfc6177#section-5>.  Summary

   The exact choice of how much address space to assign end sites is an
   issue for the operational community.  The recommendation in RFC
3177 <https://tools.ietf.org/html/rfc3177>
   [RFC3177 <https://tools.ietf.org/html/rfc3177>] to assign /48s as a
default is not a requirement of the
   IPv6 architecture; anything of length /64 or shorter works from a
   standards perspective.  However, there are important operational
   considerations as well, some of which are important if users are to
   share in the key benefit of IPv6: expanding the usable address space
   of the Internet.  The IETF recommends that any policy on IPv6 address
   assignment policy to end sites take into consideration the following:



>
> > So this change if I do the math is now 13 years past due.  Even if you
> gave a few years for host operating systems to adopt the new standard which
> I believe back then was fairly quickly the standard should have changed
> eliminating the 64 bit boundary.
> >
> > Think of all the problems “Day 17 years” this has caused and even now
> all of these threads.
> >
> > This is clearly an IETF standards issue and needs to be fixed.
> >
> > We can’t pass the blame to operators to dole out shorter prefixes or
> support PD.  The IETF really needs to take onus end fix the broken standard.
> >
> > Not going to happen for PDP as their are technical issue related to the
> Mobile Network Gateway to support PD.   I will try to dig up the exact
> reason but the network element is very different then a BNG broadband
> gateway which supports most all L3 features.
> >
> > As far as 3GPP operators they are following the well documented RIPE-690
> which only requires allocation of /64.  The main reason mobile operators
> are not making shorter prefix a standard is that is overkill from their
> perspective as you may have many mobile handsets in a household and there
> is no reason for everyone at a single location to have shorter prefixes per
> PDP.  When you are at honme you use your wired broadband and when are away
> from home on the road on 3GPP on PDP is when the segmentation comes into
> play to subdivide the /64 prefix to downstream devices but in a household
> is only needed to be provided by one of the devices.
> > Bottom line is from a 3GPP provider standpoint it does not make sense to
> provide a shorter prefix and I don’t think that will ever change even with
> 5G PDP.
> >
> > Fixed 5G broadband which is a wired broadband replacement will follow
> RIPE-690 guidelines and will allocation much shorter prefixes as with
> network slicing and other capabilities with 5G offers the requirements
> exist for shorter prefixes.  Not so much for PDP.
> >
> >
> >
> https://www.ripe.net/publications/docs/ripe-690#4-2-4--considerations-for-cellular-operators
> >
> > 4.2.4. Considerations for Cellular Operators
> >
> > There is a clear exception to the rule described above when assigning
> prefixes in a cellular network. In this case, a /64 will need to be
> provided for each PDP context for cellular phones, whereas for LTE
> modems/routers, i.e. in the case of broadband by means of cellular access,
> it will still be necessary to choose a /48 or /56 in accordance with the
> aforementioned considerations.
> >
> >
> >
> >
> >
> >
> > > 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
> >
> > --
> >
> >
> > 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]
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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