Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

[Gyan Mishra <[e-mail]>]

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.

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
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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