Transcript Supplementary material on NAT/IPv4 (pptx)

CS 3214
Computer Systems
Supplementary Material
NETWORK ADDRESS
TRANSLATION
CS 3214
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
NETWORK ADDRESS
TRANSLATION
CS 3214
NAT: Network Address Translation
rest of
Internet
local network
(e.g., home network)
192.168.5/24
192.168.5.1 /hn1.rlogin
128.173.41.81
hn1.cs.vt.edu
192.168.5.62
gogo.rlogin
192.168.5.63
umaro.rlogin
192.168.5.64
kefka.rlogin
All datagrams leaving local
network have same single source
NAT IP address: 128.173.41.81,
different source port numbers
Datagrams with source or
destination in this network
have 192.168.5.* address for
source, destination (as usual)
CS 3214
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
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
table
CS 3214
NAT: Network Address Translation
NAT translation table
WAN side addr
LAN side addr
1: host 192.168.5.62
2: NAT router
sends datagram to
changes datagram
128.173.41.81, 5001 192.168.5.62, 3345
128.119.40.186, 80
source addr from
……
……
192.168.5.62, 3345 to
128.173.41.81, 5001,
S: 192.168.5.62, 3345
updates table
D: 128.119.40.186, 80
2
1
S: 128.173.41.81, 5001
D: 128.119.40.186, 80
192.168.5.1
128.173.41.81
S: 128.119.40.186, 80
D: 128.173.41.81, 5001
192.168.5.62
3
S: 128.119.40.186, 80
D: 192.168.5.62, 3345
4
192.168.5.63
4: NAT router
192.168.5.64
changes datagram
dest addr from 128.173.41.81, 5001
to 192.168.5.62, 3345
3: Reply arrives
dest. address:
128.173.41.81, 5001
CS 3214
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
connection
CS 3214
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 rlogin.cs.vt.edu
CS 3214
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
Skype)
– Discussed in [Ford/Srisuresh/Kegel 2005]
• UDP hole punching is widely used, but TCP hole punching is
possible as well
CS 3214
NAT Relaying
• All traffic goes
through S
• Source:
[Ford/Srisuresh/Kegel 2005]
CS 3214
UDP Hole Punching
• Rendezvous server only directs punches, traffic
goes P2P
• Details in [Ford/Srisuresh/Kegel 2005]
CS 3214