draft-ietf-v6ops-464xlat-optimization-01.txt   draft-ietf-v6ops-464xlat-optimization-02.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 8, 2021 Telecentro Expires: January 12, 2021 Telecentro
July 7, 2020 July 11, 2020
464XLAT/NAT64 Optimization 464XLAT/NAT64 Optimization
draft-ietf-v6ops-464xlat-optimization-01 draft-ietf-v6ops-464xlat-optimization-02
Abstract Abstract
This document proposes possible solutions to avoid certain drawbacks IP/ICMP Translation Algorithm (SIIT) can be used to provide access
of IP/ICMP Translation Algorithm (SIIT) when the destinations are for IPv4-only devices or applications to IPv4-only or dual-stack
already available with IPv6. When SIIT is used as a stateless NAT46 destinations over IPv6-only infrastructure. In that case, the
and IPv4-only devices or applications initiate traffic flows to dual- traffic flows are translated twice: first from IPv4 to IPv6
stack services (in the operator network or Internet), those flows (stateless NAT46 at the ingress point to the IPv6-only
will be translated back to IPv4 by a NAT64. Avoiding this dual- infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
translation will significantly reduce the usage of the NAT64 and the the egress point). When the destination is IPv6-enabled, the second
relevant logging, which may be a high impact when traffic flows are translation might be avoided. This document describes a possible
towards CDNs, caches or similar resources. This is the case for optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
464XLAT and MAP-T. back to IPv4 if the destination is reachable over IPv6. The proposed
solution would significantly reduce the NAT64 utilization in the
operator's network.
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 8, 2021. This Internet-Draft will expire on January 12, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3 3. Possible Optimization . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Problem Statement Summary . . . . . . . . . . . . . . . . . . 5
5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7 5. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7
5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 7 5.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 7
5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 8 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 8
5.2.1. Detection of IPv4-only devices or applications . . . 8 5.2.1. Detection of IPv4-only hosts or applications . . . . 9
5.2.2. Detection of IPv6-enabled service . . . . . . . . . . 8 5.2.2. Detection of IPv6-enabled service . . . . . . . . . . 9
5.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 9 5.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 9
5.2.4. Forwarding path via stateful NAT for existing EAMT 5.2.4. Forwarding path via stateful NAT for existing EAMT
entries . . . . . . . . . . . . . . . . . . . . . . . 10 entries . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 11 5.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 11
5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 11 5.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 11
5.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 11 5.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 12
5.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 11 5.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 12
5.2.9. Behavior when using literal addresses or non 5.2.9. Behavior when using literal addresses or non
IPv6-compliant APIs . . . . . . . . . . . . . . . . . 12 IPv6-compliant APIs . . . . . . . . . . . . . . . . . 12
5.2.10. False detection of a dual-stack host as IPv4-only . . 12 5.2.10. Behavior in case of Foreign DNS . . . . . . . . . . . 12
5.2.11. Behavior in presence of Happy Eyeballs . . . . . . . 12 5.2.11. False detection of a dual-stack host as IPv4-only . . 13
5.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 13 5.2.12. Behavior in presence of Happy Eyeballs . . . . . . . 14
5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 14 5.2.13. Troubleshooting Implications . . . . . . . . . . . . 16
5.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 16
6. IPv6-only Services become accessible to IPv4-only 6. IPv6-only Services become accessible to IPv4-only
devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 15 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 devices or
applications to connect with IPv4 services in Internet, by means of a applications to connect with IPv4 services in Internet over IPv6-only
stateless NAT46 SIIT (IP/ICMP Translation Algorithm) as described by infrastructure, by means of a stateless NAT46 SIIT (IP/ICMP
[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.
The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator The NAT46/CLAT (WAN side) is connected by IPv6-only to the operator
network, which in turn, will have a reverse translation, the NAT64 network, which in turn, will have a reverse translation, the NAT64
([RFC6146]), known as PLAT (Provider Translator) in the case of ([RFC6146]), known as PLAT (Provider Translator) in the case of
464XLAT. This allows to translate the IPv6-only flow back to IPv4, 464XLAT. This allows to translate the IPv6 flow back to IPv4, in
in order to forward it to Internet. order to forward it to Internet.
In both cases (NAT46 and NAT64), the translation of the packet In both cases (NAT46 and NAT64), the translation of the packet
headers is done using the IP/ICMP translation algorithm defined in headers is done using the IP/ICMP translation algorithm defined in
[RFC7915] and algorithmically translating the IPv4 addresses to IPv6 [RFC7915]. Translation between IPv4 and IPv6 addresses is done as
addresses following [RFC6052]. per [RFC6052]. The NAT64 prefix should be discovered by the CE by
one or more of the existing mechanisms ([RFC7225], [RFC8781] or
[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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [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 they can use of the synthesis of AAAA records from the A records, so the NAT64 can
a NAT64, 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 devices 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
this double-translation, in the cases when the Internet services, are this double-translation, in the cases when the Internet services, are
already IPv6-enabled. So, in those cases, if the NAT46 already already IPv6-enabled. So, in those cases, if the NAT46 already
translated the IPv4-only flow to IPv6, it doesn't look necessary to translated the IPv4 flow to IPv6, it doesn't look necessary to
translate this back to IPv6. translate this back to IPv6.
A typical 464XLAT deployment is depicted in Figure 1. A typical 464XLAT deployment is depicted in Figure 1.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| IPv6 | / \ / \ | IPv6 | / \ / \
.-----. | CE | / IPv6- \ .-----. / IPv4 \ .-----. | CE | / IPv6- \ .-----. / IPv4 \
/ \ | or +--( only )---( NAT64 )---( Internet ) / \ | or +--( only )---( NAT64 )---( Internet )
/ LAN's \ | UE | \ Access /\ `-----' \ / / Dual- \ | UE | \ Access /\ `-----' \ /
( Dual- )--+ | \ / \ \ / ( Stack )--+ | \ / \ \ /
\ Stack / | with | `--+--' \ .-----. `-----' \ LAN's / | with | `--+--' \ .-----. `-----'
\ / | NAT46 | | \ / \ \ / | NAT46 | | \ / \
`-----' | CLAT | +---+----+ / IPv6 \ `-----' | CLAT | +---+----+ / IPv6 \
| | | DNS/ | ( Internet ) | | | DNS/ | ( Internet )
+-------+ | DNS64 | \ / +-------+ | DNS64 | \ /
+--------+ \ / +--------+ \ /
`-----' `-----'
Figure 1: Typical 464XLAT Deployment Figure 1: Typical 464XLAT Deployment
As it can be observed in the preceding picture, the situation is the Examples of a topology shown on the above picture includes:
same, regardless of in case of a wired network with a CE Router or a
cellular network where a UE is connecting other devices (which may be o An IPv6-only residential access network where the CE Router (with
IPv4-only or have IPv4-only apps), by means of a tethering NAT46/CLAT) supports Dual-Stack in the customer LANs.
functionality.
o An IPv6-only cellular network where a UE uses the NAT46/CLAT for
dual-stack internal applications and other devices connected via
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 )
/ LAN's \ | UE | \ Access /\ `-----' \ / / Dual- \ | UE | \ Access /\ `-----' \ /
( Dual- )--+ | \ / \ \ / ( Stack )--+ | \ / \ \ /
\ Stack / | with | `--+--' \ .-----. `--+--' \ LAN's / | with | `--+--' \ .-----. `--+--'
\ / | NAT46 | | \ / \ \ \ / | NAT46 | | \ / \ \
`-----' | CLAT | +---+----+ / IPv6 \ .--+--. `-----' | CLAT | +---+----+ / IPv6 \ .--+--.
| | | 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
skipping to change at page 5, line 27 skipping to change at page 5, line 45
o Additional logging, its relevant storage and processing resources. o Additional logging, its relevant storage and processing resources.
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 4. Problem Statement Summary
If the devices or applications in the customer LAN are IPv6-capable, If the devices 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 )--+ | \ / \ \ /
\ apps / | with | `--+--' \ .-----. `--+--' \ apps / | with | `--+--' \ .-----. `-----'
\ / | NAT46 | | \ / \ \ / | NAT46 | | \ / \
`-----' | CLAT | +---+----+ / IPv6 \ .--+--. `-----' | CLAT | +---+----+ / IPv6 \ .-----.
| | | 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
skipping to change at page 6, line 33 skipping to change at page 6, line 52
\ Caches/ \ Caches/
`-----' `-----'
<-------------------- IPv4 to IPv6 to IPv4 flow --------------------> <-------------------- IPv4 to IPv6 to IPv4 flow -------------------->
Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps Figure 4: 464XLAT access to CDNs/Caches by IPv4-only apps
Clearly, this is a non-optimal situation, as it means that even if Clearly, this is a non-optimal situation, as it means that even if
there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6 there is a dual-stack service, the NAT46/CLAT translated IPv4 to IPv6
traffic flow, is unnecessarily translated back to IPv4, traversing traffic flow, is unnecessarily translated back to IPv4, traversing
the stateful NAT64. This has a direct impact in the need to scale the stateful NAT64. This has a direct impact in the need to scale
the NAT64 beyond what will be actually needed if possible solutions, the NAT64 beyond what will be actually needed, if possible solutions,
in order to keep using the IPv6 path towards those services, are in order to keep using the IPv6 path towards those services, are
considered. considered.
As shown in the Figure 4, this is also the case for many other As shown in the Figure 4, this is also the case for many other
services, not just CDNs or caches, such as VoIP access to the services, not just CDNs or caches, such as VoIP access to the
relevant operator infrastructure, which may be also dual-stack. This relevant operator infrastructure, which may be also dual-stack. This
is true as well for many other dual-stack or IPv6-enabled services, is true as well for many other dual-stack or IPv6-enabled services,
which may be directly reachable from the operator infrastructure, which may be directly reachable from the operator infrastructure,
even if they are not part of it, for example peering agreements, even if they are not part of it, for example peering agreements,
services in IXs, etc. In general, this will become a more frequent services in IXs, etc. In general, this will become a more frequent
skipping to change at page 7, line 11 skipping to change at page 7, line 30
This document looks into different possible solution approaches in This document looks into different possible solution approaches in
order to optimize the IPv4-only SIIT translation providing a direct order to optimize the IPv4-only SIIT translation providing a direct
path to IPv6-capable services, as depicted in Figure 5. path to IPv6-capable services, as depicted in Figure 5.
+-------+ .-----. .-----. +-------+ .-----. .-----.
| 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 )--+ | \ / \ \ /
\ STB / | with | `--+--' \ .-----. `--+--' \ STB / | with | `--+--' \ .-----. `-----'
\ VoIP / | NAT46 | | \ / \ \ VoIP / | NAT46 | | \ / \
`-----' | CLAT | +---+----+ / IPv6 \ .--+--. `-----' | CLAT | +---+----+ / IPv6 \ .-----.
| | | DNS/ | ( Internet )IPv6/ Dual- \ | | | DNS/ | ( Internet )IPv6/ Dual- \
+-------+ | DNS64 | \ /----/ Stack \ +-------+ | DNS64 | \ /----/ Stack \
+--------+ \ / ( ) +--------+ \ / ( )
`-----' \ CDNs/ / `-----' \ CDNs/ /
\ Caches/ \ Caches/
`-----' `-----'
<------------------------ IPv4 to IPv6 flow ------------------------> <------------------------ IPv4 to IPv6 flow ------------------------>
Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps Figure 5: Optimized 464XLAT access to CDNs/Caches by IPv4-only apps
skipping to change at page 7, line 52 skipping to change at page 8, line 24
and a SmartTV querying for www.example.com: and a SmartTV querying for www.example.com:
www.example.com A 192.0.2.1 www.example.com A 192.0.2.1
NAT46/CLAT translated to 64:ff9b::192.0.2.1 NAT46/CLAT translated to 64:ff9b::192.0.2.1
CDN IPv6 interface must be 64:ff9b::192.0.2.1 CDN IPv6 interface must be 64:ff9b::192.0.2.1
Operator must have a specific route to 64:ff9b::192.0.2.1 Operator must have a specific route to 64:ff9b::192.0.2.1
Note: Examples using text representation as per Section 2.3 of Note: Examples using text representation as per Section 2.3 of
[RFC6052] and IPv4 documentation addresses following [RFC5737]. [RFC6052] and IPv4 documentation addresses following [RFC5737].
It should be remarked that this approach requires that the path to
the destination is configured in such way (i.e., more specific
routing prefixes), that doesn't traverse the NAT64 devices.
Because the WKP is non-routable, this solution will only be possible Because the WKP is non-routable, this solution will only be possible
if the CDN/cache is in the same ASN as the provider network, or if the CDN/cache is in the same ASN as the provider network, or
somehow interconnected without routing thru Internet. somehow interconnected without routing thru Internet.
This solution has the additional drawback of the operational This solution has the additional drawback of the operational
complexity/issues added to the operation of the CDN/cache, and the complexity/issues added to the operation of the CDN/cache, and the
need to synchronize any IPv4 interface address changes with the need to synchronize any IPv4 interface address changes with the
relevant IPv6 ones, and possibly with routing. relevant IPv6 ones, and possibly with routing.
5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 5.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution
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. by-step example case. Note that this optimization MUST NOT be
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 devices or applications 5.2.1. Detection of IPv4-only hosts or applications
The assumption is that, typically a dual-stack device will prefer The assumption is that, typically a dual-stack host will prefer using
using IPv6 as the DNS transport. So, when there is a DNS query, IPv6 as the DNS transport. So, when there is a DNS query,
transported with IPv4, for an A record, and there is not a query for transported with IPv4, for an A record, and there is not a query for
the AAAA record from the same IPv4 source (to the same destination), the AAAA record from the same IPv4 source (to the same destination),
the DNS proxy/stub resolver can infer that, most probably, it is an the DNS proxy/stub resolver can infer that, most probably, it is an
IPv4-only device or application. IPv4-only device or application.
It needs to be remarked that, if the detection of the IPv4-only It needs to be remarked that, if the detection of the IPv4-only
device or application is done incorrectly (either not detecting it or device or application is done incorrectly (either not detecting it or
by a false detection), no harm is caused. In the worst case, by a false detection), no harm is caused. In the worst case,
optimization will not be performed, at least, at the time being. optimization will not be performed, at least, at the time being.
However, optimization maybe performed later on, if a new detection However, optimization maybe performed later on, if a new detection
skipping to change at page 9, line 22 skipping to change at page 9, line 50
synthetic AAAA. synthetic AAAA.
In order to create the EAMT entry, to determine if there is an AAAA In order to create the EAMT entry, to determine if there is an AAAA
record after an A record query, it is suggested to use the same delay record after an A record query, it is suggested to use the same delay
value (50 milliseconds) as the "Resolution Delay" indicated by Happy value (50 milliseconds) as the "Resolution Delay" indicated by Happy
Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping
between destination addresses (IPv4/IPv6), which may impact some between destination addresses (IPv4/IPv6), which may impact some
applications, at the cost of a small extra delay for the initial applications, at the cost of a small extra delay for the initial
communication setup, when the EAMT entry doesn't yet exist. communication setup, when the EAMT entry doesn't yet exist.
Each EAMT entry will 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 ones:
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. IPv4 address/prefix: By default, the prefix length is 32 bits.
3. IPv6 address/prefix: By default, the prefix length is 128 bits. 3. IPv6 address/prefix: By default, the prefix length is 128 bits.
4. TTL: Because the optimization will make use of the AAAA (IPv6 4. TTL: Because the optimization will make use of the AAAA (IPv6
address), the TTL for the EAMT entry must set to the same value address), the TTL for the EAMT entry MUST be set to the same
as in the AAAA RR. In normal conditions the TTL for both A and value as in the AAAA RR. In normal conditions the TTL for both A
AAAA records, of a given FQDN, should be the same, so this and AAAA records, of a given FQDN, should be the same, so this
ensures a proper behavior if there is any DNS mismatch. ensures a proper behavior if there is any DNS mismatch.
5. FQDN: The one that originated the A query for this EAMT entry. 5. 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 6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT
be used and consequently no optimization performed. It may be be used and consequently no optimization performed. It may be
used also for an explicit configuration (GUI, CLI, provisioning used also for an explicit configuration (GUI, CLI, provisioning
skipping to change at page 11, line 42 skipping to change at page 12, line 17
2. www.another-example.com A 192.0.2.1 2. www.another-example.com A 192.0.2.1
3. www.another-example.com AAAA 2001:db8::e:e:f:f 3. www.another-example.com 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 as invalid
5.2.7. Behavior in case of multiple A/AAAA RRs 5.2.7. Behavior in case of multiple A/AAAA RRs
If multiple A and/or AAAA records are available, the DNS proxy/stub Existing DNS proxy/stub resolvers already implement mechanisms for
resolver MUST follow existing procedures to choose each one. In DNS Load Balancing ([RFC1794]). This should not be modified to
other words, the chosen pair of A/AAAA records doesn't present any implement the optimization so, if multiple A and/or AAAA records are
different result compared with a situation when this mechanism is not available, any of them could be chosen. In other words, the chosen
used. 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 5.2.8. Behavior in presence/absence of DNS64
This optimization performs the same in both cases: if a DNS64 is 464XLAT can be deployed/used with and without a DNS64. However, as
present/used or if it is not present/used. This is explained because indicated in Section 5.2.2, the EAMT entry is only created when the
the optimization is only relevant for destinations which already have service is IPv6-enabled, because the optimization is only relevant
AAAA records, and in those cases DNS64 is not relevant. Furthermore, for destinations which already have AAAA records. In those cases
because as indicated in Section 5.2.2, the EAMT entry is not created DNS64 is not relevant.
when the service is IPv6-enabled. This is relevant because 464XLAT
can be deployed/used with and without a DNS64.
5.2.9. Behavior when using literal addresses or non IPv6-compliant APIs 5.2.9. 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 devices or applications that don't
use DNS, will not create the relevant entries. use DNS, will not create the relevant entries.
They maybe optimized if devices or applications using DNS, at some They may be optimized if devices or applications using DNS, at some
point, query for the same A RRs, or if EAMT entries are statically point, query for the same A RRs, or if EAMT entries are statically
configured. configured.
5.2.10. False detection of a dual-stack host as IPv4-only 5.2.10. Behavior in case of Foreign DNS
If a dual-stack host is issuing the A query using IPv4 transport, and
the AAAA query using IPv6 transport, or using different IPv4
addresses for the A and AAAA queries, the EAMT entry will be created.
However, this EAMT entry may not be used by dual-stack devices or
applications, because those devices or applications should prefer
IPv6. 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 consequently IPv6, so this mechanism
will be correcting an undesirable behavior. This is a special case,
which actually seems to be an incoherent host or application
implementation.
However, 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.11. Behavior in presence of Happy Eyeballs
Happy Eyeballs [RFC8305] is only available in dual-stack hosts.
Consequently, is not affected by this mechanism because both, the A
and the AAAA queries should be issued by the host as soon after one
another as possible. However, 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 will be created for that
destination. Consequently, a Happy Eyeballs fallback to IPv4 will
actually be using the relevant EAMT entry IPv6 destination. This has
the disadvantage that the IPv4-IPv6-IPv4 translation path can't be
used by Happy Eyeballs-enabled applications. However, this may be
actually 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, because that means also IPv4 will not be
working. If the issue is related to extra IPv6 delay versus the IPv4
delay, Happy Eyeballs will not be able to offer a significative
advantage here, but it looks like an acceptable trade-off.
Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is
IPv6-only. So even if Happy Eyeballs is present, the fallback to
IPv4-only typically, will be slower than native IPv6 itself, because
the added delay in the NAT46+NAT64 translations, when not using this
optimization.
5.2.12. Behavior in case of Foreign DNS
Devices or applications may use DNS servers from other networks. For Devices or applications may use DNS servers from other networks. For
a complete description of reasons for that, refer to Section 4.4 of a 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 devices 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
skipping to change at page 13, line 41 skipping to change at page 13, line 19
devices such as SmartTVs or STBs (if they do, some other devices such as SmartTVs or STBs (if they do, some other
functionalities, such as CDN/caches optimizations may not work as functionalities, such as CDN/caches optimizations may not work as
well), so this only happens typically if the vendor is doing it well), so this only happens typically if the vendor is doing it
on-purpose and for good well-known reasons. on-purpose and for good well-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 apply. 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-
stack, so aren't part of the problem statement described by this stack, so aren't part of the problem statement described by this
document and will not be adversely affected. document and will not be adversely affected.
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, than the one
already described, is observed. already described, is observed.
5.2.11. False detection of a dual-stack host as IPv4-only
If a dual-stack host is issuing the A query using IPv4 transport, and
the AAAA query using IPv6 transport, or in the other way around, or
using different IPv4 addresses for the A and AAAA queries, the EAMT
entry will be created. However, this EAMT entry may not be used by
dual-stack devices or applications, because those devices or
applications should prefer IPv6. 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
consequently IPv6, so this mechanism will be correcting an
undesirable behavior. This is a special case, which 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
Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts.
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
one another as possible. In summary, the host should not be detected
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
IPv6-only. So even if Happy Eyeballs is present, IPv4 is expected to
be slower than native IPv6 itself due to delays added by the
NAT46+NAT64 translations. This optimization reduces those delays by
eliminating the second translation (NAT64).
However, there may be cases where this may be understood as
problematic. The possible reasons why Happy Eyeballs may trigger an
IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS,
in general, can be classified as:
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
or malfunctions. It is difficult to believe that this happens
only with IPv6, and if that's the case Happy Eyeballs will not
resolve the issue, because IPv4 is provided as a service on top
of IPv6.
2. Complete failure of the IPv6-only link or IPv6-only operator's
infrastructure (up to the NAT64). In this case, IPv4 will not
work for that subscriber. Happy Eyeballs will not resolve the
issue, and instead will only be adding some extra delay (the
attempt to fallback to IPv4 before timing-out).
3. Complete failure of both IPv4 and IPv6 links behind the
operator's NAT64 towards the destination. In this case,
typically both, IPv4 and IPv6 will fail (in many cases, they are
dual-stack links, not different links). Again, Happy Eyeballs
will also fail to resolve the issue.
4. Complete failure only in the IPv6 links behind the operator's
NAT64 towards the destination. This is less frequent, bus still
miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6
together with outages or IPv6-only routing issues, could generate
this problem. In this case, Happy Eyeballs could resolve the
issue, however, the optimization will disallow it.
5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In
general, the added delay of the IPv4 translations and NAT across
the path, increases the chances that IPv4 is faster than IPv6.
However, it may happen that there is some IPv6 specific link
congestion or packet dropping, that generates the reverse
situation, so IPv4 becomes faster than IPv6. Because the
optimization, the end-to-end path is forced to be IPv6, so Happy
Eyeballs will not be able to offer any significative advantage in
resolving the issue.
In summary, the optimization may be hindering the Happy Eyeballs
assistance, only in the last two cases. In one of the cases (partial
failure: slower IPv6 vs IPv4 path end-to-end), just don't help to
make IPv6 faster. In the other case (complete failure only in the
IPv6 links behind the operator's NAT64 towards the destination), it
will completely fail. However, it should be observed that in both
cases, the problem will also impact other operators (even if not
using the optimization), and especially those using only NAT64+DNS64
instead of 464XLAT, or even more, any IPv6-only hosts or applications
in any operator network across the entire Internet. It looks like it
is very important to make sure that, as IPv6 is more prevalent, there
is a better monitoring and failures are detected ASAP, instead of
being hidden by Happy Eyeballs, specially in IPv6-only networks, so
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
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
destination(s) to use IPv6, which will distort the results.
This can be avoided, using a CLI/GUI or provisioning procedure, to
either completely disable the optimization during the
troubleshooting, or create specific static EAMT entries, using the
Valid/Invalid and Auto/Static flags, as described in Section 5.2.3.
Consequently, the CE MUST allow both, disabling the optimization and
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.
This solution has the advantage of not being affected by any DNS This solution has the advantage of not being affected by any DNS
changes from the user (the EAMT is created by the operator) and changes from the user (the EAMT is created by the operator) and
ensures a complete control from the operator. However, it may impact ensures a complete control from the operator. However, it may impact
the cases of devices with a DNS configured by the vendor. the cases of devices with a DNS configured by the vendor.
skipping to change at page 16, line 10 skipping to change at page 18, line 14
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.
Spoofed DNS responses could generate incorrect EAMT entries.
However, this seems not different than if the optimization is not in
place and the spoofed DNS responses are cached by the CE DNS proxy/
stub resolver or even by hosts in the CE LANs. It very much depends
on how and where the attack is actually performed.
In both cases, 464XLAT and MAP-T, the CE device should contain a DNS
proxy/stub resolver, which is also required for the optimization.
Nevertheless, it is common that the user change DNS settings. If it
happens, in the case of MAP-T, the port-set is restricted for an
efficient public IPv4 address sharing, so the entropy of the source
ports is significantly lowered. In this case, theoretically MAP-T is
less resilient against cache poisoning ([RFC5452]) compared with
464XLAT. However, an efficient cache poisoning attack requires that
the subscriber operates its own caching DNS server and the attack is
performed in the service provider network, so the chances of a
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 TBD ... and Jen Linkova.
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>.
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
Resilient against Forged Answers", RFC 5452,
DOI 10.17487/RFC5452, January 2009,
<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>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
skipping to change at page 17, line 10 skipping to change at page 19, line 36
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011, DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>. <https://www.rfc-editor.org/info/rfc6147>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013, RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>. <https://www.rfc-editor.org/info/rfc6877>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC7225, May 2014,
<https://www.rfc-editor.org/info/rfc7225>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <https://www.rfc-editor.org/info/rfc7599>. 2015, <https://www.rfc-editor.org/info/rfc7599>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757, Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016, DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>. <https://www.rfc-editor.org/info/rfc7757>.
skipping to change at page 17, line 34 skipping to change at page 20, line 24
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router
Advertisements", RFC 8781, DOI 10.17487/RFC8781, April
2020, <https://www.rfc-editor.org/info/rfc8781>.
11.2. Informative References 11.2. Informative References
[I-D.huitema-dprive-dnsoquic] [I-D.huitema-dprive-dnsoquic]
Huitema, C., Mankin, A., and S. Dickinson, "Specification Huitema, C., Mankin, A., and S. Dickinson, "Specification
of DNS over Dedicated QUIC Connections", draft-huitema- of DNS over Dedicated QUIC Connections", draft-huitema-
dprive-dnsoquic-00 (work in progress), March 2020. dprive-dnsoquic-00 (work in progress), March 2020.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
DOI 10.17487/RFC1794, April 1995,
<https://www.rfc-editor.org/info/rfc1794>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010, DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>. <https://www.rfc-editor.org/info/rfc5737>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
 End of changes. 43 change blocks. 
129 lines changed or deleted 262 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/