< draft-palet-v6ops-464xlat-opt-cdn-caches-02.txt   draft-palet-v6ops-464xlat-opt-cdn-caches-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: December 22, 2019 Telecentro Expires: January 9, 2020 Telecentro
June 20, 2019 July 8, 2019
464XLAT Optimization 464XLAT Optimization
draft-palet-v6ops-464xlat-opt-cdn-caches-02 draft-palet-v6ops-464xlat-opt-cdn-caches-03
Abstract Abstract
This document proposes possible solutions to avoid certain drawbacks This document proposes possible solutions to avoid certain drawbacks
of IP/ICMP Translation Algorithm (SIIT) when the destinations are of IP/ICMP Translation Algorithm (SIIT) when the destinations are
available with IPv6. When SIIT is used as a NAT46 and IPv4-only available with IPv6. When SIIT is used as a NAT46 and IPv4-only
devices or applications initiate traffic flows to dual-stack CDNs devices or applications initiate traffic flows to dual-stack CDNs
(Content Delivery Networks), Caches or other network resources (in (Content Delivery Networks), Caches or other network resources (in
the operator network or Internet), those flows will be translated the operator network or Internet), those flows will be translated
back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T. back to IPv4 by a NAT64. This is the case for 464XLAT and MAP-T.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 December 22, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 16 skipping to change at page 2, line 16
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 6 4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 6
4.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 6 4.1. Approach 1: DNS/Routing-based Solution . . . . . . . . . 6
4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 7 4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution . . . 7
4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 10 4.2.1. Detection of IPv4-only devices or applications . . . 7
4.2.2. Detection of IPv6-enabled service . . . . . . . . . . 8
4.2.3. Creation of EAMT entries . . . . . . . . . . . . . . 8
4.2.4. Forwarding path for existing EAMT entries . . . . . . 10
4.2.5. Maintenance of the EAMT entries . . . . . . . . . . . 10
4.2.6. Usage example . . . . . . . . . . . . . . . . . . . . 10
4.2.7. Behavior in case of multiple A/AAAA RRs . . . . . . . 10
4.2.8. Behavior in presence/absence of DNS64 . . . . . . . . 11
4.2.9. Behavior when using literal addreses or non
IPv6-compliant APIs . . . . . . . . . . . . . . . . . 11
4.2.10. False detection of a dual-stack host as IPv4-only . . 11
4.2.11. Behaviour in presence of Happy Eyeballs . . . . . . . 11
4.2.12. Behavior in case of Foreign DNS . . . . . . . . . . . 12
4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution . . . 13
5. IPv6-only Services become accessible to IPv4-only 5. IPv6-only Services become accessible to IPv4-only
devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 11 devices/apps . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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, by means of a
NAT46 SIIT (IP/ICMP Translation Algorithm) as described by [RFC7915]. NAT46 SIIT (IP/ICMP 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)
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 services, which may be is true as well for many other dual-stack or IPv6-enabled services,
directly reachable from the operator infrastructure, even if not part which may be directly reachable from the operator infrastructure,
of it, for example peering agreements, services in IXs, etc. In even if they are not part of it, for example peering agreements,
general, this will become a more frequent situation for many other services in IXs, etc. In general, this will become a more frequent
services, which are not yet dual-stack. situation for many other services, which are not yet dual-stack.
For simplicity, across the rest of this document, references to CDNs/ For simplicity, across the rest of this document, references to CDNs/
caches, should be understood, unless otherwise stated, as any dual- caches, should be understood, unless otherwise stated, as any dual-
stacked resources. stacked resources.
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.
+-------+ .-----. .-----. +-------+ .-----. .-----.
skipping to change at page 7, line 39 skipping to change at page 7, line 39
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.
4.2. Approach 2: NAT46/CLAT/DNS-proxy-EAM-based Solution 4.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
AAAA records, respectively, so no additional complexity/issues added
to the CDN/caches operations.
The following sub-sections detail this approach and provide a step-
by-step example case.
4.2.1. Detection of IPv4-only devices or applications
The assumption is that, typically a dual-stack device will prefer The assumption is that, typically a dual-stack device will prefer
using IPv6 as the DNS transport. So, when there is a DNS query, using 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 it is an IPv4-only device the DNS proxy/stub resolver can infer that, most probably, it is an
or application. IPv4-only device or application.
Note that if the detection of the IPv4-only device or application is It needs to be remarked that, if the detection of the IPv4-only
done incorrectly (either not detecting it or by a false detection), device or application is done incorrectly (either not detecting it or
no harm is caused, as in the worst case, optimization will not be by a false detection), no harm is caused. In the worst case,
performed (at least at the time being, it may be performed later on). 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).
4.2.2. Detection of IPv6-enabled service
In the case of an IPv4-only detected device or application, the DNS In the case of an IPv4-only detected device or application, the DNS
proxy/stub resolver can actually perform an additional AAAA query, proxy/stub resolver MUST actually perform an additional AAAA query,
unless the information is already present in the Additional Section, unless the information is already present in the Additional Section,
as per Section 3 of [RFC3596]. If the response doesn't contain the as per Section 3 of [RFC3596]. Note that the NAT46/CLAT MUST already
WKP or NSP, it means that the destination is IPv6-capable, so the know the WKP or NSP being used in that network. If the response
NAT46/CLAT can create/update an entry for an Explicit Address Mapping contains at least one IPv6 address not using the WKP/NSP, it means
[RFC7757]. 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]).
4.2.3. Creation of EAMT entries
This way, an EAM Table (EAMT used for short, across the rest of this This way, an EAM Table (EAMT used for short, across the rest of this
document) is maintained automatically by the DNS proxy/stub resolver document) is created/maintained automatically by the DNS proxy/stub
in the NAT46/CLAT, and the NAT46/CLAT is responsible to prioritize resolver in the NAT46/CLAT, and the NAT46/CLAT is responsible to
any available entries in the EAMT, versus the use of the synthetic prioritize any available entries in the EAMT, versus the use of any
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 changing Eyeballs [RFC8305]. This avoids a slight NAT64 overload and flapping
destination addresses which may impact some applications, at the cost between destination addresses (IPv4/IPv6), which may impact some
of a small extra delay for each initial communication, when the EAMT applications, at the cost of a small extra delay for the initial
entry doesn't yet exist. communication setup, when the EAMT entry doesn't yet exist.
Following this approach, the IPv6-native path will take precedence Each EAMT entry will contain, the fields already described in
and traffic will not be forwarded to the NAT64. [RFC7757] and a few new ones:
Using the same example as in the previous section: 1. ID: EAMT Entry Index (optional).
2. IPv4 address/prefix: By default, the prefix length is 32 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
address), the TTL for the EAMT entry must be the one of 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.
Required in order to ensure a correct detection of cases such as
the use of reverse-proxy with a single IPv4 address to multiple
IPv6 addresses.
6. Valid/Invalid: When set to 1, means that this EAMT entry MUST NOT
be used and consequently no optimization performed. It may be
used also for an explicit configuration (GUI, CLI, provisioning
system, etc.) to disallow optimization for any IPv4 addresses.
7. Auto/Static: When set to 1, means that this EAMT entry has been
manually/statically configured, for example by means of an
explicit configuration (GUI, CLI, provisioning system, etc.), so
it doesn't expire with TTL.
When a new EAMT entry is first automatically created, it is marked as
"Valid" and "Auto" (both bits cleared). 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
"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,
which allows to re-enable optimization if a new query for the A
record has changed the situation. For example, maybe the reverse-
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
creating troubles to other hosts.
Note that when an EAMT entry is marked as "invalid", it will not
affect the devices or applications, as they will still be able to use
the regular CLAT+NAT64 flow, of course, without the optimization.
***** Open question regarding TTL and maybe FQDN and valid/auto bits.
Is this always a good thing to do for EAM? Should this document
update [RFC7757] to support this by default? Or it is just and
"extension" as per section 3.1 of [RFC7757].
4.2.4. Forwarding path for existing EAMT entries
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
that EAMT entry, will take precedence versus the NAT64 path, so the
traffic will not be forwarded to the NAT64.
4.2.5. Maintenance of the EAMT entries
The information in the EAMT MUST be kept timely-synchronized with the
AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL
expiry and consequently be deleted.
However, EAMT entries with the Auto/Static bit set, will not be
deleted.
4.2.6. Usage example
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
This approach uses the existing IPv4 and IPv6 addresses in the A and The following is an example of the CE behavior after the previous
AAAA records, respectively, so no additional complexity/issues added case has already created an EAMT entry and a reverse-proxy is
to the CDN/caches operations. detected:
The information in the EAMT MUST be kept timely-synchronized with the 1. A query for www.another-example.com A RR is received
AAAA records TTL's. In order to achieve that, each EAMT entry MUST
update with each A query, the TTL of the relevant AAAA record.
Update of RFC7757 ? TBD.
The EAMT entries MUST expire on the AAAA TTL expiry. 2. www.another-example.com A 192.0.2.1
3. www.another-example.com AAAA 2001:db8::e:e:f:f
4. A conflict has been detected
5. The existing EAMT entry for 192.0.2.1 is set as invalid
4.2.7. Behavior in case of multiple A/AAAA RRs
If multiple A and/or AAAA records are available, the DNS proxy/stub If multiple A and/or AAAA records are available, the DNS proxy/stub
resolver MUST follow existing procedures to choose each one. In resolver MUST follow existing procedures to choose each one. In
other words, the chosen pair of A/AAAA records doesn't present any other words, the chosen pair of A/AAAA records doesn't present any
different result compared with a situation when this mechanism is not different result compared with a situation when this mechanism is not
used. used.
This mechanism performs the same in both cases, if a DNS64 is used or 4.2.8. Behavior in presence/absence of DNS64
if it is not used. This is explained because the mechanism is only
relevant for destinations which don't have AAAA records, and in those This mechanism performs the same in both cases, if a DNS64 is
cases DNS64 is not relevant. present/used and if it is not present/used. This is explained
because the mechanism is only relevant for destinations which don't
have AAAA records, and in those cases DNS64 is not relevant.
Furthermore, because as indicated in Section 4.2.2, the EAMT entry is
not created when the service is IPv6-enabled. This is relevant
because 464XLAT can be deployed/used with and without a DNS64.
4.2.9. Behavior when using literal addreses or non IPv6-compliant APIs
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
use DNS, will not create the relevant entries.
They will be however optimized if devices or applications using DNS,
at some point, query for the same A RRs, or if EAMT entries are
statically configured.
4.2.10. 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 issuing the A query using IPv4 transport, and
the AAAA query using IPv6 transport, or using different IPv4 the AAAA query using IPv6 transport, or using different IPv4
addresses for the A and AAAA queries, the EAMT will be created even addresses for the A and AAAA queries, the EAMT entry will be created.
if may not be used, because the device should prefer IPv6. If the However, this EAMT entry may not be used by dual-stack devices or
host is preferring IPv4 for connecting the CDN/cache, it will be applications, because those devices or applications should prefer
actually using the NAT46/CLAT and then IPv6, so the mechanism will be IPv6. If the host is preferring IPv4 for connecting to the CDN/cache
correcting an undesirable behavior. This is a special case, which or IPv6-enabled service, it will be actually using the NAT46/CLAT,
actually seems to be an incoherent host or application 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. implementation.
Happy Eyeballs [RFC8305] is not affected by this mechanism because However, if other IPv4-only devices or applications subsequently need
both, the A and the AAAA queries should be issued by the host as soon to connect to the same IPv6-enabled service, they will take advantage
after one another as possible. Furthermore, Happy Eyeballs is only of the already existing EAMT entry, and consequently use the
present in dual-stack hosts. However, if the same NAT46/CLAT/CE is IPv6-optimised path.
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 4.2.11. Behaviour 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 destination. Consequently, a Happy Eyeballs fallback to IPv4 will
actually be using the relevant EAMT entry IPv6 destination. This has actually be using the relevant EAMT entry IPv6 destination. This has
the disadvantage that the IPv4-IPv6-IPv4 translation path can't be the disadvantage that the IPv4-IPv6-IPv4 translation path can't be
used by Happy Eyeballs-enabled applications. However, this is used by Happy Eyeballs-enabled applications. However, this may be
actually a good thing in the sense that an operator is interested in actually considered as a good thing, in the sense that an operator is
knowing as soon as possible, if its IPv6-only network is not interested in knowing as soon as possible, if the IPv6-only network
performing correctly, because that means also IPv4 will not be 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 working. If the issue is related to extra IPv6 delay versus the IPv4
delay, Happy Eyeballs will not be able to offer a significative delay, Happy Eyeballs will not be able to offer a significative
advantage here, but it looks like an acceptable trade-off. advantage here, but it looks like an acceptable trade-off.
In the case the DNS is modified, or some devices or applications use Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is
other DNS servers, the possible scenarios and the implications are: 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 detail in the NAT46+NAT64 translations, when not using this
optimization.
4.2.12. Behavior in case of Foreign DNS
Devices or applications may use DNS servers from other networks. For
a complete description of reasons for that, refer to Section 4.4 of
[I-D.ietf-v6ops-nat64-deployment]. In the case the DNS is modified,
or some devices or applications use other DNS servers, the possible
scenarios and the 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 created by other
devices using the same destinations. However, the lack of EAMT devices using the same destinations. However, the lack of EAMT
entry, will not impact negatively in the user's devices/ entry, will not impact negatively in the user's devices/
applications (the optimization is not performed). It should be applications (the optimization is not performed). It should be
noticed that users commonly, don't change the configuration of noticed that users commonly, don't change the configuration of
devices such as SmartTVs or STBs (if they do, some other devices such as SmartTVs or STBs (if they do, some other
skipping to change at page 10, line 23 skipping to change at page 13, line 12
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. 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.
4.3. Approach 3: NAT46/CLAT-provider-EAM-based Solution 4.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 11, line 52 skipping to change at page 14, line 40
6. Conclusions 6. Conclusions
NAT46/CLAT/DNS-proxy-EAM approach (Section 4.2) seems the right NAT46/CLAT/DNS-proxy-EAM approach (Section 4.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. they are located inside or outside the ISP.
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 devices and applications, at the same
time that decreases the use of the NAT64. time that decreases the use of the NAT64.
SIIT already has a SHOULD for EAM support. TBD. 464XLAT may be SIIT already has a SHOULD for EAM support. Should 464XLAT be updated
updated by this document so the CLAT has a MUST for EAM support. by this document so the CLAT has a MUST for EAM support?.
TBD. Should we recommend having A "null" records for IPv6-only
services in Internet? A web page IPv4-only hosted by IETF(?) showing
"sorry this web page/service is only available from IPv6 enabled
operators"?.
TBD. Other risks to consider ? If a CE is misconfigured, even a Should we recommend having A records for IPv6-only services in
small percentage of broken CEs may bring the content providers to Internet? The A record may point to a "reserved" or "special" IPv4
switch back to IPv4-only. So possible failure cases need to be address. A web page IPv4-only hosted by IETF(?) showing "sorry this
carefully considered for every possible solution approach. web page/service is only available from IPv6 enabled operators"?.
TBD. Should a way to manually exclude EAMT entries be considered? Open question: Should we consider any other risks? If CE's
May be a manual config in the CPE and by means of operator config. implementing this optimization create troubles, it may bring the
This is way-out to ensure nothing is broken by surprise and is not content providers to switch back to IPv4-only. So possible failure
solvable. cases need to be carefully considered for every possible solution
approach.
7. Security Considerations 7. Security Considerations
This document does not have any new specific security considerations. This document does not have any new specific security considerations.
TBD.
8. IANA Considerations 8. IANA Considerations
This document does not have any new specific IANA considerations. This document does not have any new specific IANA considerations,
unless we decide to define a "special reserved IPv4 address".
9. Acknowledgements 9. 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 and TBD ... Baker, Martin Hunek and TBD ...
10. References 10. References
10.1. Normative References 10.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>.
skipping to change at page 14, line 13 skipping to change at page 16, line 42
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
10.2. Informative References 10.2. Informative References
[I-D.huitema-quic-dnsoquic] [I-D.huitema-quic-dnsoquic]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J.
Iyengar, "Specification of DNS over Dedicated QUIC Iyengar, "Specification of DNS over Dedicated QUIC
Connections", draft-huitema-quic-dnsoquic-06 (work in Connections", draft-huitema-quic-dnsoquic-06 (work in
progress), March 2019. progress), March 2019.
[I-D.ietf-v6ops-nat64-deployment]
Palet, J., "Additional NAT64/464XLAT Deployment Guidelines
in Operator and Enterprise Networks", draft-ietf-v6ops-
nat64-deployment-06 (work in progress), May 2019.
[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>.
[RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
Transport Layer Security (DTLS)", RFC 8094, Transport Layer Security (DTLS)", RFC 8094,
DOI 10.17487/RFC8094, February 2017, DOI 10.17487/RFC8094, February 2017,
<https://www.rfc-editor.org/info/rfc8094>. <https://www.rfc-editor.org/info/rfc8094>.
 End of changes. 31 change blocks. 
90 lines changed or deleted 236 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/