NAT Working Group                                          Matt Holdrege
INTERNET-DRAFT                              	                 ipVerse
Category: Informational                                   Pyda Srisuresh
Expires as of January 14, 2001                	   Campio Communications
Expires in six months                                          July
                                                              July, 2000

     Protocol Complications with the IP Network Address Translator (NAT)
             <draft-ietf-nat-protocol-complications-03.txt>
             <draft-ietf-nat-protocol-complications-04.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance
   with all provisions of Section 10 of RFC2026.

   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."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   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 (2000).  All Rights Reserved.

Abstract:

   Many common internet applications can be adversely affected when the
   communicating end nodes are not in the same address realm and seek
   the assistance of NAT (enroute) enroute to bridge the realms. NAT by itself device
   cannot provide the necessary application/protocol transparency in
   all cases.
Often, a NAT device cases and seeks the assistance of Application Level Gateways
   (ALGs) where possible, to provide the transparency necessary for each application. transparency. The purpose of
   this document is to identify the protocols and applications that cannot function
   break with NAT enroute. The document also attempts to identify
the problem cause and describe
   any known work-arounds and the requirements
on the part of ALGs to make the protocols/applications transparent with
NAT enroute. workarounds. It is impossible to capture all the
   applications and their
issues that break with NAT in a single document. This
   document attempts to capture as much of the information as possible.
   possible, but is by no means a comprehensive coverage. We hope
   this coverage provides necessary clues for applications not
   covered by the document.

Table of Contents

   1.0 Introduction

   2.0 Common Characteristics of Protocols which require an ALG

I-D                  Protocol Complications with broken by NAT           July 2000

   3.0 Protocols which do not require that cannot work with NAT enroute

   4.0 Protocols that can work with the aid of an ALG

4.0  Routing Updates

   5.0 Protocols which cannot designed explicitly to work with NAT enroute

   6.0  Protocols which may have complications with NAT Acknowledgements

   7.0     Other issues Security Considerations

   8.0     Authors

9.0 References

   9.0  Authors Addresses

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 that
need to communicate 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. NAT's fundamental role is to alter the
addresses Where possible, application specific
ALGs may be used in conjunction with NAT to provide application level
transparency. Unlike NAT, the IP header function of a packet.

NAT can use much ALG is application specific
and would likely require examination and recomposition of the same solution set as a Stateful Inspection
Firewall. However, the ALG's IP payload.

The following sections attempt to list applications that complement NAT must also be able are known
to
recompose valid data in the payload, since it must change the address
(and perhaps port) information. This have been impacted by NAT devices enroute. However, this is because the application running
on by no
means a host machine is typically unaware comprehensive list of NAT all known protocols and may populate messages applications
that have complications with addressing information as required by NAT - rather just a subset of the application protocol and list
gathered by the addressing information may authors. It is also important to note that this
document is not be valid on intended to advocate NAT, but rather to point out
the opposite side 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 device.

One problem area is 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 a packet contains significant IP packets
contain realm-specific IP address or port information in the payload of payload.
An ALG may be able to provide work around in some cases. But,
if the packet rather than payload is IPsec secured (or secure by a transport
or application level security mechanisms), the header.
Protocols that application is
bound to fail.

2.2 Bundled session applications

Bundled session applications such as FTP, H.323, SIP and RTSP, which
use one a control connection to establish another a data flow are
adversely impacted also usually
broken by NAT. In the next section we will attempt to
document standard protocols which have significant NAT devices enroute. This is because these applications
exchange address information
in and port parameters within control session to
establish data sessions and session orientations. NAT cannot know
the payload inter-dependency of the packet.

Where this document mentions NAT, it is referring bundled sessions and would treat each
session to Traditional NAT
rather than other NAT techniques.

IP Fragmentation can be unrelated to one another. Applications in this case
can fail for a significant problem with NAT. It is not a
protocol problem per se, however the difficulty it presents should be
examined. See draft-ietf-nat-traditional-03.txt and RFC 2663 variety of reasons. Two most likely reasons for more
failures are:  (a) addressing information on NAT in control payload is
realm-specific and IP Fragmentation.

*NOTE* the authors wish to make it clear that this work is editorial in
nature. Input from not valid once packet crosses the Internet society is requested in order originating
realm, (b) control session permits data session(s) to better
cover the range of applications that can be affected by NAT. This is originate in
a
work direction that NAT might not permit.

When DNS names are used in progress.

2.0  Protocols which require ALG's

I-D                  Protocol Complications with control payload, NAT           July 2000

2.1  Single Session based protocols

2.1.1     RSVP

RSVP is positioned device in conjunction
with a DNS-ALG might be able to offer the protocol stack at the transport layer,
operating on top of IP (either IPv4 or IPv6). However, unlike other
transport protocols, RSVP does not transport necessary application level
transparency, if NAT has no contention with 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 session orientation.
However, using protocol number 46. It is
intended that raw DNS names in place of realm-specific IP datagrams should addresses may
not be used between the end systems an option to many of these applications (e.g.: FTP).

When realm-specific addressing is specified in payload, and the first (or last) hop router.  However, this may payload
is not always encrypted, an ALG may in some cases be
possible as not all systems can do raw network I/O. Because able to provide the work
around necessary to make the applications run transparently across
realms. The complexity of this, it
is possible ALG depends on the application level
knowledge required to encapsulate RSVP messages within UDP datagrams for end-
system communication. UDP-encapsulated RSVP messages process payload and maintain state.

2.3 Peer-to-peer applications

Peer-to-peer applications more than client-server based applications
are sent likely to either
port 1698 (if sent break with NAT enroute. Unlike Client-server
applications, Peer-to-peer applications can be originated by any of
the peers. When peers are distributed across private and public

realms, a session originated from 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, external realm is defined by:

Destination Address - just as
likely as the destination session from  a host in private realm. External
peers will be able to locate their peers in private realm only
when they know the externally assigned IP address for or the data packets. FQDN
ahead of time. FQDN name to assigned address mapping can happen
only so long as the enroute NAT device supports DNS-ALG. Examples
of Peer-to-peer applications include interactive games, Internet
telephony and event-based protocols (such as Instant-Messaging).

This is particularly a problem with traditional NAT and 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 less
of an issue with bi-directional NAT, where sessions are permitted
in both directions.

A possible work-around for this type of problem with traditional-NAT
is used for
demultiplexing at private hosts to maintain an outbound connection with a layer above
server acting as their representative to the globally routed
Internet.

2.4 IP layer.

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

1. RSVP message objects may contain NAPT enroute

IP addresses. The result fragmentation with NAPT enroute is that not an
RSVP-ALG must be able issue with any single
application, but pervades across all TCP/UDP applications. The
problem is described in detail in [NAT-TRAD]. Briefly, the problem
goes as follows. Say, two private hosts originated fragmented
TCP/UDP packets to replace the IP addresses based upon same destination host.  And, they happened to
use the
direction same fragmentation identifier. When the target host receives
the two unrelated datagrams, carrying same fragmentation id, and type of
from the message. For example, if an external sender
were to send an RSVP Path message same assigned host address, the target host is unable to an internal receiver,
determine which of the RSVP
session will specify two sessions the IP datagrams belong to.
Consequently, both sessions will be corrupted.

2.5 Applications requiring retention of address mapping

NAT will most likely break applications that the external sender believes is
teh IP require address of the internal receiver. However, when
mapping to be retained across contiguous sessions. These
applications require the RSVP Path
message reaches private-to-external address mapping
to be retained between sessions so the same external address
may be reused for subsequent session interactions. NAT device, cannot
know this requirement and may reassign external address to
different hosts between sessions.

Trying to keep NAT from discarding an address mapping would
require the RSVP session must application to keep sending Keepalives - which can
be annoying or sometimes not even possible. Alternately, an
ALG may be chaned required to
reflect interact with NAT to keep the IP address that
mapping from being discarded by NAT.

2.6 Applications requiring more public addresses than available

This 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 problem when the
integrity number of RSVP messages. The problem private hosts is that because of larger than
the first
point, a NAT device must be able to change IP external addresses within available to map the RSVP
messages.  However, when this is done, private addresses
into. Take for example the RSVP Integrity object is no
longer valid rlogin service initiated from a host
in private realm supported by NAPT. Rlogin service clients
use well-known rlogin port 512 as their TCP port ID. No more than
one host in private realm can initiate the RSVP message has been changed. Therefore an RSVP-ALG
will not work when the RSVP Integrity Object service. This is used.

2.1.2     DNS

Domain Names are an issue for hosts which a
case of trying to use local DNS servers behind a

I-D                  Protocol Complications with NAT           July 2000 service that fundamentally requires more
public addresses than are available. NAT device. Such servers return site specific information which may
conflict with external domain devices can conserve
addresses, but they cannot create more addresses.

Zone transfers from private address realms to an external realm must be
avoided for address assignments

3.0 Protocols that are not static. If primary cannot work with NAT enroute

3.1 IPsec and
backup name servers in IKE

NAT fundamentally operates by modifying end node addresses (within the same private domain, zone transfers do not
cross
IP header) en-route. The IPsec AH standard [RFC 2402] on the realm and DNS_ALG support for zone transfer other
hand is not an issue.

CHARACTERISTICS:

A. TCP/UDP based protocol.

B. Inverse name lookup queries embed the explicitly designed to detect alterations to IP packet
header. So when NAT alters the address information enroute in ASCII
  format. For example, a resolver that wanted to find IP
header, the
  hostname of an address 198.76.29.1 (externally assigned
  address destination host receiving the altered packet will
invalidate the packet since the contents of the headers have been
altered. The IPsec AH secure packet traversing NAT will simply not
reach the target application, as a private realm host) would pursue result.

IPsec ESP encrypted packets may be altered by NAT device enroute only
in a query limited number of cases. In the form:

QTYPE = PTR, QCLASS= IN, QNAME = 1.29.76.198.IN-ADDR.ARPA

An ALG is required to translate the query while forwarding case of TCP/UDP packets, NAT would
need to a DNS
server within private realm, so that the query will appear as follows
(replacing update the externally assigned address with its private address).

QTYPE = PTR, QCLASS= IN, QNAME = 1.0.0.10.IN-ADDR.ARPA

  Clearly, payload length could change checksum in TCP/UDP headers, when payload is
  translated.

C. Serial reuse of an address assignment between independent
  sessions. This requires that in
IP header is changed. However, as the ALG keep TCP/UDP header is encrypted by
the address
  assignment (between private and external addresses) valid
  for a pre-configured period of time, past the DNS query.

  Ex: DNS queries assume that the address assigned in response ESP, NAT would not be able to make this checksum update. As a name lookup is serially reusable by
result, TCP/UDP packets encyrpted in transport mode ESP, traversing a follow-on
      application.

D. A single DNS query payload could contain multiple queries at
NAT device will fail the
  same time, requiring translation of multiple TCP/UDP checksum validation on the receiving
end and will simply not reach the target application.

Internet Key Exchange Protocol IKE can potentially pass IP addresses within
  a private domain.

CONFIGURATION ISSUES:

DNS name to address mapping
as node identifiers during Main, Aggressive and Quick Modes. In order
for hosts in private domain should be
configured on an authorititive  name server within the private domain.
This server IKE negotiation to correctly pass through a NAT, these
payloads would need to be accessed modified.  However, these payloads are
often protected by external hash or obscured by encryption. Even in the
case where IP addresses are not used in IKE payloads and internal hosts alike for
name resolutions. A DNS ALG would be required to perform an IKE
negotiation could occur uninterrupted, there is difficulty with
retaining the private-to-external address to name
conversions mapping on DNS queries and responses.

Alternately, if there isn't a need for a name server within private
domain, private domain hosts could simply point NAT from the
time IKE completed negotiation to the time IPsec uses the key on
an external name
server for external name lookup.  No ALG is required when application. In the name

I-D                  Protocol Complications end, the use of end-to-end IPsec is severely
hampered anyway, as described earlier.

For all practical purposes, end-to-end IPsec is impossible to
accomplish with NAT           July 2000

server is located in external domain.

RFC 2694 describes a technique for enroute.

3.2 Kerberos 4

Kerberos 4 tickets are encrypted.  Therefore, an ALG cannot be
written.  when the KDC receives a DNS ALG.

2.1.3     SMTP

DESCRIPTION: SMTP is used by Internet email programs such as sendmail to
send TCP-based email messages to well known port 25.

CHARACTERISTICS:

A. SMTP ticket request, it includes the
source IP address in the returned ticket. Not all Kerberos 4
services actually check source IP addresses.  AFS is a TCP based protocol, based on a well known TCP port
  number 25.

B. In the majority good
example of cases, mail messages do not contain reference
  to private IP addresses or links to content data via names
  that a Kerberos 4 service which does not. Services which
don't check are not visible picky about NAT devices enroute. Kerberos
tickets are tied to outside.

Some mail messages do contain the IP addresses of teh MTA's address that relay requested the
message in ticket and
the "Received: " field. Some mail messages use IP addresses
in place of FQDN for debug purposes or due to lack of a DNS record, in
"Mail From: " field.

CONFIGURATION ISSUES:

You need to specify a mail server, service with which to use the ticket.

The K4 ticket (response) contains a globally assigned single IP address describing the
interface used by the  client to receive mail retrieve the ticket from external hosts.

Generally speaking, you would want to configure your mail system such
that all users specify the TGT
from the perspective of KDC. This works fine if the KDC is across a single centralized address (such
NAT gateway and as
fooboo@company.com), instead of including individual hosts (such long as
fooboo@hostA.company.com). The central address must have an MX record
specified in all of the DNS name server accessible by external hosts. Kerberos services are also
across a NAT gateway. The mail server may be located within or outside end user on private domain. But,
the requirement network will not notice
any problems.

There is also the caveat that NAT uses the server be assigned a global name same address mapping for
the private host for the connection between the client and
address, accessible by external hosts.

If one or more MTA's were to the KDC
as for the connection between the client and the application server.
A work around this problem would be located behind NAT in a private domain, to keep an SMTP-ALG will be required arbitrary connection
open to translate the IP address information
registered by remote server during throughout the MTA's. Typically, ticket lifetime, so as
not to let NAT drop the MTA's address binding. Alternately, an ALG will
need to be expected deployed to have a
static ensure that NAT would not change address mapping make
bindings during the translation valid across realms for long
periods lifetime of time.

When mail server a ticket and between the time a
ticket is located within private domain, inbound SMTP sessions
must be redirected issued to the private host from its externally assigned
address. No special mapping is required when Mail server and the time the ticket is located in
external domain.

The ability to trace used
by private host.

But, the mail route may ticket will be hampered or prevented by NAT.
This can cause problems when debugging mail problems or tracking down
abusive users valid from any host within the private realm
of mail.

ADDITIONAL INFO: RFC 821.

I-D                  Protocol Complications with NAT           July 2000

2.1.4     SIP

Description:  SIP can run on either TCP or UDP, but by default on NAPT.  Without NAPT, an attacker needs to be able to
spoof the
same port;
 5060.

When used with UDP, source IP addresses of a response connection that is being made in
order to use a SIP request does not go to stolen ticket on a different host. With NAPT, all
the
source port the request came from. Rather the SIP message contains the
port number attacker needs to do from the response should be sent to. SIP makes use private realm of ICMP port
unreachable errors in the response NAPT is to request transmissions. Request
messages are usually sent on simply
gain possession of a ticket. Of course, this assumes, NAPT private
domain is not a trusted network - not surprisingly, since many attacks
occur from inside the connected socket. If responses organization.

3.3 Kerberos 5

Just as with Kerberos 4, Kerberos 5 tickets are sent
to the source port in encrypted.  Therefore,
an ALG cannot be written.

In Kerberos 5, the request, each thread handling client specifies a request would
have to listen on list of IP addresses which the socket
ticket should be valid for, or it sent the request on. However, by
allowing responses to come to can ask for a single port, ticket valid for all
IP addresses.  By asking for an all-IP-addresses ticket or a single thread ticket
containing the NAPT device address, you can be used
for listening instead.

A server may prefer get krb5 to place the source port of each connected socket in work with an

NAPT device, although it isn't very transparent (it requires the message. Then each thread can listen
clients to behave differently than they otherwise would).  The MIT
krb5 1.0 implementation didn't have any configurability for responses separately. Since what IP
addresses the port number client asked for a response may (it always asked for the set of its
interface addresses) and did not go interact well with NAT.  The MIT krb5
1.1 implementation allows you to put "noaddresses" somewhere in
krb5.conf to request all-IP-addresses-valid tickets.

The K5 ticket (response) contains IP addresses, as requested by the source port
client node, from which the ticket is to be considered valid. If the
services being accessed with Kerberos authentication are on the
public side of the
request, SIP NAT, then the Kerberos authentication will not normally traverse a NAT and would require a SIP-
ALG.

SIP messages carry arbitrary content which is defined by a MIME type.
For multimedia sessions, this is usually fail
because the Session Description
Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be address used for the exchange of multimedia. These may lost significance when
traversing a NAT. Thus a SIP-ALG would need by the intelligence to decipher
and translate realm-relevant information.

SIP carries URL's NAT (basic NAT or NAPT) is not in its Contact, To and From fields that specify
signalling
the list of acceptable addresses. These URL's can contain IP addresses or domain
names

There are two workarounds in Kerberos 5 both of which reduce the host port portion
security of the URL. These may not be valid once
they traverse a NAT.

As an alternative tickets.  The first is to an SIP-ALG, SIP supports a proxy server which could
co-reside with NAT and function on the globally significant NAT port.
Such a proxy would have a locally specific configuration.

2.1.5     RealAudio

DESCRIPTION:    In its default mode, the clients (say, in a NAPT
private domain)
access TCP port 7070 to initiate conversation with a real-audio server
(say, located an external domain) and realm specify the public IP address of the NAPT in the
ticket's IP list.  But this leads to exchange control messages
during playback (ex: pausing or stopping the audio stream).

The actual audio traffic same security problem
detailed for K4.  Plus, it is carried on incoming UDP based packets
(originated from not obvious for the server) directed to ports client in the range of
6970-7170.

CHARACTERISTICS:

A. Real Audio has a TCP control session in one direction directed
private domain to a well-known port (7070) and find out the UDP based audio session in public IP Address of the opposite direction.

I-D                  Protocol Complications with NAT           July 2000

B. Audio session parameters are embedded in the TCP control
  session as byte stream(?)

CONFIGURATION

You could have an ALG examine the TCP traffic NAPT. That
would be a change of application behavior on end-host.

The second method is to determine the audio
session parameters and selectively enable inbound UDP sessions for the
ports agreed upon in remove all IP addresses from the TCP control session.  Alternately, K5 tickets
but this now makes theft of the ALG
could simply redirect all inbound UDP sessions directed to ports
6970-7170 to ticket even worse since the client address in tickets
can be used from anywhere.  Not just from within the private domain.

For bi-Directional NAT, you will not need an ALG.  Bi-directional NAT
could simply treat each of the TCP and UDP sessions as 2 unrelated
sessions and simply perform IP network.

3.4 The X Windowing System and TCP/UDP header level translations.

2.2  Protocols with multiple sessions

2.2.1     FTP

FTP X-term/Telnet

The X Windowing system is a TCP based application, used based. However, the client-server
relationship with these applications is reverse compared to reliably transfer files between
two hosts.

FTP
most other applications. The X server or Open-windows server is initiated by a client accessing a well-known port number 21 on the FTP server.  This is called
display/mouse/keyboard unit (i.e., the FTP control session. Often, an
additional data session accompanies one that controls the control session. By default, actual
Windows interface). The clients are the
data session would be from TCP port 20 application programs driving
the Windows interface.

Some machines run multiple X Windows servers on server to the same machine. The
first X Windows server is at 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. An FTP ALG
will 6000. The first Open Windows
server can 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 at port number with the externally valid address and 6000 or port number.  In addition, the sequence and acknowledgement numbers, TCP
checksum, 2000 (more flexible).  We will
mainly refer X windowing system for illustration purposes here.

X-term Transmits IP packet length and checksum have addresses from the client to be updated. Consequently the sequence numbers in all subsequent packets server for that stream must be
adjusted as well as TCP ACK fields and checksums.

Note, the above issue with ASCII encoded address and port can occur with
other applications as well. Changing these numbers can change the size
purpose of setting the overall packet. In rare cases, increasing DISPLAY variable.  When set the size of DISPLAY
variable is used for subsequent connections from X clients on the packet
could cause it
host to exceed an X server on the MTU of a given transport link. workstation. The packet
would then have to be fragmented which could affect performance. Or if DISPLAY variable is
sent inline during the packet has TELNET negotiations as

  DISPLAY=<local-ip-addr>:<server>.<display>

where the DF bit set, it would be ICMP rejected and <local-ip-addr> is retrieved by looking at the
originating host would then perform Path MTU Discovery. This could also
have an adverse effect on performance.

If local ip
address associated with the PROT command is socket used to secure the command channel, it will be
impossible for an ALG connect to update <server>.  The
<server> determines which port (6000 + <server>) should be used
to make the IP addresses in connection.  <display> is used to indicate which monitor
attached to the command
exchange.

I-D                  Protocol Complications with NAT           July 2000

Finally, section 4 of RFC 2428 describes how a new FTP port command
(EPSV) can X server should be used but is not important to put a connection on a fast path through NAT.

2.2.2     H.323

H.323 this
discussion.

The <local-ip-addr> used is complex, uses dynamic ports, and includes multiple UDP streams.
Here not a DNS name because:

 . The is no ability for the local machine to know its DNS name
   without performing a summary of reverse DNS lookup on the relevant issues:

An H.323 call local-ip-addr

 . There is made up of many different simultaneous connections. At
least two of no guarantee that the connections are TCP.  For an audio-only conference,
there name returned by a reverse
   DNS lookup actually maps back to the local IP address.

 . Lastly, without DNSSEC, it may not be up to 4 different UDP 'connections' made.

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

Calls use DNS addresses
   because they can easily be initiated spoofed. NAT and DNS-ALG cannot work
   unless DNSSEC is disabled.

A common use of this application is people dialing in to corporate
offices from their X terminals at home. Say, the private as well as X client is running
on a host on the external domain.
For conferencing to be useful, external users need to be able to
establish calls directly with internal users' desktop systems.

The addresses public side of the NAT and port numbers are exchanged within X server is running on a
host on the data stream private side of the 'next higher' connection. For example, NAT. The DISPLAY variable is
transmitted inline to the port number for host the H.245
connection X client is established within the Q.931 data stream. (This makes it
particularly difficult for running in some way.
The process transmitting the ALG, which will be required to modify contents of the
addresses inside those data streams.)  To make matters worse, it is
possible in Q.931, for example, to specify that DISPLAY variable does
not know the H.245 connection
should be secure (encrypted). address of the NAT.

If a session the channel transmitting the DISPLAY variable is not encrypted, it is
impossible for
NAT device might solicit the help of an ALG to decipher replace the data stream, unless it has
IP address and configure a port in the valid display range (ports
6000 and higher) to act as a gateway. Alternately, NAT may be
configured to listen for incoming connections to provide access
to the shared key.

Most of X Server(s), without requiring an ALG. But, this approach
increases the control information is encoded in ASN.1 (only security risk by providing access to the User-User
Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded
(other parts of each Q.931 PDU are X server that
would not encoded). For those unfamiliar otherwise be available. As the ALG tampers with ASN.1, suffice it to say that the
IP addresses it is a complex encoding scheme,
which does will also not end up with fixed byte offsets be possible for address information.
In fact, X Authorization methods
other than MIT-MAGIC-COOKIE-1 to be used.  MIT-MAGIC-COOKIE-1 is the same version
least secure of all the same application connecting to the same
destination documented X Authorization methods.

When START_TLS is used there may negotiate to include different options, changing be client certificate verification
problems caused by the
byte offsets.

Below is NAT depending on the protocol exchange information provided in
the certificate.

3.5 RSH/RLOGIN

RSH uses multiple sessions to support separate streams for a typical H.323 call between User A stdout and User B. A's IP address
stderr. A random port number is 88.88.88.88 and B's IP address transmitted inline from the client to

the server for use as stderr port. The stderr socket is
99.99.99.99.  Note that a connection
back from the Q.931 server to the client. And unlike FTP, there is no
equivalent to PASV mode. For traditional NAT, this is a problem
as traditional NAT would not permit incoming sessions.

RLOGIN does not use multiple sessions. But the Kerberos protected
versions of RSH and H.245 messages are encoded in
ASN.1 RLOGIN will not work in a NAT environment due
to the ticket problems and the use of multiple sessions.

3.7 SNMP

SNMP configuration packet payload may contain router configuration
items, which are IP addresses. If such a packet transits NAT to another
IP address domain they will be incorrect. Network Admins should take
care to not send such packets across NAT. In some cases, it is possible
to use SNMP-ALG to convert realm-specific addresses to globally unique
addresses.

4.0 Protocols that can work with the aid of an RTP packet. So ALG

This document predominantly addresses problems associated with
Traditional NAT, especially NAPT.

4.1 FTP

FTP is a TCP based application, used to reliably transfer files between
two hosts. FTP uses bundled session approach to accomplish this.

FTP is initiated by a connection
through client accessing a NAT device, well-known port number 21 on
the FTP server.  This is called the FTP control session. Often, an H.323-ALG will
additional data session accompanies the control session. By default, the
data session would be required from TCP port 20 on server to examine the
packet, decode TCP port client
used to initiate control session. However, the ASN.1, and translate data session ports may be
altered within the various H.323 FTP control IP
addresses.

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

      ----------------------------------------------->
      Q.931 Setup caller address = 88.88.88.88
                  caller port    = 1120
                  callee address = 99.99.99.99
                  callee port    = 1720

I-D                  Protocol Complications with NAT           July 2000

      <-----------------------------------------------
      Q.931 Alerting
      <-----------------------------------------------
      Q.931 Connect H.245 address = 99.99.99.99
                    H.245 port    = 1092

      User A establishes connection to User B at
      99.99.99.99, port 1092

      <---------------------------------------------->
      Several H.245 messages are exchanged (Terminal
      Capability Set, Master Slave Determination sessions using ASCII encoded PORT and
      their respective ACKs)

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

Also note that if
PASV commands and responses.

Say, an H.323 Gateway resided inside FTP client is in a NAT boundary, the supported private network. An FTP ALG would have to
will be cognizant of required to monitor the various gateway discovery schemes FTP control session (for both PORT and adapt
PASV modes) to those schemes as well. Or if just identify the H.323 host/terminal
was inside FTP data session port numbers and modify the NAT boundary
private address and tried to register port number with a Gatekeeper, the
IP information in externally valid address and
port number.  In addition, the registration messages would sequence and acknowledgement numbers, TCP
checksum, IP packet length and checksum have to be translated
by NAT.

3.0  Applications which do not require ALG's

3.1  The X-Windowing System/Protocol:

DESCRIPTION:   These applications are TCP based. However, updated. Consequently
the client-
server relationship with these applications is reverse compared to most
other applications. The X-server or Open-windows server is sequence numbers in all subsequent packets for that stream must be
adjusted as well as TCP ACK fields and checksums.

In rare cases, increasing the

I-D                  Protocol Complications with NAT           July 2000

display/mouse/keyboard unit (i.e., size of the one that controls packet could cause it to
exceed the actual
Windows interface). MTU of a given transport link. The clients are packet would then have

to be fragmented which could affect performance. Or, if the application programs driving packet has
the
Windows interface.

Some machines run multiple X-Windows servers DF bit set, it would be ICMP rejected and the originating host
would then have to perform Path MTU Discovery. This could have an
adverse effect on performance.

Note however, if the same machine. The
first X-windows server control command channel is at TCP port 6000. The first Open Windows
server can be at port 6000 or port 2000 (more flexible).  We secured, it will refer
X-windows mainly be
impossible for illustration purposes here.

On a UNIX system, an ALG to update the IP addresses in the csh DISPLAY command "setenv DISPLAY <hostname>:n",
where n>= 0,
exchange.

When AUTH is used to tell clients to contact X server on <hostname>
on TCP port (6000+n).

A common use of this application is people dialing in to corporate
offices from their X terminals at home.

CHARACTERISTICS:

A. X-Windows is a TCP based protocol, with Kerberos 4, Kerberos 5, and TLS, the server
  servicing TCP ports in the range of 6000 - 6000+n.
  Open-Windows same
problems that occur with X-Term/Telnet occur with FTP.

Lastly, it is also of interest to note section 4 of RFC 2428 (FTP extensions
for IPv6 and NATs) which describes how a TCP based new FTP port command (EPSV ALL)
can be used to allow NAT devices to fast-track the FTP protocol, with
eliminating further processing through ALG, if the remote server
  servicing TCP ports
accepts "EPSV ALL".

4.2 RSVP

RSVP is positioned in the range protocol stack at the transport layer,
operating on top of 6000 - 6000+n or
  2000 - 2000+n.

B. The X-Windows applications are not expected to contain
  reference to private IP addresses (either IPv4 or links to content IPv6). However, unlike other
transport protocols, RSVP does not transport application data via names that but
instead acts like other Internet control protocols (for example, ICMP,
IGMP, routing protocols).  RSVP messages are not visible to the outside. All
  the information required for Client-Server communication
  is in the sent hop-by-hop between
RSVP-capable routers as raw IP and TCP headers.

When X-Windows server (i.e., the machine that displays the X-Windows on
its console) runs in a private domain, we need to allow inbound X-server
access for the X terminals at home. I.e., Users datagrams using protocol number 46. It is
intended that need to provide X-
terminal access must have inbound access permissions.  This can raw IP datagrams should be done
statically or dynamically for private hosts.

In case of a NAPT setup, used between the individual X-Windows ports namely, 6000,
6001, 6002, 6003 end systems
and so on till (6000+n) on the external address first (or last) hop router.  However, this may not always be
statically redirected to different hosts running X-server.

For Example, you could redirect inbound TCP sessions to <External
address>:6000 to <private Host A>, sessions to <External Address>:6001
to <private Host B> and so on.

Telnet transmits IP addresses from the client
possible as not all systems can do raw network I/O. Because of this, it
is possible to the server encapsulate RSVP messages within UDP datagrams for the
purposes 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 setting the DISPLAY variable. When set, the DISPLAY variable
RSVP messages; consult Appendix C of RFC 2205.

An RSVP session, a data flow with a particular destination and
transport-layer protocol, is used for subsequent connections from X client on defined by:

Destination Address - the host to an X
server on destination IP address for the workstation.

When START_TLS is used there data packets.
This may be client certificate verification
problems caused by NAT depending on either a unicast or a multicast address.

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

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

I-D                  Protocol Complications with IP layer.

NAT           July 2000

Xauth methods other than MIT-MAGIC-COOKIE-1 devices are presented with unique problems when it comes to
supporting RSVP. Two issues are:

1. RSVP message objects may prevent NAT from
altering contain IP addresses. The result is that an
RSVP-ALG must be able to replace the IP addresses of based upon the X session.

Activision Games

DESCRIPTION: The goal
direction and type of Activision Games is to work transparently
through traditional NAT devices. As such, the protocol described is
intended message. For example, if an external sender
were to be NAT friendly so game players within a private domain can
play with other players in send an RSVP Path message to an internal receiver, the same domain or external domain.

All peers are somehow informed of each others' public and private
addresses, and each client opens up symmetrical direct connections to
each other and use whichever address (private or external)  works first.

Now, the clients can have a session directly with other clients directly
(or) they can have RSVP
session with other clients via will specify the gaming server.

CHARACTERISTICS:

A. Activision gaming protocol is proprietary and is based on UDP. The
server uses UDP port no. 21157.

B. The protocol is designed with keeping NAT and NAPT in mind.  The game
players can be within IP address that the same private domain, in a combination of
multiple private domains and external domain.

C. The key sender believes is to allow
the reuse IP address of the tuple of internal receiver. However, when the same (global
address, assigned UDP port) for initial connection to RSVP Path
message reaches the game server
(helper) and NAT device, the subsequent connection RSVP session must be changed to
reflect the client. A game player IP address that is
recognized by one of (private address, UDP port) or (Assigned global
address, assigned UDP port) by used internally for the receiver. Similar
actions must be taken for all other peer players. So, message objects that contain IP addresses.

2. RSVP provides a means, the binding
between tuples should remain unchanged so long as RSVP Integrity object, to guarantee the gaming player
integrity of RSVP messages. The problem is
in session with one or multiple other players.

CONFIGURATION ISSUES:

Opening a connection to a game server in external realm from that because of the first
point, a private
host is no problem. All NAT would have device must be able to do change IP addresses within the RSVP
messages.  However, when this is provide routing
transparency.

But, an NAPT configuration MUST allow multiple simultaneous UDP
connections on done, the same assigned global address/port.

ADDITIONAL INFO:

http://www.csn.tu-chemnitz.de/HyperNews/get/linux-ip-nat/97.html
http://newjersey1.activision.com/anet2
http://california3.activision.com/anet2

4.0  ROUTING UPDATES:

I-D                  Protocol Complications with NAT           July 2000

Routing advertisement varies considerably based on RSVP Integrity object is no
longer valid as the NAT flavor RSVP message has been changed. Therefore an RSVP-ALG
will not work when RSVP Integrity Object is used.

4.3 DNS

DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts
which use local DNS servers in
use. A traditional-NAT and bi-directional-NAT may advertise untranslated
external routes to the NAT private realm. However, a Twice-NAT device must
translate external routes (into their DNS name to address
mapping for hosts in private realm domain should be configured on an
authoritative name server within private domain. This server would
be accessed by external and internal hosts alike for name
resolutions. A DNS-ALG would be required to perform address blocks), if to name
conversions on DNS queries and responses. RFC 2694 describes DNS-ALG
in detail. If DNS packets are encrypted/authenticated per DNSSEC,
then DNS_ALG will fail because it chooses won't be able to advertise those routes perform payload
modifications.

Applications using DNS resolver to resolve a DNS name into an
IP address, assume availability of address assignment for reuse
by the application specific session. As a result, DNS-ALG will
be required to keep the address assignment (between private realm.

All flavors and
external addresses) valid for a pre-configured period of NAT must refrain from advertising time,
past the DNS query.

Alternately, if there isn't a need for a name server within private realm routes
into
domain, private domain hosts could simply point to an external realms. Instead, every name
server for external name lookup.  No ALG is required when the name
server is located in external domain.

4.4 SMTP

SMTP is a TCP based protocol (Refer RFC 821), used by Internet
email programs such as sendmail to send TCP-based email messages
to well-known port 25. The mail server may be located within or

outside private domain. But, the server must be assigned a global
name and address, accessible by external hosts. When mail server
is located within private domain, inbound SMTP sessions must be
redirected to the private host from its externally assigned
address. No special mapping is required when Mail server is
located in external domain.

Generally speaking, mail systems are configured such that all
users specify a single centralized address (such as
fooboo@company.com), instead of including individual hosts (such
as fooboo@hostA.company.com). The central address must have an MX
record specified in the DNS name server accessible by external
hosts.

In the majority of cases, mail messages do not contain reference
to private IP addresses or links to content data via names that
are not visible to outside. However, some mail messages do contain
IP addresses of the MTAs that relay the message in the "Received: "
field. Some mail messages use IP addresses in place of FQDN for
debug purposes or due to lack of a DNS record, in "Mail From: "
field.

If one or more MTAs were to be located behind NAT in a private
domain, and the mail messages are not secured by signature or
cryptographic keys, an SMTP-ALG may be used to translate the
IP address information registered by the MTAs. If the MTAs
have static address mapping, the translation would be valid
across realms for long periods of time.

The ability to trace the mail route may be hampered or prevented
by NAT alone, without the ALG. This can cause problems when
debugging mail problems or tracking down abusive users of mail.

4.5 SIP

SIP (Refer [SIP]) can run on either TCP or UDP, but by default on
the same port 5060.

When used with UDP, a response to a SIP request does not go to the
source port the request came from. Rather the SIP message contains
the port number the response should be sent to. SIP makes use of
ICMP port unreachable errors in the response to request
transmissions. Request messages are usually sent on the connected
socket. If responses are sent to the source port in the request,
each thread handling a request would have to listen on the socket
it sent the request on. However, by allowing responses to come to
a single port, a single thread can be used for listening instead.

A server may prefer to place the source port of each connected
socket in the message. Then each thread can listen for responses
separately. Since the port number for a response may not go to
the source port of the request, SIP will not normally traverse
a NAT and would require a SIP-ALG.

SIP messages carry arbitrary content, which is defined by a MIME type.
For multimedia sessions, this is usually the Session Description
Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be
used for the exchange of multimedia. These may loose significance when
traversing a NAT. Thus a SIP-ALG would need the intelligence to
decipher and translate realm-relevant information.

SIP carries URL's in its Contact, To and From fields that specify
signaling addresses. These URL's can contain IP addresses or domain
names in the host port portion of the URL. These may not be valid
once they traverse a NAT.

As an alternative to an SIP-ALG, SIP supports a proxy server which
could co-reside with NAT and function on the globally significant
NAT port. Such a proxy would have a locally specific configuration.

4.6 RealAudio

In default mode, RealAudio clients (say, in a private domain)
access TCP port 7070 to initiate conversation with a real-audio server
(say, located an external domain) and to exchange control messages
during playback (ex: pausing or stopping the audio stream). Audio
session parameters are embedded in the TCP control session as
byte stream.

The actual audio traffic is carried in the opposite direction on
incoming UDP based packets (originated from the server) directed
to ports in the range of 6970-7170.

As a result, RealAudio is broken by default on a traditional NAT
device. A work around for this would be for the ALG to examine the
TCP traffic to determine the audio session parameters and
selectively enable inbound UDP sessions for the ports agreed upon
in the TCP control session.  Alternately, the ALG could simply
redirect all inbound UDP sessions directed to ports 6970-7170 to
the client address in the private domain.

For bi-Directional NAT, you will not need an ALG.  Bi-directional NAT
could simply treat each of the TCP and UDP sessions as 2 unrelated
sessions and perform IP and TCP/UDP header level translations.

The readers may contact RealNetworks, Inc. for detailed guidelines

on how their applications can be made to work, traversing through NAT
and firewall devices.

4.7 H.323

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 private as well as the external domain.
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 the ALG, which will be required to 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). If a session is encrypted, it is
impossible for the ALG to decipher
 the data stream, unless it has access to the shared key.

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 88.88.88.88 and B's IP address is
99.99.99.99.  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, an H.323-ALG will be required to examine 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 = 88.88.88.88
                  caller port    = 1120
                  callee address = 99.99.99.99
                  callee port    = 1720

      <-----------------------------------------------
      Q.931 Alerting
      <-----------------------------------------------
      Q.931 Connect H.245 address = 99.99.99.99
                    H.245 port    = 1092

      User A establishes connection to User B at
      99.99.99.99, 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 = 99.99.99.99
                RTCP port    = 1093
      ----------------------------------------------->
      H.245 Open Logical Channel Ack, channel = 257
                RTP address = 88.88.88.88
                RTP port    = 2002
                (This is where User A would like RTP
                 data sent to)
                RTCP address = 88.88.88.88
                RTCP port    = 2003
      ----------------------------------------------->
      H.245 Open Logical Channel, channel = 257
                RTCP address = 88.88.88.88
                RTCP port    = 2003
      <-----------------------------------------------
      H.245 Open Logical Channel Ack, channel = 257
                RTP address = 99.99.99.99
                RTP port    = 1092
                (This is where User B would like RTP data
                 sent to)
                RTCP address = 99.99.99.99
                RTP port     = 1093

Also note that if an H.323 Gateway resided inside a NAT device must advertise (or boundary, the
ALG would have to be
made apparent through static configuration cognizant of neighboring routers or
some other means) the external address block it uses for mapping private
realm addresses.

5.0  Applications which cannot work with NAT enroute

5.1  IPsec

Another class of problems with NAT is end-to-end security of packets.
The IPsec AH standard [RFC 1826] is explicitly intended various gateway discovery schemes
and adapt to detect what
NAT is good at i.e. altering those schemes as well. Or if just the header of H.323 host/terminal
was inside the packet. So when NAT
alters the address information in the header of the packet, the
destination host receives the altered packet boundary 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 started.

Other IPsec protocols tried to register with NAT complications:

ESP: Encrypts IP payload. In a Gatekeeper, the case of TCP/UDP packets, this includes
checksumbased on source and destination IP addresses. When any of these
IP addresses are changed, information in the corresponding TCP/UDP checksum must also registration messages would have to be updated translated
by NAT. As a result, TCP/UDP packets encyrpted using
transport mode ESP cannot traverse a NAT device. ESP tunnel mode can

5.0 Protocols designed explicitly to work through with NAT and ESP can work if TCP/UDP checksums are turned off or
ignored by the receiver.

IKE: Potentially passes IP addresses during both Main, Aggressive and
Quick Modes. In order enroute

5.1 Activision Games

Activision Games were designed to be NAT-friendly so as not to require
an ALG for a negotiation the games to correctly pass work transparently through traditional NAT
devices.  Game players within a NAT,
these payloads would need to be modified.  However, these payloads are
often protected by hash private domain can play with other
players in the same domain or obscured by encryption. Because of IKE
rekeying behavior, it external domain. Activision gaming
protocol is necessary for implementations to float their
IKE source proprietary and is based on UDP. The server uses UDP
port in order to enable NAT no. 21157.

All peers are somehow informed of each others' public and private
addresses, and each client opens up symmetrical direct connection to demux incoming rekeys which
may not
each other and use whichever address (private or external)  works first.
Now, the same cookies as earlier traffic.

5.2  Kerberos

Kerberos tickets are encrypted. Therefore, an ALG cannot work. The
ticket contains clients can have a list of IP addresses from which session directly with other clients directly
(or) they can have session with other clients via the ticket is to be
considered valid. gaming server.
The list key is generated by the client machine, not the
KDC. If to allow the services being accessed with Kerberos authentication are on reuse of the public side tuple of the NAT, then same (global
address, assigned UDP port) for initial connection to the Kerberos authentication will fail
because game server
(helper) and the IP address used by subsequent connection to the NAT client. A game player is not in the list
recognized by one of acceptable

I-D                  Protocol Complications (private address, UDP port) or (Assigned global
address, assigned UDP port) by all other peer players. So, the binding
between tuples should remain unchanged so long as the gaming player is
in session with NAT           July 2000

addresses.

6.0  Protocols which are suspected one or multiple other players.

Opening a connection to have complications (but further
study is required.)

Rlogin/rsh ONC/RPC/NFS

7.0  Other Issues

If IP addresses are contained a game server in the data payload of the packet, then external realm from a private
host is no problem. All NAT may make those addresses irrelevant. For example, within SNMP would have to do is provide routing
transparency.

But, an NAPT configuration packets, MUST allow multiple simultaneous UDP
connections on the payload same assigned global address/port.

The readers may contain router configuration
items which are IP addresses. If such a packet transits NAT refer Activision for the proprietary, detailed
information on the function and design of this protocol.

6.0. Acknowledgements

The authors would like to another
IP address domain they will be incorrect. Network Admins should take
care express sincere thanks to Bernard Aboba,

Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine,
Jeffrey Altman, Keith Moore,  Vernon Shryver and others that had
provided valuable input in preparing this draft.

7.0. Security considerations

The security considerations outlined in [NAT-TERM] are relevant to
all NAT devices. This draft does not send such packets across NAT. The same goes for IP addresses
sent within emails. They will lose their meaning when sent through NAT. warrant additional security
considerations.

8.0

Authors Addresses:

   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803
   EMail: matt@ipverse.com

   Pyda Srisuresh
   Campio Communications
   630 Alder Drive
   Milpitas, CA 95035
   U.S.A.
   Voice: (408) 519-3849
   EMail: srisuresh@yahoo.com

9.0     References

NAT       RFC 2663, NAT

[NAT-TERM]   Srisuresh, P., Holdrege, M. "IP Network Address Translator
             (NAT) Terminology and Considerations

          draft-ietf-nat-traditional-03.txt

H.323 Considerations", RFC 2663

[NAT-TRAD]   Srisuresh, P., Egevang, K. "Traditional IP Network Address
             Translator(Traditional NAT)",
	     <draft-ietf-nat-traditional-04.txt>

[H.323]      ITU-T SG16 H.323, Intel white paper, H.323 and
	     Firewalls; Dave Chouinard, John Richardson, Milind Khare
             (with further assistance from Jamie Jason).

SMTP

[SMTP]       RFC 821

FTP

[FTP]        RFC 959

SIP

[SIP]        RFC 2543

X-Windows

[X Windows]  RFC 1198

I-D                  Protocol Complications with NAT           July 2000

RSVP

[RSVP]       RFC 2205

RealAudio       http://www.real.com/firewall/packetfil.html

DNS

[DNS]        RFC 1034, RFC 1035, RFC 2694

IPsec

[IPsec]      RFC 2401, RFC 2402, RFC 2406, RFC 2411, RFC 2709

[PRIV-ADDR]  Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot,
	     and, Lear, E.  "Address Allocation for Private Internets",
             RFC 1918

[ADDR-BEHA]  Brian carpenter, Jon Crowcroft, Yakov Rekhter, "IPv4
	     Address Behaviour Today", RFC 2101

Authors Addresses:

   Matt Holdrege
   ipVerse
   223 Ximeno Ave.
   Long Beach, CA 90803
   EMail: matt@ipverse.com

   Pyda Srisuresh
   Campio Communications
   630 Alder Drive
   Milpitas, CA 95035
   U.S.A.
   Voice: (408) 519-3849
   EMail: srisuresh@yahoo.com