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

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 19:35:46 -0500

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

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 20:06:13 -0500

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.
> 
> 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>
> 
> 
> 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.
> 
>     5 <https://tools.ietf.org/html/rfc6177#section-5>. Summary
> 
> 
> 
>     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
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 20:37:27 -0500

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 <[email-masked]> wrote:

> > <
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Ca By <[email-masked]>
Date: Mon, 9 Nov 2020 17:53:31 -0800

On Mon, Nov 9, 2020 at 4:36 PM Gyan Mishra <[email-masked]> wrote:

> The issue is interoperability related issue between the 3 IPv6 addressing
> options that had been broken for 17 years.
>
> Problem Statement:
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> provide a shorter prefix and I don’t think that will ever change even with
> 5G PDP.
>

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

> exist for shorter prefixes.  Not so much for PDP.
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

> 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.
>
>
> 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.
>
>    issue for the operational community.  The recommendation in RFC 3177 <https://tools.ietf.org/html/rfc3177>

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 12:56:45 +1100

> On 10 Nov 2020, at 12:37, Gyan Mishra <[email-masked]> 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.

You do know a datacenter (or any site) is not restricted to 2^16 /64 subnets.  You can get bigger allocations if you need them.  That has always been expected.

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

Well if you buy a niche product and use it outside of the design space and it doesn’t work there is no one to blame but yourself.  IPv6 devices are expected to support both SLAAC and DHCPv6.

> 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.
> 
> Gyan Mishra
> Network Solutions Architect 
> M 301 502-1347
> 13101 Columbia Pike 
> Silver Spring, MD
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 21:19:12 -0500

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 could be an enterprise or service provider use case where the 
> router infrastructure is statically configured so no PD here.
> 
> 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 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 
> So due to this major 17 year issue operators have not been able to 
> deploy longer prefix lengths to host subnets.
> 
> On Mon, Nov 9, 2020 at 8:06 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > Think of all the problems “Day 17 years” this has caused and even
>     now
>      > all of these threads.
>      >
>     <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>>
>      >
>      >
>      >     5 <https://tools.ietf.org/html/rfc6177#section-5
>     <https://tools.ietf.org/html/rfc6177#section-5>>. Summary
>      >
>      >
>      >
>      >     issue for the operational community.  The recommendation
>     inRFC 3177  <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>>] to assign /48s as a default
>     is not a requirement of the
>      > [email-masked] <mailto:[email-masked]>
>      > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 21:22:34 -0500

>> provide a shorter prefix and I don’t think that will ever change even with
      Gyan> Sorry I mistyped  PDP here “5G wireless handsets not 5G fixed
wireless broadband

>> Gyan> Mistyped PDP here I meant to say mobile handset.
>>
>

> Gyan> Typo above - I am referring to mobile handset not  Fixed 5G
> broadband which would support PD  and would be  much shorter prefixes.
>
>>
>>
>>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 21:29:43 -0500

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.

-- 

*Gyan Mishra*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 21:38:08 -0500

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:
> 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 <[email-masked] 
>      > On Mon, Nov 9, 2020 at 8:06 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> 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>>>
>      >      >
>      >      >
>      >      >         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
>     <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
>      >      >     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
>      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >      > Administrative Requests:
>      >     <https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>>
>      >      >
>      >      >
>      > <http://www.verizon.com/ <http://www.verizon.com/>>
>      >
>      > *Gyan Mishra*
>      >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 13:45:33 +1100

> On 10 Nov 2020, at 12:53, Ca By <[email-masked]> wrote:
> 
> 
> 
> 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.
> I am 3gpp network operator.  None of the above thinking has entered my head. 
> 
> 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. 
> 

What’s not explained is why operators haven’t deployed DHCPv6 servers.  One is already allocating /64 per customer just increase the prefix to a /48 and use the first /64 for the downstream link.  A stub DHCPv6 server can look for the Prefix Delegation and Prefix Exclude Option in the request and if present return a delegation to the already allocated /48 carving out the downstream /64.  You don’t need much more.

Are people really incapable of working out minimal implementations?  Or are they just not bothering to ask their vendors for them?  Its been 8 years since RFC 6459 was published.

> I am rolling out 5G broadband using 64share, so your above is not correct, at least for me.  Why? No dhcp servers in network. 
> 
>    [
> RFC3177
> ] to assign /48s as a default is not a requirement of the

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Nov 2020 21:55:03 -0500

> infrastructure is statically configured so no PD here.

I would claim that the next useful prefix length after 64, is 128.

In DC situations, there are really no LANs (i.e. no big yellow cables with
vampire taps), just p2p TX or FX ethernet all over the place.

It would be great to understand your DC use case better.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ca By <[email-masked]>
Date: Mon, 9 Nov 2020 19:15:37 -0800

On Mon, Nov 9, 2020 at 6:45 PM Mark Andrews <[email-masked]> wrote:

> 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
> at that moment that the standard should have changed to update RFC 4291 to
> What’s not explained is why operators haven’t deployed DHCPv6 servers.
> One is already allocating /64 per customer just increase the prefix to a
> /48 and use the first /64 for the downstream link.  A stub DHCPv6 server
> can look for the Prefix Delegation and Prefix Exclude Option in the request
> and if present return a delegation to the already allocated /48 carving out
> the downstream /64.  You don’t need much more.
>
> Are people really incapable of working out minimal implementations?  Or
> are they just not bothering to ask their vendors for them?  Its been 8
> years since RFC 6459 was published.
>

I feel like i have answered this question several time in the last 48
hours. Your answer in a word is: inertia. Set aside your pitch fork. I am
explaining the world as i see it

The force required to break the current stasis is more than i have, if i
must use dhcpv6.  Again, many years of proof.

But i believe that i, and other similar mobile operators can get < 64 size
prefix in customers hands and homes with a tweak of the 3gpp spec to allow
RA < 64 and a UE mechanism to break that prefix into many 64s

> r

>
> >
> >
> > I am rolling out 5G broadband using 64share, so your above is not
> correct, at least for me.  Why? No dhcp servers in network.
> >

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 14:28:52 +1100

> On 10 Nov 2020, at 14:15, Ca By <[email-masked]> wrote:
> 
> 
> 
> I feel like i have answered this question several time in the last 48 hours. Your answer in a word is: inertia. Set aside your pitch fork. I am explaining the world as i see it 
> 
> The force required to break the current stasis is more than i have, if i must use dhcpv6.  Again, many years of proof. 
> 
> But i believe that i, and other similar mobile operators can get < 64 size prefix in customers hands and homes with a tweak of the 3gpp spec to allow RA < 64 and a UE mechanism to break that prefix into many 64s

The question is how is this going to turn out differently to PD+PE?  That too was an extension to make greater than 1 /64 work with 3GPP.  I don’t mind trying, but given the track record of going from spec to implementation in this space is not good to say the least.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 22:31:40 -0500

> The force required to break the current stasis is more than i have, if i must use dhcpv6.  Again, many years of proof. 

So, to summarize, the problem is that you can’t get your IT department to install DHCPv6 servers?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 23:27:58 -0500

Ted, I'm not an operator, but I sure find that a very dismissive 
response.  (I doubt that was your intent)
There are operational complexities to adding a new kind of server into 
an operational network.
(Side note, we are in this case not talking about the IT department.  We 
are talking about the operational efforts of an ISP.)

When operators tell us they have constraints, it is fair for us to 
inquire as to the nature of the constraints.  It is not fair for us to 
say "you MUST make different operational choices."

We as a community decided that there were going to be two paths to 
operating an IPv6 network.  (SLAAC and DHCP, let's not worry about other 
corner cases.)  When we made that choice, we should ahve recognized that 
there were operational implications, complications, and trades inherent 
in that decision.  Just as we need to (and usually have) listened when 
operators have asked for DHCP capabilites that they need, we should be 
listening when operators tell us there are RA / SLAAC capabilities they 
need.

In particular, Cameron has been very forthcoming and clear about what he 
wants to deliver and what his operational constraints are.  Implying he 
should just use DHCP anyway seems an odd answer.

Quite a number of us have said over the years that we want operators to 
participate more, and we want to understand what they need.  We may or 
may not decide to make changes (listening does not mean agreeing).  But 
we really should be paying attention to what the range of operators are 
telling us.

I hope that my notes to Gyan have been questioning and done dismissing. 
  Apologies if they have come off otherwise.

Yours,
Joel

On 11/9/2020 10:31 PM, Ted Lemon wrote:
> On Nov 9, 2020, at 10:15 PM, Ca By <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> The force required to break the current stasis is more than i have, if 
>> i must use dhcpv6.  Again, many years of proof. 
>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Nov 2020 01:12:40 -0500

Hi Joel

In-line

> dense and missing the obvious; please explain) is why you need prefixes

    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.

> >      >     Is there some other problem you face that leads to needing
> longer
> >      >     prefix
> >      >     lengths?
> >      >
> >      >     Yours,
> >      >     Joel
> >      >
> >      >      > This may have gotten lost in all the threads so starting a
> new
> >      >     thread.
> >      >      > 4291 modified EUI64 mac based IID generation.  However,
> >     now with
> >      >     random
> >      >      > 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,
> >      >      > 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
> >      >      > support longer prefix lengths has prevented operators from
> >     being
> >      >     able to
> >      >      > 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
> >      >      > 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
> >      >      > immediately updated RFC 4291 as the dependency on fixed
> >     IID is no
> >      >     longer
> >      >      > 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
> >      >      > 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
> >      >      > 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
> >      >      > 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
> >      >      > there  is no reason for everyone at a single location to
> have
> >      >     shorter
> >      >      > 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
> >      >      > access, it will still be necessary to choose a /48 or /56
> in
> >      >     accordance
> >      >      > RFC 3177 for a default /48 allocation which is obsoleted
> >     by 6177
> >      >     which
> >      >      > putting the onus on operators to figure it out and do what
> >     they
> >      >     feel is
> >      >      >     The exact choice of how much address space to assign
> end
> >      >     sites is an
> >      >      >     considerations as well, some of which are important if
> >     users
> >      >     are to
> >      >      >     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
> >      >      >
> >      >      >
> >      >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> >     <mailto:[email-masked]>>
> >      >      > Administrative Requests:
-- 

*Gyan Mishra*

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 Nov 2020 17:13:45 +1100

> On 10 Nov 2020, at 15:27, Joel M. Halpern <[email-masked]> wrote:
> 
> Ted, I'm not an operator, but I sure find that a very dismissive response.  (I doubt that was your intent)
> There are operational complexities to adding a new kind of server into an operational network.
> (Side note, we are in this case not talking about the IT department.  We are talking about the operational efforts of an ISP.)
> 
> When operators tell us they have constraints, it is fair for us to inquire as to the nature of the constraints.  It is not fair for us to say "you MUST make different operational choices."
> 
> We as a community decided that there were going to be two paths to operating an IPv6 network.  (SLAAC and DHCP, let's not worry about other corner cases.)  When we made that choice, we should ahve recognized that there were operational implications, complications, and trades inherent in that decision.  Just as we need to (and usually have) listened when operators have asked for DHCP capabilites that they need, we should be listening when operators tell us there are RA / SLAAC capabilities they need.

RA has the O bit for a reason.  It was so every client didn’t have to code 2 solutions for getting information.  It was designed to be used with a minimal DHCPv6 server in the router.  A server that didn’t hand out addresses.  A server that didn’t need to save state.  Instead we now have every device having to be coded with 2 solutions (RA + DHCPv6).  The same data that would have been handed out in a DHCPv6 packet is now being handed out in a ICMPv6 packet.  The router is still returning the information to the client.  The only difference from the routers perspective is that it has opened one socket to listen for ICMPv6 traffic instead of 2 sockets (ICMPv6 + DHCPv6).  It still has to encode the data.  It still has to be configured with the data it is handing out.  The big difference is every other device on the planet now has to support 2 ways to get the same information.

I suspect most of this came down to operators and equipment vendors not realising how the O bit was supposed to be implemented.  If you think you have to run a DHCPv6 servers with failover that is keeping state that has to be co-ordinated with the router just to hand out nameserver addresses, etc. then yes a complaint was valid, but that was never the intention.  It could be done with seperate machines for the DHCPv6 servers but it didn’t have to be done that way.

> In particular, Cameron has been very forthcoming and clear about what he wants to deliver and what his operational constraints are.  Implying he should just use DHCP anyway seems an odd answer.
> 
> Quite a number of us have said over the years that we want operators to participate more, and we want to understand what they need.  We may or may not decide to make changes (listening does not mean agreeing).  But we really should be paying attention to what the range of operators are telling us.

> I hope that my notes to Gyan have been questioning and done dismissing.  Apologies if they have come off otherwise.
> 
> Yours,
> Joel
> 
> 
>> On Nov 9, 2020, at 10:15 PM, Ca By <[email-masked] <mailto:[email-masked]>> wrote:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Nov 2020 10:28:29 +0100

Definitively RFC6177 needs to be updated.

I was planing already to update https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-02

I think from this conversation, we may need to better define what is a site and why a site MUST be provided a /48.

Regards,

Jordi

@jordipalet

El 10/11/20 1:36, "ipv6 en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

Problem Statement:

 

5.  Summary

Thanks 

Gyan

Sent from my iPhone

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Nov 2020 10:54:19 +0100 (CET)

> to explain what is clearly documented in the standards.

... and why is that? 3GPP R11 standardised DHCPv6-PD with prefix-exclude 
back in 2011. Why are where in 2020 with no support for this 15 year old 
protocol that seems to work just fine for similar architectures (I see 
BNG-PPPoE-RG as very similar to PDNGW-GTP-UE).

Your proposal seems to me to be that instead of mobile operators telling 
their vendors to implement DHCPv6-PD in mobile core nodes, you now want to 
have changes done to everything else from the UE and behind it. What's 
that, 5-10 magnitudes more devices? With 1-3 magnitudes more vendors?

You mentioned the word "inertia". What about the inertia in the end-user 
space, with devices you don't even control?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Mudric, Dusan" <[email-masked]>
Date: Tue, 10 Nov 2020 14:44:25 +0000

It is perfectly valid for host to obtain addresses from:
- DHCPv6, or
- SLAAC, or
- both.

I implemented 'both' solution as a default on IP phones, to allow a flexible deployment. An operator has a choice to select other options.

Dusan

>> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!cfPODMB0cz_fTeew8UnhkKeFNyFe5INk-qHf0vPOCsD2K6K_W9LrC8QcSCgD$ 
> Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!OSsGDw!cfPODMB0cz_fTeew8UnhkKeFNyFe5INk-qHf0vPOCsD2K6K_W9LrC8QcSCgD$

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 16:21:51 +0100

> scenario where you have mix of addressing methods with longer

It could be even just one single smartphone.  In every single smartphone
there are at least two processors inside.  The use of virtual machines
is highly probable.  Each one would need an address.  They are on
different subnets.

This problem of virtual machines on a smartphone was mentioned by
somebody else earlier, I only repeat it.

There could be, and there are, what I call 'hacks'.  These hacks make it
possible to exclude a /64 from a /56 (prefix exlude options in DHCP or
in PMIP); they make possible to use 'proxy' ND; they make unwritten
assumptions of padding always with 0s; they make a host sending itself
an RA just for the purpose of forming an address; and there are more
hacks that I might not remember that quickly.

Alex

> bit limitation and that prevents use of DHCPv6 stateful or static
> with >64 prefix subnets.
> 
> 
>> 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?
>> 
>> Thank you, Joel
>>> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Nov 2020 14:12:30 -0500

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 <[email-masked] 
>      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.
> 
> 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.
> 
> 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.
> subnet according to the number of network element hosts on the subnet 
> for security reasons as well is the preferred method for most operators.
> 
> 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
> 
>      >  >64 prefix subnets.
>      > On Mon, Nov 9, 2020 at 9:19 PM Joel M. Halpern
>      >     community
>      >      > 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
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> 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>>>>
>      >      >      >
>      >      >      >
>      >      >      >         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>>>>. 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>>>>
>      >      >      >     [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
>      >      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>      >     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >      >      > Administrative Requests:
>      >      > 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
>      >      >
>      >      >
>      >
>      > --
>      >

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 10 Nov 2020 14:46:09 -0500

In-line

On Mon, Nov 9, 2020 at 9:55 PM Michael Richardson <[email-masked]>
wrote:

> router

   Gyan> For operators worldwide from my experience the last 20+ years
working with IPv6 of what has been deployed and proliferated around the
globe as far as prefix lengths is as follows:

Defacto standard for operators both enterprises and service providers.

/128 for loopbacks
/127 per RFC 6164 for P2P
/126 for P2P prior to 6164

Infrastructure subnet sizing based on number of hosts on the subnet.

/64 - /125

-Firewall VLAN - This could be a shared firewall trusted or untrusted VLAN.
- Router to Router shared backbone
- Load Balancer VIP vlan
- Content engines
-VPNs clusters
- Proxies

The main best practice guidelines used by operators is to make the subnet
sizing manageable with hard limit on the number of allowed hosts on the
subnet, thereby creating a hard ND cache size limit, and not rely on
software soft knobs to manage the ND cache.  Also operators requirement as
part of ND cache management is to be able to easily scan critical
infrastructure subnets.

So this concept of hard limiting can be applied to Data Center subnets
creating ND cache hard limits on the subnet sizing using >64 prefix lengths.
>From a security and management perspective for operators having the
critical infrastructure secure and easily scannable as well as the hard ND
cache limit for operators provides the much needed and necessary data
center stability.  So this is all accomplished today by static
configuration on the servers as static allows any prefix length.

For access infrastructure same concept applies for hard limit on ND cache
management, and subnet scanning capabilities for stability by deployment of
>64 prefix length DHCPv6 scopes RFC 8415 which supports any prefix length.

So now the proliferation of >64 prefix lengths is out there deployed by
Verizon as well as other operators I have worked with worldwide.

My guess is when the original IPV6 addressing specification was written if
the founders did not want anyone to use >64 prefix lengths they should have
extended the 64 bit IID boundary restriction to static and DHCPv6 stateful.

The net-net end result of this predicament for operators worldwide that
would like to use >64 prefix, as long as the subnet is deployed to network
infrastructure and they can guarantee in their deployments that there will
never be slaac hosts that has the 64 bit IID boundary then the impact is
reduced to only those scenario where slaac devices are in the mix.

So network infrastructure can and does use without impact to routing as any
prefix length 1 to 128 is routable, so from an impact perspective,
infrastructure is fine and can continue to go crazy with vlsm as it has
been doing for 20+ years and design the IPv6 addressing schema with >64
prefix length however they desire.   No issues.

For Data Centers as long as static is the guaranteed only means of
addressing on data center subnets no impact to operators here as well using
>64 prefix lengths.

Data Centers may also have dedicated mix subnets that have servers with
slaac, as well as dhcpv6 stateful and static, but in these cases now have
to keep the subnet mask at 64.   So in this particular case for operators
hard ND cache rule and security scanning requirement is where if slaac
supported >64 prefix lengths comes into play, and  that would allow mix of
the 3 addressing types on the same subnet if RFC 4291 was updated
eliminating the 64 bit IID boundary.

Same goes for access layer where you have a mix of the three addressing
types static DHCPv6 and slaac and have to use /64 due to slaac fixed 64 bit
IID restriction.  So here also is the gap of not being able to support >64
prefix lengths.

I know there are surveys of the IPv6 deployments related to vlsm usage,
however as surveys go,  they are a random sampling and an extrapolation so
you have to take it with a grain of salt is my take.

I think talking to operators like myself and others on list is really the
best way to get a true feeling  and idea of what had been deployed and a
more realistic picture.

Gyan

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 22:30:17 +0100

> with the aforementioned considerations.

This is a very valid point.

That RIPE document states clearly that "a /64 will need to be
provided for each PDP context for cellular phones".

This a big issue I was not even aware of.  If someone reads that text 
then one can no longer claim that RIPE recommends non-/64s to end users 
of cellular networks.  On the contrary, RIPE recommends /64s to end 
users of cellular networks.

I wonder where was this burried up to now that we I not see it.

Or maybe it is only me who did not see it, sorry then.

Alex