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

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

I have to disagree with most of what you wrote.  As far as I can tell, 
it comes down to "I want to use longer prefixes" which is not a reason 
to change IETF standard.

We have many mechanisms available now to address the ND Cache exhaustion 
attacks.  Changing the prefix length is not a good one.
As for the history with 6164, that was a narrow exception carved out in 
significant part due to an implementation bug with bouncing packets. 
You are not asking for a narrow carve-out, but rather tht we throw away 
the entire /64.  That level of change requires significant justification.

Apparently, your ask is quite distinct from that brought forward by 
Cameron and Barbara.

Yours,
Joel

On 11/10/2020 1:12 AM, Gyan Mishra wrote:
> Hi Joel
> 
> In-line
> 
> On Mon, Nov 9, 2020 at 9:38 PM Joel M. Halpern <[e-mail] 
> <mailto:[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]>
>      > <mailto:[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]>>
>      >      > <mailto:[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>>>
>      >      >
>      >      >      >
>      >      >
>      >     
>       <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>>
>      >      >     <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>>
>      >      >     <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>>
>      >      >     <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]>> <mailto:[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>>
>      >      >     <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/>
>     <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/ <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
> 
>