| Internet-Draft | Automatic Stub Networks | March 2024 |
| Lemon & Hui | Expires 5 September 2024 | [Page] |
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. This is applicable in cases such as constrained (Internet of Things) networks where there is a need to provide functional parity of service discovery and reachability between devices on the stub network and devices on an adjacent infrastructure link (for example, a home network).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 September 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes a set of practices for connecting stub networks to adjacent infrastructure networks. There are several use cases for stub networks. Motivating factors include:¶
What makes stub networks a distinct type of network is simply that a stub network never provides transit between networks to which it is connected. The term "stub" refers to the way the network is seen by the link to which it is connected: there is reachability through a stub network router to devices on the stub network from the infrastructure link, but there is no reachability through the stub network to any link beyond that one.¶
Eliminating transit routing is not intended to be seen as a virtue in itself, but rather as a simplifying assumption that makes it possible to solve a subset of the general problem of automating multi-link networks. Stub networks may be globally reachable, or may be only locally reachable. A host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected. A host on a globally reachable stub network should be able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet.¶
It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network. In the case of an IoT wireless network, there may be no way to do this, nor would it be desirable, but a stub router that uses ethernet on both the infrastructure and stub network sides could be connected this way. Nothing in this document is intended to prevent this from being done, but neither do we attempt to solve the problems that this could create.¶
The goal of this document is to describe the minimal set of changes or behaviors required to use existing IETF specifications to support the stub network use case. The result is intended to be deployable on existing networks without requiring changes to those networks.¶
The specific goal is for hosts on the stub network to be able to interoperate with hosts on the adjacent infrastructure link or links. What we mean by "interoperate" is that a host on a stub network:¶
Discoverability here means "discoverable using DNS, or DNS Service Discovery". DNS Service Discovery includes multicast DNS [RFC6762]. As an example, when one host connected to a specific WiFi network wishes to discover services on hosts connected to that same WiFi network, it can do so using multicast DNS. Similarly, when a host on some other network wishes to discover the same service, it must use DNS-based DNS Service Discovery [RFC6763]. In both cases, "discoverable using DNS" means that the host has one or more entries in the DNS that serve to make it discoverable.¶
We lump discoverability in with reachability and addressability, both of which are essentially Layer 3 issues. The reason for this is that it does us no good to automatically set up connectivity between stub network hosts and infrastructure hosts if the infrastructure hosts have no means to learn about the availability of services provided by stub network hosts. For stub network hosts that only consume cloud services this will not be an issue, but for stub networks that provide services, such as IoT devices on stub networks with incompatible media, discoverability is necessary in order for stub network connectivity to be useful.¶
Ability to acquire an IP address that can be used to communicate means that the IP address a host on the stub network acquires can be used to communicate with it by hosts not on the stub network.¶
Reachability to hosts on adjacent infrastructure links means that when a host (A) on the stub network has a datagram destined for the IP address of a host (B) on an adjacent infrastructure link, host (A) knows of a next-hop router to which it can send the datagram, so that it will ultimately reach host (B) on the infrastructure network.¶
Reachability from hosts on adjacent infrastructure links means that when host (A) on an adjacent infrastructure link has a datagram destined for the IP address of a host (B) on the stub network, a next-hop router is known by host (A) such that, when the datagram is sent to that router, it will ultimately reach host (B) on the stub network.¶
To achieve the reachability goal described above, this document assumes hosts attempting to reach destinations on the stub network maintain a routing table - Type C hosts as defined in Section 3.1 of [RFC4191]). Type A and Type B hosts are out-of-scope for this document.¶
In addition to the interoperability goals we've described above, the additional goal for stub networks is that they be able to be connected automatically, with no user intervention. The experience of connecting a stub network to an infrastructure should be as straightforward as connecting a new host to the same infrastructure network.¶
This section describes the meaning of and gives default values for various constants used in this document.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
We assume that the AIL supports Neighbor Discovery [RFC4861], and specifically that routers and on-link prefixes can be advertised using router advertisements and discovered using neighbor solicits. The stub network link may also support this, or may use some different mechanism. This section specifies how advertisement of the on-link prefix for such links is managed. In this section we will use the term "Advertising Interface" as described in Section 6.2.2 of [RFC4861].¶
Support for AILS on networks where Neighbor Discovery is not supported is out of scope for this document. Stub routers do not provide routing between AILs when connected to more than one such link.¶
In order to provide IPv6 routing to the stub network, IPv6 addressing must be available on each AIL. Ideally such addressing is already present on these links, and need not be provided. However, if it is not present, the stub router must provide it.¶
Stub routers must evaluate prefixes that are advertised on-link as to their suitability for use in communicating with devices on the stub network. If no suitable prefix is found, a stub router MUST advertise one.¶
An on-link prefix is considered suitable if it is advertised on the link in a Prefix Information option ([RFC4861], Section 4.6.2) with the following Prefix Information option header values:¶
A prefix is not considered a suitable on-link prefix if the 'L' bit is set, but the 'A' bit is not set. This indicates that node addressability is being managed using DHCPv6. Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "suitable"—not all hosts can actually use it.¶
A prefix is considered to be advertised on the link if, when a Router Solicit message ([RFC4861], Section 4.1) is sent, a Router Advertisement message is received in response which contains a prefix information option ([RFC4861], Section 4.6.2) for that prefix.¶
After an RA message containing a suitable prefix has been received, it can be assumed for some period of time thereafter that that prefix is still valid on the link. However, prefix lifetimes and router lifetimes are often quite long. In addition to knowing that a prefix has been advertised on the link in the past, and is still valid, we must therefore ensure that at least one router that has advertised this prefix is still alive to respond to router advertisements.¶
The possible states of an interface connected to an AIL are described here, along with actions required to be taken to monitor the state. The purpose of the state machine described here is to ensure that at all times, when a new host arrives on the AIL, it is able to acquire an IPv6 address on that link.¶
When the stub router interface first connects to the AIL, it MUST begin router discovery.¶
If, after router discovery has completed, no suitable on-link prefix has been found, the router moves this interface to STATE-BEGIN-ADVERTISING (Section 5.1.2.3).¶
If, during router discovery, a suitable on-link prefix is found, the router moves the interface to STATE-SUITABLE (Section 5.1.2.2).¶
In this state, the stub router MUST NOT treat this interface as an advertising interface as described in Section 6.2.2 of [RFC4861].¶
When entering this state, if the router MUST discontinue treating the interface as an Advertising Interface as described in Section 6.2.2 of [RFC4861], if it has been doing so.¶
When a new host appears on the AIL and sends an initial router solicit, if it does not receive a suitable on-link prefix, it will not be able to communicate. Consequently, the stub router MUST monitor router solicits and advertisements on the interface in order to determine whether a prefix that has been advertised on the link is still being advertised. To accomplish this we have two complementary methods: router staleness detection and neighbor unreachability detection.¶
The stub router MUST listen for router advertisements on the AIL to which the interface is attached, and record the time at which each router advertisement was received. The router MUST NOT consider any router advertisement that is older than STALE_RA_TIME to be suitable. When the last non-stale router advertisement containing a suitable prefixes on the link is marked stale, the stub router MUST move the interface to STATE-BEGIN-ADVERTISING.¶
For each suitable route, the stub router MUST monitor the state of reachability to the router(s) that advertised it as described in ([RFC4861], Section 7.3.1) using a ReachableTime value of no more than MAX_SUITABLE_REACHABLE_TIME. The reason for this is that if no router providing the on-link prefix on the AIL is reachable, then when a new host joins the network, it will have no suitable on-link prefix to use for autoconfiguration, and thus will be unable to communicate with hosts on the stub network.¶
Whenever the ReachableTime for a router advertising a suitable prefix exceeds MAX_SUITABLE_REACHABLE_TIME, the stub router MUST send unicast neighbor solicits as described in Section 7.2.2 of [RFC4861] until either a response is received, which resets ReachableTime to zero, or the maximum number of retransmissions has been sent.¶
The stub router MUST listen for router solicits on the AIL. When a router solicit is received, if none of the on-link routers on the AIL are marked reachable, the stub router MUST move this interface to the STATE-BEGIN-ADVERTISING state (Section 5.1.2.3).¶
If a RA beacon interval arrives, and there are no routers advertising suitable prefixes that have a ReachableTime that is less than MAX_SUITABLE_REACHABLE_TIME, then the router MUST move this interface to the STATE-BEGIN-ADVERTISING state.¶
In this state, the stub router generates its own on-link prefix for the interface. This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds. The stub router sends a router advertisement (RA) containing this prefix in a Prefix Information Option (PIO). In the PIO, the A (autonomous configuration) flag Section 4.6.2 of [RFC4861] MUST be set and the L (on-link) flag SHOULD be set. The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag.¶
The Stub Router flag ([I-D.hui-stub-router-ra-flag]) MUST be set in the RA flags field. The values of the M and O flags MUST be copied from the respective M/O flag values seen in the most recent (unicast or multicast) RA received from a non-stub-router. For the selection of the most recent RA, the following RAs MUST be excluded:¶
If there is no recent RA from a non-stub-router, both M and O flags MUST be cleared, unless the stub router rebooted recently. After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the M and O flags provided by that stub router MUST be copied. After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above. This avoids a situation where a stub router that has rebooted starts to advertise different M/O flag values than other stub routers present on the same link.¶
The sent router advertisement MUST also include a Route Information option (Section 2.3 of [RFC4191]) for each routable prefix advertised on the stub network. If the stub router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space.¶
After having sent the initial router advertisement, the stub router moves the interface into the STATE-ADVERTISING-SUITABLE state (Section 5.1.2.4).¶
When entering this state, if the router MUST begin treating the interface as an Advertising Interface as described in Section 6.2.2 of [RFC4861] if it is not already doing so.¶
The stub router sends a router advertisement message, as described in Section 5.1.2.3, every RA_BEACON_INTERVAL seconds.¶
The stub router may receive a router advertisement containing one or more suitable on-link prefixes on the AIL. If any of these prefixes are different than the prefix the stub router is advertising as the on-link suitable prefix, and the Stub Router flag is not set in in the Router Advertisement flags field, the stub router moves the interface to STATE-DEPRECATING (Section 5.1.2.5).¶
If the stub router bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be considered suitable:¶
On entry to this state, the stub router has been treating the interface as an Advertising Interface as described in Section 6.2.2 of [RFC4861], and MUST continue to do so.¶
When the stub router has detected the availability of suitable on-link prefix on the AIL to which the interface is attached, and that prefix is preferable to the one it is advertising, it continues to advertise its own prefix, but deprecates it:¶
In this state, the valid lifetime (VALID) is computed based on three values: the current time when a router advertisement is being generated (NOW), the time at which the new suitable on-link prefix advertisement was received (DEPRECATE_TIME), and STUB_PROVIDED_PREFIX_LIFETIME. All of these values are in seconds. VALID is computed as follows:¶
VALID = STUB_PROVIDED_PREFIX_LIFETIME - (NOW - DEPRECATE_TIME)¶
If VALID is less than RA_BEACON_INTERVAL, the stub router does not include the deprecated prefix in the router advertisement. Note that VALID could be less than zero. Otherwise, the prefix is provided in the advertisement, but with a valid lifetime of VALID.¶
How addressability is managed on stub networks depends on the nature of the stub network. For some stub networks, the stub router can be sure that it is the only router. For example, a stub router that is providing a Wi-Fi network for tethering will advertise its own SSID and use its own joining credentials; in this case, it can assume that it is the only router for that network, and advertise a default route and on-link prefix just like any other router.¶
However, some stub networks are more cooperative in nature, for example IP mesh networks. On such networks, multiple stub routers may be present and be providing addressability and reachability.¶
In either case, some stub router connected to the stub network MUST provide a suitable on-link prefix (the OSNR prefix) for the stub network. If the stub network is a multicast-capable medium where Router Advertisements are used for router discovery, the same mechanism described in Section 5.1.2 is used.¶
Stub networks that do not support the use of Router Advertisements for router discovery must use some similar mechanism that is compatible with that type of network. Describing the process of establishing a common OSNR prefix on such networks is out of scope for this document.¶
Stub routers may restart from time to time; when a restart occurs, the stub router may have been advertising state to the network which, following the restart, is no longer required.¶
For example, suppose there are two stub routers connected to the same infrastructure link. When the first stub router is restarted, the second takes over providing an on-link prefix. Now the first router rejoins the link. It sees that the second stub router's prefix is advertised on the infrastructure link, and therefore does not advertise its own.¶
This behavior can cause problems because the first stub router no longer sees the on-link prefix it had been advertising on infrastructure as on-link. Consequently, if it receives a packet to forward to such an address, it will forward that packet directly to a default router, if one is present; otherwise, it will have no route to the destination, and will drop the packet.¶
To address this problem, stub routers SHOULD remember the last time a prefix was advertised across restarts. On restart, the router configures the prefix on its interface but does not advertise it in Router Advertisements. Devices that are still using that prefix will be seen as on-link to the router, and so packets will be delivered using ND on-link rather than forwarded to the default router.¶
When a stub router has only flash memory with limited write lifetime, it may be inappropriate to do a write to flash every time an RA beacon containing a prefix is sent. In this case, the router SHOULD 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 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.¶
In order to be able to provide addressability either on the stub network or on an adjacent infrastructure network, a stub router MUST allocate its own ULA Site Pefix. ULA prefixes, described in Unique Local IPv6 Unicast Addresses ([RFC4193]) are randomly allocated prefixes. A stub router MUST allocate a single ULA Site Prefix for use in providing on-link prefixes to the stub network and the adjacent infrastructure link, as needed.¶
Any ULA Link Prefixes allocated by a stub router SHOULD be maintained across reboots, and SHOULD remain stable over time. (TBD: mention the SHOULD exception cases) However, for privacy reasons, a stub router that roams from network to network SHOULD allocate a different ULA Link Prefix each time it connects to a different infrastructure network, unless configured to behave otherwise.¶
If DHCPv6 prefix delegation and IPv6 service are both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using DHCPv6 prefix delegation. Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet.¶
By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the AIL. The OSNR prefix in this case is not known to the infrastructure network routing fabric, so even though packets might be able to be forwarded to the intended destination, there would be no return path. So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure-provided NAT64 will not work. Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6 PD, it MUST use DHCPv6 PD rather than the ULA Link prefix it allocated for the stub network out of its ULA Site Prefix.¶
A stub router SHOULD request stub network prefixes with length 64. If the stub router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the stub router obtains a prefix with length greater than 64, the stub router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead.¶
Stub routers MUST advertise reachability to stub network OSNR prefixes on any AIL to which they are connected. If the stub router is advertising a suitable prefix on any interface, any such prefixes MUST be advertised on that interface in the same router advertisement that is advertising the suitable prefix, to avoid unnecessary multicast traffic.¶
Each stub network will have some set of prefixes that are advertised as on-link for that network. A stub router connected to that stub network SHOULD advertise reachability to all such prefixes on any AIL to which it is attached using router advertisements.¶
A stub router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements. The exception to this rule is the case where the stub router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP.¶
The stub router MAY advertise itself as a default router on the stub network, if it itself has a default route on the AIL. In some cases it may not be desirable to advertise reachability to the Internet as a whole; in this case the stub router is not required to advertise itself as a default router.¶
If the stub router is not advertising itself as a default router on the stub network, it MUST advertise reachability to any prefixes that are being advertised as on-link on AILs to which it is attached. This is true for prefixes it is advertising, and for other prefixes being advertised on that link.¶
Note that in some stub network configurations, it is possible for more than one stub router to be connected to the stub network, and each stub router may be connected to a different AIL. In this case, a stub router advertising a default route may receive a packet destined for a link that is not an AIL for that router, but is an AIL for a different router. In such a case, if the infrastructure is not capable of routing between these two AILs, a packet which could have been delivered by another stub router will be lost by the stub router that received it.¶
Consequently, stub routers SHOULD be configurable to not advertise themselves as default routers on the stub network. Stub routers SHOULD be configurable to explicitly advertise AIL prefixes on the stub network even if they are advertising as a default router. The mechanisms by which such configuration can be accomplished are out of scope for this document.¶
It is also possible that stub routers for more than one stub network may be connected to the same AIL. In this case, the stub routers will be advertising Router Information options in their router advertisements for their OSNR prefixes. Stub routers MUST track the presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks.¶
Since DNS-SD is in wide use, and provides for ad-hoc, self-configuring advertising using the mDNS transport, this is a suitable mandatory-to-implement protocol for stub networks, which must be able to attach to infrastructure networks without the help of new mechanisms provided by the infrastructure. Therefore, stub routers MUST provide DNS-SD service as described in this section.¶
The adjacent infrastructure can be assumed to already enable some service discovery mechanism between hosts on the infrastructure network, and can be assumed to provide a local DNS resolver. Therefore, we do not need to define a stub-network-specific mechanism for providing these services on the infrastructure network.¶
In some cases it will be necessary for hosts on the AIL to be able to discover devices on the stub network. In other cases, this will be unnecessary or even undesirable. For example, it may be undesirable for devices on an AIL to be able to discover devices on a Wi-Fi tether provided by a mobile phone.¶
One example of a use case for stub networks where such discovery is desirable is the constrained network use case. In this case a low-power, low-cost stub network provides connectivity for devices that provide services to the infrastructure. For such networks, it is necessary that devices on the infrastructure be able to discover devices on the stub network.¶
The most basic use case for this is to provide feature parity with existing solutions like multicast DNS (mDNS). For example, a light bulb with built-in Wi-Fi connectivity might be discoverable on the infrastructure link to which it is connected, using mDNS, but likely is not discoverable on other links. To provide equivalent functionality for an equivalent device on a constrained network that is a stub network, the stub network device must be discoverable on the infrastructure link (which is an AIL from the perspective of the stub network).¶
If services are to be advertised using DNS Service Discovery [RFC6763], there are in principle two ways to accomplish this. One is to present services on the stub network as a DNS zone which can then be configured as a browsing domain in the DNS ([RFC6763], Section 11). The second is to advertise stub network services on the AIL using multicast DNS (mDNS) [RFC6762].¶
Because this document defines behavior for stub routers connecting to infrastructure networks that do not provide any new mechanism for integrating stub networks, there is no way for a stub router to provide DNS-SD service on an infrastructure link in the form of a DNS zone in which to do discovery. Therefore, service on the infrastructure link MUST be provided using an Advertising Proxy, as defined in [I-D.ietf-dnssd-advertising-proxy].¶
One limitation of this solution is that it requires that hosts on the stub network use the DNS-SD Service Registration Protocol [I-D.ietf-dnssd-srp] to register their DNS-SD advertisements. This means that in the case of a stub network used for WiFi tethering, hosts on the stub network will not be discoverable by hosts on the infrastructure network. Any solution to this problem would require that the stub router provide a Discovery Proxy [RFC8766]. However, a discovery proxy is queried using DNS, not mDNS. This requires assistance from the infrastructure network, and is therefore out of scope for this document.¶
Hosts on the stub network may need to discover hosts on the AIL, or on the stub network. In the IoT network example we've been using, there might be a light switch on the stub network which needs to be able to actuate a light bulb connected to the AIL. In order to know where to send the actuation messages, the light switch will need to be able to discover the light bulb's address somehow.¶
Because the stub network is managed by stub routers, any DNS resolver that's available on the stub network will necessarily be provided by one or more stub routers. This means that the stub router can enable discovery of hosts on the infrastructure network by hosts on the stub network using a Discovery Proxy [RFC8766]. The Discovery Proxy can be advertised as available to hosts on the stub network through the DNS resolver provided on the stub network, as described in Section 11 of [RFC6763].¶
By implication, this means that stub routers MUST provide a DNS resolver. In addition, stub routers MUST provide DNS zones for each AIL, and MUST list these zones in the list of default browsing zones as defined in RFC6763. [[WG: we need to say how these zones are named. Or refer to the Advertising Proxy doc and have that doc say how they are named.]]¶
The stub router MUST also maintain an SRP registrar and use registrations made through that registrar to populate a DNS zone which is advertised as a default browsing domain, as above. This SRP registrar MUST be advertised on the stub network either using the dnssd-srp and/or dnssd-srp-tls service names or some stub-network-specific mechanism, the details of which are out of scope for this document.¶
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 suitable.¶
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 other than to the adjacent infrastructure link, 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 Site 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. This also works on the return path because each stub router has its own IPv4 address, and the return packet will be destined for that IPv4 packet, and hence will always return through the stub router that translated it on the way out.¶
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.¶
Stub networks are defined to be IPv6-only because it would be difficult to implement a stub network using IPv4 technology. However, stub network devices may need to be able to communicate with IPv4-only services either on the infrastructure network, or on the global internet. Ideally, the infrastructure network fully supports IPv6, and all services on the infrastructure network are IPv6-capable. In this case, perhaps the infrastructure network provides NAT64 service to IPv4-only hosts on the internet. In this ideal setting, the stub router need do nothing—the infrastructure network is doing it all.¶
In this situation, if there are multiple stub routers, each connected to the same AIL, there is no need for special behavior—each stub router can advertise a default route, and any stub router may be used to route NAT64 traffic. If some stub routers are connected to different AILs than others, some of which support NAT64 and some of which do not, then the default route may not carry traffic to the correct link for NAT64 service. In this case, a more specific address to the infrastructure NAT64 prefix(es) MUST be advertised by those stub routers that are able to discover it.¶
In order for infrastructure-provided NAT64 to work, the stub network must have an OSNR prefix that is known to the infrastructure. Typically this means that the stub router must have acquired this prefix using DHCPv6 Prefix Delegation. Unless otherwise configured to do so, the stub router MUST NOT advertise infrastructure-provided NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation.¶
Most infrastructure networks at present do not provide NAT64 service. Many infrastructure networks do not provide DHCPv6 Prefix Delegation. In these cases it is necessary for stub routers to be able to provide NAT64 service if IPv4 hosts are to be reachable from the stub network. Therefore, stub routers MUST be capable of providing NAT64 service to the stub network. When infrastructure-provided NAT64 service is not present or is not usable, and when no other NAT64 service is already advertised on the stub network, stub routers MUST, by default, enable their own NAT64 service and advertise it on the stub network.¶
To provide NAT64 service, a stub router must allocate a NAT64 prefix. For convenience, the stub network allocates a single prefix out of the ULA Site Prefix that it maintains. Out of the 2^16 possible subnets of the /48, the stub router SHOULD use the numerically highest /64 prefix.¶
If there are multiple stub routers providing connectivity between the stub network and infrastructure, each stub network uses its own NAT64 prefix—there is no common NAT64 prefix. The reason for this is that NAT64 translation is not stateless, and is tied to the stub router's IPv4 address. Therefore each NAT64 egress is not equivalent.¶
A stub network that services a Wi-Fi stub network SHOULD provide DNS64 translation: hosts on the stub network cannot be assumed to be able to do DNS64 synthesis in the stub resolver. In this case the DNS resolver on the stub router MUST honor the CD and DO bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation. In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis.¶
On specific stub networks it may be desirable to require the stub network device to perform DNS64 synthesis. Stub network routers for such networks do not need to provide DNS64 synthesis. Instead, they MUST provide an ipv4only.arpa answer that advertises the NAT64 prefix for that stub router, and MUST provide an explicit route to that NAT64 prefix on the stub network using RA or whatever technology is specific to that stub network type.¶
In constrained networks it can be very useful if stub network resolvers provide the information required to do DNS64 translation in the answer to the AAAA query. If the answer to an AAAA query comes back with "no data" (not NXDOMAIN), this suggests that there may be an A record. In this case, the stub network's resolver SHOULD attempt to look up an A record on the same name. If such a record exists, the resolver SHOULD return no data in the Answer section of the DNS response, and SHOULD provide any CNAME records that were involved in returning the "no data" answer to the AAAA query, and SHOULD provide any A records that were ultimately returned, in the Additional section. The resolver should also include an ipv4only.arpa record in the Additional section.¶
Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can produce partitioned networks, where what is notionally the same stub network winds up looking like two or more discrete links. For mesh networks, such partitions can form and rejoin over time as a result of either changes in radio propagation or the addition of, or removal of, devices on the mesh.¶
On stub networks that can partition, one way of detecting that a partition has occurred is to notice that the stub router that has advertised the on-link prefix for the stub network is no longer reachable via the stub network. When this occurs, stub routers that notice this loss of reachability MUST advertise a ULA Link Prefix derived from their ULA Site Prefix on the stub network.¶
An implication of this is that when such a partition forms, the same ULA Link Prefix can’t be advertised on both partitions, since this will result in ambiguous routing. We address this problem by requiring that each stub router generate its own ULA Site Prefix. This prefix is then available for two purposes: providing addressing on the AIL, if needed, and providing addressing on the stub network, if needed.¶
When partitions of this type occur, they may also heal. When a partition heals in a situation where two stub routers have both been advertising a prefix, it will now appear that there are two prefixes on the stub network.¶
When the time comes to deprecate one or more prefixes as a result of a network partition healing, only one prefix should remain. If there are any GUA prefixes, and if there is no specific configuration contradicting this, the GUA prefix that is numerically lowest should be kept, and all others deprecated. If there are no GUA prefixes, then the ULA Link Prefix that is numerically lowest should be kept, and the others deprecated. By using this approach, it is not necessary for the routers to coordinate in advance.¶
In order to provide network access, stub routers must provide some network services to the stub network. We have previously discussed the following services:¶