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

[Lorenzo Colitti <[e-mail]>]

On Mon, Oct 9, 2023 at 5:29 PM Ole Troan <[e-mail]> wrote:

> I think section 8 is enough and that this could be deleted.
> It’s regardlessly an operational choice.
> Alternatively say something like:
> “If SLAAC is {needed, required, used}, the server MUST provide a prefix
> short enough…”
>

Section 8 is what motivates this recommendation, but by itself, section 8
is clearly more about discussion than about recommendations. I think it's
useful to have that requirement in the server consideration sections as
well, to provide clear advice to implementors and guarantee
interoperability with the most devices and scenarios (e.g., RFC 7084
requires at least one /64).


> Garbage collection is going to be a challenge in this solution.
> Regardless of deployment you will have a fairly small number space, that
> can easily be exhausted.
>
> The only way you can deal with that is by using short lease timers, right?
> Would it be worth providing some guidelines regarding that? At least
> describe the problem?
>

Actuall, this is less of a problem than it sounds, because this model is
effectively identical to how we manage IPv4 addresses today. The draft sort
of already says this in the "prefix pool allocation" section, but perhaps
we could add an extra sentence to clarify:

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