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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 28 July 2021 16:39 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A5E3A1789 for <ipv6@ietfa.amsl.com>; Wed, 28 Jul 2021 09:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDCfvbKeO2sJ for <ipv6@ietfa.amsl.com>; Wed, 28 Jul 2021 09:39:35 -0700 (PDT)
Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167393A177E for <ipv6@ietf.org>; 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 smtp2-g21.free.fr (Postfix) with ESMTP id 8DB5D2003F2 for <ipv6@ietf.org>; Wed, 28 Jul 2021 18:39:27 +0200 (CEST)
Subject: Re: Informed regulator about the shorter-than-64 necessity on 3G/4G/5G
To: ipv6@ietf.org
References: <616b05ca-1a02-dfbd-d7f6-c79f56276fa1@gmail.com> <83351c64-0804-a4aa-c100-9b5705c9f71f@go6.si> <02e8b306-4aa9-4694-c4dd-a76285ee0771@gmail.com> <ba4c63b7-8ebf-4d1f-c0d2-98057559a352@go6.si> <8624c38c-934c-6de5-f388-611cf151546c@gmail.com> <0baa72f9-77aa-45e6-3214-2a4e223348c0@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <8c6aa12a-5e8a-de8d-e599-d5270deba872@gmail.com>
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: <0baa72f9-77aa-45e6-3214-2a4e223348c0@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/0clXryge_Pjf-LIPgolJEKEB-1Q>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=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:

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