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

[David Farmer <[e-mail]>]

First, let’s take a step back, I observed the abstract says the following;

This document defines a "P" flag in the Prefix Information Option (PIO) of
IPv6 Router Advertisements (RAs). The flag is used to indicate that the
network prefers that clients do not use the prefix provided in the PIO for
SLAAC but request a prefix via DHCPv6 PD instead, and use that delegated
prefix to form addresses.


In my opinion, this says the document intends to define a general purpose
“P” Flag and not one specifically limited to
draft-ietf-v6ops-dhcp-pd-per-device. If the intention is to limit this flag
to only the specific use case of forming an address using SLAAC with the
delegated prefix, then it should probably say that. I suggest changing the
abstract as follows.

This document defines a "P" flag in the Prefix Information Option (PIO) of
IPv6 Router Advertisements (RAs). The flag indicates that the network
prefers that clients do not use the prefix provided in the PIO for SLAAC
but instead request a prefix via DHCPv6 PD and use that delegated prefix to
form addresses using SLAAC.


Then, at least this restriction you are saying is intended and clearly
stated.

Next, unless I completely misunderstand the meaning of the words “server”
and “client”, defining one necessarily defines or at least bounds the
definition of the other. A server without a reciprocal client is almost
useless, and vice versa. So even if draft-ietf-v6ops-dhcp-pd-per-device
talks exclusively about the network, which I don’t believe it does, it
nevertheless clearly implies things about a client or a host/device on the
network it is defining.

Finally, while the consensus around draft-ietf-v6ops-dhcp-pd-per-device is
specific about using SLAAC to form addresses from the delegated prefix,
allowing extensions to a network. Effectively requiring a /64 or shorter
prefix, at least at this time. Nevertheless, nothing in it excludes another
future specification for using DHCP-PD with longer prefixes than allowed by
SLAAC for the device or host to form addresses for only itself and disallow
extensions of the network beyond an individual device.

So, in conclusion, if the “P” flag is indeed generic, as the abstract seems
to state, then it should not exclude the later use case above using
delegated prefixes longer than allowed by SLAAC. Otherwise, the abstract
should include an explicit restriction to using SLAAC with the delegated
prefix, as I suggest above.

Thanks

On Thu, Jun 6, 2024 at 22:34 Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> On Wed, Jun 5, 2024 at 9:42 PM David Farmer <farmer=
> [e-mail]> wrote:
>
>> The DHCP-PD client requests a prefix length using the prefix hint.
>> The DHCP-PD Server SHOULD provide a prefix of the length requested in the
>> hint or shorter. But even if it can't, the DHCP-PD server is still expected
>> to make an offer if it can, regardless of whether it is longer than the
>> prefix requested. It is then up to the DHCP-PD Client to decide whether it
>> can use the offered prefix or not.
>>
>
> Technically, I don't think it's true that the PD server is expected to
> make an offer. If I'm reading RFC 8168 section 3,2 correctly, the server is
> indeed expected to send an ADVERTISE, but it's allowed to advertise that it
> cannot assign any prefixes of the desired length.
>
>
>> The length of the prefix that the network should provide was debated to
>>> great lengths during the discussion of the dhcp-pd-per-device draft. In the
>>> end, the rough consensus was that the network "MUST provide a prefix short
>>> enough for the client to extend the network to at least one interface, and
>>> allow nodes on that interface to obtain addresses via SLAAC".
>>>
>>
>> Yes, it was there was consensus for draft-ietf-v6ops-dhcp-pd-per-device
>> to use SLAAC. But that doesn't preclude future use cases that use PD
>> without requiring SLAAC for address assignment, and the P-Flag should be a
>> general tool, not necessarily one specific
>> to draft-ietf-v6ops-dhcp-pd-per-device use case. So, I think the answer is
>> to qualify the statements about SLAAC to "hosts
>> implementing draft-ietf-v6ops-dhcp-pd-per-device." Leaving things open for
>> other future use cases of the P-Flag.
>>
>
> Hmm... but draft-ietf-v6ops-dhcp-pd-per-device is very specific that it
> applies to the network, and host behaviour is out of scope. So I don't
> think we can say "hosts implementing draft-ietf-v6ops-dhcp-pd-per-device".
>
>
>> NEW:
>> "If the host does not obtain any suitable prefixes via DHCPv6 PD, in the
>> case of draft-ietf-v6ops-dhcp-pd-per-device, that is 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.“
>>
>
> I think the problem with this text is: how does the host know if the
> network is implementing pd-per-device? The intention of this draft was that
> the P bit would signal that. There needs to be a way for the network to
> signal pd-per device, because pd-per-device requires a SLAAC-sized prefix,
> and many networks do not have enough address space to provide one such
> prefix to every client. So there needs to be a flag to tell the client
> whether it should ask for a prefix or not. This ensures that clients that
> cannot function without a prefix (e.g., a RFC7084 home router) can always
> ask for a prefix, and get it, whereas clients that prefer PD but are OK to
> just use SLAAC will not ask for a prefix and tie up address space.
>
> It sounds like you're proposing something different - specifically, that
> the P flag should mean "clients can ask for a prefix on this network, but
> they will only find out whether pd-per-device is supported depending on
> whether they get a SLAAC-sized prefix or not". I think the problem with
> this is that it's slower and more complex. Clients would get a prefix, but
> if they needed a SLAAC-sized prefix and got something longer in the
> ADVERTISE, they'd have to stop the client and fall back to SLAAC. Or they
> would have to do as suggested in RFC 8168 section 3.3 and just keep asking,
> causing lots of useless multicast traffic. That's not a good outcome. We
> should define the P flag to make pd-per-device work as well as possible,
> because that's it's an IETF-specified deployment model. We shouldn't make
> that model work less well to support other potential deployment models that
> we haven't defined.
>
> Another question is - if the server does not need to provide a prefix
> suitable for SLAAC, then, why is the P flag even useful? The primary reason
> for the P bit is to ensure that clients can safely ask for a prefix without
> causing the network to run out of space. But if the network is going to
> assign longer prefixes - even something as short as a /80 - then the space
> argument doesn't apply. Clients that are OK with using a /80 can simply ask
> for that without worrying about causing the network to run out of space. It
> doesn't seem useful to add a flag to signal this.
>
> Cheers,
> Lorenzo
>


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