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

[Alexandre Petrescu <[e-mail]>]

The local telecommunicaitons regulator ARCEP just published an article I
authored saying in a footnote on page 51:

> Ideally, an operator would offer a prefix shorter than /64 to a car’s
> gateway, e.g. one that is /56 long. This would allow the gateway to
> form /64 sub-prefixes to be used in the car’s sub-networks with the
> SLAAC protocol.

That page 51 is visible on these IPv6 friendly URLs of French and
English reports:

https://www.arcep.fr/uploads/tx_gspublication/rapport-etat-internet-edition-2021-juil2021.pdf

https://en.arcep.fr/uploads/tx_gspublication/report-state-internet-2021-edition-july2021.pdf

Alex


Le 15/06/2021 à 17:52, Alexandre Petrescu a écrit :
> 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 
>> --------------------------------------------------------------------
>
>>
>> 
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------