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

Alexandre Petrescu <> Thu, 31 October 2019 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32EB81208B2 for <>; Thu, 31 Oct 2019 07:50:15 -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 f4mEXMl3r_Yu for <>; Thu, 31 Oct 2019 07:50:10 -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 F01951208D3 for <>; Thu, 31 Oct 2019 07:50:09 -0700 (PDT)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VEo4h0047495; Thu, 31 Oct 2019 15:50:04 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id BD3AD206AA0; Thu, 31 Oct 2019 15:50:04 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id AD6AB203A09; Thu, 31 Oct 2019 15:50:04 +0100 (CET)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id x9VEo3jr002636; Thu, 31 Oct 2019 15:50:03 +0100
To: Owen DeLong <>
References: <> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Thu, 31 Oct 2019 15:50:03 +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="------------7A509730D16058C4B6EE61F7"
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 14:50:19 -0000

Le 31/10/2019 à 15:16, Owen DeLong a écrit :
>> On Oct 31, 2019, at 3:02 AM, Alexandre Petrescu 
>> < <>> 
>> wrote:
>> 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.
> Well, a /60 would include not only ce10..ce17, but also ce18, ce19, 
> ce1a, ce1b, ce1c, ce1d, ce1e, and ce1f.
> I’m not familiar with your particular router or its GUI, so I can’t 
> explain why it displays what it does.
> It may simply be limited to 8 subnets that it can handle. It may be 
> something else.
> I doubt that it has anything to do with your neighbor as your neighbor 
> would get their own separate PD. They might have the opposing /61 
> (ce18..ce1f), but in that case they would still also have 8 subnets in 
> that case.

I think that's right.

I think I conclude I get a /61 at home from Free.  I will try to not 
forget this number in future conversations.

(remark, a private email also challenged me on the stability and 
contractuability of this prefix: I must say I dont know; I just know it 
did not change in several years)

>> 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.
> This is IPv4think. In the IPv6 world, the intent is to provide large 
> blocks to avoid future need to renumber and routing table pollution.

Noted the IPv4think.


> Owen
>> Alex
>> PS:
>> 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.
>> <mohkmddlfcdkakja.png>
>>> 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