[Snac] Re: Why is an AIL prefix with only the "P" flag set suitable?

[Esko Dijk <[e-mail]>]

Thanks, indeed also good to consider the network operator's / manager's 
goals here - the SNAC goals from our draft are not the only ones ;)

 > but maybe we need to explain the rationale better, since

Agree - an appendix could work for this: RFC 6762 and 6763 are good 
examples I think for this style, with useful background info on things 
that are not necessarily obvious to readers outside of the WG.


 > On a network with the 'P' bit set, I think it's reasonable to argue 
that if there is some device that only supports SLAAC, and neither IA_NA 
nor IA_PD, that that device is expected not to work on such a link, and 
so it's correct for it to fail.

Ok - then our underlying rationale seems to be along these lines:

1) when only DHCPv6 IA_NA is available and not SLAAC, we assume it's an 
unmanaged network (with possibly a legacy or weirdly configured CE 
router); and we don't want to break access for an important class of 
devices that does not use IA_NA, by letting the SNAC router offer SLAAC 
in addition.
     After all we know that the users are probably unable to reconfigure 
the network and/or diagnose the problem.
2) when the 'P' (IA_PD) flag is set and 'A' not, we assume it's a 
managed network (with newer equipment also, since 'P' is recent) and the 
managing entity explicitly doesn't want SLAAC. And we know that our 
important class of devices can do IA_PD; and we know the operator 
doesn't want legacy SLAAC-only devices to be discoverable by stub nodes.
     We assume that if the operator really would like SLAAC-only devices 
to work, they would adapt their network's settings to make it work.

Again noting that the operator's goals in case 2 are opposed to SNAC 
goals; but maybe for good reasons.
(Another factor is IPv4: if my IPv6 stub node wants to use a legacy mDNS 
service on AIL it can also use the NAT64 address of the AIL node to 
reach the service over IPv4.)


 > The current language I think accomplishes our goal, which is that all 
reasonably capable devices should be able to operate on this network.

It doesn't accomplish all the SNAC goals to the full extent. E.g. 
suppose there is no IPv4 service on AIL, and there's a legacy mDNS 
service (printing?) on AIL that a stub node needs to use, and the 
printer doesn't support IA_PD or the P flag.
Then with current SNAC the stub node can't use the printer, contrary to 
the SNAC goals.   But that fact may be aligned with the admin's goals on 
the other hand; see rationale above.   So we have to be clear what 'our 
goal' is here.

Esko


On 18-11-2025 14:45, Ted Lemon wrote:
> This is a good point. The rationale behind this language is that we 
> know that some devices will not do DHCPv6 IA_NA because they do not 
> consider a single IP address to be functional, but will do DHCPv6 
> IA_PD if it's available. There could in principle be devices that do 
> neither, and for those devices, a prefix that doesn't have 'A' set 
> isn't suitable even if 'P' is set.
>
> Given that implementing DHCPv6 IA_PD is not required, I think you can 
> definitely make the case that such a prefix shouldn't be considered 
> suitable. We don't have a standards-based reason to assert that it is 
> suitable when a prefix without 'P' or 'A' is not suitable.
>
> So the question is, what should we advise here. The current language I 
> think accomplishes our goal, which is that all reasonably capable 
> devices should be able to operate on this network.
>
> Another point is that a network with the 'P' bit set is very much a 
> managed network, so another rationale for considering the 'P' bit 
> suitable is that the operator is asserting that they want control over 
> addressing on the link, and we have evidence that they are in fact 
> providing viable addressing on the link, whereas if the 'A' bit is set 
> and the 'P' bit is not set, we can't assume that.
>
> On a network with the 'P' bit set, I think it's reasonable to argue 
> that if there is some device that only supports SLAAC, and neither 
> IA_NA nor IA_PD, that that device is expected not to work on such a 
> link, and so it's correct for it to fail.
>
> You can of course make the same argument for the 'A' bit; the 
> difference is that with the 'P' bit we actually have a complete 
> solution; without it, we do not. So I guess my conclusion from all 
> this rambling is that I think the text as written is correct, but 
> maybe we need to explain the rationale better, since it can't just be 
> that SLAAC is required if we are allowing IA_PD.
>
>> On 18 Nov 2025, at 14:16, Esko Dijk 
>> <esko.dijk=[e-mail]> wrote:
>>
>> Hi all,
>>
>> quick question here on a topic that I know we've discussed before - 
>> but I still don't understand this.
>>
>> In Section 5.1.1, we say that a prefix with the "A" flag not set and 
>> the "P" flag set is suitable. So the SNAC router doesn't have to 
>> publish its ULA prefix in a PIO to serve devices on the AIL.
>>
>> Now there can be various mDNS devices on the AIL that don't support 
>> DHCP (so no DHCP-PD client functionality). RFC 8504 lists DHCPv6 
>> based address allocation as not mandatory; and it for sure doesn't 
>> say that DHCPv6-PD would be recommended or even mandatory.
>>
>> There may also be devices that don't know about the P flag semantics.
>> If the CE router in this cases advertises an on-link prefix with only 
>> "P" flag set, then all of these services become unreachable for 
>> devices in the stub network.
>> This goes against the SNAC goals we have.  So why did we define it 
>> like this?
>>
>> regards
>> Esko
>>
>>
>> -- 
>> *IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 
>> 6 2385 8339
>> -- 
>> Snac mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339