Automatically Connecting Stub Networks to Unmanaged Infrastructure
Apple Inc.
One Apple Park Way
Cupertino
California
95014
USA
mellon@fugue.com
Internet
Internet Engineering Task Force
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).
Introduction
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:
-
Incompatible speed: for example, an 802.15.4 network could not be easily bridged to a WiFi network because the data rates
are so dissimilar. So either it must be bridged in a very complicated and careful way to avoid overwhelming the 802.15.4
network with irrelevant traffic, or the 802.15.4 network needs to be a separate subnet.
-
Incompatible media: for example, a constrained 802.15.4 network connected as a stub network to a WiFi or ethernet
infrastructure network. In the case of an 802.15.4 network, it is quite possible that the devices used to link the
infrastructure network to the stub network will not be conceived of by the end user as routers. Consequently, we cannot
assume that these devices will be on all the time. A solution for this use case will require some sort of commissioning
process for stub routers, and can't assume that any particular stub router will always be available; rather, any stub
router that is available must be able to adapt to current conditions to provide reachability.
-
Convenience: end users often connect devices to each other in order to extend networks
-
Transitory connectivity: a mobile device acting as a router for a set of co-located devices could connect to a network
and gain access to services for itself and for the co-located devices. Such a stub network is unlikely to have more
than one stub router.
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. This document addresses local reachability. A
host on a locally reachable stub network can only interoperate with hosts on the network link(s) to which it is connected.
It may be noted that just as you can plug several home routers together in series to form multi-layer NATs, there is
nothing preventing the owner of a stub network router from plugging it into another stub network router. 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.
Interoperability Goals
The goal here 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:
-
is discoverable by hosts attached to adjacent infrastructure links
-
is able to discover hosts attached to adjacent infrastructure links
-
is able to discover hosts on the Internet
-
is able to acquire an IP address that can be used to communicate with hosts attached to adjacent
infrastructure links
-
has reachability to the hosts attached to adjacent infrastructure links
-
is reachable by hosts on the adjacent infrastructure link
-
is able to reach hosts on the Internet
Discoverability here means "discoverable using DNS, or DNS Service Discovery". DNS Service Discovery includes multicast
DNS . 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 . In both cases,
"discoverable using DNS" means that the host has an entry in the DNS.
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 on adjacent links, for locally reachable stub networks.
Reachability to hosts on adjacent links means that when a host (A) on the stub network has the IP address of such a host
(B), with which it intends to communicate, host (A) knows of a next-hop router to which it can send datagrams, so that
they will ultimately reach host (B).
Reachability from hosts on adjacent links means that when host (A) on an adjacent 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.
Usability Goals
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.
Glossary
- Addressability
- The ability to associate each node on a link with its own IPv6 address.
-
Reachability
- Given an IPv6 destination address that is not on-link for any link to which a node is attached, the
information required that allows the node to send packets to a router that can forward those packets towards a link where
the destination address is on-link.
- Infrastructure network
-
the network infrastructure to which a stub router connects. This network can be a single link, or a network of links. The
network may also provide some services, such as a DNS resolver, a DHCPv4 server, and a DHCPv6 prefix delegation server,
for example.
- Adjacent infrastructure link
- any link to which a stub network router is directly attached, that is part of an infrastructure network and is not the
stub network.
- Off-Stub-Network-Routable (OSNR) Prefix
- a prefix advertised on the stub network that can be used for communication with hosts not on the stub network.
Constants
This section describes the meaning of and gives default values for various constants used in this document.
- STALE_RA_TIME
-
Default: 10 minutes. The amount of time that can pass after the last time a router advertisement from a particular has
been received before we assume the router is no longer present. This is a stopgap in case the router is reachable but has
silently stopped advertising a prefix; this situation is unlikely, but if it does happen, new devices joining the
infrastructure network will not be able to reach devices on the stub network until the stub router decides that the router
that advertised the usable prefix is stale.
- STUB_PROVIDED_PREFIX_LIFETIME
-
Default: 30 minutes. The valid and preferred lifetime the stub router will advertise. This needs to be long enough that a
host is actually willing to use it, and obviously should also be long enough that a missed beacon will not cause the host
to stop using it. The values suggested here allow ten beacons to be missed before the host will stop using the
prefix.
- BEACON_INTERVAL
-
Default: 3 minutes. How often the stub router will transmit an RA. This should be frequent enough that a missed Router
Solicit (e.g. due to congestion on a WiFi link) will not result in an extremely long outage (assuming the congestion
passes before the beacon is sent, of course).
- PREFIX_DELEGATION_INTERVAL
-
Default: 30 minutes. The lifetime a stub router should request for a DHCPv6-delegated prefix. The longer this is, the more
prefixes will be consumed on a network where stub routers are not stable. The lifetime here is chosen to be long enough
that a reboot of the DHCP server will not prevent the prefix being renewed. It happens to coincide with the value of
STUB_PROVIDED_PREFIX_LIFETIME, but the two should not be considered to be equivalent.
- MAX_USABLE_REACHABLE_TIME
-
Default: 60 seconds. The maximum ReachableTime value that a router can have in the Neighbor Table before any usable
prefixes it has advertised are no longer considered usable.
Conventions and Terminology 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
when, and only when, they appear in all capitals, as shown here.
Support for adjacent infrastructure links
We assume that the adjacent infrastructure link supports Neighbor Discovery , 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
.
Support for adjacent
infrastructure links on networks where Neighbor Discovery is not supported are out of scope for this document. Stub routers
do not provide routing between adjacent infrastructure links when connected to more than one such link.
Managing addressability on an adjacent infrastructure link
In order to provide IPv6 routing to the stub network, IPv6 addressing must be available on each adjacent infrastructure
link. 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.
Usable On-Link Prefixes
IPv6 addressing is considered to be present on the link if a usable on-link prefix is advertised on the adjacent
infrastructure link. A usable on-link prefix is a prefix advertised on the link that has a preferred time of 30 minutes
or more, is marked on-link and allows autonomous configuration.
A prefix is not considered a usable on-link prefix if it is advertised on the link as on-link, but the 'm' bit is set in
the Router Advertisement message header () that contains
the Prefix option. This indicates that node addressibility 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 "usable"—not all
hosts can actually use it.
A prefix is considered to be advertised on the link if, when a Router Solicit message
() is sent, a Router Advertisement message is received in
response which contains a prefix information option ()
for that prefix.
After an RA message containing a usable prefix has been received, it can be assumed for some period of time thereafter that the 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.
State Machine for maintaining a usable on-link prefix on an infrastructure link
The possible states of an interface connected to an adjacent infrastructure link 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 adjacent infrastructure link, it is able to acquire an IPv6 address on that
link.
Status of IP addressability on adjacent infrastructure link unknown (STATE-UNKNOWN)
When the stub router interface first connects to the adjacent infrastructure link, it MUST begin router discovery.
If, after router discovery has completed, no usable on-link prefix has been found, the router moves this interface to
STATE-BEGIN-ADVERTISING ().
If, during router discovery, a usable on-link prefix is found, the router moves the interface to
STATE-USABLE ().
In this state, the stub router MUST NOT treat this interface as an advertising interface as described in
.
IP addressability already present on adjacent infrastructure link (STATE-USABLE)
When entering this state, if the router MUST discontinue treating the interface as an Advertising Interface as
described in , if it has been doing so.
When a new host appears on the adjacent infrastructure link and sends an initial router solicit, if it does not
receive a usable 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.
Router staleness detection
The stub router MUST listen for router advertisements on the adjacent infrastructure link 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 usable. When the last non-stale router advertisement containing
a usable prefixes on the link is marked stale, the stub router MUST move the interface to STATE-BEGIN-ADVERTISING.
Router Unreachability Detection
For each usable route, the stub router MUST monitor the state of reachability to the router(s) that
advertised it as described in () using a ReachableTime
value of no more than MAX_USABLE_REACHABLE_TIME. The reason for this is that if no router providing the on-link
prefix on the infrastructure link is reachable, then when a new host joins the network, it will have no usable 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 usable prefix exceeds MAX_USABLE_REACHABLE_TIME, the stub router
MUST send unicast neighbor solicits as described in 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 adjacent infrastructure link. When a router solicit is
received, if none of the on-link routers on the adjacent infrastructure link are marked reachable, the stub router
MUST move this interface to the STATE-BEGIN-ADVERTISING state ().
If a beacon interval arrives, and there are no routers advertising usable prefixes that have a ReachableTime that is
less than MAX_USABLE_REACHABLE_TIME, then the router MUST move this interface to the STATE-BEGIN-ADVERTISING state.
IP addressability not present on adjacent infrastructure link (STATE-BEGIN-ADVERTISING)
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 containing
this prefix. The 'A' (autonomous configuration), 'L' (on-link) and the Stub
Router bit () MUST be set in the prefix header.
This router advertisement MUST also include a Route Information Option () 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-USABLE
state ().
IP addressability not present on adjacent infrastructure link (STATE-ADVERTISING-USABLE)
When entering this state, if the router MUST begin treating the interface as an Advertising Interface as
described in if it is not already doing so.
The stub router sends a router advertisement message, as described in , every
BEACON_INTERVAL seconds.
The stub router may receive a router advertisement containing a usable on-link prefix on the adjacent infrastructure
link. If the advertised prefix is different than the prefix the stub router is advertising as the on-link usable
prefix, and the Stub Router bit is not set in the prefix option for the prefix, the stub router moves the interface to
STATE-DEPRECATING ().
If the stub router bit is set in the received prefix, then one of the following must be true:
-
The prefixes are equal. In this case, the interface remains in STATE-ADVERTISING-USABLE.
-
The prefix the stub router is advertising is a ULA , and the received prefix is a non-ULA
prefix. In this case, the interface moves into the STATE-DEPRECATING () state.
-
Both prefixes are ULA prefixes, and the received prefix, considered as a 128-bit big-endian unsigned integer,
is numerically lower, then the interface moves to STATE-DEPRECATING (.
-
Otherwise the interface remains in STATE-ADVERTISING-USABLE.
Stub router deprecating its on-link prefix (STATE-DEPRECATING)
On entry to this state, the stub router has been treating the interface as an Advertising Interface as described in
, and MUST continue to do so.
When the stub router has detected the availability of usable on-link prefix on the adjacent infrastructure link 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:
-
the preferred lifetime for its prefix should be set to zero in subsequent router advertisement messages.
-
the valid lifetime for its prefix should be reduced with each subsequent router advertisement messages.
-
the usability of the infrastructure-provided on-link prefix should be monitored as in the STATE-USABLE state; if
during the deprecation period, the stub router detects that there are no longer any usable prefixes on the link, as
described in or in , it MUST return the interface to the
STATE-BEGIN-ADVERTISING () state and resume advertising its prefix with the
valid and preferred lifetimes described there.
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 usable 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 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.
Managing addressability on the stub network
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 usable 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 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.
Maintenance across stub router restarts
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 can immediately begin deprecating the prefix, and can stop after the prefix valid lifetime goes to zero, based
on the recorded time that the last advertisement was sent.
When a stub router has only flash memory with limited write lifetime, it may be inappropriate to do a write to flash
every time a prefix beacon happens. 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, 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.
Generating a ULA prefix to provide addressability
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 prefix. ULA prefixes, described in Unique Local IPv6 Unicast Addresses
() are randomly allocated prefixes. A stub router MUST allocate a single ULA prefix for use in
providing on-link prefixes to the stub network and the infrastructure network, as needed.
The ULA prefix allocated by a stub router SHOULD be maintained across reboots, and SHOULD remain stable over
time. For privacy reasons, a stub router that roams from network to network may wish to allocate a different ULA prefix
each time it connects to a different infrastructure network.
If IPv6 prefix delegation is available, which implies that IPv6 service is also available on the infrastructure
link, then the stub router MAY use IPv6 prefix delegation to acquire a prefix to advertise on the stub network, rather
than allocating one out of its ULA prefix.
Managing reachability on the adjacent infrastructure link
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 usable prefix on any interface, any such prefixes MUST be advertised on that interface in the same
beacon that is advertising the usable 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 network SHOULD advertise reachability to all such prefixes on any AIL to which it is attached using router
advertisements
Managing reachability on the stub network
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 adjacent infrastructure
link. 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.
Providing discoverability between stub network links and infrastructure network links
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.
Discoverability by hosts on adjacent infrastructure links
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 adjacent infrastructure link 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 adjacent infrastructure link to be able to discover devices on a Wi-Fi tether, for example 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 , 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 (). The second is to advertise stub network
services on the AIL using multicast DNS (mDNS) .
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 .
One limitation of this solution is that it requires that hosts on the stub network use the DNS-SD Service Registration
Protocol 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 .
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.
Providing discoverability of adjacent infrastructure hosts on the stub network
Hosts on the stub network may need to discover hosts on the adjacent infrastructure network, 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 adjacent infrastructure network. 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 .
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 .
By implication, this means that stub routers MUST provide a DNS resolver. In addition, stub routers MUST provide
DNS zones for each adjacent infrastructure link, 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.
Providing reachability to IPv4 services to the stub network
NAT64 provided by infrastructure
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
adjacent infrastructure, 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 adjacent infrastructure link, there is
no need for special behavior—each stub router can advertise a default route, and any stub router will do to route NAT64
traffic. If some stub routers are connected to different adjacent infrastructure links 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.
NAT64 provided by stub router(s)
Most infrastructure networks at present do not provide NAT64 service. It is therefore necessary for stub routers to
be able to provide NAT64 service if IPv4 hosts are to be reachable from 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 /48 ULA 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.
Handling partitioning events on a stub network
If a stub network is constructed using mesh technology, it may become partitioned. In such a situation, it may be one stub
router is connected to one partition, and another stub router is connected to the other partition. In this situation, in
order for all nodes to be reachable, it is necessary that each partition of the stub network have its own prefix. When
such a partition occurs, the stub routers must detect that it has occurred. If a stub router is currently providing a
prefix on the stub network, it need take no action. If a stub router had not been providing a prefix on the stub network,
and now discovers that there is no stub router providing a prefix on the network, it MUST begin to provide its own prefix
on the stub network. It MUST also advertise reachability to that new prefix on its adjacent infrastructure link(s).
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 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.
Normative References