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

[Gyan Mishra <[e-mail]>]

Hi Joel

In-line

On Mon, Nov 9, 2020 at 9:38 PM Joel M. Halpern <[e-mail]> wrote:

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


    Gyan> The reasoning is simply the exact same reason you would configure
a loopback as a /128, since no hosts exists on the loopback subnet same
reasoning given in RFC 6164 recommendations to use /127 on P2P links with
only 2 hosts for security and other reasons parallels IPv4 use of /31 for
P2P links.

The security reason is a big issue as well as ND cache exhaustion and
managing the ND cache by sizing the subnet based on the maximum number of
hosts you expect project or plan to have on a subnet.  For infrastructure
routed backbone or IXP large peering points to limit ND cache exhaustion
using longer prefix subnets helps limits the ND cache maximum.

I have deployed IPv6 to many enterprise and operators networks over the
past 20 years using a IPv6 address deployment architecture schema I
developed that is based on a hierarchical framework and utilizes a set of
vlsm mask standard for infrastructure,   /128 for loopbacks, /127 for P2P,
/120 infrastructure routed I call >2 host subnet used for SFC chaining or
NFV, FW or LB or any other appliance physical or virtual functions.   Host
subnets would end up being /64, however if longer prefix were allowed in
RFC 4291, I would not carve out the /64 to save on IPv6 space, as address
scarcity is not the reason for longer prefixes, so would make the subnet a
/116 or /112 maximum size if slaac supported longer prefixes.

For typical router backbone or FW or LB SFC chain networks sizing the
subnet according to the number of network element hosts on the subnet for
security reasons as well is the preferred method for most operators.

For host subnets,  that would be the size of the broadcast domain which
would play into the maximum size for security reasons as well and limiting
mazimoND cache size.  From a security standpoint added benefit is that
smaller subnets do  allows for operator network scanning to easily occur.

For ease of provisioning of network infrastructure where you have 1000s of
P2P links  it would be great if slaac could be run on P2P /127 instead of
having to configure both end you would configure one end and the other end
would be auto configured via SLAAC.  The issue with manually or even
manaually via Netconf controller is having to ensure manual or script is
error free and no DUP on network.  If slaac was supported on P2P /127 you
could configure one and and ensue the one end is unique but then the typo
via Netconf or manual is avoided by slaac.  It would be nice if all IPv6
infra longer prefix subnets could be automated this way to avoid duplicates
via slaac if slaac supported longer prefix lengths.

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

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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