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

[Ole Troan <[e-mail]>]

>>> 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 signals “if you can acquire addresses via DHCP please do so instead of doing SLAAC for this prefix”.
Why is that not independent of _how_ that prefix is used?

The pd-to-host document already describes the operational requirements for that particular use case, so I don’t see why the pio-pflag would need to repeat that.

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

One “could" implement it that way. I.e, the PD client, passes a part of the prefix to a local RA process that sends an RA on an internal interface, where the normal host code uses it for SLAAC. Seems like a long way around, instead of just assigning an address to the interface directly.


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

General solution in that something can extend the network with more than a single IPv6 link.
In your proposed model you cannot, and are required to share the IPv6 link between internal interfaces and external ones.
E.g. via L2 bridging (a technology made popular in the 80s. :-D).

Cheers,
Ole