RFC 3027
Protocol Complications with the IP Network Address Translator
Protocol Complications with the IP Network Address Translator 🎀
okay bestie, this is RFC 3027 💖 and it's giving informational energy, so it's a heads-up guide, not a rule book 🌸
- Network Working Group
- Category: Informational (it describes things, it doesn't set a standard) 📖
- Date: January 2001 🗓️
- Authors: M. Holdrege (ipVerse) and P. Srisuresh (Jasmine Networks) ✨
- Obsoletes / Updates: the title block lists neither, so this doesn't replace or update any earlier RFC 🦋
Status of this Memo 📝
this memo gives info to the internet community. it does not specify an internet standard of any kind 🙅♀️ and distribution is unlimited 💅
Copyright Notice ©️
Copyright (C) The Internet Society (2001). All Rights Reserved. 🫶
Abstract 🌈
okay so, lots of internet apps get messed up when the two end nodes aren't in the same address realm and need a NAT (IP Network Address Translator) to bridge the gap 😭 the NAT on its own can't give every app the transparency it needs, so it calls in Application Level Gateways (ALGs) where it can 🧚
this doc is all about spotting which protocols and apps break with NAT in the middle, and it also tries to mention any known workarounds 🔥 real talk though, it's impossible to catch every app that breaks in one doc. this one gathers as much as it can, but it's not a full list. we hope it gives you enough clues for the apps that aren't covered 💜
Table of Contents 📚
1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 201.0 Introduction ✨
so this doc assumes you already know the NAT basics from [NAT-TERM] 🎀 the nutshell version: NAT gives end hosts a see-through routing solution when they need to talk to a different address realm 🦋 it rewrites end node addresses (inside the IP header of a packet) while the packet is en route, and it keeps state for those rewrites so datagrams for a session get routed to the right end node on either side 💖 ALGs can team up with NAT where it's possible to give app-level transparency 🫶 the difference is that ALGs are app-specific and would probably need to look at and rebuild the IP payload 🔥
the sections below list apps that we know NAT devices in the middle have messed with 🙈 but this is definitely not the full list of every protocol and app with NAT complications. it's more like a sample the authors collected 💅 and fyi, this doc isn't trying to hype NAT up. it's just pointing out the drama that happens when NAT devices are en route 🥀
2.0 Common Characteristics of Protocols broken by NAT 🧩
[NAT-TERM] and [NAT-TRAD] both have sections on the specific problems and limits of NAT devices 📚 a few of those limits get restated here to sum up what protocols tend to get broken by NAT ✨
2.1 Realm-specific IP address information in payload 🌸
a lot of apps fail with NAT en route when IP packets have realm-specific IP address or port info in the payload 😭 an ALG can sometimes work around it 🧚 but if the payload is IPsec secured (or secured by a transport or app-level security mechanism), the app is basically doomed 💀
2.2 Bundled session applications 🎀
bundled session apps like FTP, H.323, SIP and RTSP use a control connection to set up a data flow, and they're usually broken by NAT devices en route too 🙈 the reason is that these apps swap address and port parameters inside the control session to set up data sessions and session orientations 💅 NAT can't tell that the bundled sessions depend on each other, so it treats every session as unrelated 🫠 the app can fail for a bunch of reasons. the two most likely are:
- (a) addressing info in the control payload is realm-specific, so it's not valid once the packet crosses out of the originating realm
- (b) the control session allows data sessions to start in a direction that NAT might not allow
when DNS names show up in the control payload, a NAT paired with a DNS-ALG might be able to give the app-level transparency it needs, as long as NAT doesn't clash with the data session orientation 🧚 but using DNS names instead of realm-specific IP addresses might not be an option for a lot of these apps (FTP, for example) 🥺
when realm-specific addressing is in the payload and the payload isn't encrypted, an ALG might sometimes work around it so the apps run transparently across realms ✨ how complicated the ALG is depends on how much app-level knowledge it needs to process the payload and keep state 🧠
2.3 Peer-to-peer applications 🫶
peer-to-peer apps are way more likely to break with NAT en route than client-server apps are 😭 the difference is that a peer-to-peer app can be started by any of the peers 💖 when peers are spread across private and public realms, a session started from the external realm is just as likely as one started from a host in the private realm 💅 external peers can only find their peers in the private realm if they already know the externally assigned IP address or the FQDN ahead of time 🔍 the FQDN-to-assigned-address mapping only works as long as the NAT device in the middle supports a DNS-ALG 🧚 examples of peer-to-peer apps include interactive games, Internet telephony and event-based protocols (like Instant-Messaging) 🎮📞💬
this is especially a problem with traditional NAT, and it might be less of an issue with bi-directional NAT, where sessions are allowed in both directions 🦋
one possible workaround for this problem with traditional NAT is for private hosts to keep an outbound connection open with a server that acts as their representative on the globally routed Internet 🌐✨
2.4 IP fragmentation with NAPT enroute 🧩
IP fragmentation with NAPT en route isn't a problem for any single app 🙅♀️ it spreads across all TCP/UDP apps 🌍 the problem is described in detail in [NAT-TRAD], but here's the quick version 💀 say two private hosts both send fragmented TCP/UDP packets to the same destination host, and they happen to use the same fragmentation identifier 😬 when the target host gets the two unrelated datagrams with the same fragmentation id, from the same assigned host address, it has no way to tell which session each datagram belongs to 🤯 so both sessions get corrupted 💔
2.5 Applications requiring retention of address mapping 🔐
NAT will most likely break apps that need an address mapping to stick around across back-to-back sessions 😭 these apps need the private-to-external address mapping kept between sessions so the same external address can be reused for later session interactions 🎀 NAT has no way of knowing that requirement, so it might reassign an external address to a different host between sessions 🙃
to stop NAT from throwing out an address mapping, you'd need a NAT extension protocol that lets the app tell the NAT device to keep the mappings 📡 or, an ALG might be needed to work with NAT so the address mapping doesn't get discarded 🧚
2.6 Applications requiring more public addresses than available 🌈
this is a problem when there are more private hosts than the external addresses available to map the private addresses into 😵 take the rlogin service started from a host in a private realm that's supported by NAPT as an example 🖥️ rlogin clients use the well-known rlogin port 512 as their TCP port ID 📌 so no more than one host in the private realm can start the service 💀 that's a service that fundamentally needs more public addresses than there are available 🙃 NAT devices can conserve addresses, but they cannot create more addresses 🫠
3.0 Protocols that cannot work with NAT enroute 🚫
3.1 IPsec and IKE 🔒
okay this is the big one 😭 NAT fundamentally works by modifying end node addresses (inside the IP header) en route 💅 the IPsec AH standard [IPsec-AH], on the other hand, is explicitly designed to detect changes to the IP packet header 🕵️♀️ so when NAT changes the address info in the IP header while en route, the destination host that receives the altered packet will invalidate it, since the header contents have changed 💔 as a result, an IPsec AH packet that goes through NAT just won't reach the target app 🥀
IPsec ESP ([IPsec-ESP]) encrypted packets can only be altered by a NAT device en route in a limited number of cases 🤏 for TCP/UDP packets, NAT would need to update the checksum in the TCP/UDP header whenever an address in the IP header changes 🧮 but since ESP encrypts the TCP/UDP header, NAT can't make that checksum update 🔐 so TCP/UDP packets encrypted in transport mode ESP that go through a NAT device will fail the TCP/UDP checksum validation on the receiving end and just won't reach the target app 😩
Internet Key Exchange Protocol (IKE) can potentially pass IP addresses as node identifiers during Main, Aggressive and Quick Modes 🔑 for an IKE negotiation to get through a NAT correctly, those payloads would need to be modified 🛠️ the catch is, these payloads are often protected by a hash or hidden by encryption, so that's not really doable 🙈 and even if IP addresses aren't used in the IKE payloads and an IKE negotiation could happen without interruption, there's still trouble keeping the private-to-external address mapping on the NAT from the moment IKE finishes negotiating to the moment IPsec uses the key for an application ⏳ in the end, end-to-end IPsec is already badly hampered anyway, as described earlier 💔
for all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute 🥹💅✨
3.2 Kerberos 4 🔐
Okay bestie, Kerberos 4 tickets are encrypted, so an ALG cannot be written 😭. When the KDC gets a ticket request, it puts the source IP address into the returned ticket. Not every Kerberos 4 service actually checks source IP addresses. AFS is a great example of one that doesn't 🙈. Services that don't check aren't picky about NAT devices enroute. Kerberos tickets are tied to the IP address that requested the ticket and to the service they're meant to be used with 💜.
The K4 ticket (response) contains a single IP address describing the interface the client used to retrieve the ticket from the TGT, from the KDC's point of view. This works fine if the KDC is across a NAT gateway, as long as all of the Kerberos services are also across a NAT gateway. The end user on the private network won't notice any problems ✨.
There's also a caveat 👀. NAT uses the same address mapping for the private host for the connection between the client and the KDC as it does for the connection between the client and the application server. A workaround would be to keep an arbitrary connection open to the remote server during the entire ticket lifetime, so NAT doesn't drop the address binding. Alternatively, an ALG will need to be deployed to make sure NAT doesn't change address bindings during the lifetime of a ticket, including the time between when the ticket is issued to the private host and when the private host uses it 🧚.
But the ticket will be valid from any host within the private realm of NAPT 😬. Without NAPT, an attacker needs to be able to spoof the source IP addresses of a connection being made in order to use a stolen ticket on a different host. With NAPT, all the attacker needs to do from within the private realm is gain possession of a ticket. Of course, this assumes the NAPT private domain is not a trusted network, which is not surprising, since many attacks occur from inside the organization 💀.
⚠️ Security reality check: a stolen Kerberos 4 ticket behind NAPT is basically a free pass for anyone inside the private realm. Treat that private network like it isn't trusted, because attacks really do come from the inside.
3.3 Kerberos 5 🦋
Just like Kerberos 4, Kerberos 5 tickets are encrypted, so an ALG cannot be written 🔒.
In Kerberos 5, the client specifies a list of IP addresses the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket, or a ticket containing the NAPT device address, you can get krb5 to work with a NAPT device. It isn't very transparent, though, since it requires the clients to behave differently than they otherwise would 🙃. The MIT krb5 1.0 implementation didn't have any configurability for which IP addresses the client asked for (it always asked for the set of its interface addresses), and it didn't interact well with NAT 💅. The MIT krb5 1.1 implementation lets you put noaddresses somewhere in krb5.conf to request all-IP-addresses-valid tickets ✨.
The K5 ticket (response) contains IP addresses, as requested by the client node, from which the ticket is considered valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, the Kerberos authentication will fail, because the IP address used by the NAT (basic NAT or NAPT) isn't in the list of acceptable addresses 💔.
There are two workarounds in Kerberos 5, and both of them reduce the security of the tickets 😩. The first is to have the clients in the NAPT private realm specify the public IP address of the NAPT in the ticket's IP list. But this leads to the same security problem detailed for K4. Plus, it isn't obvious for a client in the private domain to find out the public IP address of the NAPT. That would be a change of application behavior on the end host.
The second method is to remove all IP addresses from the K5 tickets. This makes theft of the ticket even worse, since the tickets can be used from anywhere, not just from within the private network 🚨.
3.4 The X Windowing System and X-term/Telnet 🖥️
The X Windowing System is TCP based. However, the client-server relationship is reversed compared to most other applications 🔄. The X server (or Open-windows server) is the display/mouse/keyboard unit, the one that controls the actual Windows interface. The clients are the application programs driving that 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 Windows server can be at port 6000 or port 2000, which is more flexible 🌈. We will mainly refer to the X Windowing System for illustration purposes here.
X-term transmits IP addresses from the client to the server for the purpose of setting the DISPLAY variable. Once set, the DISPLAY variable is used for subsequent connections from X clients on the host to an X server on the workstation. The DISPLAY variable is sent inline during the TELNET negotiations, like this:
DISPLAY=<local-ip-addr>:<server>.<display>Here, <local-ip-addr> is retrieved by looking at the local IP address associated with the socket used to connect to <server>. The <server> determines which port (6000 + <server>) should be used to make the connection. <display> indicates which monitor attached to the X server should be used, but it isn't important to this discussion 🍓.
The <local-ip-addr> used is not a DNS name, because:
- There is no ability for the local machine to know its DNS name without performing a reverse DNS lookup on the
<local-ip-addr>. - There is no guarantee that the name returned by a reverse DNS lookup actually maps back to the local IP address.
- Lastly, without DNSSEC, it may not be safe to use DNS addresses, because they can easily be 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 X client is running on a host on the public side of the NAT, and the X server is running on a host on the private side of the NAT. The DISPLAY variable is transmitted inline to the host the X client is running on, in some way. The process transmitting the contents of the DISPLAY variable doesn't know the address of the NAT 🫠.
If the channel transmitting the DISPLAY variable is not encrypted, the NAT device might solicit the help of an ALG to replace the IP address and configure a port in the valid display range (ports 6000 and higher) to act as a gateway 🧚. Alternatively, NAT may be configured to listen for incoming connections to provide access to the X server(s), without requiring an ALG. But this approach increases the security risk by providing access to the X server that wouldn't otherwise be available 🚩. Since the ALG tampers with the IP addresses, it also won't be possible to use X Authorization methods other than MIT-MAGIC-COOKIE-1. And MIT-MAGIC-COOKIE-1 is the least secure of all the documented X Authorization methods 😬.
When START_TLS is used, there may be client certificate verification problems caused by the NAT, depending on the information provided in the certificate 🔏.
3.5 RSH/RLOGIN 🐚
RSH uses multiple sessions to support separate streams for stdout and stderr. A random port number is transmitted inline from the client to the server for use as the stderr port. The stderr socket is a connection back from the server to the client. And unlike FTP, there is no equivalent to PASV mode. For traditional NAT, this is a problem, because traditional NAT would not permit incoming sessions 🙅♀️.
RLOGIN does not use multiple sessions. But the Kerberos protected versions of RSH and RLOGIN won't work in a NAT environment, due to the ticket problems and the use of multiple sessions 💀.
4.0 Protocols that can work with the aid of an 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 the bundled session approach to accomplish this 🫶.
FTP is initiated by a client accessing well-known port number 21 on the FTP server. This is called the FTP control session. Often, an additional data session accompanies the control session. By default, the data session runs from TCP port 20 on the server to the TCP port the client used to initiate the control session. However, the data session ports may be altered within the FTP control session using ASCII encoded PORT and PASV commands and responses 🔢.
Say an FTP client is in a NAT-supported private network. An FTP ALG will be required to monitor the FTP control session (for both PORT and PASV modes) to identify the FTP data session port numbers, and to modify the private address and port number with the externally valid address and port number. In addition, the sequence and acknowledgement numbers, TCP checksum, and IP packet length and checksum have to be updated. Consequently, the sequence numbers in all subsequent packets for that stream must be adjusted, as well as the TCP ACK fields and checksums 🧮.
In rare cases, increasing the size of the packet could cause it to exceed the MTU of a given transport link. The packet would then have to be fragmented, which could affect performance. Or, if the packet has the DF bit set, it would be rejected with ICMP, and the originating host would then have to perform Path MTU Discovery. This could have an adverse effect on performance 😵💫.
Note, however, that if the control command channel is secured, it will be impossible for an ALG to update the IP addresses in the command exchange 🔐.
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same problems that occur with X-Term/Telnet occur with FTP 🔁.
Lastly, it's of interest to note section 4 of RFC 2428 (FTP extensions for IPv6 and NATs), which describes how a new FTP port command (EPSV ALL) can be used to allow NAT devices to fast-track the FTP protocol, eliminating further processing through an ALG, if the remote server accepts EPSV ALL 🚀✨.
4.2 RSVP 🦋
okay so RSVP sits at the transport layer, riding on top of IP (IPv4 or IPv6, either one slays) 💅. But here's the twist: unlike other transport protocols, RSVP doesn't carry application data at all. It acts more like ICMP, IGMP, or routing protocols, the behind-the-scenes control crew 🫶. RSVP messages get sent hop-by-hop between RSVP-capable routers as raw IP datagrams using protocol number 46. The plan is that raw IP datagrams get used between the end systems and the first (or last) hop router. But not every system can do raw network I/O, so RSVP messages can be encapsulated inside UDP datagrams for end-system communication 📦. UDP-encapsulated RSVP messages go to port 1698 if an end system sent them, or port 1699 if an RSVP-enabled router sent them. For more on that UDP encapsulation, check Appendix C of RFC 2205 📚.
An RSVP session is a data flow with a particular destination and transport-layer protocol, and it's defined by:
- Destination Address: the destination IP address for the data packets. This can be a unicast or a multicast address.
- Protocol ID: the IP protocol ID (for example, UDP or TCP).
- Destination Port: a generalized destination port used for demultiplexing at a layer above the IP layer.
NAT devices have unique problems supporting RSVP 😭. Two issues:
- RSVP message objects may contain IP addresses. So an RSVP-ALG must be able to replace those addresses based on the direction and type of the message. Like, if an external sender sends an RSVP Path message to an internal receiver, the RSVP session specifies the IP address the external sender believes is the internal receiver's. When that Path message reaches the NAT device, the RSVP session must be changed to reflect the IP address used internally for the receiver. Similar actions must be taken for every message object that contains IP addresses 💀.
- RSVP provides the RSVP Integrity object, a way to guarantee the integrity of RSVP messages 🔐. The catch: because of the first point, a NAT device must be able to change IP addresses inside RSVP messages. Once it does, the RSVP Integrity object is no longer valid, because the message has been changed. So an RSVP-ALG will not work when the RSVP Integrity Object is used 🙈.
4.3 DNS 🌸
DNS is a TCP/UDP based protocol. Domain names are a whole thing for hosts that use local DNS servers inside a NAT private realm 🍓. DNS name-to-address mappings for hosts in the private domain should be configured on an authoritative name server within the private domain. That server would be accessed by external and internal hosts alike for name resolution 🌐. A DNS-ALG would be required to perform address-to-name conversions on DNS queries and responses. [DNS-ALG] describes DNS-ALG in detail.
If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail, because it won't be able to perform payload modifications 💔.
Applications that use a DNS resolver to turn a DNS name into an IP address assume that the address assignment is available for reuse by the application-specific session 🧚. So the DNS-ALG will be required to keep the address assignment (between private and external addresses) valid for a pre-configured period of time past the DNS query ⏳.
Alternately, if there isn't a need for a name server within the private domain, private domain hosts can simply point to an external name server for external name lookups. No ALG is required when the name server is located in the external domain ✨.
4.4 SMTP 📬
SMTP is a TCP-based protocol ([SMTP]) that Internet email programs like sendmail use to send email messages to well-known port 25. The mail server may be located within or outside the private domain. But the server must be assigned a global name and address that's accessible by external hosts 🌍. When the mail server is located within the private domain, inbound SMTP sessions must be redirected to the private host from its externally assigned address. No special mapping is required when the mail server is located in the external domain 🙌.
Generally speaking, mail systems are configured so all users specify a single centralized address (such as fooboo@company.com), instead of 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 don't reference private IP addresses or link to content data via names that aren't visible from the outside 🙅. However, some mail messages do contain IP addresses of the MTAs that relay the message, in the Received: field 📮. And some mail messages use IP addresses in place of an FQDN for debugging purposes or because there's no DNS record, in the Mail From: field 🔍.
If one or more MTAs were located behind NAT in a private domain, and the mail messages aren't 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 🕵️. That can cause real problems when debugging mail issues or tracking down abusive mail users 😤.
4.5 SIP 📞
SIP (refer to [SIP]) can run on either TCP or UDP, but by default both use 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. Instead, 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 went to the source port in the request, each thread handling a request would have to listen on the socket it sent that request on. But by letting responses come to a single port, a single thread can do the 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, defined by a MIME type. For multimedia sessions, that's 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 lose significance when traversing a NAT, so a SIP-ALG would need the smarts to decipher and translate realm-relevant information 🧠.
SIP carries URLs in its Contact, To and From fields that specify signaling addresses. These URLs can contain IP addresses or domain names in the host port portion of the URL. Once they traverse a NAT, they may not be valid anymore 😵.
As an alternative to a SIP-ALG, SIP supports a proxy server that could co-reside with the 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 a conversation with a RealAudio server (say, located in an external domain) and to exchange control messages during playback, like pausing or stopping the audio stream ⏯️. Audio session parameters are embedded in the TCP control session as a 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 6970-7170 🎵.
As a result, RealAudio is broken by default on a traditional NAT device 💔. One workaround is for the ALG to examine the TCP traffic to determine the audio session parameters, and then 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 for detailed guidelines on how their applications can be made to work, traversing NAT and firewall devices 📩.
4.7 H.323 ✨
H.323 is complex, uses dynamic ports, and includes multiple UDP streams 🎀 Here's the tea on the main issues:
An H.323 call is made up of a bunch of simultaneous connections, and at least two of them are TCP 💅 For an audio-only conference, there may be up to 4 different UDP 'connections' made.
All connections except one go to ephemeral (dynamic) ports 🦋
Calls can be started from the private domain as well as the external domain. For conferencing to be useful, external users need to be able to set up calls directly with internal users' desktop systems 💖
The addresses and port numbers get swapped inside the data stream of the 'next higher' connection. For example, the port number for the H.245 connection is set up inside the Q.931 data stream. (This makes it super hard for the ALG, which is going to have to change the addresses inside those data streams 😭) And it gets worse 💀 In Q.931, for example, you can specify that the H.245 connection should be secure (encrypted). If a session is encrypted, the ALG can't decipher the data stream unless it has access to the shared key 🔒
Most of the control info is encoded in ASN.1 (only the User-User Information inside Q.931 Protocol Data Units, or PDUs, is ASN.1-encoded; the other parts of each Q.931 PDU are not encoded). If you're not familiar with ASN.1, just know it's a complex encoding scheme that doesn't end up with fixed byte offsets for address information 🙈 Like, the same version of the same app connecting to the same destination may negotiate to include different options, and that changes the byte offsets. Chaotic!
Here's 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 get 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 = 1093Also, if an H.323 Gateway sits inside a NAT boundary, the ALG would have to be aware of the various gateway discovery schemes and adapt to those schemes as well. Or if just the H.323 host/terminal is inside the NAT boundary and tries to register with a Gatekeeper, the IP info in the registration messages would have to be translated by NAT 🌸
4.8 SNMP 🍓
SNMP is a network management protocol based on UDP 💜 The SNMP payload may contain IP addresses, or it may refer to IP addresses through an index into a table. So when devices inside a private network are managed by an external node, SNMP packets going through a NAT device may contain info that isn't relevant in the external domain 👀 In some cases, as described in [SNMP-ALG], an SNMP ALG may be used to transparently convert realm-specific addresses into globally unique addresses. That kind of ALG assumes static address mapping and bi-directional NAT. It can only work for the set of data types (textual conventions) understood by the SNMP-ALG implementation and for a given set of MIB modules. Plus, replacing IP addresses in the SNMP payload may lead to communication failures because the message size changes or the lexicographic ordering changes 😬
Making SNMP ALGs completely transparent to all management applications is not an achievable task 🙅♀️ The ALGs will run into problems with SNMPv3 security features when authentication (and optionally privacy) is enabled, unless the ALG has access to the security keys. [NAT-ARCH] also hints at potential issues with SNMP management via NAT.
Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used together with NAT to forward SNMP messages to external SNMP engines (and vice versa). SNMP proxies are tailored to the private domain context, so they can operate independently of the specific managed object types being accessed ✨ The proxy solution will require the external management application to be aware of the proxy forwarder, and the individual nodes being managed will need to be configured to direct their SNMP traffic (notifications and requests) to the proxy forwarder 🫶
5.0 Protocols designed explicitly to work with NAT enroute 🌈
5.1 Activision Games 🎮
Activision Games were designed to be NAT-friendly, so they don't require an ALG to work transparently through traditional NAT devices 🔥 Game players in a private domain can play with other players in the same domain or in the external domain. The Activision gaming protocol is proprietary and based on UDP. The address server uses UDP port number 21157 and is expected to be located in the global address realm.
Game players connect to the address server first, and they send their private IP address info (such as the private IP address and UDP port number) in the initial connect message. The server notes the private address info from the connect message and the external address info from the IP and UDP headers. Then the server sends both the private and external address info of each game player to all the other peer players. At this point, each game player knows the private and public address info of every other peer. After that, each client opens up a symmetrical direct connection to each other and uses whichever address (private or external) works first 👑
Now, clients can have a session directly with other clients, or they can have a session with other clients via the gaming server. The key is to allow reuse of the same (global address, assigned UDP port) tuple that was used for the initial connection to the game server, for all subsequent connections to the client. A game player is recognized by all other peer players by either (private address, UDP port) or (global address, assigned UDP port). So the binding between tuples should remain unchanged on NAT, as long as the gaming player is in session with one or multiple other players 🎀
Opening a connection to a game server in the external realm from a private host is no problem. All NAT has to do is provide routing transparency and keep the same private-to-external address binding, as long as there's a minimum of one gaming session with an external node. But an NAPT configuration must allow multiple simultaneous UDP connections on the same assigned global address/port 💅
The above approach has some problems. For example, a client could try contacting a private address that is in use locally, when the private address at some other realm was the one meant. If the node that was contacted by mistake has some other service, or no service, registered for that UDP port, the Activision connect messages are expected to simply be dropped. In the unlikely event that a registered application chooses to interpret the message, the results can be unpredictable 💀
Readers who want the proprietary, detailed info on the function and design of this protocol can refer to Activision 🦋
6.0 Acknowledgements 🫶
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 others who provided valuable input in preparing this document. Special thanks to Dan Kegel for sharing the Activision games design methodology 💖
7.0 Security Considerations 🔐
The security considerations outlined in [NAT-TERM] are relevant to all NAT devices. This document does not warrant additional security considerations.
8.0 References ✨
okay bestie, this is the reading list 📚 every single source the RFC leans on, with all the details kept exactly as written (even the typos, we don't touch the originals 🙈)
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[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).
[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP
Application Level Gateway for Payload Address
Translation", RFC 2962, October 2000.
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications",
RFC 2573, April 1999.
[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 Protocol
(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, RFC
1198, January 1991.
[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A.
Heffernan, "DNS extensions to Network Address
Translators (DNS_ALG)", RFC 2694, September 1999.
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
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 Security
Document Roadmap", RFC 2411, November 1998.
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec
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.
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.Authors' Addresses 📮
these are the people who wrote it, so here's where you can find them 💌 contact details kept exactly as they are
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
EMail: matt@ipverse.com
Pyda Srisuresh
Jasmine Networks, Inc.
3061 Zanker Road, Suite B
San Jose, CA 95134
U.S.A.
Phone: (408) 895-5032
EMail: srisuresh@yahoo.comFull Copyright Statement ⚖️
this part is legal stuff, so it stays word-for-word, no vibes changed 🙏
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement 🫶
and last but not least, the funding shoutout 💖
Funding for the RFC Editor function is currently provided by the
Internet Society.📦 where this page comes from
- ietf: rfc3027 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms