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

[Ole Troan <[e-mail]>]

Hi Lorenzo,

Regarding use case. There are certainly networks today that run with empty PIOs, typically connecting CPEs in an ISP access network.
One could imagine if one knew that all devices supported PD to the host, that one would also run without an onlink prefix.
But that’s mostly speculation. Independently of that I think we need to cover this case in the document to avoid ambiguity.

Let’s see if we can enumerate the solution space for when to try PD:

I think I have come around to the arguments you gave below.

Expected PD node behaviour:

- If no PIO, always try IA_PD/IA_NA. (Or require M-flag to be set?)
- If PIO and a PIO with P-flag. Try IA_PD

So basically use the lack of PIO as an indication to try PD.
I can craft a paragraph stating that if you like.

It would also be good in the text to make it clear that the function of the P-flag is to negate the A-flag (disable SLAAC) for PD capable hosts.
With the purpose of separating the two functions. 1. when to try PD vs 2. when to not do SLAAC.

Any corner case we’ve forgotten then?

Cheers,
Ole


> On 10 Jun 2024, at 12:26, Lorenzo Colitti <[e-mail]> wrote:
> 
> On Fri, Jun 7, 2024 at 6:32 PM Ole Troan <[e-mail]> wrote:
> > 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?
> 
> In the empty PIO case it definitely would be.
> 
> How important do you think that case is? Today I'd guess that most networks that serve client devices have prefixes assigned to them. Anything using SLAAC obviously has to have a PIO. But even for DHCPv6-only networks, I think networks generally assign a shared link prefix and then assign individual /128s from the pool. Such networks can send a PIO with A=0 (and L=0 or L=1 depending on topology) and set the P bit in there. I guess if you want to do a PD-only deployment then you might not have a PIO at all, but hosts today would not understand that. CPEs would work, but CPEs don't look at the P bit anyway, they always do PD.
>  But yeah, I see your point that you would have to have both enabled for it to make sense.
> Unless we went back to only in RA and if the P-flag is set any PD willing host should not do SLAAC on any prefix in the RA…
> Perhaps we don’t have to support filtering out which prefixes a host should do SLAAC on. The RFC7084 compliant CPEs would regardlessly not handle that.
> 
> I think that has problems though. In particular, it will break if there are multiple upstreams and not all of them support prefix delegation. One example might be a small enterprise network that has a /48 but only backup through a 5G router that only provides a /64. This situation will mostly work today if the hosts support rule 5.5, as long as the enterprise router sends its RA with high priority. With the P flag as currently defined in the draft, things will also work: the enterprise router would set P=1 A=0 and the 5G router would set P=0 A=1 and things would work. But if the P flag is per-network and not per-PIO, then as soon as the enterprise router sets P=1, the hosts would no longer have any addresses from the 5G network. So a per-network P flag would not be usable in that environment.
> 
> It would also break SNAC in the case where the client gets a prefix from the network, but somehow the stub network doesn't - the stub network would send an RA with an RIO to the stub network prefix and a PIO for the on-link prefix, but if P=1 then clients wouldn't accept the stub network's prefix.
> 
> I guess we could try to fix these problems by saying that the P bit applies only "to prefixes in this RA", but what about prefixes that are announced by multiple routers, or prefixes that have since been withdrawn?
>  
> > 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.
> 
> That would be awfully confusing.
> Could of course have flags both in RA and in PIO and either one set should trigger PD… but I’m the one worried about address configuration complexity…
> 
> Duplicate flags for the same behaviour? We could do that, but it's definitely messy.
> 
> What use case are you thinking of that has no PIO? Maybe we can solve for that separately?