draft-ietf-nat-protocol-issues-00.txt   draft-ietf-nat-protocol-issues-01.txt 
NAT Working Group Matt Holdrege NAT Working Group Matt Holdrege
INTERNET-DRAFT Ascend Communications INTERNET-DRAFT Ascend Communications
Category: Informational Pyda Srisuresh Category: Informational Pyda Srisuresh
Lucent Technologies Lucent Technologies
Expires in six months August 1998 Expires in six months November 1998
IP Network Address Translator (NAT) Protocol Issues. IP Network Address Translator (NAT) Protocol Issues.
<draft-ietf-nat-protocol-issues-00.txt> <draft-ietf-nat-protocol-issues-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast). (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Preface: Preface:
Many common internet applications can be adversely affected when the Many common internet applications can be adversely affected when the
end-to-end significance of an IP packet is disrupted. Network Address end-to-end significance of an IP packet is disrupted. Network
Translation (NAT) can cause such disruptions both at the protocol level Address Translation (NAT) can cause such disruptions both at the
and with application data. This draft covers issues with standard protocol level and with application data.
protocols when transiting a NAT device.
It is worth noting that many non-standard protocols used on the Internet
also have issues with NAT devices. These include interactive games and
certain audio/video applications. However since such
applications/protocols are constantly coming and going, we will only
document long-living standard protocols in the main body. Please read
Appendix A for a current snapshot of non-standard protocols which are
known to have issues with NAT.
While there are ready solutions for NATing each protocol listed, this
document is only concerned with defining the native limitations. Future
versions of this document may discuss workarounds.
*NOTE* the authors wish to make it clear that this work is editorial in
I-D NAT Protocol Issues August 1998 While there are ready solutions for NATing each protocol listed,
this document is only concerned with defining the native
limitations. Future versions of this document may discuss
workarounds.
nature and that input from the Internet society is requested in order to *NOTE* the authors wish to make it clear that this work is editorial
better cover the range of applications that can be affected by NAT. This in nature and that input from the Internet society is requested in
is a work in progress. order to better cover the range of applications that can be affected
by NAT. This is a work in progress.
Introduction: Introduction:
NAT provides a transparent routing solution to end hosts trying to NAT provides a transparent routing solution to end hosts trying to
communicate from disparate routing realms. This transparent routing is communicate from disparate routing realms. This transparent routing
achieved by modifying end node addresses en-route and maintaining state
for these updates so that datagrams pertaining to a session are I-D NAT Protocol Issues November 1998
transparently routed to the right end-node in either realm. NAT's
fundamental role is to alter the addresses in the IP header of a packet. is achieved by modifying end node addresses en-route and maintaining
state for these updates so that datagrams pertaining to a session
are transparently routed to the right end-node in either realm.
NAT's fundamental role is to alter the addresses in the IP header of
a packet.
NAT can use much of the same solution set as a Stateful Inspection NAT can use much of the same solution set as a Stateful Inspection
firewall. However, NAT must also be able to recompose valid data in the firewall. However, NAT must also be able to recompose valid data in
control streams, since it must change the address (and perhaps port) the control streams, since it must change the address (and perhaps
information. This is because the application running on a host machine port) information. This is because the application running on a host
is typically unaware of NAT and thus populates messages with addressing machine is typically unaware of NAT and thus populates messages
information that is not valid on the opposite side of the NAT device. with addressing information that is not valid on the opposite side
of the NAT device.
One problem area is when a packet contains significant IP address or One problem area is when a packet contains significant IP address or
port information in the payload of the packet rather than the header. port information in the payload of the packet rather than the
Network applications which use protocols that exhibit this behavior will header. Network applications which use protocols that exhibit this
have problems when a NAT device is in mid-stream. In the next section we behavior will have problems when a NAT device is in mid-stream. In
will attempt to document standard protocols which have significant the next section we will attempt to document standard protocols
address information in the payload of the packet. which have significant address information in the payload of the
packet.
Protocols:
1. PROTOCOL: FTP REFERENCE: RFC 959 FTP REFERENCE: RFC 959
FTP is a TCP based application, used to reliably transfer files between FTP is a TCP based application, used to reliably transfer files
two hosts. between two hosts.
FTP is initiated by a client accessing a well-known port number 21 on FTP is initiated by a client accessing a well-known port number 21
the FTP server. This is called the FTP control session. Often, an on the FTP server. This is called the FTP control session. Often,
additional data session accompanies the control session. By default, the an additional data session accompanies the control session. By
data session would be from TCP port 20 on server to the TCP port client default, the data session would be from TCP port 20 on server to the
used to initiate control session. However, the data session ports may be TCP port client used to initiate control session. However, the data
altered within the FTP control sessions using ASCII encoded PORT and session ports may be altered within the FTP control sessions using
PASV commands and responses. ASCII encoded PORT and PASV commands and responses.
Say, an FTP client is in a NAT supported private network. NAT will be Say, an FTP client is in a NAT supported private network. NAT will
required to monitor the FTP control session (for both PORT and PASV be required to monitor the FTP control session (for both PORT and
modes) to identify the FTP data session port numbers and modify the PASV modes) to identify the FTP data session port numbers and modify
private address and port number with the externally valid address and the private address and port number with the externally valid
port number. In addition, the sequence and acknowledgement numbers, TCP address and port number. In addition, the sequence and
checksum, IP packet length and checksum have to be updated. Consequently acknowledgement numbers, TCP checksum, IP packet length and checksum
the sequence numbers in all subsequent packets for that stream must be have to be updated. Consequently the sequence numbers in all
adjusted as well as TCP ACK fields and checksums. subsequent packets for that stream must be adjusted as well as TCP
ACK fields and checksums.
Another issue can arise when applications when addresses and port Another issue can arise when applications when addresses and port
numbers are encoded with ASCII. Changing these numbers can change the numbers are encoded with ASCII. Changing these numbers can change
size of the overall packet. In rare cases, increasing the size of the the size of the overall packet. In rare cases, increasing the size
of the packet could cause it to exceed the MTU of a given transport
I-D NAT Protocol Issues August 1998 link. The packet would then have to be fragmented which could affect
performance. Or if the packet has the DF bit set, it would be ICMP
rejected and the originating host would then perform Path MTU
Discovery. This could also have an adverse effect on performance.
packet could cause it to exceed the MTU of a given transport link. The I-D NAT Protocol Issues November 1998
packet would then have to be fragmented which could affect performance.
Or if the packet has the DF bit set, it would be ICMP rejected and the
originating host would then perform Path MTU Discovery. This could also
have an adverse effect on performance.
2. PROTOCOL H.323V1 REFERENCE ITU-T SG16 H.323V1 REFERENCE ITU-T SG16 H.323, Intel white paper, H.323 and
H.323, Intel white paper, H.323 and Firewalls. Dave Chouinard, John Firewalls Dave Chouinard, John Richardson, Milind Khare (with
Richardson, Milind Khare (with further further assistance from Jamie Jason).
assistance from Jamie Jason).
H.323 is complex, uses dynamic ports, and includes multiple UDP streams. H.323 is complex, uses dynamic ports, and includes multiple UDP
Here is a summary of the relevant issues: streams. Here is a summary of the relevant issues:
An H.323 call is made up of many different simultaneous connections. At An H.323 call is made up of many different simultaneous connections.
least two of the connections are TCP. For an audio-only conference, At least two of the connections are TCP. For an audio-only
there may be up to 4 different UDP 'connections' made. conference, there may be up to 4 different UDP 'connections' made.
All connections except one are made to ephemeral (dynamic) ports. All connections except one are made to ephemeral (dynamic) ports.
Calls can be initiated from the Internet, as well as from inside the NAT Calls can be initiated from the Internet, as well as from inside the
device. For conferencing to be useful, external users need to be able to NAT device. For conferencing to be useful, external users need to be
establish calls directly with internal users' desktop systems. able to establish calls directly with internal users' desktop
systems.
The addresses and port numbers are exchanged within the data stream of The addresses and port numbers are exchanged within the data stream
the 'next higher' connection. For example, the port number for the H.245 of the 'next higher' connection. For example, the port number for
connection is established within the Q.931 data stream. (This makes it the H.245 connection is established within the Q.931 data stream.
particularly difficult for NAT devices, which must modify the addresses (This makes it particularly difficult for NAT devices, which must
inside those data streams.) To make matters worse, it is possible in modify the addresses inside those data streams.) To make matters
Q.931, for example, to specify that the H.245 connection should be worse, it is possible in Q.931, for example, to specify that the
secure (encrypted). H.245 connection should be secure (encrypted).
Most of the control information is encoded in ASN.1 (only the User-User Most of the control information is encoded in ASN.1 (only the User-
Information within Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded User Information within Q.931 Protocol Data Units, or PDUs, is
(other parts of each Q.931 PDU are not encoded). For those unfamiliar ASN.1-encoded (other parts of each Q.931 PDU are not encoded). For
with ASN.1, suffice it to say that it is a complex encoding scheme, those unfamiliar with ASN.1, suffice it to say that it is a complex
which does not end up with fixed byte offsets for address information. encoding scheme, which does not end up with fixed byte offsets for
In fact, the same version of the same application connecting to the same address information. In fact, the same version of the same
destination may negotiate to include different options, changing the application connecting to the same destination may negotiate to
byte offsets. include different options, changing the byte offsets.
Below is the protocol exchange for a typical H.323 call between User A Below is the protocol exchange for a typical H.323 call between User
and User B. A's IP address is 88.88.88.88 and B's IP address is 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 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 ASN.1 in the payload of an RTP packet. So to accomplish a connection
through a NAT device, we would have to go into the packet, decode the through a NAT device, we would have to go into the packet, decode
ASN.1, and translate the various H.323 control IP addresses. the ASN.1, and translate the various H.323 control IP addresses.
User A User B User A User B
A establishes connection to B on well- A establishes connection to B on well-
known Q.931 port (1720) known Q.931 port (1720)
-----------------------------------------------> ----------------------------------------------->
Q.931 Setup caller address = 88.88.88.88 Q.931 Setup caller address = 88.88.88.88
I-D NAT Protocol Issues August 1998
caller port = 1120 caller port = 1120
callee address = 99.99.99.99 callee address = 99.99.99.99
callee port = 1720 callee port = 1720
<----------------------------------------------- <-----------------------------------------------
Q.931 Alerting Q.931 Alerting
<----------------------------------------------- <-----------------------------------------------
I-D NAT Protocol Issues November 1998
Q.931 Connect H.245 address = 99.99.99.99 Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092 H.245 port = 1092
User A establishes connection to User B at User A establishes connection to User B at
99.99.99.99, port 1092 99.99.99.99, port 1092
<----------------------------------------------> <---------------------------------------------->
Several H.245 messages are exchanged (Terminal Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and Capability Set, Master Slave Determination and
their respective ACKs) their respective ACKs)
skipping to change at page 4, line 49 skipping to change at page 4, line 43
RTCP port = 2003 RTCP port = 2003
<----------------------------------------------- <-----------------------------------------------
H.245 Open Logical Channel Ack, channel = 257 H.245 Open Logical Channel Ack, channel = 257
RTP address = 99.99.99.99 RTP address = 99.99.99.99
RTP port = 1092 RTP port = 1092
(This is where User B would like RTP data (This is where User B would like RTP data
sent to) sent to)
RTCP address = 99.99.99.99 RTCP address = 99.99.99.99
RTP port = 1093 RTP port = 1093
Also note that if an H.323 Gateway resided inside a NAT boundary, any of Also note that if an H.323 Gateway resided inside a NAT boundary,
the various gateway discovery schemes being discussed for use would have any of the various gateway discovery schemes being discussed for use
difficulty working through NAT. Or if just the H.323 host/terminal was would have difficulty working through NAT. Or if just the H.323
inside the NAT boundary and tried to register with a Gatekeeper, the IP host/terminal was inside the NAT boundary and tried to register with
information in the registration messages would have to be translated by a Gatekeeper, the IP information in the registration messages would
NAT. have to be translated by NAT.
3. PROTOCOL RSVP REFERENCE RFC 2205 RSVP Reference RFC 2205
RSVP is positioned in the protocol stack at the transport layer, RSVP is positioned in the protocol stack at the transport layer,
I-D NAT Protocol Issues August 1998
operating on top of IP (either IPv4 or IPv6). However, unlike other operating on top of IP (either IPv4 or IPv6). However, unlike other
transport protocols, RSVP does not transport application data but transport protocols, RSVP does not transport application data but
instead acts like other Internet control protocols (for example, ICMP, instead acts like other Internet control protocols (for example,
IGMP, routing protocols). RSVP messages are sent hop-by-hop between ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-hop
RSVP-capable routers as raw IP datagrams using protocol number 46. It is between RSVP-capable routers as raw IP datagrams using protocol
intended that raw IP datagrams should be used between the end systems number 46. It is intended that raw IP datagrams should be used
and the first (or last) hop router. However, this may not always be
possible as not all systems can do raw network I/O. Because of this, it I-D NAT Protocol Issues November 1998
is possible to encapsulate RSVP messages within UDP datagrams for end-
system communication. UDP-encapsulated RSVP messages are sent to either between the end systems and the first (or last) hop router.
port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP- However, this may not always be possible as not all systems can do
enabled router). For more information concerning UDP encapsulation of raw network I/O. Because of this, it is possible to encapsulate RSVP
RSVP messages, consult Appendix C of RFC 2205. messages within UDP datagrams for end-system communication. UDP-
encapsulated RSVP messages are sent to either port 1698 (if sent by
an end system) or port 1699 (if sent by an RSVP-enabled router). For
more information concerning UDP encapsulation of RSVP messages,
consult Appendix C of RFC 2205.
An RSVP session, a data flow with a particular destination and An RSVP session, a data flow with a particular destination and
transport-layer protocol, is defined by: transport-layer protocol, is defined by:
Destination Address - the destination IP address for the data packets. Destination Address - the destination IP address for the data
This may be either a unicast or a multicast address. packets. This may be either a unicast or a multicast address.
Protocol ID - the IP protocol ID (for example, UDP or TCP). Protocol ID - the IP protocol ID (for example, UDP or TCP).
Destination Port - a generalized destination port which is used for Destination Port - a generalized destination port which is used for
demultiplexing at a layer above the IP layer. demultiplexing at a layer above the IP layer.
NAT devices are presented with unique problems when it comes to NAT devices are presented with unique problems when it comes to
supporting RSVP. Two issues are... supporting RSVP. Two issues are...
1. RSVP message objects may contain IP addresses. The result is that NAT 1. RSVP message objects may contain IP addresses. The result is that
must be able to replace the IP addresses based upon the direction and NAT must be able to replace the IP addresses based upon the
type of the message. For example, if an external sender were to send an direction and type of the message. For example, if an external
RSVP Path message to an internal receiver, the RSVP Session will specify sender were to send an RSVP Path message to an internal receiver,
the IP address that the external sender believes is the IP address of the RSVP Session will specify the IP address that the external
the internal receiver. However, when the RSVP Path message reaches the sender believes is the IP address of the internal receiver. However,
NAT device, the RSVP Session must be changed to reflect the IP address when the RSVP Path message reaches the NAT device, the RSVP Session
that is used internally for the receiver. Similar actions must be taken must be changed to reflect the IP address that is used internally
for all message objects that contain IP addresses. for the receiver. Similar actions must be taken for all message
objects that contain IP addresses.
2. RSVP provides a means, the RSVP Integrity object, to guarantee the 2. RSVP provides a means, the RSVP Integrity object, to guarantee
integrity of RSVP messages. The problem is that because of the first the integrity of RSVP messages. The problem is that because of the
point, a NAT device must be able to change IP addresses within the RSVP first point, a NAT device must be able to change IP addresses within
messages. However, when this is done, the RSVP Integrity object is no the RSVP messages. However, when this is done, the RSVP Integrity
longer valid as the RSVP message has been changed. object is no longer valid as the RSVP message has been changed.
DNS: DNS:
Domain Names are an issue for hosts which use local DNS servers behind a Domain Names are an issue for hosts which use local DNS servers
NAT device. Such servers return site specific information which may behind a NAT device. Such servers return site specific information
conflict with true Internet names and addresses. which may conflict with true Internet names and addresses.
Also DNS Zone Transfers are not translated by NAT and should not be sent Also DNS Zone Transfers are not translated by NAT and should not be
through a NAT device. sent through a NAT device.
ROUTING UPDATES: A DNS resolver is a UDP based application, initiated by accessing a
well-known UDP port number 53 on a DNS server.
I-D NAT Protocol Issues August 1998 CHARACTERISTICS:
Routing updates from the Internet will not be translated through NAT and I-D NAT Protocol Issues November 1998
have ni significance to routers behind a NAT device. Conversely routing
updates from behind NAT should not be forwarded to the Internet. A. UDP based protocol.
B. Inverse name lookup queries embed the IP address in ASCII
format. For example, a resolver that wanted to find the
hostname of an address 198.76.29.1 (externally assigned
address of a private realm host) would pursue a query of
the form:
QTYPE = PTR, QCLASS= IN, QNAME = 1.29.76.198.IN-ADDR.ARPA
An ALG is required to translate the query while forwarding to a DNS
server within private realm, so that the query will appear as
follows (replacing 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 when payload is
translated.
C. Serial reuse of an address assignment between independent
sessions. This requires that the ALG keep 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
to a name lookup is serially reusable by a follow-on
application.
D. A single DNS query payload could contain multiple queries at the
same time, requiring translation of multiple addresses within
a private domain.
CONFIGURATION ISSUES:
DNS name to address mapping for hosts in private domain should be
configured on an authorititive name server within the 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 to name conversions on DNS queries and responses.
Alternately, if there isnt a need for a name server within private
domain, private domain hosts could simply point to an external name
server for external name lookup. No ALG is required when the name
server is located in external domain.
WHAT BREAKS: Authoritative name server for public domain access mUst
not contain hosts with private IP addresses.
ADDITIONAL INFO: Refer RFC 1034, RFC 1035, DNS-ALG draft
EMAIL: E-Mail programs - sendmail, Eudora, and others.
I-D NAT Protocol Issues November 1998
DESCRIPTION: All e-mail programs listed above operate based on a
TCP based SMTP protocol and use a well-known port number 25 to send
messages and to listen on incoming messages.
CHARACTERISTICS:
A. SMTP is a TCP based protocol, based on a well known TCP port
number 25.
B. Mail messages are not expected to contain reference to
private IP addresses or links to content data via names
that are not visible to outside.
CONFIGURATION ISSUES:
You need to specify a mail server, with a globally assigned IP
address to receive mail from external hosts.
Generally speaking, you would want to configure your mail system
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.
The mail server may be located within or outside private domain.
But, the requirement is that the server be assigned a global name
and address, accessible by external hosts.
NAT would not perform any payload translation on SMTP messages.
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.
WHAT BREAKS: When the mail message contains reference to private IP
addresses or links to content data via names that are not visible to
outside.
ADDITIONAL INFO: RFC 821.
X-Windows:
DESCRIPTION: These applications are TCP based. However, the
client-server relationship with these applications is reverse
compared to most other applications. The X-server or Open-windows
server is the display/mouse/keyboard unit (i.e., the one that
controls the actual Windows interface). The clients are the
application programs driving 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 Open
I-D NAT Protocol Issues November 1998
Windows server can be at port 6000 or port 2000 (more flexible). We
will refer X-windows mainly for illustration purposes here.
On a UNIX system, the csh DISPLAY command "setenv DISPLAY
<hostname>:n", where n>= 0, is used to tell clients to contact X
server on <hostname> on TCP port (6000+n). It is very unlikely to be
running more than a few (say 4) X-servers at a time on a host.
Most 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 the server
servicing TCP ports in the range of 6000 - 6000+n.
Open-Windows is also a TCP based protocol, with the server
servicing TCP ports in the range of 6000 - 6000+n or
2000 - 2000+n.
B. The X-Windows applications are not expected to contain
reference to private IP addresses or links to content
data via names that are not visible to the outside. All
the information required for Client-Server communication
is in the IP and TCP headers.
CONFIGURATION ISSUES:
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 that need
to provide X-terminal access must have inbound access permissions.
This can be done statically or dynamically for private hosts.
In case of a NAPT setup, the individual X-Windows ports namely,
6000, 6001, 6002, 6003 and so on till (6000+n) on the external
address may 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.
WHAT BREAKS: Accessing more X-servers than are configured.
ADDITIONAL INFO: RFC 1198.
RealAudio
DESCRIPTION: In its default mode, 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
I-D NAT Protocol Issues November 1998
control messages during playback (ex: pausing or stopping the audio
stream).
The actual audio traffic is carried on incoming UDP based packets
(originated from the server) directed to ports in the range of
6970-7170.
CHARACTERISTICS:
A. Real Audio has a TCP control session in one direction directed
to a well-known port (7070) and the UDP based audio session in
the opposite direction.
B. Audio session parameters are embedded in the TCP control
session as byte stream(?)
CONFIGURATION
You could have an ALG 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 simply perform IP and TCP/UDP header level
translations.
WHAT BREAKS:
ADDITIONAL INFO: http://www.real.com/firewall/packetfil.html
Activision Games
DESCRIPTION: The goal of Activision Games is to work transparently
through traditional NAT devices. As such, the protocol described is
intended to be NAT friendly so game players within a private domain
can play with other players in 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 session with other clients via the
gaming server.
CHARACTERISTICS:
I-D NAT Protocol Issues November 1998
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 the same private domain, in a combination
of multiple private domains and external domain.
C. The key is to allow the reuse of the tuple of the same (global
address, assigned UDP port) for initial connection to the game
server (helper) and the subsequent connection to the client. A game
player is recognized by one of (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 one or multiple other
players.
CONFIGURATION ISSUES:
Opening a connection to a game server in external realm from a
private host is no problem. All NAT would have to do is provide
routing transparency.
But, an NAPT configuration MUST allow multiple simultaneous UDP
connections on 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
ROUTING UPDATES:
Routing updates from the Internet will not be translated through NAT
and have no significance to routers behind a NAT device. Conversely
routing updates from behind NAT should not be forwarded to the
Internet.
SECURITY: SECURITY:
Another class of problems with NAT is end-to-end security of packets. Another class of problems with NAT is end-to-end security of
The IPsec AH standard [RFC 1826] is explicitly intended to prevent what packets. The IPsec AH standard [RFC 1826] is explicitly intended to
NAT is good at. That is altering the header of the packet. So when NAT prevent what NAT is good at. That is altering the header of the
does what it is supposed to do by altering the address information in packet. So when NAT does what it is supposed to do by altering the
the header of the packet, the destination host receives the altered address information in the header of the packet, the destination
packet and begins digesting the AH message. The AH routines at this host host receives the altered packet and begins digesting the AH
will invalidate the packet since the contents of the headers have been message. The AH routines at this host will invalidate the packet
altered. Depending on the configuration of the end host, the packet since the contents of the headers have been altered. Depending on
could be simply dropped, or higher layer security activities could be the configuration of the end host, the packet could be simply
started.
I-D NAT Protocol Issues November 1998
dropped, or higher layer security activities could be started.
Other IPsec protocols with NAT issues: Other IPsec protocols with NAT issues:
Protocol Issues Protocol Issues
ESP: Protects/obscures the packet contents (which would ESP: Protects/obscures the packet contents (which would
need to be visible for NATing some protocols). need to be visible for NATing some protocols).
IKE: Potentially passes IP addresses during both Main, IKE: Potentially passes IP addresses during both Main, Aggressive
Aggressive and Quick Modes. In order for a negotiation and Quick Modes. In order for a negotiation to correctly pass
to correctly pass through a NAT, these payloads would through a NAT, these payloads would need to be modified. However,
need to be modified. However, these payloads are often these payloads are often protected by hash or obscured by
protected by hash or obscured by encryption. encryption.
Authors Addresses: Authors Addresses:
Matt Holdrege Matt Holdrege
Ascend Communications, Inc. Ascend Communications, Inc.
One Ascend Plaza One Ascend Plaza
1701 Harbor Bay Parkway 1701 Harbor Bay Parkway
Alameda, CA 94502 Alameda, CA 94502
Voice: (510) 769-6001 Voice: (510) 769-6001
EMail: matt@ascend.com EMail: matt@ascend.com
Pyda Srisuresh Pyda Srisuresh
Lucent technologies Lucent Technologies
4464 Willow Road 4464 Willow Road
Pleasanton, CA 94588-8519 Pleasanton, CA 94588-8519
U.S.A. U.S.A.
Voice: (925) 737-2153 Voice: (925) 737-2153
EMail: suresh@ra.lucent.com EMail: suresh@ra.lucent.com
Appendix A:
I-D NAT Protocol Issues August 1998
talk and ntalk
IRC
VDOLive
NetShow
VXtreme
Doom
Quake
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/