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

[Alexandre Petrescu <[e-mail]>]

I want to let you know that recently I wrote a one pager with my local
telecom regulator about the 64 limit and automobiles connected to the
Internet.  This is in French and will be translated in English soon.

It basically expresses my oppinion that IPv6 for automobiles on
cellular networks is impossible because of the 64 limit.  A footnnote
suggests that, ideally, the mobile operator would give a shorter-than-64
prefix to an end user when so requested.

The paper will be published on July 7th.  I will send then a pointer URL.

Alex

>>>> 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 
>> --------------------------------------------------------------------
>
>>
>>
>> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------