Code change:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Related discussion:
text: 6. <ins> Stub Network routers must be capable of providing NAT64 themselves, and must be capable of discovering the availability of NAT64 service on the infrastructure network and providing it when it is available and usable. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. There are four possible combinations of circumstances in which to consider how to provide NAT64 service: In the first case, infrastructure-provided NAT64 is preferred, and the stub router MUST advertise this service to the stub network. In the second case, there is no way to provide connectivity to the infrastructure: we don't have IPv6 routing, because we don't have a routable prefix, we don't have NAT64 for the same reason, and we don't have IPv4, so the stub router can't do NAT64 on its own.  In this case, the stub router MUST NOT advertise NAT64 service. In the third case, despite the infrastructure providing NAT64, we can't use it, so the stub router MUST provide its own NAT64 service. In the fourth case, the stub router MUST provide its own NAT64 service. An additional complication is that there may be more than one stub router connecting the stub network to infrastructure.  In this case, it may be desirable to limit the number of stub routers providing NAT64 service, or it may be acceptable for all stub routers to provide it.  In the latter case, this should not be a problem: since each stub router is using its own ULA prefix to provide NAT64, any 5-tuple that goes through a stub router's NAT64 translator will necessarily have as its destination an IPv6 address in a particular NAT64 prefix, and that address will select the correct stub router through which to send the packet for translation. A further complication is that in some cases, some stub routers connected to the stub network may not be able to advertise an infrastructure-provided NAT64 prefix, while others may.  In this case, when the infrastructure-provided NAT64 service appears on the stub network, stub routers that are not able to advertise an infrastructure NAT64 service MUST NOT do so. To differentiate between infrastructure-provided NAT64 service and stub router-provided NAT64 service, stub routers that advertise infrastructure-provided NAT64 service MUST use a preference of medium for this service.  Stub routers advertising their own service MUST use a preference of low. In some cases a stub router may be administratively configured with a NAT64 prefix.  In this situation, the stub router MUST advertise the prefix with a preference of high. Stub routers must monitor the advertisement of other NAT64 prefixes on the stub network.  If a stub router is advertising a NAT64 prefix, and a NAT64 prefix is advertised on the stub network with a higher preference, the stub router SHOULD deprecate the prefix it is advertising. </ins> 6.1. Stub networks are defined to be IPv6-only because it would be