Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
RFC 8683
| Document | Type | RFC - Informational (November 2019; No errata) | |
|---|---|---|---|
| Author | Jordi Palet Martinez | ||
| Last updated | 2019-11-26 | ||
| Replaces | draft-palet-v6ops-nat64-deployment | ||
| Stream | IETF | ||
| Formats | plain text html xml pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Mikael Abrahamsson | ||
| Shepherd write-up | Show (last changed 2019-06-07) | ||
| IESG | IESG state | RFC 8683 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Warren Kumari | ||
| Send notices to | Mikael Abrahamsson <swmike@swm.pp.se> | ||
| IANA | IANA review state | IANA OK - No Actions Needed | |
| IANA action state | No IANA Actions | ||
Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8683 The IPv6 Company
Category: Informational November 2019
ISSN: 2070-1721
Additional Deployment Guidelines for NAT64/464XLAT in Operator and
Enterprise Networks
Abstract
This document describes how Network Address and Protocol Translation
from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be
deployed in an IPv6 network -- whether it's cellular ISP, broadband
ISP, or enterprise -- and the possible optimizations. This document
also discusses issues to be considered when having IPv6-only
connectivity, such as: a) DNS64, b) applications or devices that use
literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only
hosts or applications.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8683.
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
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
2. Requirements Language
3. NAT64 Deployment Scenarios
3.1. Known to Work
3.1.1. Service Provider NAT64 with DNS64
3.1.2. Service Provider Offering 464XLAT Using DNS64
3.1.3. Service Provider Offering 464XLAT, without Using DNS64
3.2. Known to Work under Special Conditions
3.2.1. Service Provider NAT64 without DNS64
3.2.2. Service-Provider NAT64; DNS64 in IPv6 Hosts
3.2.3. Service-Provider NAT64; DNS64 in the IPv4-Only Remote
Network
3.3. Comparing the Scenarios
4. Issues to be Considered
4.1. DNSSEC Considerations and Possible Approaches
4.1.1. Not Using DNS64
4.1.2. DNSSEC Validator Aware of DNS64
4.1.3. Stub Validator
4.1.4. CLAT with DNS Proxy and Validator
4.1.5. ACL of Clients
4.1.6. Mapping Out IPv4 Addresses
4.2. DNS64 and Reverse Mapping
4.3. Using 464XLAT with/without DNS64
4.4. Foreign DNS
4.4.1. Manual Configuration of DNS
4.4.2. DNS Privacy/Encryption Mechanisms
4.4.3. Split DNS and VPNs
4.5. Well-Known Prefix (WKP) vs. Network-Specific Prefix (NSP)
4.6. IPv4 Literals and Non-IPv6-Compliant APIs
4.7. IPv4-Only Hosts or Applications
4.8. CLAT Translation Considerations
4.9. EAM Considerations
4.10. Incoming Connections
5. Summary of Deployment Recommendations for NAT64/464XLAT
6. Deployment of 464XLAT/NAT64 in Enterprise Networks
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Example of Broadband Deployment with 464XLAT
Appendix B. CLAT Implementation
Appendix C. Benchmarking
Acknowledgements
Author's Address
1. Introduction
Stateful NAT64 [RFC6146] describes a stateful IPv6-to-IPv4
translation mechanism that allows IPv6-only hosts to communicate with
IPv4-only servers using unicast UDP, TCP, or ICMP by means of IPv4
public address sharing among multiple IPv6-only hosts. Unless
otherwise stated, references to NAT64 (function) in this document
should be interpreted as Stateful NAT64.
The translation of the packet headers is done using the IP/ICMP
translation algorithm defined in [RFC7915]; algorithmically
translating the IPv4 addresses to IPv6 addresses, and vice versa, is
done following [RFC6052].
DNS64 [RFC6147] is in charge of the synthesis of AAAA records from
the A records, so it only works for applications making use of DNS.
It was designed to avoid changes in both the IPv6-only hosts and the
IPv4-only server, so they can use a NAT64 function. As discussed in
Show full document text