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

[Lorenzo Colitti <[e-mail]>]

Ole,

When you say RIO you don't actually mean RIO, right? You mean in the RA
itself, or in the RFC 5175 flags option?

I guess we could do that, yes. Not sure if it would be useful though. In
particular: if the PIO flag is set but the RA flag is not set, what would
that mean? "Don't try PD, but prefer PD over SLAAC"? That seems like a
meaningless combination. I guess we could say that that combination is
invalid, and that if any PIO has the flag set, then the RA flag must be set
as well.

If that's correct, then it looks like adding a new flag would allow us to
communicate just one extra configuration: "PD is available, but don't use
it to replace SLAAC on any prefixes". Do you think this is useful?

I'm not sure it's worth adding a new flag just to address the no PIO case.
With this draft as currently written, the network can just send a PIO with
L=0, A=0, P=1. Whatever the PIO is (it could even be ::/0 or ::/128), this
will only have the effect of setting P to 1 and no other effect.

Cheers,
Lorenzo

On Fri, Jun 7, 2024 at 3:10 PM Ole Troan <[e-mail]> wrote:

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