Re: [IPv6] Variable IIDs

Alexandre Petrescu <> Fri, 08 December 2023 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82018C23961F for <>; Fri, 8 Dec 2023 06:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.337
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fyl6CMe3a3AE for <>; Fri, 8 Dec 2023 06:10:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D13CC09C23F for <>; Fri, 8 Dec 2023 06:10:13 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B8EABYG037532 for <>; Fri, 8 Dec 2023 15:10:11 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 7867C203768 for <>; Fri, 8 Dec 2023 15:10:11 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 729A72033F4 for <>; Fri, 8 Dec 2023 15:10:11 +0100 (CET)
Received: from [] ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 3B8EABI0004161 for <>; Fri, 8 Dec 2023 15:10:11 +0100
Message-ID: <>
Date: Fri, 08 Dec 2023 15:10:11 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr
References: <> <> <> <> <>
From: Alexandre Petrescu <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [IPv6] Variable IIDs
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 
> 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 
> <>.
> 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 

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).


> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------