Re: “DHCPv6, SLAAC, Static Day X - 17 year interoperability issue” 2nd issue

You say "In deployment cases where you would like to deploy longer 
prefix length subnets".
What problem are you facing that requires longer subnets?  I understand 
that problems that have been raised that require delegation.  That is 
not tied to longer or shorter, and I think is better addressed by 
shorter prefix lengths.

Is there some other problem you face that leads to needing longer prefix 
lengths?

Yours,
Joel

On 11/9/2020 7:35 PM, Gyan Mishra wrote:
> 
> This may have gotten lost in all the threads so starting a new thread. 
>   The issue is interoperability related issue between the 3 IPv6 
> addressing options that had been broken for 17 years.
> 
> Problem Statement:
> 
> The main point I am trying to make is that static address configuration 
> and DHCPV6 stateful RFC 8415, you can have any prefix length prefix.   
> SLAAC with A flag set requires a  64 bit IID and that stems from RFC 
> 4291 modified EUI64 mac based IID generation.  However, now with random 
> IID generation schemes with RFC 4941 privacy extension and RFC 7217 
> stable IID you can generate any length IID.
> 
> The operational issue with SLAAC not supporting any prefix length in PIO 
> and requirement for the 64 bit boundary is that in a deployment scenario 
> where you would like to deploy longer prefix length subnets with a mix 
> of server hosts with static address and mix of client hosts with managed 
> address M=1 that get their 128 bit address from the DHCPv6 server pool, 
> the fear has always been that if a device came up on the subnet that 
> only supports SLAAC it would not work due to the SLAAC A flag set and 64 
> bit IID requirement.  In that case the SLAAC host would not be able to 
> communicate with any of the devices with a longer prefix including the 
> router.
> 
> So that fear of interoperability of SLAAC hosts not being able to 
> support longer prefix lengths has prevented operators from being able to 
> deploy subnets with longer prefix lengths, as it’s hard to predict that 
> all hosts will be able to support static or stateful and so you may end 
> up in a situation where a device type may only support SLAAC so then you 
> are in trouble deploying longer prefix lengths.
> 
> Due to the SLAAC 64 bit IID restrictions it has prevented operators from 
> deploying “host” subnets with >64 bit prefix lengths.
> 
> f 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 
> <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.
> 
> 
> 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 inRFC 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:
> 
> 
> Thanks
> 
> Gyan
> 
> 
> Sent from my iPhone
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 