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

[Jen Linkova <[e-mail]>]

On Tue, Jun 11, 2024 at 6:29 PM Ole Troan <[e-mail]> wrote:
> > 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.
>
> On the other thread I saw quite a lot of support for not having that restriction.

I'd not call it a restriction. If the network supports PD, and the
client needs /120 - why does the network need to signal it?
The client can just ask for a prefix and get it.
It's completely different for SLAAC-suitable prefixes, hence this document.

> The P-flag means, “don’t autoconfigure an address using this PIO if you can get addresses via PD instead”.
> And for that use case, SLAAC is not used.

It can be, if the host uses the prefix to form SLAAC addresses.
Anyway, I believe we have had this discussion when
draft-ietf-v6ops-dhcp-pd-per-device was discussed.

> SLAAC could be used for network extensions. But only in very limited topologies, so cannot be an general solution.

If by 'a general solution' you mean 'smth that every host MUST use' -
then it cannot be indeed. If by 'a general solution' we mean 'smth
that every host can use' - then why not?

If we want to signal a general availability of a PD with an arbitrary
prefix length etc - maybe we need an RA option (or a PVD one) which
would be saying 'this network can give you /X via PD' (multihoming
would still be tricky though).

-- 
Cheers, Jen Linkova