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

[David Farmer <[e-mail]>]

One argument for the second defintion below is if the network isn't willing
to give out a /64, why bother with the DHCPv6 PD query?

However, even if the network says it is willing to give out /64 or shorter
prefixes, you still have to make the PD request to see if the DHCPv6 server
has a prefix available for you. There is no guarantee a prefix will be
available for you or that the DHCPv6 server will not limit prefix
delegation to certain known devices, leaving unknown devices to use SLAAC.

So, if the PIO tells you PD is available, regardless of whether /64 is part
of the flag's definition, you still have to make the DHCPv6 request to
determine whether you will get a prefix suitable for your purposes. "No, I
don't have a /64 for you." Isn't that much different than, "Here is a /80
prefix you can't use." The result will be the same: Do SLAAC with the PIO
prefix.

Now, suppose we make /64 or shorter prefixes part of the flag's definition.
Then do we burn a new flag for DHCPv6 PD for prefixes longer than /64?

So, I support the first definition below.

Thanks

On Tue, Jun 11, 2024 at 7:02 AM Ole Troan <otroan=
[e-mail]> wrote:

> 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
> >
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------
>


-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================