Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise NetworksThe IPv6 CompanyMolino de la Navata, 75La Navata - GalapagarMadrid28420Spainjordi.palet@theipv6company.comhttp://www.theipv6company.com/v6ops
IPv6, DNSSEC, NAT64, DNS64, 464XLAT, CLAT, NAT46, PLAT
This document describes how NAT64 (including 464XLAT) can be deployed
in an IPv6 network, whether cellular ISP, broadband ISP,
or enterprise, and possible optimizations.
The document also discusses issues to be considered when having
IPv6-only connectivity, regarding:
a) DNS64,
b) applications or devices that use literal IPv4 addresses or
non-IPv6 compliant APIs,
and c) IPv4-only hosts or applications.Stateful NAT64 () describes a stateful IPv6 to IPv4
translation mechanism, which allows IPv6-only hosts to communicate with
IPv4-only servers using unicast UDP, TCP, or ICMP, by means of IPv4 public
addresses sharing, among multiple IPv6-only
hosts. Unless otherwise stated, references in the rest of this document
to NAT64 (function) should be interpreted as to Stateful NAT64.The translation of the packet headers is done using the IP/ICMP
translation algorithm defined in and
algorithmically translating the IPv4 addresses to IPv6 addresses
and vice versa, following .DNS64 () is in charge of the synthesis
of AAAA records from the A records, so only works for applications
making use of DNS. It was designed to avoid changes in both,
the IPv6-only hosts and the IPv4-only server, so they can use
a NAT64 function. As discussed in Section 5.5 of ,
a security-aware and validating host has to perform the
DNS64 function locally.However, the use of NAT64 and/or DNS64 present three drawbacks:Because DNS64 () modifies DNS answers,
and DNSSEC is designed to detect such modifications, DNS64
() may potentially break DNSSEC, depending on
a number of factors, such as the location of the DNS64
function (at a DNS server or validator, at the end host, ...), how it
has been configured, if the end-hosts is validating, etc.Because the need of using DNS64 () or
an alternative "host/application built-in" mechanism for address synthesis,
there may be an issue for NAT64 (),
as it doesn't work when IPv4 literal addresses or non-IPv6 compliant
APIs are being used.NAT64 alone, was not designed to provide a solution for
IPv4-only hosts or applications located within a network
which are connected to a service provider IPv6-only access,
as it was designed for a very specific scenario (, Section 2.1).Above drawbacks may be true if part of, an enterprise network,
is connected to other parts of the same network or third-party networks
by means of IPv6-only connectivity. This is just an example which may
apply to many other similar cases. All them are deployment specific.According to that, across this document, the use of "operator",
"operator network", "service provider", and similar ones,
are interchangeable with equivalent cases of enterprise networks
(and similar ones). This may be also the case for "managed end-user
networks".Note that if all the hosts in a network were performing the address synthesis,
as described in Section 7.2 of , some of the drawbacks
may vanish. However, it is today unrealistic to expect that, considering
the high number of devices and applications that aren't yet IPv6-enabled.
So, in this document, this will be considered only for specific scenarios
that can guarantee it.An analysis of stateful IPv4/IPv6 mechanisms is provided in
.This document looks into different possible NAT64 ()
deployment scenarios, including IPv4-IPv6-IPv4 (464 for short) and similar ones,
which were not documented in , such as 464XLAT
(), in operator (broadband and cellular) and
enterprise networks, and provides guidelines to avoid operational issues.Towards that, this document first looks into the possible NAT64 deployment
scenarios (split in "known to work" and "known to work under special conditions"),
providing a quick and generic comparison table among them.
Then the document describes the issues that an operator need to understand
on different matters that will allow to define what is the best
approach/scenario for each specific network case. A summary provides some
recommendations and decision points. A section with clarifications
on the usage of this document for enterprise networks, is also provided.
Finally, an annex provides an example of a broadband deployment using 464XLAT
and another annex provides hints for a CLAT implementation. already provides information about
NAT64 deployment options and experiences. Both, this document and
are complementary; they are looking into
different deployment considerations and furthermore, this document is
considering the updated deployment experience and newer standards.The target deployment scenarios in this document may be covered as well
by other IPv4-as-a-Service (IPv4aaS) transition mechanisms. Note that this is
true only for the case of broadband networks, as in the case of cellular
networks the only supported solution is the use of NAT64/464XLAT.
So, it is out of scope of this document to provide a comparison among the
different IPv4aaS transition mechanisms, which is being analyzed already
in .Consequently, this document should not be understood as a guide for
an operator or enterprise to decide which IPv4aaS is the best one for
its own network. Instead it should be used as a tool for understanding
all the implications, including relevant documents (or even specific
parts of them), for the deployment of NAT64/464XLAT and facilitate
the decision process regarding specific deployment details.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.Section 7 of DNS64 (), provides three scenarios,
depending on the location of the DNS64 function. However, since the publication
of that document, other deployment scenarios and NAT64 use cases need to
be considered in actual networks, despite some of them were specifically
ruled out by the original NAT64/DNS64 work.Consequently, the perspective in this document is to broaden those scenarios,
including a few new ones. However, in order to be able to reduce the number
of possible cases, we work under the assumption that typically, the service
provider wants to make sure that all the customers have a service
without failures. This means considering the following assumptions
for the worst possible case:There are hosts that will be validating DNSSEC.IPv4 literal addresses and non-IPv6 compliant APIs are being used.There are IPv4-only hosts or applications beyond the
IPv6-only link (e.g., tethering in cellular networks).The document uses a common set of possible "participant entities":An IPv6-only access network (IPv6).An IPv4-only remote network/server/service (IPv4).A NAT64 function (NAT64) in the service provider.A DNS64 function (DNS64) in the service provider.An external service provider offering the NAT64 function and/or the
DNS64 function (extNAT64/extDNS64).464XLAT customer side translator (CLAT).Note that the nomenclature used in parenthesis is the one that, for short,
will be used in the figures. Note also that for simplicity, the boxes in
the figures don't mean they are actually a single device; they just represent
one or more functions as located in that part of the network (i.e. a single box
with NAT64 and DNS64 functions can actually be several devices, not just one).The possible scenarios are split in two general categories:Known to work.Known to work under special conditions.The scenarios in this category are known to work, as there are well-known
existing deployments from different operators using them. Each one may have
different pros and cons, and in some cases the trade-offs,
maybe acceptable for some operators.In this scenario (), the service
provider offers both, the NAT64 and the DNS64 functions.This is the most common scenario as originally considered by
the designers of NAT64 () and
DNS64 (), however
also may have the implications related the DNSSEC.This scenario also may fail to solve the issue of
IPv4 literal addresses or non-IPv6 compliant APIs, as well as
the issue of IPv4-only hosts or applications behind the
IPv6-only access network.A similar scenario () will be if
the service provider offers only the DNS64 function, and the NAT64
function is provided by an outsourcing agreement with
an external provider.
All the considerations in the previous paragraphs of this
section, are the same for this sub-case.This is equivalent to the scenario ()
where the outsourcing
agreement with the external provider is to provide both the
NAT64 and DNS64 functions. Once more, all the considerations
in the previous paragraphs of this section are the same
for this sub-case.One additional equivalent scenario ()
will be if the service provider
offers the NAT64 function only, and the DNS64 function is from an
external provider with or without a specific agreement among them.
This is a scenario already common today, as
several "global" service providers provide free DNS/DNS64
services and users often configure manually their DNS. This
will only work if both the NAT64 and the DNS64 functions are using the
WKP (Well-Known Prefix) or the same NSP (Network-Specific Prefix).
All the considerations in the previous paragraphs
of this section, are the same for this sub-case.Of course, if the external DNS64 function is agreed with the
service provider, then we are in the same case as in the previous
ones already depicted in this scenario.464XLAT () describes an architecture that
provides IPv4 connectivity across a network, or part of it,
when it is only natively transporting IPv6.
already suggest the need to support the CLAT function in order to
ensure the IPv4 service continuity in IPv6-only cellular deployments.In order to do that, 464XLAT () relies on the
combination of existing protocols:The customer-side translator (CLAT) is a stateless IPv4 to IPv6
translator (NAT46) () implemented in the
end-user device or CE (Customer Edge Router), located at the
"customer edge" of the network.The provider-side translator (PLAT) is a stateful NAT64
(), implemented typically at in
the operator network.Optionally, DNS64 (), may allow
an optimization: a single translation at the NAT64, instead
of two translations (NAT46+NAT64), when the application at
the end-user device supports IPv6 DNS (uses AAAA
Resource Records).Note that even if in the 464XLAT () terminology,
the provider-side translator is referred as PLAT, for simplicity and
uniformity, across this document is always referred as NAT64 (function).In this scenario () the service provider
deploys 464XLAT with a DNS64 function.As a consequence, the DNSSEC issues remain, unless the host
is doing the address synthesis.464XLAT () is a very simple approach to cope
with the major NAT64+DNS64 drawback: Not working with applications or
devices that use literal IPv4 addresses or non-IPv6 compliant APIs.464XLAT () has been used initially mainly in
IPv6-only cellular networks. By supporting a CLAT function, the end-user
device applications can access IPv4-only end-networks/applications,
despite those applications or devices use literal IPv4 addresses
or non-IPv6 compliant APIs.In addition to that, in the same example of the cellular network above,
if the User Equipment (UE) provides tethering, other devices behind it
will be presented with a traditional NAT44, in addition to the native
IPv6 support, so clearly it allows IPv4-only hosts behind the IPv6-only
access network.Furthermore, as discussed in , 464XLAT
can be used in broadband IPv6 network architectures,
by implementing the CLAT function at the CE.The support of this scenario in a network, offers two additional advantages:DNS load optimization: A CLAT should implement a DNS proxy
(as per ), so that only IPv6 native queries
and only for AAAA records are sent to the DNS64 server. Otherwise
doubling the number of queries may impact the DNS infrastructure.Connection establishment delay optimization: If the UE/CE
implementation is detecting the presence of a DNS64 function,
it may issue only the AAAA query, instead of both the AAAA
and A queries.In order to understand all the communication possibilities, let's
assume the following representation of two dual-stack peers:The possible communication paths, among the IPv4/IPv6 stacks of
both peers, in this case, are:Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation.Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM (Explicit Address Mappings) as indicated by
. In principle,
it is not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be
IPv6-capable.Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations.Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT
implements EAM as indicated by , instead of
using the path d. above, NAT64 translation is avoided and the
flow will use IPv6 from the CLAT to the destination.The rest of the figures in this section show different choices for placing
the different elements.A similar scenario () will be
if the service provider
offers only the DNS64 function, and the NAT64 function is provided by
an outsourcing agreement with an external provider.
All the considerations in the previous paragraphs of this
section are the same for this sub-case.As well, is equivalent to the scenario ()
where the outsourcing
agreement with the external provider is to provide both the
NAT64 and DNS64 functions. Once more, all the considerations
in the previous paragraphs of this section are the same
for this sub-case.The major advantage of this scenario (),
using 464XLAT without DNS64,
is that the service provider ensures that DNSSEC is never broken, even
in case the user modifies the DNS configuration. Nevertheless, some
CLAT implementations or applications may impose an extra delay, which
is induced by the dual A/AAAA queries (and wait for both responses),
unless Happy Eyeballs v2 () is also present.A possible variation of this scenario is the case when DNS64 is
used only for the discovery of the NAT64 prefix. The rest of the document
is not considering it as a different scenario, because once the prefix
has been discovered, the DNS64 function is not used, so it behaves as if
the DNS64 synthesis function is not present.In this scenario, as in the previous one, there are no
issues related to IPv4-only hosts (or IPv4-only applications)
behind the IPv6-only access network, neither related to the
usage of IPv4 literals or non-IPv6 compliant APIs.The support of this scenario in a network, offers one advantage:DNS load optimization: A CLAT should implement a DNS proxy
(as per ), so that only IPv6 native queries
are sent to the DNS64 server. Otherwise doubling the number of
queries may impact the DNS infrastructure.As indicated earlier, the connection establishment delay optimization
is achieved only in the case of devices, Operating Systems, or applications
that use Happy Eyeballs v2 (), which is very common.Let's assume the representation of two dual-stack peers as in the
previous case:The possible communication paths, among the IPv4/IPv6 stacks of
both peers, in this case, are:Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers.Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations.Local-IPv4 to Remote-IPv6: Not possible unless the CLAT
implements EAM as indicated by . In principle,
it is not expected that services are deployed in Internet using
IPv6-only, unless there is certainty that peers will also be
IPv6-capable.Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations.Local-IPv4 to Remote-dual-stack using EAM optimization: If the CLAT
implements EAM as indicated by , instead of
using the path d. above, NAT64 translation is avoided and the flow
will use IPv6 from the CLAT to the destination.It needs to be noticed that this scenario works while the local
hosts/applications are dual-stack (which is the current situation),
because the connectivity from a local-IPv6 to a remote-IPv4 is not possible
without an AAAA synthesis. This aspect is important only when in the
LANs behind the CLAT there are IPv6-only hosts and they need to
communicate with remote IPv4-only hosts. However, it doesn't look a
sensible approach from an Operating System or application vendor
perspective, to provide IPv6-only support unless,
similarly to case c above, there is certainty of peers supporting
IPv6 as well. A solution approach to this is also presented
in .The following figures show different choices for placing
the different elements.This is equivalent to the scenario ()
where there is an
outsourcing agreement with an external provider for the
NAT64 function. All the considerations in the previous
paragraphs of this section are the same for this sub-case.The scenarios in this category are known to not work unless significant
effort is devoted to solve the issues, or are intended to solve problems
across "closed" networks, instead of as a general Internet access usage.
In addition to the different pros, cons and trade-offs,
which may be acceptable for some operators, they have implementation
difficulties, as they are beyond the original expectations of the
NAT64/DNS64 original intent.In this scenario (),
the service provider offers a NAT64 function,
however there is no DNS64 function support at all.As a consequence, an IPv6 host in the IPv6-only
access network, will not be able to detect the presence
of DNS64 by means of , neither to learn the
IPv6 prefix to be used for the NAT64 function.This can be sorted out as indicated in .However, despite that, because the lack of the DNS64
function, the IPv6 host will not be able to obtain
AAAA synthesized records, so the NAT64 function becomes useless.An exception to this "useless" scenario will be
manually configure mappings between the A records of each
of the IPv4-only remote hosts and the corresponding AAAA records,
with the WKP (Well-Known Prefix) or NSP (Network-Specific Prefix)
used by the service provider NAT64 function,
as if they were synthesized by a DNS64 function.This mapping could be done by several means, typically
at the authoritative DNS server, or at the service provider
resolvers by means of DNS RPZ (Response Policy Zones,
) or equivalent functionality.
DNS RPZ, may have implications in DNSSEC, if the zone is signed.
Also, if the service provider is using an NSP, having the mapping
at the authoritative server, may create troubles to other parties
trying to use different NSP or the WKP, unless multiple DNS "views"
(split-DNS) is also being used at the authoritative servers.Generally, the mappings alternative, will only make sense
if a few set of IPv4-only remote hosts need to be accessed
by a single network (or a small number of them), which support
IPv6-only in the access. This will require some kind of mutual
agreement for using this procedure, so it doesn't care if they
become a trouble for other parties across Internet
("closed services").In any case, this scenario doesn't solve the issue of
IPv4 literal addresses or non-IPv6 compliant APIs, neither it
solves the problem of IPv4-only hosts within that IPv6-only
access network.In this scenario (),
the service provider offers the
NAT64 function, but not the DNS64 function. However, the IPv6 hosts
have a built-in DNS64 function.This may become common if the DNS64 function is
implemented in all the IPv6 hosts/stacks.
However, commonly this is not the actual
situation, even if it may happen in the medium-term.
At this way, the DNSSEC validation is performed on the A record,
and then the host can use the DNS64 function so to be able
to use the NAT64 function, without any DNSSEC issues.This scenario fails to solve the issue of
IPv4 literal addresses or non-IPv6 compliant APIs, unless
the IPv6 hosts also supports Happy Eyeballs v2
(, Section 7.1), which may solve that issue.However, this scenario still fails to solve the problem
of IPv4-only hosts or applications behind the IPv6-only
access network.In this scenario (), the service provider offers the
NAT64 function only. The remote IPv4-only network offers the
DNS64 function.This is not common, and looks like doesn't make too much sense
that a remote network, not deploying IPv6, is providing a DNS64
function. As in the case of the scenario depicted in
, it will only work if both sides are
using the WKP or the same NSP, so the same considerations apply.
It can be also tuned to behave as in This scenario still fails to solve the issue of
IPv4 literal addresses or non-IPv6 compliant APIs.This scenario also fails to solve the problem
of IPv4-only hosts or applications behind the IPv6-only
access network.This section compares the different scenarios, including the
possible variations (each one represented in the precedent sections
by a different figure), looking at the following criteria:DNSSEC: Are there hosts validating DNSSEC?Literal/APIs: Are there applications using IPv4 literals or non-IPv6
compliant APIs?IPv4-only: Are there hosts or applications using IPv4-only?Foreign DNS: Is the scenario surviving if the user, Operating System,
applications or devices change the DNS?DNS load opt. (DNS load optimization): Are there extra queries that
may impact DNS infrastructure?Connect. opt. (Connection establishment delay optimization):
Is the UE/CE issuing only the AAAA query or also an A query and
waiting for both responses?In the next table, the columns represent each of the scenarios from the
previous sections, by the figure number. The possible values are:"-" Scenario "bad" for that criteria."+" Scenario "good" for that criteria."*" Scenario "bad" for that criteria, however it is typically
resolved, with the support of Happy Eyeballs v2 ().In some cases, "countermeasures", alternative or
special configurations, may be available for the criteria designated
as "bad". So, this comparison is considering a generic
case, as a quick comparison guide. In some cases, a "bad" criterion is
not necessarily a negative aspect, all it depends on the specific
needs/characteristics of the network where the deployment will
take place. For instance, in a network which has only IPv6-only hosts and
apps using only DNS and IPv6-compliant APIs, there is no impact using
only NAT64 and DNS64, but if the hosts may validate DNSSEC,
that item is still relevant.As a general conclusion, we should note that, if the network
must support applications using any of the following:IPv4 literalsnon-IPv6-compliant APIsIPv4-only hosts or applicationsThen, only the scenarios with 464XLAT, a CLAT function,
or equivalent built-in local address synthesis features,
will provide a valid solution. Further to that, those scenarios will also
keep working if the DNS configuration is modified. Clearly also,
depending on if DNS64 is used or not, DNSSEC may be broken for
those hosts doing DNSSEC validation.All the scenarios are good in terms of DNS load optimization,
and in the case of 464XLAT it may provide an extra degree
of optimization. Finally, all them are also good in terms of
connection establishment delay optimization.
However, in the case of 464XLAT without DNS64, it requires the
usage of Happy Eyeballs v2. This is not an issue, as commonly it is available
in actual Operating Systems.This section reviews the different issues that an operator needs
to consider towards a NAT64/464XLAT deployment, as they may bring
to specific decision points about how to approach that deployment.As indicated in Section 8 of (DNS64, Security
Considerations), because DNS64 modifies DNS answers and DNSSEC is designed
to detect such modifications, DNS64 may break DNSSEC.If a device connected to an IPv6-only access network, queries
for a domain name in a signed zone, by means of a recursive name server
that supports DNS64, and the result is a synthesized AAAA record, and the
recursive name server is configured to perform DNSSEC validation and has
a valid chain of trust to the zone in question, it will
cryptographically validate the negative response from the authoritative
name server. This is the expected DNS64 behavior: The recursive name
server actually "lies" to the client device. However, in most of the cases,
the client will not notice it, because generally, they don't perform
validation themselves and instead, rely on the recursive name servers.A validating DNS64 resolver in fact, increase the confidence on
the synthetic AAAA, as it has validated that a non-synthetic AAAA
for sure, doesn't exists. However, if the client device is NAT64-oblivious
(most common case) and performs DNSSEC validation on the AAAA record,
it will fail as it is a synthesized record.The best possible scenario from DNSSEC point of view, is when the
client requests the DNS64 server to perform the DNSSEC validation
(by setting the DO bit to 1 and the CD bit to 0). In this case,
the DNS64 server validates the data, thus tampering may only happen
inside the DNS64 server (which is considered as a trusted part,
thus its likelihood is low) or between the DNS64 server and the
client. All other parts of the system (including transmission
and caching) are protected by DNSSEC ().Similarly, if the client querying the recursive name server is another
name server configured to use it as a forwarder, and is performing DNSSEC
validation, it will also fail on any synthesized AAAA record.All those considerations are extensively covered in
Sections 3, 5.5 and 6.2 of .A solution to avoid DNSSEC issues, will be that all the
signed zones also provide IPv6 connectivity, together with the
corresponding AAAA records. However, this is out of the control
of the operator needing to deploy a NAT64 function. This has been
proposed already in .An alternative solution, which was the one considered
while developing , is that validators
will be DNS64-aware, so could perform the necessary discovery
and do their own synthesis. That was done under the expectation
that it was sufficiently early in the validator-deployment
curve that it would be ok to break certain DNSSEC assumptions
for networks who were really stuck in a NAT64/DNS64-needing world.As already indicated, the scenarios in the previous section,
are in fact somehow simplified, looking at the worst possible case.
Saying it in a different way: "trying to look for the most perfect
approach". DNSSEC breach will not happen if the end-host
is not doing validation.Existing previous studies seems to indicate that the figures of DNSSEC
actually broken by using DNS64 will be around 1.7%
() of the cases. However, we can't negate
that this may increase, as DNSSEC deployment grows.
Consequently, a decision point for the operator must depend on
"do I really care for that percentage of cases and the impact in
my helpdesk or can I provide alternative solutions for them?".
Some possible solutions may be taken, as depicted in the next sections.A solution will be to avoid using DNS64, but as already
indicated this is not possible in all the scenarios.The use of DNS64 is a key component for some networks, in order
to comply with traffic performance metrics, monitored by some
governmental bodies and other institutions (, ).One drawback of not having a DNS64 at the network side,
is that is not possible to heuristically discover
the NAT64 ().
Consequently, an IPv6 host behind the IPv6-only access network, will not
be able to detect the presence of the NAT64 function, neither to learn the
IPv6 prefix to be used for it, unless it is configured by alternative
means.The discovery of the IPv6 prefix could be solved,
as described in , by means
of adding the relevant AAAA records to the ipv4only.arpa. zone,
of the service provider recursive servers, i.e., if
using the WKP (64:ff9b::/96):An alternative option to the above, is the use of DNS RPZ
() or equivalent functionalities. Note
that this may impact DNSSEC if the zone is signed.One more alternative, only valid in environments with PCP support (for
both the hosts or CEs and for the service provider network), is to follow
(Discovering NAT64 IPv6 Prefixes using PCP).Other alternatives may be available in the future. All them are
extensively discussed in ,
however the deployment evolution has evolved many considerations
from that document. New options are being documented, such using Router
Advertising () or DHCPv6 options
().It may be convenient the simultaneous support of several of the
possible approaches, in order to ensure that clients with different
ways to configure the NAT64 prefix, successfully obtain it.
This is also convenient even if DNS64 is being used.Of special relevance to this section is also .In general, by default, DNS servers with DNS64 function will not
synthesize AAAA responses if the DNSSEC OK (DO) flag was set in the query.In this case, as only an A record is available, if a CLAT function
is present, it means that the CLAT will take the responsibility,
as in the case of literal IPv4 addresses, to keep that traffic
flow end-to-end as IPv4, so DNSSEC is not broken.However, this will not work if a CLAT function is not present
as the hosts will not be able to use IPv4 (which is the case for all the
scenarios without 464XLAT).If the DO flag is set and the client device performs DNSSEC validation,
and the Checking Disabled (CD) flag is set for a query, the DNS64
recursive server will not synthesize AAAA responses. In this case,
the client could perform the DNSSEC validation with the A record
and then synthesize the AAAA ().
For that to be possible, the client must have learned beforehand
the NAT64 prefix using any of the available methods
(, ,
, ).
This allows the client device to avoid using the DNS64 function and still
use NAT64 even with DNSSEC.If the end-host is IPv4-only, this will not work if a CLAT function is
not present (scenarios without 464XLAT).Some devices or Operating Systems may implement, instead of a CLAT,
an equivalent function by using Bump-in-the-Host (),
implemented as part of Happy Eyeballs v2 (Section 7.1 of ).
In this case, the considerations in the above paragraphs are
also applicable.If a CE includes CLAT support and also a DNS proxy, as indicated in
Section 6.4 of , the CE could behave as a stub
validator on behalf of the client devices. Then, following the same approach
described in the , the DNS proxy
actually will "lie" to the client devices, which in most of the cases will
not notice it, unless they perform validation by themselves. Again, this
allow the client devices to avoid using the DNS64 function and still use NAT64
with DNSSEC.Once more, this will not work without a CLAT function (scenarios
without 464XLAT).In cases of dual-stack clients, the AAAA queries typically take
preference over A queries. If DNS64 is enabled for those clients,
will never get A records, even for IPv4-only servers.As a consequence, in cases where there are IPv4-only servers,
and those are located in the path before the NAT64 function,
the clients will not be able to reach them. If DNSSEC is being
used for all those flows, specific addresses or prefixes can be
left-out of the DNS64 synthesis by means of ACLs.Once more, this will not work without a CLAT function (scenarios
without 464XLAT).If there are well-known specific IPv4 addresses or prefixes
using DNSSEC, they can be mapped-out of the DNS64 synthesis.Even if this is not related to DNSSEC, this "mapping-out" feature
is actually, quite commonly used to ensure that
addresses (for example used by LAN servers) are not synthesized to
AAAA.Once more, this will not work without a CLAT function (scenarios
without 464XLAT).When a client device, using DNS64 tries to reverse-map a
synthesized IPv6 address, the name server responds with a CNAME record
pointing the domain name used to reverse-map the
synthesized IPv6 address (the one under ip6.arpa), to the domain name
corresponding to the embedded IPv4 address (under in-addr.arpa).This is the expected behavior, so no issues need to be considered
regarding DNS reverse mapping.In the case the client device is IPv6-only (either because the stack or
application is IPv6-only, or because it is connected via an IPv6-only LAN)
and the remote server is IPv4-only (either because the stack is IPv4-only,
or because it is connected via an IPv4-only LAN), only NAT64 combined
with DNS64 will be able to provide access among both. Because DNS64 is
then required, DNSSEC validation will be only possible if the recursive
name server is validating the negative response from the authoritative
name server and the client is not performing validation.Note that is not expected at this stage of the transition,
that applications, devices or Operating Systems are IPv6-only. It will
not be a sensible decision for a developer to work on that direction,
unless it is clear that the deployment scenario fully supports it.On the other hand, an end-user or enterprise network may decide to
run IPv6-only in the LANs. In case there is any chance for
applications to be IPv6-only, the Operating System may be
responsible either for doing a local address synthesis, or
alternatively, setting up some kind of on-demand VPN (IPv4-in-IPv6),
which need to be supported by that network. This may become
very common in enterprise networks, where "Unique IPv6 Prefix
per Host" is supported.However, when the client device is dual-stack and/or connected in a
dual-stack LAN by means of a CLAT function (or has a built-in
CLAT function), DNS64 is an option.With DNS64: If DNS64 is used, most of the IPv4 traffic
(except if using literal IPv4 addresses or non-IPv6 compliant APIs)
will not use the CLAT, so will use the IPv6 path and only one
translation will be done at the NAT64. This may break DNSSEC,
unless measures as described in the precedent sections are taken.Without DNS64: If DNS64 is not used, all the IPv4 traffic
will make use of the CLAT, so two translations are required (NAT46
at the CLAT and NAT64 at the PLAT), which adds some overhead in
terms of the extra NAT46 translation. However, this avoids the AAAA
synthesis and consequently will never break DNSSEC.Note that the extra translation, when DNS64 is not used, takes place
at the CLAT, which means no extra overhead for the operator.
It however adds potential extra delays to establish the connections, and no
perceptible impact for a CE in a broadband network, while it may have
some impact in a battery powered device. This cost for a battery powered
device, is possibly comparable to the cost when the device is doing a
local address synthesis (see Section 7.1 of ).Clients, devices or applications in a service provider network,
may use DNS servers from other networks. This may be the case either
if individual applications use their own DNS server, the
Operating System itself or even the CE, or combinations of the above.Those "foreign" DNS servers may not support DNS64, which as a consequence,
will mean that those scenarios that require a DNS64 may not work.
However, if a CLAT function is available, the considerations in
will apply.In the case that the foreign DNS supports the DNS64 function,
we may be in the situation of providing incorrect configurations parameters,
for example, un-matching WKP or NSP, or a case such the one described in
.Having a CLAT function, even if using foreign DNS
without a DNS64 function, ensures that everything will work,
so the CLAT must be considered as an advantage even against
user configuration errors. The cost of this, is that all the
traffic will use a double translation (NAT46 at the CLAT
and NAT64 at the operator network), unless there is
support for EAM ().An exception to that is the case when there is a CLAT function
at the CE, which is not able to obtain the correct configuration
parameters (again, un-matching WKP or NSP).However, it needs to be emphasized, that if there is not a CLAT function
(scenarios without 464XLAT), an external DNS without DNS64 support,
will disallow any access to IPv4-only destination networks, and will
not guarantee the correct DNSSEC validation,
so will behave as in the .In summary, it can be said, that the consequences of the use of
foreign DNS depend very much in each specific case. However, in general,
if a CLAT function is present, most of the time, there will not be any.
In the other cases, generally, the access to IPv6-enabled services
is still guaranteed for IPv6-enabled hosts, but not for IPv4-only hosts,
neither the access to IPv4-only services for any hosts in the network.The causes of "foreign DNS" could be classified in three main categories,
as depicted in the following sub-sections.It is becoming increasingly common that end-users or even devices
or applications configure alternative DNS in their Operating Systems,
and sometimes in CEs.A new trend is for clients or applications to use mechanisms for
DNS privacy/encryption, such as DNS over TLS
(), DNS over DTLS (),
DNS queries over HTTPS () or
DNS over QUIC ().
Those are commonly cited as DoT, DoH and DoQ.Those DNS privacy/encryption options, currently are typically
provided by the applications, not the Operating System vendors.
At the time of writing this document, at least DoT and DoH standards
have declared DNS64 (and consequently NAT64) out of their scope, so
an application using them may break NAT64, unless a correctly configured
CLAT function is used.When networks or hosts use "split-DNS" (also called Split Horizon,
DNS views or private DNS), the successful use of the DNS64 is not guaranteed.
Section 4 of , analyses this case.A similar situation may happen in case of VPNs that force all
the DNS queries through the VPN, ignoring the operator DNS64 function.Section 3 of (IPv6 Addressing of IPv4/IPv6 Translators),
discusses some considerations which are useful to decide if
an operator should use the WKP or an NSP.Taking in consideration that discussion and other issues, we can
summarize the possible decision points as:The WKP MUST NOT be used to represent non-global IPv4 addresses.
If this is required because the network to be translated use
non-global addresses, then an NSP is required.The WKP MAY appear in inter-domain routing tables, if the operator
provides a NAT64 function to peers. However, in this case, special
considerations related to BGP filtering are required and IPv4-embedded
IPv6 prefixes longer than the WKP MUST NOT be advertised (or accepted)
in BGP. An NSP may be a more appropriate option in those cases.If several NAT64 use the same prefix, packets from the same
flow may be routed to different NAT64 in case of routing changes.
This can be avoided either by using different prefixes for each NAT64
function, or by ensuring that all the NAT64 coordinate their state.
Using an NSP could simplify that.If DNS64 is required and users, devices, Operating Systems or
applications may change their DNS configuration, and deliberately
choose an alternative DNS64 function, most probably alternative
DNS64 will use by default the WKP. In that case, if an NSP is used by
the NAT64 function, clients will not be able to use the operator
NAT64 function, which will break connectivity to
IPv4-only destinations.A host or application using literal IPv4 addresses or older APIs,
which aren't IPv6 compliant, behind a network with IPv6-only access,
will not work unless any of the following alternatives is provided:CLAT (or equivalent function).Happy Eyeballs v2 (Section 7.1, ).Bump-in-the-Host () with a DNS64 function.Those alternatives will solve the problem for an end-host.
However, if that end-hosts is providing "tethering" or an equivalent
service to other hosts, that needs to be considered as well. In other
words, in a case of a cellular network, it resolves the issue for
the UE itself, but may be not the case for hosts behind it.Otherwise, the support of 464XLAT is the only valid and complete
approach to resolve this issue.An IPv4-only hosts or application behind a network with IPv6-only access,
will not work unless a CLAT function is present.464XLAT is the only valid approach to resolve this issue.As described in Section 6.3 of (IPv6 Prefix
Handling), if the CLAT function can be configured with a dedicated /64 prefix
for the NAT46 translation, then it will be possible to do a more
efficient stateless translation.Otherwise, if this dedicated prefix is not available, the CLAT function will
need to do a stateful translation, for example performing stateful NAT44
for all the IPv4 LAN packets, so they appear as coming from a single
IPv4 address, and then in turn, stateless translated to a single IPv6
address.A possible setup, in order to maximize the CLAT
performance, is to configure the dedicated translation prefix. This
can be easily achieved automatically, if the broadband CE or
end-user device is able to obtain a shorter prefix by means
of DHCPv6-PD (), or other alternatives.
The CE can then use a specific /64 for the translation. This is also
possible when broadband is provided by a cellular access.The above recommendation is often not possible for cellular networks,
when connecting smartphones (as UEs), as generally they don't use DHCPv6-PD
(). Instead, a single /64 is provided for
each PDP context and prefix sharing () is used.
So, in this case, the UEs typically have a build-in CLAT function
which is performing a stateful NAT44 translation
before the stateless NAT46.Explicit Address Mappings for Stateless IP/ICMP Translation
() provide a way to configure explicit
mappings between IPv4 and IPv6 prefixes of any length.
When this is used, for example in a CLAT function, it may provide a
simple mechanism in order to avoid traffic flows between
IPv4-only nodes or applications and dual-stack destinations
to be translated twice (NAT46 and NAT64), by creating mapping
entries with the GUA of the IPv6-reachable destination.
This optimization of the NAT64 usage is very useful in
many scenarios, including CDNs and caches, as described in
.In addition to that, it may provide as well a way for IPv4-only
nodes or applications to communicate with IPv6-only destinations.The use of NAT64, in principle, disallows IPv4 incoming connections,
which may be still needed for IPv4-only peer-to-peer applications.
However, there are several alternatives that resolve this issue:STUN (), TURN () and
ICE () are commonly used by peer-to-peer
applications in order to allow incoming connections with IPv4 NAT.
In the case of NAT64, they work as well. Note also the relevance of
.PCP () allows a host to control how incoming
IPv4 and IPv6 packets are translated and forwarded. A NAT64 may implement
PCP to allow this service.EAM () may also be used in order to configure
explicit mappings for customers that require them. This is used for example
by SIIT-DC () and SIIT-DC-DTM ().NAT64/464XLAT has demonstrated to be a valid choice in several
scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of
millions of users, being the predominant mechanism in the majority of the
cellular networks (which account for hundreds of millions of users).
NAT64/464XLAT offer different choices of deployment,
depending on each network case, needs and requirements. Despite that,
this document is not an explicit recommendation for using this choice
versus other IPv4aaS transition mechanisms. Instead, this document
is a guide that facilitates evaluating a possible implementation
of NAT64/464XLAT and key decision points about specific design
considerations for its deployment.Depending on the specific requirements of each deployment case,
DNS64 may be a required function, while in other cases the
adverse effects may be counterproductive.
Similarly, in some cases a NAT64 function, together with a DNS64 function,
may be a valid solution, when there is a certainty that IPv4-only hosts
or applications do not need to be supported ( and
). However, in other cases (i.e. IPv4-only devices
or applications need to be supported), the limitations of NAT64/DNS64,
may suggest the operator to look into 464XLAT as a more complete solution.In the case of broadband managed networks (where the CE is provided or
suggested/supported by the operator), in order to fully support
the actual user needs (IPv4-only devices and applications,
usage of IPv4 literals and non-IPv6 compliant APIs), the 464XLAT scenario
should be considered. In that case, it must support a CLAT function.If the operator provides DNS services, in order to increase performance
by reducing the double translation for all the IPv4 traffic,
they may support a DNS64 function and avoid, as much as possible,
breaking DNSSEC. In this case, if the DNS service
is offering DNSSEC validation, then it must be in such way that it is
aware of the DNS64. This is considered the simpler and safer approach,
and may be combined as well with other recommendations described
in this document:DNS infrastructure MUST be aware of DNS64 ().Devices running CLAT SHOULD follow the indications in
(Stub Validator). However, this may be out of the
control of the operator.CEs SHOULD include a DNS proxy and validator (). (ACL of clients) and
(Mapping-out IPv4 addresses) MAY be considered by
operators, depending on their own infrastructure.This "increased performance" approach has the disadvantage of
potentially breaking DNSSEC for a small percentage of validating
end-hosts versus the small impact of a double translation taking place
in the CE. If CE performance is not an issue, which is the most frequent
case, then a much safer approach is to not use DNS64 at all,
and consequently, ensure that all the IPv4 traffic
is translated at the CLAT ().If DNS64 is not used, at least one of the alternatives
described in , must be followed in order
to learn he NAT64 prefix.The operator needs to consider that if the DNS configuration can
be modified (, ,
), which most probably
is impossible to avoid, there are chances that instead of configuring
a DNS64 a foreign non-DNS64 is used. In a scenario with only a
NAT64 function IPv4-only remote host will no longer be accessible.
Instead, it will continue to work in the case of 464XLAT.Similar considerations need to be taken regarding the usage of
a NAT64 WKP vs NSP (), as they must match
with the configuration of the DNS64. In case of using foreign DNS,
they may not match.
If there is a CLAT and the configured foreign DNS is not a DNS64, the
network will keep working only if other means of learning the NAT64
prefix are available.As described in , for broadband networks,
the CEs supporting a CLAT function, SHOULD
support DHCPv6-PD (), or alternative means for
configuring a shorter prefix. The CE SHOULD internally reserve
one /64 for the stateless NAT46 translation. The operator must ensure
that the customers get allocated prefixes shorter than /64 in order
to support this optimization. One way or the other, this is not
impacting the performance of the operator network.Operators may follow Section 7 of (Deployment
Considerations), for suggestions in order to
take advantage of traffic engineering requirements.In the case of cellular networks, the considerations regarding DNSSEC
may appear as out-of-scope, because UEs Operating Systems,
commonly don't support DNSSEC. However, applications running on them
may do, or it may be an Operating System "built-in" support in the
future. Moreover, if those devices offer tethering,
other client devices behind the UE, may be doing the validation,
hence the relevance of a proper DNSSEC support by the operator network.Furthermore, cellular networks supporting 464XLAT
() and "Discovery of the IPv6 Prefix Used for
IPv6 Address Synthesis" (), allow a progressive
IPv6 deployment, with a single APN supporting all types of PDP context
(IPv4, IPv6, IPv4v6). This approach allows the network to
automatically serve every possible combinations of UEs.If the operator chooses to provide validation for the DNS64
prefix discovery, it must follow the advice from Section 3.1. of
(Validation of Discovered Pref64::/n).One last consideration, is that many networks may have a mix of different
complex scenarios at the same time, for example, customers requiring 464XLAT,
others not requiring it, customers requiring DNS64, others not, etc. In
general, the different issues and the approaches described in this document
can be implemented at the same time for different customers or parts of
the network. That mix of approaches don't present any problem or
incompatibility, as they work well together, being just a matter of
appropriate and differentiated provisioning. In fact, the NAT64/464XLAT
approach facilitates an operator offering both cellular and broadband
services, to have a single IPv4aaS for both networks while differentiating
the deployment key decisions to optimize each case. It even makes possible
using hybrid CEs that have a main broadband access link and a backup via
the cellular network.In an ideal world we could safely use DNS64, if the approach
proposed in
is followed, avoiding the cases where DNSSEC may be broken.
However, this will not solve the issues related to DNS Privacy
and Split DNS.The only 100% safe solution, which also resolves all the issues,
will be, in addition to having a CLAT function, not using a DNS64 but
instead making sure that the hosts have a built-in address
synthesis feature. Operators could manage to provide CEs with
the CLAT function, however the built-in address
synthesis feature is out of their control. If the synthesis is
provided either by the Operating System (via its DNS resolver API)
or by the application (via its own DNS resolver), in such way that
the prefix used for the NAT64 function is reachable for the host,
the problem goes away.Whenever feasible, using EAM ()
as indicated in , provides a very relevant
optimization, avoiding double-translations.Applications that require incoming connections, typically already
provide means for that. However, PCP and EAM, as indicated in
, are valid alternatives, even for
creating explicit mappings for customers that require them.The recommendations of this document can be used as well in
enterprise networks, campus and other similar scenarios (including
managed end-user networks).This include scenarios where the NAT64 function
(and DNS64 function, if available) are under
the control of that network (or can be configured manually according
to that network specific requirements), and for whatever reasons,
there is a need to provide "IPv6-only access" to any part of that
network or it is IPv6-only connected to third party-networks.An example of that is the IETF meetings network itself,
where both NAT64 and DNS64 functions are provided, presenting in this case
the same issues as per . If there
is a CLAT function in the IETF network, then there is no
need to use DNS64 and it falls under the considerations of
. Both scenarios have been tested and
verified already in the IETF network itself.Next figures are only meant to represent a few of the possible
scenarios, not pretending to be the only feasible ones. provides an example of an
IPv6-only enterprise network connected with dual-stack to
Internet and using local NAT64 and DNS64 functions. provides an example of a
dual-stack (DS) enterprise network connected with dual-stack (DS)
to Internet and using a CLAT function, without a DNS64 function.Finally, provides an example of an
IPv6-only provider with a NAT64 function, and a dual-stack (DS) enterprise
network by means of their own CLAT function, without a DNS64 function.This document does not have new specific security considerations beyond
those already reported by each of the documents cited.It should be remarked that the use of a DNS64 function has equivalent
privacy considerations as in the case of a regular DNS, either located
in the service provider or an external one.This document does not have any new specific IANA considerations.Note: This section is assuming that https://www.rfc-editor.org/errata/eid5152
is resolved, otherwise, this section may include the required text
to resolve the issue.Alternatively, this could be fixed also by .The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker,
Mohamed Boucadair, Alejandro D'Egidio, Dan Wing, Mikael Abrahamsson
and Eric Vyncke.Conversations with Marcelo Bagnulo, one of the co-authors of NAT64 and
DNS64, as well as several emails in mailing lists from Mark Andrews,
have been very useful for this work.Christian Huitema inspired working in this document by suggesting
that DNS64 should never be used, during a discussion regarding the
deployment of CLAT in the IETF network.This section summarizes how an operator may deploy an IPv6-only
network for residential/SOHO customers, supporting IPv6 inbound
connections, and IPv4-as-a-Service (IPv4aaS) by using 464XLAT.Note that an equivalent setup could also be provided for enterprise
customers. In case they need to support IPv4 inbound connections, several
mechanisms, depending on specific customer needs, allow that, for instance
.Conceptually, most part of the operator network could be IPv6-only
(represented in the next pictures as "IPv6-only flow"), or even if
this part of the network is actually dual-stack, only IPv6-access
is available for some customers (i.e. residential customers).
This part of the network connects the IPv6-only subscribers
(by means of IPv6-only access links), to the IPv6 upstream providers,
as well as to the IPv4-Internet by means of the NAT64 (PLAT
in the 464XLAT terminology).The traffic flow from and back to the CE to services available in the
IPv6 Internet (or even dual-stack remote services, when IPv6 is being used),
is purely native IPv6 traffic, so there are no special considerations about it.Looking at the picture from the DNS perspective, there are remote
networks with are IPv4-only, and typically will have only IPv4 DNS
(DNS/IPv4), or at least will be seen as that from the CE perspective.
At the operator side, the DNS, as seen from the CE, is
only IPv6 (DNS/IPv6) and has also a DNS64 function. In the customer LANs side, there is actually one network, which of course
could be split in different segments. The most common setup will be
those segments being dual-stack, using global IPv6 addresses and
for IPv4, as usual in any regular residential/SOHO IPv4 network.
In the figure, it is represented as tree segments, just to show that the
three possible setups are valid (IPv6-only, IPv4-only and dual-stack).In addition to the regular CE setup, which will be typically
access-technology dependent, the steps for the CLAT function
configuration can be summarized as:Discovery of the PLAT (NAT64) prefix: It may be done
using , or in those networks where PCP
is supported, by means of , or other
alternatives that may be available in the future, such as Router
Advertising () or
DHCPv6 options ().If the CLAT function allows stateless NAT46 translation, a /64 from
the pool typically provided to the CE by means of DHCPv6-PD
, need to be set aside for that translation.
Otherwise, the CLAT is forced to perform an intermediate stateful
NAT44 before the a stateless NAT46, as described in .A more detailed configuration approach is described in
.The operator network needs to ensure that the correct responses are provided
for the discovery of the PLAT prefix. It is highly recommended
to follow , in order to ensure that multiple /64s
are available, including the one needed for the NAT46 stateless translation.The operator needs to understand other issues, described across this document,
in order to take the relevant decisions. For example, if several NAT64 functions
are needed in the context of scalability/high-availability, an NSP should be
considered ().More complex scenarios are possible, for example, if a network offers
multiple NAT64 prefixes, destination-based NAT64 prefixes, etc.If the operator decides not to provide a DNS64 function, then this
setup turns into the one in the following Figure. This will be also
the setup that "will be seen" from the perspective
of the CE, if a foreign DNS is used and consequently is
not the operator-provided DNS64 function.In this case, the discovery of the PLAT prefix needs to be arranged as
indicated in .In this case, the CE doesn't have a built-in CLAT function, or the customer can
choose to setup the IPv6 operator-managed CE in bridge mode (and optionally
use an external router), or for example, there is an access technology
that requires some kind of media converter (ONT for FTTH, Cable-Modem
for DOCSIS, etc.), the complete setup will look as in .
Obviously, there will be some intermediate configuration steps for the
bridge, depending on the specific access technology/protocols, which
should not modify the steps already described in the previous cases
for the CLAT function configuration.It should be avoided that several routers (i.e., the operator provided CE
and a downstream user provided router) enable simultaneously routing and/or
CLAT, in order to avoid multiple NAT44 and NAT46 levels, as well as
ensuring the correct operation of multiple IPv6 subnets. In those cases,
it is suggested the use of HNCP ().Note that the procedure described here for the CE setup, can be simplified
if the CE follows .In addition to the regular set of features for a CE, a CLAT CE
implementation requires support of: for the NAT46 function. for the PLAT prefix discovery. for the PLAT prefix discovery if PCP is supported. for the PLAT prefix
discovery by means of Router Advertising. for the PLAT prefix
discovery by means of DHCP.If stateless NAT46 is supported, a mechanism to ensure that
multiple /64 are available, such as DHCPv6-PD .There are several OpenSource implementations of CLAT, such as:Android: https://github.com/ddrown/android_external_android-clat.Jool: https://www.jool.mx.Linux: https://github.com/toreanderson/clatd.OpenWRT: https://github.com/openwrt-routing/packages/blob/master/nat46/files/464xlat.sh.VPP: https://git.fd.io/vpp/tree/src/plugins/nat. has defined a benchmarking methodology for IPv6
transition technologies. NAT64 and 464XLAT are addressed among the single and
double translation technologies, respectively. DNS64 is addressed in
Section 9, and the methodology is more elaborated in .Several documents provide references to benchmarking results, for example
in the case of DNS64, .Section to be removed after WGLC.
Significant updates are:Text changes across all the document.Section to be removed after WGLC.
Significant updates are:Added references to new cited documents.Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs w/o DNS64.Overall review and editorial changes.Section to be removed after WGLC.
Significant updates are:Added text related to EAM considerations.Section to be removed after WGLC.
Significant updates are:Added cross references to EAM section.Reworded "foreing DNS section".Overall editorial review of text, pictures and nits correction.Section to be removed after WGLC.
Significant updates are:Corrected EAMT to EAM.Typos and nits.New considerations regarding incoming connections.Section to be removed after WGLC.
Significant updates are:Inputs/clarifications from IESG review.Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64Benchmarking DNS64 Implementations: Theory and PracticeBenchmarking Methodology for DNS64 ServersLet’s talk about IPv6 DNS64 & DNSSECAPNIC BlogMeasuring Broadband America Mobile 2013-2018 Coarsened DataFCCService client des opérateurs : les mesures de qualité de serviceARCEPBest Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose RIPE