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, NAT64, DNS64, 464XLAT
This document describes how NAT64 and 464XLAT can be deployed
in an IPv6 operator
(cellular and broadband) or enterprise network and the issues
to be considered when having an IPv6-only access link, regarding:
a) DNS64,
b) applications or devices that use literal IPv4 addresses or
non-IPv6 compliant APIs,
and c) IPv4-only hosts or applications.NAT64 () describes a stateful IPv6 to IPv4
translation, which allows IPv6-only hosts to contact IPv4 servers using
unicast UDP, TCP or ICMP, by means of a single or a set of IPv4 public
addresses assigned to the translator, to be shared by the IPv6-only clients.The translation of the packet headers is done using the IP/ICMP
Translation Algorithm defined in and
algorithmically translating the IPv4-hosts addresses to IPv6 ones
following .To avoid changes in both, the IPv6-only hosts and the IPv4-only server,
NAT64 requires also the use of a DNS64 (),
in charge for the synthesis of AAAA records from the A records.However, the use of NAT64 and/or DNS64 present three issues:Because DNS64 () modifies DNS answers,
and DNSSEC is designed to detect such modifications, DNS64
() can 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 as been
configured, if the end-hosts is validating, etc.Because the need of using DNS64 (),
there is a major issue for NAT64 (),
as doesn't work when literal addresses or non-IPv6 compliant
APIs are being used.NAT64 alone, doesn't provide
a solution for IPv4-only hosts or applications located within a
network which are connected to a service provider IPv6-only access.The same issues are true if part of an enterprise or similar network,
is connected to other parts of the same network or third party networks
by means of IPv6-only links.According to that, across this document, the use of "operator network"
is interchangeable with equivalent cases of enterprise
(or similar) networks.This document looks into different possible NAT64 ()
deployment scenarios, including 464XLAT () ones,
in operators (broadband and cellular) and enterprise networks, and provides
guidelines to avoid the above-mentioned 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 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 and then a clarification of the usage of this
document for enterprise networks is provided. Finally, an Annex provides an example
of a broadband deployment using 464XLAT.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 3 scenarios,
looking at the location of the DNS64. However, since the publication
of that document, there are new possible scenarios and NAT64 use cases
that need to be considered now, despite they were specifically ruled out
of the original NAT64/DNS64 work.Consequently, the perspective in this document is to broader 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 the service provider
wants to make sure that all the customers have a service without failures.
This means considering the worst possible case:There are hosts that will be validating DNSSEC.Literal addresses and non-IPv6 compliant APIs are being used.There are IPv4-only hosts or applications beyond the
IPv6-only link.We use a common set of possible "participant entities":An IPv6-only access network (IPv6).An IPv4-only remote network/server/services (IPv4).The NAT64 function (NAT64) in the service provider.The DNS64 function (DNS64) in the service provider.An external service provider offering the NAT64 and/or the
DNS64 function (extNAT64/extDNS64).464XLAT customer side translator (CLAT).We split the possible scenarios in two general categories:Known to work.Known to work under special conditions.The scenarios in this category are known to work. 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 function.This is probably the most common scenario, however
also has the implications related the DNSSEC.This scenario also fails to solve the issue of
literal addresses or non-IPv6 compliant APIs, as well as
the issue of IPv4-only hosts or applications inside the
IPv6-only access network.A totally equivalent 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.One more equivalent scenario will be if the service provider
offers the NAT64 only, and the DNS64 function is from an
external provider with or without a specific agreement among them.
This is an scenario already feasible today, as
several "global" service providers provide free DNS64
services and users often configure manually their DNS. This
will only work if both the NAT64 and the DNS64 are using the same
WKP (Well-Known Prefix) or 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 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.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, located at the "customer" edge of the
network.The provider-side translator (PLAT) is a stateful NAT64
(), implemented typically at the opposite edge
of the operator network, that provides access to both IPv4 and IPv6
upstreams.Optionally, DNS64 (), implemented as part
of the PLAT allows 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 RR).Note that even in the 464XLAT () terminology,
the provider-side translator is referred as PLAT, for simplicity and
uniformity, in this document is always referred as NAT64.In this scenario the service provider deploys 464XLAT with DNS64.As a consequence, the DNSSEC issues remain.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 in
IPv6 cellular networks, providing an IPv6-only access network.
By supporting CLAT, 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 inside the IPv6-only
access network.Furthermore, as indicated in (464XLAT),
can be used in broadband IPv6 network architectures,
by implementing the CLAT functionality at the CE.An equivalent 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.In this scenario, as in the previous one, there are no
issues related to IPv4-only hosts inside the IPv6-only access network,
neither to the usage of IPv4 literals or non-IPv6 compliant APIs.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 not to 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,
however there is no DNS64 function support.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 learning the
IPv6 prefix to be used for the NAT64.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 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,
as if they were synthesized by a DNS64.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). The
latest, may have implications in DNSSEC, if the zone is signed.
Also, if the service provider is using a NSP, having the mapping
at the authoritative server, will mean that may create troubles
to other parties trying to use different NSP or the WKP, unless
multiple DNS "views" are 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 reduced set of them, which support IPv6-only
in the access, with 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
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, but not the DNS64. 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, which is not the actual
situation. 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, without any DNSSEC issues.This scenario fails to solve the issue of
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 inside the IPv6-only
access network.In this scenario, the service provider offers the
NAT64 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 and 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
literal addresses or non-IPv6 compliant APIs.This scenario also fails to solve the problem
of IPv4-only hosts or applications inside 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 parameters:DNSSEC: Are there host validating DNSSEC?.Literal/APIs: Are there applications using 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 change the DNS?.In the next table, the columns represent each of the scenario from the
previous sections, by the Figure number. The possible values are:- Scenario "bad" for that item.+ Scenario "good" for that item.Needs to be noted that in some cases "countermeasures", alternative or
special configurations, may be available for the items designated
as "bad", so this comparison is making a generic
case, as a quick comparison guide. In some cases, a "bad" idem 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 literals, non-IPv6-compliant APIs, or
IPv4-only hosts or applications, only the scenarios with 464XLAT
will provide a solution. Further to that, those scenarios will also
keep working if the user change the DNS setup. Clearly also,
depending on if DNS64 is used or not, DNSSEC may be broken for
those hosts doing DNSSEC validation.This section reviews the different issues that an operator needs
to consider towards a NAT64/464XLAT deployment, as they may bring
to 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 can break DNSSEC.If a device connected to an IPv6-only WAN 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 an 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 .The ideal solution to avoid DNSSEC issues, will be that all the
signed zones also provide IPv6 connectivity, together with the
corresponding AAAA records, which is out of the control of the operator
needing to deploy NAT64.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.Previous data seems to indicate, that the figures of DNSSEC
broken by using DNS64 will be around 1.7% ().As already indicated, the scenarios in the previous section,
are in fact somehow simplified, looking at the worst possible case
(or saying it in a different way: "trying to look for the most perfect
approach"), because breaking DNSSEC will not happen if the end-host
is not doing validation, which is the case today in 1.7% of the cases.
So a decision point for the operator must dependo on "do I really care
for that percentage of cases or can I provide alternative
solutions for them?". Some possible solutions may be taken,
as depicted in the next sections.The ideal solution will be to avoid using DNS64, but as already
indicated this is not possible in all the scenarios.However, not having a DNS64, means that is not possible to
heuristically discover the NAT64 () and
consequently, an IPv6 host in the IPv6-only access network, will not
be able to detect the presence of the DNS64, neither to learn the
IPv6 prefix to be used for the NAT64.The learning of the IPv6 prefix could be solved 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
(Response Policy Zones).One more alternative, only valid in environments with PCP support (for
both the hosts or CEs and for the service provider network), to follow
(Discovering NAT64 IPv6 Prefixes using PCP).Other alternatives may be available in the future, such as DHCPv6
options.It may be convenient to support at the same time several of the
approaches described, in order to ensure that clients with different
ways to configure the NAT64 prefix, obtain it. This is also convenient
even if DNS64 is being used.In general, DNS servers with DNS64 function, by default, 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, 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 is not present as the hosts will
not be able to use IPv4 (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, as the DNS64
recursive server will not synthesize AAAA responses, the client could
perform the DNSSEC validation with the A record and then may query the
network for a NAT64 prefix () in order to
synthesize the AAAA (). This allows the client
device to avoid using the CLAT and still use NAT64 even with DNSSEC.If the end-host is IPv4-only, this will not work if a CLAT is
not present (scenarios without 464XLAT).Some devices/OSs may implement, instead of CLAT, a similar 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, following the same approach
described in the precedent section (Stub validator). So, the DNS proxy
actually lie to the client devices, which in most of the cases will not
notice it unless they perform validation themselves. Again, this allow
the client devices to avoid using the CLAT and still use NAT64 with
DNSSEC.Once more, this will not work without a CLAT (scenarios without
464XLAT).In cases of dual-stack clients, stub resolvers should send the
AAAA queries before the A ones. So, such clients, if DNS64 is enabled,
will never get A records, even for IPv4-only servers, and they may be
in the path before the NAT64 and accessible by IPv4. If DNSSEC is being
used for all those flows, specific addresses or prefixes can be left-out
the DNS64 synthesis by means of ACLs.Once more, this will not work without a CLAT (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 (scenarios without
464XLAT).When a client device, using a name server configured to perform 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 to be considered regarding
DNS reverse mapping.In the case the client device is IPv6-only (either because the stack 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.However, when the client device is dual-stack and/or connected in a
dual-stack LAN by means of a CLAT (or has the built-in CLAT),
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 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, 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 ).When clients, in a service provider network, use DNS servers from
other networks, for example manually configured by users,
they may support or not DNS64, so the considerations in
will apply as well.Even in the case that the external DNS supports 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 and using an external DNS without DNS64,
ensures that everything will work, so the CLAT must be considered as
an advantage against user configuration errors.However, it needs to be reinforced, that if there is not a CLAT
(scenarios without 464XLAT), an external DNS without DNS64 support,
will not only guarantee that DNSSEC is broken, but also disallow any access to
IPv4-only networks, so will behave as in the . (IPv6 Addressing of IPv4/IPv6 Translators),
Section 3, 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 NAT64 to peers, however special considerations
related to BGP filtering are then required and IPv4-embedded
IPv6 prefixes longer than the WKP MUST NOT be advertised in BGP. An
NSP may be a more appropriate option in those cases.If several NAT64s use the same prefix, packets from the same
flow may be routed to different NAT64s in case of routing changes.
This can be avoided either by using different prefixes for each NAT64,
or by ensuring that all the NAT64s coordinate their state.
Using an NSP could facilitate that.If DNS64 is required and users may change their DNS configuration,
and deliberately choose an alternative DNS64, most probably alternative
DNS64 will use by default the WKP. If an NSP is used by the NAT64,
the users will not be able to use the operator NAT64.A hosts or application using literal IPv4 addresses or older APIs,
behind a network with IPv6-only access, will not work unless a
CLAT is present.A possible alternative approach is described as part of
Happy Eyeballs v2 Section 7.1 (), or if not
supporting HEv2, directly using Bump-in-the-Host (),
and then a DNS64 function.Those alternatives will solve the problem for and end-hosts,
however, if that end-hosts is providing "tethering" or an equivalent
service to others hosts, that need 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 for hosts behind it.Otherwise, 464XLAT is the only valid approach to resolve this issue.An IPv4-only hosts or application behind a network with IPv6-only access,
will not work unless a CLAT 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 can be configured with a dedicated /64 prefix
for the NAT46 translation, then it will be possible to do a more
efficient stateless translation.However, if this dedicated prefix is not available, the CLAT 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.The obvious recommended 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 () so, the CE can use a
/64 for that. 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 they don't use DHCPv6-PD
() an instead a single /64 is provided for
each PDP context and use /64 prefix sharing ().
So, in this case, the UEs typically have a build-in CLAT client,
which is doing a stateful NAT44 before the stateless NAT46.It can be argued that none of the possible transition mechanisms
is perfect, and somehow, we may consider that actually this is a good
thing as a way to push for the IPv6 deployment, or otherwise, it may
be further delayed, with clear undesirable effects for the global
Internet.However, for an operator, being in business means minimizing
the adverse transition effects, and provide the most perfect one
reasonably balanced with cost (CAPEX/OPEX), and at the same time
looking for a valid long-term vision.NAT64/464XLAT has demonstrated to be a valid choice in several
scenarios, with hundreds of millions of users, offering different
choices of deployment, depending on each network case, needs and
requirements.Depending on those requirements, DNS64 may be a required function,
while in other cases the adverse effects may be counterproductive.
Similarly, in some cases NAT64, together with DNS64, may be a
valid solution, when for sure there is no need to support hosts
or applications which are IPv4-only (,
). However, in other cases the
limitations they have, may suggest the operator to look
into 464XLAT as a more complete solution.Service providers willing to deploy NAT64, need to take into
account the considerations of this document in order to better
decide what is more appropriate for their own specific case.In the case of broadband managed networks (CE provided or
suggested/supported by the operator), in order to fully support
the actual user needs (IPv4-only devices and applications,
usage of literals and old APIs), they SHOULD consider the 464XLAT
scenario and in that case, MUST support the
customer-side translator (CLAT).If the operator offers DNS services, in order to increase performance
by reducing the double translation for all the IPv4 traffic,
they MAY support DNS64 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 de simpler and safer approach,
and MAY be combined as well with the other possible solutions 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
each operator, 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.The operator need to consider that if the user can modify the
DNS configuration (which most probably is impossible to avoid),
and instead of configuring a DNS64 choose an
external regular DNS (non-DNS64), an scenario with only NAT64 will
not work with any IPv4-only remote host, while it will continue
working in the case of 464XLAT ().Similar considerations need to be taked regarding the usage of
a NAT64 Well-Known vs Network-Specific Prefix (),
in the sense of, if using DNS64, they MUST match and if the user
can change the DNS config, they will, most probably, not.The ideal configuration for CEs supporting CLAT, is that they support
DHCPv6-PD () and 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.As indicated in Section 7 of (Deployment
Considerations), operators MAY follow those suggestions in order to
take advantage of traffic engineering.In the case of cellular networks, the considerations regarding DNSSEC
may appear as out-of-scope, because UEs OSs, commonly don't support
DNSSEC, however applications running on them may do, or it may be an
OS "built-in" support in the future. Moreover, if those devices offer
tethering, other client devices 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), in such way that the network is able to
automatically serve all the possible combinations of UEs.One last consideration is that many networks may have different
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 approaches described in this document
can be implemented at the same time for different customers or parts of
the network, so not representing any problem for complex cases.Finally, if the operator chooses to secure the NAT64 prefix,
it MUST follow the advice from Section 3.1.1. of
(Validation of Discovered Pref64::/n).The recommendations of this document can be used as well in
enterprise networks, campus and other similar scenarios,
when the NAT64 (and/or DNS64) are under the control of that network, 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 a NAT64 and DNS64 are provided, presenting in this case
the same issues as per . If there
is a CLAT 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 ones that are feasible.The following figure provides an example of and IPv6-only enterprise
network connected with dual-stack to Internet and using local NAT64 and DNS64.The following figure provides an example of dual-stack enterprise
network connected with dual-stack to Internet and using CLAT without DNS64.Finally, the following figure provides an example of an
IPv6-only provider with NAT64, and a dual-stack enterprise
network by means of their own CLAT without DNS64.This document does not have any new specific security considerations.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.The author would like to acknowledge the inputs of Gabor Lencse,
Andrew Sullivan, Lee Howard, Barbara Stark, Fred Baker and TBD ... 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 IPv4 inbound connections, several
mechanisms, depending on specific customer needs, allow that.Conceptually, most of the operator network could be IPv6-only
(represented in the next pictures as "IPv6-only Internet").
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 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, and the most common setup will be
those segments being dual-stack (global IPv6 addresses and
for IPv4, as usual in any regular residential/SOHO IPv4 network today).
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 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 DHCPv6 options).If the CLAT 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 .The operator network need to ensure that the correct responses are provided
for the discovery of the PLAT prefix, as well as it is highly recommended
follows , in order to ensure that multiple /64s
are available including the one needed for the NAT46 translation.The operator need to understand other issues, described across this document,
in order to take the relevant decisions. For example, if several NAT64 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 DNS64, then this
setup turns into the one in the following Figure. This will be also
the setup that, if the user has changed the DNS and consequently is
not using the operator DNS64, it will be seen from the perspective
of the CE.In this case the discovery of te PLAT prefix need to be arranged as
indicated in .In this case the CE doesn't have a built-in CLAT, or the customer can
choose to setup the IPv6 operator-managed CE in bridge mode (and optionally
use its own external router), or for example there is an access technology
that requires some kind of media converter (ONT for FTTH, CableModem
for DOCSIS, etc.), the complete setup will look as in the next figure.
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 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, so it is
suggested to use HNCP ().Note that the procedure described here for the CE setup, can be simplified
if the CE follows draft-ietf-v6ops-transition-ipv4aas ... TBD.TBD.A CLAT CE implementation basically requires support of
for the NAT46 functionality, for the PLAT prefix
discovery (and/or for PCP), and if stateless NAT46
is supported, mechanisms 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.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.Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012Let’s talk about IPv6 DNS64 & DNSSECAPNIC BlogBest Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non-persistent, and what size to choose RIPE