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

[Ole Troan <[e-mail]>]

Lorenzo,

The P-flag seems to have two distinct functions.
1) Act as a hint to the host that it should try PD
2) IF P and A is set in PIO, signal to the host that it should not do SLAAC with this prefix

Two separate flags would solve this quite nicely. One in RIO, the other in PIO.
That would also resolve the issue of how to handle an empty PIO.

Ole

> On 7 Jun 2024, at 05:34, Lorenzo Colitti <[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