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

[Jen Linkova <[e-mail]>]

On Tue, Jun 11, 2024 at 10:00 PM Ole Troan <[e-mail]> wrote:
> 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.

I assume it's what we are doing right now.

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

I'd say neither.
P-flag = 1 means that it's *safe* and desirable for a PD-capable host
to request prefixes large enough for SLAAC.
We really do not need any new flags to signal that PD is available (it
works for RFC7084 devices right now, no flags involved). We do not
need a flag to signal that a host can request /126 or /120.
The only reason the flag exists is to notify the host that the network
is OK for endpoints to request large prefixes.


> > 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
> >
>
>


--
Cheers, Jen Linkova