Chair of Network Architectures and Services Department of Informatics Technical University of Munich
Internet Lab (iLab1) NAT / DHCP Dominik Scholz ilab1@net.in.tum.de - - PowerPoint PPT Presentation
Internet Lab (iLab1) NAT / DHCP Dominik Scholz ilab1@net.in.tum.de - - PowerPoint PPT Presentation
Chair of Network Architectures and Services Department of Informatics Technical University of Munich Internet Lab (iLab1) NAT / DHCP Dominik Scholz ilab1@net.in.tum.de Chair of Network Architectures and Services Department of Informatics
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
1/40
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
2/40
Bonus Credits
You are encouraged to improve the quality of the exercises
- feedback
- improvements (errors, typos)
- suggestions (questions, topics)
Use ticket system and feedback form!
3/40
Attestations
No lecture during week of attestations
- No lecture: 2018-12-12
- TLS and packet filtering lab will be 2 weeks
- Lecture on this topic next week
4/40
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
5/40
Motivation: IPv4 Address Scarcity
6/40
Yearly Address Allocations
source: P . Richter et al., A Primer on IPv4 Scarcity, ACM Computer Communication Review (2015)
7/40
Allocated Address Blocks
source: P . Richter et al., A Primer on IPv4 Scarcity, ACM Computer Communication Review (2015)
8/40
IPv4 Address Allocation in 2012
source: A. Dainotti et al., Estimating Internet address space usage through passive measurements, ACM Computer Communication Review (2014)
9/40
IPv4 Address Scarcity: Mitigation Strategies
- a) more efficient use of the address space
→ e.g. use unrouted addresses, address trading
10/40
IPv4 Address Scarcity: Mitigation Strategies
- a) more efficient use of the address space
→ e.g. use unrouted addresses, address trading
- b) create more addresses
→ IPv6
10/40
IPv4 Address Scarcity: Mitigation Strategies
- a) more efficient use of the address space
→ e.g. use unrouted addresses, address trading
- b) create more addresses
→ IPv6
- c) address sharing
→ NAT (and DHCP)
10/40
a) IPv4 Address Market
Address trading / company mergers
- in 2011 Microsoft bought 667K IPv4 addresses for 7.5M USD (11.25 USD per IPv4 address)
source: http://www.theregister.co.uk/2011/03/24/microsoft_ip_spend
- in 2017 MIT started selling half of its 16 million IPv4 addresses
source: https://www.networkworld.com/article/3191503/internet/mit-selling-8-million-coveted-ipv4-addresses-amazon-a-buyer.html
- IPv4 address trading increases, 15-18 USD per IPv4 address
source: http://www.circleid.com/posts/20180307_the_ipv4_market_2017_and_beyond/
Address pricing
- opaque, transactions not public
- further reading: Lee Howard, Internet Access Pricing in a Post-IPv4 Runout World, http://www.asgard.org/images/pricing_v1.3.docx
11/40
b) IPv6 Deployment
IPv6 support required from end-to-end:
- server-side: Content Providers
- network path: ISP Networks and Transit Providers
- client-side: Content Consumers
https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic further reading: https://cdn.prod.internetsociety.org/wp-content/uploads/2017/08/IPv6_report_2017-0606.pdf
12/40
b) IPv6 Deployment: Content Providers
- 28% of Top 1000 websites reachable over IPv6
source: http://www.worldipv6launch.org/measurements/
- 15% of Top 1M websites reachable over IPv6
source: https://bgp.he.net/ipv6-progress-report.cgi
- 98% of the 4M sites on Cloudflare use IPv6
source: https://blog.cloudflare.com/98-percent-ipv6/
- DNS: 98.4% of TLDs operate IPv6 nameservers
source: https://bgp.he.net/ipv6-progress-report.cgi https://www.akamai.com/uk/en/about/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp
13/40
b) IPv6 Deployment: ISP and Transit Networks
- 24% of all ASes announce IPv6 prefixes
source: http://v6asns.ripe.net/v/6 source: http://v6asns.ripe.net/v/6
14/40
b) IPv6 Deployment: Content Consumers
- 24% of Google visitors connect over IPv6
source: https://www.google.com/intl/en/ipv6/statistics.html http://www.circleid.com/posts/20180521_what_drives_ipv6_deployment/
15/40
c) Address Sharing: Private IPv4 Address Ranges
Properties
- anyone can use these IP address ranges in their own network
- addresses are not routed in the public Internet
- Internet access through address translation → NAT
Address Ranges
- RFC 1918 reserves the following IPv4 address ranges
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
- RFC 6598 reserves an additional range for ISP networks
- 100.64.0.0/10
- RFC 4193 specifies Unique Local IPv6 addresses
- fc00::/7
16/40
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
17/40
Concept: Providing Internet Access for Private IPs
Internet Private Host e.g. 192.168.1.42
- outgoing packet: replace packet source with public endpoint
18/40
Concept: Providing Internet Access for Private IPs
Internet Private Host e.g. 192.168.1.42
- outgoing packet: replace packet source with public endpoint
Internet Private Host e.g. 192.168.1.42
- incoming packet: replace packet destination with local host
18/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 Packet
src: 192.168.1.43:3345 dst: 131.159.15.49:80 19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 Packet
src: dst: 131.159.15.49:80
- replace src IP (and port) in outgoing packets
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 Packet
src: 1.2.3.4 dst: 131.159.15.49:80
- replace src IP (and port) in outgoing packets
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 Packet
src: 1.2.3.4:4444 dst: 131.159.15.49:80
- replace src IP (and port) in outgoing packets
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 NAT translation table L4 global endpoint local endpoint
TCP 1.2.3.4:4444 192.168.1.43:3345
Packet
src: 1.2.3.4:4444 dst: 131.159.15.49:80
- replace src IP (and port) in outgoing packets
- remember mapping of private and public endpoint
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 NAT translation table L4 global endpoint local endpoint
TCP 1.2.3.4:4444 192.168.1.43:3345
Packet
src: 131.159.15.49:80 dst: 1.2.3.4:4444
- replace src IP (and port) in outgoing packets
- remember mapping of private and public endpoint
- lookup mapping of private and public endpoint
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 NAT translation table L4 global endpoint local endpoint
TCP 1.2.3.4:4444 192.168.1.43:3345
Packet
src: 131.159.15.49:80 dst:
Packet
src: 131.159.15.49:80 dst: 192.168.1.43:3345
- replace src IP (and port) in outgoing packets
- remember mapping of private and public endpoint
- lookup mapping of private and public endpoint
- replace dst IP (and port) in incoming packets
19/40
Network Address (and Port) Translation (NAT)
Server 131.159.15.49 Internet NAT pub: 1.2.3.4 priv: 192.168.1.1 Private Host 192.168.1.42 Private Host 192.168.1.43 NAT translation table L4 global endpoint local endpoint
TCP 1.2.3.4:4444 192.168.1.43:3345
- replace src IP (and port) in outgoing packets
- remember mapping of private and public endpoint
- lookup mapping of private and public endpoint
- replace dst IP (and port) in incoming packets
19/40
NAT in Practice
Deployment
- today the majority of end users are located behind NAT
(+ other middleboxes)
- no standardization of NAT
→ many different implementations
- transparent to the public Internet
20/40
NAT in Practice (contd.)
Benefits
- effectively saves IP addresses: allows ∼65,000 simultaneous flows with a single public IP address
- address independence: public/private IP addresses can be changed independently
- topology hiding: devices inside local network are not explicitly addressable/visible from outside
Problems
- connections can only be established from the local network
- ports should not be used to address hosts
- routers should not manipulate packets above layer 2 (end-to-end principle)
21/40
Recap: Textbook Internet Architecture
browser TCP IP HTTP server TCP IP Ethernet driver Ethernet driver IP Ethernet driver Ethernet driver
HTTP protocol TCP protocol IP protocol IP protocol Ethernet protocol Ethernet protocol
Ethernet Ethernet router
22/40
Real-World Internet Architecture: Middleboxes
browser TCP IP HTTP server TCP IP Ethernet driver Ethernet driver HTTP TCP IP Ethernet driver Ethernet driver
HTTP protocol HTTP protocol TCP protocol TCP protocol IP protocol IP protocol Ethernet protocol Ethernet protocol
Ethernet Ethernet middlebox
23/40
Protocols Affected by NAT
characteristics of protocols that are affected by NAT (RFC 3027):
- server located in the local network
- any service behind NAT, peer-to-peer applications
- realm-specific IP address information in payload
- e.g. SIP
, FTP
- bundled session applications
- protocols using multiple connections, e.g. active FTP
- unsupported protocols
- e.g. SCTP
, IPsec 24/40
Example: Session Initiation Protocol (SIP)
INVITE message: establish a session (e.g. VoIP call) between peers INVITE sip:Callee@200.3.4.5 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5:5060 src: < sip:Caller@192.168.1.5 > dst: <sip:Callee@200.3.4.5> CSeq: 1 INVITE Contact: <sip:Caller@192.168.1.5:5060> Content−Type: application/sdp v=0
- =Alice 214365879 214365879 IN IP4 192.168.1.5
c=IN IP4 192.168.1.5 t= 0 0 m=audio 5200 RTP/AVP 0 9 7 3 a=rtpmap:8 PCMU/8000 a=rtpmap:3 GSM/8000
25/40
Example: File Transfer Protocol (FTP)
FTP Server FTP Client control connection FTP uses
- a persistent control connection
26/40
Example: File Transfer Protocol (FTP)
FTP Server FTP Client control connection data connection FTP uses
- a persistent control connection
- an on-demand data connection
e.g. PORT command for 10.0.0.1:1025 PORT 10, 0, 0, 1, 4, 1
26/40
Problem mitigation
- port forwarding
- static entry in the NAT state table (manually or via protocol)
- requires support in the NAT and end hosts
27/40
Problem mitigation
- port forwarding
- static entry in the NAT state table (manually or via protocol)
- requires support in the NAT and end hosts
- application layer gateway (ALG)
- NAT analyzes and rewrites application layer protocols, e.g. FTP
- requires support for every protocol in the NAT device
27/40
Problem mitigation
- port forwarding
- static entry in the NAT state table (manually or via protocol)
- requires support in the NAT and end hosts
- application layer gateway (ALG)
- NAT analyzes and rewrites application layer protocols, e.g. FTP
- requires support for every protocol in the NAT device
- hole punching
- end hosts try to establish a direct connection to each other
- requires support in the end hosts, dependent on NAT implementation, UDP works better than TCP
27/40
Problem mitigation
- port forwarding
- static entry in the NAT state table (manually or via protocol)
- requires support in the NAT and end hosts
- application layer gateway (ALG)
- NAT analyzes and rewrites application layer protocols, e.g. FTP
- requires support for every protocol in the NAT device
- hole punching
- end hosts try to establish a direct connection to each other
- requires support in the end hosts, dependent on NAT implementation, UDP works better than TCP
- relay server
- public relay server forwards data
- affects bandwith and latency
27/40
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
28/40
IPv4 and IPv6 Coexistence
Transition Phase
- IPv4 and IPv6 coexist during the transition phase
- ISPs need to provide access to IPv4-only services
- ISPs with a growing customer base face a tradeoff
buying IPv4 addresses vs. Large Scale NAT (LSN)
Extend the lifetime of IPv4
- Carrier Grade NAT (NAT444)
Transition to IPv6
- Native IPv6, tunneled/translated IPv4:
e.g. Dual-Stack Lite, 464XLAT
- many more (usually require CGN)
see: N. Škoberne et al., IPv4 address sharing mechanism classification and tradeoff analysis, IEEE/ACM Transactions on Networking (2014)
29/40
Carrier Grade NAT (NAT444)
Cellular Networks Fixed-line Networks
- widespread deployment in mobile networks
- growing deployment (esp. new customers) in fixed-line networks
- further reading: P
. Richter et al., A Multi-perspective Analysis of Carrier-Grade NAT Deployment, IMC’16, https://people.csail.mit.edu/richterp/imc176-richterA.pdf
30/40
IPv6 Transition Techniques: Dual-Stack Lite
E.g. Comcast (US), Unitymedia (DE), Kabel Deutschland (DE)
http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in-launch-of-ipv6-broadband-network
31/40
IPv6 Transition Techniques: 464XLAT
E.g. T-Mobile US
http://www.internetsociety.org/deploy360/resources/case-study-t-mobile-us-goes-ipv6-only-using-464xlat
32/40
IPv6 Transition Techniques: 464XLAT
Customer-side translation (CLAT)
- private IPv4 is translated into IPv6 using Stateless IP/ICMP Translation (SIIT)
- stateless translation between reserved IPv6 address range (::ffff:0:0:0/96) and IPv4 addresses
32/40
IPv6 Transition Techniques: 464XLAT
Provider-side translation (PLAT)
- translate IPv4-translated addresses to IPv4 using NAT64 and DNS64
32/40
Conclusion
NAT deployment
- widespread NAT deployment is one reason for the slow adoption of IPv6
source: L. Zhang, A Retrospective View of Network Address Translation, IEEE Network Sep/Oct 2008
- NAT will be around until nobody uses IPv4 any more
Carrier Grade NAT
- limited control over the NAT function (e.g. no port forwarding)
- multiple customers share the same public IP address
→ hampers criminal prosecution based on IP address
- customers can interfere with each other
→ number of concurrent connections
- logging each mapping is expensive
→ bulk port allocation
33/40
Test your own Connection
- Netalyzr
- Android application or web-based test (Java applet)
- JavaScript version in development
- more than 100 tests including NAT behavior
- http://netalyzr.icsi.berkeley.edu
34/40
Outline
Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP
35/40
Dynamic Host Configuration Protocol (DHCP)
Motivation
- manual network configuration of hosts not scalable
General Concepts
- automated configuration of network parameters
e.g. IP addresses, subnets, gateway, DNS server, etc.
- UDP-based client-server protocol
- servers lease IP addresses to clients for a certain amount of time
- stateful server, can make decisions based on client history
- extensible through DHCP options
36/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
37/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
discover
- discover message: client announces its presence in the network (L2 broadcast)
37/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
discover
- ffer
- discover message: client announces its presence in the network (L2 broadcast)
- offer message: server(s) make a lease offer to the client.
37/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
discover
- ffer
request
- discover message: client announces its presence in the network (L2 broadcast)
- offer message: server(s) make a lease offer to the client.
- request message: client accepts an offer and requests the offered configuration (L2 broadcast)
- implicitly denies offers of other servers
- is also used to extend the lease of a currently used configuration
37/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
discover
- ffer
request acknowledge
- discover message: client announces its presence in the network (L2 broadcast)
- offer message: server(s) make a lease offer to the client.
- request message: client accepts an offer and requests the offered configuration (L2 broadcast)
- implicitly denies offers of other servers
- is also used to extend the lease of a currently used configuration
- acknowledge message: server leases a configuration to the client
37/40
DHCPv4 Protocol
- UDP protocol on top of IPv4 (server port 67, client port 68)
- uses IPv4 broadcast packets
Client DHCP Server
discover
- ffer
request acknowledge
- discover message: client announces its presence in the network (L2 broadcast)
- offer message: server(s) make a lease offer to the client.
- request message: client accepts an offer and requests the offered configuration (L2 broadcast)
- implicitly denies offers of other servers
- is also used to extend the lease of a currently used configuration
- acknowledge message: server leases a configuration to the client
37/40
DHCPv6 Protocol
- UDP protocol on top of IPv6 (server port 547, client port 546)
- protocol sequence similar to DHCPv4
Client DHCP Server
solicit advertise request reply
- uses IPv6 multicast packets
- uses DHCP Unique Identifiers (DUIDs) to identify the client instead of MAC addresses
38/40
DHCPv6 vs. SLAAC
- DHCPv6 can complement SLAAC or completely replace it
- DHCPv6 provides more configuration parameters than SLAAC (and can easily be extended)
e.g. DNS server configuration: router advertisements require RDNSS extension (RFC6106), not supported by all clients
- DHCPv6 allows fine-grained control over the allocated addresses and centralized address logging
39/40
DHCPv6 Prefix Delegation
2001:0DB8::/64 2001:0DB8: 0000:0001::/64 delegating router requesting router 2001:DB8::/48
- extension enables the DHCPv6 server to assign prefixes
- recommendation: ISPs should assign a /48 subnet to each customer, /64 in mobile networks (RFC 3177)
- requesting router at the customer acts as DHCP client and requests to be assigned prefix(es)
- delegating router at the ISP acts as a DHCP server and assigns prefix(es) to the requesting router