Code change:
NAME The new sections need to go in just after all the "", otherwise the XML doesn't build (order is fixed).
Question on the cases included: isn't there a case possible where network is managed and is IPv6 only DHCPv6 addressing is used (as intended by operator) - assume DHCPv6 hands out ULA addresses no RA-Guard is applied user brings stub router, plugs it in, and it advertises a ULA prefix in PIO other devices on the link start configuring a SLAAC IPv6 address and try to use this to communicate (and routing fails because the DHCP managed ULA was not used as the source, but rather the SLAAC based ULA) But maybe this is not relevant because the source address selection algorithm would always pick the correct, managed ULA due to a better prefix match with the IPv6 destination address ?
Regarding the DHCPv6-only use case, we are assuming that the network operator wants to control which devices have addresses on the local link. In this case, they MUST use RA Guard. If they do not, then there is no protection against random devices sending RAs. So this would be a misconfiguration, and hence we don't need to do anything about it.
NAME Right, I also agree we don't have to do anything about solving this "problem" other than pointing to RA guard. But still I think it's worth mentioning: it's the one identified corner case where the SNAC router has unwanted side effects. I wasn't even sure if I was correct in predicting the effects. Considering that there is I think no other IETF-specified / IETF-compliant device that, when plugged in, would instantly disrupt this network in the way that the stub router does. If this is the worst case we can find, it should actually show that our stub router is good to go.
During email discussion in 2023, there were worries that placing a SNAC stub router in a network (with its default configurations) would disturb / harm the existing network / AIL. For example due to the advertising of extra prefixes, or advertising particular (deviating?) values of bits, routes or time-durations in the RA. One proposed solution was to provide a taxonomy (e.g. an appendix) that explains which particular topologies/configurations a SNAC stub router can work, and in which ones it doesn't work, and in which ones it can cause malfunctions (if any). Some examples: stub router doesn't work in a network that has RA-guard in a network without RA guard, and where no suitable prefix is advertised on AIL, stub router can "disrupt" by advertising its ULA prefix. In this case we assume the ULA prefix is not intended by the admin. (Maybe the admin and/or network users should know better here, but anyhow it's a possibility.) Having a better overview of success/fail cases also helps reviewers of the document to judge the risk. FYI here's a pointer to one of the messages in the thread of 2023 that summarizes some cases and how it could be documented: URL
PR resolves this issue.
In -04, "'L' bit is set" is required for a suitable prefix. However section 5.1.2.3 allows sending PIO with L flag cleared, in particular cases. This leads to the issue that the generated PIO AIL prefix won't be recognized as a "suitable prefix" by other stub routers. So the requirement "'L' bit is set" must be relaxed for particular link layer technologies where L=0. Taking one step back – I just tried to summarize SNAC stub router scenario archetypes; both good and bad. Of the below it seems that only scenario 4 is now discussed as having a risk of breaking the network, correct? 1) Non-expert home user connects stub router to own unmanaged home network; it magically works and provides IPv6 stub/AIL routing – no matter whether user’s ISP offers IPv6 or not. 2) Ignorant employee brings stub router to work and plugs it into well-managed network; companies’ IT network magically protects the network from ill effects (RA guard, and/or port-based access control, … ) 3) Ignorant employee brings stub router to work and plugs it into unmanaged (IPv6) network; nothing bad happens - there’s already a PIO prefix with ‘A’ on the AIL 4) Ignorant employee brings stub router to work and plugs it into not-so-well managed DHCPv6-only network; stub router sends RA PIO; many hosts on the link now autoconfigure a ULA which somehow breaks connectivity for these existing hosts. 5) Ignorant network admin connects stub router to company network without changing the default settings; then it becomes similar to 4. This case is btw probably out of our scope to solve and could be solved by the mantra “don’t do that then”. (The stub router is only intended for case 1, but of course the stub router cannot tell apart cases 1,4,5.) +1 on clearly defining the possible breakage scenarios. E.g. some devices may not configure multiple addresses and get stuck with a ULA only? Or known issues with source address selection; IPv4 interactions, etc. in presence of ULAs. When doing this the Type A, B and C IPv6 hosts may also be considered. If we find no issues then we may also state this in the draft in an Appendix – what was considered, and why it isn’t a problem. Esko From: Lorenzo Colitti Sent: Friday, September 8, 2023 11:38 To: Ole Trøan Cc: Lorenzo Colitti ; Ted Lemon ; Juliusz Chroboczek ; Esko Dijk ; Michael Richardson ; Handa Wang ; EMAIL Subject: Re: [Snac] Should a stub router learn RA header parameters from other routers? I am not OK with a SNAC router connecting to an existing IPv6 network and breaking it. If you can elaborate on the type of breakage you are concerned about, then we can discuss it and possibly design for it. FWIW, just the fact of the hosts getting new addresses does not qualify as breakage IMO. All IPv6 hosts have multiple addresses and source address selection generally gets hosts to do the right thing.

Related discussion:
text: of DHCPv6 can't be considered "suitable"&#151;not all hosts can actually use it. <ins> Note: there can be layer two networks where neighbor discovery is not supported and therefore we cannot set the 'L' bit, but could set the 'A' bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is received in response which contains a prefix information option