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

[Ted Lemon <[e-mail]>]

When we are thinking about heuristics, we can only ever do our best: there is no perfect heuristic. If it were a perfect heuristic, it would be an algorithm. So our analysis should be toward what causes the least harm.

So there are two cases where the P bit is set: one where SLAAC is allowed, and one where it is not. In the first case, we're fine. In the second case, this could be either because of a bad home router, or a misconfigured or deliberately configured managed network.

Consider the bad home router case. In this case, the home router is in violation of RFC7084:

	WAA-1:   The IPv6 CE router MUST support Stateless Address
        	       Autoconfiguration (SLAAC) [RFC4862].

So I think we don't need to address this case, because non-conformant home routers should be out of scope. E.g., a home router MUST NOT automatically turn on RA Guard, but of course it could, and if it does, that will also break SNAC. If that should happen, there's nothing we can do about it. Same situation applies here.

It's of course possible that the operator of a home router might turn off SLAAC, but in that case you have a managed network. Which brings us to the second case—a misconfigured or deliberately configured managed network.

In this case, if it's misconfigured, presumably someone will notice and fix the issue. So it's not our job to fix it in this case.

If it's deliberately configured this way, then I think it makes sense to follow the operator's intention. Our goal here is not to make every network SNAC-capable, but rather to make sure that when SNAC should work, it does work. In this case, the operator has clearly decided that SNAC shouldn't work for hosts that don't do IA_PA (or possibly IA_NA). I think it's fine for us to not solve this problem.


> On 21 Nov 2025, at 11:11, Esko Dijk <[e-mail]> wrote:
> 
> 
> Currently, for determination of suitable on-link prefix, only the PIO fields and flags are taken into account I think.
> Below I've created a table of all the options including the L / A / P flags in PIO.  The M flag (from the RA mesage) is mentioned below for explanation, but not used in the decision.
> The prefix length in the PIO is assumed to be /64 i.e. valid.
> 
> No RA seen  : no IPv6 router on link -> send PIO
> L=0,A=?,P=? : prefix is not on-link -> send PIO
> L=1,A=0,P=0 : addr conf is either manual (M=0), or misconfiguration, or it is DHCPv6 IA_NA (M=1) -> send PIO
> L=1,A=0,P=1 : addr conf is strictly DHCPv6-PD, legacy IPv6 nodes explicitly excluded(?) -> do not send PIO?
> L=1,A=1,P=0 : SLAAC available -> do not send PIO
> L=1,A=1,P=1 : SLAAC and DHCPv6-PD available -> do not send PIO
> 
> 
> So the discussion case was L=1,A=0,P=1 which seems to hint at a managed network where the operator explicitly wants to block legacy (SLAAC-only) IPv6 nodes from obtaining an address.
> Otherwise the operator would have set L=1,A=1,P=1 . This is fine for the newer devices that understand P=1 : they will know that P=1 implies they need to ignore the A flag per RFC 9762.
> And legacy devices can use SLAAC due to the A=1 and will ignore the P flag always.
> 
> Another possibility is indeed a misconfiguration where SLAAC-only devices are accidentally barred from configuring an address.
> But how to distinguish misconfiguration in small-office cases from the properly managed network case? Not sure if we can.
> 
> Esko
> 
> 
> On 20-11-2025 23:54, Michael Richardson wrote:
>> Ted Lemon <[e-mail]> <mailto:[e-mail]> wrote:
>>     > On 20 Nov 2025, at 16:46, Michael Richardson <[e-mail]> <mailto:[e-mail]> wrote:
>>     >> Maybe 5.1.1 list of flags should consider A=0,P=?,M=0 as unsuitable.
>> 
>>     > That is indeed the question we are trying to answer. I think the
>>     > scenario where we'd see this is not a home router but a managed
>>     > network.
>> 
>> Thanks for confirming my understanding!
>> It seems like a weird corner case, but I can see it happening in some poorly
>> (ISP) managed small-office.
>> Yes, with residential IoT stuff.
>> Think shoe store or hairdresser.
>> 
>> --
>> Michael Richardson <[e-mail]> <mailto:[e-mail]>   . o O ( IPv6 IøT consulting )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>> 
>> 
>> 
>> 
> 
> -- 
> IoTconsultancy.nl | Email/Teams: [e-mail] <mailto:[e-mail]> | [phone]
>