Subject: Informed regulator about the shorter-than-64 necessity on 3G/4G/5G

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 18 Jan 2021 09:45:07 +0100

Hi, 6MANners,

Today I formulated a brief personal email to some person(s) at the
regulator agency suggesting the allocation of shorter-than-64 prefixes
(e.g. /56) to end users.

I explained that the current situation where each of the mobile
operators deliver a /64 and not shorter to smartphones is not usable for
networks such as mobile hotspots or in-car multi-subnet networks.

I informed that there are some I-D proposals of Variable SLAAC that is
relatively refused at IETF because of the IETF necessity of 64bit (and
not shorter) IIDs.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Jan 2021 19:04:12 -0300

Hi, Alex,

> relatively refused at IETF because of the IETF necessity of 64bit (and

This seems to be confusing things.

Proposals for "classless IPv6" (e.g.: 
draft-bourbaki-6man-classless-ipv6) are meant to allow SLAAC to work 
with *longer* prefixes (i.e., shorter IIDs)

Shorter prefixes (i.e., bigger address blocks leased to users) are 
already supported by DHCPv6-PD, without the need of any additional 
protocol action.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jan 2021 14:19:10 +1100

> On 19 Jan 2021, at 09:04, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Alex,
> 
> Proposals for "classless IPv6" (e.g.: draft-bourbaki-6man-classless-ipv6) are meant to allow SLAAC to work with *longer* prefixes (i.e., shorter IIDs)
> 
> Shorter prefixes (i.e., bigger address blocks leased to users) are already supported by DHCPv6-PD, without the need of any additional protocol action.

I think the intent of the message was to get regulators to force operators to *use* DHCPv6-PD with short prefixes.

There is too big a power differential between the cellular user that want to be able to have multiple subnets and the telcos for free market economics to work.

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jan 2021 09:44:26 +0100

Le 19/01/2021 à 04:19, Mark Andrews a écrit :
>>> Hi, 6MANners, Today I formulated a brief personal email to some 
>>> person(s) at the regulator agency suggesting the allocation of 
>>> shorter-than-64 prefixes (e.g. /56) to end users. I explained 
>>> that the current situation where each of the mobile operators 
>>> deliver a /64 and not shorter to smartphones is not usable for 
>>> I informed that there are some I-D proposals of Variable SLAAC
>>> that is relatively refused at IETF because of the IETF necessity
>>> of 64bit (and not shorter) IIDs.
>> 
>> draft-bourbaki-6man-classless-ipv6) are meant to allow SLAAC to 
>> work with *longer* prefixes (i.e., shorter IIDs)
>> 
> I think the intent of the message was to get regulators to force 
> operators to *use* DHCPv6-PD with short prefixes.

I do not know.

There is a problem when all operators deliver only /64s.  The problem is
for mobile hotspots, vehicular networks, and probably others, who need
more than just a single /64.

In implementation, DHCPv6-PD has itself some problems on smartphones,
regardless of using /64s or other plens.  That DHCPv6 problem is at the
modem manufacturers who block DHCPv6.  A telecom operator might or
rather might not be able to work towards solving it at the modem
manufacturer.

A regulator might work with mobile telecom operator towards assigning
more than a single /64 to end users.

> There is too big a power differential between the cellular user that 
> want to be able to have multiple subnets and the telcos for free 
> market economics to work.

I can see such differential as between large and small dented wheels,
but I dont understand quite what do you mean?  Do you think there are
too few users in need of multiple subnets for make a market uptake?

For my side I can cite figures of the autonomous connected automobiles
market poised to grow to billions of dollars capitalization in the next
few years.

Alex

> 
>> Thanks, -- Fernando Gont SI6 Networks e-mail: [email-masked]
>> [email-masked] Administrative Requests: 
>> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jan 2021 09:54:02 +0100

Le 19/01/2021 à 04:19, Mark Andrews a écrit :
>>> networks such as mobile hotspots or in-car multi-subnet
>>> networks. I informed that there are some I-D proposals of
>>> Variable SLAAC that is relatively refused at IETF because of the
>>> IETF necessity of 64bit (and not shorter) IIDs.
>> 

Could be an idea.

I first formulated it as a need of other-than-64 prefix lengths, and not
in terms of a protocol to require.

We might see whether or not the regulator considers the necessity to
require a particular protocol such as DHCPv6 and DHCPv6-PD.

In the context, this particular regulator was able to formulate a
intentionally brief requirement of deploying 'IPv6 compatible routing'
when allocating spectrum for 5G to mobile operators; it means operators
get 5G spectrum only if they commit on a simple IPv6 commitment too
(among other non-tech commitments).  However, the regulator has
reluctance in expanding that brief 'IPv6 compatible routing'
requirement, because of having experienced too complex requirements that
were too hard check compliance with.

This is one of the reasons I suspect that formulating a simple req only
on the prefix length (and not on protocol compliance) might have some
chance to get through all the way to operators.

Another reason is the following: I suspect a non-64 plen requirement
might be dealt with between the regulator and the operator, whereas a
DHCPv6 protocol requirement might need to involve the modem manufacturer
as well.  It would be a longer path between 3 parties, rather than 2.

Alex

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

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Tue, 19 Jan 2021 18:21:55 +0100

> networks such as mobile hotspots or in-car multi-subnet networks.

Hi,

There are multiple different things to consider here. First of all, 
prefix that is assigned to mobile phone is negotiated through PDPv6 
establishment procedure and not by DHCPv6. That is mostly set to /64 
because different GGSNs choose the IPv6 address of your mobile phone 
differently (yes, I tried with the same mobile phone connecting to 
different GGSN vendors and IPv6 address host part was completely 
different between them, once having ::2 and next vendor declaring some 
random 64bit value as a host part). I would say that for single phone - 
/64 is enough as that's a single host and I would not bother suggesting 
regulators to change that.

However, if PDPv6 context is established and end-device is able to send 
DHCPv6-PD request - then the system should react and assign to that 
device a routable /56 - but that's the way PPPoE works today and mobile 
access should be no different. From what I remember - mobile routers 
already support DHCPv6-PD request - it's just a matter if mobile 
operator is actually listening on DPDv6 "tunnel" for that request and 
react to it.

Maybe people from mobile equipment vendors can chime in and tell us if 
that's supported or not.

Cheers, Jan

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 19 Jan 2021 19:26:50 +0100 (CET)

On Tue, 19 Jan 2021, Jan Zorz - Go6 wrote:

> There are multiple different things to consider here. First of all, prefix 
> that is assigned to mobile phone is negotiated through PDPv6 establishment 
> procedure and not by DHCPv6. That is mostly set to /64 because different

The prefix is "assigned" by sending RA with /64 PIO A=1 down the PDP 
context. I've seen this done automatically at PDP context activation time, 
but the docs also talk about the UE sending RS and GGSN responding with 
RA.

https://tools.ietf.org/html/rfc7066 section 2.3.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jan 2021 06:56:42 +0100

Le 19/01/2021 à 18:21, Jan Zorz - Go6 a écrit :
[...]
> I would say that for single phone - /64 is enough as that's a single 
> host and I would not bother suggesting regulators to change that.

A single phone with a single interface concerned about IPv6 maybe one 
/64 is enough.

But a single phone with multiple interfaces concerned about IPv6 (e.g.
its cellular interface, its WiFi interface in AP mode and a virtual
interface for an internal virtual machine) - do you still think one /64
is enough?

Alex

> 
> However, if PDPv6 context is established and end-device is able to 
> send DHCPv6-PD request - then the system should react and assign to 
> that device a routable /56 - but that's the way PPPoE works today
> and mobile access should be no different. From what I remember -
> mobile routers already support DHCPv6-PD request - it's just a matter
> if mobile operator is actually listening on DPDv6 "tunnel" for that 
> request and react to it.
> 
> Maybe people from mobile equipment vendors can chime in and tell us 
> if that's supported or not.
> 
> Cheers, Jan
> 
>  IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Yucel Guven <[email-masked]>
Date: Wed, 20 Jan 2021 20:56:29 +0300

> "There is too big a power differential between the cellular user that
want to be able to have multiple subnets and the telcos for free market
economics to work."

More explicitly?  Do you mean that cellular operators 'do not want you
share your internet connection'  for free market economics to work?

Regards,

On Tue, Jan 19, 2021 at 6:19 AM Mark Andrews <[email-masked]> wrote:

> draft-bourbaki-6man-classless-ipv6) are meant to allow SLAAC to work with
> *longer* prefixes (i.e., shorter IIDs)
> >
> already supported by DHCPv6-PD, without the need of any additional protocol
> action.
>
> There is too big a power differential between the cellular user that want
> to be able to have multiple subnets and the telcos for free market
> economics to work.
>
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks

---

From: Simon Hobson <[email-masked]>
Date: Thu, 21 Jan 2021 09:53:06 +0000

Yucel Guven <[email-masked]> wrote:

> > "There is too big a power differential between the cellular user that want to be able to have multiple subnets and the telcos for free market economics to work."
> 
> More explicitly?  Do you mean that cellular operators 'do not want you share your internet connection'  for free market economics to work?

There is that. My "gut feeling" from observation is that cellular operators don't (or didn't) want users to be sharing the connection - that means you are not paying them a separate fee for each device that's using bandwidth. I can't speak for the US market, but here in the UK it does seem that the attitude has changed over the years - possibly an acceptance that the worms are well clear of the can and aren't going back in.

And even though we have (I believe) a significantly more competitive market over here, there is still the situation that all the operators offer a similar  or even identical service regarding technical things like this - so the user has no "free market power" to move to an operator that does offer a better service. Until one operator breaks ranks, then as a group they hold ALL the power regarding technical operations - the user has one simple choice, take it or leave it. And as things stand, there doesn't seem to be any incentive for any operator to break ranks.

Simon

---

From: Yucel Guven <[email-masked]>
Date: Thu, 21 Jan 2021 15:45:17 +0300

It can not be the provider's business to put connection restrictions
AFTER subscribers paid for X GB connection. Subscribers share it or
not, it's their choice.
This situation also sheds some light on why cellular providers do not
like/want 'tethering'.

If in the future, cellular providers restricts tethering/sharing/etc.,
then I think 'portion' of responsibility will also be on shoulders of
RFC writers
since many parts of the operating software is written with respect to RFCs,
and this is NOT a BUSINESS but rather it's a technical communication
protocol subject.

Regards,
Yucel

---

From: Simon Hobson <[email-masked]>
Date: Thu, 21 Jan 2021 18:00:05 +0000

> AFTER subscribers paid for X GB connection. Subscribers share it or

You'd think so, but it seems that the cellular industry (at least in some parts) still disagrees.

> This situation also sheds some light on why cellular providers do not

Historically I could see a valid argument for that. When you consider how phones used to be limited in function, and inherently limited in how much data they could consume, being able to tether a "real" computer to it could dramatically alter the data usage proposition. And that change has the scope to dramatically alter the costs to the operator (both in terms of upstream bandwidth, and in terms of network infrastructure) without changing the price the customer pays.
But these days, most phones can stream media as well as (or even better than !) a computer that might be tethered to it - so the argument collapses.

An anecdote for you ...

Going back to the 90s and 00s, and even into the 10s, at least here in the UK it was fairly common to hook up PSTN-mobile gateways of some sort (generically called Primicells as a common device from Nokia was the Premicell) to the company PBX. This has been the case at my previous 2 jobs. At my last job, we had one of these, used only for low volumes of traffic between the office and our 3-4 engineers. We had to disconnect it one time as we got a call from our mobile provider that basically said "using one of those is not allowed, disconnect it or we terminate all your phones". Given our usage patterns, I don't think it did as many call minutes as lots of people would do with their real phones !

But at the time, the mobile industry was used to extracting high termination charges for incoming calls from the PSTN. So allowing PBX-mobile calls to shift from being PSTN-mobile to mobile-mobile (using "free" inclusive minutes) meant that they lost a slice of revenue from each call. And "because they can", it was common to find such usage prohibited in the contract small print.

Going back to my previous job to that, we ended up stopping using the gateways - at one point we had two on different networks. It just got too much trouble playing whack-a-mole with the routing. Routing whole prefixes for a network through a device on that network was not a problem - but back then, if someone ported their number* then the network charged inter-network rates which were as high as, or even higher, than PSTN calls to the target network. The networks were working on the group of friends problem - if all your friends are on carrier A, and it costs a fortune to call them unless you are on carrier A, then you will also go with carrier A. As a result, all the carriers (we had 4 in the UK at the time) made sure that it was expensive not to be on the same one as your friends. Every time we got the bill, I'd have to put exception routing in for a bunch of new numbers that had been ported and it got unmanageable.

* I don't know whether you ever sorted this out in the USA, but here in the UK the carriers eventually gave in to pressure and porting was allowed. You could move to network B but keep your number on network A. The call would initially be routed to network A, who would then re-present it to network B - which means another set of charges behind the scenes.
AFAIK that's still the case here in the UK - though there has long been talk of having a network where any network would be able to determine (down to single number level) which network any call needed to be presented to, and I haven't kept up with how that went on.

> and this is NOT a BUSINESS but rather it's a technical communication

I'm not sure there much that can be done about it by the IETF.
If the IETF writes a standard (e.g. thou shalt provide a /56 to the mobile device) that 100% of the cellular industry disagrees with - then the response from the industry will be to ignore it. Since, as previously mentioned, customers are unable to vote with their feet/wallets (even if they realised that it would be a good thing to do), then it would change nothing.

Simon

---

From: Yucel Guven <[email-masked]>
Date: Thu, 21 Jan 2021 23:54:13 +0300

For mobile connections, we pay for the "amount" of data (in units of
bytes) that we consume either in 3 seconds or in 30 days.
It's not our problem to think about provider's network infrastructure
in the past or in the future.
Subscribers pay for the service in this free market economy as mentioned,
and subscribers should be able to decide what to do with paid mobile connection,
either with one interface or with multiple interfaces (usb, wifi,
etc...), either with one /64 or with /xy prefix.
(Better not to diverge from the title of thread.)

Regards,
Yucel

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 22 Jan 2021 13:19:06 +0100

> interface for an internal virtual machine) - do you still think one /64

If that's the case then a phone should send a DHCPv6-PD request and try 
to get a larger prefix delegated.

What I've see mobile phone vendors trying to pull is some sort of 
proxying that IPv6 prefix down to wifi interface and "share" it with 
wifi users connected to mobile AP. Not entirely how I would do it, but 
they rather chose this option other than sending an DHCPv6-PD request to 
get something larger than /64.

Cheers, Jan

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Jan 2021 15:11:43 +0100

Le 22/01/2021 à 13:19, Jan Zorz - Go6 a écrit :
>> Le 19/01/2021 à 18:21, Jan Zorz - Go6 a écrit : [...]
>>> I would say that for single phone - /64 is enough as that's a 
>>> single host and I would not bother suggesting regulators to 
>>> change that.
>> 
>> A single phone with a single interface concerned about IPv6 maybe 
>> one /64 is enough.
>> 
>> But a single phone with multiple interfaces concerned about IPv6 
>> (e.g. its cellular interface, its WiFi interface in AP mode and a 
>> virtual interface for an internal virtual machine) - do you still 
>> think one /64 is enough?
> 
> If that's the case then a phone should send a DHCPv6-PD request and 
> try to get a larger prefix delegated.

When the ARM part of the smartphone sends the DHCPv6-PD request, the
baseband modem part of the smartphone blocks it (drop).

Alex

> wifi users connected to mobile AP. Not entirely how I would do it, 
> but they rather chose this option other than sending an DHCPv6-PD 
> request to get something larger than /64.
> 
> Cheers, Jan
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Jan 2021 18:20:35 +0100

> request to get something larger than /64.

Yes.

But mobile phone vendors are not the only ones who connect to 5G
networks.  There are lots of other non mobile phone vendors who sell
devices to connect to 5G networks.  Some of these are makers of IoT
routers.  These IoT routers do not implement that kind of sharing that
mobile phone vendors do.  (in linux-android speech it is called 'clatd'
which are absent from other IoT oriented linuces which are not android).

'clatd' is tightly bound to the concept of offering IPv4 pipes when the
cellular access network is IPv6, because most apps for web browsing
absolutely still need to work unmodified on IPv4 even if the network is
migrated to IPv6.

However, contrary to smartphones, many IoT routers dont need to browse
the IPv4 web.  Some of them are pure IPv6 on pure IPv6 networks
accessing pure IPv6 services.  They dont want to be constrained by the
64 limit just because IPv4 apps on smartphones absolutely need to
convert IPv6-IPv4.

Another inconvenient of clatd is that while it does '64share' it does
not work for multiple subnets that might be behind an IoT router - it
works only for one subnet, for one particular 'tethering' app: extend
the cellular interface down into the WiFi interface.  This 64share does
not allow to extend the cellular to the WiFi and to the USB interface.

The IP networks deployed in vehicles need the IoT routers and not the
smartphones.  Smartphones are ephemerically plugged in and out of the
dashboard, but they do not represent the permanent connection the car
computers need.

These are few points that make it need for more than a /64 from the
cellular network.

Alex

PS: DHCPv6-PD is in a Stds Track RFC; '64share' is defined in an
INFORMATIONAL RFC, and 'IoT Router' is defined in an invidiually
submitted Internet Draft in v6ops WG; there are other individual I-Ds
that might solve the problem, e.g. ND-PD, ariable SLAAC,... others.  But
the interest now, I think, is not necessarily to push particular
solutions (DHCPv6-PD, etc), but to make a request for address space.
This is how I understand the earlier discussions in this email list on
this topic: whenver I complain about the 64 limit, most people tell that
there is enough space available and one should ask to the operator.