draft-ietf-v6ops-464xlat-optimization-02.txt   draft-ietf-v6ops-464xlat-optimization-03.txt 
v6ops J. Palet Martinez v6ops J. Palet Martinez
Internet-Draft The IPv6 Company Internet-Draft The IPv6 Company
Intended status: Informational A. D'Egidio Intended status: Informational A. D'Egidio
Expires: January 12, 2021 Telecentro Expires: January 29, 2021 Telecentro
July 11, 2020 July 28, 2020
464XLAT/NAT64 Optimization 464XLAT/MAT-T Optimization
draft-ietf-v6ops-464xlat-optimization-02 draft-ietf-v6ops-464xlat-optimization-03
Abstract Abstract
IP/ICMP Translation Algorithm (SIIT) can be used to provide access IP/ICMP Translation Algorithm (SIIT) can be used to provide access
for IPv4-only devices or applications to IPv4-only or dual-stack for IPv4-only hosts or applications to IPv4-only or dual-stack
destinations over IPv6-only infrastructure. In that case, the destinations over IPv6-only infrastructure. In that case, the
traffic flows are translated twice: first from IPv4 to IPv6 traffic flows are translated twice: first from IPv4 to IPv6
(stateless NAT46 at the ingress point to the IPv6-only (stateless NAT46 at the ingress point to the IPv6-only
infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
the egress point). When the destination is IPv6-enabled, the second the egress point). When the destination is IPv6-enabled, the second
translation might be avoided. This document describes a possible translation might be avoided. This document describes a possible
optimization to 464XLAT and MAP-T to avoid translating IPv6 flows optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
back to IPv4 if the destination is reachable over IPv6. The proposed back to IPv4 if the destination is reachable over IPv6. The proposed
solution would significantly reduce the NAT64 utilization in the solution would significantly reduce the NAT64 utilization in the
operator's network. operator's network, increasing the performance.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3 3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement Summary . . . . . . . . . . . . . . . . . . 5 4. Problem Statement Summary . . . . . . . . . . . . . . . . . . 6
5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7 5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 8
5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 7 5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 8
5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 8 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 9
5.2.1. Detection of IPv4-only hosts or applications . . . . 9 5.2.1. Optimization enabling . . . . . . . . . . . . . . . . 9
5.2.2. Detection of IPv6-enabled service . . . . . . . . . . 9 5.2.2. Detection of IPv4-only hosts . . . . . . . . . . . . 9
5.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 9 5.2.3. Detection of IPv6-enabled service . . . . . . . . . . 10
5.2.4. Forwarding path via stateful NAT for existing EAMT 5.2.4. CE DNS proxy responses . . . . . . . . . . . . . . . 10
entries . . . . . . . . . . . . . . . . . . . . . . . 11 5.2.5. Creation of EAMT entries . . . . . . . . . . . . . . 11
5.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 11 5.2.6. Forwarding path via stateful NAT for existing EAMT
5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 11 entries . . . . . . . . . . . . . . . . . . . . . . . 13
5.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 12 5.2.7. Maintenance of the EAMT entries . . . . . . . . . . . 13
5.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 12 5.2.8. Usage example . . . . . . . . . . . . . . . . . . . . 14
5.2.9. Behavior when using literal addresses or non 5.2.9. Behavior in case of multiple A/AAAA RRs . . . . . . . 14
IPv6-compliant APIs . . . . . . . . . . . . . . . . . 12 5.2.10. Behavior in presence/absence of DNS64 . . . . . . . . 14
5.2.10. Behavior in case of Foreign DNS . . . . . . . . . . . 12 5.2.11. Behavior when using literal addresses or non
5.2.11. False detection of a dual-stack host as IPv4-only . . 13 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 15
5.2.12. Behavior in presence of Happy Eyeballs . . . . . . . 14 5.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 15
5.2.13. Troubleshooting Implications . . . . . . . . . . . . 16 5.2.13. False detection of a dual-stack host as IPv4-only . . 16
5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 16 5.2.14. Behavior in presence of Happy Eyeballs . . . . . . . 16
5.2.15. Troubleshooting Implications . . . . . . . . . . . . 18
5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 18
6. IPv6-only Services become accessible to IPv4-only 6. IPv6-only Services become accessible to IPv4-only
devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 17 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Different transition mechanisms, typically in the group of the so- Different transition mechanisms, typically in the group of the so-
called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT called IPv6-only with IPv4aaS (IPv4-as-a-Service), such as 464XLAT
([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only devices or ([RFC6877]) or MAP-T ([RFC7599]), allow IPv4-only hosts or
applications to connect with IPv4 services in Internet over IPv6-only applications to connect with IPv4 services in Internet over IPv6-only
infrastructure, by means of a stateless NAT46 SIIT (IP/ICMP infrastructure, by means of a stateless NAT46 SIIT (IP/ICMP
Translation Algorithm) as described by [RFC7915]. Translation Algorithm) as described by [RFC7915].
This is done by the implementation of SIIT at the CE (Customer Edge) This is done by the implementation of SIIT at the CE (Customer Edge)
Router or sometimes at the end-device, for example, the UE (User Router or sometimes at the end-device, for example, the UE (User
Equipment) in cellular networks. This functionality is the CLAT Equipment) in cellular networks. This functionality is the CLAT
(Customer Translator) in the case of 464XLAT, while in the case of (Customer Translator) in the case of 464XLAT, while in the case of
MAP-T is called NAT46. MAP-T is called NAT46.
skipping to change at page 3, line 37 skipping to change at page 3, line 37
headers is done using the IP/ICMP translation algorithm defined in headers is done using the IP/ICMP translation algorithm defined in
[RFC7915]. Translation between IPv4 and IPv6 addresses is done as [RFC7915]. Translation between IPv4 and IPv6 addresses is done as
per [RFC6052]. The NAT64 prefix should be discovered by the CE by per [RFC6052]. The NAT64 prefix should be discovered by the CE by
one or more of the existing mechanisms ([RFC7225], [RFC8781] or one or more of the existing mechanisms ([RFC7225], [RFC8781] or
[RFC7050]), and sometimes it is pre-configured at the CE to the WKP. [RFC7050]), and sometimes it is pre-configured at the CE to the WKP.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Possible Optimization 3. Possible Optimization
In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge In the case of 464XLAT, a DNS64 ([RFC6147]) is (optionally) in charge
of the synthesis of AAAA records from the A records, so the NAT64 can of the synthesis of AAAA records from the A records, so the NAT64 can
be used without the need of doing a double-translation by means of be used without the need of doing a double-translation by means of
the NAT46/CLAT. the NAT46/CLAT.
However, the DNS64 is not useful for the IPv4-only devices or However, the DNS64 is not useful for the IPv4-only hosts or
applications in the LANs, as they will not be able to use the AAAA applications in the LANs, as they will not be able to use the AAAA
records, so they are always forced to use the double-translation. records, so they are always forced to use the double-translation.
This is the expected behavior, as the original design of NAT64 was This is the expected behavior, as the original design of NAT64 was
targeted to connect IPv6-only devices (using DNS) to IPv4-only targeted to connect IPv6-only devices (using DNS) to IPv4-only
services. 464XLAT expanded the solution to also allow IPv4-only services. 464XLAT expanded the solution to also allow IPv4-only
devices (even if not using DNS) to connect to IPv4-only services by devices (even if not using DNS) to connect to IPv4-only services by
means of IPv6-only access networks. means of IPv6-only access networks.
The optimization solutions presented by this document try to avoid The optimization solutions presented by this document try to avoid
skipping to change at page 4, line 39 skipping to change at page 4, line 39
`-----' `-----'
Figure 1: Typical 464XLAT Deployment Figure 1: Typical 464XLAT Deployment
Examples of a topology shown on the above picture includes: Examples of a topology shown on the above picture includes:
o An IPv6-only residential access network where the CE Router (with o An IPv6-only residential access network where the CE Router (with
NAT46/CLAT) supports Dual-Stack in the customer LANs. NAT46/CLAT) supports Dual-Stack in the customer LANs.
o An IPv6-only cellular network where a UE uses the NAT46/CLAT for o An IPv6-only cellular network where a UE uses the NAT46/CLAT for
dual-stack internal applications and other devices connected via dual-stack internal applications and other hosts connected via
tethering. tethering.
If the operator is providing direct access, for example, to Content If the operator is providing direct access, for example, to Content
Delivery Networks (CDNs), caches, or other resources, and they are Delivery Networks (CDNs), caches, or other resources, and they are
dual-stacked, the situation can be described as shown in Figure 2. dual-stacked, the situation can be described as shown in Figure 2.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| IPv6 | / \ / \ | IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \ .-----. | CE | / IPv6- \ .-----. / IPv4 \
/ \ | or +--( only )---( NAT64 )---( Internet ) / \ | or +--( only )---( NAT64 )---( Internet )
skipping to change at page 5, line 24 skipping to change at page 5, line 24
| | | DNS/ | ( Internet ) / Dual- \ | | | DNS/ | ( Internet ) / Dual- \
+-------+ | DNS64 | \ /----/ Stack \ +-------+ | DNS64 | \ /----/ Stack \
+--------+ \ / ( ) +--------+ \ / ( )
`-----' \ CDNs/ / `-----' \ CDNs/ /
\ Caches/ \ Caches/
`-----' `-----'
Figure 2: Typical 464XLAT Deployment with CDNs/Caches Figure 2: Typical 464XLAT Deployment with CDNs/Caches
In this case if the flows initiated in the LANs come from IPv4-only In this case if the flows initiated in the LANs come from IPv4-only
devices or applications, even if the destination resources are hosts or applications, even if the destination resources are
IPv6-enabled, the double-translation is enforced, which has the IPv6-enabled, the double-translation is enforced, which has the
following consequences: following consequences:
o More traffic needs to pass thru the NAT64 devices. o More traffic needs to pass thru the NAT64 devices.
o More NAT64 devices may be needed to handle the additional traffic. o More NAT64 devices may be needed to handle the additional traffic.
o Additional usage of IPv4 addresses. o Additional usage of IPv4 addresses.
o Additional state at the NAT64 devices. o Additional state at the NAT64 devices.
o Additional logging, its relevant storage and processing resources. o Additional logging, its relevant storage and processing resources.
o Increasing of delay and redduction of traffic performance.
o Unnecessary point(s) of failure for that traffic.
Clearly, all those aspects have impact in both, CapEx and OpEx. This Clearly, all those aspects have impact in both, CapEx and OpEx. This
is extremely important when considering that most of the time, the is extremely important when considering that most of the time, the
contents stored in CDNs, caches, and so on, is there for a good contents stored in CDNs, caches, and so on, is there for a good
reason: It is frequently accessed resources and/or big. Examples reason: It is frequently accessed resources and/or big. Examples
such as video, audio, software and updates, are very common. So, such as video, audio, software and updates, are very common. So,
this optimization can be highly impacting in many networks. this optimization can be highly impacting in many networks.
4. Problem Statement Summary 4. Problem Statement Summary
If the devices or applications in the customer LAN are IPv6-capable, If the hosts or applications in the customer LAN are IPv6-capable,
then the access to the CDNs, caches or other resources, will be made then the access to the CDNs, caches or other resources, will be made
in an optimized way, by means of IPv6-only, not using the NAT64, as in an optimized way, by means of IPv6-only, not using the NAT64, as
depicted in Figure 3. depicted in Figure 3.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| IPv6 | / \ / \ | IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \ .-----. | CE | / IPv6- \ .-----. / IPv4 \
/ \ | or +--( only )---( NAT64 )---( Internet ) / \ | or +--( only )---( NAT64 )---( Internet )
/ IPv6 \ | UE | \ Access /\ `-----' \ / / IPv6 \ | UE | \ Access /\ `-----' \ /
( capable )--+ | \ / \ \ / ( capable )--+ | \ / \ \ /
skipping to change at page 6, line 24 skipping to change at page 6, line 31
| | | DNS/ | ( Internet )IPv6/ Dual- \ | | | DNS/ | ( Internet )IPv6/ Dual- \
+-------+ | DNS64 | \ /----/ Stack \ +-------+ | DNS64 | \ /----/ Stack \
+--------+ \ / ( ) +--------+ \ / ( )
`-----' \ CDNs/ / `-----' \ CDNs/ /
\ Caches/ \ Caches/
`-----' `-----'
<---------------------- end-to-end IPv6 flow ----------------------> <---------------------- end-to-end IPv6 flow ---------------------->
Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps Figure 3: 464XLAT access to CDNs/Caches by IPv6-capable apps
However, if the devices or applications are IPv4-only, for example, However, if the hosts or applications are IPv4-only, for example,
many SmartTVs and Set-Top-Boxes available today, a non-optimal double many SmartTVs and Set-Top-Boxes available today, a non-optimal double
translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as translation will occur (NAT46 at the CLAT and NAT64 at the PLAT), as
illustrated in Figure 4. illustrated in Figure 4.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| IPv6 | / \ / \ | IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \ .-----. | CE | / IPv6- \ .-----. / IPv4 \
/ IPv4- \ | or +--( only )---( NAT64 )---( Internet ) / IPv4- \ | or +--( only )---( NAT64 )---( Internet )
/ only \ | UE | \ Access /\ `-----' \ / / only \ | UE | \ Access /\ `-----' \ /
( SmartTV )--+ | \ / \ \ / ( SmartTV )--+ | \ / \ \ /
skipping to change at page 8, line 48 skipping to change at page 9, line 27
If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/ If the NAT46/CLAT/CE, as commonly is the case, is also a DNS proxy/
stub resolver, it is possible to modify the behavior and create an stub resolver, it is possible to modify the behavior and create an
"internal" interaction among both of them. "internal" interaction among both of them.
This approach uses the existing IPv4 and IPv6 addresses in the A and This approach uses the existing IPv4 and IPv6 addresses in the A and
AAAA records, respectively, so no additional complexity/issues added AAAA records, respectively, so no additional complexity/issues added
to the CDN/caches operations. to the CDN/caches operations.
The following sub-sections detail this approach and provide a step- The following sub-sections detail this approach and provide a step-
by-step example case. Note that this optimization MUST NOT be by-step example case.
enabled when the WAN link is IPv4-only or dual-stack. In other
words, only can be enabled if the WAN link is IPv6-only and
consequently, the NAT46/CLAT is enabled in the CE.
5.2.1. Detection of IPv4-only hosts or applications 5.2.1. Optimization enabling
The assumption is that, typically a dual-stack host will prefer using This optimization MUST be enabled by default, but only when the WAN
IPv6 as the DNS transport. So, when there is a DNS query, link is IPv6-only and the NAT46/CLAT is being used. This allows the
transported with IPv4, for an A record, and there is not a query for users to get CEs from the retail and take advantage of the
the AAAA record from the same IPv4 source (to the same destination), optimization, without requiring any configuration.
the DNS proxy/stub resolver can infer that, most probably, it is an
IPv4-only device or application.
It needs to be remarked that, if the detection of the IPv4-only The CE MUST support a way to completely disable the optimization, in
device or application is done incorrectly (either not detecting it or order to allow the operator to turn it off in case it is required.
by a false detection), no harm is caused. In the worst case,
optimization will not be performed, at least, at the time being.
However, optimization maybe performed later on, if a new detection
succeeds (for example, another device using the same A record).
5.2.2. Detection of IPv6-enabled service It is expected that the NAT64/CLAT is only enabled if the WAN link is
IPv6-only.
In the case of an IPv4-only detected device or application, the DNS 5.2.2. Detection of IPv4-only hosts
proxy/stub resolver MUST actually perform an additional AAAA query,
unless the information is already present in the Additional Section,
as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already
know the WKP or NSP being used in that network. If the response
contains at least one IPv6 address not using the WKP/NSP, it means
that the destination is IPv6-enabled (because at least one of the
IPv6 addresses is not synthesized). This means that it is possible
for the NAT46/CLAT, to create an Explicit Address Mapping
([RFC7757]).
5.2.3. Creation of EAMT entries The goal is to ensure that only IPv4-only hosts are optimized.
Towards that, the CE MUST use ARP and ND (and their relevant caches,
if the information of a hosts has been already learnt) each time a
new host starts a connection. If it is possible to bind the same MAC
address to both an IPv4 and IPv6 address, then the host is not
IPv4-only (it may be IPv6-only or dual-stack), and MUST NOT be
optimized.
This way, an EAM Table (EAMT used for short, across the rest of this The CE MUST maintain a table of IPv4-only hosts and ensure that if
document) is created/maintained automatically by the DNS proxy/stub any IPv4-only hosts become IPv6-enabled, it is properly handled.
resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to
prioritize any available entries in the EAMT, versus the use of any
synthetic AAAA.
In order to create the EAMT entry, to determine if there is an AAAA This mechanism to detect IPv4-only hosts has two drawbacks:
record after an A record query, it is suggested to use the same delay
value (50 milliseconds) as the "Resolution Delay" indicated by Happy 1. If a subscriber has intermediate dual-stack routers in between
Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping the IPv4-only host and the NAT46/CLAT, the IPv4-only hosts will
between destination addresses (IPv4/IPv6), which may impact some be detected as dual-stack, so no optimization will be performed.
applications, at the cost of a small extra delay for the initial This is not the most common scenario, as typically the devices
communication setup, when the EAMT entry doesn't yet exist. that are more relevant to the optimization (in terms of those
that generate more IPv4-only traffic) are directly attached to
the CE, or in bridged interfaces.
2. If a host is dual-stack, but has some IPv4-only applications,
because the host will be detected as dual-stack, none of the
applications will be optimized. This is a good trade-off,
considering the most important traffic to optimize is typically
coming from real IPv4-only devices such as old SmartTVs/STBs.
Furthermore, this avoid breaking other mechanisms present only in
dual-stack hosts, such as Happy Eyeballs [RFC8305] and simplifies
troubleshooting.
It needs to be remarked that, if the detection of the IPv4-only host
is done incorrectly (either not detecting it or by a false
detection), the goal is that no harm is caused. In the worst case,
optimization MUST NOT be performed.
5.2.3. Detection of IPv6-enabled service
In the case of an IPv4-only detected host, the DNS proxy/stub
resolver MUST actually perform an additional AAAA query, unless the
information is already present in the Additional Section, as per
Section 3 of [RFC3596].
Note that the NAT46/CLAT MUST already know the WKP or NSP being used
in that network. If the response contains at least one IPv6 address
not using the WKP/NSP, it means that the destination is IPv6-enabled
(because at least one of the IPv6 addresses is not synthesized).
This means that it is possible for the NAT46/CLAT, to create an
Explicit Address Mapping ([RFC7757]).
5.2.4. CE DNS proxy responses
In the case of an IPv4-only detected host, the CE DNS proxy MUST only
return the answer to an A query once any of the following happens:
1. An answer to the AAAA query has been received.
2. A SERVFAIL has been received.
3. The "Resolution Delay" has passed.
The Resolution Delay MUST be set to the same value (50 milliseconds)
as indicated by Happy Eyeballs [RFC8305].
5.2.5. Creation of EAMT entries
An EAM Table (EAMT used for short, across the rest of this document)
MUST be created/maintained automatically by the NAT46/CLAT, which is
responsible to prioritize any available entries in the EAMT, versus
the use of any synthetic AAAA.
The EAMT entry MUST only be created if all the following conditions
are met:
1. The source host is IPv4-only.
2. The DNS proxy is ready to return the A answer (according to
Section 5.2.4).
3. There is at least one non-synthesized AAAA response.
4. If DNSSEC is available, the response has been locally validated
or the AD bit has been set by a trusted resolver, as per
[RFC3655].
This avoids a slight NAT64 overload and flapping between destination
addresses (IPv4/IPv6), which may impact some applications, at the
cost of a small extra delay for the initial communication setup, when
the EAMT entry doesn't yet exist.
Each EAMT entry MUST contain, the fields already described in Each EAMT entry MUST contain, the fields already described in
[RFC7757] and a few new ones: [RFC7757] and a few new extensions (as per section 3.1 of [RFC7757]):
1. ID: EAMT Entry Index (optional). 1. ID: EAMT Entry Index (optional).
2. IPv4 address/prefix: By default, the prefix length is 32 bits. 2. MAC address: Identify the host to which this EAMT entry belongs.
3. IPv6 address/prefix: By default, the prefix length is 128 bits. 3. Destination IPv4 address/prefix: By default, the prefix length is
32 bits.
4. TTL: Because the optimization will make use of the AAAA (IPv6 4. Destination IPv6 address/prefix: By default, the prefix length is
address), the TTL for the EAMT entry MUST be set to the same 128 bits. Only non-synthesized addresses are allowed.
value as in the AAAA RR. In normal conditions the TTL for both A
and AAAA records, of a given FQDN, should be the same, so this
ensures a proper behavior if there is any DNS mismatch.
5. FQDN: The one that originated the A query for this EAMT entry. 5. TTL: It MUST be set to the minimum value from the AAAA/A RR pair.
In normal conditions the TTL for both A and AAAA records, of a
given FQDN, should be the same, so this ensures a proper behavior
if there is any DNS mismatch.
6. FQDN: The one that originated the A query for this EAMT entry.
Required in order to ensure a correct detection of cases such as Required in order to ensure a correct detection of cases such as
the use of reverse-proxy with a single IPv4 address to multiple the use of reverse-proxy with a single IPv4 address to multiple
IPv6 addresses. IPv6 addresses.
6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT 7. Valid/Stale/Invalid: When set to Stale, means that this EAMT
be used and consequently no optimization performed. It may be entry MUST NOT be used for new connections. When set to Invalid,
used also for an explicit configuration (GUI, CLI, provisioning means that this EAMT entry can be deleted, unless the Auto/Static
system, etc.) to disallow optimization for explicitly configured bit is also set.
IPv4 addresses.
7. Auto/Static: When set to 1, means that this EAMT entry has been 8. Auto/Static: When set to 1, means that this EAMT entry has been
manually/statically configured, for example by means of an manually/statically configured, for example by means of an
explicit configuration (GUI, CLI, provisioning system, etc.), so explicit configuration (GUI, CLI, provisioning system, etc.).
it doesn't expire with TTL.
When a new EAMT entry is first automatically created, it is marked as Note that allowing destination IPv4 and IPv6 prefixes, together with
"Valid" and "Auto" (both bits cleared). If a subsequent A query, the Valid/Stale/Invalid and Auto/Static flags, allows manual explicit
with a different FQDN, results in an IPv4 address that has already an optimization and non-optimization configuration for specific parts of
EAMT entry and a different IPv6 address, it means that some reverse- Internet.
proxy or similar functionality is being used by the IPv6-enabled
service. In this case, the existing EAMT entry will be marked as
"Invalid" (bit set). No new EAMT entry is created for that IPv4
address. Otherwise, the optimization will only allow to access the
first set of IPv4/IPv6/FQDN, which may break the access to other FQDN
that share the same IPv4 address and different IPv6 addresses.
In this case the EAMT entry will still expire according the TTL, When a new EAMT entry is first automatically created, it is flagged
which allows to re-enable optimization if a new query for the A as "Valid" and "Auto". If a subsequent A query, with a different
FQDN, results in an IPv4 address that has already an EAMT entry and a
different IPv6 address, it means that some reverse-proxy or similar
functionality is being used by the IPv6-enabled service. In this
case, the existing EAMT entry will be marked as "Stale". No new EAMT
entry is created for that IPv4 address. Otherwise, the optimization
will only allow to access the first set of IPv4/IPv6/FQDN, which may
break the access to other FQDN that share the same IPv4 address and
different IPv6 addresses.
In this case the EAMT entry will still become "Invalid" according the
TTL, which allows to re-enable optimization if a new query for the A
record has changed the situation. For example, maybe the reverse- record has changed the situation. For example, maybe the reverse-
proxy has been removed, or there is now only a single device using proxy has been removed, or there is now only a single device using
it, so at the time being, the optimization is again possible without it, so at the time being, the optimization is again possible without
creating troubles to other hosts. creating troubles to other hosts.
Note that when an EAMT entry is marked as "invalid", it will not An EAMT entry marked as "Stale" or "Invalid", only affects the
affect the devices or applications, as they will still be able to use relevant host. Other hosts have their own EAMT entries or they are
the regular CLAT+NAT64 flow, of course, without the optimization. using the regular NAT46/CLAT+NAT64 path (without the optimization).
Note the newly defined EAMT fields, follow the "extensions" approach
as per section 3.1 of [RFC7757].
5.2.4. Forwarding path via stateful NAT for existing EAMT entries 5.2.6. Forwarding path via stateful NAT for existing EAMT entries
Following this approach, if there is a valid EAMT entry, for a given Following this approach, if there is a valid EAMT entry, for a given
IPv4-destination, the IPv6-native path pointed by the IPv6 address of pair of source-MAC-address/IPv4-destination, the IPv6-native path
that EAMT entry, will take precedence versus the NAT64 path, so the pointed by the IPv6 address of that EAMT entry, will take precedence
traffic will not be forwarded to the NAT64. versus the NAT64 path, so the traffic will not be forwarded to the
NAT64.
However, this is not sufficient to ensure that individual However, this is not sufficient to ensure that individual
applications are able to keep existing connections. In many cases, applications are able to keep existing connections. In many cases,
audio and video streaming may use a single TCP connection lasting audio and video streaming may use a single TCP connection lasting
from minutes to hours. Instead, the CDN TTLs may be configured in from minutes to hours. Instead, the CDN TTLs may be configured in
the range from 10 to 300 seconds in order to allow new resolutions to the range from 10 to 300 seconds in order to allow new resolutions to
switch quickly and to handle large recursive resolvers (with hundreds switch quickly and to handle large recursive resolvers (with hundreds
of thousands of clients behind them). of thousands of clients behind them).
Consequently, the EAMT entries should not be used directly to Consequently, the EAMT entries MUST NOT be used directly to establish
establish a forwarding path, but instead, to create a stateful NAT a forwarding path, but instead, MUST be used to create a stateful NAT
entry for the 4-tuple for the duration of the session/connection. entry for the 4-tuple for the duration of the session/connection.
This means that to implement the optimization the NAT46 MUST be
stateful. Typically, stateful NAT46 are implemented by means of a
stateful NAT44 (which often maybe hardware off-loaded), followed by a
stateless NAT46. If the SoC/code is able to do stateless NAT46, this
still could be used when the optimization is disabled.
5.2.5. Maintenance of the EAMT entries 5.2.7. Maintenance of the EAMT entries
The information in the EAMT MUST be kept timely-synchronized with the An EATM entry with the Auto/Static bit set, MUST NOT be automatically
AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL modified.
expiry and consequently be deleted.
However, EAMT entries with the Auto/Static bit set, will not be An EAMT entry with the Auto/Static bit clear, MUST be set to Stale in
deleted. This allows users/operators to set explicit rules for case of:
1. TTL time-out.
2. Or the conditions for creation of the EAMT entry (Section 5.2.5)
aren't longer met.
Entries in Stale state MUST be set to Invalid once existing
connections time-out.
The Invalid EAMT entries MUST be deleted, unless the Auto/Static bit
is set. This allows users/operators to set explicit rules for
diagnostics or resolution of issues in special situations. diagnostics or resolution of issues in special situations.
5.2.6. Usage example 5.2.8. Usage example
Using the same example as in the previous approach: Using the same example as in the previous approach:
www.example.com A 192.0.2.1 www.example.com A 192.0.2.1
AAAA 2001:db8::a:b:c:d AAAA 2001:db8::a:b:c:d
EAMT entry 192.0.2.1 2001:db8::a:b:c:d EAMT entry 192.0.2.1 2001:db8::a:b:c:d
NAT46/CLAT translated to 2001:db8::a:b:c:d NAT46/CLAT translated to 2001:db8::a:b:c:d
CDN IPv6 interface already is 2001:db8::a:b:c:d CDN IPv6 interface already is 2001:db8::a:b:c:d
Operator already has a specific route to 2001:db8::a:b:c:d Operator already has a specific route to 2001:db8::a:b:c:d
The following is an example of the CE behavior after the previous The following is an example of the CE behavior after the previous
case has already created an EAMT entry and a reverse-proxy is case has already created an EAMT entry and a reverse-proxy is
detected: detected:
1. A query for www.another-example.com A RR is received 1. A query for www.example.net A RR is received
2. www.another-example.com A 192.0.2.1 2. www.example.net A 192.0.2.1
3. www.another-example.com AAAA 2001:db8::e:e:f:f 3. www.example.net AAAA 2001:db8::e:e:f:f
4. A conflict has been detected 4. A conflict has been detected
5. The existing EAMT entry for 192.0.2.1 is set as invalid 5. The existing EAMT entry for 192.0.2.1 is set to Stale
5.2.7. Behavior in case of multiple A/AAAA RRs 5.2.9. Behavior in case of multiple A/AAAA RRs
If multiple A/AAAA RRs are available, any of them could be chosen and
in general, the optimization will not present any different result to
the hosts compared with a situation where the optimization is not
used.
Existing DNS proxy/stub resolvers already implement mechanisms for Existing DNS proxy/stub resolvers already implement mechanisms for
DNS Load Balancing ([RFC1794]). This should not be modified to DNS Load Balancing ([RFC1794]). This don't need to be modified to
implement the optimization so, if multiple A and/or AAAA records are implement the optimization if some degree of randomness is already
available, any of them could be chosen. In other words, the chosen secured.
pair of A/AAAA records doesn't present any different result compared
with a situation when this mechanism is not used.
5.2.8. Behavior in presence/absence of DNS64 To secure sufficient randomness, a possible algorithm shall ensure
that different EAMT entries (for different hosts) are permuted
randomly among different A/AAAA records on the A/AAAA RR set.
5.2.10. Behavior in presence/absence of DNS64
464XLAT can be deployed/used with and without a DNS64. However, as 464XLAT can be deployed/used with and without a DNS64. However, as
indicated in Section 5.2.2, the EAMT entry is only created when the indicated in Section 5.2.3, the EAMT entry is only created when the
service is IPv6-enabled, because the optimization is only relevant service is IPv6-enabled, because the optimization is only relevant
for destinations which already have AAAA records. In those cases for destinations which already have AAAA records. In those cases
DNS64 is not relevant. DNS64 is not relevant.
5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs 5.2.11. Behavior when using literal addresses or non IPv6-compliant
APIs
Because the EAMT entries are only created when the NAT46/CLAT/CE Because the EAMT entries are only created when the NAT46/CLAT/CE
proxy/stub DNS is being used, any devices or applications that don't proxy/stub DNS is being used, any hosts or applications that don't
use DNS, will not create the relevant entries. use DNS, will not create the relevant entries.
They may be optimized if devices or applications using DNS, at some They will not be optimized unless EAMT entries are statically
point, query for the same A RRs, or if EAMT entries are statically
configured. configured.
5.2.10. Behavior in case of Foreign DNS 5.2.12. Behavior in case of Foreign DNS
Devices or applications may use DNS servers from other networks. For Hosts or applications may use DNS servers from other networks. For a
a complete description of reasons for that, refer to Section 4.4 of complete description of reasons for that, refer to Section 4.4 of
[RFC8683]. In the case the DNS is modified, or some devices or [RFC8683]. In the case the DNS is modified, or some hosts or
applications use other DNS servers, the possible scenarios and the applications use other DNS servers, the possible scenarios and the
implications are: implications are:
a. Devices configured to use a DNS proxy/resolver which is not the a. Devices configured to use a DNS proxy/resolver which is not the
CE/NAT46/CLAT. In this case this optimization will not work, CE/NAT46/CLAT. In this case this optimization will not work,
because the EAMT entry will not be created based on their own because the EAMT entry will not be created based on their own
flows. Nevertheless, the EAMT entry may be created by other flows. Nevertheless, the EAMT entry may be manually created.
devices using the same destinations. However, the lack of EAMT However, the lack of EAMT entry, will not impact negatively in
entry, will not impact negatively in the user's devices/ the user's hosts/applications (the optimization is not
applications (the optimization is not performed). It should be performed). It should be noticed that users commonly, don't
noticed that users commonly, don't change the configuration of change the configuration of devices such as SmartTVs or STBs (if
devices such as SmartTVs or STBs (if they do, some other they do, some other functionalities, such as CDN/caches
functionalities, such as CDN/caches optimizations may not work as optimizations may not work as well), so this only happens
well), so this only happens typically if the vendor is doing it typically if the vendor is doing it on-purpose and for good well-
on-purpose and for good well-known reasons. known reasons.
b. DNS privacy/encryption. Hosts or applications that use b. DNS privacy/encryption. Hosts or applications that use
mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], mechanisms for DNS privacy/encryption, such as DoT ([RFC7858],
[RFC8094]), DoH ([RFC8484]) or DoQ [RFC8094]), DoH ([RFC8484]) or DoQ
([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/ ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/
proxy resolver, so the same considerations as for the previous proxy resolver, so the same considerations as for the previous
case applies. case applies.
c. Users that modify the DNS in their Operating Systems. This is c. Users that modify the DNS in their Operating Systems. This is
quite frequent, however commonly Operating Systems are dual- quite frequent, however commonly Operating Systems are dual-
skipping to change at page 13, line 35 skipping to change at page 16, line 8
d. Users that modify the DNS in the CE. This is less common. In d. Users that modify the DNS in the CE. This is less common. In
this case, this optimization is not adversely affected, because this case, this optimization is not adversely affected, because
it doesn't depend on the operator DNS, it works only based on the it doesn't depend on the operator DNS, it works only based on the
internal CE interaction between the NAT46/CLAT and the stub/proxy internal CE interaction between the NAT46/CLAT and the stub/proxy
resolver. Note that it may be affected if the operator offers resolver. Note that it may be affected if the operator offers
different "DNS views" or "split DNS", however this is not related different "DNS views" or "split DNS", however this is not related
to this optimization and will anyway impact in the other possible to this optimization and will anyway impact in the other possible
operator optimizations (i.e. CDN/cache features). operator optimizations (i.e. CDN/cache features).
e. Combinations of the above ones. No further impact, than the one e. Combinations of the above ones. No further impact is observed,
already described, is observed. beyond the ones already described.
5.2.11. False detection of a dual-stack host as IPv4-only 5.2.13. False detection of a dual-stack host as IPv4-only
If a dual-stack host is issuing the A query using IPv4 transport, and If a dual-stack host is being detected as IPv4-only, is because it is
the AAAA query using IPv6 transport, or in the other way around, or not responding to the CE ND messages, so by all means, should be
using different IPv4 addresses for the A and AAAA queries, the EAMT considered, at the time being, as IPv4-only, and consequently EAMT
entry will be created. However, this EAMT entry may not be used by entries will be created and traffic will be optimized for IPv4 flows.
dual-stack devices or applications, because those devices or
applications should prefer IPv6. If the host is preferring IPv4 for However, if this hosts suddenly become IPv6-enabled (or dual-stack),
connecting to the CDN/cache or IPv6-enabled service, it will be the relevant EAMT entries must be flagged by the CE as "Stale". The
host will be able to complete the connections and the entries will be
marked as "Invalid" and deleted.
Anyway, those EAMT entries, while "Valid", may not be actually used
by the dual-stack hosts, because those hosts or applications should
prefer IPv6, so most probably was either a temporary failure or done
on-purpose (user, troubleshooting). If the host is preferring IPv4
for connecting to the CDN/cache or IPv6-enabled service, it will be
actually using the NAT46/CLAT, including the EAMT entry and actually using the NAT46/CLAT, including the EAMT entry and
consequently IPv6, so this mechanism will be correcting an consequently IPv6, so this mechanism will be correcting an
undesirable behavior. This is a special case, which actually seems undesirable behavior. This may be also a special case, which
to be an incoherent host or application implementation. actually seems to be an incoherent host or application
implementation.
Afterwards, if other IPv4-only devices or applications subsequently
need to connect to the same IPv6-enabled service, they will take
advantage of the already existing EAMT entry, and consequently use
the IPv6-optimised path.
5.2.12. Behavior in presence of Happy Eyeballs 5.2.14. Behavior in presence of Happy Eyeballs
Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts. Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts.
Consequently, it is not affected by this optimization because both, Consequently, it is not affected by this optimization because both,
the A and the AAAA queries should be issued by the host as soon after as the host should not be detected as IPv4-only, following
one another as possible. In summary, the host should not be detected Section 5.2.2.
as IPv4-only, following Section 5.2.1.
Nevertheless, if the same NAT46/CLAT/CE is serving IPv4-only hosts
and dual-stack hosts and both of them are using the same
destinations, an EAMT entry may have been previously created for that
destination. Consequently, if Happy Eyeballs triggers a fallback to
IPv4, it will be actually using the relevant EAMT entry towards the
IPv6 destination. This has the disadvantage that the IPv4-IPv6-IPv4
translation path can't be used by Happy Eyeballs-enabled
applications, so avoiding a real IPv4-fallback and making IPv6 the
only available protocol.
This is the natural and expected path for IPv6-only networks, so
actually it may be considered as a good thing, in the sense that an
operator is interested in knowing as soon as possible, if the
IPv6-only network is not performing correctly.
Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is If Happy Eyeballs triggers a fallback to IPv4 for a given host, it
IPv6-only. So even if Happy Eyeballs is present, IPv4 is expected to will be actually using IPv4 without the optimization, which in turn,
be slower than native IPv6 itself due to delays added by the uses the IPv6-only WAN link of the NAT46/CLAT/CE. So even if Happy
NAT46+NAT64 translations. This optimization reduces those delays by Eyeballs is present, IPv4 is expected to be slower than native IPv6
eliminating the second translation (NAT64). itself due to delays added by the NAT46/CLAT+NAT64 translations.
This optimization reduces those delays by eliminating the second
translation (NAT64) for IPv4-only detected hosts.
However, there may be cases where this may be understood as However, there may be cases where this may be understood as
problematic. The possible reasons why Happy Eyeballs may trigger an problematic. The possible reasons why Happy Eyeballs may trigger an
IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS, IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS,
in general, can be classified as: in general, can be classified as:
1. Failure at the CE or customer LANs. It may happen that the CE or 1. Failure at the CE or customer LANs. It may happen that the CE or
other devices in the customer LANs are showing erratic behaviors other devices in the customer LANs are showing erratic behaviors
or malfunctions. It is difficult to believe that this happens or malfunctions. It is difficult to believe that this happens
only with IPv6, and if that's the case Happy Eyeballs will not only with IPv6, and if that's the case Happy Eyeballs will not
skipping to change at page 15, line 19 skipping to change at page 17, line 30
operator's NAT64 towards the destination. In this case, operator's NAT64 towards the destination. In this case,
typically both, IPv4 and IPv6 will fail (in many cases, they are typically both, IPv4 and IPv6 will fail (in many cases, they are
dual-stack links, not different links). Again, Happy Eyeballs dual-stack links, not different links). Again, Happy Eyeballs
will also fail to resolve the issue. will also fail to resolve the issue.
4. Complete failure only in the IPv6 links behind the operator's 4. Complete failure only in the IPv6 links behind the operator's
NAT64 towards the destination. This is less frequent, bus still NAT64 towards the destination. This is less frequent, bus still
miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6 miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6
together with outages or IPv6-only routing issues, could generate together with outages or IPv6-only routing issues, could generate
this problem. In this case, Happy Eyeballs could resolve the this problem. In this case, Happy Eyeballs could resolve the
issue, however, the optimization will disallow it. issue, however. It will work because the optimization is not
enabled for dual-stack hosts.
5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In 5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In
general, the added delay of the IPv4 translations and NAT across general, the added delay of the IPv4 translations and NATs across
the path, increases the chances that IPv4 is faster than IPv6. the path, increases the chances that IPv4 is slower than IPv6.
However, it may happen that there is some IPv6 specific link However, it may happen that there is some IPv6 specific link
congestion or packet dropping, that generates the reverse congestion or packet dropping, that generates the reverse
situation, so IPv4 becomes faster than IPv6. Because the situation, so IPv4 become faster than IPv6. Because the
optimization, the end-to-end path is forced to be IPv6, so Happy optimization is not being used for dual-stack hosts, Happy
Eyeballs will not be able to offer any significative advantage in Eyeballs will be resolving the issue.
resolving the issue.
In summary, the optimization may be hindering the Happy Eyeballs In summary, the optimization will not change the Happy Eyeballs
assistance, only in the last two cases. In one of the cases (partial behaviour. Furthermore, it should be observed that IPv6 failures
failure: slower IPv6 vs IPv4 path end-to-end), just don't help to will also impact other operators (even if not using the
make IPv6 faster. In the other case (complete failure only in the optimization), and especially those using only NAT64+DNS64 instead of
IPv6 links behind the operator's NAT64 towards the destination), it 464XLAT, or even more, any IPv6-only hosts and applications in any
will completely fail. However, it should be observed that in both operator network across the entire Internet. It looks like it is
cases, the problem will also impact other operators (even if not very important to make sure that, as IPv6 is more prevalent, there is
using the optimization), and especially those using only NAT64+DNS64 a better monitoring and failures are detected ASAP, instead of being
instead of 464XLAT, or even more, any IPv6-only hosts or applications hidden by Happy Eyeballs, specially in IPv6-only networks. It should
in any operator network across the entire Internet. It looks like it be noticed also that in IPv6-only with IPv4aaS, the chances of
is very important to make sure that, as IPv6 is more prevalent, there troubles in the IPv4 paths seem to be higher than in the IPv6, as
is a better monitoring and failures are detected ASAP, instead of there are more translations, more devices, more delays, while the
being hidden by Happy Eyeballs, specially in IPv6-only networks, so optimization will precisely reduce them.
it seems an acceptable trade-off. It should be noticed also that in
IPv6-only with IPv4aaS, the chances of troubles in the IPv4 paths
seem to be higher than in the IPv6, as there are more translations,
more devices, more delays, while the optimization will precisely
reduce them.
5.2.13. Troubleshooting Implications 5.2.15. Troubleshooting Implications
When there is a need to troubleshoot IPv4 from the CE LANs, it may When there is a need to troubleshoot IPv4 from the CE LANs, it may
happen that there is an EAMT entry forcing the flow to a given happen that there is an EAMT entry forcing the flow to a given
destination(s) to use IPv6, which will distort the results. destination(s) to use IPv6, which will distort the results, unless
the host being used is dual-stack (which is the most common
situation).
This can be avoided, using a CLI/GUI or provisioning procedure, to This can be avoided, using a CLI/GUI or provisioning procedure, to
either completely disable the optimization during the either completely disable the optimization during the
troubleshooting, or create specific static EAMT entries, using the troubleshooting, or create specific static EAMT entries, using the
Valid/Invalid and Auto/Static flags, as described in Section 5.2.3. Valid/Stale/Invalid and Auto/Static flags, as described in
Section 5.2.5.
Consequently, the CE MUST allow both, disabling the optimization and Consequently, the CE MUST allow both, disabling the optimization and
the setup of manual/static EAMT entries. the setup of manual/static EAMT entries.
5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution
Instead of using the DNS proxy/stub resolver to create the EAMT Instead of using the DNS proxy/stub resolver to create the EAMT
entries, the operator may push this table (or parts of it) into the entries, the operator may push this table (or parts of it) into the
CE/NAT46/CLAT, by using configuration/management mechanisms. CE/NAT46/CLAT, by using configuration/management mechanisms.
skipping to change at page 16, line 52 skipping to change at page 19, line 10
Operator already has a specific route to 2001:db8::f:e:d:c Operator already has a specific route to 2001:db8::f:e:d:c
EAMT may contain TTLs which probably are derived from DNS ones, or EAMT may contain TTLs which probably are derived from DNS ones, or
alternatively, a global TTL for the full table. alternatively, a global TTL for the full table.
An alternative way to configure the table, is that the CE is actually An alternative way to configure the table, is that the CE is actually
pulling the table (or parts of it) from the operator infrastructure. pulling the table (or parts of it) from the operator infrastructure.
In this case it will be mandatory that the entries have individual In this case it will be mandatory that the entries have individual
TTLs, again probably derived from the DNS ones. TTLs, again probably derived from the DNS ones.
The major drawback of this approach is that it requires a new This approach has three major drawbacks:
protocol, or an extension to existing ones, in order to push or pull
the EAMT, in addition to the possible impact in terms of bandwidth 1. CDNs are used to do frequent changes at the DNS level, so unless
each time the CEs reboot, or an EAMT must be pushed to all the CEs, the CDNs offer an API or equivalent convenient solution to keep
etc. updated the EAMT, the operator will need to cache the most
frequent FQDNs being resolved in their own DNS and based on the
TTLs, update the EAMT.
2. It requires a new protocol, or an extension to existing ones, in
order to push or pull the EAMT updates.
3. It may generate additional bandwidth utilization in the WAN links
for every CE when the EAMT needs to be update, even when a CE
reboots.
6. IPv6-only Services become accessible to IPv4-only devices/apps 6. IPv6-only Services become accessible to IPv4-only devices/apps
One of the issues with the IPv6 deployment, is that those services One of the issues with the IPv6 deployment, is that those services
which become IPv6-only in Internet, aren't reachable by IPv4-only which become IPv6-only in Internet, aren't reachable by IPv4-only
devices and applications. This means that new content providers must hosts and applications. This means that new content providers must
support dual-stack even for new services, even while IPv4 public support dual-stack even for new services, even while IPv4 public
addresses aren't available. addresses aren't available.
If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also If NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) is chosen, it also
offers the chance to resolve this issue. This is possible if offers the chance to resolve this issue. This is possible if
IPv6-only services get configured with an A resource record pointing IPv6-only services get configured with an A resource record pointing
to a well-known IPv4 address despite they aren't actually connected to a well-known IPv4 address despite they aren't actually connected
to IPv4. This is out of scope for this document, as it will require to IPv4. This is out of scope for this document, as it will require
further work and a reservation by IANA, This will mean that those further work and a reservation by IANA, This will mean that those
services will work fine if there is a NAT46/CLAT supporting the services will work fine if there is a NAT46/CLAT supporting the
skipping to change at page 17, line 49 skipping to change at page 20, line 16
7. Conclusions 7. Conclusions
NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right NAT46/CLAT/DNS-proxy-EAM approach (Section 5.2) seems the right
solution for optimizing the access to dual-stack services, whether solution for optimizing the access to dual-stack services, whether
they are located inside or outside the ISP. It is also the only they are located inside or outside the ISP. It is also the only
approach which has no additional requirements for the network approach which has no additional requirements for the network
operators (both ISPs and CDN/cache operators). operators (both ISPs and CDN/cache operators).
Having this type of optimization facilitates and increases the usage Having this type of optimization facilitates and increases the usage
of IPv6, even for IPv4-only devices and applications, at the same of IPv6, even for IPv4-only hosts and applications, at the same time
time that decreases the use of the NAT64. that decreases the use of the NAT64.
SIIT already has a SHOULD for EAM support, so it is not a high SIIT already has a SHOULD for EAM support, so it is not a high
additional burden the support required for existing implementations additional burden the support required for existing implementations
to be updated for this optimization. to be updated for this optimization.
8. Security Considerations 8. Security Considerations
This document does not have any new specific security considerations, This document does not have any new specific security considerations,
besides the ones already known for DNS64. besides the ones already known for DNS64.
skipping to change at page 18, line 39 skipping to change at page 21, line 8
performed in the service provider network, so the chances of a performed in the service provider network, so the chances of a
successful exploitation of this vulnerability are low. successful exploitation of this vulnerability are low.
9. IANA Considerations 9. IANA Considerations
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations.
10. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the inputs of Erik Nygren, Fred The authors would like to acknowledge the inputs of Erik Nygren, Fred
Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani Baker, Martin Hunek, Chongfeng Xie, Fernando Gont, Fernando Frediani,
and Jen Linkova. Jen Linkova, Eduard Vasilenko and Philip Homburg.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", STD 88, "DNS Extensions to Support IP Version 6", STD 88,
RFC 3596, DOI 10.17487/RFC3596, October 2003, RFC 3596, DOI 10.17487/RFC3596, October 2003,
<https://www.rfc-editor.org/info/rfc3596>. <https://www.rfc-editor.org/info/rfc3596>.
[RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS
Authenticated Data (AD) bit", RFC 3655,
DOI 10.17487/RFC3655, November 2003,
<https://www.rfc-editor.org/info/rfc3655>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452, Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009, DOI 10.17487/RFC5452, January 2009,
<https://www.rfc-editor.org/info/rfc5452>. <https://www.rfc-editor.org/info/rfc5452>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>. <https://www.rfc-editor.org/info/rfc6052>.
 End of changes. 76 change blocks. 
241 lines changed or deleted 331 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/