Internet Lab (iLab1) NAT / DHCP Dominik Scholz ilab1@net.in.tum.de - - PowerPoint PPT Presentation

internet lab ilab1 nat dhcp
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 1

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 Technical University of Munich

Lab 6 – WiSe 2018

slide-2
SLIDE 2

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

1/40

slide-3
SLIDE 3

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

2/40

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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

slide-6
SLIDE 6

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

5/40

slide-7
SLIDE 7

Motivation: IPv4 Address Scarcity

6/40

slide-8
SLIDE 8

Yearly Address Allocations

source: P . Richter et al., A Primer on IPv4 Scarcity, ACM Computer Communication Review (2015)

7/40

slide-9
SLIDE 9

Allocated Address Blocks

source: P . Richter et al., A Primer on IPv4 Scarcity, ACM Computer Communication Review (2015)

8/40

slide-10
SLIDE 10

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

slide-11
SLIDE 11

IPv4 Address Scarcity: Mitigation Strategies

  • a) more efficient use of the address space

→ e.g. use unrouted addresses, address trading

10/40

slide-12
SLIDE 12

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

slide-13
SLIDE 13

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

slide-14
SLIDE 14

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

slide-15
SLIDE 15

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

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

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

slide-20
SLIDE 20

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

17/40

slide-21
SLIDE 21

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

slide-22
SLIDE 22

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

slide-23
SLIDE 23

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

slide-24
SLIDE 24

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

slide-25
SLIDE 25

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

slide-26
SLIDE 26

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

slide-27
SLIDE 27

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

slide-28
SLIDE 28

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

slide-29
SLIDE 29

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

slide-30
SLIDE 30

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

slide-31
SLIDE 31

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

slide-32
SLIDE 32

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

slide-33
SLIDE 33

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

slide-34
SLIDE 34

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

slide-35
SLIDE 35

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

slide-36
SLIDE 36

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

slide-37
SLIDE 37

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

slide-38
SLIDE 38

Example: File Transfer Protocol (FTP)

FTP Server FTP Client control connection FTP uses

  • a persistent control connection

26/40

slide-39
SLIDE 39

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

slide-40
SLIDE 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

slide-41
SLIDE 41

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

slide-42
SLIDE 42

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

slide-43
SLIDE 43

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

slide-44
SLIDE 44

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

28/40

slide-45
SLIDE 45

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

slide-46
SLIDE 46

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

slide-47
SLIDE 47

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

slide-48
SLIDE 48

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

slide-49
SLIDE 49

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

slide-50
SLIDE 50

IPv6 Transition Techniques: 464XLAT

Provider-side translation (PLAT)

  • translate IPv4-translated addresses to IPv4 using NAT64 and DNS64

32/40

slide-51
SLIDE 51

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

slide-52
SLIDE 52

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

slide-53
SLIDE 53

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

35/40

slide-54
SLIDE 54

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

slide-55
SLIDE 55

DHCPv4 Protocol

  • UDP protocol on top of IPv4 (server port 67, client port 68)
  • uses IPv4 broadcast packets

Client DHCP Server

37/40

slide-56
SLIDE 56

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

slide-57
SLIDE 57

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

slide-58
SLIDE 58

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

slide-59
SLIDE 59

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

slide-60
SLIDE 60

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

slide-61
SLIDE 61

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

slide-62
SLIDE 62

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

slide-63
SLIDE 63

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

40/40