Supplementary Material CS 3214 Computer Systems Supplementary Material Godmar Back

Network Address Translation CS 3214

NETWORK ADDRESS TRANSLATION 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.62 gogo.rlogin 192.168.5.1 /hn1.rlogin 192.168.5.63 umaro.rlogin 128.173.41.81 hn1.cs.vt.edu 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 sends datagram to 128.119.40.186, 80 2: NAT router changes datagram source addr from 192.168.5.62, 3345 to 128.173.41.81, 5001, updates table 128.173.41.81, 5001 192.168.5.62, 3345 …… …… S: 192.168.5.62, 3345 D: 128.119.40.186, 80 1 S: 128.119.40.186, 80 D: 192.168.5.62, 3345 4 192.168.5.62 S: 128.173.41.81, 5001 D: 128.119.40.186, 80 2 192.168.5.1 128.173.41.81 192.168.5.63 S: 128.119.40.186, 80 D: 128.173.41.81, 5001 3 4: NAT router 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 192.168.5.64 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: NAT is controversial: 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