[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

[Jen Linkova <[e-mail]>]

Hi Ole,

Thanks for suggesting the text.
A few comments:

On Tue, Jun 4, 2024 at 5:09 PM Ole Troan
<otroan=[e-mail]> wrote:
> There is a simple fix to the document to achieve that I belive.
> Simply remove the following:
>
> OLD:
> "If the host does not obtain any suitable prefixes via DHCPv6 PD that
> are suitable for SLAAC, it MAY choose to disable further processing
> of the P flag on that interface, allowing the host to fall back to
> other address assignment mechanisms, such as forming addresses via
> SLAAC (if the PIO has the A flag set to 1) and/or requesting
> individual addresses via DHCPv6.
> “
> NEW:
> —

So you are suggesting to remove 'MAY stop processing P flag'. I'm not
sure it's a good idea: this text provides optional guidance for hosts
on how to deal with DHCP-PD failures. Removing it would not prohibit
such behaviour indeed, but IMHO it's still worth mentioning it
explicitly.

> OLD:
> "If the delegated prefix is too long to be used for SLAAC, the host
> MUST ignore it. If the prefix is shorter than required for SLAAC,
> the host SHOULD accept it, allocate one or more longer prefix
> suitable for SLAAC and use the prefixes as described below.”
> --

This specific draft focuses on providing a mechanism to enable
pd-per-device. It doesn’t signal availability of DHCPv6 PD - the host
can discover that by sending a PD request and seeing if it gets an
answer. The flag is indicating that the network can provide a prefix
suitable for SLAAC w/o running out of space and the device can use
that prefix for SLAAC/sending downstream in PIOs etc.
As David has pointed out, we shall make it much more clear in the
abstract/introduction.

If a device can use a long prefix (such as /120 or /80) it can just
ask for it all the time, it doesn’t need the flag - at least *this*
flag.
Therefore if we delete this text, it would basically render the flag useless.

> OLD:
> "When a host requests a prefix via DHCPv6 PD, it MUST use the prefix
> length hint Section 18.2.4 of [RFC8415] to request a prefix that is
> short enough to form addresses via SLAAC.”
>
> NEW:
> "The host MAY indicate as a hint to the delegating
> router the size of the prefix it requires. If so, it MUST
> ask for a prefix large enough to assign one /64 for each of
> its interfaces, rounded up to the nearest nibble, and SHOULD
> be configurable to ask for more."

That makes sense but I'd suggest a few modifications:
- replace '/64' with 'a prefix suitable for SLAAC' - we shall not be
hardcoding 64 anywhere.
- maybe we shall not be saying 'each interface' - my laptop has a
number of interfaces which might not even have IPv6 enabled or there
is no need to extend the network connectivity there (e.g. loopback).
So maybe smtj like 'to assign a prefix suitable for SLAAC to each
interface the host is extending the network connectivity to'?

-- 
Cheers, Jen Linkova