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

[Lorenzo Colitti <[e-mail]>]

David,

I think you're missing an important point here: to make pd-per-device
deployable, we don't need a way to signal that _PD is available_. We need a
way to signal that it's _OK to ask for a /64***_. This is because:

   1. Many devices already ask for /64 (e.g., CPEs).
   2. Many networks already provide a /64 when asked (e.g., home networks).
   3. Many of these networks do not have enough space to provide a /64 to
   every client.

I think we all agree that the desired outcome on these networks is: CPEs
will continue to get /64s, and devices that can do pd-per-device do *not*
get /64s, because if they did, the network would run out of space.

Assuming we agree on this, then how do we achieve it?

   - We can't do as you suggest and define a flag that says, "PD is
   available". By that definition, these networks should set the flag: after
   all, PD is available, and devices will even get a /64 if they ask. But that
   doesn't help, because if all clients ask for a /64, the network will run
   out of space. This is a bad outcome: devices that would be OK with SLAAC,
   like phones, might get a prefix, but devices that need a /64, like CPEs,
   might not.
   - We cannot say "the networks should switch to handing out /123 or /99
   or /80", because that will break devices that need a /64.
   - We cannot say, "the network should give /64s only to devices that
   really need it", because there is no way for the network to know whether
   something is a CPE that needs a /64 or a phone that is OK with just SLAAC.

That's why the draft is written the way it is. To be sure, it's probably
not the only solution. But it's likely the simplest solution that solves
the problem and is also per-prefix (which I think we agree is necessary).

I agree that there are possible deployment models where devices get
prefixes longer than /64. But because of the above, I don't think we can
use the same flag to signal both pd-per-device and these other possible
deployment models. And if we have to pick between solving for pd-per-device
and solving for these other possible deployment models, then we should pick
pd-per-device, because that's a deployment model that is defined and
documented by the IETF. Additionally, because these other possible
deployment models do not create any address space issues, they can simply
be deployed without a flag to signal them.

Cheers,
Lorenzo

*** More precisely, "SLAAC-sized prefix". I'm just going to use "/64" for
brevity.

On Tue, Jun 11, 2024 at 10:06 PM David Farmer <farmer=
[e-mail]> wrote:

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