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

[Ole Troan <[e-mail]>]

Jen,

I think it comes down to how you view the P-flag and how that should be specified.
That is up to this working group to determine.

If the flag means:
- “If PD capable, use the delegated prefix to assign addresses instead of SLAAC for this PIO”

or if it means:
- “If PD capable, use the delegated prefix to assign addresses to yourself, instead of SLAAC for this PIO,
   but only if the size of the prefix is /64 or bigger.

Cheers,
Ole


> On 11 Jun 2024, at 10:39, Jen Linkova <[e-mail]> wrote:
> 
> 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
>