Re: [IPv6] Variable IIDs

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 08 December 2023 14:10 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 82018C23961F for <ipv6@ietfa.amsl.com>; Fri, 8 Dec 2023 06:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.337
X-Spam-Level:
X-Spam-Status: No, score=-4.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fyl6CMe3a3AE for <ipv6@ietfa.amsl.com>; Fri, 8 Dec 2023 06:10:13 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (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 7D13CC09C23F for <ipv6@ietf.org>; Fri, 8 Dec 2023 06:10:13 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B8EABYG037532 for <ipv6@ietf.org>; Fri, 8 Dec 2023 15:10:11 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7867C203768 for <ipv6@ietf.org>; Fri, 8 Dec 2023 15:10:11 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 729A72033F4 for <ipv6@ietf.org>; Fri, 8 Dec 2023 15:10:11 +0100 (CET)
Received: from [10.8.32.70] (is156570.intra.cea.fr [10.8.32.70]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B8EABI0004161 for <ipv6@ietf.org>; Fri, 8 Dec 2023 15:10:11 +0100
Message-ID: <02bfb208-82ff-435c-aa12-db3e29284741@gmail.com>
Date: Fri, 08 Dec 2023 15:10:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr
To: ipv6@ietf.org
References: <d935987f-7550-855a-c57f-7f8c2fc6e5cf@gmail.com> <CAN-Dau1Q=ZkLUbi9s44QtGk+mC=ZoZZtqrWJ8Vez0yKwZvkwaw@mail.gmail.com> <CAO42Z2whKEMin8cF3AJuq0oL7-qM-+veMCWxoi5erd0KGEiR4w@mail.gmail.com> <F7C72E30-38CC-4180-B20C-2CE6C279C881@tiesel.net> <CAKD1Yr3TVfMBTmDvn_2yMhKpZggKieMCP1yPFGwj9YCeod+46g@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <CAKD1Yr3TVfMBTmDvn_2yMhKpZggKieMCP1yPFGwj9YCeod+46g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-CEA-Virus: SOPHOS_SAVI_ERROR_OLD_VIRUS_DATA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3BKGY3BHO9PCfiCFxnXrWo_WUmc>
Subject: Re: [IPv6] Variable IIDs
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 08 Dec 2023 14:10:17 -0000

Le 07/11/2023 à 10:23, Lorenzo Colitti a écrit :
> On Tue, Nov 7, 2023 at 10:05 AM Philipp S. Tiesel <philipp@tiesel.net> 
> wrote:
>
>     If we just focus on these two arguments, we could easily settle
>     with a /80 for a physical host and stop the race to the bottom
>     right there.
>
>     Given the above, why should we still standardise smaller IIDs?
>     Because we want to be able to use parts of your /64 or /80 on a
>     virtual network inside your physical host and have SLAAC work
>     there. Here, we are not dealing with abandoned IoT-devices we need
>     to support, but stuff to come once we got sufficient IP address
>     space to physical hosts.
>
>
> Unfortunately, I think Mark is right about the "hand out the smallest 
> unit" mindset - not all networks have this mindset, but some do, and 
> unfortunately, software evolution is generally driven by the lowest 
> common denominator - it's easier to build and maintain just one thing 
> that always works instead of one thing that always works PLUS other 
> things that might work some of the time.
>
> Given the "hand out the smallest unit" mindset, I see no way to 
> achieve variable subnetting. As soon as hosts support getting a /96 or 
> a /104 or a /120, then that is what they will get from the network, 
> and they will be unable to subnet it further.
>
> As Steve Deering observed, when they designed IPv6 they considered 
> variable length addressing, but they rejected it because they observed 
> that all protocols with variable address sizes in practice ended up 
> always using the maximum size. I think the video is here 
> <https://www.youtube.com/watch?v=fvc0tHimVbo>.
>
> Like I said - if we want to lengthen the SLAAC prefix size, we can 
> only do it once, and there must be ONE value.

Along the lines of this discussion, I wanted to give some update about 
my  humble interest in the topic.

I am interested in connected mobile entities of many kinds, such as cars 
and others.  They feature many subnets inside a so-called 'moving 
network'.  Mobile IPv6 NEMO, VPNs and other tunnel-based technos were 
experimented.

Why tunnel?, because cellular networks only give a /64 to a UE and that 
is not sufficient for a car.  Home ISPs give /56s but they are not mobile.

Hence, maybe a Variable IID, or a Variable SLAAC, could be needed.

A satcom operator, on another hand, can give a /56 to a mobile entity, 
such as to a car. (it's the case with starlink as it appears almost 100% 
sure to feature a DHCPv6-PD Server in their core).  There are very many 
constellation plans announced this year.

In that sense, maybe the technology used by starlink to give that /56 to 
a car (DHCPv6-PD, etc) is sufficient.  It could be advantageously 
considered by cellular network operators too. Maybe in their future 
'NTN'-converged technos. (non-terrestrial nets).  Maybe in the future 
NTN 6G or 7G UEs there will be DHCPv6 Clients.  Or maybe not, I dont 
know.  But that's ok, because there will be starlink and satcom anyways.

(a cellular network operator, such as Orange, also featured DHCPv6-PD 
/56 to UE, as an experiment, re-used for cellular from their home ISP 
feature; but that did not get into exploitation, whereas starlink /56 to 
UE is there).

Alex

>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------