Re: SLAAC, Static & DHCPv6 day 1 interoperability issue

You should not insist on blaming the RIPE-690 (“As far as 3GPP operators they are following the well documented RIPE-690 which only requires allocation of /64”), which is false, because:
It is not a standard, it is a BCP.
It was following the existing practices for existing LTE deployments, not changing it.
As you already included the text from 4.2.4., it is easy to see that it was already accounting for a /64 per PDP for a cellular smartphone, but when the cellular smartphone is used as a router, or it is a cellular router device and not a cellular smartphone, then it should also follows the rest of the BCP and standards regarding the provision of /48 or /56.

I think there is not chance for a wrong interpretation of section 4.2.4 in the RIPE-690. I tried my best and consulted with many folks, to make sure that it was clear enough. Even more, because not being native english speaker, I wanted to make sure that we don’t say anything that can be missinterpreted. Nevertheless, if you think it can be wrongly interpreted, I’m happy to work with the rest of the co-authors and make a new version, add whatever is needed for 5G, etc., etc. Just provide inputs.

Regards,

Jordi

@jordipalet

El 9/11/20 23:44, "ipv6 en nombre de Gyan Mishra" <ipv6-bounces@ietf.org en nombre de hayabusagsm@gmail.com> escribió:

In-line

On Mon, Nov 9, 2020 at 4:57 PM Brian E Carpenter <brian.e.carpenter@gmail.com> 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 <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".

    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

-- 

Gyan Mishra

Network Solutions Architect 

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

-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.