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

[Alexandre Petrescu <[e-mail]>]

Le 22/01/2021 à 13:19, Jan Zorz - Go6 a écrit :
> On 20/01/2021 06:56, Alexandre Petrescu wrote:
>> 
>> 
>> 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.
> 
> 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.

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.

> 
> Cheers, Jan
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------