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

Alexandre Petrescu <> Wed, 28 July 2021 16:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6A5E3A1789 for <>; Wed, 28 Jul 2021 09:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GDCfvbKeO2sJ for <>; Wed, 28 Jul 2021 09:39:35 -0700 (PDT)
Received: from ( [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 167393A177E for <>; Wed, 28 Jul 2021 09:39:34 -0700 (PDT)
Received: from [IPv6:2a01:e0a:937:bc30::c8b2:2e1d] (unknown [IPv6:2a01:e0a:937:bc30::c8b2:2e1d]) by (Postfix) with ESMTP id 8DB5D2003F2 for <>; Wed, 28 Jul 2021 18:39:27 +0200 (CEST)
Subject: Re: Informed regulator about the shorter-than-64 necessity on 3G/4G/5G
References: <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 28 Jul 2021 18:39:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jul 2021 16:39:40 -0000

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:


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 Administrative
>>> Requests: 
>>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list Administrative 
>> Requests: 
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list Administrative 
> Requests: 
> --------------------------------------------------------------------