--- 1/draft-ietf-v6ops-nat64-deployment-05.txt 2019-05-04 06:13:15.957095523 -0700 +++ 2/draft-ietf-v6ops-nat64-deployment-06.txt 2019-05-04 06:13:16.045097745 -0700 @@ -1,19 +1,19 @@ v6ops J. Palet Martinez Internet-Draft The IPv6 Company -Intended status: Informational April 19, 2019 -Expires: October 21, 2019 +Intended status: Informational May 4, 2019 +Expires: November 5, 2019 Additional NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks - draft-ietf-v6ops-nat64-deployment-05 + draft-ietf-v6ops-nat64-deployment-06 Abstract This document describes how NAT64 (including 464XLAT) can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise, and possible optimizations. The document also discusses issues to be considered when having IPv6-only connectivity, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 21, 2019. + This Internet-Draft will expire on November 5, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -76,37 +76,39 @@ 4.2. DNS64 and Reverse Mapping . . . . . . . . . . . . . . . . 22 4.3. Using 464XLAT with/without DNS64 . . . . . . . . . . . . 22 4.4. Foreign DNS . . . . . . . . . . . . . . . . . . . . . . . 23 4.4.1. Manual Configuration of Foreign DNS . . . . . . . . . 24 4.4.2. DNS Privacy . . . . . . . . . . . . . . . . . . . . . 24 4.4.3. Split DNS . . . . . . . . . . . . . . . . . . . . . . 25 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) 25 4.6. IPv4 literals and old APIs . . . . . . . . . . . . . . . 25 4.7. IPv4-only Hosts or Applications . . . . . . . . . . . . . 26 4.8. CLAT Translation Considerations . . . . . . . . . . . . . 26 - 4.9. EAMT Considerations . . . . . . . . . . . . . . . . . . . 27 + 4.9. EAM Considerations . . . . . . . . . . . . . . . . . . . 27 + 4.10. Incoming Connections . . . . . . . . . . . . . . . . . . 27 5. Summary of Deployment Recommendations for NAT64/464XLAT . . . 27 6. Deployment of NAT64 in Enterprise Networks . . . . . . . . . 30 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 10. ANNEX A: Example of Broadband Deployment with 464XLAT . . . . 32 11. ANNEX B: CLAT Implementation . . . . . . . . . . . . . . . . 36 - 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 36 - 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 36 + 12. ANNEX C: Benchmarking . . . . . . . . . . . . . . . . . . . . 37 + 13. ANNEX D: Changes from -00 to -01/-02 . . . . . . . . . . . . 37 14. ANNEX E: Changes from -02 to -03 . . . . . . . . . . . . . . 37 - 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 37 - 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 37 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 37 - 17.2. Informative References . . . . . . . . . . . . . . . . . 39 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 + 15. ANNEX F: Changes from -03 to -04 . . . . . . . . . . . . . . 38 + 16. ANNEX G: Changes from -04 to -05 . . . . . . . . . . . . . . 38 + 17. ANNEX H: Changes from -05 to -06 . . . . . . . . . . . . . . 38 + 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 18.1. Normative References . . . . . . . . . . . . . . . . . . 38 + 18.2. Informative References . . . . . . . . . . . . . . . . . 41 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction Stateful NAT64 ([RFC6146]) describes a stateful IPv6 to IPv4 translation mechanism, which allows IPv6-only hosts to communicate with IPv4-only servers using unicast UDP, TCP, or ICMP, by means of IPv4 public addresses sharing, among multiple IPv6-only hosts. Unless otherwise stated, references in the rest of this document to NAT64 (function) should be interpreted as to Stateful NAT64. @@ -292,23 +294,23 @@ | | +----------+ +----+-----+ | | | | | IPv6 +--------+ DNS64 + | | | | +----------+ +----------+ Figure 2: NAT64 in external service provider - As well, is equivalent to the scenario where the outsourcing - agreement with the external provider is to provide both the NAT64 and - DNS64 functions. Once more, all the considerations in the previous + This is equivalent to the scenario where the outsourcing agreement + with the external provider is to provide both the NAT64 and DNS64 + functions. Once more, all the considerations in the previous paragraphs of this section are the same for this sub-case. +----------+ +----------+ | extNAT64 | | | | + +-------+ IPv4 | | extDNS64 | | | +----+-----+ +----------+ | +----------+ | | | | @@ -435,31 +437,31 @@ The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: DNS64 and NAT64 translation. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT - implements EAMT as indicated by Section 4.9. In principle, it is - not expected that services are deployed in Internet using - IPv6-only, unless there is certainty that peers will also be - IPv6-capable. + implements EAM (Explicit Address Mappings) as indicated by + Section 4.9. In principle, it is not expected that services are + deployed in Internet using IPv6-only, unless there is certainty + that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: DNS64, CLAT and NAT64 translations. - e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the - CLAT implements EAMT as indicated by Section 4.9, instead of - using the path d. above, NAT64 translation is avoided and the - flow will use IPv6 from the CLAT to the destination. + e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the + CLAT implements EAM as indicated by Section 4.9, instead of using + the path d. above, NAT64 translation is avoided and the flow will + use IPv6 from the CLAT to the destination. The rest of the figures in this section show different choices for placing the different elements. +----------+ +----------+ +----------+ | IPv6 | | NAT64 | | | | + +--------+ + +--------+ IPv4 | | CLAT | | DNS64 | | | +----------+ +----------+ +----------+ @@ -502,22 +504,22 @@ | CLAT | +----------+ Figure 7: 464XLAT with DNS64; NAT64 and DNS64 in external provider 3.1.3. Service Provider Offering 464XLAT, without DNS64 The major advantage of this scenario, using 464XLAT without DNS64, is that the service provider ensures that DNSSEC is never broken, even in case the user modifies the DNS configuration. Nevertheless, some - CLAT implementations or applications may expose an extra delay, which - is inducted by the dual A/AAAA queries (and wait for both responses), + CLAT implementations or applications may impose an extra delay, which + is induced by the dual A/AAAA queries (and wait for both responses), unless Happy Eyeballs v2 (HEv2, [RFC8305]) is also present. A possible variation of this scenario is the case when DNS64 is used only for the discovery of the NAT64 prefix. The rest of the document is not considering it as a different scenario, because once the prefix has been discovered, the DNS64 function is not used, so it behaves as if the DNS64 synthesis function is not present. In this scenario, as in the previous one, there are no issues related to IPv4-only hosts (or IPv4-only applications) behind the IPv6-only @@ -557,32 +559,32 @@ The possible communication paths, among the IPv4/IPv6 stacks of both peers, in this case, are: a. Local-IPv6 to Remote-IPv6: Regular DNS and native IPv6 among peers. b. Local-IPv6 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. c. Local-IPv4 to Remote-IPv6: Not possible unless the CLAT - implements EAMT as indicated by Section 4.9. In principle, it is + implements EAM as indicated by Section 4.9. In principle, it is not expected that services are deployed in Internet using IPv6-only, unless there is certainty that peers will also be IPv6-capable. d. Local-IPv4 to Remote-IPv4: Regular DNS, CLAT and NAT64 translations. - e. Local-IPv4 to Remote-dual-stack using EAMT optimization: If the - CLAT implements EAMT as indicated by Section 4.9, instead of - using the path d. above, NAT64 translation is avoided and the - flow will use IPv6 from the CLAT to the destination. + e. Local-IPv4 to Remote-dual-stack using EAM optimization: If the + CLAT implements EAM as indicated by Section 4.9, instead of using + the path d. above, NAT64 translation is avoided and the flow will + use IPv6 from the CLAT to the destination. It needs to be noticed that this scenario works while the local hosts/applications are dual-stack (which is the current situation), because the connectivity from a local-IPv6 to a remote-IPv4 is not possible without an AAAA synthesis. This aspect is important only when in the LANs behind the CLAT there are IPv6-only hosts and they need to communicate with remote IPv4-only hosts. However, it doesn't look a sensible approach from an Operating System or application vendor perspective, to provide IPv6-only support unless, similarly to case c above, there is certainty of peers supporting IPv6 as well. A @@ -760,25 +762,25 @@ the previous sections, by the figure number. The possible values are: o "-" Scenario "bad" for that criteria. o "+" Scenario "good" for that criteria. o "*" Scenario "bad" for that criteria, however it is typically resolved, with the support of HEv2 ([RFC8305]). - In some cases "countermeasures", alternative or special + In some cases, "countermeasures", alternative or special configurations, may be available for the criteria designated as - "bad". So this comparison is considering a generic case, as a quick - comparison guide. In some cases, a "bad" criteria is not necessarily - a negative aspect, all it depends on the specific needs/ + "bad". So, this comparison is considering a generic case, as a quick + comparison guide. In some cases, a "bad" criterion is not + necessarily a negative aspect, all it depends on the specific needs/ characteristics of the network where the deployment will take place. For instance, in a network which has only IPv6-only hosts and apps using only DNS and IPv6-compliant APIs, there is no impact using only NAT64 and DNS64, but if the hosts may validate DNSSEC, that item is still relevant. +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | Item / Figure | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | +----------------+---+---+---+---+---+---+---+---+---+----+----+----+ | DNSSEC | - | - | - | - | - | - | - | + | + | + | + | + | @@ -1060,57 +1062,57 @@ will be done at the NAT64. This may break DNSSEC, unless measures as described in the precedent sections are taken. 2. Without DNS64: If DNS64 is not used, all the IPv4 traffic will make use of the CLAT, so two translations are required (NAT46 at the CLAT and NAT64 at the PLAT), which adds some overhead in terms of the extra NAT46 translation. However, this avoids the AAAA synthesis and consequently will never break DNSSEC. Note that the extra translation, when DNS64 is not used, takes place - at the CLAT, which means no extra overhead for the operator. - However, adds potential extra delays to establish the connections, - and no perceptible impact for a CE in a broadband network, while it - may have some impact in a battery powered device. This cost for a + at the CLAT, which means no extra overhead for the operator. It + however adds potential extra delays to establish the connections, and + no perceptible impact for a CE in a broadband network, while it may + have some impact in a battery powered device. This cost for a battery powered device, is possibly comparable to the cost when the device is doing a local address synthesis (see Section 7.1 of [RFC8305]). 4.4. Foreign DNS Clients, devices or applications in a service provider network, may use DNS servers from other networks. This may be the case either if individual applications use their own DNS server, the Operating System itself or even the CE, or combinations of the above. Those "foreign" DNS servers may not support DNS64, which will mean that those scenarios that require a DNS64 may not work. However, if a CLAT function is available, the considerations in Section 4.3 will apply. In the case that the foreign DNS supports the DNS64 function, we may be in the situation of providing incorrect configurations parameters, - for example un-matching WKP or NSP, or a case such the one described + for example, un-matching WKP or NSP, or a case such the one described in Section 3.2.3. Having a CLAT function, even if using foreign DNS without a DNS64 function, ensures that everything will work, so the CLAT must be considered as an advantage even against user configuration errors. The cost of this, is that all the traffic will use a double translation (NAT46 at the CLAT and NAT64 at the operator network), - unless there is support for EAMT (Section 4.9). + unless there is support for EAM (Section 4.9). An exception to that is the case when there is a CLAT function at the CE, which is not able to obtain the correct configuration parameters (again, un-matching WKP or NSP). - However, it needs to be reinforced, that if there is not a CLAT + However, it needs to be emphasized, that if there is not a CLAT function (scenarios without 464XLAT), an external DNS without DNS64 support, will disallow any access to IPv4-only destination networks, and will not guarantee DNSSEC, so will behave as in the Section 3.2.1. The causes of "foreign DNS" could be classified in three main categories, as depicted in the following sub-sections. 4.4.1. Manual Configuration of Foreign DNS @@ -1137,21 +1139,21 @@ When networks or hosts use "split-DNS" (also called Split Horizon, DNS views or private DNS), the successful use of the DNS64 is not guaranteed. Section 4 of [RFC6950], analyses this case. A similar situation may happen in case of VPNs that force all the DNS queries through the VPN, ignoring the operator DNS64 function. 4.5. Well-Known Prefix (WKP) vs Network-Specific Prefix (NSP) - [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), Section 3, + Section 3 of [RFC6052] (IPv6 Addressing of IPv4/IPv6 Translators), discusses some considerations which are useful to decide if an operator should use the WKP or an NSP. Taking in consideration that discussion and other issues, we can summarize the possible decision points as: a. The WKP MUST NOT be used to represent non-global IPv4 addresses. If this is required because the network to be translated use non- global addresses, then an NSP is required. @@ -1225,36 +1227,55 @@ translation. This is also possible when broadband is provided by a cellular access. The above recommendation is often not possible for cellular networks, when connecting smartphones (as UEs), as generally they don't use DHCPv6-PD ([RFC8415]). Instead, a single /64 is provided for each PDP context and prefix sharing ([RFC6877]) is used. So, in this case, the UEs typically have a build-in CLAT function which is performing a stateful NAT44 translation before the stateless NAT46. -4.9. EAMT Considerations +4.9. EAM Considerations Explicit Address Mappings for Stateless IP/ICMP Translation ([RFC7757]) provide a way to configure explicit mappings between IPv4 and IPv6 prefixes of any length. When this is used, for example in a CLAT function, it may provide a simple mechanism in order to avoid traffic flows between IPv4-only nodes or applications and dual-stack destinations to be translated twice (NAT46 and NAT64), by creating mapping entries with the GUA of the IPv6-reachable destination. This optimization of the NAT64 usage is very useful in many scenarios, including CDNs and caches, as described in [I-D.palet-v6ops-464xlat-opt-cdn-caches]. In addition to that, it may provide as well a way for IPv4-only nodes or applications to communicate with IPv6-only destinations. +4.10. Incoming Connections + + The use of NAT64, in principle, disallows IPv4 incoming connections, + which may be still needed for IPv4-only peer-to-peer applications. + However, there are several alternatives that resolve this issue: + + a. STUN ([RFC5389]), TURN ([RFC5766]) and ICE ([RFC8445]) are + commonly used by peer-to-peer applications in order to allow + incoming connections with IPv4 NAT. In the case of NAT64, they + work as well. + + b. PCP ([RFC6887]) allows a host to control how incoming IPv4 and + IPv6 packets are translated and forwarded. A NAT64 may implement + PCP to allow this service. + + c. EAM ([RFC7757]) may also be used in order to configure explicit + mappings for customers that require them. This is used for + example by SIIT-DC ([RFC7755]) and SIIT-DC-DTM ([RFC7756]). + 5. Summary of Deployment Recommendations for NAT64/464XLAT NAT64/464XLAT has demonstrated to be a valid choice in several scenarios (IPv6-IPv4 and IPv4-IPv6-IPv4), with hundreds of millions of users, offering different choices of deployment, depending on each network case, needs and requirements. Despite that, this document is not an explicit recommendation for using this choice versus other IPv4aaS transition mechanisms. Instead, this document is a guide that facilitates evaluating a possible implementation of NAT64/464XLAT and key decision points about specific design @@ -1306,21 +1327,22 @@ the CLAT (Section 4.3). If DNS64 is not used, at least one of the alternatives described in Section 4.1.1, must be followed in order to learn he NAT64 prefix. The operator needs to consider that if the DNS configuration can be modified (Section 4.4, Section 4.4.2, Section 4.4.3), which most probably is impossible to avoid, there are chances that instead of configuring a DNS64 a foreign non-DNS64 is used. In a scenario with only a NAT64 function IPv4-only remote host will no longer be - accesible. Instead, it will continue to work in the case of 464XLAT. + accessible. Instead, it will continue to work in the case of + 464XLAT. Similar considerations need to be taken regarding the usage of a NAT64 WKP vs NSP (Section 4.5), as they must match with the configuration of the DNS64. In case of using foreign DNS, they may not match. If there is a CLAT and the configured foreign DNS is not a DNS64, the network will keep working only if other means of learning the NAT64 prefix are available. As described in Section 4.8, for broadband networks, the CEs supporting a CLAT function, SHOULD support DHCPv6-PD ([RFC8415]), or @@ -1377,23 +1399,27 @@ The only 100% safe solution, which also resolves all the issues, will be, in addition to having a CLAT function, not using a DNS64 but instead making sure that the hosts have a built-in address synthesis feature. Operators could manage to provide CEs with the CLAT function, however the built-in address synthesis feature is out of their control. If the synthesis is provided either by the Operating System (via its DNS resolver API) or by the application (via its own DNS resolver), in such way that the prefix used for the NAT64 function is reachable for the host, the problem goes away. - Whenever feasible, using EAMT ([RFC7757]) as indicated in - Section 4.9, provides a very relevant optimization, avoiding double- - translations. + Whenever feasible, using EAM ([RFC7757]) as indicated in Section 4.9, + provides a very relevant optimization, avoiding double-translations. + + Applications that require incoming connections, typically already + provide means for that. However, PCP and EAM, as indicated in + Section 4.10, are valid alternatives, even for creating explicit + mappings for customers that require them. 6. Deployment of NAT64 in Enterprise Networks The recommendations of this document can be used as well in enterprise networks, campus and other similar scenarios (including managed end-user networks). This include scenarios where the NAT64 function (and DNS64 function, if available) are under the control of that network (or can be configured manually according to that network specific requirements), @@ -1550,23 +1576,21 @@ of [RFC7225], or other alternatives that may be available in the future, such as Router Advertising ([I-D.ietf-6man-ra-pref64]) or DHCPv6 options ([I-D.li-intarea-nat64-prefix-dhcp-option]). 2. If the CLAT function allows stateless NAT46 translation, a /64 from the pool typically provided to the CE by means of DHCPv6-PD [RFC8415], need to be set aside for that translation. Otherwise, the CLAT is forced to perform an intermediate stateful NAT44 before the a stateless NAT46, as described in Section 4.8. - A more detailed configuration approach is described in - - [I-D.ietf-v6ops-transition-ipv4aas]. + A more detailed configuration approach is described in [RFC8585]. The operator network needs to ensure that the correct responses are provided for the discovery of the PLAT prefix. It is highly recommended to follow [RIPE-690], in order to ensure that multiple /64s are available, including the one needed for the NAT46 stateless translation. The operator needs to understand other issues, described across this document, in order to take the relevant decisions. For example, if several NAT64 functions are needed in the context of scalability/ @@ -1599,21 +1623,21 @@ Figure 18: CE setup with built-in CLAT without DNS64 In this case, the discovery of the PLAT prefix needs to be arranged as indicated in Section 4.1.1. In this case, the CE doesn't have a built-in CLAT function, or the customer can choose to setup the IPv6 operator-managed CE in bridge mode (and optionally use an external router), or for example, there is an access technology that requires some kind of media converter - (ONT for FTTH, CableModem for DOCSIS, etc.), the complete setup will + (ONT for FTTH, Cable-Modem for DOCSIS, etc.), the complete setup will look as in the next figure. Obviously, there will be some intermediate configuration steps for the bridge, depending on the specific access technology/protocols, which should not modify the steps already described in the previous cases for the CLAT function configuration. +-------+ .-----. .-----. | | / \ / \ | Res./ | / IPv6- \ .-----. / IPv4- \ | SOHO +--( only )--( NAT64 )--( only ) @@ -1644,21 +1668,21 @@ Figure 19: CE setup with bridged CLAT without DNS64 It should be avoided that several routers (i.e., the operator provided CE and a downstream user provided router) enable simultaneously routing and/or CLAT, in order to avoid multiple NAT44 and NAT46 levels, as well as ensuring the correct operation of multiple IPv6 subnets. In those cases, it is suggested the use of HNCP ([RFC8375]). Note that the procedure described here for the CE setup, can be - simplified if the CE follows [I-D.ietf-v6ops-transition-ipv4aas]. + simplified if the CE follows [RFC8585]. 11. ANNEX B: CLAT Implementation In addition to the regular set of features for a CE, a CLAT CE implementation requires support of: o [RFC7915] for the NAT46 function. o [RFC7050] for the PLAT prefix discovery. @@ -1707,50 +1731,71 @@ 2. Reference to RFC8273 and on-demand IPv4-in-IPv6 VPN for IPv6-only LANs w/o DNS64. 3. Overall review and editorial changes. 15. ANNEX F: Changes from -03 to -04 Section to be removed after WGLC. Significant updates are: - 1. Added text related to EAMT considerations. + 1. Added text related to EAM considerations. 16. ANNEX G: Changes from -04 to -05 Section to be removed after WGLC. Significant updates are: - 1. Added cross references to EAMT section. + 1. Added cross references to EAM section. 2. Reworded "foreing DNS section". 3. Overall editorial review of text, pictures and nits correction. -17. References +17. ANNEX H: Changes from -05 to -06 -17.1. Normative References + Section to be removed after WGLC. Significant updates are: + + 1. Corrected EAMT to EAM. + + 2. Typos and nits. + + 3. New considerations regarding incoming connections. + +18. References + +18.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + DOI 10.17487/RFC5389, October 2008, + . + [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, . + [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using + Relays around NAT (TURN): Relay Extensions to Session + Traversal Utilities for NAT (STUN)", RFC 5766, + DOI 10.17487/RFC5766, April 2010, + . + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, . [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful @@ -1767,20 +1812,25 @@ [RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . + [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and + P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, + DOI 10.17487/RFC6887, April 2013, + . + [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, . [RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, . @@ -1810,25 +1860,31 @@ [RFC8375] Pfister, P. and T. Lemon, "Special-Use Domain 'home.arpa.'", RFC 8375, DOI 10.17487/RFC8375, May 2018, . [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . + [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive + Connectivity Establishment (ICE): A Protocol for Network + Address Translator (NAT) Traversal", RFC 8445, + DOI 10.17487/RFC8445, July 2018, + . + [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . -17.2. Informative References +18.2. Informative References [About-DNS64] Linkova, J., "Let's talk about IPv6 DNS64 & DNSSEC", 2016, . [DNS64-Benchm] Lencse, G. and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications , vol. 127, no. 1, pp. 61-74, @@ -1849,31 +1905,25 @@ Huitema, C., Shore, M., Mankin, A., Dickinson, S., and J. Iyengar, "Specification of DNS over Dedicated QUIC Connections", draft-huitema-quic-dnsoquic-06 (work in progress), March 2019. [I-D.ietf-6man-ra-pref64] Colitti, L., Kline, E., and J. Linkova, "Discovering PREF64 in Router Advertisements", draft-ietf-6man-ra- pref64-00 (work in progress), March 2019. - [I-D.ietf-v6ops-transition-ipv4aas] - Palet, J., Liu, H., and M. Kawashima, "Requirements for - IPv6 Customer Edge Routers to Support IPv4 Connectivity - as-a-Service", draft-ietf-v6ops-transition-ipv4aas-15 - (work in progress), January 2019. - [I-D.li-intarea-nat64-prefix-dhcp-option] Li, L., Cui, Y., Liu, C., Wu, J., Baker, F., and J. Palet, "DHCPv6 Options for Discovery NAT64 Prefixes", draft-li- - intarea-nat64-prefix-dhcp-option-01 (work in progress), - March 2017. + intarea-nat64-prefix-dhcp-option-02 (work in progress), + April 2019. [I-D.lmhp-v6ops-transition-comparison] Lencse, G., Palet, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", draft-lmhp-v6ops-transition-comparison-02 (work in progress), January 2019. [I-D.palet-v6ops-464xlat-opt-cdn-caches] Palet, J. and A. D'Egidio, "464XLAT Optimization for CDNs/ Caches", draft-palet-v6ops-464xlat-opt-cdn-caches-01 (work @@ -1897,20 +1947,31 @@ [RFC7051] Korhonen, J., Ed. and T. Savolainen, Ed., "Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix", RFC 7051, DOI 10.17487/RFC7051, November 2013, . [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, . + [RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for + IPv6 Data Center Environments", RFC 7755, + DOI 10.17487/RFC7755, February 2016, + . + + [RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP + Translation for IPv6 Internet Data Center Environments + (SIIT-DC): Dual Translation Mode", RFC 7756, + DOI 10.17487/RFC7756, February 2016, + . + [RFC7849] Binet, D., Boucadair, M., Vizdal, A., Chen, G., Heatley, N., Chandler, R., Michaud, D., Lopez, D., and W. Haeffner, "An IPv6 Profile for 3GPP Mobile Devices", RFC 7849, DOI 10.17487/RFC7849, May 2016, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . @@ -1918,20 +1979,25 @@ [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/RFC8094, February 2017, . [RFC8219] Georgescu, M., Pislaru, L., and G. Lencse, "Benchmarking Methodology for IPv6 Transition Technologies", RFC 8219, DOI 10.17487/RFC8219, August 2017, . + [RFC8585] Palet Martinez, J., Liu, H., and M. Kawashima, + "Requirements for IPv6 Customer Edge Routers to Support + IPv4-as-a-Service", RFC 8585, DOI 10.17487/RFC8585, May + 2019, . + [RIPE-690] RIPE, "Best Current Operational Practice for Operators: IPv6 prefix assignment for end-users - persistent vs non- persistent, and what size to choose", October 2017, . [Threat-DNS64] Lencse, G. and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and