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

Owen DeLong <> Thu, 31 October 2019 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3A72120180 for <>; Thu, 31 Oct 2019 07:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lju82DV2zpAr for <>; Thu, 31 Oct 2019 07:17:24 -0700 (PDT)
Received: from ( [IPv6:2620:0:930::200:2]) by (Postfix) with ESMTP id F087512018B for <>; Thu, 31 Oct 2019 07:17:23 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x9VEGvI9032491 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 07:16:58 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 x9VEGvI9032491
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; t=1572531419; bh=iDHpRlqPScRj/nBPxCqepsoS0qdnNpofzfcBOSAR12w=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=2RzzLqo135f2wfbRovX5A/TZFUY3yyUBJGkHtB8W2YmVtAfddSBYkMf3etBG6gVA/ fQANj7XAf5q6aOGOPLVNXV3fhKfS7NUy9pRAEwOa/6c0rOSwNZf8aQjYZQYyctzPP9 bCXxTQTNhzTTPbqiCtRbFJ7MvTN7Ghybq1OjoZ7w=
From: Owen DeLong <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_901C778E-71AF-47E7-9D4E-A42AD66B884F"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Thu, 31 Oct 2019 07:16:57 -0700
In-Reply-To: <>
To: Alexandre Petrescu <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Thu, 31 Oct 2019 07:16:59 -0700 (PDT)
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:17:29 -0000

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


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