As per Relevance of the word addresses, we have this rfc below:
Network Working Group M.
Request for Comments: 3027
Category: Informational P.
Jasmine
January 2001
Protocol Complications with the IP Network Address
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Many internet applications can be adversely affected when end
are not in the same address realm and seek the assistance of an
Network Address Translator (NAT) enroute to bridge the realms.
NAT device alone cannot provide the necessary application/
transparency in all cases and seeks the assistance of
Level Gateways (ALGs) where possible, to provide transparency.
purpose of this document is to identify the protocols
applications that break with NAT enroute. The document also
to identify any known workarounds. It is not possible to capture
applications that break with NAT in a single document. This
attempts to capture as much information as possible, but is by
means a comprehensive coverage. We hope the coverage
sufficient clues for applications not covered
Table of
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
This document requires the reader to be familiar with the
and function of NAT devices as described in [NAT-TERM]. In
nutshell, NAT attempts to provide a transparent routing solution
end hosts requiring communication to disparate address realms.
modifies end node addresses (within the IP header of a packet) en
route and maintains state for these updates so that
pertaining to a session are transparently routed to the right end
node in either realm. Where possible, application specific ALGs
be used in conjunction with NAT to provide application
transparency. Unlike NAT, the function of ALG is
specific and would likely require examination and recomposition of
payload
The following sections attempt to list applications that are known
have been impacted by NAT devices enroute. However, this is by
means a comprehensive list of all known protocols and
that have complications with NAT - rather just a subset of the
gathered by the authors. It is also important to note that
document is not intended to advocate NAT, but rather to point out
complications with protocols and applications when NAT devices
enroute
2.0 Common Characteristics of Protocols broken by
[NAT-TERM] and [NAT-TRAD] have sections listing the specific
of problems and limitations to NAT devices. Some of
limitations are being restated in this section to
characteristics of protocols that are broken by NAT
2.1 Realm-specific IP address information in
A wide range of applications fail with NAT enroute when IP
contain realm-specific IP address or port information in payload.
ALG may be able to provide work around in some cases. But, if
packet payload is IPsec secured (or secure by a transport
application level security mechanisms), the application is bound
fail
2.2 Bundled session
Bundled session applications such as FTP, H.323, SIP and RTSP,
use a control connection to establish a data flow are also
broken by NAT devices enroute. This is because these
exchange address and port parameters within control session
establish data sessions and session orientations. NAT cannot
the inter-dependency of the bundled sessions and would treat
Holdrege & Srisuresh Informational [Page 2]
RFC 3027 Protocol Complications with NAT January 2001
session to be unrelated to one another. Applications in this
can fail for a variety of reasons. Two most likely reasons
failures are: (a) addressing information in control payload
realm-specific and is not valid once packet crosses the
realm, (b) control session permits data session(s) to originate in
direction that NAT might not permit
When DNS names are used in control payload, NAT device in
with a DNS-ALG might be able to offer the necessary application
transparency, if NAT has no contention with data session orientation
However, using DNS names in place of realm-specific IP addresses
not be an option to many of these applications (e.g., FTP).
When realm-specific addressing is specified in payload, and
payload is not encrypted, an ALG may in some cases be able to
the work around necessary to make the applications run
across realms. The complexity of ALG depends on the
level knowledge required to process payload and maintain state
2.3 Peer-to-peer
Peer-to-peer applications more than client-server based
are likely to break with NAT enroute. Unlike Client-
applications, Peer-to-peer applications can be originated by any
the peers. When peers are distributed across private and
realms, a session originated from an external realm is just as
as the session from a host in private realm. External peers will
able to locate their peers in private realm only when they know
externally assigned IP address or the FQDN ahead of time. FQDN
to assigned address mapping can happen only so long as the
NAT device supports DNS-ALG. Examples of Peer-to-peer
include interactive games, Internet telephony and event-
protocols (such as Instant-Messaging).
This is particularly a problem with traditional NAT and may be
of an issue with bi-directional NAT, where sessions are permitted
both directions
A possible work-around for this type of problem with traditional-
is for private hosts to maintain an outbound connection with a
acting as their representative to the globally routed Internet
2.4 IP fragmentation with NAPT
IP fragmentation with NAPT enroute is not an issue with any
application, but pervades across all TCP/UDP applications.
problem is described in detail in [NAT-TRAD]. Briefly, the
goes as follows. Say, two private hosts originated
Holdrege & Srisuresh Informational [Page 3]
RFC 3027 Protocol Complications with NAT January 2001
TCP/UDP packets to the same destination host. And, they happened
use the same fragmentation identifier. When the target host
the two unrelated datagrams, carrying same fragmentation id, and
the same assigned host address, the target host is unable
determine which of the two sessions the datagrams belong to
Consequently, both sessions will be corrupted
2.5 Applications requiring retention of address
NAT will most likely break applications that require address
to be retained across contiguous sessions. These
require the private-to-external address mapping to be
between sessions so the same external address may be reused
subsequent session interactions. NAT cannot know this
and may reassign external address to different hosts
sessions
Trying to keep NAT from discarding an address mapping would require
NAT extension protocol to the application that would allow
application to inform the NAT device to retain the mappings
Alternately, an ALG may be required to interact with NAT to keep
address mapping from being discarded by NAT
2.6 Applications requiring more public addresses than
This is a problem when the number of private hosts is larger than
external addresses available to map the private addresses into.
for example the rlogin service initiated from a host in private
supported by NAPT. Rlogin service clients use well-known rlogin
512 as their TCP port ID. No more than one host in private realm
initiate the service. This is a case of trying to use a service
fundamentally requires more public addresses than are available.
devices can conserve addresses, but they cannot create
addresses
3.0 Protocols that cannot work with NAT
3.1 IPsec and
NAT fundamentally operates by modifying end node addresses (
the IP header) en-route. The IPsec AH standard [IPsec-AH] on
other hand is explicitly designed to detect alterations to IP
header. So when NAT alters the address information enroute in
header, the destination host receiving the altered packet
invalidate the packet since the contents of the headers have
altered. The IPsec AH secure packet traversing NAT will simply
reach the target application, as a result
Holdrege & Srisuresh Informational [Page 4]
RFC 3027 Protocol Complications with NAT January 2001
IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by
device enroute only in a limited number of cases. In the case
TCP/UDP packets, NAT would need to update the checksum in TCP/
headers, when an address in IP header is changed. However, as
TCP/UDP header is encrypted by the ESP, NAT would not be able to
this checksum update. As a result, TCP/UDP packets encrypted
transport mode ESP, traversing a NAT device will fail the TCP/
checksum validation on the receiving end and will simply not
the target application
Internet Key Exchange Protocol IKE can potentially pass IP
as node identifiers during Main, Aggressive and Quick Modes.
order for an IKE negotiation to correctly pass through a NAT,
payloads would need to be modified. However, these payloads
often protected by hash or obscured by encryption. Even in the
where IP addresses are not used in IKE payloads and an
negotiation could occur uninterrupted, there is difficulty
retaining the private-to-external address mapping on NAT from
time IKE completed negotiation to the time IPsec uses the key on
application. In the end, the use of end-to-end IPsec is
hampered anyway, as described earlier
For all practical purposes, end-to-end IPsec is impossible
accomplish with NAT enroute
3.2 Kerberos 4
Kerberos 4 tickets are encrypted. Therefore, an ALG cannot
written. When the KDC receives a ticket request, it includes
source IP address in the returned ticket. Not all Kerberos 4
services actually check source IP addresses. AFS is a good
of a Kerberos 4 service which does not. Services which don't
are not picky about NAT devices enroute. Kerberos tickets are
to the IP address that requested the ticket and the service
which to use the ticket
The K4 ticket (response) contains a single IP address describing
interface used by the client to retrieve the ticket from the
from the perspective of KDC. This works fine if the KDC is across
NAT gateway and as long as all of the Kerberos services are
across a NAT gateway. The end user on private network will
notice any problems
There is also the caveat that NAT uses the same address mapping
the private host for the connection between the client and the KDC
for the connection between the client and the application server.
work around this problem would be to keep an arbitrary
open to remote server during throughout the ticket lifetime, so
Holdrege & Srisuresh Informational [Page 5]
RFC 3027 Protocol Complications with NAT January 2001
not to let NAT drop the address binding. Alternately, an ALG
need to be deployed to ensure that NAT would not change
bindings during the lifetime of a ticket and between the time
ticket is issued to private host and the time the ticket is used
private host
But, the ticket will be valid from any host within the private
of NAPT. Without NAPT, an attacker needs to be able to spoof
source IP addresses of a connection that is being made in order
use a stolen ticket on a different host. With NAPT, all the
needs to do from the private realm of NAPT is to simply
possession of a ticket. Of course, this assumes, NAPT private
is not a trusted network - not surprisingly, since many attacks
from inside the organization
3.3 Kerberos 5
Just as with Kerberos 4, Kerberos 5 tickets are encrypted
Therefore, an ALG cannot be written
In Kerberos 5, the client specifies a list of IP addresses which
ticket should be valid for, or it can ask for a ticket valid for
IP addresses. By asking for an all-IP-addresses ticket or a
containing the NAPT device address, you can get krb5 to work with
NAPT device, although it isn't very transparent (it requires
clients to behave differently than they otherwise would). The
krb5 1.0 implementation didn't have any configurability for what
addresses the client asked for (it always asked for the set of
interface addresses) and did not interact well with NAT. The
krb5 1.1 implementation allows you to put "noaddresses" somewhere
krb5.conf to request all-IP-addresses-valid tickets
The K5 ticket (response) contains IP addresses, as requested by
client node, from which the ticket is to be considered valid. If
services being accessed with Kerberos authentication are on
public side of the NAT, then the Kerberos authentication will
because the IP address used by the NAT (basic NAT or NAPT) is not
the list of acceptable addresses
There are two workarounds in Kerberos 5 both of which reduce
security of the tickets. The first is to have the clients in
private realm specify the public IP address of the NAPT in
ticket's IP list. But this leads to the same security
detailed for K4. Plus, it is not obvious for the client in
private domain to find out the public IP Address of the NAPT.
would be a change of application behavior on end-host
Holdrege & Srisuresh Informational [Page 6]
RFC 3027 Protocol Complications with NAT January 2001
The second method is to remove all IP addresses from the K5
but this now makes theft of the ticket even worse since the
can be used from anywhere. Not just from within the private network
3.4 The X Windowing System and X-term/
The X Windowing system is TCP based. However, the client-
relationship with these applications is reverse compared to
other applications. The X server or Open-windows server is
display/mouse/keyboard unit (i.e., the one that controls the
Windows interface). The clients are the application programs
the Windows interface
Some machines run multiple X Windows servers on the same machine
The first X Windows server is at TCP port 6000. The first
Windows server can be at port 6000 or port 2000 (more flexible).
will mainly refer X windowing system for illustration purposes here
X-term Transmits IP addresses from the client to the server for
purpose of setting the DISPLAY variable. When set the
variable is used for subsequent connections from X clients on
host to an X server on the workstation. The DISPLAY variable is
inline during the TELNET negotiations
DISPLAY=:.
where the is retrieved by looking at the local
address associated with the socket used to connect to .
determines which port (6000 + ) should be used
make the connection. is used to indicate which
attached to the X server should be used but is not important to
discussion
The used is not a DNS name because
. The is no ability for the local machine to know its DNS
without performing a reverse DNS lookup on the local-ip-
. There is no guarantee that the name returned by a
DNS lookup actually maps back to the local IP address
. Lastly, without DNSSEC, it may not be safe to use DNS
because they can easily be spoofed. NAT and DNS-ALG cannot
unless DNSSEC is disabled
A common use of this application is people dialing in to
offices from their X terminals at home. Say, the X client is
on a host on the public side of the NAT and X server is running on
Holdrege & Srisuresh Informational [Page 7]
RFC 3027 Protocol Complications with NAT January 2001
host on the private side of the NAT. The DISPLAY variable
transmitted inline to the host the X client is running in some way
The process transmitting the contents of the DISPLAY variable
not know the address of the NAT
If the channel transmitting the DISPLAY variable is not encrypted
NAT device might solicit the help of an ALG to replace the IP
and configure a port in the valid display range (ports 6000
higher) to act as a gateway. Alternately, NAT may be configured
listen for incoming connections to provide access to the X Server(s),
without requiring an ALG. But, this approach increases the
risk by providing access to the X server that would not otherwise
available. As the ALG tampers with the IP addresses it will also
be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1
to be used. MIT-MAGIC-COOKIE-1 is the least secure of all
documented X Authorization methods
When START_TLS is used there may be client certificate
problems caused by the NAT depending on the information provided
the certificate
3.5 RSH/
RSH uses multiple sessions to support separate streams for stdout
stderr. A random port number is transmitted inline from the
to the server for use as stderr port. The stderr socket is
connection back from the server to the client. And unlike FTP,
is no equivalent to PASV mode. For traditional NAT, this is
problem as traditional NAT would not permit incoming sessions
RLOGIN does not use multiple sessions. But the Kerberos
versions of RSH and RLOGIN will not work in a NAT environment due
the ticket problems and the use of multiple sessions
4.0 Protocols that can work with the aid of an
This document predominantly addresses problems associated
Traditional NAT, especially NAPT
4.1
FTP is a TCP based application, used to reliably transfer
between two hosts. FTP uses bundled session approach to
this
FTP is initiated by a client accessing a well-known port number 21
the FTP server. This is called the FTP control session. Often,
additional data session accompanies the control session. By default
Holdrege & Srisuresh Informational [Page 8]
RFC 3027 Protocol Complications with NAT January 2001
the data session would be from TCP port 20 on server to the TCP
client used to initiate control session. However, the data
ports may be altered within the FTP control sessions using
encoded PORT and PASV commands and responses
Say, an FTP client is in a NAT supported private network. An FTP
will be required to monitor the FTP control session (for both
and PASV modes) to identify the FTP data session port numbers
modify the private address and port number with the externally
address and port number. In addition, the sequence
acknowledgement numbers, TCP checksum, IP packet length and
have to be updated. Consequently the sequence numbers in
subsequent packets for that stream must be adjusted as well as
ACK fields and checksums
In rare cases, increasing the size of the packet could cause it
exceed the MTU of a given transport link. The packet would then
to be fragmented which could affect performance. Or, if the
has the DF bit set, it would be ICMP rejected and the
host would then have to perform Path MTU Discovery. This could
an adverse effect on performance
Note however, if the control command channel is secured, it will
impossible for an ALG to update the IP addresses in the
exchange
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the
problems that occur with X-Term/Telnet occur with FTP
Lastly, it is of interest to note section 4 of RFC 2428 (
extensions for IPv6 and NATs) which describes how a new FTP
command (EPSV ALL) can be used to allow NAT devices to fast-track
FTP protocol, eliminating further processing through ALG, if
remote server accepts "EPSV ALL".
4.2
RSVP is positioned in the protocol stack at the transport layer
operating on top of IP (either IPv4 or IPv6). However, unlike
transport protocols, RSVP does not transport application data
instead acts like other Internet control protocols (for example
ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-
between RSVP-capable routers as raw IP datagrams using
number 46. It is intended that raw IP datagrams should be
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
I/O. Because of this, it is possible to encapsulate RSVP
within UDP datagrams for end-system communication. UDP-
Holdrege & Srisuresh Informational [Page 9]
RFC 3027 Protocol Complications with NAT January 2001
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
information concerning UDP encapsulation of RSVP messages;
Appendix C of RFC 2205.
An RSVP session, a data flow with a particular destination
transport-layer protocol, is defined by
Destination Address - the destination IP address for the
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 that is used
demultiplexing at a layer above the IP layer
NAT devices are presented with unique problems when it comes
supporting RSVP. Two issues are
1. RSVP message objects may contain IP addresses. The result is
an RSVP-ALG must be able to replace the IP addresses based upon
direction and type of the message. For example, if an
sender were to send an RSVP Path message to an internal receiver,
RSVP session will specify the IP address that the external
believes is the IP address of the internal receiver. However,
the RSVP Path message reaches the NAT device, the RSVP session
be changed to reflect the IP address that is used internally for
receiver. Similar actions must be taken for all message objects
contain IP addresses
2. RSVP provides a means, the RSVP Integrity object, to guarantee
integrity of RSVP messages. The problem is that because of the
point, a NAT device must be able to change IP addresses within
RSVP messages. However, when this is done, the RSVP Integrity
is no longer valid as the RSVP message has been changed.
an RSVP-ALG will not work when RSVP Integrity Object is used
4.3
DNS is a TCP/UDP based protocol. Domain Names are an issue for
which use local DNS servers in NAT private realm. DNS name
address mapping for hosts in private domain should be configured
an authoritative name server within private domain. This
would be accessed by external and internal hosts alike for
resolutions. A DNS-ALG would be required to perform address to
conversions on DNS queries and responses. [DNS-ALG] describes DNS
Holdrege & Srisuresh Informational [Page 10]
RFC 3027 Protocol Complications with NAT January 2001
in detail. If DNS packets are encrypted/authenticated per DNSSEC
then DNS_ALG will fail because it won't be able to perform
modifications
Applications using DNS resolver to resolve a DNS name into an
address, assume availability of address assignment for reuse by
application specific session. As a result, DNS-ALG will be
to keep the address assignment (between private and
addresses) valid for a pre-configured period of time, past the
query
Alternately, if there isn't a need for a name server within
domain, private domain hosts could simply point to an external
server for external name lookup. No ALG is required when the
server is located in external domain
4.4
SMTP is a TCP based protocol ([SMTP]), used by Internet
programs such as sendmail to send TCP-based email messages to well
known port 25. The mail server may be located within or
private domain. But, the server must be assigned a global name
address, accessible by external hosts. When mail server is
within private domain, inbound SMTP sessions must be redirected
the private host from its externally assigned address. No
mapping is required when Mail server is located in external domain
Generally speaking, mail systems are configured such that all
specify a single centralized address (such as fooboo@company.com),
instead of including individual hosts (such
fooboo@hostA.company.com). The central address must have an
record specified in the DNS name server accessible by external hosts
In the majority of cases, mail messages do not contain reference
private IP addresses or links to content data via names that are
visible to outside. However, some mail messages do contain
addresses of the MTAs that relay the message in the "Received: "
field. Some mail messages use IP addresses in place of FQDN
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
domain, and the mail messages are not secured by signature
cryptographic keys, an SMTP-ALG may be used to translate the
address information registered by the MTAs. If the MTAs have
address mapping, the translation would be valid across realms
long periods of time
Holdrege & Srisuresh Informational [Page 11]
RFC 3027 Protocol Complications with NAT January 2001
The ability to trace the mail route may be hampered or prevented
NAT alone, without the ALG. This can cause problems when
mail problems or tracking down abusive users of mail
4.5
SIP (Refer [SIP]) can run on either TCP or UDP, but by default on
same port 5060.
When used with UDP, a response to a SIP request does not go to
source port the request came from. Rather the SIP message
the port number the response should be sent to. SIP makes use
ICMP port unreachable errors in the response to
transmissions. Request messages are usually sent on the
socket. If responses are sent to the source port in the request
each thread handling a request would have to listen on the socket
sent the request on. However, by allowing responses to come to
single port, a single thread can be used for listening instead
A server may prefer to place the source port of each connected
in the message. Then each thread can listen for
separately. Since the port number for a response may not go to
source port of the request, SIP will not normally traverse a NAT
would require a SIP-ALG
SIP messages carry arbitrary content, which is defined by a
type. For multimedia sessions, this is usually the
Description Protocol (SDP RFC 2327). SDP may specify IP addresses
ports to be used for the exchange of multimedia. These may
significance when traversing a NAT. Thus a SIP-ALG would need
intelligence to decipher and translate realm-relevant information
SIP carries URL's in its Contact, To and From fields that
signaling addresses. These URL's can contain IP addresses or
names in the host port portion of the URL. These may not be
once they traverse a NAT
As an alternative to an SIP-ALG, SIP supports a proxy server
could co-reside with NAT and function on the globally significant
port. Such a proxy would have a locally specific configuration
4.6
In default mode, RealAudio clients (say, in a private domain)
TCP port 7070 to initiate conversation with a real-audio server (say
located an external domain) and to exchange control messages
playback (ex: pausing or stopping the audio stream). Audio
parameters are embedded in the TCP control session as byte stream
Holdrege & Srisuresh Informational [Page 12]
RFC 3027 Protocol Complications with NAT January 2001
The actual audio traffic is carried in the opposite direction
incoming UDP based packets (originated from the server) directed
ports in the range of 6970-7170.
As a result, RealAudio is broken by default on a traditional
device. A work around for this would be for the ALG to examine
TCP traffic to determine the audio session parameters and
enable inbound UDP sessions for the ports agreed upon in the
control session. Alternately, the ALG could simply redirect
inbound UDP sessions directed to ports 6970-7170 to the
address in the private domain
For bi-Directional NAT, you will not need an ALG. Bi-directional
could simply treat each of the TCP and UDP sessions as 2
sessions and perform IP and TCP/UDP header level translations
The readers may contact RealNetworks for detailed guidelines on
their applications can be made to work, traversing through NAT
firewall devices
4.7 H.323
H.323 is complex, uses dynamic ports, and includes multiple
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-
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
domain. For conferencing to be useful, external users need to
able to establish calls directly with internal users'
systems
The addresses and port numbers are exchanged within the data
of the 'next higher' connection. For example, the port number
the H.245 connection is established within the Q.931 data stream
(This makes it particularly difficult for the ALG, which will
required to modify the addresses inside these data streams.) To
matters worse, it is possible in Q.931, for example, to specify
the H.245 connection should be secure (encrypted). If a session
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,
Holdrege & Srisuresh Informational [Page 13]
RFC 3027 Protocol Complications with NAT January 2001
ASN.1-encoded (other parts of each Q.931 PDU are not encoded).
those unfamiliar with ASN.1, suffice it to say that it is a
encoding scheme, which does not end up with fixed byte offsets
address information. In fact, the same version of the
application connecting to the same destination may negotiate
include different options, changing the byte offsets
Below is the protocol exchange for a typical H.323 call between
A and User B. A's IP address is 88.88.88.88 and B's IP address
99.99.99.99. Note that the Q.931 and H.245 messages are encoded
ASN.1 in the payload of an RTP packet. So to accomplish a
through a NAT device, an H.323-ALG will be required to examine
packet, decode the ASN.1, and translate the various H.323 control
addresses
User A User
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
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
User A establishes connection to User B
99.99.99.99, port 1092
<---------------------------------------------->
Several H.245 messages are exchanged (
Capability Set, Master Slave Determination
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
data sent to
Holdrege & Srisuresh Informational [Page 14]
RFC 3027 Protocol Complications with NAT January 2001
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
sent to
RTCP address = 99.99.99.99
RTP port = 1093
Also note that if an H.323 Gateway resided inside a NAT boundary,
ALG would have to be cognizant of the various gateway
schemes and adapt to those schemes as well. Or if just the H.323
host/terminal was inside the NAT boundary and tried to register
a Gatekeeper, the IP information in the registration messages
have to be translated by NAT
4.8
SNMP is a network management protocol based on UDP. SNMP payload
contain IP addresses or may refer IP addresses through an index
a table. As a result, when devices within a private network
managed by an external node, SNMP packets transiting a NAT device
contain information that is not relevant in external domain. In
cases, as described in [SNMP-ALG], an SNMP ALG may be used
transparently convert realm-specific addresses into globally
addresses. Such an ALG assumes static address mapping and bi
directional NAT. It can only work for the set of data types (
conventions) understood by the SNMP-ALG implementation and for
given set of MIB modules. Furthermore, replacing IP addresses in
SNMP payload may lead to communication failures due to changes
message size or changes in the lexicographic ordering
Making SNMP ALGs completely transparent to all
applications is not an achievable task. The ALGs will run
problems with SNMPv3 security features, when authentication (
optionally privacy) is enabled, unless the ALG has access to
keys. [NAT-ARCH] also hints at potential issues with SNMP
via NAT
Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used
conjunction with NAT to forward SNMP messages to external
engines (and vice versa). SNMP proxies are tailored to the
Holdrege & Srisuresh Informational [Page 15]
RFC 3027 Protocol Complications with NAT January 2001
domain context and can hence operate independent of the
managed object types being accessed. The proxy solution will
the external management application to be aware of the
forwarder and the individual nodes being managed will need to
configured to direct their SNMP traffic (notifications and requests
to the proxy forwarder
5.0 Protocols designed explicitly to work with NAT
5.1 Activision
Activision Games were designed to be NAT-friendly so as not
require an ALG for the games to work transparently
traditional NAT devices. Game players within a private domain
play with other players in the same domain or external domain
Activision gaming protocol is proprietary and is based on UDP.
address server uses UDP port number 21157 and is expected to
located in the global address realm
Game players connect to the address server first, and send
private IP address information (such as private IP address and
port number) in the initial connect message. The server
private address information from the connect message and
address information from the IP and UDP headers. The server
sends both the private and external address information of the
player to all the other peer players. At this point, each
player knows the private and public address information of
other peer. Subsequent to this, each client opens up
direct connection to each other and uses whichever address (
or external) works first
Now, the clients can have a session directly with other clients (or
they can have session with other clients via the gaming server.
key is to allow reuse of the same (global address, assigned UDP port
tuple used for initial connection to the game server for
subsequent connections to the client. A game player is recognized
one of (private address, UDP port) or (global address, assigned
port) by all other peer players. So, the binding between
should remain unchanged on NAT, so long as the gaming player is
session with one or multiple other players
Opening a connection to a game server in external realm from
private host is no problem. All NAT would have to do is
routing transparency and retain the same private-to-external
binding so long as there is a minimum of one gaming session with
external node. But, an NAPT configuration must allow
simultaneous UDP connections on the same assigned
address/port
Holdrege & Srisuresh Informational [Page 16]
RFC 3027 Protocol Complications with NAT January 2001
The above approach has some problems. For example, a client
try contacting a private address, but that private address could
in use locally, when the private address at some other realm
meant. If the node that was contacted wrongfully has some
service or no service registered for the UDP port, the
connect messages are expected to be simply dropped. In the
event, a registered application chooses to interpret the message,
results can be unpredictable
The readers may refer to Activision for the proprietary,
information on the function and design of this protocol
6.0
The authors would like to express sincere thanks to Bernard Aboba
Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine
Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and
that had provided valuable input in preparing this document.
thanks to Dan Kegel for sharing the Activision games
methodology
7.0 Security
The security considerations outlined in [NAT-TERM] are relevant
all NAT devices. This document does not warrant additional
considerations
8.0
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP
Address Translator (Traditional NAT)", RFC 3022,
2001.
[H.323] ITU-T SG16 H.323, Intel white paper, "H.323
Firewalls", Dave Chouinard, John Richardson,
Khare (with further assistance from Jamie Jason).
[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An
Application Level Gateway for Payload
Translation", RFC 2962, October 2000.
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
RFC 2573, April 1999.
Holdrege & Srisuresh Informational [Page 17]
RFC 3027 Protocol Complications with NAT January 2001
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993,
November 2000.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10,
RFC 821, August 1982.
[FTP] Postel, J. and J. Reynolds, "File Transfer
(FTP)", STD 9, RFC 959, October 1985.
[SIP] Handley, M., Schulzrinne, H., Schooler, E. and J
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[X Windows] Scheifler, B., "FYI on the X Window System", FYI 6,
1198, January 1991.
[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S
Jamin, "Resource ReSerVation Protocol (RSVP) --
1 Functional Specification", RFC 2205, September 1997.
[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts
Facilities", STD 13, RFC 1034, November 1987.
[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A
Heffernan, "DNS extensions to Network
Translators (DNS_ALG)", RFC 2694, September 1999.
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating
Payload (ESP)", RFC 2406, November 1998.
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP
Document Roadmap", RFC 2411, November 1998.
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode
for NAT Domains", RFC 2709, October 1999.
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
Holdrege & Srisuresh Informational [Page 18]
RFC 3027 Protocol Complications with NAT January 2001
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv
Address Behaviour Today", RFC 2101, February 1997.
Authors'
Matt
223 Ximeno Ave
Long Beach, CA 90803
EMail: matt@ipverse.
Pyda
Jasmine Networks, Inc
3061 Zanker Road, Suite
San Jose, CA 95134
U.S.A
Phone: (408) 895-5032
EMail: srisuresh@yahoo.
Holdrege & Srisuresh Informational [Page 19]
RFC 3027 Protocol Complications with NAT January 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Holdrege & Srisuresh Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
