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

["Joel M. Halpern" <[e-mail]>]

Let me try again.
What you describe below is a case where if you were giving out longer 
prefixes, SLAAC would have problems. That much I get.

What I still do not understand (and I will grant that maybe I am just 
dense and missing the obvious; please explain) is why you need prefixes 
longer than /64 at all.

Yours,
Joel

On 11/9/2020 9:29 PM, Gyan Mishra wrote:
> 
> 
> I was just giving an example of mixed hosts on the same subnet using 
> different IPv6 addresses methods.  So it can be any network or any 
> scenario where you have mix of addressing methods with longer prefixes.
> 
> The problem is that SLAAC does not support >64 prefixes due to IID 64 
> bit limitation and that prevents use of DHCPv6 stateful or static with 
>  >64 prefix subnets.
> 
> 
> On Mon, Nov 9, 2020 at 9:19 PM Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Gyan, I apparently was not unclear.
>     I was not asking who needs to use longer prefixes.  I was asking why.
>     Telling me that some data enters want them does not tell me what
>     problem
>     the data center needs to solve.
> 
>     Can you explain what problem needs to be solved, for whichever
>     community
>     it is that needs to deploy these longer prefixes?
> 
>     I presume there is a real problem.  But I can not tell from your
>     description what it is.
> 
>     Thank you,
>     Joel
> 
>     On 11/9/2020 8:37 PM, Gyan Mishra wrote:
>      > This is a separate issue from 3GPP PDP handset segmentation issue to
>      > downstream devices.
>      >
>      > This issue exists with any deployments where the operator would
>     like to
>      > deploy >64 prefix length host subnets at data center or access
>     layer and
>      > this could be an enterprise or service provider use case where the
>      > router infrastructure is statically configured so no PD here.
>      >
>      > So in this case the operator would like to deploy >64 prefixes
>     and has
>      > let’s say all servers are configured with static and all access
>     hosts
>      > are configured with dhcpv6 stateful RFC 8415.  No  PD here.   So
>     we have
>      > both static and stateful hosts on the same subnet.
>      >
>      > So now you have SLAAC hosts that get added to that same subnet
>       that now
>      > don’t support static or DHCPv6 stateful let’s say Chromebook or
>     could be
>      > any device type for example and now your are in trouble.
>      >
>      > So now due to SLAAC not supporting longer prefixes that very real
>     fear
>      > of host operating systems that may only support slaac you and up
>     in an
>      > terrible interoperability situation that you have to change your
>     prefix
>      > length for all devices back to /64 so that all devices types with
>     the 3
>      > different IPv6 address allocation scheme can operate on the same
>     subnet.
>      >
>      > So due to this major 17 year issue operators have not been able to
>      > deploy longer prefix lengths to host subnets.
>      >
>      > This is a MAJOR problem for all operators.
>      >
>      >
>      > Hope that helps clarify the interoperability issue.
>      >
>      >
>      > Gyan
>      >
>      > On Mon, Nov 9, 2020 at 8:06 PM Joel M. Halpern
>     <[e-mail] <mailto:[e-mail]>
>      > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>      >
>      >     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>
>      >   
>       <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>>
>      >
>      >      >
>      >   
>       <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>
>      >   
>       <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
>     <https://tools.ietf.org/html/rfc6177#section-5>
>      >     <https://tools.ietf.org/html/rfc6177#section-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
>     <https://tools.ietf.org/html/rfc3177>
>      >     <https://tools.ietf.org/html/rfc3177
>     <https://tools.ietf.org/html/rfc3177>>>
>      >      >     [RFC3177  <https://tools.ietf.org/html/rfc3177
>     <https://tools.ietf.org/html/rfc3177>
>      >     <https://tools.ietf.org/html/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] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >      > Administrative Requests:
>      > https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>      >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>      >      >
>     --------------------------------------------------------------------
>      >      >
>      >
>      > --
>      >
>      > <http://www.verizon.com/ <http://www.verizon.com/>>
>      >
>      > *Gyan Mishra*
>      >
>      > /Network Solutions A//rchitect /
>      >
>      > /M 301 502-1347
>      > 13101 Columbia Pike
>      > /Silver Spring, MD
>      >
>      >
> 
> -- 
> 
> <http://www.verizon.com/>
> 
> *Gyan Mishra*
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>