draft-ietf-v6ops-464xlat-optimization-00.txt   draft-ietf-v6ops-464xlat-optimization-01.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: July 17, 2020 Telecentro Expires: January 8, 2021 Telecentro
January 14, 2020 July 7, 2020
464XLAT/NAT64 Optimization 464XLAT/NAT64 Optimization
draft-ietf-v6ops-464xlat-optimization-00 draft-ietf-v6ops-464xlat-optimization-01
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
already available with IPv6. When SIIT is used as a stateless NAT46 already available with IPv6. When SIIT is used as a stateless NAT46
and IPv4-only devices or applications initiate traffic flows to dual- and IPv4-only devices or applications initiate traffic flows to dual-
stack services (in the operator network or Internet), those flows stack services (in the operator network or Internet), those flows
will be translated back to IPv4 by a NAT64. Avoiding this dual- will be translated back to IPv4 by a NAT64. Avoiding this dual-
translation will significantly reduce the usage of the NAT64 and the translation will significantly reduce the usage of the NAT64 and the
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 17, 2020. This Internet-Draft will expire on January 8, 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 5, line 20 skipping to change at page 5, line 20
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 Clearly all those aspects have impact in both, CapEx and OpEx. Clearly, all those aspects have impact in both, CapEx and OpEx. This
is extremely important when considering that most of the time, the
This is extremely important when considering that most of the time, contents stored in CDNs, caches, and so on, is there for a good
the 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
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.
skipping to change at page 9, line 32 skipping to change at page 9, line 32
Each EAMT entry will contain, the fields already described in Each EAMT entry will 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 be the one of the AAAA address), the TTL for the EAMT entry must set to the same value
RR. In normal conditions the TTL for both A and AAAA records, of as in the AAAA RR. In normal conditions the TTL for both A and
a given FQDN, should be the same, so this ensures a proper AAAA records, of a given FQDN, should be the same, so this
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
system, etc.) to disallow optimization for any IPv4 addresses. system, etc.) to disallow optimization for explicitly configured
IPv4 addresses.
7. Auto/Static: When set to 1, means that this EAMT entry has been 7. 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.), so
it doesn't expire with TTL. it doesn't expire with TTL.
When a new EAMT entry is first automatically created, it is marked as When a new EAMT entry is first automatically created, it is marked as
"Valid" and "Auto" (both bits cleared). If a subsequent A query, "Valid" and "Auto" (both bits cleared). If a subsequent A query,
with a different FQDN, results in an IPv4 address that has already an 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- EAMT entry and a different IPv6 address, it means that some reverse-
skipping to change at page 10, line 27 skipping to change at page 10, line 27
which allows to re-enable optimization if a new query for the A 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 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 affect the devices or applications, as they will still be able to use
the regular CLAT+NAT64 flow, of course, without the optimization. the regular CLAT+NAT64 flow, of course, without the optimization.
***** Open question regarding TTL and maybe FQDN and valid/auto bits. Note the newly defined EAMT fields, follow the "extensions" approach
Is this always a good thing to do for EAM? Should this document as per section 3.1 of [RFC7757].
update [RFC7757] to support this by default? Or it is just and
"extension" as per section 3.1 of [RFC7757].
5.2.4. Forwarding path via stateful NAT for existing EAMT entries 5.2.4. 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 IPv4-destination, the IPv6-native path pointed by the IPv6 address of
that EAMT entry, will take precedence versus the NAT64 path, so the that EAMT entry, will take precedence versus the NAT64 path, so the
traffic will not be forwarded to the NAT64. 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,
skipping to change at page 11, line 12 skipping to change at page 11, line 12
establish a forwarding path, but instead, to create a stateful NAT establish a forwarding path, but instead, 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.
5.2.5. Maintenance of the EAMT entries 5.2.5. Maintenance of the EAMT entries
The information in the EAMT MUST be kept timely-synchronized with the 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 AAAA records TTL's, so the EAMT entries MUST expire on the AAAA TTL
expiry and consequently be deleted. expiry and consequently be deleted.
However, EAMT entries with the Auto/Static bit set, will not be However, EAMT entries with the Auto/Static bit set, will not be
deleted. deleted. This allows users/operators to set explicit rules for
diagnostics or resolution of issues in special situations.
5.2.6. Usage example 5.2.6. 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
skipping to change at page 11, line 49 skipping to change at page 11, line 50
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 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.
5.2.8. Behavior in presence/absence of DNS64 5.2.8. Behavior in presence/absence of DNS64
This mechanism performs the same in both cases, if a DNS64 is This optimization performs the same in both cases: if a DNS64 is
present/used and if it is not present/used. This is explained present/used or if it is not present/used. This is explained because
because the mechanism is only relevant for destinations which don't the optimization is only relevant for destinations which already have
have AAAA records, and in those cases DNS64 is not relevant. AAAA records, and in those cases DNS64 is not relevant. Furthermore,
because as indicated in Section 5.2.2, the EAMT entry is not created
Furthermore, because as indicated in Section 5.2.2, the EAMT entry is when the service is IPv6-enabled. This is relevant because 464XLAT
not created when the service is IPv6-enabled. This is relevant can be deployed/used with and without a DNS64.
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 will be however optimized if devices or applications using DNS, They maybe optimized if devices or applications using DNS, at some
at some point, query for the same A RRs, or if EAMT entries are point, query for the same A RRs, or if EAMT entries are statically
statically configured. configured.
5.2.10. False detection of a dual-stack host as IPv4-only 5.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 entry will be created. 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 However, this EAMT entry may not be used by dual-stack devices or
applications, because those devices or applications should prefer applications, because those devices or applications should prefer
IPv6. If the host is preferring IPv4 for connecting to the CDN/cache 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, or IPv6-enabled service, it will be actually using the NAT46/CLAT,
skipping to change at page 13, line 11 skipping to change at page 13, line 12
actually considered as a good thing, in the sense that an operator is 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 interested in knowing as soon as possible, if the IPv6-only network
is not 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.
Note that when using 464XLAT, the WAN link of the NAT46/CLAT/CE is 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 IPv6-only. So even if Happy Eyeballs is present, the fallback to
IPv4-only typically, will be slower than native IPv6 itself, because IPv4-only typically, will be slower than native IPv6 itself, because
the added detail in the NAT46+NAT64 translations, when not using this the added delay in the NAT46+NAT64 translations, when not using this
optimization. optimization.
5.2.12. 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 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
[I-D.ietf-v6ops-nat64-deployment]. In the case the DNS is modified, [RFC8683]. In the case the DNS is modified, or some devices or
or some devices or applications use other DNS servers, the possible applications use other DNS servers, the possible scenarios and the
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 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
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 ([I-D.huitema-quic-dnsoquic]), [RFC8094]), DoH ([RFC8484]) or DoQ
will not make use of the stub/proxy resolver, so the same ([I-D.huitema-dprive-dnsoquic]), will not make use of the stub/
considerations as for the previous case apply. proxy resolver, so the same considerations as for the previous
case apply.
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
skipping to change at page 15, line 15 skipping to change at page 15, line 15
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 devices 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 (TBD: IPv6-only services get configured with an A resource record pointing
special allocated IANA IPv4 address), despite they aren't actually to a well-known IPv4 address despite they aren't actually connected
connected to IPv4. This will mean that those services will work fine to IPv4. This is out of scope for this document, as it will require
if there is a NAT46/CLAT. This A RR has no negative impact if the further work and a reservation by IANA, This will mean that those
NAT46/CLAT doesn't exist, because is not reachable via IPv4-only, so services will work fine if there is a NAT46/CLAT supporting the
is not a different situation than not having an A RR. optimization. This A RR has no negative impact if the NAT46/CLAT
doesn't exist, or it is not optimized, because is not reachable via
IPv4-only, so is not a different situation compared with not having
an A RR.
The result of this is equivalent to the approach taken by MAP-T The result of this is equivalent to the approach taken by MAP-T
(Section 12.3 of [RFC7599]). However, it has the advantage that the (Section 12.3 of [RFC7599]). However, it has the advantage that the
MAP-T approach is restricted to services in the MAP-T domain. MAP-T approach is restricted to services in the MAP-T domain.
TBD. In fact, it may become an incentive for the IPv6 deployment in In fact, it may become an incentive for the IPv6 deployment in
Internet services and provides the option to use an IPv4 address Internet services, as it provides the option to use a well-known IPv4
(maybe anycast) for the "non-valid" A RR, that points to a address (maybe anycast) for the "non-valid" A RR, that points, in
"universal" web page (maybe hosted by IANA or IETF?) that displays a case of port 80/443 to a web page or service that returns a warning
warning such as "You should contact your ISP; this service is only such as "This service is only available if the network is properly
available if the network is properly connected to Internet, which is connected to Internet with IPv6".
not the case.".
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
operator. 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 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. Should 464XLAT be updated SIIT already has a SHOULD for EAM support, so it is not a high
by this document so the CLAT has a MUST for EAM support?. additional burden the support required for existing implementations
to be updated for this optimization.
Should we recommend having A records for IPv6-only services in
Internet? The A record may point to a "reserved" or "special" IPv4
address. A web page IPv4-only hosted by IETF(?) showing "sorry this
web page/service is only available from IPv6 enabled operators"?.
Open question: Should we consider any other risks? If CE's
implementing this optimization create troubles, it may bring the
content providers to switch back to IPv4-only. So possible failure
cases need to be carefully considered for every possible solution
approach.
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.
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.
unless we decide to define a "special reserved IPv4 address". TBD.
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 TBD ...
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 17, line 42 skipping to change at page 17, line 36
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>.
11.2. Informative References 11.2. Informative References
[I-D.huitema-quic-dnsoquic] [I-D.huitema-dprive-dnsoquic]
Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Huitema, C., Mankin, A., and S. Dickinson, "Specification
Iyengar, "Specification of DNS over Dedicated QUIC of DNS over Dedicated QUIC Connections", draft-huitema-
Connections", draft-huitema-quic-dnsoquic-07 (work in dprive-dnsoquic-00 (work in progress), March 2020.
progress), September 2019.
[I-D.ietf-v6ops-nat64-deployment]
Palet, J., "Additional NAT64/464XLAT Deployment Guidelines
in Operator and Enterprise Networks", draft-ietf-v6ops-
nat64-deployment-08 (work in progress), July 2019.
[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>.
[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>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>. <https://www.rfc-editor.org/info/rfc8484>.
[RFC8683] Palet Martinez, J., "Additional Deployment Guidelines for
NAT64/464XLAT in Operator and Enterprise Networks",
RFC 8683, DOI 10.17487/RFC8683, November 2019,
<https://www.rfc-editor.org/info/rfc8683>.
Authors' Addresses Authors' Addresses
Jordi Palet Martinez Jordi Palet Martinez
The IPv6 Company The IPv6 Company
Molino de la Navata, 75 Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420 La Navata - Galapagar, Madrid 28420
Spain Spain
Email: jordi.palet@theipv6company.com Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/ URI: http://www.theipv6company.com/
 End of changes. 20 change blocks. 
75 lines changed or deleted 64 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/