RFC 3715 (rfc3715) - Page 2 of 18
IPsec-Network Address Translation (NAT) Compatibility Requirements
Alternative Format: Original Text Document
RFC 3715 IPsec-NAT Compatibility Requirements March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language. . . . . . . . . . . . . . . . . . 2 2. Known Incompatibilities between NA(P)T and IPsec . . . . . . . 3 2.1. Intrinsic NA(P)T Issues. . . . . . . . . . . . . . . . . 3 2.2. NA(P)T Implementation Weaknesses . . . . . . . . . . . . 7 2.3. Helper Incompatibilities . . . . . . . . . . . . . . . . 8 3. Requirements for IPsec-NAT Compatibility . . . . . . . . . . . 8 4. Existing Solutions . . . . . . . . . . . . . . . . . . . . . . 12 4.1. IPsec Tunnel Mode. . . . . . . . . . . . . . . . . . . . 12 4.2. RSIP . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 9 . Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 1. Introduction Perhaps the most common use of IPsec [RFC 2401] is in providing virtual private networking (VPN) capabilities. One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Today, Network Address Translations (NATs) as described in [RFC 3022] and [RFC 2663], are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment of IPsec in one of its principal uses. This document describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them. 1.1. Requirements Language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC 2119]. Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is not the same thing as requiring that all protocol traffic be encrypted. Aboba & Dixon Informational



