Network Address Translation

CS 3214
Computer Systems
Lecture 24
Supplementary Material
Godmar Back
CS 3214 Fall 2010
Some of these slides are substantially derived from slides provided by
Jim Kurose & Keith Ross. Copyright on this material is held by Kurose
& Ross. Used with permission. The textbook is Computer Networking:
A Top Down Approach Featuring the Internet Jim Kurose, Keith Ross,
Addison-Wesley, July 2004
CS 3214 Fall 2010
NAT: Network Address Translation
rest of
local network
(e.g., home network)
192.168.5/24 /hn1.rlogin
All datagrams leaving local
network have same single source
NAT IP address:,
different source port numbers
Datagrams with source or
destination in this network
have 192.168.5.* address for
source, destination (as usual)
CS 3214 Fall 2010
NAT: Network Address Translation
• Motivation: local network uses just one IP
address as far as outside word is concerned:
– no need to be allocated range of addresses from ISP:
- just one IP address is used for all devices
– can change addresses of devices in local network
without notifying outside world
– can change ISP without changing addresses of
devices in local network
– devices inside local net not explicitly addressable,
visible by outside world (a huge security plus).
CS 3214 Fall 2010
NAT: Network Address Translation
Implementation: NAT router must:
– outgoing datagrams: replace (source IP address, port #)
of every outgoing datagram to (NAT IP address, new
port #)
. . . remote clients/servers will respond using (NAT IP
address, new port #) as destination addr.
– remember (in NAT translation table) every (source IP
address, port #) to (NAT IP address, new port #)
translation pair
– incoming datagrams: replace (NAT IP address, new port
#) in dest fields of every incoming datagram with
corresponding (source IP address, port #) stored in NAT
CS 3214 Fall 2010
NAT: Network Address Translation
NAT translation table
WAN side addr
LAN side addr
1: host
2: NAT router
sends datagram to
changes datagram, 5001, 3345, 80
source addr from
……, 3345 to, 5001,
S:, 3345
updates table
D:, 80
S:, 5001
D:, 80
S:, 80
D:, 5001
3: Reply arrives
dest. address:, 5001
S:, 80
D:, 3345
4: NAT router
changes datagram
dest addr from, 5001
to, 3345
CS 3214 Fall 2010
Managing NAT table
• NAT Gateway (usually) adds entries for datagrams
traveling private to public automatically
– Allows UDP/TCP clients to transparently
sendto/connect to outside servers
• Removal of entries
– UDP: timeout due to inactivity
– TCP: timeout + TCP connection teardown
• Other direction requires configuration so NAT
Gateway knows where to forward incoming
datagram even if no private host previously
punched a hole by initiating UDP traffic/TCP
CS 3214 Fall 2010
NAT Disadvantages
• 16-bit port-number field:
– Only 60,000 simultaneous connections with a single
LAN-side address!
• NAT is controversial:
– routers should only process up to layer 3
– violates end-to-end argument
• NAT possibility must be taken into account by app designers,
eg, P2P applications
– address shortage should instead be solved by IPv6
– really annoying if you time out on
CS 3214 Fall 2010
NAT Challenges
• Considering that most Internet hosts are behind NAT these
days – how should applications be written to deal with that?
• No problem as long as server has public IP and client knows
where to connect (HTTP, XMPP, SMTP, POP)
– If server has private IP, entries in NAT forwarding table can be
manually configured
• What about P2P applications?
– Could relay through server, but that would defeat purpose of P2P
– Instead, a technique called “hole punching” is widely used (e.g., in
– Discussed in [Ford/Srisuresh/Kegel 2005]
• UDP hole punching is widely used, but TCP hole punching is
possible as well
CS 3214 Fall 2010
NAT Relaying
• All traffic goes
through S
• Source:
[Ford/Srisuresh/Kegel 2005]
CS 3214 Fall 2010
UDP Hole Punching
• Rendezvous server only directs punches, traffic
goes P2P
• Details in [Ford/Srisuresh/Kegel 2005]
CS 3214 Fall 2010