Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?

Ole Troan <> Thu, 26 November 2020 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 326DB3A00D9 for <>; Thu, 26 Nov 2020 10:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IvEL3cI0vIj9 for <>; Thu, 26 Nov 2020 10:32:08 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 06B9D3A00C9 for <>; Thu, 26 Nov 2020 10:32:07 -0800 (PST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id EEF7D4E11AFF; Thu, 26 Nov 2020 18:32:06 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ole Troan <>
Mime-Version: 1.0 (1.0)
Subject: Re: [v6ops] How do you solve 3GPP issue if neither operator nor handset supports PD?
Date: Thu, 26 Nov 2020 19:32:04 +0100
Message-Id: <>
References: <>
Cc:, Michael Richardson <>
In-Reply-To: <>
To: Philip Homburg <>
X-Mailer: iPhone Mail (18B92)
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: Thu, 26 Nov 2020 18:32:09 -0000

> On 26 Nov 2020, at 19:11, Philip Homburg <> wrote:
>> Doing this kind of unicast request/response is PRECISELY what DHCPv6
>> was created for.
> I agree. The question is whether it actually good at this.
> 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.

It’s 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 isn’t specified, doesn’t make it simple. 

> DHCP is separate from RA. So coordination is required between DHCP and RA
> if we want to delegate the entire prefix.
> 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. 

> So there is an opportunity to come up with a better way of doing prefix
> delegation.
> 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. 

Let’s ask the question differently. Would RS/RA be a good protocol for address assignment?