Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD? Fri, 27 November 2020 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1BF43A1581 for <>; Fri, 27 Nov 2020 02:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hJYdcP9KamaO for <>; Fri, 27 Nov 2020 02:08:19 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 893683A0B4E for <>; Fri, 27 Nov 2020 02:08:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 8B2154E11BB3; Fri, 27 Nov 2020 10:08:17 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 483194631A26; Fri, 27 Nov 2020 11:08:15 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
In-Reply-To: <>
Date: Fri, 27 Nov 2020 11:08:14 +0100
Cc: 6man WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Philip Homburg <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Nov 2020 10:08:21 -0000

>>> DHCPv6 has a very complex model. There can be multiple relays and multiple
>>> DHCP servers. So a downstream router first has to collect offers and then
>>> select one.
>> Its hard to see what you could remove. A RA solution would likely
>> have to be implemented with some sort of database backend like
>> RADIUS. That something isnt specified, doesnt make it simple.
> Radius is an optional feature. Yes, you can use it if for example you have
> static prefixes, but you can just as well have a pool of prefixes on the
> router.
> For SLAAC, a router also needs to know what prefix to use. You could use radius
> for that, but I assume that local configuration is more likely.
>>> Worse, we have trouble tying a DHCP PD to link state.
>> The goal of PD is _not_ to tie it to link state. I would expect
>> that goal to be general regardless of wire-representation.
> I think this is the key change we should make is to avoid renumbering problems.
> The downstream router has to actively verify that the prefix is still valid.

The exact opposite you mean. It will create renumbering problems.
You seem to propose pushing all the cost of ephemeral addressing to the end-users.
I doubt that the problem is solvable in the sense of finding a way it can be deployed.
Look forward to a draft.

>>> RA has the advantage that all information can be in a single RA, ensuring
>>> consistency. We can also add mechanisms that the downstream node quickly
>>> and reliably notices flash renumbering independent of link state.
>> It might be worth noting that  RAs do not guarantee all information
>> in a single RA. It can be split across multiple messages or come
>> from different sources.
> So that is something we should work out. I.e., specify that related information
> has to go in a single message. Maybe a bit that says this a point-to-point
> link. Maybe a counter to allow the host to verify that all parts have been
> received.

Now you are designing a new configuration protocol...

>> Lets ask the question differently. Would RS/RA be a good protocol
>> for address assignment?
> RA is widely used for SLAAC. Though SLAAC has a few renumbering issues.
> On the other hand, in the mode DHCPv6 PD is commonly used, it is a bad protocol.