Re: [v6ops] Continuing WGLC: ietf-v6ops-dhcp-pd-per-device-03

[Ole Troan <[e-mail]>]

> On 10 Oct 2023, at 08:27, Lorenzo Colitti <[e-mail]> wrote:
> 
> On Tue, Oct 10, 2023 at 3:10 PM Ole Troan <[e-mail]> wrote:
> > This is very similar to how address pools are allocated when using DHCP to assign individual addresses (e.g., DHCPv4 or DHCPv6 IA_NA), where each link has a dedicated pool of addresses, and clients on the link obtain addresses from the pool. In this model, each link's pool can be sized according to the expected maximum of devices on a particular link, similar to how DHCPv4 pools are sized today. For example, if the network assigns a /64 to every client, then any link that is assigned an IPv4 prefix of /X (e.g., X=/18, X=/24) would require a corresponding prefix pool of size X+32 (e.g., X=/50, X=56).
> 
> I think I would like to see some operational guidance.
> 
> Isn't the text I suggested above already operational guidance? It basically says that for the pool-per-link model (which is the only one documented in the draft), the operator should assign one pool for each link and size the pools based on expected maximum usage, which is basically the same way that operators size IPv4 address pools today. Not sure what else we should say here, maybe say that the lease times need to be consistent with IPv4 lifetimes as well, to prevent prefix exhaustion?

Yes, lifetimes as well as T1/T2 timers.
It would probably be good to not say consistent with IPv4 timers, as we’d like the text to be applicable in an IPv6 only context.


>  Also, regarding the prefix pool idea. When this was last discussed in SNAC the opinions seemed to lean towards flat allocation. That’s a lot more efficient for address utilisation. The pool approach is hierarchical. At least at the first level.
> If an EN has 3 downstream links, I think the network should get a PD request with 3 IA_PD options. Assigning a /64 to each. Instead of a request of a /62 with a prefix hint. The document likely needs some guidance regarding that. Not quite sure how the text should look like.
> 
> I don't think we can easily make such a recommendation since a direct contradiction of RFC 7084 (WPD-2 says that if it supports hinting it MUST ask for a single prefix enough to address the entire router). Also, this draft is trying to avoid specifying any host behaviour as much as possible, and focus on the network side. This is because removing the text that we had about hosts resolved a lot of objections/lack of consensus, and because v6ops this isn't really a WG that is chartered to change host behaviour or define new protocols. This draft is strictly operational - it describes an operational model and what network operators need to do to support it.

If this is an operational document or not, or a protocol specification, that’s a little blurry.
You are essentially proposing a new use case for DHCPv6 PD. One that it was not intended for.
WPD-2 doesn’t quite apply. WPD-2 is about prefix delegation across administrative boundaries. Your proposal is about prefix assignment within an administrative domain.
This document should be in sync with (and probably should reference the stub router document.
At least there should be text explaining the two models. Flat and hierarchical. And that the network needs to support both.


> Once this is published I think we can get more ambitious - for example, work on the mobility problem that as Pascal points out would be a major upgrade - but I think we should get this document out first.