Subject: [v6ops] The bottom is /112 (was: RE: Extending a /64) -- How about new fixed bottom /80 win-win for all - epiphany at 6:54am after v6ops preso

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 07:18:35 -0500

v6ops preso - "race to bottom slide" slightly modified - new proposal for
new /80 bottom so that we could actually make multiple /48s I mean /64s
actually wearable.

A /64 would be the new /48 as we shifted the IID by 16 bits shorter &
making the prefix 16 bits longer.

/64 = current Bottom fixed based on 64 bit IID.

/48 = 64k /64s - Due to current 3GPP architecture limitation we cannot dole
out shorter prefixes via 64share v2 even that Cameron proposed.  Also with
the RA PD style trickery w/o A bit set as Lorenzo mentioned the host would
not accept the shorter prefix as it is expecting a 64 bit prefix from the
3GPP gateway.

Why /48's wearable is not possible today for 2 reasons:

1. Large providers such as Verizon subscribers = 150M not including
broadband and /24 equates to 16M /48 way short and /20 even 160M but large
providers as Verizon's of the world need to scale to 1B or 7B.

2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48,
RFC 4291 would have to change the 64 bit fixed boundary requirement for any
handset to accept shorter prefix.  So we are stuck and 64 share v2 is not
possible w/o RFC 4291 changing.

What if we made the new fixed bottom a /80 meaning.  So that would
essentially be the new bottom that ISPs cannot race any further since the
standard would be fixed at the new /80 bottom just as its fixed at the /64
bottom.  We just gave ourselves 16 bits to play with.

64 share v2 - Allocate /64 as it does today and that would basically be
equivalent to a /48 allocation. Nice!

*/80 = New bottom => Problem solved *

*/64 = 64k /80s - wearable - so now both 3GPP and broadband  providers
problem solved for segmentation*

*/64 Current bottom*

*/48 = 64k /64s*

As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes
up to /80.  I think while we are changing RFC 4291 I think it would make
sense to allow for shorter prefixes maybe to any length or fix a a value
that makes sense for shorter then /64.  So in the future if 3GPP can be
updated for shorter prefixes we could give out shorter as well which would
be a ton of prefixes.

However, I think if we made the new bottom a /80, in reality the end site
allocation would be equivalent to a /48 so would not have to allow slaac
really to allow for shorter then /64.

Although as they say - never say never.."when you build - they will come"

SLAAC would use random IID generation schemes to generate the shorter 48
bit IID via RFC 4941 or stable IID RFC 7217.

>From a privacy perspective for broadband users we would still have 48 bit
IID which in the scheme of things as the double edged sword for operators &
law enforcement scanning I think the address correlation attacks I think
the 48 bits random IID for privacy extension, I think we would be in good
shape.

This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6
& slaac as now we can have longer prefixes up  to /80.

This may solve some of the aviation issues that Fred Templin is working on
as well.

Also with Network Slicing to be mainstream with 5G  and proliferation of
IoT devices I can see end user allocations growing very quickly

AND = "NO RACE TO BOTTOM" possible even  as we would fix the new boundary
at "/80" as the new bottom so you cannot race down any further. Would be no
different then the /64 boundary but now getting a 16 bit bonus out of the
deal.

IANA now does not have to dig into unallocating more ::/3s for larger
allocations - see Slide 10 from v6ops preso below

Slide 10 in v6 ops preso

One of the reasons why 6MAN has deferred removing the 64 bit boundary is
due to the  ISP “race to the bottom” fear that we are at the bottom giving
out /64 to mobile handsets that ISP’s will in theory do what history has
shown us what was done with IPv4 where due to address depletion issues and
issues with overlapping address space ISP’s made the broadband standard to
dole out /32 WAN IP which is NAT port overloaded outside wan interface.
NAT as well as CGNAT have solved issues with IPv4 shortage and overlapping
ranges allowing overlapping ranges to co-exist with NAT as well as now
ISP’s due to the risk of IPv4 address depletion made the standard a /32 WAN
IP with NAT port overloaded via PAT (Port Address translation) with private
192.168.1.0/24 subnet for SOHO hosts.

IPv6 on the other hand does not have any risk of address depletion so you
cannot compare what history has told us with IPv4 to IPv6 and there is no
other data point to be had.

On the other side of the spectrum with 64share we are looking now at
shorter prefixes and maybe an idea of creating and RFC 6177bis that allows
a /48 per human per mobile device.  Is that possible ???

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

2000::/3 GUI

IAIA <=>RIR <=> ISP <=> End user Allocation

RIR allocations to Service Providers:

For the massive block allocations for ISPs is it tiered like this

/32 - General Starting point for ISP allocation

/24-26 - Medium to Large

/19-20 - Exceptions and rare

Since allocations are done blockwize and not linearly you have to account
for future growth so generally over allocate for growth next 20 years.  So
with that the much larger allocations.

With that being said let's say for a typical large ISP /24 - that would
yield 16M /48s.  That still is small since most large ISPs like, we Verizon
we want to scale to a billion as right now we have 150M and that's just
domestic not worldwide.  Safe best for large ISPs is we want to scale to
the number of humans on the planet so 7 Billion is a good number.  Also
that does not account for broadband.  So for Verizon as an example /48  per
human is not possible.

I think /48 per user site is sensible for the much smaller ISPS with few
million subscriber base  but I think an impossibility at least for the
larger Verizon size ISP’s.  Looking on IAIA allocation link I don't see too
many RIRs getting a /12.

*https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
<https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>*

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Nov 2020 14:00:57 +0100

The right way to resolve this is very simple.

Go to your RIR (ARIN I guess) “ARIN I want to provide a /48 for each of my subscribers, so I need a subsequent allocation, following the section 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy Manual, and this is my justification …”.

Done!

https://www.arin.net/participate/policy/nrpm/#6-5-3-subsequent-allocations-to-lirs

Regards,

Jordi

@jordipalet

El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

v6ops preso - "race to bottom slide" slightly modified - new proposal for new /80 bottom so that we could actually make multiple /48s I mean /64s actually wearable.   

A /64 would be the new /48 as we shifted the IID by 16 bits shorter & making the prefix 16 bits longer.

/48 = 64k /64s - Due to current 3GPP architecture limitation we cannot dole out shorter prefixes via 64share v2 even that Cameron proposed.  Also with the RA PD style trickery w/o A bit set as Lorenzo mentioned the host would not accept the shorter prefix as it is expecting a 64 bit prefix from the 3GPP gateway.

1. Large providers such as Verizon subscribers = 150M not including broadband and /24 equates to 16M /48 way short and /20 even 160M but large providers as Verizon's of the world need to scale to 1B or 7B.

2. 64share v2 even if 3GPP arch allowed shorter prefixes /56 or even /48, RFC 4291 would have to change the 64 bit fixed boundary requirement for any handset to accept shorter prefix.  So we are stuck and 64 share v2 is not possible w/o RFC 4291 changing.

What if we made the new fixed bottom a /80 meaning.  So that would essentially be the new bottom that ISPs cannot race any further since the standard would be fixed at the new /80 bottom just as its fixed at the /64 bottom.  We just gave ourselves 16 bits to play with.

64 share v2 - Allocate /64 as it does today and that would basically be equivalent to a /48 allocation. Nice!

/80 = New bottom => Problem solved 

/64 = 64k /80s - wearable - so now both 3GPP and broadband  providers problem solved for segmentation

/64 Current bottom

/48 = 64k /64s

As far as SLAAC goes we would modify RFC 4291 to allow for longer prefixes up to /80.  I think while we are changing RFC 4291 I think it would make sense to allow for shorter prefixes maybe to any length or fix a a value that makes sense for shorter then /64.  So in the future if 3GPP can be updated for shorter prefixes we could give out shorter as well which would be a ton of prefixes.  

However, I think if we made the new bottom a /80, in reality the end site allocation would be equivalent to a /48 so would not have to allow slaac really to allow for shorter then /64.  

SLAAC would use random IID generation schemes to generate the shorter 48 bit IID via RFC 4941 or stable IID RFC 7217.

>From a privacy perspective for broadband users we would still have 48 bit IID which in the scheme of things as the double edged sword for operators & law enforcement scanning I think the address correlation attacks I think the 48 bits random IID for privacy extension, I think we would be in good shape. 

This also solves the day 1 VLSM issue as well for mixed host static, dhcpv6 & slaac as now we can have longer prefixes up  to /80.   

This may solve some of the aviation issues that Fred Templin is working on as well.  

Also with Network Slicing to be mainstream with 5G  and proliferation of IoT devices I can see end user allocations growing very quickly

AND = "NO RACE TO BOTTOM" possible even  as we would fix the new boundary at "/80" as the new bottom so you cannot race down any further. Would be no different then the /64 boundary but now getting a 16 bit bonus out of the deal. 

IANA now does not have to dig into unallocating more ::/3s for larger allocations - see Slide 10 from v6ops preso below

Slide 10 in v6 ops preso

One of the reasons why 6MAN has deferred removing the 64 bit boundary is due to the  ISP “race to the bottom” fear that we are at the bottom giving out /64 to mobile handsets that ISP’s will in theory do what history has shown us what was done with IPv4 where due to address depletion issues and issues with overlapping address space ISP’s made the broadband standard to dole out /32 WAN IP which is NAT port overloaded outside wan interface.  NAT as well as CGNAT have solved issues with IPv4 shortage and overlapping ranges allowing overlapping ranges to co-exist with NAT as well as now ISP’s due to the risk of IPv4 address depletion made the standard a /32 WAN IP with NAT port overloaded via PAT (Port Address translation) with private 192.168.1.0/24 subnet for SOHO hosts.  

IPv6 on the other hand does not have any risk of address depletion so you cannot compare what history has told us with IPv4 to IPv6 and there is no other data point to be had. 

On the other side of the spectrum with 64share we are looking now at shorter prefixes and maybe an idea of creating and RFC 6177bis that allows a /48 per human per mobile device.  Is that possible ??? 

2000::/3 GUI 

/24-26 - Medium to Large 

Since allocations are done blockwize and not linearly you have to account for future growth so generally over allocate for growth next 20 years.  So with that the much larger allocations.

With that being said let's say for a typical large ISP /24 - that would yield 16M /48s.  That still is small since most large ISPs like, we Verizon we want to scale to a billion as right now we have 150M and that's just domestic not worldwide.  Safe best for large ISPs is we want to scale to the number of humans on the planet so 7 Billion is a good number.  Also that does not account for broadband.  So for Verizon as an example /48  per human is not possible. 

I think /48 per user site is sensible for the much smaller ISPS with few million subscriber base  but I think an impossibility at least for the larger Verizon size ISP’s.  Looking on IAIA allocation link I don't see too many RIRs getting a /12.

https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops 

**********************************************
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: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 08:38:36 -0500

Thanks Jordi!

That solves one problem but does not solve the 64share v2 issue as we have
to still modify
RFC 4861 for mobile to accept shorter prefix.

Thanks

Gyan

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Go to your RIR (ARIN I guess) “ARIN I want to provide a /48 for each of my
> subscribers, so I need a subsequent allocation, following the section
> 6.5.3. (Subsequent Allocation to LIRs) of the Number Resource Policy
> Manual, and this is my justification …”.
>
>
>
> Done!
>
>
>
>
> El 19/11/20 13:26, "v6ops en nombre de Gyan Mishra" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>
>
> /48 = 64k /64s - Due to current 3GPP architecture limitation we cannot
> dole out shorter prefixes via 64share v2 even that Cameron proposed.  Also
> with the RA PD style trickery w/o A bit set as Lorenzo mentioned the host
> would not accept the shorter prefix as it is expecting a 64 bit prefix from
> the 3GPP gateway.
>
>
>
> This also solves the day 1 VLSM issue as well for mixed host static,
> dhcpv6 & slaac as now we can have longer prefixes up  to /80.
>
>
>
> larger Verizon size ISP’s.  Looking on IAIA allocation link I don't see
> too many RIRs getting a /12.
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g> *Silver
> Spring, MD
> <https://www.google.com/maps/search/13101+Columbia+Pike+Silver+Spring,+MD?entry=gmail&source=g>
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> 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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

*Gyan Mishra*

---

From: [email-masked]
Date: Thu, 19 Nov 2020 14:51:41 +0100

> That solves one problem but does not solve the 64share v2 issue as we have to still modify 

As Lorenzo explained during the meeting reusing the PIO isn't going to work.

You would need a new option. It would likely be useful for the requesting router to indicate interest in the option. Even hinting at what prefix size it was expecting.
Now can you explain to me again the reasons why this approach is better than using the existing DHPCv6 protocol packets?

Best regards,
Ole

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 08:58:33 -0500

> As Lorenzo explained during the meeting reusing the PIO isn't going to

   Gyan> Understood.  Lorenzo made a key point which is why I am bringing
up that we would need a new option as we defined in the variable slaac
solutions draft.

>
>
> You would need a new option. It would likely be useful for the requesting
> router to indicate interest in the option. Even hinting at what prefix size
> it was expecting.
> Now can you explain to me again the reasons why this approach is better
> than using the existing DHPCv6 protocol packets?

    3GPP gateway does not support DHCPv6

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 09:13:50 -0500

Jordi

I am not sure if all RIRs for example ARIN if it or others are as liberal
as RIPE.

Gyan

On Thu, Nov 19, 2020 at 8:38 AM Gyan Mishra <[email-masked]> wrote:

>> Go to your RIR (ARIN I guess) “ARIN I want to provide a /48 for each of
>> my subscribers, so I need a subsequent allocation, following the section
>> As far as SLAAC goes we would modify RFC 4291 to allow for longer
>> prefixes up to /80.  I think while we are changing RFC 4291 I think it
>> would make sense to allow for shorter prefixes maybe to any length or fix a
>> a value that makes sense for shorter then /64.  So in the future if 3GPP
>> can be updated for shorter prefixes we could give out shorter as well which
>> would be a ton of prefixes.
>>

*Gyan Mishra*

---

From: Gert Doering <[email-masked]>
Date: Thu, 19 Nov 2020 15:16:33 +0100

Hi,

>     3GPP gateway does not support DHCPv6

Why can this not be changed?

A few 3GPP gateways vs. "billions of phones"?

(Especially since 3G standards seems to already include DHCPv6)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 Nov 2020 15:26:32 +0100

Le 19/11/2020 à 14:51, [email-masked] a écrit :
>> That solves one problem but does not solve the 64share v2 issue as
>> we have to still modify RFC 4861 for mobile to accept shorter
>> prefix.
> 
> You would need a new option. It would likely be useful for the
> requesting router to indicate interest in the option. Even hinting at
> what prefix size it was expecting.

Ole,

Are you referring to Lorenzo's explanation in order to suggest the use
of a new option in order to explain that DHCPv6-PD could be such an option?

Or are you suggesting a new option in order to explain that a new option
in RA, like a bit flag, might be appropriate?

Do you think that an operator might be interested in implementing a new
option in RA at the 3GPP gateway? (I am asking because an operator said
'no' to that question, and another operator said they'd prefer to just
modify a parm in conf file - 64share-V2; maybe you see that differently).

For information, a maintainer of stack implementation in linux kernel
asks what is the level of 'IETF consensus' of the proposed new option in
RA to kernel implementation.    This is an Individual Submission.  And I
dont know how to move forward.

Alex

> Now can you explain to me again the reasons why this approach is
> better than using the existing DHPCv6 protocol packets?
> 
> Best regards, Ole 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Nov 2020 15:55:18 +0100

Every RIR has their own policies, but in general they match very closely (I tried very hard doing that thru policy proposals when it was making sense, and this was the case for IPv6 initial and subsequent allocations).

As explained a few emails ago … in general I will say that you only have a problem in LACNIC and AFRINIC if you don’t have your services there, or at least the majority of those services.

Regards,

Jordi

@jordipalet

El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

Jordi

I am not sure if all RIRs for example ARIN if it or others are as liberal as RIPE.

Gyan

Thanks Jordi!

Thanks 

Gyan

On Thu, Nov 19, 2020 at 8:01 AM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Done!

Regards,

Jordi

@jordipalet

/64 Current bottom

/48 = 64k /64s

Slide 10 in v6 ops preso

2000::/3 GUI 

/24-26 - Medium to Large 

 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Nov 2020 15:57:01 +0100

Exactly!

Blame vendors that did a bad job, not IETF or RIRs. Vendors should follow standards, and if they not, pay for the consequences. Standards should not be "adapted" to vendors.

Regards,
Jordi
@jordipalet

El 19/11/20 15:19, "ipv6 en nombre de Gert Doering" <[email-masked] en nombre de [email-masked]> escribió:

    Hi,

    Gert Doering
            -- NetMaster

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 10:11:20 -0500

Thanks Jordi!

On Thu, Nov 19, 2020 at 9:55 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Every RIR has their own policies, but in general they match very closely
> (I tried very hard doing that thru policy proposals when it was making
> sense, and this was the case for IPv6 initial and subsequent allocations).
>
>
>
> As explained a few emails ago … in general I will say that you only have a
> problem in LACNIC and AFRINIC if you don’t have your services there, or at
> least the majority of those services.
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 19/11/20 15:16, "v6ops en nombre de Gyan Mishra" <
-- 

*Gyan Mishra*

---

From: [email-masked]
Date: Thu, 19 Nov 2020 16:33:21 +0100

> On 19 Nov 2020, at 14:58, Gyan Mishra <[email-masked]> wrote:
> 

3GPP gateway doesn't support new option. What's your point?

Ole

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 19 Nov 2020 17:03:05 -0500

On Thu, Nov 19, 2020 at 10:33 AM <[email-masked]> wrote:

> requesting router to indicate interest in the option. Even hinting at what
> prefix size it was expecting.

    The point of the v6ops presentation and this email thread is how to
“extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled a
list of options and of the two I had highlighted in red were the 64share v2
Cameron’s option and the variable slaac option.  So on the call this
morning Lorenzo shot down 64share v2 shorter prefix option as even if the
3GPP architecture was updated to support longer prefixes and even is the
3GPP gateway was able to send a shorter prefix with A flag not set, all
mobile devices per Lorenzo’s point would be broken as they would not accept
the shorter let’s say /56 prefix to build the slaac 128 bit address.  So
the bottom line is the 64share v2 won’t work unless we update RFC 4291 and
remove the 64 bit boundary.

 So we are back to square uno - no viable solution

 So now we had thrown out the longer >64 due to race to bottom worries
which I and others believe is Fud and as described in slide 10 of the v6ops
“race to the bottom slide”.

So a happy medium /80 fixed boundary I came up with that I think solves a
lot of the issue and not just the 3GPP initial segmentation of downstream
devices problem statement.

Since we have to update RFC 4291 for 64share v2 to work anyways to allow
for shorter prefixes, why not instead create a new bottom at /80 giving 16
bits more of prefix length and shrinking the IID down to 48 bits.  Doing so
you would not even have to update the 3GPP architecture as I don’t know if
that would fly or not.  Also this solves a few other problems at the same
time.

As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mainstream
for operators for static addressing on router and switch infrastructure and
dhcpv6 subnets longer prefixes for network infrastructure appliance
clusters, NFV/VNF virtualization and server farms.  On host subnets where
there is a chance of mix of slaac hosts with dhcpv6  devices the prefix
length is stuck at /64.  So on these mix addressing host subnets we cannot
do longer prefixes following our ND cache hard limit mantra to prevent ND
cache exhaustion issues as described in RFC 6164.

So with the /80 new fixed boundary shifting prefix length 16 bits longer
and shortening the IID by 16 bits gives resolved the 3GPP issue which
64share can work as is and subtending to downstream devices will now work
as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 for
broadband not all operators have adopted the shorter prefix lengths /56 or
/48 recommendations  and now that’s not an issue as the /64 would now
suffice.

>From an operators perspective that gain allows at least for 3GPP massive
growth and subtending with a single /64 allows the operators such as
Verizon with massive subscriber base worldwide can stay with current
allocations and don’t have to ask for /10.

As 5G gets rolled out with Enhanced VPN framework and Network slicing
paradigm, the demand for shorter blocks and wearable multiple /48 will be
our new reality.

Making that 16 bit shift now to /80 making a /64 the new /48 will give
broadband and 3GPP subscribers a ton of space to subtending their networks
we would be set for the future.  Especially with IOT the demand for
subtending will continue to grow astronomically.

Also IANA does not have to get start in allocating the other /3 and other
available blocks.

Lots of problems being solved here with a fixed /80 new boundary.

Also with the existing random IID generation schemes which we have tested
on Linux kernel can do longer prefixes using RFC 4941 privacy extension or
RFC 7217 stable IID.

Win-Win for all.

Ole

-- 

*Gyan Mishra*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Nov 2020 17:13:59 -0500

I am missing something in your reasoning.
You seem to say at one point that (to paraphrase) "we can't do this 
because it does not work with the existing UE software".
Any new solution where a UE delegates based on any change of any kind 
(including lengthening the prefix, shortening the prefix, or magically 
incanting new prefixes) requires that the UE be upgraded to know what to 
do with the information.  I do not see how that differentiates any of 
the solutions. (Except "don't do anything", which I think we do not want 
to take.)

Yours,
Joel

On 11/19/2020 5:03 PM, Gyan Mishra wrote:
> 
> 
> On Thu, Nov 19, 2020 at 10:33 AM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>      > On 19 Nov 2020, at 14:58, Gyan Mishra <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>     requesting router to indicate interest in the option. Even hinting
>     at what prefix size it was expecting.
> “extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled 
> a list of options and of the two I had highlighted in red were the 
> 64share v2 Cameron’s option and the variable slaac option.  So on the 
> call this morning Lorenzo shot down 64share v2 shorter prefix option as 
> even if the 3GPP architecture was updated to support longer prefixes and 
> even is the 3GPP gateway was able to send a shorter prefix with A flag 
> not set, all mobile devices per Lorenzo’s point would be broken as they 
> would not accept the shorter let’s say /56 prefix to build the slaac 128 
> bit address.  So the bottom line is the 64share v2 won’t work unless we 
> update RFC 4291 and remove the 64 bit boundary.
> 
> which I and others believe is Fud and as described in slide 10 of the 
> v6ops “race to the bottom slide”.
> 
> So a happy medium /80 fixed boundary I came up with that I think solves 
> a lot of the issue and not just the 3GPP initial segmentation of 
> downstream devices problem statement.
> 
> for shorter prefixes, why not instead create a new bottom at /80 giving 
> 16 bits more of prefix length and shrinking the IID down to 48 bits.  
> Doing so you would not even have to update the 3GPP architecture as I 
> don’t know if that would fly or not.  Also this solves a few other 
> problems at the same time.
> 
> 
> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is 
> mainstream for operators for static addressing on router and switch 
> infrastructure and dhcpv6 subnets longer prefixes for network 
> infrastructure appliance clusters, NFV/VNF virtualization and server 
> farms.  On host subnets where there is a chance of mix of slaac hosts 
> with dhcpv6  devices the prefix length is stuck at /64.  So on these mix 
> addressing host subnets we cannot do longer prefixes following our ND 
> cache hard limit mantra to prevent ND cache exhaustion issues as 
> described in RFC 6164.
> 
> 64share can work as is and subtending to downstream devices will now 
> work as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 
> for broadband not all operators have adopted the shorter prefix lengths 
> /56 or /48 recommendations  and now that’s not an issue as the /64 would 
> now suffice.
> 
>  From an operators perspective that gain allows at least for 3GPP 
> massive growth and subtending with a single /64 allows the operators 
> such as Verizon with massive subscriber base worldwide can stay with 
> current allocations and don’t have to ask for /10.
> 
> paradigm, the demand for shorter blocks and wearable multiple /48 will 
> be our new reality.
> 
> broadband and 3GPP subscribers a ton of space to subtending their 
> networks we would be set for the future.  Especially with IOT the demand 
> for subtending will continue to grow astronomically.
> 
> Also IANA does not have to get start in allocating the other /3 and 
> other available blocks.
> 
> Also with the existing random IID generation schemes which we have 
> tested on Linux kernel can do longer prefixes using RFC 4941 privacy 
> extension or RFC 7217 stable IID.
> 
> Win-Win for all.
> 
>     Ole
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347
> 13101 Columbia Pike
> /Silver Spring, MD
> 
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Nov 2020 11:49:56 +1300

And if we had left the boundary at /80, as it was in 1995 (RFC1884), would you now be arguing for /96, since in that case 3GPP would have settled on /80?

Sorry, but this is exactly and precisely a 16-bit jump in the race to the bottom. And it breaks all existing SLAAC hosts on the way.

The problem here is caused by 3GPP, but a solution like Cameron's should work for everybody with minimal changes.

Regards
   Brian

On 20-Nov-20 11:03, Gyan Mishra wrote:
> 
> 
> On Thu, Nov 19, 2020 at 10:33 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     > On 19 Nov 2020, at 14:58, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     The point of the v6ops presentation and this email thread is how to “extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled a list of options and of the two I had highlighted in red were the 64share v2 Cameron’s option and the variable slaac option.  So on the call this morning Lorenzo shot down 64share v2 shorter prefix option as even if the 3GPP architecture was updated to support longer prefixes and even is the 3GPP gateway was able to send a shorter prefix with A flag not set, all mobile devices per Lorenzo’s point would be broken as they would not accept the shorter let’s say /56 prefix to build the slaac 128 bit address.  So the bottom line is the 64share v2 won’t work unless we update RFC 4291 and remove the 64 bit boundary.
> 
>  So now we had thrown out the longer >64 due to race to bottom worries which I and others believe is Fud and as described in slide 10 of the v6ops “race to the bottom slide”.  
> 
> So a happy medium /80 fixed boundary I came up with that I think solves a lot of the issue and not just the 3GPP initial segmentation of downstream devices problem statement.
> 
> Since we have to update RFC 4291 for 64share v2 to work anyways to allow for shorter prefixes, why not instead create a new bottom at /80 giving 16 bits more of prefix length and shrinking the IID down to 48 bits.  Doing so you would not even have to update the 3GPP architecture as I don’t know if that would fly or not.  Also this solves a few other problems at the same time.
> 
> 
> As I mentioned in the v6ops deck presented that vlsm 0 to 128 is mainstream for operators for static addressing on router and switch infrastructure and dhcpv6 subnets longer prefixes for network infrastructure appliance clusters, NFV/VNF virtualization and server farms.  On host subnets where there is a chance of mix of slaac hosts with dhcpv6  devices the prefix length is stuck at /64.  So on these mix addressing host subnets we cannot do longer prefixes following our ND cache hard limit mantra to prevent ND cache exhaustion issues as described in RFC 6164.
> 
> So with the /80 new fixed boundary shifting prefix length 16 bits longer and shortening the IID by 16 bits gives resolved the 3GPP issue which 64share can work as is and subtending to downstream devices will now work as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 for broadband not all operators have adopted the shorter prefix lengths /56 or /48 recommendations  and now that’s not an issue as the /64 would now suffice.
> 
> From an operators perspective that gain allows at least for 3GPP massive growth and subtending with a single /64 allows the operators such as Verizon with massive subscriber base worldwide can stay with current allocations and don’t have to ask for /10.  
> 
> As 5G gets rolled out with Enhanced VPN framework and Network slicing paradigm, the demand for shorter blocks and wearable multiple /48 will be our new reality.  
> 
> Making that 16 bit shift now to /80 making a /64 the new /48 will give broadband and 3GPP subscribers a ton of space to subtending their networks we would be set for the future.  Especially with IOT the demand for subtending will continue to grow astronomically.
> 
> Also IANA does not have to get start in allocating the other /3 and other available blocks.
> 
> Also with the existing random IID generation schemes which we have tested on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC 7217 stable IID.
> 
> Win-Win for all.
> 
>     Ole
> 
> -- 
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 19 Nov 2020 15:02:28 -0800

Brian,

> On Nov 19, 2020, at 2:49 PM, Brian E Carpenter <[email-masked]> wrote:
> 

+100

Either something like Cameron’s draft or a very minimal DHCPv6 PD implementation that can run in a 3GPP environment.   It doesn’t need to be a full DHCPv6 server.

Bob

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 17:27:13 -0500

(top posting)

As I would like to clear the air as well as get to the crux of the v6ops
presentation development results as well as next steps for this draft and
the 6man variable slaac solutions draft:

This thread was in light of Lorenzo kindly pointing out that upgrading 3GPP
is not all that needs be done for Cameron’s 64share v2 to work - as all
mobile devices would stop working- as slaac would not would be effectively
broken.

The mobile device would receive a shorter prefix let’s say /56 but not know
what to do with it since it’s expecting a /64.

So that a major gap and the only solution is updating RFC 4291 removing the
64 bit boundary allowing for shorter prefix and now as well longer prefixes
to work and in that respect now provide the much needed parity with static
and DHCPv6 which can do any prefix length.

So that is a drastic change to RFC 4291.  However, in light of this
development on the v6ops 109 call, my balancing act of best of both worlds
and also to keep everyone happy to make this a WG effort for this change by
proposing in the subject heading /80 fixed boundary and not a variable
slaac change allowing all bits vlsm.

Basically stealing 16 bits for network prefix out of the IID, still keeping
the fixed boundary so longer than 80 would NOT  be allowed.

A /64 would now be equivalent to a /48 with now 64k /80’s.

This /80 would keep the operators and law enforcement happy as now 16 bits
less helps traceability but is still long enough for 48 bits of privacy to
IP correlation by attackers.

This /80 would be a nice optimal balance as it would keep wired broadband
and mobile handset customers happy respecting their privacy as the 16 bits
less of heuristics is minimal change that will impact IP correlation by
attackers.

The IID as it’s less than the current 64 bit cannot use MAC based EUI64
IID, which is not a problem as Mac based IID is not recommended as most all
manufacturers use RFC 4941 and I believe Linux flavors some use stable IID
RFC 7217.

So now the 48 bit IID would require a random IID generation schema so can
use either RFC 4941 privacy extension or RFC 7217 stable IID to generate
the 48 bit IID.

3GPP subtending would now work issue mentioned in the problem statement
draft without even having to use 64share as now longer prefixes up to /80
would be supported allowing for further segmentation of downstream devices.

This also would help wired broadband and soon fixed 5G broadband
proliferation where operators in light of BCP RIPE-690, are sill allocation
via BNG gateways a /64, now operators  can stay as-is, as the /64 would now
be allowed to be further segmented supporting 64k /80s, way more then
enough for SOHO.

This would allow 64share if used by 3GPP operators to work and would not
require the 3GPP specification to be updated.  We don’t know even if the
3GPP architecture specification can be updated to support shorter prefixes
and if the 3GPP consortium of operators would agree to it.  So that is all
theoretical of that change is possible.

As with 5G with Enhanced VPN framework SR steering of high priority
traffic, traffic isolation and Network slicing capabilities becomes
mainstream and will soon be a real world reality and as fixed 5G broadband
proliferation takes off and mobile 5G == the idea of a wearable /48 will
really be many /48s.

As this paradigm shift takes place, operators around the world will be
clamoring after the RIR for massive blocks, I would say less than /8 more
like a /5 or /4.  If you do the math on the way high side a /10 yields 7
bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is tiny number
with the number of large size operators worldwide.

With the massive proliferation of IOT devices and just about every home or
office appliance on 5G, the problem now gets way exacerbated.

As this evolution unfolds IANA will be scrambling to release all remaining
/3 as well as all unallocated blocks to subvert RIR IPv6 address space
depletion.

Playing Monday night quarterbacking in hindsight we would never think this
would happen in a million years, but we would see IPv6 on the verge of
address space depletion.  Unheard of but it can happen as the saying goes
“when you build - they will come”.

It is true as history has taught that very important lesson.

The answer to this real world problem is in the subject heading of this
thread.

This would also fix the day 1 issue I mentioned allowing mix of slaac
devices with static and DHCPv6 up to /80.

The variable slaac solution draft proposes a new  RA PIO flag that would be
used to signal longer prefixes, and would provide backwards compatibility
so that devices not supporting woud ignore the flag  and devices on newer
code supporting would use the flag.  We definitely don’t want to impact any
existing devices on the existing 64 bit slaac boundary standard.

Dmytro has tested the solution on Linux kernel signaling RA PIO flag and
was able to successfully test any length mask and random IID generation
both RFC 4941 privacy extension as well as stable IID RFC 7217.

https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/

If everyone is in agreement with what I have stated on this thread, I would
like to ask the chairs for WG adoption as this is a WG effort.

I would like to garner support from all 6MAN members with full consensus to
change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary.

Kind Regards

Gyan

On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <[email-masked]> wrote:

> > tested on Linux kernel can do longer p
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>refixes
> using RFC 4941 privacy
-- 

*Gyan Mishra*

---

From: Ole Troan <[email-masked]>
Date: Fri, 20 Nov 2020 23:41:06 +0100

> On 20 Nov 2020, at 23:27, Gyan Mishra <[email-masked]> wrote:
> 
> The mobile device would receive a shorter prefix let’s say /56 but not know what to do with it since it’s expecting a /64.
> 
> So that a major gap and the only solution is updating RFC 4291 removing the 64 bit boundary allowing for shorter prefix and now as well longer prefixes to work and in that respect now provide the much needed parity with static and DHCPv6 which can do any prefix length.

I am sorry, but I don’t follow how you got to that conclusion. 
Address assignment != prefix delegation. 

In the plethora of emails I have lost track. Would you be able to reiterate the sets of technical problems you desire solved?

Cheers,
Ole

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 Nov 2020 18:02:41 -0500

Gyan, separate from Ole's comments about the difference between address 
assignment and delegation, I have another problem following the 
reasoning below.

Yes, the proposal for using shorter prefixes to enable UE to perform 
delegation will require changes to the UE.
But I do not see how that is relevant to any choice we are trying to make.
Any solution that enables UE to delegate addresses (in the sense that 
they lack the capability now) willr equire changes to the UE.  Yoru 
proposed change to the SLAAC length if anything does more violence to 
the software (depending upon the exact software architecture.)

So I do not follow how you got to your conclusion.

Yours,
Joel

On 11/20/2020 5:27 PM, Gyan Mishra wrote:
> presentation development results as well as next steps for this draft 
> and the 6man variable slaac solutions draft:
> 
> 
> This thread was in light of Lorenzo kindly pointing out that upgrading 
> 3GPP is not all that needs be done for Cameron’s 64share v2 to work - as 
> all mobile devices would stop working- as slaac would not would be 
> effectively broken.
> 
> The mobile device would receive a shorter prefix let’s say /56 but not 
> know what to do with it since it’s expecting a /64.
> 
> So that a major gap and the only solution is updating RFC 4291 removing 
> the 64 bit boundary allowing for shorter prefix and now as well longer 
> prefixes to work and in that respect now provide the much needed parity 
> with static and DHCPv6 which can do any prefix length.
> 
> development on the v6ops 109 call, my balancing act of best of both 
> worlds and also to keep everyone happy to make this a WG effort for this 
> change by proposing in the subject heading /80 fixed boundary and not a 
> variable slaac change allowing all bits vlsm.
> 
> Basically stealing 16 bits for network prefix out of the IID, still 
> keeping the fixed boundary so longer than 80 would NOT  be allowed.
> 
> This /80 would keep the operators and law enforcement happy as now 16 
> bits less helps traceability but is still long enough for 48 bits of 
> privacy to IP correlation by attackers.
> 
> This /80 would be a nice optimal balance as it would keep wired 
> broadband and mobile handset customers happy respecting their privacy as 
> the 16 bits less of heuristics is minimal change that will impact IP 
> correlation by attackers.
> 
> IID, which is not a problem as Mac based IID is not recommended as most 
> all manufacturers use RFC 4941 and I believe Linux flavors some use 
> stable IID RFC 7217.
> 
> So now the 48 bit IID would require a random IID generation schema so 
> can use either RFC 4941 privacy extension or RFC 7217 stable IID to 
> generate the 48 bit IID.
> 
> draft without even having to use 64share as now longer prefixes up to 
> /80 would be supported allowing for further segmentation of downstream 
> devices.
> 
> proliferation where operators in light of BCP RIPE-690, are sill 
> allocation via BNG gateways a /64, now operators  can stay as-is, as the 
> /64 would now be allowed to be further segmented supporting 64k /80s, 
> way more then enough for SOHO.
> 
> 3GPP architecture specification can be updated to support shorter 
> prefixes and if the 3GPP consortium of operators would agree to it.  So 
> that is all theoretical of that change is possible.
> 
> mainstream and will soon be a real world reality and as fixed 5G 
> broadband proliferation takes off and mobile 5G == the idea of a 
> wearable /48 will really be many /48s.
> 
> clamoring after the RIR for massive blocks, I would say less than /8 
> more like a /5 or /4.  If you do the math on the way high side a /10 
> yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR which is 
> tiny number with the number of large size operators worldwide.
> 
> With the massive proliferation of IOT devices and just about every home 
> or office appliance on 5G, the problem now gets way exacerbated.
> 
> As this evolution unfolds IANA will be scrambling to release all 
> remaining /3 as well as all unallocated blocks to subvert RIR IPv6 
> address space depletion.
> 
> Playing Monday night quarterbacking in hindsight we would never think 
> this would happen in a million years, but we would see IPv6 on the verge 
> of address space depletion.  Unheard of but it can happen as the saying 
> goes “when you build - they will come”.
> 
> The variable slaac solution draft proposes a new  RA PIO flag that would 
> be used to signal longer prefixes, and would provide backwards 
> compatibility so that devices not supporting woud ignore the flag  and 
> devices on newer code supporting would use the flag.  We definitely 
> don’t want to impact any existing devices on the existing 64 bit slaac 
> boundary standard.
> 
> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
> 
> If everyone is in agreement with what I have stated on this thread, I 
> would like to ask the chairs for WG adoption as this is a WG effort.
> 
> I would like to garner support from all 6MAN members with full consensus 
> to change the existing RFC 4941 /64 fixed boundary to /80 fixed boundary.
> 
> Kind Regards
> 
> Gyan
> 
> On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >
>      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
>     <[email-masked] <mailto:[email-masked]>
>      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >      >
>      >      > You would need a new option. It would likely be useful for the
>      >      > Now can you explain to me again the reasons why this
>     approach is
>      >      >
>      >      >     3GPP gateway does not support DHCPv6
>      >
>      > <http://www.verizon.com/ <http://www.verizon.com/>>
>      >
>      > *Gyan Mishra*
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>      >
> 
> -- 
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 19:36:23 -0500

Ole

In-line

> Address assignment != prefix delegation.

    3GPP Gateway does not support PD

    I summarized in the last email.

   We can start with the subject line that you had in the email you had
sent a earlier “extending a /64” as that is the main issue and is part of
the problem statement draft.

This is in the context of 3GPP gateway proving a via RA a /64 so how can
the UE segment the /64 to downstream devices.

3GPP gateway does not support PD and can only send a /64.

We can extend a single /64 via PD RA 64share technique but the UE need more
then a /64 for downstream devices since a /64 cannot be segmented.

Even if we were able to get 3GPP architecture to send shorter prefix, we
would still need mobile devices to accept /56 via RA since PD is not
supported.

So this would require updating RFC 4291 removing the 64 bit boundary so
that slaac shorter prefix will work.

>
>
> In the plethora of emails I have lost track. Would you be able to
> reiterate the sets of technical problems you desire solved?
>
> Cheers,
> Ole

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 20 Nov 2020 19:58:52 -0500

Hi Joel

In-line

> delegation will require changes to the UE.

    Gyan> Agreed.  So that change would be to RFC 4291 64 bit boundary to
allow for longer prefix.  Do you agree?

If you don’t agree what do think the change would be to allow the UE to
accept shorter prefix from the 3GPP gateway?

> they lack the capability now) willr equire changes to the UE.

Gyan> If the UE receives a /56 via RA it could delegate /64 to downstream
> devices.  No change needed to delegate  /64, however a change is needed to
> accept /56 via RA.

    If 3GPP gateway supported PD - problem solved but that’s not the case
and that does not sound like it will ever change even with 5G.

   Gyan> The UE needs to be able to accept shorter prefix.  That’s the IPV6
specification change that requires removal of the 64 bit boundary.

Yoru
> the software (depending upon the exact software architecture.)

   Gyan> What violence to software.  There would be more violence to
software if we removed the 64 bit boundary and allowed slaac to support any
vlsm prefix lengths.

My /80 proposal would just shift the boundary 16 bits to /80.

Hosts on the same subnet with two different masks would not be on-net to
each other as on different subnets.  The router would be configured with
the two subnets /64 and /80 subnet to support the two device types.
The solution would be a simple RA PIO flag that is set and older hosts not
upgraded would be backwards compatible and so would only support 64 bit
boundary by ignoring flag. Hosts upgraded to support would understand the
flag and be able to support longer mask up to /80.

> >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
> >      > current allocations and don’t have to ask
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g>
> for /10.
> >      >
> >     <
> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g
> >refixes
> >     using RFC 4941 privacy
-- 

*Gyan Mishra*

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 20 Nov 2020 20:46:14 -0500

The nesting got me lost, so I will top post my take on the answer to the 
one quesiton I could understand.

I believe you asked what I think would need to be changed to permit the 
delegation.
As with anything, the real things that need to change are the devices in 
the network.

With regard to IETF standards, what is proposed is a change to RA. 
There are several possible changes.  None of them require a change to 
the IPv6 addressing archtiecture, as the addressing structure remains as 
it is.
As for the exact mechanism, at the moment I lean towards Ole's proposal 
of using a new option in his generic option mechanism.  But I am not 
wedded to that answer.

And of course, to get this supported in mobile environments we will have 
to work with 3GPP and make sure there are no other hidden issues. 
That's the way we do things.  Work together.

Changing the prefix length to /80 is technically also possible.  It does 
a lot more violence to my understanding of the architecture and software 
structures that go with it, and is a very limited and narrow solution to 
the problem.

Yours,
Joel

On 11/20/2020 7:58 PM, Gyan Mishra wrote:
> Hi Joel
> 
> In-line
> 
> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <[email-masked] 
>      Gyan> Agreed.  So that change would be to RFC 4291 64 bit boundary 
> to allow for longer prefix.  Do you agree?
> 
>     Gyan> If the UE receives a /56 via RA it could delegate /64 to
>     downstream devices.  No change needed to delegate  /64, however a
>     change is needed to accept /56 via RA. 
> 
> 
>      If 3GPP gateway supported PD - problem solved but that’s not the 
> case and that does not sound like it will ever change even with 5G.
> 
>     Gyan> The UE needs to be able to accept shorter prefix.  That’s the 
> IPV6 specification change that requires removal of the 64 bit boundary.
> 
>     Yoru
> software if we removed the 64 bit boundary and allowed slaac to support 
> any vlsm prefix lengths.
> 
> The solution would be a simple RA PIO flag that is set and older hosts 
> not upgraded would be backwards compatible and so would only support 64 
> bit boundary by ignoring flag. Hosts upgraded to support would 
> understand the flag and be able to support longer mask up to /80.
> 
> 
> 
>     <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/
>     <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>
>      >
>      > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >
>      >     the solutions. (Except "don't do anything", which I think we
>     do not
>      >     want
>      >     to take.)
>      >
>      >     Yours,
>      >     Joel
>      >
>      >      > On Thu, Nov 19, 2020 at 10:33 AM <[email-masked]
>      >     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >      >
>      >      >
>      >      >
>      >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>>>> wrote:
>      >      >      >
>      >      >      > You would need a new option. It would likely be
>     useful for the
>      >      >     requesting router to indicate interest in the option. Even
>      >     hinting
>      >      >     at what prefix size it was expecting.
>      >      >      > Now can you explain to me again the reasons why this
>      >     approach is
>      >      >     better than using the existing DHPCv6 protocol packets?
>      >      >      >
>      >      >      >     3GPP gateway does not support DHCPv6
>      >      >
>      >      >     3GPP gateway doesn't support new option. What's your
>     point?
>      >      >
>      >      >
>      >      >
>      >      >      The point of the v6ops presentation and this email
>     thread is
>      >     how to
>      >      > “extend a /64” in the 3GPP use case  in slide 1 of the
>     deck you
>      >     compiled
>      >      > a list of options and of the two I had highlighted in red
>     were the
>      >      > 64share v2 Cameron’s option and the variable slaac
>     option.  So on
>      >     the
>      >      > call this morning Lorenzo shot down 64share v2 shorter prefix
>      >     option as
>      >      > even if the 3GPP architecture was updated to support longer
>      >     prefixes and
>      >      > even is the 3GPP gateway was able to send a shorter prefix
>     with A
>      >     flag
>      >      > not set, all mobile devices per Lorenzo’s point would be
>     broken
>      >     as they
>      >      > would not accept the shorter let’s say /56 prefix to build the
>      >     slaac 128
>      >      > bit address.  So the bottom line is the 64share v2 won’t work
>      >     unless we
>      >      > update RFC 4291 and remove the 64 bit boundary.
>      >      >
>      >      >   So we are back to square uno - no viable solution
>      >      >
>      >      >   So now we had thrown out the longer >64 due to race to
>     bottom
>      >     worries
>      >      > which I and others believe is Fud and as described in
>     slide 10 of
>      >     the
>      >      > v6ops “race to the bottom slide”.
>      >      >
>      >      > So a happy medium /80 fixed boundary I came up with that I
>     think
>      >     solves
>      >      > a lot of the issue and not just the 3GPP initial
>     segmentation of
>      >      > downstream devices problem statement.
>      >      >
>      >      > Since we have to update RFC 4291 for 64share v2 to work
>     anyways
>      >     to allow
>      >      > for shorter prefixes, why not instead create a new bottom
>     at /80
>      >     giving
>      >      > 16 bits more of prefix length and shrinking the IID down
>     to 48 bits.
>      >      > Doing so you would not even have to update the 3GPP
>     architecture
>      >     as I
>      >      > don’t know if that would fly or not.  Also this solves a
>     few other
>      >      > problems at the same time.
>      >      >
>      >      >
>      >      > As I mentioned in the v6ops deck presented that vlsm 0 to
>     128 is
>      >      > mainstream for operators for static addressing on router
>     and switch
>      >      > infrastructure and dhcpv6 subnets longer prefixes for network
>      >      > infrastructure appliance clusters, NFV/VNF virtualization
>     and server
>      >      > farms.  On host subnets where there is a chance of mix of
>     slaac
>      >     hosts
>      >      > with dhcpv6  devices the prefix length is stuck at /64.  So on
>      >     these mix
>      >      > addressing host subnets we cannot do longer prefixes following
>      >     our ND
>      >      > cache hard limit mantra to prevent ND cache exhaustion
>     issues as
>      >      > described in RFC 6164.
>      >      >
>      >      > So with the /80 new fixed boundary shifting prefix length
>     16 bits
>      >     longer
>      >      > and shortening the IID by 16 bits gives resolved the 3GPP
>     issue
>      >     which
>      >      > 64share can work as is and subtending to downstream
>     devices will now
>      >      > work as a /64 is now equivalent to a /48 with 64k /80s.  Also
>      >     BCP-690
>      >      > for broadband not all operators have adopted the shorter
>     prefix
>      >     lengths
>      >      > /56 or /48 recommendations  and now that’s not an issue as the
>      >     /64 would
>      >      > now suffice.
>      >      >
>      >      >  From an operators perspective that gain allows at least
>     for 3GPP
>      >      > massive growth and subtending with a single /64 allows the
>     operators
>      >      > such as Verizon with massive subscriber base worldwide can
>     stay with
>      >      > current allocations and don’t have to ask
>      >      > As 5G gets rolled out with Enhanced VPN framework and Network
>      >     slicing
>      >      > paradigm, the demand for shorter blocks and wearable
>     multiple /48
>      >     will
>      >      > be our new reality.
>      >      >
>      >      > Making that 16 bit shift now to /80 making a /64 the new
>     /48 will
>      >     give
>      >      > broadband and 3GPP subscribers a ton of space to
>     subtending their
>      >      > networks we would be set for the future.  Especially with
>     IOT the
>      >     demand
>      >      > for subtending will continue to grow astronomically.
>      >      >
>      >      > Also IANA does not have to get start in allocating the
>     other /3 and
>      >      > other available blocks.
>      >      >
>      >      > Lots of problems being solved here with a fixed /80 new
>     boundary.
>      >      >
>      >      > Also with the existing random IID generation schemes which
>     we have
>      >      > tested on Linux kernel can do longer p
>      >   
>       <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>>refixes
>      >     using RFC 4941 privacy
>      >      > extension or RFC 7217 stable IID.
>      >      >
>      >      > Win-Win for all.
>      >      >
>      >      >     Ole
>      >      >
>      >      > --
>      >      >
>      >      > <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
>      >      >
>      >      >
>      >      >
>      >      > _______________________________________________
>      >      > v6ops mailing list
>      >      > [email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >      > https://www.ietf.org/mailman/listinfo/v6ops
>      >     <https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>>
>      >      >
>      >
>      > --
>      >

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Nov 2020 16:00:13 +1300

Joel,

It seems to me that it's high time to draft a liaison statement to 3GPP,
observing that:

(1) There is a serious problem for the design and implementation of
5G-based IPv6 "hot spots" and CEs [which is where this conversation started];

(2) Although the best solution is not yet obvious, defining and
standardizing it will require a joint effort by the IETF and 3GPP.

Followed by a proposal to form an ad hoc joint design team.

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Nov 2020 15:19:36 +1100

> 5G-based IPv6 "hot spots" and CEs [which is where this conversation

I think it is also important to find out why they haven't deployed DHCPv6
to solve this problem.

Don't they think DHCPv6 infrastructure will scale? Is it just that they
don't know how to scale it?

Is it a vendor / mobile operator / handset developer DHCPv6
capability chicken-and-egg problem?

Is there an overriding business or industry reason?

The mobile industry has been resistant to tethering over the years, and
probably only came to begrudgingly accept it because they couldn't prevent
phone vendors from implementing Wifi and NAT, and couldn't very effectively
stop their customers from using that capability (One trick I've heard of to
prevent tethering working was to check if an IPv4 packet's TTL value was 64
when it arrived at the network, meaning it originated from the directly
attached handset. Packets from tethered devices had a TTL of 63 so were
dropped. Of course, you could set the default TTL on a tethered PC to 65 to
get around that.)

I guess there might be a fairly strong mindset that there must be a fee per
device attached to the network in addition to a fee for network
utilisation. Providing multiple /64s would be formally acknowledging that
multiple devices can be attached and a fee per device isn't and can't ever
be charged, counter to the mindset.

Regards,
Mark.

> >>      >     incanting new prefixes) requires that the UE be upgraded to
> know
> >>      >     what to
> >>      >      > <mailto:[email-masked] <mailto:[email-masked]
> >
> >>      >      >     requesting router to indicate interest in the option.
> Even
> >>      >     hinting
> >>      >      >      > Now can you explain to me again the reasons why
> this
> >>      >     approach is
> >>      >      >      The point of the v6ops presentation and this email
> >>     thread is
> >>      >     how to
> >>      >      > “extend a /64” in the 3GPP use case  in slide 1 of the
> >>     deck you
> >>      >     compiled
> >>      >      > 64share v2 Cameron’s option and the variable slaac
> >>     option.  So on
> >>      >     the
> >>      >      > call this morning Lorenzo shot down 64share v2 shorter
> prefix
> >>      >     option as
> >>      >      > even if the 3GPP architecture was updated to support
> longer
> >>      >     prefixes and
> >>      >      > even is the 3GPP gateway was able to send a shorter prefix
> >>     with A
> >>      >     flag
> >>      >      > not set, all mobile devices per Lorenzo’s point would be
> >>     broken
> >>      >     as they
> >>      >      > would not accept the shorter let’s say /56 prefix to
> build the
> >>      >     slaac 128
> >>      >      > bit address.  So the bottom line is the 64share v2 won’t
> work
> >>      >     unless we
> >>      >      >   So now we had thrown out the longer >64 due to race to
> >>     bottom
> >>      >     worries
> >>      >      > which I and others believe is Fud and as described in
> >>     slide 10 of
> >>      >     the
> >>      >      > So a happy medium /80 fixed boundary I came up with that I
> >>     think
> >>      >     solves
> >>      >      > Since we have to update RFC 4291 for 64share v2 to work
> >>     anyways
> >>      >     to allow
> >>      >      > for shorter prefixes, why not instead create a new bottom
> >>     at /80
> >>      >     giving
> >>      >      > Doing so you would not even have to update the 3GPP
> >>     architecture
> >>      >     as I
> >>      >      > farms.  On host subnets where there is a chance of mix of
> >>     slaac
> >>      >     hosts
> >>      >      > with dhcpv6  devices the prefix length is stuck at /64.
> So on
> >>      >     these mix
> >>      >      > addressing host subnets we cannot do longer prefixes
> following
> >>      >     our ND
> >>      >      > So with the /80 new fixed boundary shifting prefix length
> >>     16 bits
> >>      >     longer
> >>      >      > and shortening the IID by 16 bits gives resolved the 3GPP
> >>     issue
> >>      >     which
> >>      >      > work as a /64 is now equivalent to a /48 with 64k /80s.
> Also
> >>      >     BCP-690
> >>      >      > for broadband not all operators have adopted the shorter
> >>     prefix
> >>      >     lengths
> >>      >      > /56 or /48 recommendations  and now that’s not an issue
> as the
> >>      >     /64 would
> >>      >      > now suffice.
> >>      >      >
> https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g
> >
> >>     for /10.
> >>      >      >
> >>      >      > As 5G gets rolled out with Enhanced VPN framework and
> Network
> >>      >     slicing
> >>      >      > paradigm, the demand for shorter blocks and wearable
> >>     multiple /48
> >>      >     will
> >>      >      > be our new reality.
> >>      >      >
> >>      >      > Making that 16 bit shift now to /80 making a /64 the new
> >>     /48 will
> >>      >     give
> >>      >      > networks we would be set for the future.  Especially with
> >>     IOT the
> >>      >     demand
> >>      >      > <http://www.verizon.com/ <http://www.verizon.com/>

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Nov 2020 16:47:34 +1100

> the 6man variable slaac solutions draft:
You're asserting that everybody has accepted there is a problem to be
solved, and that everybody has accepted that the only way to solve it is to
change the default 64 bit IID size. This is both premature and not a
representation about "everybody's" opinion you can make.

I haven't accepted either of those things.

I'm not happy with the idea of changing away for 64 bit IIDs because I
don't think 64 bit IIDs are the problem. Plenty of operators have given out
/56s. I'm working at my second one. It is not impossible.

Many things below are incorrect, uninformed, or quite frankly ridiculous.
Some read like you've let your imagination go wild and then have just
assumed because you can imagine it it will then inevitably happen in the
near future.

For example, DHCPv6 does not provide a prefix length to hosts. Your
proposal does not make SLAAC "consistent' with what DHCPv6 does, because
DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA in
the DHCPv6 RFC).

"the idea of a wearable /48 will really be many /48s"? Do you really think
we're going to have more devices on our person that we'll need more than 65
536 /64 subnets (a single /48) to number them? That sounds like science
fiction to me for at least the next 200 years or more.

IPv6 isn't and isn't required to be the final and only Internet protocol
for the remainder of humanity, so we don't have to try to accommodate every
conceivable idea that somebody can come up with that might cause the 128
bit address space to be too small.

> devices on newer code supporting would use the flag.  We definitely don’t
> want to impact any existing devices on the existing 64 bit slaac boundary
> standard.
>

---

From: Ca By <[email-masked]>
Date: Fri, 20 Nov 2020 22:12:22 -0800

> don't know how to scale it?

Definitely do not know how. I had a look at the dhcpv6 rfc and it was over
150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr.

> capability chicken-and-egg problem?

I believe that exists too.

> Is there an overriding business or industry reason?

No. Just the usual nobody will come to the shop to pay for dhcpv6,  so it
is hard to
martial market demand. Major vendors (android) have vocally declined to
support dhcpv6. Other scenarios it is supported but default off.

> I guess there might be a fairly strong mindset that there must be a fee
> per device attached to the network in addition to a fee for network

I believe the sentiment on this list from operators has been trying to find
ways to make more effective ways to support more complete ipv6 networks
with the machinery we have.  I don’t think you have seen otherwise.

My own view is that i am trying to connect 10+M households, many rural,
with 5G broadband... and i feel it would be negligent to not support ipv6
in the most common home networking scenarios.

That said, my thinking has evolved.  And, i appreciate the living and
illuminating discussion.   i don’t think i need standards work at  this
point. I am i going to take a swing at making dhcpv6 work... not as
specified in that long rfc, but just taking the view of a dhcpv6-pd packet
as an api, which will simplify things.

This has been a helpful read
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-03

>> >>     But I do not see how that is relevant to any choice we are trying
>> to
>> >>     make.
>> >>      > change by proposing in the subject heading /80 fixed boundary
>> and
>> >>     not a
>> >>      > The IID as it’s less than the current 64 bit cannot use MAC
>> based
>> >>     EUI64
>> >>      > allocation via BNG gateways a /64, now operators  can stay
>> as-is,
>> >>     as the
>> >>      > require the 3GPP specification to be updated.  We don’t know
>> even
>> >>     if the
>> >>      > compatibility so that devices not supporting woud ignore the
>> flag
>> >>       and
>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>> >>      >
>> >>     <
>> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>
>> >>      >
>> >>      >      > <mailto:[email-masked] <mailto:
>> [email-masked]>
>> >>      >      >     requesting router to indicate interest in the
>> option. Even
>> >>      >     hinting
>> >>      >      > massive growth and subtending with a single /64 allows
>> the
>> >>     operators
>> >>      >      > such as Verizon with massive subscriber base worldwide
>> can
>> >>     stay with
>> >>      >      > Also with the existing random IID generation schemes
>> which
>> >>     we have
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>>
>> /Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>      >      >
>> >>      >      >
>> >>      >      >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>>
>> /Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>      >
>> >>      >
>> >>
>> >> --
>> >>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>>>
>> /Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>
>> >>
>> >

---

From: Gert Doering <[email-masked]>
Date: Sat, 21 Nov 2020 09:50:17 +0100

Hi,

>     3GPP Gateway does not support PD

I challenged that statement before, but that mail was ignored.

It's not there because it is impossible to do, but because vendors 
and operators had no interest in making it happen.

>From RFC 7066:

"Starting from Release-10, DHCPv6 Prefix Delegation was added as an
 optional feature to the 3GPP system architecture"

So - a standard compliant 3GPP Gateway could easily support DHCPv6 PD.

Gert Doering
        -- NetMaster

---

From: Ole Troan <[email-masked]>
Date: Sat, 21 Nov 2020 10:43:03 +0100

> On 21 Nov 2020, at 07:13, Ca By <[email-masked]> wrote:
> 
> That said, my thinking has evolved.  And, i appreciate the living and illuminating discussion.   i don’t think i need standards work at  this point. I am i going to take a swing at making dhcpv6 work... not as specified in that long rfc, but just taking the view of a dhcpv6-pd packet as an api, which will simplify things. 

Exactly. It’s just a simple two packet exchange. You don’t need much of the machinery. You do need some sort of database. But you got that. 

Cheers 
Ole

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 Nov 2020 22:24:17 +1100

On Sat, 21 Nov 2020, 17:12 Ca By, <[email-masked]> wrote:

>> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, <
>> [email-masked]> wrote:
>>
>>> Joel,
>>>

It is long. A lot of that is really about maintaining state synchronisation
between the client and the server, and that is for address state
synchronisation and dynamic allocation.

> support dhcpv6.

Specifically PD?

The objection to DHCPv6 support I've seen has been about not supporting
DHCPv6 for address assignment to the host itself.

PD is really router rather than host configuration. I sometimes wonder what
a "routing protocol" solution to PD would have looked like. For example,
perhaps OSPF or BGP extensions to support delegating prefixes to downstream
routers.

I think right now it is better to stay with using DHCPv6 PD because it
exists and has been successfully deployed. However I think the idea of
using RAs for PD would heading down that "routing protocol" solution path
to an extent.

Other scenarios it is supported but default off.
> I believe the sentiment on this list from operators has been trying to
> find ways to make more effective ways to support more complete ipv6
> networks with the machinery we have.  I don’t think you have seen
> otherwise.
>

The production wired residential deployment I worked in back in 2010 had a
DHCPv6 server on the BNG, not a relay, however that was fed subscriber
attributes via RADIUS. These days they would be RFC6911 RADIUS attributes
rather than vendor specific ones.

So the DHCPv6 server infrastructure scaling problem upsteam of the BNG gets
replaced by a RADIUS scaling one, which people may be more familiar with
solving and already have solved.

> https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-03
I think some or all of these problems might go away with the above DHCPv6
server/RADIUS model, because there is a lot more DHCPv6 session state
available on the first hop device.

Regards,
Mark.

>>> >>      > prefixes to work and in that respect now provide the much
>>> needed
>>> >>     parity
>>> >>      > of address space depletion.  Unheard of but it can happen as
>>> the
>>> >>     saying
>>> >>      > don’t want to impact any existing devices on the existing 64
>>> bit
>>> >>     slaac
>>> >>      > boundary standard.
>>> >>      >
>>> >>      >     Any new solution where a UE delegates based on any change
>>> of
>>> >>     any kind
>>> >>      >     (including lengthening the prefix, shortening the prefix,
>>> or
>>> >>     magically
>>> >>      >     incanting new prefixes) requires that the UE be upgraded
>>> to know
>>> >>      >     what to
>>> >>      >      > a list of options and of the two I had highlighted in
>>> red
>>> >>     were the
>>> >>      >      > bit address.  So the bottom line is the 64share v2
>>> won’t work
>>> >>      >     unless we
>>> >>      >      > As I mentioned in the v6ops deck presented that vlsm 0
>>> to
>>> >>     128 is
>>> >>      >      > infrastructure appliance clusters, NFV/VNF
>>> virtualization
>>> >>     and server
>>> >>      >      > with dhcpv6  devices the prefix length is stuck at
>>> /64.  So on
>>> >>      >     these mix
>>> >>      >      > work as a /64 is now equivalent to a /48 with 64k
>>> /80s.  Also
>>> >>      >     BCP-690

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 21 Nov 2020 14:57:04 +0100

Le 21/11/2020 à 06:47, Mark Smith a écrit :
> 
> 
> On Sat, 21 Nov 2020, 09:27 Gyan Mishra, <[email-masked] 
>     As I would like to clear the air as well as get to the crux of the
>     v6ops presentation development results as well as next steps for
>     this draft and the 6man variable slaac solutions draft:
> 
> 
> solved, and that everybody has accepted that the only way to solve it is 
> to change the default 64 bit IID size. This is both premature and not a 
> don't think 64 bit IIDs are the problem. Plenty of operators have given 
> out /56s.

No 3GPP operator gives out a /56 on a public deployment.

There are some private trials on 3GPP operators with /56 and DHCPv6-PD, 
but that's a private APN with dedicated SIM cards.  It is not new, it is 
old, and dying out, because it is not working, because no smartphone 
could ever use it, because modems dont implement it.

> I'm working at my second one. It is not impossible.

Mark, is that work in a 3GPP network on a 3G/4G link?

Alex

> 
> Many things below are incorrect, uninformed, or quite frankly 
> ridiculous. Some read like you've let your imagination go wild and then 
> have just assumed because you can imagine it it will then inevitably 
> happen in the near future.
> 
> DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA 
> in the DHCPv6 RFC).
> 
> "the idea of a wearable /48 will really be many /48s"? Do you really 
> think we're going to have more devices on our person that we'll need 
> more than 65 536 /64 subnets (a single /48) to number them? That sounds 
> like science fiction to me for at least the next 200 years or more.
> 
> for the remainder of humanity, so we don't have to try to accommodate 
> every conceivable idea that somebody can come up with that might cause 
> the 128 bit address space to be too small.
> 
> 
>     This thread was in light of Lorenzo kindly pointing out that
>     upgrading 3GPP is not all that needs be done for Cameron’s 64share
>     v2 to work - as all mobile devices would stop working- as slaac
>     would not would be effectively broken.
> 
>     The mobile device would receive a shorter prefix let’s say /56 but
>     not know what to do with it since it’s expecting a /64.
> 
>     So that a major gap and the only solution is updating RFC 4291
>     removing the 64 bit boundary allowing for shorter prefix and now as
>     well longer prefixes to work and in that respect now provide the
>     much needed parity with static and DHCPv6 which can do any prefix
>     length.
> 
>     worlds and also to keep everyone happy to make this a WG effort for
>     this change by proposing in the subject heading /80 fixed boundary
>     and not a variable slaac change allowing all bits vlsm.
> 
>     This /80 would keep the operators and law enforcement happy as now
>     16 bits less helps traceability but is still long enough for 48 bits
>     of privacy to IP correlation by attackers.
> 
>     broadband and mobile handset customers happy respecting their
>     privacy as the 16 bits less of heuristics is minimal change that
>     will impact IP correlation by attackers.
> 
>     The IID as it’s less than the current 64 bit cannot use MAC based
>     EUI64 IID, which is not a problem as Mac based IID is not
>     recommended as most all manufacturers use RFC 4941 and I believe
>     Linux flavors some use stable IID RFC 7217.
> 
>     So now the 48 bit IID would require a random IID generation schema
>     so can use either RFC 4941 privacy extension or RFC 7217 stable IID
>     to generate the 48 bit IID.
> 
>     3GPP subtending would now work issue mentioned in the problem
>     statement draft without even having to use 64share as now longer
>     prefixes up to /80 would be supported allowing for further
>     segmentation of downstream devices.
> 
>     allocation via BNG gateways a /64, now operators  can stay as-is, as
>     the /64 would now be allowed to be further segmented supporting 64k
>     /80s, way more then enough for SOHO.
> 
>     This would allow 64share if used by 3GPP operators to work and would
>     not require the 3GPP specification to be updated.  We don’t know
>     even if the 3GPP architecture specification can be updated to
>     support shorter prefixes and if the 3GPP consortium of operators
>     would agree to it.  So that is all theoretical of that change is
>     possible.
> 
>     As this paradigm shift takes place, operators around the world will
>     be clamoring after the RIR for massive blocks, I would say less than
>     /8 more like a /5 or /4.  If you do the math on the way high side a
>     /10 yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR
>     which is tiny number with the number of large size operators worldwide.
> 
>     With the massive proliferation of IOT devices and just about every
>     home or office appliance on 5G, the problem now gets way exacerbated.
> 
>     Playing Monday night quarterbacking in hindsight we would never
>     think this would happen in a million years, but we would see IPv6 on
>     the verge of address space depletion.  Unheard of but it can happen
>     as the saying goes “when you build - they will come”.
> 
>     The answer to this real world problem is in the subject heading of
>     this thread.
> 
>     This would also fix the day 1 issue I mentioned allowing mix of
>     slaac devices with static and DHCPv6 up to /80.
> 
>     The variable slaac solution draft proposes a new  RA PIO flag that
>     would be used to signal longer prefixes, and would provide backwards
>     compatibility so that devices not supporting woud ignore the flag
>       and devices on newer code supporting would use the flag.  We
>     definitely don’t want to impact any existing devices on the existing
>     64 bit slaac boundary standard.
> 
>     Dmytro has tested the solution on Linux kernel signaling RA PIO flag
>     and was able to successfully test any length mask and random IID
>     generation both RFC 4941 privacy extension as well as stable IID RFC
>     7217.
> 
>     If everyone is in agreement with what I have stated on this thread,
>     I would like to ask the chairs for WG adoption as this is a WG effort.
> 
>     I would like to garner support from all 6MAN members with full
>     consensus to change the existing RFC 4941 /64 fixed boundary to /80
>     fixed boundary.
> 
>     Kind Regards
> 
>     Gyan
> 
>         Even hinting
>         thread is how to
>         with A flag
>         broken as they
>         bottom worries
>         think solves
>         anyways to allow
>         architecture as I
>         slaac hosts
>         following our ND
>         issue which
>         prefix lengths
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 Nov 2020 10:24:02 -0500

It seems to me that it would help to get agreement on what we want 
before we ask 3GPP to work on it with us.
Once we have rough agreement, sure, getting the IETF 3GPP liaison 
manager to work with us and sned a liaison seems sensible.

Yours,
Joel

On 11/20/2020 10:00 PM, Brian E Carpenter wrote:
>>>      upgrading
>>>      removing
>>>      privacy as
>>>      statement
>>>      consensus

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 21 Nov 2020 10:25:29 -0500

As I understand it, the situation is not that 3GPP has not defined use 
of DHCP.  But rather than operators have uniformly declined to deploy 
it.  (3GPP has defined DHCP for 5G for fixed access.  We have heard here 
that even that is not what the operators want.)  As such, asking 3GPP 
why they didn't deploy it seems a bit odd.

Yours,
Joel

On 11/20/2020 11:19 PM, Mark Smith wrote:
> 
> 
> On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Joel,
> 
> I think it is also important to find out why they haven't deployed 
> DHCPv6 to solve this problem.
> 
> probably only came to begrudgingly accept it because they couldn't 
> prevent phone vendors from implementing Wifi and NAT, and couldn't very 
> effectively stop their customers from using that capability (One trick 
> I've heard of to prevent tethering working was to check if an IPv4 
> packet's TTL value was 64 when it arrived at the network, meaning it 
> originated from the directly attached handset. Packets from tethered 
> devices had a TTL of 63 so were dropped. Of course, you could set the 
> default TTL on a tethered PC to 65 to get around that.)
> 
> utilisation. Providing multiple /64s would be formally acknowledging 
> that multiple devices can be attached and a fee per device isn't and 
> can't ever be charged, counter to the mindset.
> 
> Regards,
> Mark.
> 
> 
>      >> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern
>      >>     But I do not see how that is relevant to any choice we are
>     trying to
>      >>     make.
>      >>      > (top posting)
>      >>      > As I would like to clear the air as well as get to the
>     crux of
>      >>     the v6ops
>      >>      > presentation development results as well as next steps
>     for this
>      >>     draft
>      >>      > and the 6man variable slaac solutions draft:
>      >>      >
>      >>      >
>      >>      > This thread was in light of Lorenzo kindly pointing out that
>      >>     upgrading
>      >>      > 3GPP is not all that needs be done for Cameron’s 64share
>     v2 to
>      >>     work - as
>      >>      > all mobile devices would stop working- as slaac would not
>     would be
>      >>      > effectively broken.
>      >>      >
>      >>      > The mobile device would receive a shorter prefix let’s
>     say /56
>      >>     but not
>      >>      > know what to do with it since it’s expecting a /64.
>      >>      >
>      >>      > So that a major gap and the only solution is updating RFC
>     4291
>      >>     removing
>      >>      > the 64 bit boundary allowing for shorter prefix and now
>     as well
>      >>     longer
>      >>      > prefixes to work and in that respect now provide the much
>     needed
>      >>     parity
>      >>      > with static and DHCPv6 which can do any prefix length.
>      >>      >
>      >>      > So that is a drastic change to RFC 4291.  However, in
>     light of this
>      >>      > development on the v6ops 109 call, my balancing act of
>     best of both
>      >>      > worlds and also to keep everyone happy to make this a WG
>     effort
>      >>     for this
>      >>      > change by proposing in the subject heading /80 fixed
>     boundary and
>      >>     not a
>      >>      > variable slaac change allowing all bits vlsm.
>      >>      >
>      >>      > Basically stealing 16 bits for network prefix out of the
>     IID, still
>      >>      > keeping the fixed boundary so longer than 80 would NOT
>       be allowed.
>      >>      >
>      >>      > A /64 would now be equivalent to a /48 with now 64k /80’s.
>      >>      >
>      >>      > This /80 would keep the operators and law enforcement
>     happy as
>      >>     now 16
>      >>      > bits less helps traceability but is still long enough for
>     48 bits of
>      >>      > privacy to IP correlation by attackers.
>      >>      >
>      >>      > This /80 would be a nice optimal balance as it would keep
>     wired
>      >>      > broadband and mobile handset customers happy respecting their
>      >>     privacy as
>      >>      > the 16 bits less of heuristics is minimal change that
>     will impact IP
>      >>      > correlation by attackers.
>      >>      >
>      >>      > The IID as it’s less than the current 64 bit cannot use
>     MAC based
>      >>     EUI64
>      >>      > IID, which is not a problem as Mac based IID is not
>     recommended
>      >>     as most
>      >>      > all manufacturers use RFC 4941 and I believe Linux
>     flavors some use
>      >>      > stable IID RFC 7217.
>      >>      >
>      >>      > So now the 48 bit IID would require a random IID generation
>      >>     schema so
>      >>      > can use either RFC 4941 privacy extension or RFC 7217
>     stable IID to
>      >>      > generate the 48 bit IID.
>      >>      >
>      >>      > 3GPP subtending would now work issue mentioned in the problem
>      >>     statement
>      >>      > draft without even having to use 64share as now longer
>     prefixes
>      >>     up to
>      >>      > /80 would be supported allowing for further segmentation of
>      >>     downstream
>      >>      > devices.
>      >>      >
>      >>      > This also would help wired broadband and soon fixed 5G
>     broadband
>      >>      > proliferation where operators in light of BCP RIPE-690,
>     are sill
>      >>      > allocation via BNG gateways a /64, now operators  can
>     stay as-is,
>      >>     as the
>      >>      > /64 would now be allowed to be further segmented
>     supporting 64k
>      >>     /80s,
>      >>      > way more then enough for SOHO.
>      >>      >
>      >>      > This would allow 64share if used by 3GPP operators to
>     work and
>      >>     would not
>      >>      > require the 3GPP specification to be updated.  We don’t
>     know even
>      >>     if the
>      >>      > 3GPP architecture specification can be updated to support
>     shorter
>      >>      > prefixes and if the 3GPP consortium of operators would
>     agree to
>      >>     it.  So
>      >>      > that is all theoretical of that change is possible.
>      >>      >
>      >>      > As with 5G with Enhanced VPN framework SR steering of
>     high priority
>      >>      > traffic, traffic isolation and Network slicing
>     capabilities becomes
>      >>      > mainstream and will soon be a real world reality and as
>     fixed 5G
>      >>      > broadband proliferation takes off and mobile 5G == the
>     idea of a
>      >>      > wearable /48 will really be many /48s.
>      >>      >
>      >>      > As this paradigm shift takes place, operators around the
>     world
>      >>     will be
>      >>      > clamoring after the RIR for massive blocks, I would say
>     less than /8
>      >>      > more like a /5 or /4.  If you do the math on the way high
>     side a /10
>      >>      > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per RIR
>      >>     which is
>      >>      > tiny number with the number of large size operators
>     worldwide.
>      >>      >
>      >>      > With the massive proliferation of IOT devices and just about
>      >>     every home
>      >>      > or office appliance on 5G, the problem now gets way
>     exacerbated.
>      >>      >
>      >>      > As this evolution unfolds IANA will be scrambling to
>     release all
>      >>      > remaining /3 as well as all unallocated blocks to subvert
>     RIR IPv6
>      >>      > address space depletion.
>      >>      >
>      >>      > Playing Monday night quarterbacking in hindsight we would
>     never
>      >>     think
>      >>      > this would happen in a million years, but we would see
>     IPv6 on
>      >>     the verge
>      >>      > of address space depletion.  Unheard of but it can happen
>     as the
>      >>     saying
>      >>      > goes “when you build - they will come”.
>      >>      >
>      >>      > It is true as history has taught that very important lesson.
>      >>      >
>      >>      > The answer to this real world problem is in the subject
>     heading
>      >>     of this
>      >>      > thread.
>      >>      >
>      >>      > This would also fix the day 1 issue I mentioned allowing
>     mix of
>      >>     slaac
>      >>      > devices with static and DHCPv6 up to /80.
>      >>      >
>      >>      > The variable slaac solution draft proposes a new  RA PIO flag
>      >>     that would
>      >>      > be used to signal longer prefixes, and would provide
>     backwards
>      >>      > compatibility so that devices not supporting woud ignore
>     the flag
>      >>       and
>      >>      > devices on newer code supporting would use the flag.  We
>     definitely
>      >>      > don’t want to impact any existing devices on the existing
>     64 bit
>      >>     slaac
>      >>      > boundary standard.
>      >>      >
>      >>      > Dmytro has tested the solution on Linux kernel signaling
>     RA PIO
>      >>     flag and
>      >>      > was able to successfully test any length mask and random IID
>      >>     generation
>      >>      > both RFC 4941 privacy extension as well as stable IID RFC
>     7217.
>      >>      >
>      >>      >
>      >>
>       <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>
>      >>      >
>      >>   
>       <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>
>      >>   
>       <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>>
>      >>      >
>      >>      > If everyone is in agreement with what I have stated on this
>      >>     thread, I
>      >>      > would like to ask the chairs for WG adoption as this is a
>     WG effort.
>      >>      >
>      >>      > I would like to garner support from all 6MAN members with
>     full
>      >>     consensus
>      >>      > to change the existing RFC 4941 /64 fixed boundary to /80
>     fixed
>      >>     boundary.
>      >>      >
>      >>      > Kind Regards
>      >>      >
>      >>      > Gyan
>      >>      >
>      >>      > On Thu, Nov 19, 2020 at 5:14 PM Joel M. Halpern
>     <mailto:[email-masked] <mailto:[email-masked]>>
>      >>      > <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>      >>      >
>      >>      >     I am missing something in your reasoning.
>      >>      >     You seem to say at one point that (to paraphrase) "we
>     can't
>      >>     do this
>      >>      >     because it does not work with the existing UE software".
>      >>      >     Any new solution where a UE delegates based on any
>     change of
>      >>     any kind
>      >>      >     (including lengthening the prefix, shortening the
>     prefix, or
>      >>     magically
>      >>      >     incanting new prefixes) requires that the UE be
>     upgraded to know
>      >>      >     what to
>      >>      >     do with the information.  I do not see how that
>      >>     differentiates any of
>      >>      >     the solutions. (Except "don't do anything", which I
>     think we
>      >>     do not
>      >>      >     want
>      >>      >     to take.)
>      >>      >
>      >>      >     Yours,
>      >>      >     Joel
>      >>      >
>      >>      >     On 11/19/2020 5:03 PM, Gyan Mishra wrote:
>      >>      >      >
>      >>      >      >
>      >>      >      > On Thu, Nov 19, 2020 at 10:33 AM
>     <[email-masked] <mailto:[email-masked]>
>      >>      >     <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>>
>      >>      >      > <mailto:[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>      >>      >      >
>      >>      >      >
>      >>      >      >
>      >>      >      >      > On 19 Nov 2020, at 14:58, Gyan Mishra
>      >>      >     <[email-masked] <mailto:[email-masked]>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >>      >      >     <mailto:[email-masked]
>     <mailto:[email-masked]>>>>> wrote:
>      >>      >      >      >
>      >>      >      >      > You would need a new option. It would likely be
>      >>     useful for the
>      >>      >      >     requesting router to indicate interest in the
>     option. Even
>      >>      >     hinting
>      >>      >      >     at what prefix size it was expecting.
>      >>      >      >      > Now can you explain to me again the reasons
>     why this
>      >>      >     approach is
>      >>      >      >     better than using the existing DHPCv6 protocol
>     packets?
>      >>      >      >      >
>      >>      >      >      >     3GPP gateway does not support DHCPv6
>      >>      >      >
>      >>      >      >     3GPP gateway doesn't support new option.
>     What's your
>      >>     point?
>      >>      >      >
>      >>      >      >
>      >>      >      >
>      >>      >      >      The point of the v6ops presentation and this
>     email
>      >>     thread is
>      >>      >     how to
>      >>      >      > “extend a /64” in the 3GPP use case  in slide 1 of the
>      >>     deck you
>      >>      >     compiled
>      >>      >      > a list of options and of the two I had highlighted
>     in red
>      >>     were the
>      >>      >      > 64share v2 Cameron’s option and the variable slaac
>      >>     option.  So on
>      >>      >     the
>      >>      >      > call this morning Lorenzo shot down 64share v2
>     shorter prefix
>      >>      >     option as
>      >>      >      > even if the 3GPP architecture was updated to
>     support longer
>      >>      >     prefixes and
>      >>      >      > even is the 3GPP gateway was able to send a
>     shorter prefix
>      >>     with A
>      >>      >     flag
>      >>      >      > not set, all mobile devices per Lorenzo’s point
>     would be
>      >>     broken
>      >>      >     as they
>      >>      >      > would not accept the shorter let’s say /56 prefix
>     to build the
>      >>      >     slaac 128
>      >>      >      > bit address.  So the bottom line is the 64share v2
>     won’t work
>      >>      >     unless we
>      >>      >      > update RFC 4291 and remove the 64 bit boundary.
>      >>      >      >
>      >>      >      >   So we are back to square uno - no viable solution
>      >>      >      >
>      >>      >      >   So now we had thrown out the longer >64 due to
>     race to
>      >>     bottom
>      >>      >     worries
>      >>      >      > which I and others believe is Fud and as described in
>      >>     slide 10 of
>      >>      >     the
>      >>      >      > v6ops “race to the bottom slide”.
>      >>      >      >
>      >>      >      > So a happy medium /80 fixed boundary I came up
>     with that I
>      >>     think
>      >>      >     solves
>      >>      >      > a lot of the issue and not just the 3GPP initial
>      >>     segmentation of
>      >>      >      > downstream devices problem statement.
>      >>      >      >
>      >>      >      > Since we have to update RFC 4291 for 64share v2 to
>     work
>      >>     anyways
>      >>      >     to allow
>      >>      >      > for shorter prefixes, why not instead create a new
>     bottom
>      >>     at /80
>      >>      >     giving
>      >>      >      > 16 bits more of prefix length and shrinking the
>     IID down
>      >>     to 48 bits.
>      >>      >      > Doing so you would not even have to update the 3GPP
>      >>     architecture
>      >>      >     as I
>      >>      >      > don’t know if that would fly or not.  Also this
>     solves a
>      >>     few other
>      >>      >      > problems at the same time.
>      >>      >      >
>      >>      >      >
>      >>      >      > As I mentioned in the v6ops deck presented that
>     vlsm 0 to
>      >>     128 is
>      >>      >      > mainstream for operators for static addressing on
>     router
>      >>     and switch
>      >>      >      > infrastructure and dhcpv6 subnets longer prefixes
>     for network
>      >>      >      > infrastructure appliance clusters, NFV/VNF
>     virtualization
>      >>     and server
>      >>      >      > farms.  On host subnets where there is a chance of
>     mix of
>      >>     slaac
>      >>      >     hosts
>      >>      >      > with dhcpv6  devices the prefix length is stuck at
>     /64.  So on
>      >>      >     these mix
>      >>      >      > addressing host subnets we cannot do longer
>     prefixes following
>      >>      >     our ND
>      >>      >      > cache hard limit mantra to prevent ND cache exhaustion
>      >>     issues as
>      >>      >      > described in RFC 6164.
>      >>      >      >
>      >>      >      > So with the /80 new fixed boundary shifting prefix
>     length
>      >>     16 bits
>      >>      >     longer
>      >>      >      > and shortening the IID by 16 bits gives resolved
>     the 3GPP
>      >>     issue
>      >>      >     which
>      >>      >      > 64share can work as is and subtending to downstream
>      >>     devices will now
>      >>      >      > work as a /64 is now equivalent to a /48 with 64k
>     /80s.  Also
>      >>      >     BCP-690
>      >>      >      > for broadband not all operators have adopted the
>     shorter
>      >>     prefix
>      >>      >     lengths
>      >>      >      > /56 or /48 recommendations  and now that’s not an
>     issue as the
>      >>      >     /64 would
>      >>      >      > now suffice.
>      >>      >      >
>      >>      >      >  From an operators perspective that gain allows at
>     least
>      >>     for 3GPP
>      >>      >      > massive growth and subtending with a single /64
>     allows the
>      >>     operators
>      >>      >      > such as Verizon with massive subscriber base
>     worldwide can
>      >>     stay with
>      >>      >      > current allocations and don’t have to ask
>      >>   
>       <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g>>
>      >>     for /10.
>      >>      >      >
>      >>      >      > As 5G gets rolled out with Enhanced VPN framework
>     and Network
>      >>      >     slicing
>      >>      >      > paradigm, the demand for shorter blocks and wearable
>      >>     multiple /48
>      >>      >     will
>      >>      >      > be our new reality.
>      >>      >      >
>      >>      >      > Making that 16 bit shift now to /80 making a /64
>     the new
>      >>     /48 will
>      >>      >     give
>      >>      >      > broadband and 3GPP subscribers a ton of space to
>      >>     subtending their
>      >>      >      > networks we would be set for the future. 
>     Especially with
>      >>     IOT the
>      >>      >     demand
>      >>      >      > for subtending will continue to grow astronomically.
>      >>      >      >
>      >>      >      > Also IANA does not have to get start in allocating the
>      >>     other /3 and
>      >>      >      > other available blocks.
>      >>      >      >
>      >>      >      > Lots of problems being solved here with a fixed
>     /80 new
>      >>     boundary.
>      >>      >      >
>      >>      >      > Also with the existing random IID generation
>     schemes which
>      >>     we have
>      >>      >      > tested on Linux kernel can do longer p
>      >>      >
>      >>     
>       <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>>>refixes
>      >>      >     using RFC 4941 privacy
>      >>      >      > extension or RFC 7217 stable IID.
>      >>      >      >
>      >>      >      > Win-Win for all.
>      >>      >      >
>      >>      >      >     Ole
>      >>      >      >
>      >>      >      > --
>      >>      >      >
>      >>      >      > <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
>      >>      >      >
>      >>      >      >
>      >>      >      >
>      >>      >      > _______________________________________________
>      >>      >      > v6ops mailing list
>      >>      >      > [email-masked] <mailto:[email-masked]>
>      >>     <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>      >>      >      > https://www.ietf.org/mailman/listinfo/v6ops
>      >>      >     <https://www.ietf.org/mailman/listinfo/v6ops
>     <https://www.ietf.org/mailman/listinfo/v6ops>>>
>      >>      >      >
>      >>      >
>      >>      > --
>      >>      >

---

From: Mark Smith <[email-masked]>
Date: Sun, 22 Nov 2020 09:58:17 +1100

> could ever use it, because modems dont implement it.

*Why* don't they implement it?

3GPP themselves put DHCPv6-PD support in 3GPP Release-10, more than 6 years
ago. They themselves have said it is possible.

We can't just accept "it hasn't been done" as a valid reason to develop a
new alternative technical solution. That new solution may also not be used
if the reasons the old solution hasn't been used aren't technical.

There may be business / business model reasons, or education reasons, or
vendors not implementing it because customers aren't asking for it. A new
alternative technical solution will not solve any of these other causes. An
actual solution to the actual reason may be much cheaper than developing
and deploying a new technical solution.

You need to ensure you properly understand exactly what problem you're
trying to solve before you then try to solve it. That's the only way to
ensure you're solving the actual problem, not some assumed and possibly
non-existent problem.

> Mark, is that work in a 3GPP network on a 3G/4G link?

No. However that doesn't prove it is impossible in a 3GPP network - and the
3GPP people don't believe that either.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Sun, 22 Nov 2020 14:59:35 +0000

Hi, I believe the AERO/OMNI approach to prefix delegation would be good for the 3GPP
case also. The approach is predicated on the router returning an RA with an IPv6 link-local
destination address determined by the delegated prefix. The link-local address is formed
by writing the most significant 64 bits of the delegated prefix into the interface ID of the
prefix fe80::/64.

For example, if the delegated prefix were 2001:db8:1:0::/56 then the IPv6 link-local
destination address is fe80::2001:db8:1:0. This provides at least two important
operational advantages:

1) It conveys the delegated prefix in the IPv6 destination address of the RA so that
no PIOs inside the RA need to be used for prefix delegation.

2) It supplies the mobile node with a guaranteed-unique link-local address that
it can use for future communications without the need to perform DAD.

Again, the proposal comes from the AERO/OMNI use case, but I believe is also
good for 3GPP and really any other wireless use case where a lightweight
prefix delegation capability is desired.

Fred

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 22 Nov 2020 14:08:00 -0500

> one quesiton I could understand.

   Gyan> Thank you

> As with anything, the real things that need to change are the devices in

    Gyan> Agreed

> the IPv6 addressing archtiecture, as the addressing structure remains as

    Gyan> Agreed

> of using a new option in his generic option mechanism.  But I am not

    Gyan>ok

> That's the way we do things.  Work together.

    Gyan> Yes Agreed.  Thank you

>
>
> Changing the prefix length to /80 is technically also possible.

     Gyan>

> It does

    Gyan> Understood.  This is a multi faceted problem and may require a
multi faceted solution.  Thank you.

> >      >      > would not accept the shorter let’s say /56 prefix to build
> the
> >      >     slaac 128
> >      >      > /56 or /48 recommendations  and now that’s not an issue as
> the
> >      >     /64 would
> >      >      > now suffice.
> >      >      >
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 22 Nov 2020 14:47:55 -0500

> representation about "everybody's" opinion you can make.

    Gyan> I believe after the v6ops presentation I gave on the problem
statement as well as the countless threads and interest I think more folks
think their is an issue to be solved then don’t.  I think the problem is
clear. I never said that this is the only way to solve the problem.  This
is just one idea of a possible solution and there definitely maybe others
that are better and I am not denying that.  Nothing premature as this is
just and idea of one possible proposed solution.

> /56s. I'm working at my second one. It is not impossible.

    Gyan> All of the countess threads have all been spawned from the
variable slaac problem statement draft and solution to change the 64 bit
IID boundary.  There are two sides to the camp of changing versus not
changing as this idea to change is not new as it comes up every few years
with a fierce onslaught of threads for and against.  Their is definitely
interest in changing but thus far the balance of not changing as been the
weighted majority over not changing.  I am hoping this time around maybe we
have a game changer of a problem to be solved and the fixed 64 bit IID
change gets close to workgroup consensus.

> assumed because you can imagine it it will then inevitably happen in the

   Gyan> That is your POV.

> DHCPv6 doesn't work the way you think it does (look up IA_NA and IA_TA in

    Gyan> Understood.  I think you may have misunderstood what I meant and
maybe I did not state clearly and that’s my fault if the latter.  My point
is that DHCPv6 is length independent as the sever sends 128 bit managed
address M=1 to host. Point here is that both static and dhcpv6 are prefix
length independent and slaac is fixed at 64 bit.  This does introduce
incompatibility issue with slaac host endpoints not having parity with
dhcpv6 and static being prefix length agnostic. So as stated in the v6ops
deck this prevents operators from having longer then 64 bit prefix lengths
on host subnets due to the 64 bit boundary.  I understand that there are
many addressing guidelines that state that due to this parity issue that
/64 is recommended for all host subnets. However operators would like this
to change so that >64 prefix can be deployed to host subnets.

> fiction to me for at least the next 200 years or more.

Gyan> I did not start the original thread on “wearable” /64.   Please see
6MAN archives.  I just took that and ran with it based on future network
infrastructure developments upcoming and paradigm shift and a reality of a
digital transformation with 5G in the context of “network slicing” which
will require exorbitant amount of address space.  It’s no different then
concept of cloud computing and hypervisor virtualization which required
many more addresses per VM as compare to physical servers.  So now apply
that to the wireless operators RAN front haul and backhaul xHaul
virtualization framework with “network slicing” game changer paradigm shift.

>> remaining /3 as well as all unallocated blocks to subvert RIR IPv6 address
>> space depletion.
>>
>> this would happen in a million years, but we would see IPv6 on the verge of
>>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%2FSilver+Spring,+MD?entry=gmail&source=g>>
>>> /Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>

*Gyan Mishra*

---

From: Mark Smith <[email-masked]>
Date: Mon, 23 Nov 2020 07:10:19 +1100

> operational advantages.

In my operational experience it is far better to make things explicit in
packets rather than implicit.

See RFC8469 for an example of where what was implicit in packets has caused
so many problems that now being explicit has become the recommendation.
(Absence of this in a wholesaler's network caused us and a customer months
of troubleshooting for unusual performance problems, and is now costing us
service outages for many customers at once while they put it in place.)

> it can use for future communications without the need to perform DAD.

So the RA DA is carries both delegated prefix information and with
link-local address configuration too? How does a node know to use the RA DA
as its link-local address?

With the rise of wireless we need to care about the global traceability of
link-local addresses too. Persistent, globally unique link-local IIDs have
the same privacy implications as persistent globally unique WiFi MAC
addresses and Bluetooth MAC addresses.

Have a look at https://wigle.net and the Android app for collecting the
data.

A similar app focused on Bluetooth is Ramble.

Neither of these apps require a hacked phone, the can just be installed and
run by anybody from the Google app store.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Nov 2020 22:12:25 -0500

> 150 pages long. Longer than bgp, mpls, ipv6 ... tl; dr.

Yes, because it details with dozens of different things.
IPv6-PD is only one section, and on circuits (vs ethernet), almost of the
lifetime management stuff is moot.

Also, you can't write BGP4 and read only one document, so your comparison is
just not on.

I've written PD-only DHCPv6 for a BMS (PPPoE).

The daemon is about 2000 lines of C, including test cases.
Most of the logic is about learning about new interfaces and decoding Radius
TLVs.  (Not really open source, sorry)

I thought about writing an LWIG document on this, but decided not to.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 01:40:59 -0500

> why they didn't deploy it seems a bit odd.

    Gyan> One possible non technical factor is that Android which as of
2019 statistical data below holds 87% of the global mobile market share and
Apple 13% and Android is continuing to climb in 2020.   Android adamantly
refuses to change its position on support of DHCPv6.  I think that really
shackles 3GPP carriers from supporting DHCPv6 is close to 100% of all
mobile handsets won’t support it.

https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/

> >      >>      > As I would like to clear the air as well as get to the
> >     crux of
> >      >>     the v6ops
> >      >>      > presentation development results as well as next steps
> >     for this
> >      >>     draft
> >      >>      > 3GPP is not all that needs be done for Cameron’s 64share
> >     v2 to
> >      >>     work - as
> >      >>      > The mobile device would receive a shorter prefix let’s
> >     say /56
> >      >>     but not
> >      >>      > the 64 bit boundary allowing for shorter prefix and now
> >     as well
> >      >>     longer
> >      >>      > worlds and also to keep everyone happy to make this a WG
> >     effort
> >      >>     for this
> >      >>      > change by proposing in the subject heading /80 fixed
> >     boundary and
> >      >>     not a
> >      >>      > This /80 would keep the operators and law enforcement
> >     happy as
> >      >>     now 16
> >      >>      > IID, which is not a problem as Mac based IID is not
> >     recommended
> >      >>     as most
> >      >>      > So now the 48 bit IID would require a random IID
> generation
> >      >>     schema so
> >      >>      > draft without even having to use 64share as now longer
> >     prefixes
> >      >>     up to
> >      >>      > /80 would be supported allowing for further segmentation
> of
> >      >>     downstream
> >      >>      > devices.
> >      >>      >
> >      >>      > allocation via BNG gateways a /64, now operators  can
> >     stay as-is,
> >      >>     as the
> >      >>      > /64 would now be allowed to be further segmented
> >     supporting 64k
> >      >>     /80s,
> >      >>      > This would allow 64share if used by 3GPP operators to
> >     work and
> >      >>     would not
> >      >>      > require the 3GPP specification to be updated.  We don’t
> >     know even
> >      >>     if the
> >      >>      > prefixes and if the 3GPP consortium of operators would
> >     agree to
> >      >>     it.  So
> >      >>      > As this paradigm shift takes place, operators around the
> >     world
> >      >>     will be
> >      >>      > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs per
> RIR
> >      >>     which is
> >      >>      > With the massive proliferation of IOT devices and just
> about
> >      >>     every home
> >      >>      > this would happen in a million years, but we would see
> >     IPv6 on
> >      >>     the verge
> >      >>      > of address space depletion.  Unheard of but it can happen
> >     as the
> >      >>     saying
> >      >>      > The answer to this real world problem is in the subject
> >     heading
> >      >>     of this
> >      >>      > thread.
> >      >>      >
> >      >>      > The variable slaac solution draft proposes a new  RA PIO
> flag
> >      >>     that would
> >      >>      > don’t want to impact any existing devices on the existing
> >     64 bit
> >      >>     slaac
> >      >>      > boundary standard.
> >      >>      >
> >      >>      > Dmytro has tested the solution on Linux kernel signaling
> >     RA PIO
> >      >>     flag and
> >      >>      > was able to successfully test any length mask and random
> IID
> >      >>     generation
> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <
> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <
> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/ <
> https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>>
> >      >>      >
> >      >>      > If everyone is in agreement with what I have stated on
> this
> >      >>     thread, I
> >      >>      > to change the existing RFC 4941 /64 fixed boundary to /80
> >     fixed
> >      >>     boundary.
> >      >>      >
> >      >>      > Kind Regards
> >      >>      >
> >      >>      > Gyan
> >      >>      >
> >      >>      > <mailto:[email-masked] <mailto:[email-masked]>
> >      >>      >     You seem to say at one point that (to paraphrase) "we
> >     can't
> >      >>     do this
> >      >>      >     Any new solution where a UE delegates based on any
> >     change of
> >      >>     any kind
> >      >>      >     (including lengthening the prefix, shortening the
> >     prefix, or
> >      >>     magically
> >      >>      >     incanting new prefixes) requires that the UE be
> >     upgraded to know
> >      >>      >     what to
> >      >>      >      > On Thu, Nov 19, 2020 at 10:33 AM
> >      >>      >     <mailto:[email-masked]
> >      >>      >      > <mailto:[email-masked]
> >      >>     <mailto:[email-masked] <mailto:[email-masked]
> >>
> >      >>      >      >      > You would need a new option. It would
> likely be
> >      >>     useful for the
> >      >>      >      >      > Now can you explain to me again the reasons
> >     why this
> >      >>      >     approach is
> >      >>      >      >     3GPP gateway doesn't support new option.
> >     What's your
> >      >>     point?
> >      >>      >      >
> >      >>      >      >
> >      >>      >      >
> >      >>      >      > a list of options and of the two I had highlighted
> >     in red
> >      >>     were the
> >      >>      >      > call this morning Lorenzo shot down 64share v2
> >     shorter prefix
> >      >>      >     option as
> >      >>      >      > even if the 3GPP architecture was updated to
> >     support longer
> >      >>      >     prefixes and
> >      >>      >      > would not accept the shorter let’s say /56 prefix
> >     to build the
> >      >>      >     slaac 128
> >      >>      >      > 16 bits more of prefix length and shrinking the
> >     IID down
> >      >>     to 48 bits.
> >      >>      >      > don’t know if that would fly or not.  Also this
> >     solves a
> >      >>     few other
> >      >>      >      > As I mentioned in the v6ops deck presented that
> >     vlsm 0 to
> >      >>     128 is
> >      >>      >      > mainstream for operators for static addressing on
> >     router
> >      >>     and switch
> >      >>      >      > addressing host subnets we cannot do longer
> >     prefixes following
> >      >>      >     our ND
> >      >>      >      > cache hard limit mantra to prevent ND cache
> exhaustion
> >      >>     issues as
> >      >>      >      > described in RFC 6164.
> >      >>      >      >
> >      >>      >      > /56 or /48 recommendations  and now that’s not an
> >     issue as the
> >      >>      >     /64 would
> >      >>      >      > now suffice.
> >      >>      >      >
> >      >>      >      >  From an operators perspective that gain allows at
> >     least
> >      >>     for 3GPP
> >      >>      >      > massive growth and subtending with a single /64
> >     allows the
> >      >>     operators
> >      >>      >      > such as Verizon with massive subscriber base
> >     worldwide can
> >      >>     stay with
> >      >>      >      > As 5G gets rolled out with Enhanced VPN framework
> >     and Network
> >      >>      >     slicing
> >      >>      >      > Also IANA does not have to get start in allocating
> the
> >      >>     other /3 and
> >      >>      >      > other available blocks.
> >      >>      >      >
> >      >>      >      > Lots of problems being solved here with a fixed
> >     /80 new
> >      >>     boundary.
> >      >>      >      >
> >      >>      >      > Also with the existing random IID generation
> >     schemes which
> >      >>     we have
> https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>
> <
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 01:55:04 -0500

> https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/
     Gyan> I have spoken with executives at Google and in talks related to
Chromebook DHCPv6 support, they said that their development platform is a
common platform for both Android and Chromebook and that for mobile
handsets they cannot change and gave their technical justifications.  Based
on that feedback, 3GPP operators are really stuck between a rock and hard
place and cannot change to support DHCPv6 as close to 90% of the market
share is Android.Their maybe some other technical reasons as well on the
operator gateway side which I would have to research if one exist as well
why they won’t adopt PD.

>> >      >>      > yields 7 bits so 128 divided by 5 RIRs yields 24 ISPs
>> per RIR
>> >      >>     which is
>> >      >>      >     <[email-masked] <mailto:[email-masked]
>> >
>> >      >>      >      > 64share can work as is and subtending to
>> downstream
>> >      >>     devices will now
>> >      >>      >      > Also IANA does not have to get start in
>> allocating the
>> >      >>     other /3 and
>> >      >>      >      > other available blocks.
>> >      >>      >      >
>> >      >>      >      > <http://www.verizon.com/ <http://www.verizon.com/
>> >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >>
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>>
>> /Silver Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>
>> >      >>      >      >
>> >      >>      >      >
>> >      >>      >      >
>> <https://www.google.com/maps/search/13101+Columbia+Pike+%0D%0A+%C2%A0+%C2%A0+%C2%A0++%2FSilver+Spring,+MD?entry=gmail&source=g>>>
>> /Silver Spring, MD
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 01:58:33 -0500

On Thu, Nov 19, 2020 at 6:02 PM Bob Hinden <[email-masked]> wrote:

> > And if we had left the boundary at /80, as it was in 1995 (RFC1884),
> would you now be arguing for /96, since in that case 3GPP would have
> settled on /80?
> >
> > Sorry, but this is exactly and precisely a 16-bit jump in the race to
> the bottom. And it breaks all existing SLAAC hosts on the way.
> >
> Either something like Cameron’s draft or a very minimal DHCPv6 PD
> implementation that can run in a 3GPP environment.   It doesn’t need to be
> a full DHCPv6 server.
>
> Bob

> a lot of the issue and not just the 3GPP initial segmentation of downstream
> >> Since we have to update RFC 4291 for 64share v2 to work anyways to
> allow for shorter prefixes, why not instead create a new bottom at /80
> giving 16 bits more of prefix length and shrinking the IID down to 48
> bits.  Doing so you would not even have to update the 3GPP architecture as
> I don’t know if that would fly or not.  Also this solves a few other
> farms.  On host subnets where there is a chance of mix of slaac hosts with
> dhcpv6  devices the prefix length is stuck at /64.  So on these mix
> addressing host subnets we cannot do longer prefixes following our ND cache
> hard limit mantra to prevent ND cache exhaustion issues as described in RFC
> 6164.
> >>
> >> So with the /80 new fixed boundary shifting prefix length 16 bits
> longer and shortening the IID by 16 bits gives resolved the 3GPP issue
> which 64share can work as is and subtending to downstream devices will now
> work as a /64 is now equivalent to a /48 with 64k /80s.  Also BCP-690 for
> massive growth and subtending with a single /64 allows the operators such
> as Verizon with massive subscriber base worldwide can stay with current
> <https://www.google.com/maps/search/ivacy+extension+or+RFC+7217+stable+IID.?entry=gmail&source=g>
> >>
> >> Win-Win for all.
> >>
> >>    Ole
> >>
> >> --
> >>

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 23 Nov 2020 02:27:17 -0500

On Mon, Nov 23, 2020 at 1:58 AM Gyan Mishra <[email-masked]> wrote:

>> > The problem here is caused by 3GPP, but a solution like Cameron's
>> should work for everybody with minimal changes.
>>
>> +100
>>
>> Gyan> How do you propose to solve this issue if Android holds 90% of the
>> market and is growing and Google adamantly stated they will not support
>> DHCPv6 or PD.
>
>
        So the problem is 2 fold and I am not sure 100% if one has a
dependency on the other.

   3GPP architecture for PD support has been around  for over 10 years.
Operators have chosen to NOT support PD.  I am thinking there is some
underlying technical issue but they plan to not support for 5G as well.  I
don’t think that is changing any time soon or ever.

What does make the solution more complicated is my post above that Android
hold 90% of the mobile market share so even if the operators were willing
to support PD, 90% of handsets would not work.

I am not sure if Apple iOS supports DHCPv6 or PD?

I did google and does not look like Apple iOS supports DHCPv6 or PD.

I am not just throwing our fluff to change change to a new bottom /80.  I
don’t think we have a lot of options as we have a lot of forces going
against us that our out of the IETF’s control.

Hypothetically if we moved to /80 being the new fixed IID boundary, how is
that any different then our current /64 in the context that you believe
that a new /96 or /112 or /128 boundary will magically form if we changed
the fixed boundary to /80.

Please explain how our current /64 boundary has stayed a /64 boundary and
has not magically changed to /80 or /96 ...???

We would of course have to make the /80 change so it backwards compatible
so existing devices are not impacted.

As far as I can tell from all the threads the /80 fixed boundary proposal
is the only real viable solution.

If we think 16 bits is way too much I am OK with shrinking way down as for
SOHO or tethering I think a few bits would do the trick.

How about a /68 as the new fixed boundary.  That would yield 16 /64s or
maybe even a /72 8 extra bits yielding 255 /64s would still be way plenty.

Any takers??

>> >>     The point of the v6ops presentation and this email thread is how
>> to “extend a /64” in the 3GPP use case  in slide 1 of the deck you compiled
>> a list of options and of the two I had highlighted in red were the 64share
>> v2 Cameron’s option and the variable slaac option.  So on the call this
>> >> So a happy medium /80 fixed boundary I came up with that I think
>> solves a lot of the issue and not just the 3GPP initial segmentation of

*Gyan Mishra*

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Nov 2020 09:03:29 +0000

Hello Brian

Please note that RFC 8929 would work there too -that's proxy ND with the backbone on the Wi-Fi link and the wireless access on the 3GPP link-, used in the routing proxy mode - that's when the links are not bridgeable-..
Basically the phone as a routing proxy installs host (connected) routes towards the 3GPP link for the addresses present there, and defends those addresses over the Wi-Fi Link.
On paper the result is similar to RFC 7278, but the method is a bit different since internally it relies on ND proxy as opposed to anycast. Arguably the phone would self-assign another global address on the Wi-Fi link, if it cares to have one at all on that link.
Bottom line is yes, I agree we should consider the applicability of what we have before we start breaking things down.

Keep safe;

Pascal

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: jeudi 19 novembre 2020 23:50
> To: Gyan Mishra <[email-masked]>; [email-masked]
> Cc: IPv6 Operations <[email-masked]>; 6MAN <[email-masked]>; JORDI PALET
> MARTINEZ <jordi.palet=[email-masked]>
> Subject: Re: [v6ops] The bottom is /112
> 
> And if we had left the boundary at /80, as it was in 1995 (RFC1884), would you
> now be arguing for /96, since in that case 3GPP would have settled on /80?
> 
> Sorry, but this is exactly and precisely a 16-bit jump in the race to the bottom.
> And it breaks all existing SLAAC hosts on the way.
> 
> router to indicate interest in the option. Even hinting at what prefix size it was
> expecting.
> >     The point of the v6ops presentation and this email thread is how to “extend
> a /64” in the 3GPP use case  in slide 1 of the deck you compiled a list of options
> and of the two I had highlighted in red were the 64share v2 Cameron’s option
> and the variable slaac option.  So on the call this morning Lorenzo shot down
> 64share v2 shorter prefix option as even if the 3GPP architecture was updated
> to support longer prefixes and even is the 3GPP gateway was able to send a
> shorter prefix with A flag not set, all mobile devices per Lorenzo’s point would
> be broken as they would not accept the shorter let’s say /56 prefix to build the
> slaac 128 bit address.  So the bottom line is the 64share v2 won’t work unless
> we update RFC 4291 and remove the 64 bit boundary.
> >
> which I and others believe is Fud and as described in slide 10 of the v6ops “race
> to the bottom slide”.
> >
> > So a happy medium /80 fixed boundary I came up with that I think solves a lot
> of the issue and not just the 3GPP initial segmentation of downstream devices
> problem statement.
> >
> for shorter prefixes, why not instead create a new bottom at /80 giving 16 bits
> more of prefix length and shrinking the IID down to 48 bits.  Doing so you would
> not even have to update the 3GPP architecture as I don’t know if that would fly
> or not.  Also this solves a few other problems at the same time.
> >
> >
> dhcpv6 subnets longer prefixes for network infrastructure appliance clusters,
> NFV/VNF virtualization and server farms.  On host subnets where there is a
> chance of mix of slaac hosts with dhcpv6  devices the prefix length is stuck at
> /64.  So on these mix addressing host subnets we cannot do longer prefixes
> following our ND cache hard limit mantra to prevent ND cache exhaustion issues
> as described in RFC 6164.
> >
> > So with the /80 new fixed boundary shifting prefix length 16 bits longer and
> shortening the IID by 16 bits gives resolved the 3GPP issue which 64share can
> work as is and subtending to downstream devices will now work as a /64 is now
> equivalent to a /48 with 64k /80s.  Also BCP-690 for broadband not all
> operators have adopted the shorter prefix lengths /56 or /48
> recommendations  and now that’s not an issue as the /64 would now suffice.
> >
> growth and subtending with a single /64 allows the operators such as Verizon
> with massive subscriber base worldwide can stay with current allocations and
> don’t have to ask for /10.
> >
> paradigm, the demand for shorter blocks and wearable multiple /48 will be our
> new reality.
> >
> we would be set for the future.  Especially with IOT the demand for subtending
> will continue to grow astronomically.
> >
> on Linux kernel can do longer prefixes using RFC 4941 privacy extension or RFC
> 7217 stable IID.
> >
> > Win-Win for all.
> >
> >     Ole
> >
> > --
> >

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 23 Nov 2020 09:13:50 +0000

+1 to Mark
Tethering was never in the business model of Mobile market. Neither for carriers themselves nor for vendors.
In general this discussion is “how to enforce somebody to act against his business interests” leveraging some technology tools.
Ed/
From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: 21 ноября 2020 г. 7:20
To: Brian E Carpenter <[email-masked]>
Cc: 6MAN <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: Next step? [Re: [v6ops] The bottom is /112]

On Sat, 21 Nov 2020, 14:00 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
Joel,

I think it is also important to find out why they haven't deployed DHCPv6 to solve this problem.

Don't they think DHCPv6 infrastructure will scale? Is it just that they don't know how to scale it?

Is it a vendor / mobile operator / handset developer DHCPv6 capability chicken-and-egg problem?

The mobile industry has been resistant to tethering over the years, and probably only came to begrudgingly accept it because they couldn't prevent phone vendors from implementing Wifi and NAT, and couldn't very effectively stop their customers from using that capability (One trick I've heard of to prevent tethering working was to check if an IPv4 packet's TTL value was 64 when it arrived at the network, meaning it originated from the directly attached handset. Packets from tethered devices had a TTL of 63 so were dropped. Of course, you could set the default TTL on a tethered PC to 65 to get around that.)

I guess there might be a fairly strong mindset that there must be a fee per device attached to the network in addition to a fee for network utilisation. Providing multiple /64s would be formally acknowledging that multiple devices can be attached and a fee per device isn't and can't ever be charged, counter to the mindset.

Regards,
Mark.

Regards
   Brian Carpenter
On 21-Nov-20 14:46, Joel M. Halpern wrote:
>> On Fri, Nov 20, 2020 at 6:02 PM Joel M. Halpern <[email-masked]<mailto:[email-masked]>
>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>
>>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>      > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>>      >
>>      >      > On Thu, Nov 19, 2020 at 10:33 AM <[email-masked]<mailto:[email-masked]>
>>     <mailto:[email-masked]<mailto:[email-masked]>>
>>      >     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>>      >      > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:
>>      >      >
>>      >      >
>>      >      >
>>      >     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>>      >      >     <mailto:[email-masked]<mailto:[email-masked]>
>>     <mailto:[email-masked]<mailto:[email-masked]>>
>>      >     <mailto:[email-masked]<mailto:[email-masked]>
>>     <mailto:[email-masked]<mailto:[email-masked]>>>>> wrote:
>>      >      >      >
>>      >      > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>     <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> [email-masked]<mailto:[email-masked]>

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

---

From: Gert Doering <[email-masked]>
Date: Mon, 23 Nov 2020 13:10:33 +0100

Hi,

On Mon, Nov 23, 2020 at 01:58:33AM -0500, Gyan Mishra wrote:
> mobile handsets won???t support it.

Lorenzo is the man to talk to, what "The Android Camp" thinks is the way
forward...

Gert Doering
        -- NetMaster

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 23 Nov 2020 18:51:55 +0100

Le 23/11/2020 à 07:40, Gyan Mishra a écrit :
> 
> 
> On Sat, Nov 21, 2020 at 10:26 AM Joel M. Halpern <[email-masked]
> As I understand it, the situation is not that 3GPP has not defined
> use of DHCP.  But rather than operators have uniformly declined to
> deploy it.  (3GPP has defined DHCP for 5G for fixed access.  We have
> heard here that even that is not what the operators want.)  As such,
> asking 3GPP why they didn't deploy it seems a bit odd.
> 
> 
> 2019 statistical data below holds 87% of the global mobile market
> share and Apple 13% and Android is continuing to climb in 2020.
> Android adamantly refuses to change its position on support of
> DHCPv6.

At which point, one can wonder why Android refuses to support DHCPv6.

This has also been discussed other time.

There have been given reasons.  If I remember correctly, some of the
reasons had to do with the difficulty put on a user to manually
configure some matters exclusively related to DHCP; or maybe the 
difficulty of syncing between data received on RA vs DHCP; but I am not 
sure I remember ok.

Alex

PS: a colleague here ported a couple of open source DHCPv6(-PD) clients
to Android.  We stopped short from submitting these clients to the
respective store, because it required payment to accept them.  The
business model at the store assumes that an initial small investment
would be later covered by numerous paying uses of a DHCP app.
That problem (have to pay for acceptance) adds to the other problem of
blocking in the modem.  One could still use a DHCP client on the wifi
interface; or could use DHCP client on the 3gpp iface with a https
tunnel drilled through the modem (provided, of course, that PGW mounts a
SSL tunnel for DHCP purpose, or listens to 443 for DHCP - neither of
these is acceptable at operator, even if the DHCP-PD server software,
and https software, and SSL tunnel software are all present in that PGW.)

   I think
> that really shackles 3GPP carriers from supporting DHCPv6 is close to
>  100% of all mobile handsets won’t support it.
> 
> <https://www.statista.com/statistics/272307/market-share-forecast-for-smartphone-operating-systems/>
>
> 
> 
> 
> 
> Yours, Joel
> 
>> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] 
> <mailto:[email-masked]>>> wrote:
>> 
>> Joel,
>> 
>> 5G-based IPv6 "hot spots" and CEs [which is where this
> conversation
>> started];
>> 
>> 
>> packet's TTL value was 64 when it arrived at the network, meaning
>> it originated from the directly attached handset. Packets from
>> tethered devices had a TTL of 63 so were dropped. Of course, you
>> could set
> the
>> per device attached to the network in addition to a fee for
>> network utilisation. Providing multiple /64s would be formally
>> acknowledging that multiple devices can be attached and a fee per
>> device isn't and can't ever be charged, counter to the mindset.
>> 
>> Regards, Mark.
>> 
>> 
>> Regards Brian Carpenter On 21-Nov-20 14:46, Joel M. Halpern wrote:
>>> The nesting got me lost, so I will top post my take on the
> answer
>> to the
>>> delegation. As with anything, the real things that need to change
>>> are the
>> devices in
>>> the network.
>>> 
>>> it is. As for the exact mechanism, at the moment I lean towards
>>> Ole's
>> proposal
>>> a lot more violence to my understanding of the
> architecture and
>> software
>>> Yours, Joel
>>>> Yes, the proposal for using shorter prefixes to
> enable UE to
>> perform
>>>> Gyan> Agreed.  So that change would be to RFC 4291
> 64 bit
>> boundary
>>>> make. Any solution that enables UE to delegate addresses
> (in the
>> sense that
>>>> Yoru proposed change to the SLAAC length if anything does more
>> violence to
>>>> software if we removed the 64 bit boundary and allowed
> slaac to
>> support
>>>> any vlsm prefix lengths.
>>>> 
>>>> Hosts on the same subnet with two different masks would
> not be
>> on-net to
>>>> The solution would be a simple RA PIO flag that is set
> and older
>> hosts
>>>> Yours, Joel
>>>>> all mobile devices would stop working- as slaac
> would not
>> would be
>>>>> effectively broken.
>>>>> 
>>>>> So that a major gap and the only solution is
> updating RFC
>> 4291
>>>> removing
>>>>> Basically stealing 16 bits for network prefix out
> of the
>> IID, still
>>>>> bits less helps traceability but is still long
> enough for
>> 48 bits of
>>>>> This /80 would be a nice optimal balance as it
> would keep
>> wired
>>>>> The IID as it’s less than the current 64 bit
> cannot use
>> MAC based
>>>> EUI64
>>>>> /80 would be supported allowing for further
> segmentation of
>>>> downstream
>>>>> devices.
>>>>> 
>>>>> proliferation where operators in light of BCP
> RIPE-690,
>> are sill
>>>>> 3GPP architecture specification can be updated to
> support
>> shorter
>>>>> mainstream and will soon be a real world reality
> and as
>> fixed 5G
>>>>> clamoring after the RIR for massive blocks, I
> would say
>> less than /8
>>>>> more like a /5 or /4.  If you do the math on the
> way high
>> side a /10
>>>>> yields 7 bits so 128 divided by 5 RIRs yields 24
> ISPs per RIR
>>>> which is
>>>>> With the massive proliferation of IOT devices and
> just about
>>>> every home
>>>>> remaining /3 as well as all unallocated blocks to
> subvert
>> RIR IPv6
>>>>> address space depletion.
>>>>> 
>>>>> Playing Monday night quarterbacking in hindsight
> we would
>> never
>>>> think
>>>>> This would also fix the day 1 issue I mentioned
> allowing
>> mix of
>>>> slaac
>>>>> The variable slaac solution draft proposes a new
> RA PIO flag
>>>> that would
>>>>> compatibility so that devices not supporting woud
> ignore
>> the flag
>>>> and
>>>>> devices on newer code supporting would use the
> flag.  We
>> definitely
>>>>> was able to successfully test any length mask and
> random IID
>>>> generation
>>>>> both RFC 4941 privacy extension as well as stable
> IID RFC
>> 7217.
>>>>> 
>>>>> 
>>>> 
>> 
> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>>
>
> 
>>>> 
>>>> 
>> 
> <https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/>>>>
>
> 
>>>> 
>>>>> If everyone is in agreement with what I have
> stated on this
>>>> thread, I
>>>>> would like to ask the chairs for WG adoption as
> this is a
>> WG effort.
>>>>> 
>>>>> I would like to garner support from all 6MAN
> members with
>> full
>>>> consensus
> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>> <mailto:[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>> wrote:
>>>>> 
>>>>> I am missing something in your reasoning. You seem to say at
>>>>> one point that (to
> paraphrase) "we
>> can't
>>>> do this
>>>>> what to do with the information.  I do not see how that
>>>> differentiates any of
>>>>> the solutions. (Except "don't do anything",
> which I
>> think we
>>>> do not
>>>>> want to take.)
>>>>> 
>>>>> Yours, Joel
>>>>> 
>> <mailto:[email-masked] <mailto:[email-masked]>>>>
>> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>>>
> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> <[email-masked]
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>>>> wrote:
>>>>>>> 
>>>>>>> You would need a new option. It
> would likely be
>>>> useful for the
>>>>>> better than using the existing DHPCv6
> protocol
>> packets?
>>>>>>> 
>>>>>> The point of the v6ops presentation
> and this
>> email
>>>> thread is
>>>>> how to
>>>>>> So now we had thrown out the longer >64
> due to
>> race to
>>>> bottom
>>>>> worries
>>>>>> a lot of the issue and not just the 3GPP
> initial
>>>> segmentation of
>>>>>> Since we have to update RFC 4291 for
> 64share v2 to
>> work
>>>> anyways
>>>>> to allow
>>>>>> for shorter prefixes, why not instead
> create a new
>> bottom
>>>> at /80
>>>>> giving
>>>>>> infrastructure and dhcpv6 subnets longer
> prefixes
>> for network
>>>>>> farms.  On host subnets where there is a
> chance of
>> mix of
>>>> slaac
>>>>> hosts
>>>>>> So with the /80 new fixed boundary shifting
> prefix
>> length
>>>> 16 bits
>>>>> longer
>>>>>> and shortening the IID by 16 bits gives
> resolved
>> the 3GPP
>>>> issue
>>>>> which
>>>>>> for broadband not all operators have
> adopted the
>> shorter
>>>> prefix
>>>>> lengths
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g
> <https://www.google.com/maps/search/ent+allocations+and+don%E2%80%99t+have+to+ask?entry=gmail&source=g>>>
>
> 
>>> for /10.
>>>>>> 
>>>>>> Making that 16 bit shift now to /80 making
> a /64
>> the new
>>>> /48 will
>>>>> give
>>>>>> broadband and 3GPP subscribers a ton of
> space to
>>>> subtending their
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>>
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g
> <https://www.google.com/maps/search/tested+on+Linux+kernel+can+do+longer+p?entry=gmail&source=g>>>>refixes
>
> 
>>>> using RFC 4941 privacy
>>>>>> <http://www.verizon.com/
> <http://www.verizon.com/> <http://www.verizon.com/ 
> <http://www.verizon.com/>>
> <http://www.verizon.com/ <http://www.verizon.com/>>>>>
>>>>>> 
>>>>>> *Gyan Mishra*
>>>>>> 
>>>>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ v6ops
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:[email-masked]>>>>
> <https://www.ietf.org/mailman/listinfo/v6ops>>>>
>>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> 
>>>> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD
>>>> 
>>>> 
>>> 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] <mailto:[email-masked]>
>> 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
> <https://www.ietf.org/mailman/listinfo/ipv6>>
>> 
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6 
> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD
> 
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Nov 2020 09:23:25 +1300

I've had several guesses but RFC 8929 still puzzles me :-)

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Nov 2020 09:42:52 +1300

OK, that was cheating: citing an RFC the day before it was published ;-).

Regards
   Brian