Code change:
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> <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.

Related discussion:
text: 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.