[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

NAT Working Group                                          Matt Holdrege
INTERNET-DRAFT                                     Ascend Communications
Category: Informational                                   Pyda Srisuresh
                                                     Lucent Technologies
Expires in six months                                        August 1998

          IP Network Address Translator (NAT) Protocol Issues.

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Copyright Notice

Copyright  (C) The Internet Society (1998).  All Rights Reserved.


Many common internet applications can be adversely affected when the
end-to-end significance of an IP packet is disrupted. Network Address
Translation (NAT) can cause such disruptions both at the protocol level
and with application data. This draft covers issues with standard
protocols when transiting a NAT device.

It is worth noting that many non-standard protocols used on the Internet
also have issues with NAT devices. These include interactive games and
certain audio/video applications. However since such
applications/protocols are constantly coming and going, we will only
document long-living standard protocols in the main body. Please read
Appendix A for a current snapshot of non-standard protocols which are
known to have issues with NAT.

While there are ready solutions for NATing each protocol listed, this
document is only concerned with defining the native limitations. Future
versions of this document may discuss workarounds.

*NOTE* the authors wish to make it clear that this work is editorial in

Holdrege & Srisuresh                                            [Page 1]

I-D                       NAT Protocol Issues                August 1998

nature and that input from the Internet society is requested in order to
better cover the range of applications that can be affected by NAT. This
is a work in progress.


NAT provides a transparent routing solution to end hosts trying to
communicate from disparate routing realms. This transparent routing is
achieved by modifying end node addresses en-route and maintaining state
for these updates so that datagrams pertaining to a session are
transparently routed to the right end-node in either realm. NAT's
fundamental role is to alter the addresses in the IP header of a packet.

NAT can use much of the same solution set as a Stateful Inspection
firewall.  However, NAT must also be able to recompose valid data in the
control streams, since it must change the address (and perhaps port)
information. This is because the application running on a host machine
is typically unaware of NAT  and thus populates messages with addressing
information that is not valid on the opposite side of the NAT device.

One problem area is when a packet contains significant IP address or
port information in the payload of the packet rather than the header.
Network applications which use protocols that exhibit this behavior will
have problems when a NAT device is in mid-stream. In the next section we
will attempt to document standard protocols which have significant
address information in the payload of the packet.


1.      PROTOCOL:       FTP         REFERENCE:      RFC 959

FTP is a TCP based application, used to reliably transfer files between
two hosts.

FTP is initiated by a client accessing a well-known port number 21 on
the FTP server.  This is called the FTP control session. Often, an
additional data session accompanies the control session. By default, the
data session would be from TCP port 20 on server to the TCP port client
used to initiate control session. However, the data session ports may be
altered within the FTP control sessions using ASCII encoded PORT and
PASV commands and responses.

Say, an FTP client is in a NAT supported private network. NAT will be
required to monitor the FTP control session (for both PORT and PASV
modes) to identify the FTP data session port numbers and modify the
private address and port number with the externally valid address and
port number.  In addition, the sequence and acknowledgement numbers, TCP
checksum, IP packet length and checksum have to be updated. Consequently
the sequence numbers in all subsequent packets for that stream must be
adjusted as well as TCP ACK fields and checksums.

Another issue can arise when applications when addresses and port
numbers are encoded with ASCII. Changing these numbers can change the
size of the overall packet. In rare cases, increasing the size of the

Holdrege & Srisuresh                                            [Page 2]

I-D                       NAT Protocol Issues                August 1998

packet could cause it to exceed the MTU of a given transport link. The
packet would then have to be fragmented which could affect performance.
Or if the packet has the DF bit set, it would be ICMP rejected and the
originating host would then perform Path MTU Discovery. This could also
have an adverse effect on performance.

2.      PROTOCOL        H.323V1         REFERENCE       ITU-T SG16
H.323, Intel white paper, H.323 and Firewalls.  Dave Chouinard, John
Richardson, Milind Khare (with                         further
assistance from Jamie Jason).

H.323 is complex, uses dynamic ports, and includes multiple UDP streams.
Here is a summary of the relevant issues:

An H.323 call is made up of many different simultaneous connections. At
least two of the connections are TCP.  For an audio-only conference,
there may be up to 4 different UDP 'connections' made.

All connections except one are made to ephemeral (dynamic) ports.

Calls can be initiated from the Internet, as well as from inside the NAT
device. For conferencing to be useful, external users need to be able to
establish calls directly with internal users' desktop systems.

The addresses and port numbers are exchanged within the data stream of
the 'next higher' connection. For example, the port number for the H.245
connection is established within the Q.931 data stream. (This makes it
particularly difficult for NAT devices, which must modify the addresses
inside those data streams.)  To make matters worse, it is possible in
Q.931, for example, to specify that the H.245 connection should be
secure (encrypted).

Most of the control information is encoded in ASN.1 (only the User-User
Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded
(other parts of each Q.931 PDU are not encoded).  For those unfamiliar
with ASN.1, suffice it to say that it is a complex encoding scheme,
which does not end up with fixed byte offsets for address information.
In fact, the same version of the same application connecting to the same
destination may negotiate to include different options, changing the
byte offsets.

Below is the protocol exchange for a typical H.323 call between User A
and User B. A's IP address is and B's IP address is  Note that the Q.931 and H.245 messages are encoded in
ASN.1 in the payload of an RTP packet. So to accomplish a connection
through a NAT device, we would have to go into the packet, decode the
ASN.1, and translate the various H.323 control IP addresses.

User A                                                  User B
      A establishes connection to B on well-
      known Q.931 port (1720)

      Q.931 Setup caller address =

Holdrege & Srisuresh                                            [Page 3]

I-D                       NAT Protocol Issues                August 1998

                  caller port    = 1120
                  callee address =
                  callee port    = 1720
      Q.931 Alerting
      Q.931 Connect H.245 address =
                    H.245 port    = 1092

      User A establishes connection to User B at, port 1092

      Several H.245 messages are exchanged (Terminal
      Capability Set, Master Slave Determination and
      their respective ACKs)

      H.245 Open Logical Channel, channel = 257
                RTCP address =
                RTCP port    = 1093
      H.245 Open Logical Channel Ack, channel = 257
                RTP address =
                RTP port    = 2002
                (This is where User A would like RTP
                 data sent to)
                RTCP address =
                RTCP port    = 2003
      H.245 Open Logical Channel, channel = 257
                RTCP address =
                RTCP port    = 2003
      H.245 Open Logical Channel Ack, channel = 257
                RTP address =
                RTP port    = 1092
                (This is where User B would like RTP data
                 sent to)
                RTCP address =
                RTP port     = 1093

Also note that if an H.323 Gateway resided inside a NAT boundary, any of
the various gateway discovery schemes being discussed for use would have
difficulty working through NAT. Or if just the H.323 host/terminal was
inside the NAT boundary and tried to register with a Gatekeeper, the IP
information in the registration messages would have to be translated by

3.      PROTOCOL        RSVP         REFERENCE       RFC 2205

RSVP is positioned in the protocol stack at the transport layer,

Holdrege & Srisuresh                                            [Page 4]

I-D                       NAT Protocol Issues                August 1998

operating on top of IP (either IPv4 or IPv6). However, unlike other
transport protocols, RSVP does not transport application data but
instead acts like other Internet control protocols (for example, ICMP,
IGMP, routing protocols).  RSVP messages are sent hop-by-hop between
RSVP-capable routers as raw IP datagrams using protocol number 46. It is
intended that raw IP datagrams should be used between the end systems
and the first (or last) hop router.  However, this may not always be
possible as not all systems can do raw network I/O. Because of this, it
is possible to encapsulate RSVP messages within UDP datagrams for end-
system communication. UDP-encapsulated RSVP messages are sent to either
port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP-
enabled router). For more information concerning UDP encapsulation of
RSVP messages, consult Appendix C of RFC 2205.

An RSVP session, a data flow with a particular destination and
transport-layer protocol, is defined by:

Destination Address - the destination IP address for the data packets.
This may be either a unicast or a multicast address.

Protocol ID - the IP protocol ID (for example, UDP or TCP).

Destination Port - a generalized destination port which is used for
demultiplexing at a layer above the IP layer.

NAT devices are presented with unique problems when it comes to
supporting RSVP. Two issues are...

1. RSVP message objects may contain IP addresses. The result is that NAT
must be able to replace the IP addresses based upon the direction and
type of the message. For example, if an external sender were to send an
RSVP Path message to an internal receiver, the RSVP Session will specify
the IP address that the external sender believes is the IP address of
the internal receiver. However, when the RSVP Path message reaches the
NAT device, the RSVP Session must be changed to reflect the IP address
that is used internally for the receiver. Similar actions must be taken
for all message objects that contain IP addresses.

2. RSVP provides a means, the RSVP Integrity object, to guarantee the
integrity of RSVP messages. The problem is that because of the first
point, a NAT device must be able to change IP addresses within the RSVP
messages.  However, when this is done, the RSVP Integrity object is no
longer valid as the RSVP message has been changed.


Domain Names are an issue for hosts which use local DNS servers behind a
NAT device. Such servers return site specific information which may
conflict with true Internet names and addresses.

Also DNS Zone Transfers are not translated by NAT and should not be sent
through a NAT device.


Holdrege & Srisuresh                                            [Page 5]

I-D                       NAT Protocol Issues                August 1998

Routing updates from the Internet will not be translated through NAT and
have ni significance to routers behind a NAT device. Conversely routing
updates from behind NAT should not be forwarded to the Internet.


Another class of problems with NAT is end-to-end security of packets.
The IPsec AH standard [RFC 1826] is explicitly intended to prevent what
NAT is good at. That is altering the header of the packet. So when NAT
does what it is supposed to do by altering the address information in
the header of the packet, the destination host receives the altered
packet and begins digesting the AH message. The AH routines at this host
will invalidate the packet since the contents of the headers have been
altered. Depending on the configuration of the end host, the packet
could be simply dropped, or higher layer security activities could be

Other IPsec protocols with NAT issues:

Protocol        Issues

ESP:            Protects/obscures the packet contents (which would
                need to be visible for NATing some protocols).

IKE:            Potentially passes IP addresses during both Main,
                Aggressive and Quick Modes. In order for a negotiation
                to correctly pass through a NAT, these payloads would
                need to be modified.  However, these payloads are often
                protected by hash or obscured by encryption.

Authors Addresses:

   Matt Holdrege
   Ascend Communications, Inc.
   One Ascend Plaza
   1701 Harbor Bay Parkway
   Alameda, CA 94502
   Voice: (510) 769-6001
   EMail: matt@ascend.com

   Pyda Srisuresh
   Lucent technologies
   4464 Willow Road
   Pleasanton, CA 94588-8519
   Voice: (925) 737-2153
   EMail: suresh@ra.lucent.com

Appendix A:

Holdrege & Srisuresh                                            [Page 6]

I-D                       NAT Protocol Issues                August 1998

talk and ntalk







Holdrege & Srisuresh                                            [Page 7]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/