Protocol Complications with the IP Network Address Translator
RFC 3027
|
Document |
Type |
|
RFC - Informational
(January 2001; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
WG Document
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3027 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group M. Holdrege
Request for Comments: 3027 ipVerse
Category: Informational P. Srisuresh
Jasmine Networks
January 2001
Protocol Complications with the IP Network Address Translator
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Many internet applications can be adversely affected when end nodes
are not in the same address realm and seek the assistance of an IP
Network Address Translator (NAT) enroute to bridge the realms. The
NAT device alone cannot provide the necessary application/protocol
transparency in all cases and seeks the assistance of Application
Level Gateways (ALGs) where possible, to provide transparency. The
purpose of this document is to identify the protocols and
applications that break with NAT enroute. The document also attempts
to identify any known workarounds. It is not possible to capture all
applications that break with NAT in a single document. This document
attempts to capture as much information as possible, but is by no
means a comprehensive coverage. We hope the coverage provides
sufficient clues for applications not covered.
Table of Contents
1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 20
Holdrege & Srisuresh Informational [Page 1]
RFC 3027 Protocol Complications with NAT January 2001
1.0 Introduction
This document requires the reader to be familiar with the terminology
and function of NAT devices as described in [NAT-TERM]. In a
nutshell, NAT attempts to provide a transparent routing solution to
end hosts requiring communication to disparate address realms. NAT
modifies end node addresses (within the IP header of a packet) en-
route and maintains state for these updates so that datagrams
pertaining to a session are transparently routed to the right end-
node in either realm. Where possible, application specific ALGs may
be used in conjunction with NAT to provide application level
transparency. Unlike NAT, the function of ALG is application
specific and would likely require examination and recomposition of IP
payload.
The following sections attempt to list applications that are known to
have been impacted by NAT devices enroute. However, this is by no
means a comprehensive list of all known protocols and applications
that have complications with NAT - rather just a subset of the list
gathered by the authors. It is also important to note that this
document is not intended to advocate NAT, but rather to point out the
complications with protocols and applications when NAT devices are
enroute.
2.0 Common Characteristics of Protocols broken by NAT
[NAT-TERM] and [NAT-TRAD] have sections listing the specific nature
of problems and limitations to NAT devices. Some of these
limitations are being restated in this section to summarize
characteristics of protocols that are broken by NAT.
2.1 Realm-specific IP address information in payload
A wide range of applications fail with NAT enroute when IP packets
contain realm-specific IP address or port information in payload. An
ALG may be able to provide work around in some cases. But, if the
packet payload is IPsec secured (or secure by a transport or
application level security mechanisms), the application is bound to
fail.
2.2 Bundled session applications
Bundled session applications such as FTP, H.323, SIP and RTSP, which
use a control connection to establish a data flow are also usually
broken by NAT devices enroute. This is because these applications
exchange address and port parameters within control session to
establish data sessions and session orientations. NAT cannot know
the inter-dependency of the bundled sessions and would treat each
Holdrege & Srisuresh Informational [Page 2]
Show full document text