Original text:
record the set of prefixes that have been advertised on infrastructure and the maximum valid lifetime that was advertised. On restart, the router should assume that hosts on the infrastructure <del> link have received advertisements for any such prefixes, and should immediately deprecate them, and continue to do so until the maximum valid lifetime has elapsed after restart. [WG: we could actually just not advertise the prefix, rather than deprecating it.  In this case, the host should wind up preferring some other prefix for new connections anyway, because it will have a later preferred lifetime expiry.  As long as we remember the route and resume forwarding for it, existing connections can continue until the prefix becomes invalid. Further experience with this shows that this solution doesn't work well at all.  Ideally the stub routers would all use some identifier specific to the stub network to construct the prefix advertised on the AIL.  At present Thread uses the Thread "extended PAN ID", which is a 64-bit quantity.  Perhaps something like the SSID could be used for a WiFi stub network.  I don't think there's a way to specify this generally.  But it seems as if the solution proposed here probably isn't worth doing.] </del>  5.2.2.

Reviewer comments:
Actually, the two stub routers might not be connected to the same stub network, and that should be okay. The point is to stabilize the on-link prefix on the AIL if it's provided by a stub router. If stub routers A and B are connected to the same AIL, only one will advertise an on-link prefix. If that one reboots, the other will remember that that prefix is on-link, so it will do the right thing with responses send to hosts on that prefix. The goal is to make sure that the router that rebooted also considers that prefix on-link, even though it's never seen an RA. I think this section needs a bit of work; the clarifications you've requested would be part of that, but it was useful to re-think this based on your comments as well, because I think I see how to make this work in a relatively clean way. If we are not advertising the prefix on the link, because there's a usable prefix on the link, and we get a message from the stub network for an address on the remembered prefix, there are the following possibilities that I can think of: The prefix is a DHCP prefix, meaning it's routable and doesn't belong to the stub router. In this case, the stub router could try to renew it; if that succeeds, it could assume that the prefix is valid on the AIL and forward packets to that prefix to the AIL. If that fails, it assumes the prefix is only reachable through a router, so it forwards the packet using its routing table, and hopes for the best. The prefix is a prefix generated by that stub router. In this case, if the stub router is on a different AIL, it's immaterial, since the prefix isn't routable. So the stub router can assume that that prefix is on-link and forward packets for that prefix to the link; if they reach their intended destination, great. If not, nothing is lost. The prefix is a stub-network-specific prefix. As an example, Thread uses the thread XPANID, which is a 48-bit number unique to a Thread network and its set of credentials, to generate a ULA prefix for the AIL. This means that if there are several stub routers connected to the same AIL and the same Thread network, they will all always advertise the same ULA on the AIL if there's no usable prefix there. This has a really nice benefit of increasing the stability of numbering on the wire in the presence of stub router reboots. This prefix isn't routable, so if the stub router gets connected to a different AIL, there's not much it can do about it. It's not actually clear what to do in this situation, since if there's another stub router still connected to the old AIL, we have ambiguous routing to that prefix on the stub network. In the case of Thread, we don't consider this a serious concern, since thread has similar locality to home networks: if you can't reach the home router, you probably can't reach the thread network you were connected to before either.
Not all aspects described here are fully clear yet, and there's a tension between this text and other PR text that says ULA Site Prefix is used to generate the AIL ULA link prefix. But it's best to merge the new text now and use that as a basis for further review!

Revised text:
record the set of prefixes that have been advertised on infrastructure and the maximum valid lifetime that was advertised. On restart, the router should assume that hosts on the infrastructure  <ins> link have received advertisements for any such prefixes. When possible, it is best if all stub routers serving a particular stub network use the same 64-bit prefix on the AIL.  For example, Thread stub routers use bits from the Thread Extended PAN ID to generate the ULA prefix's Global ID and Subnet ID.  The Global ID generation conforms to RFC4193 because the Extended PAN ID is generated randomly using the same mechanism that is specified in RFC 4193 for the ULA prefix bits. </ins> 5.2.2.