Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks
RFC 8683

Document Type RFC - Informational (November 2019; No errata)
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)
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