Subject: Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2020 10:41:17 +1300

Hi authors,

> 8.  Greater than 64 bit prefix usage by ISPs is strictly prohibited
> 
>    The RA flag S bit setting proposed by this draft for greater or less
>    then /64 bit prefix feature is strictly for enterprises and broadband
>    subscriber customer use only. 

How do you propose to enforce this, to prevent a race to the bottom
between ISPs? Do you have a funding source for the new Protocol Police?

It's hard to see why this draft is needed anyway. All that is needed
is to remove the "64 bit" statement from the addressing architecture,
which the WG has consistently failed to reach consensus about.

>    o  1: Variable length interface identifier is enabled (ignored by
>       hosts not supporting)

How does this work if the router expects hosts to use shorter IIDs but
hosts in fact use standard 64 bit IIDs? As far as I can see, SLAAC,
DAD and default address selection will only work correctly if all
nodes on a given link agree about the prefix and IID lengths. For
all existing devices, the baked-in code assumes that both are 64.

If a 64 bit node wants to send to a destination with the same
64 bit prefix that is in fact off-link because the on-link prefix
is actually supposed to be /68, what happens?

Regards
   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Nov 2020 02:20:41 -0500

Brian

Responses in-line

Thanks

Gyan

> between ISPs? Do you have a funding source for the new Protocol Police?

   Gyan> Understood that there is no way we can police.  Working as a Tier
1 ISP with Verizon, I can say that from a cost benefit analysis trade off
that it would be cost prohibitive to manage vlsm to customers.

> which the WG has consistently failed to reach consensus about.

    Gyan>  This topic has come up many times over the years in heated
debate and this is another instance of that.  Agreed.  However, what makes
this instance different is that we have a major problem to be solved with
4G  &  now as 5G is rolled out, segmentation is of utmost importance.  I
think in the past we have not had a major problem to be solved and so this
change being proposed did not gain traction,  but now as 5G becomes the
"norm" as it will compete directly with broadband that customers will start
using 5G in SOHO as well as other environments.   This is a major issue
that has come up with the ramp up for 5G IPv6 only deployments.  The
problem with increasing the size of the handset allocation from /64 is
problematic as well just due to the massive mobile subscriber base as I
believe the last count of mobile handsets worldwide is 15 Billion.  The
segmentation as well for 4G & 5G use cases with IOT as well would be
beneficial.  Also as 5G swallows up the broadband subscriber base this
problem gets even worse with not having segmentation capability.

>     Gyan> Valid point. Any subnet would require all hosts to support the
same vlsm mask just a we do today with IPv4.  The only way to get around
that which is common is if you have multiple IPv6 addresses on a LAN subnet
on a router and RA PIO sends all the prefixes down to the host and then the
host via Default address selection picks the address to use.  The goal is
to allow slaac to not have a fixed iid dependency as defined in RFC 4291
from an addressing standpoint have parity with static and stateful so that
you could have a greater than /64 prefix length with a mix of hosts static,
dhcp & slaac all on the same subnet.  Existing IPv6 deployments have
shackled static & dhcpv6 unfortunately due to the 64 bit iid boundary
restriction so that slaac devices can be supported.  So even though static
& dhcpv6 support vlsm, it is not commonly deployed due to the slaac fixed
64 bit iid issue and possible interop issues that could crop up if slaac
devices came up on LAN with dhcpv6 or static vlsm masking.  This has been a
day 1 operations issue that all operators have lived with unfortunately.

> is actually supposed to be /68, what happens?

    I don't think you could have mix of vlsm masked hosts on the same
subnet as that would not work.  That is not at all what is being suggested
in this draft.  What is being suggested is variable length prefix greater
or less then .64 bit and for longer prefixes use of RFC 4941 or RFC 7217
random iid that does not have modified EUI mac dependency.   In the
variable mask scenario all hosts would have the same mask.

A point that came up a year or so ago with the classless draft below was
related as well to the race to the bottom which comes up every time but
also the variable length sizing and I think there was some contention as to
what size to support.  So with this draft as it supports any length prefix,
it would be supported with any length random iid would be generated RFC
4941 or stable RFC 7217 style whichever is desired.  Greater than or less
then /64 length prefixes and corresponding iid would be supported.

https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05

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

-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 3 Nov 2020 03:04:07 -0500

With 5G network slicing will become a formidable part of the paradigm shift
from shared resources to network resource isolation at the radio and RAN
layers.  The use case for being able to provide critical segmentation for
network slices makes it an industry imperative to be able support variable
IID lengths with slaac as all 5G deployments worldwide will be IPv6 only
from the start.

*Gyan Mishra*

---

From: [email-masked]
Date: Tue, 3 Nov 2020 10:02:12 +0100

> With 5G network slicing will become a formidable part of the paradigm shift from shared resources to network resource isolation at the radio and RAN layers.  The use case for being able to provide critical segmentation for network slices makes it an industry imperative to be able support variable IID lengths with slaac as all 5G deployments worldwide will be IPv6 only from the start.

You'd likely find most people on this group thinking of 5G as just "more of the same"; access to the Internet.
At least I struggled understanding what there is about 5G that would require a change in IPv6 addressing models.

Are there any of the problems/use-cases that cannot be solved by assigning a shorter prefix than /64 to the end-user networks?

Best regards,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Tue, 03 Nov 2020 12:28:18 +0100

>is actually supposed to be /68, what happens?

I don't expect any problems here. In the past I did advertise a /96 prefix
om my network and nothing bad happened.

What is supposed to happen is that a host only configures a SLAAC address if
the IID length and the prefix length add up to 128. So existing hosts should
just ignore anything that is not a /64. No address, no need to participate in
DAD.

As for an on-link prefix, this is completely separate from SLAAC. Today
you could have an on-link /68 and use that for DHCP IA_NA and all hosts
should be able to use that.

My personal opinion on this draft is that we spend enough discussing this,
The problem statement doesn't seem to contain new information. 

Of course it is worth looking (probably in v6ops) if there are clear gaps
in our exiting solutions for distributing prefixes.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Nov 2020 09:20:25 +1300

> Are there any of the problems/use-cases that cannot be solved by assigning a shorter prefix than /64 to the end-user networks?

Is it really the case that 5G hasn't fixed the notorious 4G bug of only allowing /64s? Or is it a matter of operational choice by 5G operators?

   Brian

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 01:35:54 -0500

Hi Ole

Responses in-line

On Tue, Nov 3, 2020 at 4:02 AM <[email-masked]> wrote:

> > With 5G network slicing will become a formidable part of the paradigm
> shift from shared resources to network resource isolation at the radio and
> RAN layers.  The use case for being able to provide critical segmentation
> for network slices makes it an industry imperative to be able support
> variable IID lengths with slaac as all 5G deployments worldwide will be
> IPv6 only from the start.
>
> At least I struggled understanding what there is about 5G that would
> require a change in IPv6 addressing models.

  Gyan> With 5G you have mobile handset 5G and fixed 5G that would replace
broadband.  So the fixed 5G would be subject to BCOP RIPE-690 and
recommendations for /56 allocations just as with broadband and maybe bigger
allocations for network slicing.  The big change with 5G 10G cell bandwidth
is the concept of network slicing.  So today 4G front hall is handset to
cell tower and then RAN radio VPN is a single VPN backhaul to the core and
out to the internet.  So with 5G the concept of network slicing is the big
change as you have 10G bandwidth to the mobile device.  So the the mobile
handset would sit on a regular VPN network slice that is SR-TE steered over
the core.  So network slicing does not have any impact on the handset as it
sits on a single BAU normal RAN backhaul VPN.

So I was mistaken that that handset network slicing /64 segmentation is an
issue with 5G. The concept of network slicing framework is on the fronthaul
mobile to cell tower and backhaul cell tower to core, so here as far as
this draft, network slicing as that is seamless to the mobile handset does
not impact this draft as far as /64 segmentation.

However, the issue mentioned in the problem statement draft with
segmentation with 4G, the same issue exists with 5G on the customer network.

>
>
> Are there any of the problems/use-cases that cannot be solved by assigning
> a shorter prefix than /64 to the end-user networks?

   Gyan> The issue here with 4G providers to be able to force providers to
go with a shorter prefix is impossible and similar to the issue we see with
the v6ops flash renumbering issue and even in light of BCOP RIPE-690 that
broadband operator’s PD allocations is /64 and not /56 as recommended in
BCOP and due to the impact of flash renumbering events we are now changing
the VL PL to short timers to age our the stale prefix during a renumbering
event.  So the standard on 4G and as it is the same standard for 5G
handsets allocation, a /64, and 4G and even 5G operators for mobile handset
provisioning do not plan to make it a shorter prefix.  So either customers
end up suffering with flash renumbering events or you update the standard.
Same issue we are faced with here with wireless providers and forcing them
to dole out shorter prefix.

Fixed 5G replacement for broadband I mentioned, not to be confused with 5G
mobile handset, would follow BCOP RIPE-690 and I believe will go in with
larger allocation like a /56 or larger.  So the fixed 5G network slicing
how it comes into play as a value proposition and massive benefit to
customers, is it can now have the front haul 5G to tower and back haul
tower to core now be provisioned to the fixed 5G with a normal BAU slice
template for normal traffic and at the same time separate slices for
special Enhanced VPN over SRv6 core SR-TE steered with dedicated resources
and traffic  isolation and special QoS prioritization for applications such
as IOT, E911 emergency services, or utilities etc.

https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 01:46:47 -0500

On Tue, Nov 3, 2020 at 3:48 PM Brian E Carpenter <
[email-masked]> wrote:

> > Are there any of the problems/use-cases that cannot be solved by
> assigning a shorter prefix than /64 to the end-user networks?
>
> Is it really the case that 5G hasn't fixed the notorious 4G bug of only
> allowing /64s? Or is it a matter of operational choice by 5G operators?

    Operational choice for operators.  So the same segmentation mentioned
in the draft issue that exists is with 4G also exists with 5G but not in
the context of network slicing.   In my reply to Ole I clarified the
difference between mobile handset 5G and fixed 5G where fixed 5G would be a
broadband replacement and would use the value added at a premium service of
network slicing for isolated VPN with dedicated for critical services such
as E911, utilities etc.  For fixed 5G I would think as new deployments
would follow BCOP RIPE-690 with shorter prefixes per network slice.

-- 

*Gyan Mishra*

---

From: [email-masked]
Date: Wed, 4 Nov 2020 09:45:54 +0100

Gyan,

>    Gyan> The issue here with 4G providers to be able to force providers to go with a shorter prefix is impossible and similar to the issue we see with the v6ops flash renumbering issue and even in light of BCOP RIPE-690 that broadband operator’s PD allocations is /64 and not /56 as recommended in BCOP and due to the impact of flash renumbering events we are now changing the VL PL to short timers to age our the stale prefix during a renumbering event.  So the standard on 4G and as it is the same standard for 5G handsets allocation, a /64, and 4G and even 5G operators for mobile handset provisioning do not plan to make it a shorter prefix.  So either customers end up suffering with flash renumbering events or you update the standard.  Same issue we are faced with here with wireless providers and forcing them to dole out shorter prefix.

I don't understand the coupling you make between the 64 bit boundary and flash renumbering.

> Fixed 5G replacement for broadband I mentioned, not to be confused with 5G mobile handset, would follow BCOP RIPE-690 and I believe will go in with larger allocation like a /56 or larger.  So the fixed 5G network slicing how it comes into play as a value proposition and massive benefit to customers, is it can now have the front haul 5G to tower and back haul tower to core now be provisioned to the fixed 5G with a normal BAU slice template for normal traffic and at the same time separate slices for special Enhanced VPN over SRv6 core SR-TE steered with dedicated resources and traffic  isolation and special QoS prioritization for applications such as IOT, E911 emergency services, or utilities etc.
> 

OK, so the problem is:
"How do you connect an end-user network with multiple links to a provider who only allocates a /64 to the site.".

There is a conundrum here. A reason for the 64-bit boundary is that it forces the provider to give at least a /64.
That design decision seems to have had the intended effect. You don't see any providers assigning less address space than the /64.

If we were to relax that limitation, then there is a fear that providers will start assigning fewer addresses to end-users. Down to a single address like we see in IPv4.

The conundrum then is:
How do we ensure providers allocate at least a /64 of address space to end-users, and at the same time allow end-users to extend a network with only a /64 assigned to it.

Answer that and we can make progress.

Best regards,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Nov 2020 17:51:40 +0900

On Tue, Nov 3, 2020 at 4:27 PM Gyan Mishra <[email-masked]> wrote:

> that has come up with the ramp up for 5G IPv6 only deployments.
>

There is already a solution to this: use DHCPv6 PD on 5G networks. It's
been supported since 3GPP release 10 several years ago.

---

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

Exactly!

In fact, not using it is very bad when you want to offer 5G broadband to customers that may not have access to a wireline. If they aren’t able to get /48 thru the 5G “modem”, how come they can segment their network? This is just creating NAT for IPv6, as if a 5G broadband customer needs to have multiple /64 VLANs, they have no other way.

Regards,

Jordi

@jordipalet

El 4/11/20 9:52, "ipv6 en nombre de Lorenzo Colitti" <[email-masked] en nombre de lorenzo=[email-masked]> escribió:

    Gyan>  This topic has come up many times over the years in heated debate and this is another instance of that.  Agreed.  However, what makes this instance different is that we have a major problem to be solved with 4G  &  now as 5G is rolled out, segmentation is of utmost importance.  I think in the past we have not had a major problem to be solved and so this change being proposed did not gain traction,  but now as 5G becomes the "norm" as it will compete directly with broadband that customers will start using 5G in SOHO as well as other environments.   This is a major issue that has come up with the ramp up for 5G IPv6 only deployments.

There is already a solution to this: use DHCPv6 PD on 5G networks. It's been supported since 3GPP release 10 several years ago.

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

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

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

---

From: Ca By <[email-masked]>
Date: Wed, 4 Nov 2020 07:45:55 -0800

> been supported since 3GPP release 10 several years ago.

Has any mobile provider deployed dhcpv6 pd?

Perhaps the mobile providers have seen what an operational nightmare dhcpv6
pd is and... are like nope.

I am in favor of the ietf opening their eyes to a better solution.

Rfc7278 is universally deployed because it is easy.

Can we do better (more /64s) and easy ?

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 10:54:22 -0500

> been supported since 3GPP release 10 several years ago.

   Agreed.  Fixed 5G broadband agreed would use the current wired broadband
DHCPv6 PD and would follow the BSOP RIPE-690 and I think would use the
recommended shorter prefix like a /56.  As fixed 5G would take advantage of
the value added at a premium network slicing capabilities for the front
haul and backhaul I can see Broadband 5G getting even a /48.  The issue
mentioned in the draft is related to 4G as well as 5G “mobile handsets” and
getting a /64 allocation which has been the standard which cannot be
segmented by the Subscriber customer end.  I don’t see the mobile handset
/64 prefix being going any shorter even for 5G.  For 5G the business driver
for larger allocation is for the value added network slicing capabilities
and the is relevant only for fixed broadband 5G which will replace wired
broadband.  Mobile handset 5G will not get network slicing capabilities as
it would use the front hall handset to tower backhaul tower to core Normal
RAN Radio VPN.  Compared to Fixed 5G broadband which would have
capabilities of being provisioned for high priority network slice Enhanced
VPN with resource isolation and dedicated resource characteristics.

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 10:57:45 -0500

On Wed, Nov 4, 2020 at 4:29 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Exactly!
>
>
>
> In fact, not using it is very bad when you want to offer 5G broadband to
> customers that may not have access to a wireline. If they aren’t able to
> get /48 thru the 5G “modem”, how come they can segment their network? This
> is just creating NAT for IPv6, as if a 5G broadband customer needs to have
> multiple /64 VLANs, they have no other way.
>
>
>
   Gyan> See my response to Lorenzo.  Fixed 5G broadband replacement of
wired broadband would use DHCPV6 PD and get much larger allocations than a
/64 and would follow the BCOP RIPE-690 practices.  One of the reasons for a
much larger allocation is for the value added service at a premium network
slicing capabilities.

> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 4/11/20 9:52, "ipv6 en nombre de Lorenzo Colitti" <
> [email-masked] en nombre de lorenzo=[email-masked]>
> escribió:
>
>
>
> -------------------------------------------------------------------- IETF
> IPv6 working group mailing list [email-masked] Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> 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.
>
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 11:27:22 -0500

On Wed, Nov 4, 2020 at 3:45 AM <[email-masked]> wrote:

> >    Gyan> The issue here with 4G providers to be able to force providers
> to go with a shorter prefix is impossible and similar to the issue we see
> with the v6ops flash renumbering issue and even in light of BCOP RIPE-690
> that broadband operator’s PD allocations is /64 and not /56 as recommended
> in BCOP and due to the impact of flash renumbering events we are now
> changing the VL PL to short timers to age our the stale prefix during a
> renumbering event.  So the standard on 4G and as it is the same standard
> for 5G handsets allocation, a /64, and 4G and even 5G operators for mobile
> handset provisioning do not plan to make it a shorter prefix.  So either
> customers end up suffering with flash renumbering events or you update the
> standard.  Same issue we are faced with here with wireless providers and
> forcing them to dole out shorter prefix.
>

   Gyan> This was an apples versus oranges analogy not comparison.  So to
clarify what I was trying to say is that with flash renumbering issue
instead of putting the onus on the service provider to fix the issue with
flash renumbering to broadband customers we are changing the standards now
to use very short 2 hour timers for VL and PL.  Similarly as an analogy it
will be very difficult to get 3GPP 4G and 5G mobile handset scenario to
change to provide shorter prefix.  The standard is a /64 allocation to
mobile handsets and that will more than likely remain and not change

>
>
> > Fixed 5G replacement for broadband I mentioned, not to be confused with
> 5G mobile handset, would follow BCOP RIPE-690 and I believe will go in with
> There is a conundrum here. A reason for the 64-bit boundary is that it
> forces the provider to give at least a /64.
> That design decision seems to have had the intended effect. You don't see
> any providers assigning less address space than the /64.
>
> If we were to relax that limitation, then there is a fear that providers
> will start assigning fewer addresses to end-users. Down to a single address
> like we see in IPv4.
>
> The conundrum then is:
> How do we ensure providers allocate at least a /64 of address space to
> end-users, and at the same time allow end-users to extend a network with
> only a /64 assigned to it.
>

   Gyan>

As a representative SME of Verizon a tier 1 service provider and one of the
largest wireless carriers worldwide I can make a guarantee that it won’t
change  and if Verizon made the /64 allocation part of our marketing
strategy that would deter any other operators from wanting to go with
longer prefixes as they would loose business.  As a tier 1 we can work with
the other major carriers we have partnership with to garner support among
the largest wireless providers.

We could also write an RFC BCOP that the minimum requirement allocation is
a /64 and that operators must abide by that.

We could also develop a RIPE doc and publish with ISOC that mandates the
standard as well as work with all operator groups worldwide to ensure they
abide by the BCOP.

Another point is the OPEX overhead costs of management and maintenance of
vlsm to customers which is had to be accounted for 0 monetary gain for the
additional OPEX costs versus /64 size to all customers.

I would say of all the points above in addition, operators are driven just
as any business by monetary gain and what is the bottom line ROI.  If the
answer is 0 why change from a /64 allocation.  As the IPv6 allocations for
providers is leaps and bounds way more massive as compare to IPv4, there is
not any address space saving that could be gained which could translate
into ROI to go with a smaller than /64 allocation.

-- 

*Gyan Mishra*

---

From: Philip Homburg <[email-masked]>
Date: Wed, 04 Nov 2020 17:53:28 +0100

>standard as well as work with all operator groups worldwide to ensure they

If mobile providers don't comply with RIPE-690 (and many other documents that
tell ISPs that just providing a /64 is not enough), then why do you expect
that any new documents have any effect?

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 4 Nov 2020 18:02:44 +0100

> that any new documents have any effect?

I discovered that document, thank you.

RIPE-690 says "IPv6 is not the same as IPv4. In IPv6 you assign a short 
prefix to each end-user site, so they are able to have as many subnets 
(/64s)"

That is a good direction.  But 'site' is not a 'smartphone'.  The text 
should say 'site and smartphone', or 'site and User Equipment'. 
Otherwise cellular operators do not feel concerned about that RIPE document.

I know of other even stronger than RIPE requirements that operators will 
likely overlook.  The document that sells 5G licenses to mobile 
operators requires them to do several things, among which to use 'IPv6 
routing compatibility' in 5G.  That way of formulating sounds 
encouraging for the IPv6-inclined but also is a way to do nothing: any 
current IP router is 'compatible' with IPv6 routing out of the box. 
Should that requirement have been formulated such as: MUST offer native 
IPv6-only default routes to end users, and provided we had a good 
definition of 'IPv6-only', then there would be more chances for IPv6 
deployment.

RIPE should clarify its document.

Alex

---

From: Philip Homburg <[email-masked]>
Date: Wed, 04 Nov 2020 18:21:00 +0100

> RIPE should clarify its document.

What about Section 4.2.4:

4.2.4. Considerations for Cellular Operators

There is a clear exception to the rule described above when assigning
prefixes in a cellular network. In this case, a /64 will need to
be provided for each PDP context for cellular phones, whereas for
LTE modems/routers, i.e. in the case of broadband by means of
cellular access, it will still be necessary to choose a /48 or /56
in accordance with the aforementioned considerations.

Though I don't know why there is an exception for mobile phones.

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 13:26:31 -0500

On Wed, Nov 4, 2020 at 11:53 AM Philip Homburg <
[email-masked]> wrote:

>     RIPE-690 is for wired broadband not mobile operators.  Mobile
operators have always used /64.  For mobile operators guidance when making
your phone a mobile hotspot RFC 7278 provides guidance but its still a /64
and not a larger space.

https://tools.ietf.org/html/rfc7278

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 4 Nov 2020 17:15:26 -0500

RIPE-690 is primarily in the context of flash renumbering events by wired
broadband Carriers.

That does not apply to mobile carriers - mobile handsets.

*Gyan Mishra*

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2020 11:37:33 +1300

On 05-Nov-20 04:45, Ca By wrote:
> 
> 
> On Wed, Nov 4, 2020 at 12:52 AM Lorenzo Colitti <lorenzo=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Tue, Nov 3, 2020 at 4:27 PM Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Perhaps the mobile providers have seen what an operational nightmare dhcpv6 pd is and... are like nope. 

Perhaps that needs to be documented over in v6ops.
 
> Rfc7278 is universally deployed because it is easy. 

As far as I can tell that is no use for the case of routed network connected to a hotspot, since there is still only one /64 prefix.
 
> Can we do better (more /64s) and easy ?

You mean multiple /64s for a single mobile device? Rather than fixing 3GPP to support shorter prefixes, which seems simpler.

    Brian

---

From: Ca By <[email-masked]>
Date: Wed, 4 Nov 2020 16:15:14 -0800

On Wed, Nov 4, 2020 at 2:37 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >             Gyan>  This topic has come up many times over the years in
> heated debate and this is another instance of that.  Agreed.  However, what
> makes this instance different is that we have a major problem to be solved
> with 4G  &  now as 5G is rolled out, segmentation is of utmost importance.
> I think in the past we have not had a major problem to be solved and so
> this change being proposed did not gain traction,  but now as 5G becomes
> the "norm" as it will compete directly with broadband that customers will
> start using 5G in SOHO as well as other environments.   This is a major
> issue that has come up with the ramp up for 5G IPv6 only deployments.
> >
> >
> >     There is already a solution to this: use DHCPv6 PD on 5G networks.
> It's been supported since 3GPP release 10 several years ago.
> >
> >
> As far as I can tell that is no use for the case of routed network
> connected to a hotspot, since there is still only one /64 prefix.
>
> You mean multiple /64s for a single mobile device? Rather than fixing 3GPP
> to support shorter prefixes, which seems simpler.
>
>     Brian

Mobile providers have not deployed dhcp pd in the last 10 years.

As a mobile provider, my bet is the next 10 years may be no better.

Yet, rfc 7278 is deployed in many places in mobile

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Nov 2020 00:44:27 +0900

So are you suggesting defining a "delegated prefix" RA option that would
only be correct to use on point-to-point links?

Technically I think that would work and would be quite simple to implement.
I think someone might have proposed it already, perhaps Alexandre?

I think the downsides are a) we already have something that does this
(DHCPv6 PD), and b) if such an option were ever to be sent on a
non-point-to-point link, it would cause havoc.

On Thu, Nov 5, 2020 at 9:15 AM Ca By <[email-masked]> wrote:

>> You mean multiple /64s for a single mobile device? Rather than fixing
>> 3GPP to support shorter prefixes, which seems simpler.
>>
>>     Brian
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 17:49:46 +0100

> How do we ensure providers allocate at least a /64 of address space to end-users, and at the same time allow end-users to extend a network with only a /64 assigned to it.

I want to not forget to If there is a future version of this draft then 
I want to make sure to add the problem of "Race to the Bottom" in the 
Variable SLAAC Problem Statement draft.

We could also try to answer how one could make sure the providers 
allocates _at least_ a /64 to an end user.  I think there is an RFC for 
that, that we might cite.  And a RIPE note too.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 18:53:22 +0100

Hi Brian,

Le 02/11/2020 à 22:41, Brian E Carpenter a écrit :
>> The RA flag S bit setting proposed by this draft for greater or 
>> less then /64 bit prefix feature is strictly for enterprises and 
>> broadband subscriber customer use only.
> 

The race to the bottom problem should be mentioned, especially if there
are subsequent versions of these drafts.

>  is to remove the "64 bit" statement from the addressing 
> architecture, which the WG has consistently failed to reach
> consensus about.

But it might be possible to suggest alternative paths like INFORMATIONAL
or EXPERIMENTAL.

> How does this work if the router expects hosts to use shorter IIDs 
> but hosts in fact use standard 64 bit IIDs?

That is a good question.  There is an implementation in linux of IIDs
65bit, that I let mention later.  A Host running that implementation of
SLAAC will not understand an openBSD router sending it an RA lacking
that bit, and vice-versa.  Worse, the FreeBSD implementation of SLAAC
does not do SLAAC with a 65bit IID.  The three are incompatible.  But a
document could make them interoperable.

 From the standpoint of implementing a variable plen SLAAC in linux there
are more problems, other than the conceptual problems discussed here at
IETF.  These problems include the acceptance of patches in the mainline,
which depend on IPR and on RFC existence or absence.  There are also
problems of maintaining patches during a time of discussing it at IETF.
  These patches are difficult to maintain because their target C and
header files change constantly.

> As far as I can see, SLAAC, DAD and default address selection will 
> only work correctly if all nodes on a given link agree about the 
> prefix and IID lengths. For all existing devices, the baked-in code 
> assumes that both are 64.

DAD works already with IIDs and plens different than 64.

Default address selection - I dont know, because I did not try.

> If a 64 bit node wants to send to a destination with the same 64 bit 
> prefix that is in fact off-link because the on-link prefix is 
> actually supposed to be /68, what happens?

I think that needs to be checked.

Alex

> Regards Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2020 19:05:24 +0100

Le 03/11/2020 à 21:20, Brian E Carpenter a écrit :
>>> With 5G network slicing will become a formidable part of the 
>>> paradigm shift from shared resources to network resource 
>>> isolation at the radio and RAN layers.  The use case for being 
>>> able to provide critical segmentation for network slices makes
>>> it an industry imperative to be able support variable IID
>>> lengths with slaac as all 5G deployments worldwide will be IPv6
>>> only from the start.
>> 
>> You'd likely find most people on this group thinking of 5G as just 
>> "more of the same"; access to the Internet. At least I struggled 
>> understanding what there is about 5G that would require a change
>> in IPv6 addressing models.
>> 
> Is it really the case that 5G hasn't fixed the notorious 4G bug of 
> only allowing /64s?

I think yes, it is really the case.

A 5G network will see many modifications (from 4G) with the New Radio
access, but is not likely to make many change to GGSN and SGSN, which 
are the entities involved in IP address allocation.  I think.

One operator's goal to migrate to 5G is to make it as easy to migrate
for end users as possible.  Just notice higher bandwidth.  On a
smartphone, there will be just a small acronym '5G', hardly seen without
glasses, in the list of acronyms GPRS, 3G, H+, 4G and 4G+ next to 5
small bars showing signal quality.  And no, 5 in the number of bars is 
just a coincidence: they have always been 5 even in times of 2G.

This is how it happened when it moved from 3G to 4G and still kept that /64.

Where I live the next 5G deployment for the masses arrives at the
earliest in December.  At that point it's easy to try it and answer to
the question you raise: is 5G offering something else than a /64 to
smartphones.

(there is one little issue in trying that very quickly, in that the
operator that claims to do 5G first among all the others also has
something against IPv6, believing in essence IPv6 is not needed
anywhere, including 5G; so the trial might not happen that quickly).

> Or is it a matter of operational choice by 5G operators?

I dont know.

Some operators say they depend on what the router manufacturers do.
Router manufacturers do put this DHCPv6-PD option in, but for
convenience, also keep the 64bit limit in most places.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Thu, 5 Nov 2020 10:28:51 -0800

Hi,

> Yet, rfc 7278 is deployed in many places in mobile

If mobile providers have not implemented DHCP PD in the last 10 years, why would anyone expect them to implement some new mechanism with the similar functionality.   It seems to me that they don’t want to support functionality like this.

Bob

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Nov 2020 07:00:19 +1100

On Fri, 6 Nov 2020, 02:45 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

> Technically I think that would work and would be quite simple to
> implement. I think someone might have proposed it already, perhaps
> Alexandre?
>

I worked on a production deployment of PD back in 2010 and then when I
moved to another city was an end-user of it for the next 8 years. IPv6
enabled became enabled by default on new customer connections about a year
after the 2010 deployment.

I still keep in contact with people there, there are no reported PD
"nightmares". It just worked.

I'd also expect to have heard about PD nightmares on either the 6man or
v6ops mailing lists.

The first time I've even heard the term "PD nightmare" is below.

>>> architecture,

---

From: Alexandre PETRESCU <[email-masked]>
Date: Thu, 5 Nov 2020 21:38:10 +0100

--
Alexandre Petrescu
[email-masked], tél 0169089223

Le 05/11/2020 à 19:28, Bob Hinden a écrit :
> If mobile providers have not implemented DHCP PD in the last 10
> years, why would anyone expect them to implement some new mechanism
> with the similar functionality.   It seems to me that they don’t want
> to support functionality like this.

If we run SLAAC-GUA with a plen 65 and IID 63 _behind_ the Mobile 
Router, not on its 3GPP interface, then the operator is not concerned by 
this solution.

In other words, the mobile operator could continue to do SLAAC-64, or 
DHCPv6-PD if it so wishes, and the 3GPP modem manufacturer continue to 
do 64 and block multicast.  But the SLAAC-65 and IID-63len on the 
Ethernet interface would allow to make that 'hotspot' work.

Alex

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Thu, 5 Nov 2020 20:53:51 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Alexandre PETRESCU

Yes, as an observer here, don't mobile operators decide what features their phones should have? In the US, this seems very much the case. Allowing longer than /64 prefixes would only impact what is behind their own captive phones.

Even if this can’t be used today, OS limitations or whatever, it doesn’t have to create big impacts industry-wide, does it? The longer prefixes can be introduced gradually, only with the newer phones, allowing these new pones to create more sophisticated hotpots.

The bigger deal would be for cars, trucks, buses, given that these are being assigned /64 only. You need better than a flat network inside these vehicles. For instance, infotainment, diagnostics, and autonomous/assisted driving communications, should not coexist in one IP subnet. The autonomous/assisted driving comms will certainly be separated into separate layer 3 networks too.

Again, sooner or later, my bet is, we would be heading in this direction.

Bert

---

From: [email-masked]
Date: Fri, 6 Nov 2020 10:05:53 +0100

Cameron,

> Can we do better (more /64s) and easy ?

It's difficult to design a better solution without understanding what "operational nightmares" mean.
Would you mind elaborating?

Best regards,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 6 Nov 2020 09:27:28 +0000

Hi all,
You are discussing here the very big and principal question indeed.
IPv6 has been designed with 64bit address space. Other 64bits have been abused for L2 address inserted into L3 address.
It could potentially has some advantages and disadvantages.
Example for potential advantage: Address Resolution Protocol (ND) is not needed.
Example of potential disadvantage: almost half of L3 address bits are wasted (a few bits are needed inside the link).
I personally do not see how advantages have been leveraged and disadvantages mitigated. Hence, the request to expand address space above 64bit looks valid.
But the opposite argument that "64bit is enough address space for mankind in the next century" is the valid too.
Tough dilemma.
IMHO: if There are no clear reasons - then it is better to keep it "as it is now". My opinion: I have not seen clear reasons yet to expand IPv6 address space.
Examples of some bad practices that do not have reasons behind - is not counted as "the reason".
Eduard

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 06:55:00 -0300

> Example for potential advantage: Address Resolution Protocol (ND) is not needed.

This is not correct, since the IID has always allowed for manual 
configuration -- hence you cannot assume that what's in the IID is the 
underlying MAC address.  -- And, at the time of this writing, your best 
bet is that it isn't (think RFC7217, RFC4941, and manual configuration).

> Example of potential disadvantage: almost half of L3 address bits are wasted (a few bits are needed inside the link).

I wouldn't necessarily say "wasted"... but yeah, I see what you mean.

> But the opposite argument that "64bit is enough address space for mankind in the next century" is the valid too.

I don't know what  "expanding the address space" would mean. If the 
argument is "be able to do SLAAC with != 64", then I'd probably agree, 
though. -- and my understanding is that disagreement on this point is 
why rfc4941bis was stalled.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Nov 2020 11:04:49 +0100

I have been reminded in private about 'race to the bottom'.

In the Variable SLAAC solution draft we do touch on the problem:

> The "race to the bottom problem" - is the problem where allowing 
> prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and 
> so on, up to 127 and 128 allocations.  At that point the bottom
> would be reached and thus impossible to extend the network further.

A solution is then proposed in section 8 titled "Greater than 64 bit
prefix usage by ISPs is strictly prohibited".  And there we propose a
new bit - bit 'S'.

Maybe it is better to move the problem description into the Variable
SLAAC Problem Statement draft.

Alex

Le 05/11/2020 à 17:49, Alexandre Petrescu a écrit :
>>> Gyan> The issue here with 4G providers to be able to force 
>>> providers to go with a shorter prefix is impossible and similar 
>>> to the issue we see with the v6ops flash renumbering issue and 
>>> even in light of BCOP RIPE-690 that broadband operator’s PD 
>>> allocations is /64 and not /56 as recommended in BCOP and due to
>>>  the impact of flash renumbering events we are now changing the 
>>> VL PL to short timers to age our the stale prefix during a 
>>> renumbering event.  So the standard on 4G and as it is the same 
>>> standard for 5G handsets allocation, a /64, and 4G and even 5G 
>>> operators for mobile handset provisioning do not plan to make it
>>>  a shorter prefix.  So either customers end up suffering with 
>>> flash renumbering events or you update the standard. Same issue 
>>> we are faced with here with wireless providers and forcing them 
>>> Fixed 5G replacement for broadband I mentioned, not to be 
>>> confused with 5G mobile handset, would follow BCOP RIPE-690 and I
>>> believe will go in with larger allocation like a /56 or larger.
>>> So the fixed 5G network slicing how it comes into play as a value
>>> proposition and massive benefit to customers, is it can now have
>>> the front haul 5G to tower and back haul tower to core now be
>>> provisioned to the fixed 5G with a normal BAU slice template for
>>> normal traffic and at the same time separate slices for special
>>> Enhanced VPN over SRv6 core SR-TE steered with dedicated
>>> resources and traffic  isolation and special QoS prioritization
>>> for applications such as IOT, E911 emergency services, or
>>> utilities etc.
>>> 
>> OK, so the problem is: "How do you connect an end-user network with
>> multiple links to a provider who only allocates a /64 to the 
>> site.".
>> 
>> There is a conundrum here. A reason for the 64-bit boundary is that
>> it forces the provider to give at least a /64. That design decision
>> seems to have had the intended effect. You don't see any providers
>> assigning less address space than the /64.
>> 
>> If we were to relax that limitation, then there is a fear that 
>> providers will start assigning fewer addresses to end-users. Down 
>> to a single address like we see in IPv4.
>> 
>> The conundrum then is: How do we ensure providers allocate at least
>> a /64 of address space to end-users, and at the same time allow
>> end-users to extend a network with only a /64 assigned to it.
> 
> 
> I want to not forget to If there is a future version of this draft 
> then I want to make sure to add the problem of "Race to the Bottom" 
> in the Variable SLAAC Problem Statement draft.
> 
> allocates _at least_ a /64 to an end user.  I think there is an RFC 
> for that, that we might cite.  And a RIPE note too.
> 
> Alex
> 
>> 
>> Best regards, Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 6 Nov 2020 10:18:01 +0000

Hi Fernando,
I said that "address resolution is not needed". Some simplified protocol is needed anyway.
You have pointed to the manual address collision.
I could additionally say that the router should announce "seed" to obfuscate MAC addresses on this link (the same MAC should look different on different links).
Additionally, RA is needed to centralized push of configuration information.
But it is not "neighbor discovery", it is "link configuration".
Well, it does not make sense to discuss - much smaller things has been rejected on 6man. It is really the revolution that I do believe make sense to push.

But yes, such revolution would need to keep subnet boundary at the exact position (like /64).
Eduard
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 6 ноября 2020 г. 12:55
> To: Vasilenko Eduard <[email-masked]>; IPv6 List
> <[email-masked]>
> Subject: Re: [EXTERNAL] Re: I-D Action: draft-mishra-6man-variable-slaac-01.txt
> 
> > IPv6 has been designed with 64bit address space. Other 64bits have been
> abused for L2 address inserted into L3 address.
> This is not correct, since the IID has always allowed for manual configuration --
> hence you cannot assume that what's in the IID is the underlying MAC address.  -
> - And, at the time of this writing, your best bet is that it isn't (think RFC7217,
> RFC4941, and manual configuration).
> 
> 
> 
> > I personally do not see how advantages have been leveraged and
> disadvantages mitigated. Hence, the request to expand address space above
> 64bit looks valid.
> I don't know what  "expanding the address space" would mean. If the argument
> is "be able to do SLAAC with != 64", then I'd probably agree, though. -- and my
> understanding is that disagreement on this point is why rfc4941bis was stalled.
> 
> Thanks,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP Fingerprint:
> 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 07:33:33 -0300

> You have pointed to the manual address collision.

No. I pointed out that unless the IID is mandated to embed the 
underlying MAC address in all cases, you still need address resolution.

(and *that* has never been mandated).

> I could additionally say that the router should announce "seed" to obfuscate MAC addresses on this link (the same MAC should look different on different links).

Why should it?

> But yes, such revolution would need to keep subnet boundary at the exact position (like /64).

Sorry, I'm lost here.

There's no *technical* reason for the subnet boundary to be required to 
be fixed at /64.

/64 was only needed if one wanted to support IID generation based on 
embedding MAC addresses on link-layers with 64-bit MACs.

Once we got rid of recommending that IIDs be generated by embeding the 
underlying mac address (think RFC8064), the only reason for mandating a 
fixed subnet boundary is electro-political, *not* technical.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 07:36:17 -0300

On 6/11/20 07:04, Alexandre Petrescu wrote:
>> prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and so 
>> on, up to 127 and 128 allocations.  At that point the bottom
> prefix usage by ISPs is strictly prohibited".

Then we'd need an RFC for formally creating the Internet police/militia. 
  (possibly a very bad timing for an already bad idea).

Thanks,

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 6 Nov 2020 11:42:14 +0000

Address could not be flexible to infinity. It should have maximum. It is /64 now.
If it would become bigger - some protocols would have the challenge.
For example, temporary address generation (your rfc4941bis) would not have 64bits anymore for IID. We would need rfc4941_bis_bis
Ed/
> From: Fernando Gont [mailto:[email-masked]]
> Sent: 6 ноября 2020 г. 13:34
> To: Vasilenko Eduard <[email-masked]>; Fernando Gont
> <[email-masked]>; IPv6 List <[email-masked]>
> No. I pointed out that unless the IID is mandated to embed the underlying MAC
> address in all cases, you still need address resolution.
> 
> > I could additionally say that the router should announce "seed" to obfuscate
> MAC addresses on this link (the same MAC should look different on different
> links).
> 
> Why should it?
> 
> 
> 
> > Well, it does not make sense to discuss - much smaller things has been
> rejected on 6man. It is really the revolution that I do believe make sense to push.
> >
> There's no *technical* reason for the subnet boundary to be required to be fixed
> at /64.
> 
> underlying mac address (think RFC8064), the only reason for mandating a fixed
> subnet boundary is electro-political, *not* technical.
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 6 Nov 2020 09:11:11 -0500

On Fri, Nov 6, 2020 at 6:42 AM Vasilenko Eduard <[email-masked]>
wrote:

> For example, temporary address generation (your rfc4941bis) would not have
> 64bits anymore for IID. We would need rfc4941_bis_bis

    As Fernando mentioned and others on this thread, it’s the IID
generation modified EUI64 is what is setting the boundaries at 64.

As Fernando mentioned with a random IID generation stable or not RFC 4941
or RFC 7217 you are now not bound to the 64 bit fixed IID.

I believe free BSD does not fix the boundary

We have tested with Linux kernel mods using random IID generation schema
RFC 4941 or RFC 7217 stable and you can create any length IID.

> > > I said that "address resolution is not needed". Some simplified
> protocol is
> > needed anyway.
> underlying MAC
> > > But yes, such revolution would need to keep subnet boundary at the
> exact
> > position (like /64).
> >
> > Sorry, I'm lost here.
> >
> be fixed
> fixed
-- 

*Gyan Mishra*

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Nov 2020 15:14:53 +0100

Le 06/11/2020 à 11:36, Fernando Gont a écrit :
>>>  prefixes longer than 64 to be used in SLAAC will lead to 65, 66
>>> and so on, up to 127 and 128 allocations.  At that point the
>>> bottom would be reached and thus impossible to extend the network
>>> further.
>> 
>> A solution is then proposed in section 8 titled "Greater than 64
>> bit prefix usage by ISPs is strictly prohibited".
> 
> Then we'd need an RFC for formally creating the Internet
> police/militia. (possibly a very bad timing for an already bad
> idea).

So we need to attenuate that 'strictly prohibited' wording and improve a
way forward.

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 6 Nov 2020 09:27:32 -0500

> So we need to attenuate that 'strictly prohibited' wording and improve a

     Along with updating the verbiage in the draft we can create a 3GPP
mobile handset address allocation draft that that recommends only /64
allocation.

A RIPE BCOP may help as well for mobile operators.
This is all a theoretical fear that operators will race to the bottom, but
until we remove the 64 bit boundary, we don’t know for sure either way.  My
thoughts are that large operators such as Verizon as I can influence the
stance Verizon takes on allocation guidelines, that they will not change
and will remain at /64.  Verizon as a major stakeholder can influence other
operators as well on the stance. The complexity of management vlsm is
allocation for operators is not worth the saving and what is the real
savings.  Most operators have massive IPv6 assignments they got decades ago
so they never have to go back to the well again for more.

-- 

*Gyan Mishra*

---

From: "Mudric, Dusan" <[email-masked]>
Date: Fri, 6 Nov 2020 14:30:58 +0000

Would it help if the problem statemen clarifies that:

- There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,
- It is not about restricting the ISP prefix assignments to minimum one 64bit prefix, by imposing 64bit SLAAC prefix limitation on the clients,
- Minimum of one 64bit prefix limitation should be imposed by other network elements, rather than clients. Edge routers can block >64bit prefixes,
- Clients should be enabled to use >64bit prefixes for SLAAC to address X, Y, Z problems, and
- Operators engineering >64bit subnets need to evaluate how low is the IID; should maximum prefix length be 70 or 96 or ... (for security or other reasons)?

Dusan

On 2020-11-06, 9:15 AM, "Alexandre Petrescu" <[email-masked]> wrote:

Alex

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 6 Nov 2020 09:37:39 -0500

> so they never have to go back to the well again for more.

     As mentioned on this thread m, the original IPv6 underpinnings to
fixed IID was the modified EUI64 Mac based generation schema, but now with
the recommend random IID generation for privacy RFC4941 or RFC 7217 stable
based which are both now the industry standard we have in reality been
almost there as far and elimination of the 64 bit boundary and all that is
left is updating RFC 4291 verbiage.

I think at this point the only thing holding us back is the race to the
bottom theoretical fears which I think are disconnected from reality as I
don’t think it will happen.

*Gyan Mishra*

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Nov 2020 15:41:26 +0100

>    A RIPE BCOP may help as well
>    for mobile operators.  This is all a theoretical fear that
>    operators will race to the bottom, but until we remove the 64
>    bit boundary, we dont know for sure either way.  My thoughts
>    are that large operators such as Verizon as I can influence the
>    stance Verizon takes on allocation guidelines, that they will
>    not change and will remain at /64.  Verizon as a major stakeholder
>    can influence other operators as well on the stance. The complexity
>    of management vlsm is allocation for operators is not worth the
>    saving and what is the real savings.  Most operators have massive
>    IPv6 assignments they got decades ago so they never have to go
>    back to the well again for more.

If mobile providers such as Verizon care about standards, and can influence
other operators then maybe they can comply with a 9 year old RFC (RFC 6177):

"Although a /64 can (in theory) address an almost unlimited
"number of devices, sites should be given sufficient address
"space to be able to lay out subnets as appropriate, and not be
"forced to use address conservation techniques such as using
"bridging.  Whether or not bridging is an appropriate choice is
"an end site matter.

RFC 7278 uses a weird type of bridging to get around the lack of address 
space. This is something that affects just about all phones because almost
without exception phones can be used as wifi base station to connect other
devices over the mobile link.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 6 Nov 2020 09:58:09 -0500

On Fri, Nov 6, 2020 at 9:31 AM Mudric, Dusan <[email-masked]> wrote:

> - It is not about restricting the ISP prefix assignments to minimum one
> 64bit prefix, by imposing 64bit SLAAC prefix limitation on the clients,
> - Minimum of one 64bit prefix limitation should be imposed by other
> network elements, rather than clients. Edge routers can block >64bit
> prefixes,
> - Operators engineering >64bit subnets need to evaluate how low is the
> IID; should maximum prefix length be 70 or 96 or ... (for security or other
> reasons)?

   Good points.  I think that would be helpful and that we can clarify that
that we are not changing the current BCOP RIPE-690 for allocation
guidelines for mobile operators which today states /64.    As for privacy
concerns when connected to the internet for segmentation behind a handset
we can provide guidelines on minimum IID length recommended when directly
connected to the internet.  For operators from an infrastructure
perspective mostly static has been done for years vlsm down to P2P links
/127 as the standard.  The key here is endpoint hosts and IID sizing
minimum recommendation for privacy when directly connected to the internet.

*Gyan Mishra*

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Nov 2020 08:57:42 -0300

> For example, temporary address generation (your rfc4941bis) would not have 64bits anymore for IID. We would need rfc4941_bis_bis

You don't need 64 bits for that. Yes, there are tradeoffs (RFC7421) -- 
so e.g. the fewer bits for the IID, the higher the chances for IID 
collisions.  But there's no substantive difference in that respect for 
anything from /64 to /32.

Thanks,

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 6 Nov 2020 16:19:26 +0000

> - It is not about restricting the ISP prefix assignments to minimum one 64bit
> prefix, by imposing 64bit SLAAC prefix limitation on the clients,
> - Operators engineering >64bit subnets need to evaluate how low is the IID;
> should maximum prefix length be 70 or 96 or ... (for security or other
> reasons)?
> 
> Dusan

I'm thinking it might be reasonable to impose a requirement on CE routers (and devices in similar roles) that it MUST NOT accept delegation of a prefix longer than 64 bits on any interface using a technology that only exists on WAN links (e.g., DSL, PON, DOCSIS). This doesn't fully solve the problem. But if it's hard to get routers that will accept such delegations on WAN-only links, it will discourage most operators from doing them. From a business analysis case, the cost of providing prefixes with length <= 64 would be less than the cost of making sure all their customers have CE routers in place that do not have this limitation.
Barbara

> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
> ;!!BhdT!wVq_pzyE528tYQ87Kjxz_9O56DPf2t4bw1c6tQSvzc64sLdjOExbP4XV4
> smz_A$

---

From: Ca By <[email-masked]>
Date: Fri, 6 Nov 2020 08:29:09 -0800

On Fri, Nov 6, 2020 at 8:21 AM STARK, BARBARA H <[email-masked]> wrote:

> > - There is no race to the bottom. We are not trying to solve ISP problem
> by
> > allowing longer than 64bit prefixes,
> 64bit
> > - Clients should be enabled to use >64bit prefixes for SLAAC to address
> X, Y, Z
> > problems, and
> IID;
> I'm thinking it might be reasonable to impose a requirement on CE routers
> (and devices in similar roles) that it MUST NOT accept delegation of a
> prefix longer than 64 bits on any interface using a technology that only
> exists on WAN links (e.g., DSL, PON, DOCSIS). This doesn't fully solve the
> problem. But if it's hard to get routers that will accept such delegations
> on WAN-only links, it will discourage most operators from doing them. From
> a business analysis case, the cost of providing prefixes with length <= 64
> would be less than the cost of making sure all their customers have CE
> routers in place that do not have this limitation.
> Barbara
>

I would prefer to not set traps for network operators like this.

CB

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Nov 2020 17:36:19 +0100

> I'm thinking it might be reasonable to impose a requirement on CE
> routers (and devices in similar roles) that it MUST NOT accept
> delegation of a prefix longer than 64 bits on any interface using
> a technology that only exists on WAN links (e.g., DSL, PON, DOCSIS).
> This doesn't fully solve the problem. But if it's hard to get
> routers that will accept such delegations on WAN-only links, it
> will discourage most operators from doing them. From a business
> analysis case, the cost of providing prefixes with length <= 64
> would be less than the cost of making sure all their customers have
> CE routers in place that do not have this limitation.  Barbara

We can also impose a requirement on CE routers and phones, etc. that if they
don't get a suitable prefix (using DHCPv6 PD or homenet) to number all of
their downstream interfaces using /64s, then they should drop the WAN link.

Is such a requirement going to have any effect? Probably not.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Nov 2020 09:09:14 +1300

> - There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,

Unfortunately, once you push code allowing >64 subnet prefixes for SLAAC into the wild, you do automatically give ISPs a path to to allocating longer prefixes to customers, and all history tells us that some of them will follow that path.

Once that code is out there, the race to the bottom is enabled.

Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the /64 default for SLAAC. (If it did, my name would not be on that draft.)

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Fri, 6 Nov 2020 14:10:51 -0800

Brian,

> On Nov 6, 2020, at 12:09 PM, Brian E Carpenter <[email-masked]> wrote:
> 

> Once that code is out there, the race to the bottom is enabled.

I fully agree.   And once it is broken, there is no going back.

Also, I have yet to see any solution to having a mix of devices on the same link that can only support 64bit IIDs and ones that can support shorter IIDs.  I think there is an impossible transition problem.

Lastly and probably the most important, I have not seen a convincing argument why this is necessary.   The risk is breaking IPv6 in a fundamental way.

Bob

---

From: "Mudric, Dusan" <[email-masked]>
Date: Fri, 6 Nov 2020 23:08:26 +0000

The first sentence is taken out of the context. I actually said:

"- There is no race to the bottom. We are not trying to solve ISP problem by allowing longer than 64bit prefixes,
- It is not about restricting the ISP prefix assignments to minimum one 64bit prefix, by imposing 64bit SLAAC prefix limitation on the clients,
- Minimum of one 64bit prefix limitation should be imposed by other network elements, rather than clients. Edge routers can block >64bit prefixes,"

because I believe the race to the bottom can be addressed by other network elements (e.g. CE), not only clients.

Dusan

On 2020-11-06, 5:11 PM, "Bob Hinden" <[email-masked]> wrote:

Brian,

Bob

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Nov 2020 10:17:17 +1100

On Sat, 7 Nov 2020, 07:09 Brian E Carpenter, <[email-masked]>
wrote:

> by allowing longer than 64bit prefixes,
>
> Unfortunately, once you push code allowing >64 subnet prefixes for SLAAC
> into the wild, you do automatically give ISPs a path to to allocating
> longer prefixes to customers, and all history tells us that some of them
> will follow that path.
>

The current bottom is a single /64.

Any provider who is only giving out a single /64 to customers who might or
will need more than one /64 has already raced to the current bottom.

A "deeper bottom" or longer default allowed prefix length will just
facilitate further racing to the deeper bottom. It won't encourage giving
out more than one /64 for those who might need them; it'll do the opposite.

The pain should to be put where it is caused, onto the providers who should
be giving out multiple /64s to their customers.

Regards,
Mark.

> Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the /64
> default for SLAAC. (If it did, my name would not be on that draft.)
>
>    Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 7 Nov 2020 12:20:47 +1300

> because I believe the race to the bottom can be addressed by other network elements (e.g. CE), not only clients.

But the consumer CE is very often supplied by the ISP, and it therefore does what the ISP wants. If that's different from what an RFC says, it's the ISP that wins.

   Brian

---

From: "Mudric, Dusan" <[email-masked]>
Date: Fri, 6 Nov 2020 23:29:38 +0000

Should be a way to implement the prefix limitation in the service contract for the uplink to ISP. 

Dusan

On 2020-11-06, 6:20 PM, "Brian E Carpenter" <[email-masked]> wrote:

   Brian

---

From: Ca By <[email-masked]>
Date: Fri, 6 Nov 2020 15:35:00 -0800

On Fri, Nov 6, 2020 at 3:17 PM Mark Smith <[email-masked]> wrote:

>> > - There is no race to the bottom. We are not trying to solve ISP
>> problem by allowing longer than 64bit prefixes,
>>
> The pain should to be put where it is caused, onto the providers who
> should be giving out multiple /64s to their customers.
>
> Regards,
> Mark.
>

Why are the isps not giving more than one 64 ?

Is it because the ietf made it hard and dhcp-pd is unworkable , especially
in mobile ?

Yes

So what will the  ietf do? Well, we had multiple solutions that are
equivalent to cutting off one’s nose to spite the face

CB

>
>
>
>> Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the
>> /64 default for SLAAC. (If it did, my name would not be on that draft.)
>>
>>    Brian
>>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 18:58:51 -0500

Bob Hinden <[email-masked]> wrote:
    > Also, I have yet to see any solution to having a mix of devices on the
    > same link that can only support 64bit IIDs and ones that can support
    > shorter IIDs.  I think there is an impossible transition problem.

I have no interest in enabling ISPs to provide less than a /60.
(Particularly mobile ISPs.  5G is the ATM of the 2020s)

However, I think that draft-troan-6man-p2p-ethernet is one solution.
I have read the document, but there is a thread from two weeks ago that I
haven't contributed to yet.

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Nov 2020 12:13:54 +1100

On Sat, 7 Nov 2020 at 10:35, Ca By <[email-masked]> wrote:
>> On Sat, 7 Nov 2020, 07:09 Brian E Carpenter, <[email-masked]> wrote:
>>>
>> Any provider who is only giving out a single /64 to customers who might or will need more than one /64 has already raced to the current bottom.
>>
>> A "deeper bottom" or longer default allowed prefix length will just facilitate further racing to the deeper bottom. It won't encourage giving out more than one /64 for those who might need them; it'll do the opposite.
>>
>> The pain should to be put where it is caused, onto the providers who should be giving out multiple /64s to their customers.
>>
>> Regards,
>> Mark.
>
>
> Is it because the ietf made it hard and dhcp-pd is unworkable ,

There are multiple production residential deployments of DHCPv6-PD.

I worked on one that was deployed in 2010. I then used it for the next
8 years, and only moved away to another provider (and employer) where
it is in beta.

Telstra here in Australia have also been deploying it for a number of
years in production.

Sky in the UK have deployed PD to 5 million subscribers.

PD is very workable, and a number of people have made it work.

> especially in mobile ?

Why is that?

Doesn't 3GPP Release-10 specify PD support?

> Yes
>
> So what will the  ietf do? Well, we had multiple solutions that are equivalent to cutting off one’s nose to spite the face
>

What are these multiple solutions?

PD was the only solution until RFC7278, and I think that's only needed
because mobile devices have for some reason not been treated as an
ordinary portable IPv6 host, and a 3G link not being treated as just
another type of link-layer. Things would be a lot simpler if all that
existed IPv6 over 3G is a short IPv6-over-foo link-layer RFC, and the
upper layers were covered by the existing and generic IPv6 node and
host RFCs.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 Nov 2020 22:23:56 -0500

> 8 years, and only moved away to another provider (and employer) where

That's much cool.
It's very useful to hear of such successes!

A question: was it easy to assign static subnets to the customers?

My ISP initially statically routed my /56 to me, and then when they turned on
PD, they now send me three subnets. One statically, and apparently two by
DHCPv6-PD which they say they can't turn off/fix.  Very weird.
Well.... they aren't present today.

    > PD is very workable, and a number of people have made it work.

Maybe RIPE would do a survey to understand what has these things so
successful so that others can repeat it!

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Nov 2020 01:30:58 -0500

On Fri, Nov 6, 2020 at 3:09 PM Brian E Carpenter <
[email-masked]> wrote:

> default for SLAAC. (If it did, my name would not be on that draft.

   Gyan> I am not sure I understand the comment of pushing >64 subnet
prefixes out into the wild as if by doing so we are breaking IPv6.  Also
can you enlighten me on the history of another instance where a similar
apples for apples comparison where something similar was done by ISPs?

So once the code is there it is only in theory that the race to the bottom
will be used by providers once enabled.  We have a BCOP RIPE-690 which
would still apply to broadband carriers recommendation of /56 or larger and
with 3GPP mobile handset a /64.

If we have expect that operators to not follow BCOP why have a BCOP.

Could we not have an IPv6 allocation guideline for mobile operators to
support a minimum allocation of /64 similar to RFC 3177 or RFC 6177.  What
good is an IETF protocol specification if it is not followed by operators.

Bourbaki draft states that free BSD ships with SLAAC of any length.  That
is a good point duly noted by the draft.

So in theory if router manufacturers decided they could ship code now that
supports any prefix length and Free BSD and their maybe other OSs out there
that may work.

Bourbaki draft is actually referenced in both of our drafts and Bourbaki
draft clearly recommends any IID length.

Introduction:

   Over the history of IPv6, various classful address models have been

   proposed, none of which has withstood the test of time.  The last
   remnant of IPv6 classful addressing is a rigid network interface
   identifier boundary at /64.  This document removes the fixed position
   of that boundary for interface addressing.

5 <https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05#section-5>.
Recommendations

Note that OpenBSD ships with SLAAC for lengths longer than /64.

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identifier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064 <https://tools.ietf.org/html/rfc8064>])
algorithm for selecting stable interface
   identifiers [RFC7217 <https://tools.ietf.org/html/rfc7217>] is a
parameter, rather than a hard-coded value.

-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Nov 2020 01:39:58 -0500

On Fri, Nov 6, 2020 at 5:11 PM Bob Hinden <[email-masked]> wrote:

> Lastly and probably the most important, I have not seen a convincing
> argument why this is necessary.   The risk is breaking IPv6 in a
> fundamental way.

     Gyan> How is removing the archaic 64 bit boundary breaking IPV6 in a
fundamental way.

Another way to look at is that SLAAC has been broken Day 1 in a fundamental
way in that  interoperability hosts configured with static or dhcpv6 can
support any prefix length but due to the fact that SLAAC cannot support any
prefix length is has literally shackled static and dhcpv6 addressing to
only use the fixed 64 bit IID so that all the addressing methods are
 interoperable on the same subnet.

So in my mind SLAAC fixed IID has really made it difficult to change host
subnet sizing and we are stuck with /64 host subnet for any IPV6 deployment.

So in my mind SLAAC today is fundamentally broken.

To that end I can see when RFC 4291 was written we had modified EUI64 mac
based IID but once random IID came around with RFC 4941 privacy extension
and RFC 7217 stable IID the fixed SLAAC IID should have been eliminated
from the IPv6 addressing specification.

-- 

*Gyan Mishra*

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 7 Nov 2020 20:29:55 +1300

On Sat, 7 Nov 2020, 19:34 Gyan Mishra, <[email-masked]> wrote:

>> /64 default for SLAAC. (If it did, my name would not be on that draft.
>
>

Yes, it was called IPv4 and the rise of NAT was the result.

Regards
    Brian
    (via tiny screen & keyboard)

> 5 <https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05#section-5>.  Recommendations
>
>
>    recommended (see [RFC8064 <https://tools.ietf.org/html/rfc8064>]) algorithm for selecting stable interface
>    identifiers [RFC7217 <https://tools.ietf.org/html/rfc7217>] is a parameter, rather than a hard-coded value.
>
>
>
>
>
>>
>>    Brian
>>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 7 Nov 2020 16:31:23 +0900

> out more than one /64 for those who might need them; it'll do the opposite.

Exactly.

The fixed 64 bit boundary prevents this by defining the bottom in the
*only* way that actually matters: by ensuring that if a network goes below
the bottom, many hosts just won't work.

If it were possible to hand out less than a single /64 and have things work
acceptably for their customers, then someone, somewhere, would be doing it
already.

If we change the standards to make this technically possible but ask
operators not to do it, some will just do it anyway. After all - if it
works for them, why would they do otherwise? Because an RFC they maybe
haven't even read says they shouldn't?

The logical consequence is that we end up at /128. This is particularly
risky because any operator with lots of experience with IPv4 will find "one
/128 per host" obvious, expected and natural. One device has one IP
address, right? And once get to that point, we'll need to bring back NAT in
order to extend further. That would pretty much make the entire transition
to IPv6 pointless. We might as well have stayed with IPv4.

Personally I think that once there's more industry experience and IPv6 is
widely deployed in all network types (say, once we reach 80% of the
internet, and many networks are IPv6-only), we might be able to safely move
the bottom, once. But it's much too early for that.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 07 Nov 2020 12:24:29 +0100

>Is it because the ietf made it hard and dhcp-pd is unworkable , especially

Maybe I missed something. But where is the proposal from the mobile
world to do prefix delegation in a way that is 'workable'?

In particular, where is the problem statement. Just saying that 
'dhcp-pd is unworkable' doesn't sound very technical to me. And it is also
weird that just about all landline ISPs can do DHCPv6 PD just fine.

Though of course it could be that mobile is weird enough that normal 
things, like running a DHCP relay become unworkable.

---

From: Alexandre PETRESCU <[email-masked]>
Date: Sat, 7 Nov 2020 13:10:40 +0100

Le 07/11/2020 à 08:31, Lorenzo Colitti a écrit :
> On Sat, 7 Nov 2020, 08:17 Mark Smith, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Any provider who is only giving out a single /64 to customers who 
> might or will need more than one /64 has already raced to the
> current bottom.
> 
> facilitate further racing to the deeper bottom. It won't encourage 
> giving out more than one /64 for those who might need them; it'll do
>  the opposite.
> 
> 
> Exactly.
> 
> The fixed 64 bit boundary prevents this by defining the bottom in
> the *only* way that actually matters: by ensuring that if a network
> goes below the bottom, many hosts just won't work.

I think that might be a speculation explaining the past.

> If it were possible to hand out less than a single /64 and have 
> things work acceptably for their customers, then someone, somewhere, 
> would be doing it already.
> 
> operators not to do it, some will just do it anyway. After all - if 
> it works for them, why would they do otherwise?

A Variable SLAAC would not request operators to do something else than
they do already do today - allocate a /64 to end users.

This Variable SLAAC would allow _some_ operator and non-operator people
to not use IPv6 NAT, or 1subnet-restricted 64share or IPv6-in-IPv4 VPN
single points of failure and audio quality reducers.

> Because an RFC they maybe haven't even read says they shouldn't?

I think operators should all read RFC7934 which is a BCP and whose title
is "Host Address Availability Recommendations".

That BCP recommends "that networks provide general-purpose end hosts
with multiple global IPv6 addresses".

Do you think a single /64 represents multiple IPv6 addresses?

> The logical consequence is that we end up at /128. This is 
> particularly risky because any operator with lots of experience with 
> IPv4 will find "one /128 per host" obvious, expected and natural.
> One device has one IP address, right? And once get to that point,
> we'll need to bring back NAT in order to extend further. That would
> pretty much make the entire transition to IPv6 pointless. We might as
> well have stayed with IPv4.

I tend to agree, although not entirely.

> 
> Personally I think that once there's more industry experience and 
> IPv6 is widely deployed in all network types (say, once we reach 80% 
> of the internet, and many networks are IPv6-only), we might be able 
> to safely move the bottom, once. But it's much too early for that.

Might be too early - care to explain why?

Or maybe a bit late you meant?

Late, because IPv6 hotspots and similar moving IPv6 networks, all
plugged onto 4G, are already there.  Smartphone tethering uses 64share
some mobile WiFi access points use IPv6-in-IPv4 VPNs or, worse, IPv6
NATs.  I agree it is not 80% of IP deployments, but it goes in that
direction.

Alex

---

From: Bob Hinden <[email-masked]>
Date: Sat, 7 Nov 2020 09:41:20 -0800

Lorenzo,

> On Nov 6, 2020, at 11:31 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> The fixed 64 bit boundary prevents this by defining the bottom in the *only* way that actually matters: by ensuring that if a network goes below the bottom, many hosts just won't work.
> 
> If it were possible to hand out less than a single /64 and have things work acceptably for their customers, then someone, somewhere, would be doing it already.
> 
> If we change the standards to make this technically possible but ask operators not to do it, some will just do it anyway. After all - if it works for them, why would they do otherwise? Because an RFC they maybe haven't even read says they shouldn't?
> 
> The logical consequence is that we end up at /128. This is particularly risky because any operator with lots of experience with IPv4 will find "one /128 per host" obvious, expected and natural. One device has one IP address, right? And once get to that point, we'll need to bring back NAT in order to extend further. That would pretty much make the entire transition to IPv6 pointless. We might as well have stayed with IPv4.

I agree.

> Personally I think that once there's more industry experience and IPv6 is widely deployed in all network types (say, once we reach 80% of the internet, and many networks are IPv6-only), we might be able to safely move the bottom, once. But it's much too early for that.

From reading this thread, I think if there is a problem to solve now, it is to make it easier for mobile operators to give shorter prefixes to mobiles.   If there are problems with DHCPv6 PD let’s fix that, or if some other mechanism is needed let’s do that.   We should not be going in the other direction.

Bob

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Nov 2020 21:02:30 +0000

Bob Hinden wrote on 07/11/2020 17:41:
>> particularly risky because any operator with lots of experience
>> with IPv4 will find "one /128 per host" obvious, expected and
>> natural. One device has one IP address, right? And once get to that
>> point, we'll need to bring back NAT in order to extend further.
>> That would pretty much make the entire transition to IPv6
>> pointless. We might as well have stayed with IPv4.
> 
> I agree.

there's a string of generalisations and assumptions going on here, and 
like many arguments which use reductio ad absurdum, I fear that the 
outcome shows the absurdity of the line of argument more than the issue 
being argued about.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Nov 2020 17:33:27 -0500

On Nov 7, 2020, at 4:02 PM, Nick Hilliard <[email-masked]> wrote:
> there's a string of generalisations and assumptions going on here, and like many arguments which use reductio ad absurdum, I fear that the outcome shows the absurdity of the line of argument more than the issue being argued about.

Considering your opening sentence, I would have hoped that we’d find something more than conjecture in the following sentence, but… no.

What Bob said is not conjecture—we’ve already seen clear pressure to race to the bottom. We have actual data to support what he says. You can’t contradict data with conjecture.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Nov 2020 23:01:15 +0000

Ted Lemon wrote on 07/11/2020 22:33:
> What Bob said is not conjecture—we’ve already seen clear pressure to 
> race to the bottom. We have actual data to support what he says. You 
> can’t contradict data with conjecture.

[[citation needed]]

Nick

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Nov 2020 18:16:32 -0500

Read the whole thread, please, Nick. 

> On Nov 7, 2020, at 18:01, Nick Hilliard <[email-masked]> wrote:
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Nov 2020 23:24:23 +0000

> Read the whole thread, please, Nick.

this is the problem: I did read it, just like I've read through all the 
other threads on this topic over the last several years. There was a 
repeat of the usual speculation, generalisation and echo-chamber 
mechanics which have characterised this discussion at the ietf since 
more-or-less forever.

You said: "we’ve already seen clear pressure to race to the bottom".

So I politely ask you again: please provide citations to data.  Then we 
can have a discussion.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sun, 8 Nov 2020 10:41:40 +1100

> outcome shows the absurdity of the line of argument more than the issue

They're not assumptions if you have first hand experience of the history of
the rise of IPv4 address conservation measures, and can remember what IPv4
addressing practices and mindsets were before IPv4 addresses became
precious.

The address conservation mindset is even more distinct and distinguishable
when you've actually taught it through teaching IPv4 VLSM in the mid 90s.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Nov 2020 23:56:03 +0000

Mark Smith wrote on 07/11/2020 23:41:
> They're not assumptions if you have first hand experience of the history 
> of the rise of IPv4 address conservation measures, and can remember what 
> IPv4 addressing practices and mindsets were before IPv4 addresses became 
> precious.

btdt, thanks.

> The address conservation mindset is even more distinct and 
> distinguishable when you've actually taught it through teaching IPv4 
> VLSM in the mid 90s.

this looks very much like an appeal to authority.  We're better than this.

So once again, let's try to keep the topic about actual data concerning 
ipv6 and this "race to the bottom" as it relates to ipv6.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 7 Nov 2020 19:00:33 -0500

I am not sure what data you are looking for Nick.
By definition, no one complying with the RFCs is giving out prefixes 
longer than /64.
By observation, folks are giving out /64s, when we would prefer they 
gave out /56 or even shorter.
Given that there are policy statements from various groups about giving 
out shorter, adn those are being ignored, something is causing that.
There may be multiple causes.

History does tell us that ISPs give out very long prefixes even when 
they do not need to.

Since there appears to be know way to observe a trend past /64, we have 
to look to history and analogy for data.  History is data.  We can argue 
about whether it is relevant data.  But it is all the data we have on 
the topic.

Yours,
Joel

On 11/7/2020 6:56 PM, Nick Hilliard wrote:
>> They're not assumptions if you have first hand experience of the 
>> history of the rise of IPv4 address conservation measures, and can 
>> remember what IPv4 addressing practices and mindsets were before IPv4 
>> addresses became precious.
> 
> btdt, thanks.
>

---

From: Ca By <[email-masked]>
Date: Sat, 7 Nov 2020 17:00:54 -0800

> about whether it is relevant data.  But it is all the data we have on

History tells us that ipv4 was scarce so people conserved addresses.

Operators have unlearend that lesson but the ietf has not. And so, ietf
people think operators are trying conserve addresses, this is not true.
Stop saying it. Stop saying “race to the bottom”, it does not mean
anything.

The current and future issue is that the mechanics of providing n number of
/64 is broken, dhcp pd is not being deployed in
Mobile. Accept reality. Mobile devices dont support it. Mobile networks
dont deploy it.

So, the problem statement in mobile is - how do we better make use of the
/64 that is provided or get more /64s in an effective way

No, yelling at operators and making punitive standards will not help.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 7 Nov 2020 20:03:55 -0500

On Nov 7, 2020, at 6:24 PM, Nick Hilliard <[email-masked]> wrote:
> So I politely ask you again: please provide citations to data.  Then we can have a discussion.

ISPS are handing out /64s. This was mentioned in the thread. This is all the evidence you need that there has been a race to the bottom.

---

From: Ca By <[email-masked]>
Date: Sat, 7 Nov 2020 17:05:58 -0800

On Sat, Nov 7, 2020 at 5:04 PM Ted Lemon <[email-masked]> wrote:

> ISPS are handing out /64s. This was mentioned in the thread. This is all
> the evidence you need that there has been a race to the bottom.
>

This is only evidence that dhcpv6-pd does not meet the need in mobile.

Ietf failed. Try harder.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 7 Nov 2020 20:08:11 -0500

I follow most of your reasoning, but I am missing on critical step.
Can you please explain how / why / in what fashion DHCPv6 pd is broken?
Just saying ~mobile operators chose not to use it~ does not give us any 
information to judge what solutions are likely to be workable.

I will also note that even if mobile operators would have good reason to 
use a longer prefix system, and would not abuse it, I am not so sure the 
same can be said about fixed operators.  If your claim is that DHCPv6 PD 
is broken for them too, then explaining why and how becomes more 
important for us to understand the situation.

Yours,
Joel

On 11/7/2020 8:00 PM, Ca By wrote:
> 
> 
> On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> The current and future issue is that the mechanics of providing n number 
> of /64 is broken, dhcp pd is not being deployed in
> So, the problem statement in mobile is - how do we better make use of 
> the /64 that is provided or get more /64s in an effective way
> 
>      > [email-masked] <mailto:[email-masked]>
>      > Administrative Requests:
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 8 Nov 2020 10:30:17 +0900

> This is only evidence that dhcpv6-pd does not meet the need in mobile.

So fix it. :-) Write something up, and if there is rough consensus we will
implement it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 8 Nov 2020 10:35:55 +0900

> So I politely ask you again: please provide citations to data.  Then we

Ok, I'll bite. Once. :-)

Here's some data:

https://www.ietf.org/proceedings/96/slides/slides-96-v6ops-4.pdf

says that 29% of survey responses says the LAN prefix size is /64. This is
despite pretty much every IETF and RIR document saying that ISPs should
assign more.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Nov 2020 14:38:06 +1300

On 08-Nov-20 14:00, Ca By wrote:
...
> Operators have unlearend that lesson but the ietf has not.

If that is true, why on Earth does 3GPP still ration each PDP context to one /64? That is for sure not the IETF's fault. We've told them and told them.

It is not the case that the IETF hasn't learned the lesson. In fact, the lack of scarcity is exactly why "wasting" 64 bits on Interface IDs and handing out /48 or /56 to end users are the IETF recommendations. The pressure against those recommendations is *exactly* the race to the bottom.

(In answer to Nick: the data for the race to the bottom don't come from IPv6. We're talking about IPv4, between about 1993 and today.)

But Cameron, please tell us in detail why PD is problematic for some operators. That seems to be the sticking point here.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 8 Nov 2020 14:56:12 +1300

On 08-Nov-20 14:35, Lorenzo Colitti wrote:
> On Sun, 8 Nov 2020, 08:24 Nick Hilliard, <[email-masked] <mailto:[email-masked]>> wrote:
> 
> says that 29% of survey responses says the LAN prefix size is /64. This is despite pretty much every IETF and RIR document saying that ISPs should assign more.

There's some 2010-vintage data at https://tools.ietf.org/html/rfc6036#section-2.5 suggesting that even then, there was a variety of practice including some /64-only operators. And: "Mobile operators offer /64 in accordance with 3GPP, but at least one would like to be allowed to offer /128 or /126."

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 8 Nov 2020 12:55:47 +1100

On Sun, 8 Nov 2020 at 12:01, Ca By <[email-masked]> wrote:
> Operators have unlearend that lesson but the ietf has not. And so, ietf people think operators are trying conserve addresses, this is not true. Stop saying it. Stop saying “race to the bottom”, it does not mean anything.
>

So you're saying this 33% has gone to zero in the past 4 years?

"With regards to what prefix is allocated for customers’ LANs, 22% of
the respondents indicated that they are using a /48, 35% indicated
they are using a /56, 33% a /64 and 10% other sizes (among them, a
/60, a /62, a /57, a /127 and a /128). "

"IPv6 deployment survey: the results"
https://blog.apnic.net/2016/11/14/ipv6-deployment-survey-results/

> The current and future issue is that the mechanics of providing n number of /64 is broken, dhcp pd is not being deployed in
> Mobile. Accept reality. Mobile devices dont support it. Mobile networks dont deploy it.
>

You're not explaining why it hasn't been deployed. What are the
problems with DHCPv6-PD that are unique to mobile networks that don't
exist in large scale residential broadband networks that have
successfully deployed PD at scale with /56s or shorter?

> So, the problem statement in mobile is - how do we better make use of the /64 that is provided or get more /64s in an effective way
>

---

From: Ca By <[email-masked]>
Date: Sat, 7 Nov 2020 18:26:00 -0800

On Sat, Nov 7, 2020 at 5:38 PM Brian E Carpenter <
[email-masked]> wrote:

> If that is true, why on Earth does 3GPP still ration each PDP context to
> one /64? That is for sure not the IETF's fault. We've told them and told
> them.
>
> It is not the case that the IETF hasn't learned the lesson. In fact, the
> lack of scarcity is exactly why "wasting" 64 bits on Interface IDs and
> handing out /48 or /56 to end users are the IETF recommendations. The
> pressure against those recommendations is *exactly* the race to the bottom.
>
> (In answer to Nick: the data for the race to the bottom don't come from
> IPv6. We're talking about IPv4, between about 1993 and today.)
>
> But Cameron, please tell us in detail why PD is problematic for some
> operators. That seems to be the sticking point here.
>

Honestly, i believe the issue is that dhcp-pd does not exist in 3gpp
deployments and there is no way to will it into place.  /64s are assigned
from the gateway using a local pool assigned the the gateway. Very simple,
no radius, no dhcp, no binding pd routing to assignments

So, just like with 64share, we need to work with what we have.

1. We have slaac, can slacc gives us more addresses ?

2.  Each attachment to 3gpp provides a /64, is there a real problem today
with scaling up attachments to get more /64 addresses on demand?  Probably
fine for 2 or 3 more /64 in the common home scenarios.

3.  Can we adapt 64share to slice up the existing /64 ?

4.  Other? Not dhcp-pd.

5.  Ndproxy ?

The problem that i have today, is that $dayjob has a very quick growing
4G/5G home broadband business.  Today, we use 64share to get ipv6 on to the
LAN. Works great. But, a lot of people are using “google wifi” mesh which
adds ... a 3rd layer of nat44 and kills ipv6 getting to the actual user
LAN. But, google wifi does support dhcpv6-pd. Might be nice if it supported
ndproxy

---

From: Ca By <[email-masked]>
Date: Sat, 7 Nov 2020 18:31:30 -0800

On Sat, Nov 7, 2020 at 5:56 PM Mark Smith <[email-masked]> wrote:

> Stop saying it. Stop saying “race to the bottom”, it does not mean anything.
> >
>

Wireline broadband (pon, docsis) has an assumption that there is a dhcp
server present as a fundamental part of the architecture in ipv4. So there
it is in ipv6.

DHCP is generally not used in mobile. There is no such function bake into
the architecture to evolve to support PD.  Could it be added as a
greenfield ? Yes. Will it? Probably not, and we have 10 years of proof.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 7 Nov 2020 21:43:19 -0500

If I understand you, you are not saying DHCPv6 is broken.  You are 
saying the 3GPP chose not to try to use it.  They had to develop a new 
address allocation mechanism for IPv6, and chose to use RA / SLAAC (a 
defensible choice) instead of DHCPv6.

If so, and if the goal is to allow subtending devices and networks more 
cleanly, and if the desired approach is to modify RA messages, then why 
not modify them to make clear to the UE when it is allowed to 
sub-allocated /64s (or shorter) out of something shorter than /64. 
Sure, it is abusing RA for a routing allocation.  But so is the approach 
you want.  And it avoids (or at least makes harder) creating any risk of 
misbehavior by networks using the extension in ways that were not intended.

Maybe there is even some other, better solution.  But let's not assume 
that we need to break the rules to build working networks.

Yours,
Joel

On 11/7/2020 9:31 PM, Ca By wrote:
> 
> 
> On Sat, Nov 7, 2020 at 5:56 PM Mark Smith <[email-masked] 
>     On Sun, 8 Nov 2020 at 12:01, Ca By <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >
>      >
>      >
>      > On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern
>     <[email-masked] <mailto:[email-masked]>> wrote:
>      >>
>      > Operators have unlearend that lesson but the ietf has not. And
>     so, ietf people think operators are trying conserve addresses, this
>     is not true. Stop saying it. Stop saying “race to the bottom”, it
>     does not mean anything.
>      >
> 
>     <https://blog.apnic.net/2016/11/14/ipv6-deployment-survey-results/>
> 
> 
>      > The current and future issue is that the mechanics of providing n
>     number of /64 is broken, dhcp pd is not being deployed in
> server present as a fundamental part of the architecture in ipv4. So 
> there it is in ipv6.
> 
> DHCP is generally not used in mobile. There is no such function bake 
> into the architecture to evolve to support PD.  Could it be added as a 
>      > So, the problem statement in mobile is - how do we better make
>     use of the /64 that is provided or get more /64s in an effective way
>      >

---

From: Ca By <[email-masked]>
Date: Sat, 7 Nov 2020 19:04:14 -0800

> that we need to break the rules to build working networks.

Joel,

Fully agree.

RA prefix information can be set to any number between 0 and 128

But, 3gpp enshrined it to be 64

https://tools.ietf.org/html/rfc6459#section-5.2

Let’s change and and make it so the UE to slice up a prefix into multiple
downstream /64s

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 7 Nov 2020 23:44:10 -0500

> Yes, it was called IPv4 and the rise of NAT was the result.

    Gyan> The big difference and it does not make it an accurate comparison
or analogy is that with IPv4  there  was a real fear of address space
exhaustion, which we know many many  years when broadband become  common
place.  You can’t say the same for IPV6 that address space exhaustion is
going to occur ever just given the many more bits v6 is exponentially
larger space then IPv4 and there is no publication that shows data based on
usage the IPV6 has any fear of exhaustion.

The ISPs for IPV4 were justified to do what they did to shrink the
allocation down and  created the NAT interface overload standard 1 to many
port address translation now port forwarding standard, because there was a
REAL fear of IPV4 exhaustion which has happened and we knew then what it a
reality now.

We need a real data point to make the race to the bottom a valid conclusion
that occur and not just a theoretical possibility,
.

>> So once the code is there it is only in theory that the race to the
>> bottom will be used by providers once enabled.  We have a BCOP RIPE-690
>> which would still apply to broadband carriers recommendation of /56 or
>> larger and with 3GPP mobile handset a /64.
>>
>> So in theory if router manufacturers decided they could ship code now
>> that supports any prefix length and Free BSD and their maybe other OSs out
>> there that may work.
>>
>> *M 301 502-134713101 Columbia Pike
>> <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: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 00:21:55 -0500

On Fri, Nov 6, 2020 at 6:21 PM Brian E Carpenter <
[email-masked]> wrote:

> > "- There is no race to the bottom. We are not trying to solve ISP
> prefixes,"
> > because I believe the race to the bottom can be addressed by other
> network elements (e.g. CE), not only clients.
>
> But the consumer CE is very often supplied by the ISP, and it therefore
> does what the ISP wants. If that's different from what an RFC says, it's
> the ISP that wins.

   From my standpoint previous response about the race rob bottom
feasibility, I agree we are at the bottom now, but we are only theorizing
that their would be a new bottom with longer prefixes.  As I stated before
IPV6 is not IPV4 and is not subject to address space exhaustion so as
exhaustion is an impossibility there would never be a case where a new
bottom would occur as ISPs do not have any fear of IPV6 address space
exhaustion.

> >> Unfortunately, once you push code allowing >64 subnet prefixes for
> SLAAC into the wild, you do automatically give ISPs a path to to allocating
-- 

*Gyan Mishra*

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2020 09:12:01 +0100

> By observation,
> folks are giving out /64s, when we would prefer they gave out /56
> or even shorter.  

I'd say that a /56 is a clear example of the race to the bottom.

ISPs have been trying to give just a /128 to customers, just like IPv4.
There is a common complaint that a 64-bit IID just wastes bits without 
stating how those bits are more useful as part of the prefix.

And somehow the original 'give everybody a /48' got changed into '/56 is
also fine' without clear operational reason. The only one I can think of
is 6RD, but /56 shows up everywhere outside 6RD.

Why /56? because /48 has way too many subnets for a consumer. Again
preserving bits that don't need to be preserved.

This tendency to use the longest possible prefix for a network or subnet
is very strong.

---

From: [email-masked]
Date: Sun, 8 Nov 2020 10:55:42 +0100

> Let’s change and and make it so the UE to slice up a prefix into multiple downstream /64s

I suspect you find the RA mechanism which assigns prefixes to a link simpler to use because that configuration information is tied to the lifetime of that particular link.
That premise does not hold when you are delegating address space to a network behind that link.

If you were taking that approach, it would imply ephemeral addressing and flash renumbering.

Simple and cheap on the operator side likely implies complex and costly on the end-user side.
That might not be a good tradeoff. There are many more end-user sites than operators.

Best regards,
Ole

---

From: Simon Hobson <[email-masked]>
Date: Sun, 8 Nov 2020 13:12:15 +0000

> But the consumer CE is very often supplied by the ISP, and it therefore does what the ISP wants. If that's different from what an RFC says, it's the ISP that wins.

Indeed, and we've seen all sorts of "interesting" ideas about how networking should work.

>    From my standpoint previous response about the race rob bottom feasibility, I agree we are at the bottom now, but we are only theorizing that their would be a new bottom with longer prefixes.  As I stated before IPV6 is not IPV4 and is not subject to address space exhaustion so as exhaustion is an impossibility there would never be a case where a new bottom would occur as ISPs do not have any fear of IPV6 address space exhaustion.

That is only true if we assume that the people building the IPv6 networks (and operating policies) have unlearned all they've learned from doing the same with IPv4. And there is evidence that they haven't ...

> This tendency to use the longest possible prefix for a network or subnet

I see a number of "human factors" at work in this.

Firstly, for some there is an opinion that anyone wanting more than one address [per device] must be wanting to do something "naughty" - whether that's getting up top mischief, or heaven forbid, host a service themselves on a residential connection. This latter reason is something I've come across in my (admittedly limited) experience in a small IT services company and dealing with a number of ISPs - some will actually cite this as a reason for not allowing a static IPv4 address unless you are paying more for a "business" connection (Talk Talk), or pay a stupidly high monthly fee for it (BT Internet).
The same mindset would translate into IPv6 as people wanting lots of address must be trying to hide something.

Something else I've come across in the past is "pay by devices". Granted it's mostly been in the mobile world where contracts explicitly prohibit sharing the connection with anything but the phone itself. But I vaguely recall some fixed services in the past having different tiers of pricing depending on how many devices you wanted to connect to it - again as a means of forcing businesses to pay more. Once you eliminate NAT (which effectively hides the number of devices without expensive traffic analysis), then you open the doors to "per per device" again - and what better method to restrict devices than to restrict the number of addresses ? Look forward to price tiers by subnet size.

The second factor, which I suspect is a very significant one, is that many people still think IPv6 is "IPv4 with a few more address bits". If your job is to build/manage IPv4 networks, and you are told "just add IPv6" without any extra budget, training, etc, then you are likely to just think in terms of "New IPv4 with more bits" and work from there.

You are not likely to have even heard of the privacy argument for large address allocations and address hopping - and if you have, then in many circles the ability to address hop would actually be seen as a bad thing. Don't forget that large parts of the world do not have the liberal views most of us in "the west" take for granted.

And I expect the majority of ISPs are still in the mindset that a customer network is your WAN connection plus "the ISP supplied router and exactly one network". I've dealt with ISPs that explicitly don't allow your to use your own router - and that included one (Vodafone) selling business DSL connections.

In summary, I too think having a fixed 64 bits doesn't make a lot of sense technically - I've seen enough to believe that there would in fact be a race to the bottom in some areas. And given that some places don't have the choice we take for granted in the UK, if you are unlucky enough to be in a "take or leave the /127 on offer" then that would indeed be a very bad thing.

I also think NAT was the spawn of the devil and put back widespread adoption of IPv6 by a decade at least - and diverted immeasurable developer (and support) resources away from fixing the underlying problem.

Simon

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sun, 8 Nov 2020 15:07:33 +0000

> elements (e.g. CE), not only clients.

I agree. The "race to the bottom" argument is a 100% FUD argument. As such, it
can never be disproven (or proven -- unless the opportunity were to actually exist).
IMO, at this point in IPv6 deployment, the 64-bit "bottom" boundary is extremely 
well established. With a few additions of requirements to CE router and BNGs,
I think it would be easy to codify this boundary in telco network equipment.
I suspect the cable ISPs would be willing to do the same (in their specs for similar
network elements). Maybe 3GPP, too.

There are tremendous advantages inside LANs to being able to more fully utilize a /64
(not the least of which is that -- as mentioned -- many ISPs are just giving out a single /64).
We're penalizing LAN environments and end users for the sake of FUD.
Barbara

> into the wild, you do automatically give ISPs a path to to allocating longer
> prefixes to customers, and all history tells us that some of them will follow
> that path.
> >
> 
> Also, I have yet to see any solution to having a mix of devices on the same
> link that can only support 64bit IIDs and ones that can support shorter IIDs.  I
> think there is an impossible transition problem.
> 
> argument why this is necessary.   The risk is breaking IPv6 in a fundamental
> way.
> 
> Bob
> 
> 
> >
> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
> H5q-w$
> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
> H5q-w$

---

From: Ca By <[email-masked]>
Date: Sun, 8 Nov 2020 07:08:36 -0800

On Sun, Nov 8, 2020 at 1:55 AM <[email-masked]> wrote:

> I suspect you find the RA mechanism which assigns prefixes to a link
> simpler to use because that configuration information is tied to the
> lifetime of that particular link.

Yes, that is the case of the deployment today. I am simply looking to give
< 64 instead of = 64, that is an improvement that is achievable

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 16:35:53 +0000

> I am not sure what data you are looking for Nick.

honestly, I'm not sure that any useful data even exists which suggests 
that right now, this entire "race to the bottom" discussion is an 
echo-chamber affair.  As Barbara points out (correctly, imo), the entire 
discussion is based on FUD and it's about time that this working group 
acknowledged this.

> History does tell us that ISPs give out very long prefixes even when 

Addressing scarcity has been an issue since before we had functional or 
widespread access services.  Also, provisioning mechanisms in the early 
days of access services were bereft of functionality, which meant that 
doing anything other than a single ipv4 statically-assigned /32 was 
troublesome and non-scalable.

There's never been a period where commodity ipv4 access products were 
available and where ipv4 addresses weren't a scarce resource, and 
scarcity has been the primary driver of addressing assignment policies 
since commodification of internet access services.  So this line of 
argument is not valid because there isn't a scarcity of ipv6 addressing 
resources.

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 11:41:10 -0500

> discussion is based on FUD and it's about time that this working group

   Gyan> Completely Agree!

> argument is not valid because there isn't a scarcity of ipv6 addressing

    Gyan> My point exactly.  We would have to prove based on data we have
today that IPv6 address depletion is even a remote possibility.  If not
then the argument of “race to the bottom” has no validity.

-- 

*Gyan Mishra*

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 16:56:43 +0000

STARK, BARBARA H wrote on 08/11/2020 15:07:
> I agree. The "race to the bottom" argument is a 100% FUD argument.

It's more than just FUD. The term "race to the bottom" is a politically 
charged phrase which is being used to shut down and obscure legitimate 
discussion about the complex issue of subnet size management on 
production networks.  Loaded language of this form has no place in an 
SDO working group.

Nick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 8 Nov 2020 12:12:36 -0500

Fair enough.  Let's not use the phrase "race to the bottom"

We can observe that some operators have indicated in reputable surveys 
that they would like to allocate /126 to customers.

We know, from both experience and analysis, that any particular number 
is hard to defend.  We could say the longest assignment to a UE / Node / 
... had to be /96.  And we would get arguments about why it needed to be 
longer.  We agreed during the design of IPv6, on the /64 in part so that 
we would not have to repeat the argument eveyr time we turned around.

there is a fair question about how an operator who is not using DHCPv6 
for address assignment (whether mobile or fixed) can use RA to give out 
a prefix to a piece of equipment that can be used for suballocation. 
The premise in this discussion is that such an allocation would need to 
be longer than /64.  I do not understand why.  If we are going to etend 
RA to support this (a request that seems reasonable) then why not do the 
extension in a way that respects the /64.

It would seem to be sensible to look at solutions that do not violate 
MUSTs in existing specs before assuming solutions that change the MUST 
are necessary.

Yours,
Joel

PS: The airplane case is sufficiently different that I find it hard to 
include it in the discussion.  In part because there is a LOT of design 
that we are not free to alter in order to ask "is that the right 
answer".  It is absolutely fair and necessary for folks to do designs 
for their own problem space.  But those designs should respect the 
limits that have been in place for more than 20 years.  Or be prepared 
to have actual discussions of design choices.  (Tony and Fred mean ve3ry 
well, and they are doing a good job of describing the constraints ICAO 
has accepted.  But they can't change those constraints or make commit to 
make changes.  Heck, it is not clear they even agree with each other.)

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 18:21:23 +0000

Brian E Carpenter wrote on 08/11/2020 01:38:
> If that is true, why on Earth does 3GPP still ration each PDP context
> to one /64? That is for sure not the IETF's fault. We've told them
> and told them.

Sure, but different access technologies use different deployment models.

Unfortunately, any time this discussion happens on 6man or v6ops, 
generalisations are made about the entire ipv6 networking ecosystem 
based on speculation about perceived worst-case situations in specific 
networking models, often cellular / mobile.

There's more to ipv6 than service provider access models, and there's 
more to ipv6 service provider access models than just cellular.  We 
should not accept as a working group that discussion about /64 is 
consistently driven into the ditch because people consistently steer the 
discussion in the direction of some specific access technology models 
and then make unsubstantiated claims relating to those models.  6man 
needs to move past this.

Nick

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 20:46:05 +0100

There are many ISPs offering IPv6. I never hear of any that doesn't use DHCPv6-PD to allocate /48, /56, some do /60, very few do /64 and we shall train them to understand that this is incorrect.

There is no technical neither cost reason (in terms of RIRs cost for getting a bigger IPv6 block), to allocate smaller prefixes for customers. The only reason they some time to /56 instead of /48 is "marketing" to differentiate business from residential customers. Nothing else.

Many ISPs do persistent prefixes.

Again, see RIPE-690 and https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf (look for the survey slides at the 2nd part).

Regards,
Jordi
@jordipalet

El 7/11/20 4:24, "ipv6 en nombre de Michael Richardson" <[email-masked] en nombre de [email-masked]> escribió:

    That's much cool.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 20:49:38 +0100

RIPE-690 was for all kind of operators and it was clear on that:

4.2.4. Considerations for Cellular Operators
There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas for LTE modems/routers, i.e. in the case of broadband by means of cellular access, it will still be necessary to choose a /48 or /56 in accordance with the aforementioned considerations.

We understood at that time that the default deployment model was /64 per PDP for a smartphone, but note that it was clear that a cellular router (or a device acting as a cellular router, it can still be a smartphone), should get /48 or /56.

Regards,

Jordi

@jordipalet

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

On Fri, Nov 6, 2020 at 3:09 PM Brian E Carpenter <[email-masked]> wrote:

Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the /64 default for SLAAC. (If it did, my name would not be on that draft.

   Gyan> I am not sure I understand the comment of pushing >64 subnet prefixes out into the wild as if by doing so we are breaking IPv6.  Also can you enlighten me on the history of another instance where a similar apples for apples comparison where something similar was done by ISPs?

So once the code is there it is only in theory that the race to the bottom will be used by providers once enabled.  We have a BCOP RIPE-690 which would still apply to broadband carriers recommendation of /56 or larger and with 3GPP mobile handset a /64.

Could we not have an IPv6 allocation guideline for mobile operators to support a minimum allocation of /64 similar to RFC 3177 or RFC 6177.  What good is an IETF protocol specification if it is not followed by operators.  

Bourbaki draft states that free BSD ships with SLAAC of any length.  That is a good point duly noted by the draft.

So in theory if router manufacturers decided they could ship code now that supports any prefix length and Free BSD and their maybe other OSs out there that may work.

Bourbaki draft is actually referenced in both of our drafts and Bourbaki draft clearly recommends any IID length.  

Introduction:

5.  Recommendations

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identifier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hard-coded value.

   Brian

-- 

Gyan Mishra

Network Solutions Architect 

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 8 Nov 2020 14:57:10 -0500

Jorid, from what has been said, some ISPs do not use DHCPv6.  that's 
fair.  We actually told them they did not have to.
So I do not think it is fair or appropriate to claim that to solve the 
delegation problem they must use DHCPv6.

     What is not clear to me is why solving the delegation problem 
requires extending the allocation boundary past /64.  The draft on the 
v6ops agenda simply asserts that it is necessary.

Yours,
Joel

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 20:59:35 +0100

It is IPv4-mind-set problem.

The solution is not to change that in standards. Otherwise, everytime operators decide to do something against standars, we change them again? The solution is to ensure that they missleaded operators get trained.

Fortunatelly the 29% is going lower and lower. ISPs are learning with the time (the survey is always open, so I keep measuring changes in the market).

Regards,

Jordi

@jordipalet

El 8/11/20 2:36, "ipv6 en nombre de Lorenzo Colitti" <[email-masked] en nombre de lorenzo=[email-masked]> escribió:

Ok, I'll bite. Once. :-)

Here's some data:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 21:02:55 +0100

I don't think that's true, at least not in broadband.

It is only true in mobile. I never understood why they don't want to use DHCPv6-PD, at least as an option if the device needs more than /64, for example a "mobile router".

Regards,
Jordi
@jordipalet

El 8/11/20 20:57, "ipv6 en nombre de Joel M. Halpern" <[email-masked] en nombre de [email-masked]> escribió:

    Yours,
    Joel

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 21:14:05 +0100

This is wrong. As one of the authors of that document, I can ensure that it covers both aspects, size and persistence and it also covers mobile. See:

 

Regards,

Jordi

@jordipalet

El 4/11/20 23:16, "ipv6 en nombre de Gyan Mishra" <[email-masked] en nombre de [email-masked]> escribió:

RIPE-690 is primarily in the context of flash renumbering events by wired broadband Carriers. 

 

 

    RIPE-690 is for wired broadband not mobile operators.  Mobile operators have always used /64.  For mobile operators guidance when making your phone a mobile hotspot RFC 7278 provides guidance but its still a /64 and not a larger space.

 

-- 

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: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 21:31:52 +0100

Le 08/11/2020 à 02:55, Mark Smith a écrit :
>> <[email-masked]> wrote:
>>> 
>>> I am not sure what data you are looking for Nick. By definition,
>>> no one complying with the RFCs is giving out prefixes longer than
>>> /64. By observation, folks are giving out /64s, when we would
>>> prefer they gave out /56 or even shorter. Given that there are
>>> policy statements from various groups about giving out shorter,
>>> adn those are being ignored, something is causing that. There may
>>> be multiple causes.
>>> 
>>> History does tell us that ISPs give out very long prefixes even
>>> when they do not need to.
>>> 
>>> Since there appears to be know way to observe a trend past /64,
>>> we have to look to history and analogy for data.  History is
>>> data.  We can argue about whether it is relevant data.  But it is
>>> all the data we have on the topic.
>> 
>> 
>> Operators have unlearend that lesson but the ietf has not. And so,
>> ietf people think operators are trying conserve addresses, this is
>> not true. Stop saying it. Stop saying “race to the bottom”, it does
>> not mean anything.
>> 
> 
> "With regards to what prefix is allocated for customers’ LANs, 22%
> of the respondents indicated that they are using a /48, 35%
> indicated they are using a /56, 33% a /64 and 10% other sizes (among
> them, a /60, a /62, a /57, a /127 and a /128). "
> 
>> number of /64 is broken, dhcp pd is not being deployed in Mobile.
>> Accept reality. Mobile devices dont support it. Mobile networks
>> dont deploy it.
>> 
> 
> problems with DHCPv6-PD that are unique to mobile networks that
> don't exist in large scale residential broadband networks that have 

There are some differences.

The CPE devices are all entirely controlled by their ISPs.  I cant log
into them.  The smartphones are all mandated by legislation to allow
their owners to log into them.

I suspect (some humans at some computers at some) operators protect
themselves against malicious smartphone owners by retaining closeness
and onwership of one part of the smartphone - the modem.  I can login
into the modem OS (a sub-OS connected to Android)) even though I can
login on Android.  That sub-OS of the modem manufacturer in 3GPP devices
does not do DHCPv6-PD and even blocks it.

If one wants to understand why such modem does not do DHCPv6-PD and
blocks it one has to get in touch to that modem manufacturer and ask the
question.

For my side, I did, with backing from operator.  I held long
discussions.   It all boils down to this: 'the IPv6 design is SLAAC and
no DHCP'.

One may want to interpret that phrase in many ways.

One might speculate of why that manufacturer maintains position against
DHCP.  It's not only they are against DHCPv6-PD but against DHCP
altogether.  The reason - I speculate - might have to do with IPR.  IPR
is present somehow on DHCP but absent somehow from SLAAC.  Add to that
the sensitivity of that manufacturer to IPR aspects in 3GPP, and it may
consitute a valid explanation.

But I am not sure this is the kind of answer you are looking for when
asking what are the problems of DHCPv6-PD unique to mobile as opposed to
household networks.

Alex

> 
>> So, the problem statement in mobile is - how do we better make use
>> of the /64 that is provided or get more /64s in an effective way
>> 
>>> Yours, Joel
>>>>> They're not assumptions if you have first hand experience of
>>>>> the history of the rise of IPv4 address conservation
>>>>> measures, and can remember what IPv4 addressing practices and
>>>>> mindsets were before IPv4 addresses became precious.
>>>> 
>>>> btdt, thanks.
>>>> 
>>>>> distinguishable when you've actually taught it through
>>>>> teaching IPv4 VLSM in the mid 90s.
>>>> 
>>>> So once again, let's try to keep the topic about actual data
>>>> concerning ipv6 and this "race to the bottom" as it relates to
>>>> ipv6.
>>>> 
>>>> Nick
>>>> 
>>>> [email-masked] Administrative Requests:
>>> IETF IPv6 working group mailing list [email-masked] Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
>> IETF IPv6 working group mailing list [email-masked] Administrative
>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 21:37:49 +0100

Le 08/11/2020 à 02:56, Brian E Carpenter a écrit :
>> this is the problem: I did read it, just like I've read through all
>> the other threads on this topic over the last several years. There
>> was a repeat of the usual speculation, generalisation and
>> echo-chamber mechanics which have characterised this discussion at
>> the ietf since more-or-less forever.
>> 
>> says that 29% of survey responses says the LAN prefix size is /64.
>> This is despite pretty much every IETF and RIR document saying that
>> ISPs should assign more.
> 
> There's some 2010-vintage data at
> https://tools.ietf.org/html/rfc6036#section-2.5 suggesting that even
> then, there was a variety of practice including some /64-only
> operators. And: "Mobile operators offer /64 in accordance with 3GPP,
> but at least one would like to be allowed to offer /128 or /126."

I think that could be a good supposition to imagine that that (human) at 
operator might race to a bottom.

But there could be other reasons than racing to a bottom.

Initial IPv6 deployments at mobile operators where with ppp protocol, 
which needed only two addresses on a link, hence just a /127, or so. 
Then SLAAC on 3GPP links arrived, proposing that /64.  But some 
operators wished to _continue_ to use their /127 and not migrate up to 
/64, for backwards compatibility.

In the end, after some changes in the network, _some_ operators migrated 
all their connections to /64 and got rid of /127.  There are still some 
places that are compatible with /127 ppp IPv6 mobile connections, which 
is good, because it is simpler.

But moving uupper from /64 to /56, for example, does not happen.

Because, there is so SLAAC with a /56 either.  It is one reason.

And because there is no DHCPv6-PD on 3GPP modems either.  It is another 
reason.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 21:51:19 +0100

> By definition, no one complying with the RFCs is giving out prefixes 

Hence we must write an RFC that makes that compliant.

> gave out /56 or even shorter.

It's not that simple.

If we have an operator that puts a /56 in an RA to a smartphone - will 
that be sufficient?

For my part I think it will not be sufficient.

It will not be sufficient because the smartphone does not know how to 
use a /56 to form an address.  Because it can only form an IID of length 
64.  Pad with 0s?  There' no RFC for that, they could be 1s as well.

So the operator might need to do more work: allocate an additional /64 
for that link, or maybe extract prefixes one of another to accommodate 
the IID  64 mandatory length.

> There may be multiple causes.

YEs there are.

And they are so since a few years.

> about whether it is relevant data.  But it is all the data we have on 

While I agree, I would also say that one would gain from counting the 
time one waits, and not wait forever in what appears to be forming into 
an infinite loop.

Often the time is mentioned: how long should we still wait for mobile 
operators to give /56s to smartphones?

Alex

>> concerning ipv6 and this "race to the bottom" as it relates to ipv6.
>>
>> Nick
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 21:57:42 +0100

Joel,

Allow me a question: I do not know why you ask the question of DHCPv6-PD 
brokenness in this context?

The race to the bottom problem might appear if the IID length is 
permitted to be of length 63.  Today 63, tomorrow 62, and so on down to 
the bottom.

That problem is on SLAAC, not on DHCP.

I would like a solution to the problem of mobile hotspots by using SLAAC 
with IID 63 on the Ethernet interface.  It's not a DHCP problem.  It's 
not an operator problem (some).

Bringing DHCPv6-PD in the figure is of no relevance, here, I think.

One cant expect mobile operators to use DHCPv6-PD, and, even if they 
did, there would still be race to the bottom problems.  They could use 
DHCPv6-PD as well to hand out /63 today, /64 tomorrow, /65 later, and so 
on down to the bottom.

THat is why I ask the above.

Alex

>> ietf people think operators are trying conserve addresses, this is not 
>> true. Stop saying it. Stop saying “race to the bottom”, it does not 
>> mean anything.
>>
>>      > Mark Smith wrote on 07/11/2020 23:41:
>>      >> They're not assumptions if you have first hand experience of the
>>      >> history of the rise of IPv4 address conservation measures, and 
>> can
>>      >> remember what IPv4 addressing practices and mindsets were before
>>     IPv4
>>      >> addresses became precious.
>>      >
>>      > btdt, thanks.
>>      >
>>      >> The address conservation mindset is even more distinct and
>>      >> distinguishable when you've actually taught it through teaching
>>     IPv4
>>      >> VLSM in the mid 90s.
>>      >
>>      > this looks very much like an appeal to authority.  We're better
>>     than this.
>>      >
>>      > So once again, let's try to keep the topic about actual data
>>     concerning
>>      > ipv6 and this "race to the bottom" as it relates to ipv6.
>>      >
>>      > Nick
>>      >
>>      > 
>>      > IETF IPv6 working group mailing list
>>      > [email-masked] <mailto:[email-masked]>
>>      > Administrative Requests:
>>      >

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 21:59:25 +0100

Le 08/11/2020 à 03:43, Joel M. Halpern a écrit :
> saying the 3GPP chose not to try to use it. 

It's worse than that.  3GPP did specify its use, but it is not used.

In an IETF world it sometimes happens that RFCs dont get implemented as 
much as we''d like - and its normal.  But in 3GPP world, the lack of 
implementation of a specified features says many more question marks.

Alex

  They had to develop a new
> sub-allocated /64s (or shorter) out of something shorter than /64. Sure, 
> it is abusing RA for a routing allocation.  But so is the approach you 
> want.  And it avoids (or at least makes harder) creating any risk of 
>>      > On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern
>>      >>
>>      >> I am not sure what data you are looking for Nick.
>>      >> By definition, no one complying with the RFCs is giving out 
>> prefixes
>>      >> longer than /64.
>>      >> By observation, folks are giving out /64s, when we would 
>> prefer they
>>      >> gave out /56 or even shorter.
>>      >> Given that there are policy statements from various groups about
>>     giving
>>      >> out shorter, adn those are being ignored, something is causing 
>> that.
>>      >> There may be multiple causes.
>>      >>
>>      >> History does tell us that ISPs give out very long prefixes 
>> even when
>>      >> they do not need to.
>>      >>
>>      >> Since there appears to be know way to observe a trend past /64,
>>     we have
>>      >> to look to history and analogy for data.  History is data.  We
>>     can argue
>>      >> about whether it is relevant data.  But it is all the data we
>>     have on
>>      >> the topic.
>>      >
>>      >
>>      > History tells us that ipv4 was scarce so people conserved 
>> addresses.
>>      >
>>      > Operators have unlearend that lesson but the ietf has not. And
>>      > The current and future issue is that the mechanics of providing n
>>      > Mobile. Accept reality. Mobile devices dont support it. Mobile
>>     networks dont deploy it.
>>      >
>>
>> Wireline broadband (pon, docsis) has an assumption that there is a 
>> dhcp server present as a fundamental part of the architecture in ipv4. 
>> So there it is in ipv6.
>>
>>      > So, the problem statement in mobile is - how do we better make
>>      > No, yelling at operators and making punitive standards will not 
>> help.
>>      >
>>      >>
>>      >>
>>      >> Yours,
>>      >> Joel
>>      >>
>>      >> On 11/7/2020 6:56 PM, Nick Hilliard wrote:
>>      >> > Mark Smith wrote on 07/11/2020 23:41:
>>      >> >> They're not assumptions if you have first hand experience 
>> of the
>>      >> >> history of the rise of IPv4 address conservation measures,
>>     and can
>>      >> >> remember what IPv4 addressing practices and mindsets were
>>     before IPv4
>>      >> >> addresses became precious.
>>      >> >
>>      >> > btdt, thanks.
>>      >> >
>>      >> >> The address conservation mindset is even more distinct and
>>      >> >> distinguishable when you've actually taught it through
>>     teaching IPv4
>>      >> >> VLSM in the mid 90s.
>>      >> >
>>      >> > this looks very much like an appeal to authority.  We're
>>     better than this.
>>      >> >
>>      >> > So once again, let's try to keep the topic about actual data
>>     concerning
>>      >> > ipv6 and this "race to the bottom" as it relates to ipv6.
>>      >> >
>>      >> > Nick
>>      >> >
>>      >> >
>>      >> > IETF IPv6 working group mailing list
>>      >> > [email-masked] <mailto:[email-masked]>
>>      >> > Administrative Requests:
>>      >> >
>>      >>
>>      >> 
>>      >> IETF IPv6 working group mailing list
>>      >> [email-masked] <mailto:[email-masked]>
>>      >> Administrative Requests:
>>      >>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 22:04:17 +0100

> Fair enough.  Let's not use the phrase "race to the bottom"

[...]

> The premise in this discussion is that such an allocation would need 
> to be longer than /64.

No.

The premise would be that mobile operator continues to assign a /64 to a
smartphone but this smartphone would make a /65 out of it to put it on
its WiFi interface towards others in that hotspot.  These others would
use IIDs of length 63.

> I do not understand why.  If we are going to etend RA to support this
> (a request that seems reasonable) then why not do the extension in a
> way that respects the /64.

We have a solution proposal in which we try to extend RA to accommodate 
this longer-than-64 prefix on linux.  But it's certainly not the only 
way possible.

OpenBSD does it differently.  I think they dont add any new bit in RA 
and still implement that feature.  The problem I have with it is that 
few if any at all computers in cars are based on OpenBSD.

> It would seem to be sensible to look at solutions that do not
> violate MUSTs in existing specs before assuming solutions that change
> the MUST are necessary.

I certainly agree.

I think there are many ways out of that, including the status decisions.

Alex

> 
> Yours, Joel
> 
> PS: The airplane case is sufficiently different that I find it hard 
> to include it in the discussion.  In part because there is a LOT of 
> design that we are not free to alter in order to ask "is that the 
> right answer".  It is absolutely fair and necessary for folks to do 
> designs for their own problem space.  But those designs should 
> respect the limits that have been in place for more than 20 years. Or
> be prepared to have actual discussions of design choices.  (Tony and
> Fred mean ve3ry well, and they are doing a good job of describing the
> constraints ICAO has accepted.  But they can't change those 
> constraints or make commit to make changes.  Heck, it is not clear 
> they even agree with each other.)
> 
>> It's more than just FUD. The term "race to the bottom" is a 
>> politically charged phrase which is being used to shut down and 
>> obscure legitimate discussion about the complex issue of subnet 
>> size management on production networks.  Loaded language of this 
>> form has no place in an SDO working group.
>> 
>> Nick
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 22:05:53 +0100

> v6ops agenda simply asserts that it is necessary.

I dont think we propose to extend the allocation boundary past /64.

I think we propose a solution in which an operator might still 
'allocate' a /64 to smartphones but the smartphones might 'allocate' a 
/65 to the ones that smartphone so wants.  With SLAAC.

Alex

>> There are many ISPs offering IPv6. I never hear of any that doesn't 
>> use DHCPv6-PD to allocate /48, /56, some do /60, very few do /64 and 
>> we shall train them to understand that this is incorrect.
>>
>> There is no technical neither cost reason (in terms of RIRs cost for 
>> getting a bigger IPv6 block), to allocate smaller prefixes for 
>> customers. The only reason they some time to /56 instead of /48 is 
>> "marketing" to differentiate business from residential customers. 
>> Nothing else.
>>
>> Again, see RIPE-690 and 
>> https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf 
>> (look for the survey slides at the 2nd part).
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>> El 7/11/20 4:24, "ipv6 en nombre de Michael Richardson" 
>> <[email-masked] en nombre de [email-masked]> escribió:
>>
>>
>>          >> Why are the isps not giving more than one 64 ?
>>          >>
>>          >> Is it because the ietf made it hard and dhcp-pd is 
>> unworkable ,
>>
>>          > There are multiple production residential deployments of 
>> DHCPv6-PD.
>>
>>          > I worked on one that was deployed in 2010. I then used it 
>> for the next
>>          > 8 years, and only moved away to another provider (and 
>> employer) where
>>          > it is in beta.
>>
>>      That's much cool.
>>          > Telstra here in Australia have also been deploying it for a 
>> number of
>>          > years in production.
>>
>>          > Sky in the UK have deployed PD to 5 million subscribers.
>>
>>          > PD is very workable, and a number of people have made it work.
>>
>> 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: "Joel M. Halpern" <[email-masked]>
Date: Sun, 8 Nov 2020 16:10:36 -0500

The reason I asked about DHCP being broken is that some of the earlier 
messages in the thread seemed (and I may have been misreading) to say 
"some operators can't use DHCPv6" rather than "some operators do not 
want to use DHCP, including almost all mobile operators".  The former 
statement is one where we as the IETF could look at the problems and see 
if there was something to fix.  The later statement is a not 
unreasonable policy statement that I am now trying to work with.

Yours,
Joel

On 11/8/2020 3:57 PM, Alexandre Petrescu wrote:
>> Just saying ~mobile operators chose not to use it~ does not give us 
>> any information to judge what solutions are likely to be workable.
>>
>> I will also note that even if mobile operators would have good reason 
>> to use a longer prefix system, and would not abuse it, I am not so 
>> sure the same can be said about fixed operators.  If your claim is 
>> that DHCPv6 PD is broken for them too, then explaining why and how 
>> becomes more important for us to understand the situation.
>>
>> Yours,
>> Joel
>>
>>>      >> history of the rise of IPv4 address conservation measures, 
>>> and can

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 10:35:21 +1300

> I agree. The "race to the bottom" argument is a 100% FUD argument. 

I don't agree. The documented "bottom" used to be /48. It was entirely
due to pressure from operators, and the short-sighted choice made by
3GPP, that it was changed to /64. There was justified fear when we published
RFC3177 in 2001; there was no room for uncertainty or doubt when we bowed to
reality and published RFC6177 in 2011. We've given enough ground on this.
Also, /64 is burned into more than 3 billion devices at this point, which
is a pretty strong commercial and operational argument.

There is no need to split /64s, when it is trivial to split /56s or /48s,
of which we have trillions to waste.

Just get 3GPP to change its /64 rule in accordance with RFC6177 and I
suspect that this entire problem will go away.

Regards
    Brian

> As such, it

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 22:40:37 +0100

Le 08/11/2020 à 22:10, Joel M. Halpern a écrit :
> The reason I asked about DHCP being broken is that some of the 
> earlier messages in the thread seemed (and I may have been 
> misreading) to say "some operators can't use DHCPv6" rather than 
> "some operators do not want to use DHCP, including almost all mobile 
> operators".

I agree.  In the discussions, DHCPv6-PD comes into the picture whenever
a hotspot-like, or 'stub network' or vehicle network is given as a use case.

Some operators do DHCPv6-PD for mobile phones but no mobile phone does
DHCPv6-PD because their modems dont allow for it.  That puts DHCPv6-PD
out of the discussion.

DHCPv6-PD has two entities: the Server and the Client.  Putting a Server
in place is not sufficient to mean that DHCPv6-PD works.

A same operator with DHCPv6-PD working ok with their CPEs does not mean
that same DHCPv6-PD works ok for their smartphones.  Even if it's a same
operator.

> The former statement is one where we as the IETF could look at the 
> problems and see if there was something to fix.

I think at IETF one couldnt solve the DHCPv6-PD lack of support in
Brandname modems.

As much as we cant request operators to give /56s to smartphones we cant
request modem manufacturers to implement protocol DHCPv6-PD either (not
even to let it through).

> The later statement is a not unreasonable policy statement that I am
> now trying to work with.

You are trying to formulate a policy statement?

Alex

>>> I follow most of your reasoning, but I am missing on critical 
>>> step. Can you please explain how / why / in what fashion DHCPv6 
>>> pd is broken?
>> 
>> Joel,
>> 
>> Allow me a question: I do not know why you ask the question of 
>> DHCPv6-PD brokenness in this context?
>> 
>> permitted to be of length 63.  Today 63, tomorrow 62, and so on 
>> down to the bottom.
>> 
>> I would like a solution to the problem of mobile hotspots by using 
>> SLAAC with IID 63 on the Ethernet interface.  It's not a DHCP 
>> problem.  It's not an operator problem (some).
>> 
>> One cant expect mobile operators to use DHCPv6-PD, and, even if 
>> they did, there would still be race to the bottom problems.  They 
>> could use DHCPv6-PD as well to hand out /63 today, /64 tomorrow, 
>> /65 later, and so on down to the bottom.
>> 
>>> Just saying ~mobile operators chose not to use it~ does not give 
>>> us any information to judge what solutions are likely to be 
>>> workable.
>>> 
>>> I will also note that even if mobile operators would have good 
>>> reason to use a longer prefix system, and would not abuse it, I 
>>> am not so sure the same can be said about fixed operators.  If 
>>> your claim is that DHCPv6 PD is broken for them too, then 
>>> explaining why and how becomes more important for us to 
>>> understand the situation.
>>> 
>>> Yours, Joel
>>> 
>>>> I am not sure what data you are looking for Nick. By 
>>>> definition, no one complying with the RFCs is giving out 
>>>> prefixes longer than /64. By observation, folks are giving out 
>>>> /64s, when we would prefer they gave out /56 or even shorter. 
>>>> Given that there are policy statements from various groups 
>>>> about giving out shorter, adn those are being ignored, 
>>>> something is causing that. There may be multiple causes.
>>>> 
>>>> History does tell us that ISPs give out very long prefixes
>>>> even when they do not need to.
>>>> 
>>>> Since there appears to be know way to observe a trend past
>>>> /64, we have to look to history and analogy for data.  History
>>>> is data.  We can argue about whether it is relevant data.  But
>>>> it is all the data we have on the topic.
>>>> 
>>>> 
>>>> so, ietf people think operators are trying conserve addresses, 
>>>> this is not true. Stop saying it. Stop saying “race to the 
>>>> bottom”, it does not mean anything.
>>>> 
>>>> The current and future issue is that the mechanics of
>>>> providing n number of /64 is broken, dhcp pd is not being
>>>> deployed in Mobile. Accept reality. Mobile devices dont support
>>>> it. Mobile networks dont deploy it.
>>>> 
>>>> the
>>>>>> history of the rise of IPv4 address conservation measures,
>>>>>> 
>>>> and can
>>>>>> teaching
>>>>> this looks very much like an appeal to authority.  We're 
>>>>> better
>>>> than this.
>>>>> 
>>>>> [email-masked] <mailto:[email-masked]> Administrative 
>>>>> Requests:
>>>> [email-masked] <mailto:[email-masked]> Administrative Requests: 
>>> IETF IPv6 working group mailing list [email-masked]
>>> Administrative Requests:

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 10:44:11 +1300

> There is a clear exception to the rule described above when assigning prefixes in a cellular network. In this case, a /64 will need to be provided for each PDP context for cellular phones, whereas…

Can you be more explicit? Are you saying that this problem is in fact solved for 5G modems? If so, and 4G is soon to be legacy, why are we even having this discussion?

Regards
     Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 21:45:15 +0000

> suspect that this entire problem will go away.

can we shine the light on the other side of this statement?

Is the IETF beholden to 3GPP to the extent that it feels hidebound to 
maintain /64 as a generic autoconfiguration boundary for all ipv6 access 
mechanisms in perpetuity?

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 11:05:12 +1300

> mechanisms in perpetuity?

That's the wrong question. It's 3GPP that created a problem. We are stuck with it, but that doesn't mean we should quietly concede.

During the RFC4291bis Wars I argued that we should separate the /64 boundary for SLAAC as a parameter, rather than as a constant in the addressing architecture. So no, not in perpetuity, especially if we move out of the 2000::/3 address space. However, the privacy arguments are fairly strong for not going beyond /80, I think, at any time in the future.

   Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 08 Nov 2020 23:06:29 +0100

We drafted this text knowing that according to standards, a smartphone can use several PDP context, and each one obtain a /64, but that the standards (already in 3G release 10, I think around 2011) also support DHCPv6-PD, so it is expected that if it is not a smartphone, but a router, it will support a shorter prefix (/48, /56, etc.).

I think Cameron confirmed that in a previous email in this thread.

The problem seems to be that either vendors didn't implemented it, or operators didn't deployed it.

Also, Alex insisted that chipset vendors don't support it. I don't think this is the case, I recall having used DHCPv6-PD with an LTE router long time ago.

I'm sure we have in the list folks from Apple, Broadcom, Qualcomm, maybe ARM, or somebody in the list can reach them, to ensure if this is a chipset problem, which I don't think is the case.

It looks to me it is more a problem of the rest of the mobile network equipment, just not implementing it by default.

El 8/11/20 22:44, "ipv6 en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

    Regards
         Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2020 22:35:05 +0000

Brian E Carpenter wrote on 08/11/2020 22:05:
> That's the wrong question. It's 3GPP that created a problem. We are
> stuck with it, but that doesn't mean we should quietly concede.

it's ok to ask a question like this, and to question both the question 
and the answer.  Obviously the question was loaded in the "have you 
stopped beating your wife yet" sense, but there is a grain of truth to it?

The real question was: to what extent is the IETF going to restrain 
itself from making ipv6 protocol behaviour decisions because a different 
SDO made a move in a particular direction and stayed there?

If the IETF can't make changes to ipv6 protocol behaviour decisions 
relating to access technologies other than 3GPP, then does 6man feel it 
has any mandate for ongoing ipv6 protocol management relating to other 
generic access technologies and not just service provider access products?

I.e. is the tail wagging the dog here?  And if so, where does this end?

Nick

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 8 Nov 2020 23:43:37 +0100

Le 08/11/2020 à 23:06, JORDI PALET MARTINEZ a écrit :
[...]
> Also, Alex insisted that chipset vendors don't support it. I don't
> think this is the case, I recall having used DHCPv6-PD with an LTE
> router long time ago.

I asked it at that time, I will ask it again the same question of 
whether this was on a smartphone or on a CPE, with which operator, which 
LTE modem, was the Server in the cellular network, and other details.

(if my assumptions about your trial is correct) The fact that a CPE 
router has a LTE interface and that the Server is outside the network 
operator it does not mean DHCPv6-PD works on smartphones.

> I'm sure we have in the list folks from Apple, Broadcom, Qualcomm,
> maybe ARM, or somebody in the list can reach them, to ensure if this
> is a chipset problem, which I don't think is the case.

It is the case.

> It looks to me it is more a problem of the rest of the mobile network
> equipment, just not implementing it by default.

No, it is a problem on the modem in the smartphone, not in the network.

Anyways, we will not solve it here.

One has to admit that in some environments some things are simply not 
there and wont come.

Alex

> 
> 
> El 8/11/20 22:44, "ipv6 en nombre de Brian E Carpenter"
> <[email-masked] en nombre de [email-masked]>
> escribió:
> 
>> This is wrong. As one of the authors of that document, I can ensure
>> that it covers both aspects, size and persistence and it also
>> covers mobile. See:
>> 
>> 
>> 
>> There is a clear exception to the rule described above when
>> assigning prefixes in a cellular network. In this case, a /64 will
>> need to be provided for each PDP context for cellular phones,
>> whereas for LTE modems/routers, i.e. in the case of broadband by
>> means of cellular access, it will still be necessary to choose a
>> /48 or /56 in accordance with the aforementioned considerations.
>> 
> 
> Can you be more explicit? Are you saying that this problem is in fact
> solved for 5G modems? If so, and 4G is soon to be legacy, why are we
> even having this discussion?
> 
> Regards Brian
> 
> 
> ********************************************** IPv4 is over Are you
> ready for the new Internet ? http://www.theipv6company.com The IPv6
> Company
> 
> authorized disclosure, copying, distribution or use of the contents
> of this information, even if partially, including attached files, is

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Nov 2020 00:04:53 +0100

> is a chipset problem, which I don't think is the case.

Apple and ARM are not modem manufacturers.  They make processors.
Actually, in a smartphone, working on the ARM or on the Apple processors
is very good.  There is some form of access, and ability to modify, to
port source code, etc.

To be clear and not to name, I meant Qualcomm in particular.  There are
other modems from China such as Balong (if I remember correctly the name).

We were in close contact with Qualcomm.  The people from Qualcomm at
IETF were very friendly and helpful, and brought us to the humans
at design and implementation.  It is there that all blocks.

None of Qualcomm of Balong modems let DHCPv6 through.  Some block UDP
port number of DHCP, others block multicast.  I specifically say 'block'
because trying other port numbers or trying unicast does let DHCPv6-PD
through.  But these other port numbers or unicast are not standard
because other RFCs.  So operator does not want to allow it.  Which I
think it is right.

There are other modem manufacturers that you did not list above, but
most of them copy the behaviours of the ones we talk about.

There is something else in implementation that we could talk about but
that you do not mention.  In Android there is no DHCPv6-PD client by
default.  Google somehow (religiously?) opposes DHCP.  (PRobably because
of the same apparently religious reasons that Qualcomm believes IPv6
design is SLAAC and not DHCP.)  But we did port a DHCPv6-PD client in
Android on ARM because we were allowed to (open source, etc.)  Of
course, we might dream about requesting Google themselves to port a
DHCPv6-PD client on ARM on Android, but I think we already tried
and we did not succeed, here at IETF.  Alternatively, we might try to
inject a DHCPv6-PD client in the kernel, and so - maybe - Android will
inherit it some time.  We have a draft for that implementation in v6ops
WG, and an implementation freely available.

But even then, because of all the reasons I tried to explain earlier, I
still think DHCPv6-PD is not the point of our discussion here.

Alex

> 
> It looks to me it is more a problem of the rest of the mobile
> network equipment, just not implementing it by default.
> 
> 
>> This is wrong. As one of the authors of that document, I can
>> ensure that it covers both aspects, size and persistence and it
>> also covers mobile. See:
>> 
>> 
>> 
> Can you be more explicit? Are you saying that this problem is in
> fact solved for 5G modems? If so, and 4G is soon to be legacy, why
> are we even having this discussion?
> 
> Regards Brian
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 8 Nov 2020 17:58:48 -0500

3G is only now starting to be sunset by wireless operators but for 4G it’s
a different story all together and it’s possible 4G may never sunset.

The major issue with 5G is right now with most 5G carriers urban densely
populated areas are the only areas where you will be able to get 5G.
Because 4G also has 4G+ which is the transition to 5G, 4G+ 4x4 MIMO is
still not even available yet in dense areas which gives up to GiG speeds
and 5G 10G speeds will start with densely populated urban areas but it’s
not available anywhere yet by any mobile operators.

Just as LED TV manufacturers came out with 4K well before cable operators
started delivering 4K and still lagging same goes with 5G the handsets and
fixed manufacturing comes way before the network is ready for primetime.

Also 3G surprisingly lingered for quite a long time and only now wireless
operators are now starting to shutdown 3G.  It’s going to be a very long
time before 4G or 4G+ becomes legacy and a think in some cases rural areas
may remain indefinitely as 5G has been targeted by wireless operators for
densely populated urban areas.  I would count on 4G and 4G+ being around
almost indefinitely.

Gyan
On Sun, Nov 8, 2020 at 4:44 PM Brian E Carpenter <
[email-masked]> wrote:

> > This is wrong. As one of the authors of that document, I can ensure that
> it covers both aspects, size and persistence and it also covers mobile. See:
> >
> >
> >
> prefixes in a cellular network. In this case, a /64 will need to be
> provided for each PDP context for cellular phones, whereas for LTE
> modems/routers, i.e. in the case of broadband by means of cellular access,
> it will still be necessary to choose a /48 or /56 in accordance with the
> aforementioned considerations.
> >
>
> solved for 5G modems? If so, and 4G is soon to be legacy, why are we even
> having this discussion?
>
> Regards
>      Brian
>
>
-- 

*Gyan Mishra*

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Nov 2020 10:58:30 +1100

> On 5 Nov 2020, at 02:54, Gyan Mishra <[email-masked]> wrote:
>    Agreed.  Fixed 5G broadband agreed would use the current wired broadband DHCPv6 PD and would follow the BSOP RIPE-690 and I think would use the recommended shorter prefix like a /56.  As fixed 5G would take advantage of the value added at a premium network slicing capabilities for the front haul and backhaul I can see Broadband 5G getting even a /48.  The issue mentioned in the draft is related to 4G as well as 5G “mobile handsets” and getting a /64 allocation which has been the standard which cannot be segmented by the Subscriber customer end.

This is a failure of imagination, not a technical impossibility. There is nothing preventing cell phones from being a router that hands out /64s to other routers than people with lack of imagination.  Cell phones have more than enough capacity to do this.  It’s not like the cell phone are incapable of handling /56 or /48 responses these days.  10 years ago there where some that fell over but given the attrition rate of cell phones and that there are newer images that do correctly handle shorter than /64 should have reconciled this to history.

Even in Africa the cost of a /56 per customer per year is well under 0.01USD as is the initial allocation fee.

                Allocation fee Membership
Small	/32	$2,500	       $2,500
Large	>/32	$20,000	       $20,000

$2500/(2^(56-32))
.00014
$20000/(2^(56-31))
.00059
$20000/(2^(56-28))
.00007

I think most of this comes down to can I save $18000 per year over a customer base of > 16 million.  Penny pinching at its extreme.

> I don’t see the mobile handset /64 prefix being going any shorter even for 5G.  For 5G the business driver for larger allocation is for the value added network slicing capabilities and the is relevant only for fixed broadband 5G which will replace wired broadband.  Mobile handset 5G will not get network slicing capabilities as it would use the front hall handset to tower backhaul tower to core Normal RAN Radio VPN.  Compared to Fixed 5G broadband which would have capabilities of being provisioned for high priority network slice Enhanced VPN with resource isolation and dedicated resource characteristics.

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

---

From: Ca By <[email-masked]>
Date: Sun, 8 Nov 2020 16:00:04 -0800

> Would you mind elaborating?

I believe running a dhcp server supporting 120M mobile subscribers would be
a nightmare.  I believe dhcpv6 is a larger stateful database and a not very
forgiving protocol... and client implementations are ... heterogeneous. ...
and server failover.. messy

None of that exists today in mobile. I feel the effort and scale are
daunting, so i am not going to do it.

But, getting a knob in the gateway to set the RA to be 60 (or other)
instead of 64 would be easy. And, that knob could be constrained to only
compatible device type (chef’s kisses!)... it can be done

---

From: Ca By <[email-masked]>
Date: Sun, 8 Nov 2020 16:01:56 -0800

On Sun, Nov 8, 2020 at 3:58 PM Mark Andrews <[email-masked]> wrote:

> >    Agreed.  Fixed 5G broadband agreed would use the current wired
> broadband DHCPv6 PD and would follow the BSOP RIPE-690 and I think would
> use the recommended shorter prefix like a /56.  As fixed 5G would take
> advantage of the value added at a premium network slicing capabilities for
> the front haul and backhaul I can see Broadband 5G getting even a /48.  The
> issue mentioned in the draft is related to 4G as well as 5G “mobile
> handsets” and getting a /64 allocation which has been the standard which
> cannot be segmented by the Subscriber customer end.
>
> This is a failure of imagination, not a technical impossibility. There is
> nothing preventing cell phones from being a router that hands out /64s to
> other routers than people with lack of imagination.  Cell phones have more
> than enough capacity to do this.  It’s not like the cell phone are
> incapable of handling /56 or /48 responses these days.  10 years ago there
> where some that fell over but given the attrition rate of cell phones and
> that there are newer images that do correctly handle shorter than /64
> should have reconciled this to history.
>
> Even in Africa the cost of a /56 per customer per year is well under
> 0.01USD as is the initial allocation fee.
>
> I think most of this comes down to can I save $18000 per year over a
> customer base of > 16 million.  Penny pinching at its extreme.

Yet another person missing the point and harkening back to the idea that
anyone is trying to conserve  ipv6 addresses.

Please stop.

>
> > I don’t see the mobile handset /64 prefix being going any shorter even
> for 5G.  For 5G the business driver for larger allocation is for the value
> added network slicing capabilities and the is relevant only for fixed
> broadband 5G which will replace wired broadband.  Mobile handset 5G will
> not get network slicing capabilities as it would use the front hall handset
> to tower backhaul tower to core Normal RAN Radio VPN.  Compared to Fixed 5G
> broadband which would have capabilities of being provisioned for high
> priority network slice Enhanced VPN with resource isolation and dedicated
> resource characteristics.
>
> > --
> >
> >
> > Gyan Mishra

---

From: Mark Andrews <[email-masked]>
Date: Mon, 9 Nov 2020 11:32:46 +1100

> On 8 Nov 2020, at 10:24, Nick Hilliard <[email-masked]> wrote:
> 
> this is the problem: I did read it, just like I've read through all the other threads on this topic over the last several years. There was a repeat of the usual speculation, generalisation and echo-chamber mechanics which have characterised this discussion at the ietf since more-or-less forever.
> 

Telcos only supplying /64 despite 3GPP supporting shorter than /64.  Every Telco that only supplies /64 has raced to the bottom.  There was reasons for this initially.  Some devices did not work correctly with short than /64 because their developers fail to properly test them before releasing them.  Its now a decade later and many of those Telcos are still doing /64.

DHCP-PD supports STATIC leases.  Whether you get a static of dynamic lease depends on the functionality the DHCP server vendor built in and how the server is configured.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2020 14:25:53 +1300

On 09-Nov-20 13:00, Ca By wrote:
> 
> 
> On Fri, Nov 6, 2020 at 1:05 AM <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Cameron,
> 
> I believe running a dhcp server supporting 120M mobile subscribers would be a nightmare.  I believe dhcpv6 is a larger stateful database and a not very forgiving protocol... and client implementations are ... heterogeneous. ... and server failover.. messy

Of course. You would have to run thousands of DHCPv6 servers out in the wild. Certainly there would need to be some distributed address pool management too. Just handing out a /56 to each PDP context would be so much better.

    Brian

> 
> None of that exists today in mobile. I feel the effort and scale are daunting, so i am not going to do it. 
> 
> But, getting a knob in the gateway to set the RA to be 60 (or other) instead of 64 would be easy. And, that knob could be constrained to only compatible device type (chef’s kisses!)... it can be done
> 
> 
> 
>     Best regards,
>     Ole
> 
>

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 9 Nov 2020 01:16:39 -0500

Another point as far as IPv6 exhaustion possibilities is that IANA could
release additional blocks per RFC 3587.

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

Current GUA:
2000::/3 Global Unicast [RFC3513 <https://www.iana.org/go/rfc3513>][RFC4291
<https://www.iana.org/go/rfc4291>] The IPv6 Unicast space encompasses the
entire IPv6 address range with the exception of ff00::/8, per [RFC4291
<https://www.iana.org/go/rfc4291>]. IANA unicast address assignments are
currently limited to the IPv6 unicast address range of 2000::/3. IANA
assignments from this block are registered in [IANA registry
*ipv6-unicast-address-assignments*
<https://www.iana.org/assignments/ipv6-unicast-address-assignments>]. [7
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note7>]
[8
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note8>]
[9
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note9>]
[10
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note10>]
[11
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note11>]
[12
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note12>]
[13
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note13>]
[14
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note14>]
[15
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note15>
]

2^125 =

42,535,295,865,117,307,932,921,825,928,971,026,432

Other IETF reserved allocations that could be released in the future.
0000::/8 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>] [1
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note1>]
[2
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note2>]
[3
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note3>]
[4
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note4>]
[5
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note5>]
[6
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note6>
]
0100::/8 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>] 0100::/64 reserved for
Discard-Only Address Block [RFC6666 <https://www.iana.org/go/rfc6666>].
Complete registration details are found in [IANA registry
*iana-ipv6-special-registry*
<https://www.iana.org/assignments/iana-ipv6-special-registry>].
0200::/7 Reserved by IETF [RFC4048 <https://www.iana.org/go/rfc4048>]
Deprecated
as of December 2004 [RFC4048 <https://www.iana.org/go/rfc4048>]. Formerly
an OSI NSAP-mapped prefix set [RFC4548 <https://www.iana.org/go/rfc4548>].
0400::/6 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
0800::/5 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
1000::/4 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
2000::/3 Global Unicast [RFC3513 <https://www.iana.org/go/rfc3513>][RFC4291
<https://www.iana.org/go/rfc4291>] The IPv6 Unicast space encompasses the
entire IPv6 address range with the exception of ff00::/8, per [RFC4291
<https://www.iana.org/go/rfc4291>]. IANA unicast address assignments are
currently limited to the IPv6 unicast address range of 2000::/3. IANA
assignments from this block are registered in [IANA registry
*ipv6-unicast-address-assignments*
<https://www.iana.org/assignments/ipv6-unicast-address-assignments>]. [7
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note7>]
[8
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note8>]
[9
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note9>]
[10
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note10>]
[11
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note11>]
[12
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note12>]
[13
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note13>]
[14
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note14>]
[15
<https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml#note15>
]
4000::/3 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
6000::/3 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
8000::/3 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
a000::/3 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
c000::/3 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
e000::/4 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
f000::/5 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]
f800::/6 Reserved by IETF [RFC3513 <https://www.iana.org/go/rfc3513>][
RFC4291 <https://www.iana.org/go/rfc4291>]

https://tools.ietf.org/html/rfc3587

See section 2 3rd paragraph.

2 TLA/NLA Made Historic

   RFC 2374 <https://tools.ietf.org/html/rfc2374> was the definition
of addre.  sses for Format Prefix 001
   (2000::/3) which is formally made historic by this document.  Even
   though currently only 2000::/3 is being delegated by the IANA,
   implementations should not make any assumptions about 2000::/3 being
   special.  In the future, the IANA might be directed to delegate
   currently unassigned portions of the IPv6 address space for the
   purpose of Global Unicast as well.

On Sun, Nov 8, 2020 at 7:33 PM Mark Andrews <[email-masked]> wrote:

> other threads on this topic over the last several years. There was a repeat
> of the usual speculation, generalisation and echo-chamber mechanics which
> have characterised this discussion at the ietf since more-or-less forever.
> >
> Telcos only supplying /64 despite 3GPP supporting shorter than /64.  Every
> Telco that only supplies /64 has raced to the bottom.  There was reasons
> for this initially.  Some devices did not work correctly with short than
> /64 because their developers fail to properly test them before releasing
> them.  Its now a decade later and many of those Telcos are still doing /64.
>
> DHCP-PD supports STATIC leases.  Whether you get a static of dynamic lease
> depends on the functionality the DHCP server vendor built in and how the
> server is configured.
>
> > Nick
> >
-- 

*Gyan Mishra*

---

From: [email-masked]
Date: Mon, 9 Nov 2020 08:18:57 +0100

> But, getting a knob in the gateway to set the RA to be 60 (or other) instead of 64 would be easy. And, that knob could be constrained to only compatible device type (chef’s kisses!)... it can be do…

You could operate DHCP PD the exact same way.

cheers,
Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 10:09:01 +0100

I tried to find the information in my notes, but it was a casual testing, not in the scope of the customer project, I just took the opportunity to test it because I saw an LTE router and a network "combination" that was supporting it. Tested and worked. I recall there were many LTE routers (kind of CPEs with SIM support), most of them were from Chinese's vendors (some well-known brands such as Huawei).

El 8/11/20 23:44, "ipv6 en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    It is the case.

    Alex

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 10:16:06 +0100

Unless I got it wrong, Apple started some years ago to make their own chipsets for "everything", including the cellular interface.

I know ARM is not a "modem" manufacturer, but many vendors are using their designs as part of the CPUs and SoC they make, including Apple and Broadcom, for example and ARM is aware of those developments, because it requires a specific license with each customer, I believe.

Regarding Qualcomm, I can't believe they are "blocking" with no-way-back specific UDP or TCP ports. This may break many other things. I could understand that their default SDK or implementation, or whatever is doing that, but not that you can't re-configure it for your own purpose. It will be a very bad design, as it closes yourself the doors for other purposes.

About Android and DHCPv6, we all know. But I don't know if it is true for a DHCPv6-PD client. I guess Android is being used also in some (mobile and broadband) CPEs, which need that feature.

We need to understand *in detail* why cellular vendors aren't using DHCPv6-PD, even if it is in the 3GPP specs.

Regards,
Jordi
@jordipalet

El 9/11/20 0:05, "ipv6 en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Nov 2020 10:24:20 +0100

I think there are many instances where one tries DHCPv6 on a computer 
connected to LTE and it appears to be working.

But there might be some details in that high level statement that might 
not be enough for what we try to achieve.

For example, executing DHCPv6 on an processor running linux did succeed 
to ask for IPv6 addresses to a modem on LTE.  But the modem itself 
transformed that DHCPv6 request into something else (a link layer 
message) that is not DHCPv6.   We too have tried such configuration - 
execute DHCPv6 on the processor - but the LTE operator did not receive 
any DHCPv6 message from us.

We have writen a draft that tries to explain, among other things, that 
difference between a processor and the modem, and the behaviour of 
DHCPv6 on them.  The file name is draft-shytyi-v6ops-danir-05 and it is 
titled "DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR)". 
In particular, in the figure before section 8, one can see a computer 
User Equipment made of a laptop with an E329 USB Dongle.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 Nov 2020 10:34:38 +0100

[...]
> Just handing out a /56 to each PDP context would be so much better.

Sounds reasonable because a /56 is so much space, and can make several /64s.

But still, it would not be enough.  How would the smartphone form an
IPv6 address when receiving a /56 in the RA?  There is no spec that
tells it how to, because the IID must be 64bit and the smartphone would
not know how to pad the remaining 8 bits.

At that point the operator might want to put a /64 in an RA and also
respond to DHCPv6-PD with a /56 inside.  It would be a double address
architecture effort.

This is why I am wondering how would one think the smartphone would be
happy enough when receiving a /56 in a DHCPv6 advertisement.

Alex

> 
> Brian
> 
>> 
>> None of that exists today in mobile. I feel the effort and scale 
>> are daunting, so i am not going to do it.
>> 
>> But, getting a knob in the gateway to set the RA to be 60 (or 
>> other) instead of 64 would be easy. And, that knob could be 
>> constrained to only compatible device type (chef’s kisses!)... it 
>> can be done
>> 
>> 
>> 
>> Best regards, Ole
>> 
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 10:39:20 +0100

I think there is some performance testing done in ISC KEA, which allows distributed DHCPv6 (including PD) servers, HA features, etc. I don't think this should be a different problem than the fact that they need to run many APNs, authentications servers, billing, DPI, firewalling, etc., for the same number of hundreds of millions of customers (in the bigger cases of cellular networks).

Regards,
Jordi
@jordipalet

El 9/11/20 2:26, "ipv6 en nombre de Brian E Carpenter" <[email-masked] en nombre de [email-masked]> escribió:

        Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 10:52:46 +0100

There are many solutions for that, and in fact, some of them, not "in RFCs" are being used.

For example, you can use by default the first /64 for the WAN link, then 2nd one for the smartphone itself, then the rest don't need to be standardized. In fact, which one uses the smartphone itself is not needed.

See RFC3633, and also https://tools.ietf.org/html/draft-palet-v6ops-p2p-links-04.

In fact, I recall having seen some slides or document indicating that each /64 allocated to a smartphone is actually a /60 and part of it is the p2p link, but I'm not sure if that was before the actual standards, just an idea, or actual standards. I need to find that document to make sure ....

... Just found it! https://www.rmv6tf.org/wp-content/uploads/2012/11/Cisco_Suthar_Designing-LTE-with-IPv6_26-April-20111.pdf

Regards,
Jordi
@jordipalet

El 9/11/20 10:35, "ipv6 en nombre de Alexandre Petrescu" <[email-masked] en nombre de [email-masked]> escribió:

    [...]

    Alex

---

From: Simon Hobson <[email-masked]>
Date: Mon, 9 Nov 2020 10:06:42 +0000

> Yet another person missing the point and harkening back to the idea that anyone is trying to conserve  ipv6 addresses. 
> 
> Please stop. 

Have you heard of the expression "don't shoot the messenger" ?
People are telling you what they observe. Right or wrong, there **ARE** ISPs out there where "bottom line" is the only thing they care about, and customer experience come last on the list of priorities.

You'd think that an ISP selling (more or less) only DSL services which tend to be "always on" by their nature would achieve no saving by having dynamic address allocation vs static - but they still cling to the belief that a fixed IP is something that either costs them more, or at the very least is something they can screw the customer over.

You keep telling people that this is "not a thing" without presenting any evidence whatsoever. We all know that the IPv6 address space is "very big", but the evidence is there that some ISPs are not treating it the way you claim they all will. You've already been given stats that show that a significant number of ISPs are choosing to only supply a /64 when it has always been recommended practice to offer a larger allocation. And you've also been given evidence that some ISPs would offer a much smaller (even a /127) allocation if they could get away with it.

Simon

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 11:18:20 +0100

>However, the privacy arguments are fairly strong for not going beyon
>d /80, I think, at any time in the future.

Peronally I'm a lot more worried about collisions. At the moment we have
no operational experience with collisions. Does DAD work? We don't really
know. How does a device recover if it picked an address that is a duplicate
of another.

If we look at /96. That means that more than one in 4 billion addresses
generated is a collision. If IPv6 is adopted worldwide, that will be many
collisions per day. 

A key question here is: do we set a relatively safe limit that allows us
to ignore DAD because duplicates essentially never happen, or do we let 
operator pick a prefix length, spend quite a bit of time trying to deal
with all the collisions that result.

For example, at the moment a low power IoT device could just switch off for
a while and resume. Technically that would be wrong, but in practice it works.
What would we do if IoT devices would randomly renumber do to collisions?

If we set a hard limit, then we are back at the original question, how do you
extend network if you got the longest possible prefix that is supported.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2020 11:21:16 +0100 (CET)

> the bottom, once. But it's much too early for that.

I still fully agree with this. To this day, I run into people who want to 
via DHCPv6 assign a single address to each host. They do not care that 
this host might be running docker containers, VMs or whatever, that might 
benefit from having a GUA. To them it's "obvious" way to do, because 
that's how it's "always" been done.

They've already completed the race to the bottom, and indeed that's a 
/128.

We see all this /64 deployment because ISPs are saying "why more, there is 
just a single LAN?" and then /64 PD is the natural result of that thought 
process. This is the *only* thing stopping them from assigning smaller 
subnets. I'm sure there are plenty who started out with /120 and then 
discovered that didn't work, did some research and discovered "oh, I need 
/64" and then that was that.

I do agree we should try to solve this problem so that my machine can get 
for instance a /112 assigned to it in one go, basically "prefix 
registration" so the upstream router can assign a large subnet to a host 
and install a route for that. Still, that doesn't solve the nested doll 
problem with router->router->router->machine->VM->docker etc that we want 
to support.

I don't know how to solve this, but letting go of the /64 limit makes me 
very Fearful, Uncertain and Doubtful about the future.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2020 22:05:41 +1100

On Mon, 9 Nov 2020, 20:39 JORDI PALET MARTINEZ, <jordi.palet=
[email-masked]> wrote:

> I think there is some performance testing done in ISC KEA, which allows
> distributed DHCPv6 (including PD) servers, HA features, etc. I don't think
> this should be a different problem than the fact that they need to run many
> APNs, authentications servers, billing, DPI, firewalling, etc., for the
> same number of hundreds of millions of customers (in the bigger cases of
> cellular networks).
>

HFC cable networks would have run large scale DHCPv4 for decades now. As an
example of their scale, I remember one if the large US ones wanting IPv6
just for cable modem management, because they'd run out of RFC1918
addresses.

 It's not a new problem.

Regards,
Mark.

> Regards,
> Jordi
> @jordipalet
>
>
>
> El 9/11/20 2:26, "ipv6 en nombre de Brian E Carpenter" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>     >     > There is already a solution to this: use DHCPv6 PD on 5G
> networks. It's been supported since 3GPP release 10 several years ago.
>     >     >
>     >     > Perhaps the mobile providers have seen what an operational
> nightmare dhcpv6 pd is and... are like nope.
>     >     >
>     > I believe running a dhcp server supporting 120M mobile subscribers
> would be a nightmare.  I believe dhcpv6 is a larger stateful database and a
> not very forgiving protocol... and client implementations are ...
> heterogeneous. ... and server failover.. messy
>
>     Of course. You would have to run thousands of DHCPv6 servers out in
> the wild. Certainly there would need to be some distributed address pool
> management too. Just handing out a /56 to each PDP context would be so much
> better.
>
>         Brian
>
>     >

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 12:26:22 +0100

Agree (I’m saying should not be a problem), but don’t compare the scale of “huge cellular” providers with the any of the top bigger broadband ones …

Regards,

Jordi

@jordipalet

El 9/11/20 12:06, "ipv6 en nombre de Mark Smith" <[email-masked] en nombre de [email-masked]> escribió:

On Mon, 9 Nov 2020, 20:39 JORDI PALET MARTINEZ, <jordi.palet=[email-masked]> wrote:

HFC cable networks would have run large scale DHCPv4 for decades now. As an example of their scale, I remember one if the large US ones wanting IPv6 just for cable modem management, because they'd run out of RFC1918 addresses.

 It's not a new problem.

Regards,

Mark.

Regards,
Jordi
@jordipalet

        Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2020 12:28:21 +0100 (CET)

> compatible device type (chef’s kisses!)... it can be done

If you already know what /56 the customer has (because you assign it the 
same way as the default bearer /64 is assigned today), you don't need a 
full-on stateful dhcpv6 server in the PDN gateway. You can do it 
statelessly and just respond with the same /56 regardless. You don't need 
a full DHCPv6-PD server, you just need a bare-bones DHCPv6 responder that 
takes information from the local pool database that it already uses to 
keep track of what prefix goes to what bearer.

There is also nothing stopping you from sending two RAs, one for the /64 
and one for /56 and then just 3GPP standardize that this means the /56 is 
routed to you. I'd fully support also having an additional flag in the RA 
saying "if you received this RA, it means I routed the entire PIO to you" 
and you own it.

That flag would be useful also on PPPoE or any kind of point to point 
media (like Ole p2p ethernet proposal).

We've discussed this before. Let's go that route and give people larger 
prefixes instead of trying to carve up that poor /64 into smaller pieces.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2020 12:36:00 +0100 (CET)

On Mon, 9 Nov 2020, Mikael Abrahamsson wrote:

> statelessly and just respond with the same /56 regardless. You don't 
> need a full DHCPv6-PD server, you just need a bare-bones DHCPv6 
> responder that takes information from the local pool database that it 
> already uses to keep track of what prefix goes to what bearer.

https://www.etsi.org/deliver/etsi_ts/123400_123499/123401/11.03.00_60/ts_123401v110300p.pdf 
talks about /56 instead of /64, and then it uses PD-exclude for the 
RA-announced "classic" /64 on the bearer.

This seems to me like it was designed *exactly* to avoid more state in the 
PDN gateway. You just assign a /56 to each bearer, send the /64 RA as you 
always do, then if someone happens to ask for DHCPv6-PD you respond with 
that /56. There is no additional "DHCP-servers" etc, you just need a bare 
minimum DHCPv6-PD "announcer/responder".

I can't believe this standard was done in 2011 and now 9 years later we're 
still not any further into deployment. Why?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 07:00:36 -0500

> People are telling you what they observe. Right or wrong, there **ARE** ISPs out there where "bottom line" is the only thing they care about, and customer experience come last on the list of priori…

Simon, the thing you’re glossing over here, which I actually don’t hear anybody talking about, is that there has thus far been no market pressure that could punish ISPs that hand out /64s. What’s the bad outcome for the end user in practice? They can’t subnet their home network? Well, they don’t, do they? HNCP has a market penetration of 0% right now.

We can reasonably expect this to change in the next year or two. Several initiatives are underway at the moment that are likely to suffer from the absence of a narrower allocation: specifically CHIP and Thread, both of which rely on 802.15.4.6lowpan networks. It’s reasonable to expect that these technologies will start to be deployed in homes in significant numbers in the near future.

At present, when such technologies are deployed, they will be forced to rely on IPv4 for cloud service reachability for ISPs that don’t provide an allocation narrower than /64. Since these networks are v6-only, this will be done using NAT64. And this will work fine, except that the ISP is now stuck giving the customer an IPv4 address.

What is less scarce than an IPv4 address? Why, a /60 or a /56. These are 2^28 or 2^24 less scarce than IPv4 addresses, respectively.

So all this fuss about how to solve the problem of ISPs only giving out /64s is genuinely premature. Market forces will change their behavior. It’s just a matter of time.

---

From: Simon Hobson <[email-masked]>
Date: Mon, 9 Nov 2020 12:10:35 +0000

Mikael Abrahamsson <swmike=[email-masked]> wrote:

> We've discussed this before. Let's go that route and give people larger prefixes instead of trying to carve up that poor /64 into smaller pieces.

Perhaps we're simply looking at the problem from the wrong angle ?

Perhaps the right question to be considering is "HOW do we persuade that subset of ISPs that they need to allocate a /56 or /48 ?" It seems to me, that if we can solve that one, then all the rest of the discussion becomes moot.

That's already in the various best practice guides, and has been since ... like forever. But some are either not seeing it, not understanding it, not acting on it as it conflicts with everything they "know" about networking, or just don't see any reason to act on it as it conflicts with their commercial priorities.

I'll put a magic wand on my ${festive_season} list :D

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2020 13:40:36 +0100 (CET)

On Mon, 9 Nov 2020, Ted Lemon wrote:

> So all this fuss about how to solve the problem of ISPs only giving out 
> /64s is genuinely premature. Market forces will change their behavior. 
> It’s just a matter of time.

There is an additional requirement here that is also an issue, and that's 
the lack of DHCPv6-PD support in the RG on its LAN interface, to 
sub-delegate any space it might have. This is not very common 
unfortunately, I see people show up weekly on the IRC channels I hang out 
in, with non-working IPv6 because they hooked up their Openwrt router 
behind their ISP router and it didn't support PD (even if there actually 
was a /56 delegated to the ISP-provided RG).

Other vendors also do not support this, one fairly popular brand is 
Ubiquiti that I see a lot of, which doesn't support sub-PD.

>From what I can tell, working as a delegating router within the home is 
not in RFC7084.

I use openwrt at home primarily for this reason, as it does support 
sub-PD.

Unfortunately I don't think normal users will notice the lack of /64 or 
larger within the home. Software vendors will have to work around this 
with IPv4 fallback just like you say, to ensure a good customer 
experience. They will invisibly to the user workaround the problem to hide 
this network deficiency. It'll cost everybody time and money without 
anyone really noticing.

PS. I still remember my first IETF meeting, in Stockholm where I blundered 
at the mic about this and made a fool of myself with a "how hard can it 
be?" comment regarding sub-PD. That was 2009, and we're still not further 
ahead afaik.

---

From: [email-masked]
Date: Mon, 9 Nov 2020 13:44:39 +0100

> There is an additional requirement here that is also an issue, and that's the lack of DHCPv6-PD support in the RG on its LAN interface, to sub-delegate any space it might have. This is not very common unfortunately, I see people show up weekly on the IRC channels I hang out in, with non-working IPv6 because they hooked up their Openwrt router behind their ISP router and it didn't support PD (even if there actually was a /56 delegated to the ISP-provided RG).
> 
> Other vendors also do not support this, one fairly popular brand is Ubiquiti that I see a lot of, which doesn't support sub-PD.
> 
> I use openwrt at home primarily for this reason, as it does support sub-PD.
> 
> Unfortunately I don't think normal users will notice the lack of /64 or larger within the home. Software vendors will have to work around this with IPv4 fallback just like you say, to ensure a good customer experience. They will invisibly to the user workaround the problem to hide this network deficiency. It'll cost everybody time and money without anyone really noticing.
> 
> PS. I still remember my first IETF meeting, in Stockholm where I blundered at the mic about this and made a fool of myself with a "how hard can it be?" comment regarding sub-PD. That was 2009, and we're still not further ahead afaik.

sub-PD aka hierarchical PD only works in very specific topologies.
Which is why the IETF consensus went to another solution instead.

Cheers,
Ole

---

From: Simon Hobson <[email-masked]>
Date: Mon, 9 Nov 2020 12:49:13 +0000

> What is less scarce than an IPv4 address? Why, a /60 or a /56. These are 2^28 or 2^24 less scarce than IPv4 addresses, respectively.

I think all of us on this list know that - it would seem that many don't.

> So all this fuss about how to solve the problem of ISPs only giving out /64s is genuinely premature. Market forces will change their behavior. It’s just a matter of time.

I applaud your optimism !

Would these be the same market forces that give many of you in the US a choice of exactly one (the cable company covering your area) or zero (if you live anywhere the cable companies have decided isn't worthwhile) "high speed" internet provider ? I know we have our problems over here in the UK, but they do seem relatively minor compared to what I read about over there.

Besides, as long as "stuff works" and the general population don't understand "all this technical stuff", then customers aren't going to be complaining. Until some of the IOT vendors (taking your examples) start telling customers that "your network is broken, this stuff will stop working unless you fix it" then there never will be any pressure on the ISPs to change.

> Other vendors also do not support this, one fairly popular brand is Ubiquiti that I see a lot of, which doesn't support sub-PD.

Unless they've fixed that, their access points also filter out IPv6 altogether (ibtables rule IIRC).

> Unfortunately I don't think normal users will notice the lack of /64 or larger within the home. Software vendors will have to work around this with IPv4 fallback just like you say, to ensure a good…

Exactly. Lots of devs/support people/whatever will be forced to waste loads of effort working around this - just like they have done for years with NAT. And the end users will only see a problem when it doesn't work - but they won't be blaming their ISP because (unless the vendor takes the effort to educate them) they just won't know.

Simon

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Nov 2020 13:53:17 +0100 (CET)

> Unless they've fixed that, their access points also filter out IPv6 altogether (ibtables rule IIRC).

Afaik this is on the guest lan / captive portal stuff. I personally have 
ubiquiti APs and running them in standard WPA2-PSK config they support 
IPv6 just fine (one might want to tweak DTIM though, but that has nothing 
to do with ebfilter).

---

From: Jared Mauch <[email-masked]>
Date: Mon, 9 Nov 2020 07:55:25 -0500

> On Nov 9, 2020, at 7:53 AM, Mikael Abrahamsson <swmike=[email-masked]> wrote:
> 
> Afaik this is on the guest lan / captive portal stuff. I personally have ubiquiti APs and running them in standard WPA2-PSK config they support IPv6 just fine (one might want to tweak DTIM though, but that has nothing to do with ebfilter).

Yes, I turned off the captive portal stuff because of the lack of a redirect on IPv6 to the captive portal and the way they implemented it.  You can workaround it, but it’s basically just letting v6 through, so you’ll see the captive portal when you reach things on v4 but not v6.

- Jared

https://community.ui.com/questions/IPV6-on-Guest-network/61fe37c4-b0a7-4fb7-b97b-49b6a7063caf

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 08:30:17 -0500

> Besides, as long as "stuff works" and the general population don't understand "all this technical stuff", then customers aren't going to be complaining. Until some of the IOT vendors (taking your e…

Users won’t pressure ISPs. ISPs will want to move away from NAT64 on stub networks. When this becomes a pain point for them, they will suddenly see salvation in narrower delegations. Until then, they will not. There is nothing we can do to hurry this other than to continue to innovate in places where we do have agency.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2020 14:36:44 +0100

>That's already in the various best practice guides, and has been since ... l
>ike forever. But some are either not seeing it, not understanding it, not ac
>ting on it as it conflicts with everything they "know" about networking, or 
>just don't see any reason to act on it as it conflicts with their commercial
> priorities.

In the context of mobile, mobile telcos present each new generation of
mobile technology as some sort of revolution. The best way to connect
to the internet.

It may help if infuential parties explictly call out issues with mobile
deployment. I.e., if the automotive industry would say, 5G is nice but
we can't number networks in a car so we need something else.

The trent seems to be, something doesn't work with mobile so we need to
go to the IETF to make a change to internet standards. 

That said, I would would be happy to get any kind of IPv6 on my phone
at all.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 9 Nov 2020 10:16:54 -0500

It is clear to me that any solution will require changes on the UE / RG 
as well as in the ISP infrastructure.

If we take as an assumption that we want this to work without DHCP, then 
we presumably are changing RAs.
At that point,  the question I see is whether it is cleaner to specify 
how this works (maybe with an extra flag) using an RA to allocate a /56 
to the UE, or whether it is cleaner to change the rules to allow 
sub-allocation from /64 and change the RA to have bits indicating when 
the UE is doing that.
It seems to me that the former is MUCH cleaner than the later.

Yours,
Joel

On 11/9/2020 4:34 AM, Alexandre Petrescu wrote:
>>> instead of 64 would be easy. And, that knob could be constrained to 
>>> only compatible device type (chef’s kisses!)... it can be done
>>>
>>>
>>>
>>> Best regards, Ole
>>>
>>>

---

From: Ca By <[email-masked]>
Date: Mon, 9 Nov 2020 08:13:10 -0800

> same number of hundreds of millions of customers (in the bigger cases of
All those things you mentioned above (billing,  dpi, ...)  are working today

Dhcpv6 is not. Has not. Will not.

Just like the story of 464xlat, we can deploy ipv6 if we listen to what
mobile operators in the ietf are saying.

Just like back then, the ietf simply said use dual-stack, no need for
464xlat. Same story now, folks say use dhcpv6. Not helpful.

---

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

On Mon, Nov 9, 2020 at 2:07 AM Simon Hobson <[email-masked]> wrote:

> People are telling you what they observe. Right or wrong, there **ARE**
> ISPs out there where "bottom line" is the only thing they care about, and
> customer experience come last on the list of priorities.
>
> You'd think that an ISP selling (more or less) only DSL services which
> tend to be "always on" by their nature would achieve no saving by having
> dynamic address allocation vs static - but they still cling to the belief
> that a fixed IP is something that either costs them more, or at the very
> least is something they can screw the customer over.
>
> You keep telling people that this is "not a thing" without presenting any
> evidence whatsoever. We all know that the IPv6 address space is "very big",
> but the evidence is there that some ISPs are not treating it the way you
> claim they all will. You've already been given stats that show that a
> significant number of ISPs are choosing to only supply a /64 when it has
> always been recommended practice to offer a larger allocation. And you've
> also been given evidence that some ISPs would offer a much smaller (even a
> /127) allocation if they could get away with it.
>
> Simon
>

Then let’s leave it at that.

Anti-ipv6 conservation action is not a problem to solve in the ietf.

I am a mobile operator and i want the ietf’s help to provide < /64 prefixes
to my users. I want to give them more ipv6 space. Help me focus the
conversation on how to engineer better methods to deploy larger blocks of
space.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Nov 2020 17:59:59 +0100

Hi Cameron,

You know that I’ve been defending 464XLAT in broadband as well … so your comment is not fair in my own case.

Let me clarify my point.

I know that authentication, billing, dpi, etc., are working for even the bigger cellular providers. What I’m saying is that if those have been able to scale in a safe way for you, DHCPv6-PD should be as well.

I’m just trying (and I think many folks in this discussion), why the 3GPP incorporated DHCPv6-PD in the standards, and however, is not being used. We are missing facts, reasons, why it doesn’t work.

Regards,

Jordi

@jordipalet

El 9/11/20 17:13, "ipv6 en nombre de Ca By" <[email-masked] en nombre de [email-masked]> escribió:

On Mon, Nov 9, 2020 at 1:39 AM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regards,
Jordi
@jordipalet

Just like the story of 464xlat, we can deploy ipv6 if we listen to what mobile operators in the ietf are saying. 

Just like back then, the ietf simply said use dual-stack, no need for 464xlat. Same story now, folks say use dhcpv6. Not helpful. 

        Brian

---

From: Simon Hobson <[email-masked]>
Date: Mon, 9 Nov 2020 17:30:58 +0000

> Dhcpv6 is not. Has not. Will not.

That's a bold statement. "is not, has not" may well be correct, but I fail to see why "will not" is a valid statement other than for vested interests deciding to nobble it. Reading some bits of the discussion, it sounds a bit like locking a horse in it's stable and then complaining that it didn't finish the race !

> I am a mobile operator and i want the ietf’s help to provide < /64 prefixes to my users. I want to give them more ipv6 space. Help me focus the conversation on how to engineer better methods to deploy larger blocks of space. 

OK, that probably deserves a new thread - it's almost completely orthogonal to the original question of splitting a single /64 to make multiple networks.
What specifically is stopping you from doing that now, with the tools available ?

TBH, the technicalities have gone beyond what I've learned, but I've seen talk in this thread (thread of threads) suggesting that it's supported by the mobile standards (3GPP ?) but it's just that some operators are stuck in an "everything is a /64" mindset. I get the impression that there are people in here that do have the in depth knowledge of how to do it. I do suspect that it may also depend on what kit you currently have in your network.

Simon

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Nov 2020 06:47:05 +1100

On Mon, 9 Nov 2020, 23:01 Ted Lemon, <[email-masked]> wrote:

> Simon, the thing you’re glossing over here, which I actually don’t hear
> anybody talking about, is that there has thus far been no market pressure
> that could punish ISPs that hand out /64s. What’s the bad outcome for the
> end user in practice? They can’t subnet their home network? Well, they
> don’t, do they? HNCP has a market penetration of 0% right now.
>

I think the current and existing need that wouldn't be being satisfied with
a single /64 are things like a guest WIFI SSID in the home, or perhaps a
kids SSID where Internet access policy can be applied.

With IPv4, the current home internal address space is effectively the
entire RFC1918 space behind the NAT implementation.

The common exception is when an employer's RFC1918 space needs to be
excluded so the employee can VPN in from home without traffic instead going
to the local instance of that address space.

It seems fairly common for corporates to use 10/8, or sometimes 172.16/12,
and common for IPv4 CPE to use 192.168/16, naturally avoiding this address
space duplication issue.

So limiting to 192.168/16, with the /24 common subnet length, IPv4 users
have 256 /24s for their CPE to dole out for these purposes, equivalent to
an IPv6 /56.

Regards,
Mark.

> We can reasonably expect this to change in the next year or two. Several
> initiatives are underway at the moment that are likely to suffer from the
> absence of a narrower allocation: specifically CHIP and Thread, both of
> which rely on 802.15.4.6lowpan networks. It’s reasonable to expect that
> these technologies will start to be deployed in homes in significant
> numbers in the near future.
>
> At present, when such technologies are deployed, they will be forced to
> rely on IPv4 for cloud service reachability for ISPs that don’t provide an
> allocation narrower than /64. Since these networks are v6-only, this will
> be done using NAT64. And this will work fine, except that the ISP is now
> stuck giving the customer an IPv4 address.
>
> What is less scarce than an IPv4 address? Why, a /60 or a /56. These are
> 2^28 or 2^24 less scarce than IPv4 addresses, respectively.
>
> /64s is genuinely premature. Market forces will change their behavior. It’s
> just a matter of time.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 15:21:53 -0500

On Nov 9, 2020, at 2:47 PM, Mark Smith <[email-masked]> wrote:
> I think the current and existing need that wouldn't be being satisfied with a single /64 are things like a guest WIFI SSID in the home, or perhaps a kids SSID where Internet access policy can be applied.

That’s true, but the same caveat applies: right now, the ISP is giving the customer an IPv4 address, and so they can just do NAT. If IPv6 doesn’t work because they gave out a /64, right now they feel no pain. Later on, when they are trying to economize on IPv4 support, the pain will become more apparent, and then it’ll seem obvious and cheap to start giving out narrower PDs.

---

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

On Mon, Nov 9, 2020 at 3:22 PM Ted Lemon <[email-masked]> wrote:

> I think the current and existing need that wouldn't be being satisfied
> with a single /64 are things like a guest WIFI SSID in the home, or perhaps
> a kids SSID where Internet access policy can be applied.
>
>
> That’s true, but the same caveat applies: right now, the ISP is giving the
> customer an IPv4 address, and so they can just do NAT. If IPv6 doesn’t work
> because they gave out a /64, right now they feel no pain. Later on, when
> they are trying to economize on IPv4 support, the pain will become more
> apparent, and then it’ll seem obvious and cheap to start giving out
> narrower PDs.
>

   Or if the IID 64 bit boundary is eliminated the /64 would be sufficient
and could be sub divided.  Now there is not any dependency on PD and even
today broadband operators are still giving out /64 and not /56 or larger.
Without going down the painful NAT ULA path it makes sense to easily solve
the single /64 allocation issue which exists for 3GPP PDP but also exists
for wired broadband only getting a /64 via PD.  Now they wont have to wait
for providers to make a change as they can now can autonomously do their
own segmentation.

-- 

*Gyan Mishra*

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Nov 2020 16:47:08 -0500

On Nov 9, 2020, at 4:29 PM, Gyan Mishra <[email-masked]> wrote:
>    Or if the IID 64 bit boundary is eliminated the /64 would be sufficient and could be sub divided.  Now there is not any dependency on PD and even today broadband operators are still giving out /64 and not /56 or larger.  Without going down the painful NAT ULA path it makes sense to easily solve the single /64 allocation issue which exists for 3GPP PDP but also exists for wired broadband only getting a /64 via PD.  Now they wont have to wait for providers to make a change as they can now can autonomously do their own segmentation.

Right, but I’m certainly not going to code that up. I’m perfectly happy to stick with NAT64 for sites that don’t support IPv6 prefix delegation. As an implementor, what do I gain by splitting the IID for more subnet bits compared to just using NAT64? When I was working on an open source Thread border router implementation, I considered this exact thing, and concluded that supporting IPv6-to-the-cloud for the case where the ISP doesn’t provide at least a /60 and where the CE router doesn’t do internal PD is just a bunch of unnecessary code I’d have to maintain. I _have_ to support NAT64, and I get no added value when I also do NAT66 or whatever weird prefix-sharing hack. I have limited time—I’m not going to code something I don’t need.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 9 Nov 2020 18:12:09 -0500

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

>> That’s true, but the same caveat applies: right now, the ISP is giving
>> the customer an IPv4 address, and so they can just do NAT. If IPv6 doesn’t
>> work because they gave out a /64, right now they feel no pain. Later on,
>> when they are trying to economize on IPv4 support, the pain will become
>> more apparent, and then it’ll seem obvious and cheap to start giving out
>> narrower PDs.
>>
>

So, dumb question, but would it make sense to consider some local
coordination
mechanism that assigns "subnet" meaning to the most significant bits of the
IIDs
on a link? RFC 7136 basically says that IIDs have no structure, RFC 8065
says
we'd like to have at least 46 bits of entropy for IIDs used in global
addresses and
ideally ~59. Other RFCs have defined privacy IIDs, etc. RFC 6282 allows for
compression of arbitrary prefixes; no /64 architectural constraint there.

Kerry

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Nov 2020 12:43:30 +1100

On Tue, 10 Nov 2020, 10:12 Kerry Lynn, <[email-masked]> wrote:

>>    Or if the IID 64 bit boundary is eliminated the /64 would be
>> sufficient and could be sub divided.  Now there is not any dependency on PD
>> and even today broadband operators are still giving out /64 and not /56 or
>> larger.  Without going down the painful NAT ULA path it makes sense to
>> easily solve the single /64 allocation issue which exists for 3GPP PDP but
>> also exists for wired broadband only getting a /64 via PD.  Now they wont
>> have to wait for providers to make a change as they can now can
>> autonomously do their own segmentation.
>>
>
> mechanism that assigns "subnet" meaning to the most significant bits of
> the IIDs

Question is, what does all that effort and cost save when the literal
minimum ISPs and carriers get from an RIR is 4 billion /64s or a /32.

The IETF, implementors and operators would spend millions of dollars in
terms of time and effort to make these changes.

Handing out a single /64 instead of many is saving so little cost that the
ISP or carrier would save more money by spending time finding lost ball
point pens.

(If I recall a calculation I did a few years ago correctly, each /48 costs
$0.03 per year from APNIC in the first year (i.e. including new member
fees) from the most expensive minimum of a /32. Cheaper after that. That's
more than 10 times cheaper than buying one postage stamp per customer per
year.)

Regards,
Mark.

---

From: [email-masked]
Date: Tue, 10 Nov 2020 10:49:41 +0100

> Yes, that is the case of the deployment today. I am simply looking to give < 64 instead of = 64, that is an improvement that is achievable 

If your "yes" was to "ephemeral addressing"...
Not saying we shouldn't do it. But that has massive ramifications for all applications.

It moves IP mobility to the transport or application layer. And would require something like MP-TCP or a new session layer.

I'm also unsure if the network configuration protocols HNCP and ND would work.
You would essentially get renumbered any time the cellular connection to the network flap, right? ;-)

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 11:38:57 +0100

Le 09/11/2020 à 22:47, Ted Lemon a écrit :
> On Nov 9, 2020, at 4:29 PM, Gyan Mishra <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> sufficient and could be sub divided.  Now there is not any 
>> dependency on PD and even today broadband operators are still 
>> giving out /64 and not /56 or larger.  Without going down the 
>> painful NAT ULA path it makes sense to easily solve the single /64 
>> allocation issue which exists for 3GPP PDP but also exists for 
>> wired broadband only getting a /64 via PD.  Now they wont have to 
>> wait for providers to make a change as they can now can 
> Right, but I’m certainly not going to code that up. I’m perfectly 
> happy to stick with NAT64 for sites that don’t support IPv6 prefix 
> delegation. As an implementor, what do I gain by splitting the IID 
> for more subnet bits compared to just using NAT64? When I was
> working on an open source Thread border router implementation, I
> considered this exact thing, and concluded that supporting
> IPv6-to-the-cloud for the case where the ISP doesn’t provide at least
> a /60 and where the CE router doesn’t do internal PD is just a bunch
> of unnecessary code I’d have to maintain. I _have_ to support NAT64,
> and I get no added value when I also do NAT66 or whatever weird
> prefix-sharing hack.

I think this brings in the reason of why it might be too early for
Variable SLAAC with non-64 IIDs - because onne _has_ to support NAT64,
which means one _has_ to think about IPv4 first.

While I tend to agree one has to keep IPv4 in mind for a long time when
designing things, the question of precedence - which one is more
important - influences how things are designed.

> I have limited time—I’m not going to code something I don’t need.

I can understand.

But would one prevent something else coding it?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 10 Nov 2020 11:54:34 +0100

Le 10/11/2020 à 00:12, Kerry Lynn a écrit :
[...]

> coordination mechanism that assigns "subnet" meaning to the most
> significant bits of the IIDs on a link?

I think it is a good idea.  I think that could be in agreement with a 
relevant part in RFC4291 "IPv6 address archi" section 2.5.4 "GUAs" which 
pictures an address as a set of variable length prefix, subnet ID and IID:

>  The general format for IPv6 Global Unicast addresses is as follows:
> 
>    |         n bits         |   m bits  |       128-n-m bits         |
>    +------------------------+-----------+----------------------------+
>    | global routing prefix  | subnet ID |       interface ID         |
>    +------------------------+-----------+----------------------------+
> [end of RFC quote.]

> RFC 7136 basically says that IIDs have no structure, RFC 8065 says
> addresses and ideally ~59. Other RFCs have defined privacy IIDs, etc.
> RFC 6282 allows for compression of arbitrary prefixes; no /64
> architectural constraint there.

So yes, I agree with you - no constraint there.  Thank you for this list 
of RFCs.

There might be many other RFCs that do have the 64bit constraint, like 
the IPv6-over-foo and HIP RFCs.

Alex

> <mailto:[email-masked]> Administrative Requests: 
> /Network Solutions A//rchitect /
> 
> /M 301 502-1347 13101 Columbia Pike /Silver Spring, MD
> 
> 
> <mailto:[email-masked]> Administrative Requests:

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Nov 2020 08:08:34 -0500

Alex, nothing would prevent someone coding it, other than a wish to do what requires the least work and maintenance. 

If I didn’t think IPv4 would be required, maybe I’d do ULA+NAT66. But nobody who is actually deploying a product in a home or commercial setting is going to have that illusion. 

Your situation is a bit different: you are thinking of vehicular networking, IIRC. There it may be the case that you do not need to care about IPv4. But you probably also don’t want your brakes to be reachable from the internet, so ULA is probably fine. 

> On Nov 10, 2020, at 05:39, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> On Nov 9, 2020, at 4:29 PM, Gyan Mishra <[email-masked] <mailto:[email-masked]>> wrote:
>> Right, but I’m certainly not going to code that up. I’m perfectly happy to stick with NAT64 for sites that don’t support IPv6 prefix delegation. As an implementor, what do I gain by splitting the IID for more subnet bits compared to just using NAT64? When I was
>> IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
>

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 15 Nov 2020 17:23:11 -0500

All,

I will be adding a  "race to the bottom" slide to the v6ops deck as that
was a fairly contentious debate and I think you really need to understand
the internet routing architecture to see why there is not a race to the
bottom.  There are two sides to this so we would address both sides.

On side we have  the longer prefix discussion and the "race to bottom" fear
that ISPs will allocate /128.

The other side of this is address size allocation and being able to
allocate shorter prefixes like a /48 per human.

As the Global unicast space 2000::/3 is split between the RIRs and then the
ISPs get their allocation.  Because the allocations are block wise
allocations and not linear even though you have 35 trillion in 2000::/3
that is not what the ISPs are using to service millions of customers.   So
you have to think of it from a service provider allocation perspective and
that gets fairly complicated since you have to large buckets of
subscribers  broadband and cellular.

This will all be addressed in the slide deck on v6ops.

Thank you

Gyan

On Tue, Nov 10, 2020 at 4:50 AM <[email-masked]> wrote:

> > Yes, that is the case of the deployment today. I am simply looking to
> give < 64 instead of = 64, that is an improvement that is achievable
>
> It moves IP mobility to the transport or application layer. And would
> require something like MP-TCP or a new session layer.
>

-- 

*Gyan Mishra*