Code change:
stub router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. <del> 5.3. </del> <ins> A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for a SNAC router to specify this interval. 5.2.3.1. It is possible that a SNAC router might obtain a prefix from a DHCPv6 server using prefix delegation and then something about the infrastructure network attachment might change that affects the validity of that prefix for use on the stub network.  The section of I-D.ietf-dhc-rfc8415bis titled "Refreshing Configuration Information" discusses the various scenarios that can occur.  We assume that the DHCPv6 prefix delegation client being used by the SNAC router conforms to this specification. Situations that can occur include (but are not limited to): The SNAC router MUST NOT use a prefix once the DHCPv6-PD client has determined that it is no longer valid.  If the DHCPv6-PD client provides a new prefix, and the old prefix is still valid, the SNAC router SHOULD explicitly deprecate the old prefix at the same time that it first advertises the new prefix. If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to the ULA link prefix that it has allocated for use on the SNAC network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment draft-ietf-dhc-rfc8415bis and the end of the lease has been reached, then the SNAC router MUST deprecate the DHCPv6-PD-provided OSNR prefix and begin advertising the ULA link prefix. A failure to renew the DHCPv6-PD-provided OSNR prefix could be because the SNAC network has been disconnected from one AIL and moved to a different AIL.  In this situation, if the new AIL also has IPv6 service and DHCPv6-PD service, the DHCPv6 client will get a clear indication that the old prefix is no longer valid.  However, it may be that no DHCPv6-PD service is available on the new link, either because it is an IPv4-only link or because it's an IPv6-capable link that doesn't provide DHCPv6 service.  In this situation, if the SNAC network remains connected to the link and no DHCPv6 service appears, the DHCPv6-PD-provided OSNR prefix will eventually time out and be replaced.  The SNAC router SHOULD NOT attempt to replace it prior to this normal timeout process, because there is no benefit to changing the OSNR prefix on the SNAC network in such a situation, and it's possible that the SNAC router will return to the other link before the OSNR prefix expires. 5.2.4. </ins> Stub routers MUST advertise reachability to stub network OSNR prefixes on any AIL to which they are connected.  If the stub router

Related discussion:
text: … AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.