Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Alexandre Petrescu <> Thu, 31 October 2019 10:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B1A311200B3 for <>; Thu, 31 Oct 2019 03:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.63
X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K7fmHSrdYIJy for <>; Thu, 31 Oct 2019 03:02:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8A3912004E for <>; Thu, 31 Oct 2019 03:02:46 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VA2csv047661; Thu, 31 Oct 2019 11:02:38 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 6837F201451; Thu, 31 Oct 2019 11:02:38 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 52D87202633; Thu, 31 Oct 2019 11:02:38 +0100 (CET)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VA2X8N032018; Thu, 31 Oct 2019 11:02:34 +0100
To: Owen DeLong <>
References: <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 31 Oct 2019 11:02:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------03038B2FFC2D569502CB2DC5"
Content-Language: fr
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2019 10:02:51 -0000

Le 31/10/2019 à 04:05, Owen DeLong a écrit :
> 8 /64s is a /61.

Right, I guess 8 /64s is a /61 because 2^3 is 8, and 3+61 is 64.

Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an annotated 
figure of GUI below).  They are 8 /64s.  I dont see ce18, neither ce19 
in the GUI.  Might it be that my neighbor gets ce18 and ce19, but it 
would mean s/he cant get more than 2 /64s.  Might it be that free hides 
ce18 and ce19 for something else inside my home that they dont tell me 
what.  Might it be they expect me to ask them for more addresses later.

Whether I get a /61 or a /60 at home is still a valid question for me.

> 16 /64s is a /60.
> 256 /64s is a /56.
> You should be getting 65,536 /64s (a /48) and if I were you, I would complain to any ISP that gave me less.I

I keep the /48 request in mind for my next interaction with their 
service, because I have many things to ask.

I suppose they will ask me, in return, if I already spent the 2^61 
addresses they already gave me.



For information, see below an annotated copy of the GUI listing the form 
of the 8 prefixes I see in GUI on CPE.

One may notice things to complain about: the use of ff:fe in the LL, the 
way they call it 'Prefix Delegation' without using DHCPv6-PD and the 
optional firewall IPv6 activation (off by default - they dream :-)

You may understand why I say I have many things to ask them.

> Owen
>> On Oct 30, 2019, at 9:29 AM, Alexandre Petrescu <> wrote:
>> Le 30/10/2019 à 15:27, Radu-Adrian Feurdean a écrit :
>>> On Thu, Oct 24, 2019, at 11:20, Alexandre Petrescu wrote:
>>>> In particular, the home networks scenario is very appropriate.
>>>> First, I must say that the home network that I use uses a fixed
>>>> /56 allocated by my ISP.  In this, the prefix never changes, and it
>>>> is not obtained by DHCPv6-PD - it is guaranteed by contract signed
>>>> by hand. Such a case could be mentioned, as not being a problem described in this draft.
>>> If you are talking about residential service (not business/enterprise-class), I would like to know who your service provider is.
>> (my correction: I am not at all good at bit fiddling, sorry.  What I get
>> at home is a /60, I think, not a /56.  Because the CPE GUI proposes me
>> to split it into 8 /64s).
>> YEs, it is at home, probably you mean it is residential.  The payment is
>> a flat 35eur/month.  No special QoS commitments from them, other than a
>> 'noise level' of 55dbm due to the length of the line.
>> The service provider is Free. ('Free' is its name; it was the first
>> callable at gratuitous phone numbers when all others requested a payment
>> in exchange; later they were the first to offer flat rates when the
>> others were per-connection time; because of that it called itself so).
>>>> I must say that this kind of software (request a prefix with DHCPv6-PD, form sub-prefixes, and put them in RAs on the other interfaces) does not exist as open source or some other available package.
>>> Dibbler-client does that by default. Once the delegated prefix (shorter than /64) is obtained, a /64 from that prefix is assigned to
>>> each interface. With proper radvd.conf configuration (prefix ::/64),
>>> RAs will be sent for those prefixes.
>> I did not know.  The difficulty I talked about is to maintain what's in
>> that radvd.conf in sync with what is dhcpd.conf.  Maybe some software
>> packages already do it.
>> Also, because you talk about deriving /64s out of /56: I am not sure
>> there is a standard way to do it.  Maybe dibbler does it, but I doubt it
>> is the best way.
>>> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do this in some form or another. Some do this automatically (take prefixes and assign them to interfaces), other need manual configuration (n-th prefix go to interface ZZZ).
>> It's good to know.
>> But again, I doubt these CPEs derive prefixes in the manner that _I_
>> want it.
>> For example, I want the /60 to be derived into one /64 and a single
>> other set of /64s.  I dont want the /60 to be derived into 8 /64s.
>> I do that to help aggregation and speed up the forwarding process.
>> Other times I might want to derive that /60 differently.
>> I dont think there is a standard way to do it.
>>>> Because of that, I am surprised that you call it 'the most common deployment scenario'.  Is this a scenario that is _expected_ to be
>>>> 'common'?
>>> "Expected enough" to warrant a device to be disqualified as "CPE that
>>> supports IPv6" if it doesn't work this way. In an ISP environment.
>> Well.
>> A CPE that supports IPv6 should run DHCPv6.  A CLient and a Server?
>> Both?  Just one?
>> How does CPE propagate the prefixes learned with its CLient to its Server?
>>>> I would like to request addition of two other scenarios:
>>>> - an IoT scenario, in which an IoR Router connects several sensors
>>>> to the Internet.  For example, an IoT Router is deployed in a box
>>>> at a traffic lights.  The IoT device is the Traffic Lights Controller connected on Ethernet to the IoT Router.  The IoT Router
>>>> is connected on 4G.
>>>> - a vehicular networks scenario: the On-Board Unit is deployed in a
>>>> car. This OBU has a 4G interface and an Ethernet interface. There
>>>> are several computers in the car that need IPv6 addresses.
>>> Like : you have a mobile phone on a network doing IPv6+NAT64,
>> My CPE is not doing NAT64, I think.
>> I dont want NAT64.
>>> you pout it in tethering/mobile-hotspot mode, and connect several other devices (usually laptops) to that hotspot - they all get IPv6 addresses (in the same single /64 that the phone obtained via SLAAC or something else). It is clear that getting a /56 (even a /60 or /62
>>> would do it) via DHCPv6-PD would be a nicer solution, but when your
>>> mobile device runs android....
>> Well.  Android is good in many places and for many goals.
>> I agree that tethering/mobile-hotspot mode is a good solution in certain
>> circumstances, like sharing one's smartphone connection to tablets nearby.
>> However, tethering in IPv6 ('64share' RFC) has some drawbacks: (1) it
>> does not support more than the WiFi tethered to the cellular (doesnt
>> support an additional subnet like Ethernet) and (2) the incoming
>> interface must be cellular (cant be another wifi).
>> In a car, one has a WiFi hotspot but also lots of Ethernets and CANs.
>> It's not possible to use 64share to accomodate all that.
>> Hence, there DHCPv6-PD is not just a nicer solution - it is a requirement.
>> Other than cars, even at home, one may want a DHCPv6-PD Server on the
>> CPE for similar reasons.
>> If one wants to run tethering on a device at home that has no cellular
>> connection (e.g. a WiFi<->USB, or a USB<->Ethernet device) to extend to
>> other devices then one cant use tethering ('64share'), must use DHCPv6-PD.
>> Alex
>> _______________________________________________
>> v6ops mailing list