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

[Jen Linkova <[e-mail]>]

Hi David,

On Tue, Jun 11, 2024 at 5:38 PM David Farmer
<farmer=[e-mail]> wrote:
> 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.

Yes, thank you for suggesting the text. The authors just realized that
the Intro/abstract sections are not sufficiently clear about the
purpose of the P flag. While Section 3, Rationale, does explain the
motivation, we definitely need to make it explicit that the purpose of
the P flag is to signal to hosts that the network supports the
pd-per-device model.
We'll update the text in the next revision of the draft.


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

IMHO the very important thing here is that the P flag indicates to the
client that the client can request a prefix *short enough* for SLAAC.
The goal is to prevent a client to ask for a short prefix if the
network supports PD in general but doesn't have enough space for such
clients.
Clients which need long prefixes (/120../80 whatever) can just do it
any time, I'm not sure there is any need for signalling support for an
arbitrary long prefix.

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

Yes, thank you, we'll update the text.

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



-- 
Cheers, Jen Linkova