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

[Gyan Mishra <[e-mail]>]

On Mon, Nov 9, 2020 at 8:53 PM Ca By <[e-mail]> wrote:

>
>
> On Mon, Nov 9, 2020 at 4:36 PM Gyan Mishra <[e-mail]> 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
>>
>
> No
>

> 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.
>>
>
      Gyan> Sorry I mistyped  PDP here “5G wireless handsets not 5G fixed
wireless broadband

>
> I am 3gpp network operator.  None of the above thinking has entered my
> head.
>
> I have never read any ripe docs, so you cant say i am beholden to them.
>
> 3gpp operators only provide /64 because that is all that the standards
> allow for without dhcpv6. No other reason, please avoid creating narratives
> to explain what is clearly documented in the standards.
>
> https://tools.ietf.org/html/rfc6459#section-5.3
>
>
>
>> 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.
>>
>> Gyan> Mistyped PDP here I meant to say mobile handset.
>>
>

> I am rolling out 5G broadband using 64share, so your above is not correct,
> at least for me.  Why? No dhcp servers in network.
>
> Maybe you can tell us about how vz is deploying ipv6 here ?
>
>
> https://www.google.com/amp/s/www.rcrwireless.com/20200612/5g/verizon-expanding-enhancing-5g-fixed-wireless-service/amp
>
> Gyan> Typo above - I am referring to mobile handset not  Fixed 5G
> broadband which would support PD  and would be  much shorter prefixes.
>
>>
>>
>>
>> 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 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:
>>
>>
>> Thanks
>>
>> Gyan
>>
>>
>> Sent from my iPhone
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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