1.3.1 Network Address Translation Traversal (NAT-T)

In the original IPsec specifications, the interposition of network address translation (NAT) devices between IPsec peers prevents correct IPsec operation. For more information about the incompatibilities, see [RFC3715] section 2.

Two specifications have been defined to address these incompatibilities. For more information about the User Datagram Protocol (UDP) encapsulation of ESP packets, see [RFC3948]. UDP-encapsulated ESP packets are correctly translated by NAT devices. [RFC3947] specifies an IKE extension to detect the presence of NAT devices between two IPsec peers and to negotiate the use of a UDP-encapsulated ESP.

Network address translation traversal (NAT-T) negotiation for IKE was first published as an Internet draft before becoming [RFC3947]. In [DRAFT-NATT], the IKE parameter numbers for NAT-T negotiation are chosen from the appropriate private use ranges, as specified in [IANAISAKMP]. In specification [RFC3947], different IKE parameter numbers were assigned by the Internet Assigned Numbers Authority (IANA). As a result, a [DRAFT-NATT]-compliant implementation is incompatible with an [RFC3947]-compliant implementation. For more information, see [DRAFT-NATT].

The NAT-T extension specified in this document enables IKE implementations supporting NAT-T to negotiate the use of either the [DRAFT-NATT] or the [RFC3947] parameters. This specification does not extend the NAT-T protocol itself. It negotiates only the interpretation of the NAT-T IKE parameter numbers. Also, this document specifies the support of NAT-T IKE for IPsec transport mode only.

The extension negotiates the use of the [DRAFT-NATT] or [RFC3947] parameters as follows:

  1. The host signals which revisions of the specification it supports (that is, [DRAFT-NATT], [RFC3947], or both) by sending vendor ID payloads ("RFC 3947" or "draft-ietf-ipsec-nat-t-ike-02\n") with its first IKE message. See section 1.7, Capability Negotiation.

  2. On receipt of the first IKE message from the peer, the host looks up the vendor ID payloads to determine which revision of the NAT-T protocol to use. If both revisions are supported by both hosts, preference is given to [RFC3947] over [DRAFT-NATT].

For details, see section 3.2.