Stub networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the limited
availability and functionality of IPv4 router discovery mechanisms (such as ICMP Router Discovery Messages
[RFC1256]) compared to IPv6 Router Advertisements. However, it can still be useful for hosts on the stub network
to establish communications with IPv4-only hosts on the infrastructure network or the Internet.¶
Although NAT64 [RFC6146] provides IPv6-only hosts with a way to reach IPv4-only hosts, there is no easy way for an IPv4-only host to
use NAT64 to originate communication with a host using IPv6. Therefore, a SNAC router enables hosts on the stub network
to discover and reach IPv4-only hosts on infrastructure, but does not provide a way for IPv4-only hosts
on infrastructure to communicate to (IPv6-only) hosts on the stub network.¶
This should be acceptable, because hosts on the infrastructure network that need to communicate with hosts on the stub network
are expected to be capable of using IPv6 to do so, and of course it is necessary that hosts on the stub network be capable of
communicating using IPv6 since SNAC routers do not provide IPv4 service on their stub networks.¶
So the purpose of providing IPv4 connectivity for stub network hosts is to enable communication with arbitrary IPv4-only hosts which
may be on the AIL, elsewhere on the infrastructure network, or on the Internet. This is accomplished by providing NAT64 address translation in the SNAC router, and by enabling
service discovery using a Discovery Proxy in the SNAC router.¶
A SNAC router MUST be capable of providing NAT64 service itself, and MUST be capable of discovering the availability
of NAT64 service on the infrastructure network and providing it to its stub network 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, a SNAC router MUST use the mechanism provided by the network medium used on the stub network to advertise
NAT64 service. Otherwise, NAT64 service MUST be advertised on the stub network using the PREF64 Router Advertisement option
[RFC8781].¶
All the normative requirements in the remainder of this section (including subsections) apply to the default operation
of a SNAC router.
A SNAC router SHOULD be administratively configurable to disable and re-enable its NAT64 function.
The consequence of not following this recommendation is that a SNAC router's NAT64 function is always enabled;
a network administrator then has no means to prevent hosts on the stub network from initiating communication to IPv4
destinations, for example to enforce an IPv6-only network policy or to comply with local security requirements, other
than switching off the SNAC router.¶
In case that the NAT64 function in a SNAC router is administratively disabled, these
requirements do not apply as long as the NAT64 function remains disabled.
Note that if NAT64 is disabled, the SNAC router's discovery and use of NAT64 service on the infrastructure network
is also disabled.¶
There are four possible combinations of circumstances in which to consider how to provide NAT64 service:¶
-
Infrastructure provides DHCPv6-PD support, and the infrastructure provides NAT64¶
-
Infrastructure provides no DHCPv6-PD support, infrastructure provides NAT64, and there is no IPv4 on infrastructure¶
-
Infrastructure provides no DHCPv6-PD support, infrastructure provides NAT64, and there is IPv4 on infrastructure¶
-
Infrastructure provides no DHCPv6-PD support, infrastructure provides no NAT64 (and may also not be providing
IPv6), and there is IPv4 on infrastructure¶
In the first case, infrastructure-provided NAT64 is preferred, and the SNAC router MUST advertise this NAT64 service
to the stub network.¶
In the second case, there is no way to provide connectivity to the infrastructure network: there is no IPv6 routing other than to
the adjacent infrastructure link, because there is no routable prefix, and there is no NAT64 for the same reason, and there
is no IPv4, so the SNAC router can't do NAT64 on its own. In this case, the SNAC router MUST NOT advertise NAT64
service.¶
In the third case, despite the infrastructure network providing NAT64, nodes in the stub network can't use it, so the SNAC
router MUST provide its own NAT64 service.¶
In the fourth case, the SNAC router MUST provide its own NAT64 service.¶
An additional complication is that there may be more than one SNAC router connecting the stub network to infrastructure. In
this case, it may be desirable to limit the number of SNAC routers providing NAT64 service, or it may be acceptable for all
SNAC routers to provide it.¶
In the latter case, this should not be a problem: since each SNAC router is using its own ULA site prefix to provide NAT64,
any 5-tuple that goes through a SNAC 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 SNAC router through which to send the packet for
translation. This also works on the return path, because each SNAC router has its own IPv4 address, and the return packet
will be destined for that IPv4 address, and hence will always return through the SNAC router that translated it on the way
out.¶
A further complication is that in some cases, some SNAC routers connected to the stub network may not be able to
advertise an infrastructure-provided NAT64 prefix, while others may.
This can happen, for example, due to a stub network technology limitation on the number of (NAT64) prefixes that can
be advertised simultaneously at any given time.
In such cases, when at least one infrastructure-provided NAT64
service is already advertised on the stub network, a SNAC router that was initially not able to advertise a NAT64 service
on the stub network MUST stop attempting to advertise NAT64 service itself until the moment that there is no more NAT64
service advertised on the stub network.¶
For stub network technologies that support the advertising of a NAT64 service with an associated preference level,
the below rules for preference level selection MUST be used.
Although the details of such a stub network technology's service advertisements are out of scope of this document,
it is assumed that at least the three levels of 'low', 'medium', and 'high' can be distinguished with it.
For stub network technologies that don't support NAT64 preference levels (for example, technologies using the PREF64 option),
these rules do not apply.¶
To differentiate between infrastructure-provided NAT64 service and SNAC router-provided NAT64 service, a SNAC router that
advertises infrastructure-provided NAT64 service with a preference level MUST use a preference of 'medium' for this service.
A SNAC router advertising its own service MUST use a preference of 'low'.¶
In some cases a SNAC router may be administratively configured with a NAT64 prefix. In this situation, the SNAC router
MUST advertise the prefix with a preference of 'high'.¶
A SNAC router MUST monitor the advertisement of other NAT64 prefixes on the stub network. If a SNAC router is advertising
a NAT64 prefix on a constrained stub network, and another NAT64 prefix is advertised on the stub network with a
higher preference level, the SNAC router SHOULD deprecate the NAT64 prefix it is advertising.
This rule is based on the assumption that for a constrained stub network technology the size of the network configuration
data needs to be minimized. Exceptions to this rule specific to a stub network technology may apply.
The consequence of not following this rule depends on the stub network technology. For a constrained stub network,
it can be the case that a prefix entry is needlessly occupied (by the NAT64 prefix) in the network configuration data,
potentially preventing another prefix entry to be advertised.¶
Stub networks are defined to be IPv6-only in this specification, while enabling IPv6 stub network hosts to use
IPv4-only services and to communicate with IPv4-only hosts.
Ideally, the infrastructure network also fully supports IPv6, and all
services on the infrastructure network are IPv6-capable. In this case, perhaps the infrastructure network provides NAT64
service to enable communication with IPv4-only hosts on the Internet.
In this ideal setting, the SNAC router need do nothing—the infrastructure network is doing it all.¶
In this situation, if there are multiple SNAC routers, each connected to the same AIL, there is
no need for special behavior—each SNAC router can advertise a default route, and any SNAC router may be used to route NAT64
traffic. If some SNAC 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.
Advertising (on the stub network) a specific route to the NAT64 prefix would resolve this issue.
However, given that support for multiple AILs connected to the same stub network is out of scope
(see Section 4.2), there are no normative requirements related to this for a SNAC router.¶
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 SNAC router must have acquired this prefix using DHCPv6 prefix delegation.
Unless otherwise configured to do so, the SNAC router MUST NOT advertise infrastructure-provided NAT64 service on the
stub network if the OSNR prefix was not acquired 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 SNAC routers to be able to provide NAT64 service if IPv4-only hosts are
to be reachable from the stub network. Therefore, a SNAC router 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, a SNAC router MUST enable its own NAT64 service and advertise it
on the stub network.¶
To provide NAT64 service, a SNAC router MUST allocate a /96 NAT64 prefix. For convenience, the SNAC router allocates a single
prefix out of the ULA site prefix that it maintains. Out of the 2^16 possible subnets of the /48, the SNAC router SHOULD
use the numerically highest /64 prefix and allocate the /96 NAT64 prefix from that.
The consequence of not following this recommendation is that the NAT64 prefix and addresses derived from it are
harder to identify in stub network diagnostic/debugging/logging operations, and might be more easily confused
with ULA link prefixes.¶
If there are multiple SNAC routers providing connectivity between the stub network and infrastructure, each SNAC router
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 SNAC router's IPv4 address. Therefore, each NAT64 egress is not equivalent.¶
This specification requires the stub network host itself to perform local IPv6 address synthesis, as needed,
analogous to the customer-side translator (CLAT) function of 464XLAT [RFC6877]. This is the
host-side equivalent of the network-based DNS64 [RFC6147] function. A SNAC router does not
provide DNS64.¶
A SNAC router MUST provide an explicit route to its NAT64 prefix
on the stub network using RA or an equivalent protocol for that stub network type.¶
In constrained networks it can be useful if a SNAC router's DNS resolver provides the information required to do DNS64
translation already in the answer to an AAAA query. If the answer to an AAAA query has zero AAAA records (but not
the NXDOMAIN response code), this suggests that there may still be an A record for the name.
In this case, the DNS resolver in the SNAC router MUST attempt to look up A record(s) on the same name, unless it is
explicitly configured to disable such lookups.
If such A record(s) exist, the DNS resolver MUST provide these in the Additional section of the DNS response.
If the queried name is an alias, the chain of CNAME records leading from the queried name to the canonical name
is already present in the Answer section of the response, per standard CNAME processing
(Section 3.6.2 of [RFC1034]); the A record(s) provided in the Additional
section are in that case the A record(s) of the canonical name.¶