iLab NAT / DHCP Florian Wohlfart Minoo Rouhi lastname @in.tum.de - - PowerPoint PPT Presentation

▶
ilab
SMART_READER_LITE
LIVE PREVIEW

iLab NAT / DHCP Florian Wohlfart Minoo Rouhi lastname @in.tum.de - - PowerPoint PPT Presentation

May 21, 2023 350 likes •957 views

iLab NAT / DHCP Florian Wohlfart Minoo Rouhi lastname @in.tum.de Chair of Network Architectures and Services Department of Informatics Technical University of Munich Lab 6 17ws 1 / 39 Outline Meta IPv4 Address Scarcity NAT IPv6

slide-1
SLIDE 1

iLab

NAT / DHCP Florian Wohlfart Minoo Rouhi lastname@in.tum.de

Chair of Network Architectures and Services Department of Informatics Technical University of Munich

Lab 6 – 17ws

1 / 39

slide-2
SLIDE 2

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

2 / 39

slide-3
SLIDE 3

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

3 / 39

slide-4
SLIDE 4

Oral Attestations

◮ Make sure you confirmed your time slot! ◮ We assume you show up for your designated slot ◮ Attestation is required for passing the course 4 / 39

slide-5
SLIDE 5

Bonus Credits

Not only TCP BBR optional lab

You are encouraged to improve the quality of the exercises

◮ feedback ◮ improvements (errors, typos) ◮ suggestions (questions, topics)

Use ticket system and feedback form!

5 / 39

slide-6
SLIDE 6

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

6 / 39

slide-7
SLIDE 7

Motivation: IPv4 Address Scarcity

source: http://www.heise.de/newsticker/meldung/RIPE-72-Streit-um-letzte-IPv4-Adressen-3221309.html

7 / 39

slide-8
SLIDE 8

Yearly Address Allocations

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

8 / 39

slide-9
SLIDE 9

Allocated Address Blocks

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

9 / 39

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)

10 / 39

slide-11
SLIDE 11

IPv4 Address Scarcity: Mitigation Strategies

◮ a) more efficient use of the address space

→ e.g. use unrouted addresses, address trading

11 / 39

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

11 / 39

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

11 / 39

slide-14
SLIDE 14

a) IPv4 Address Market

Address trading / company mergers

◮ in 2011 Microsoft bought 667K IPv4 addresses for 7.5M, that

makes USD 11.25 per address

source: http://www.theregister.co.uk/2011/03/24/microsoft_ip_spend

◮ in 2011 the bankrupt bookseller Borders offered 65K IPv4

addresses for USD 12 per address

source: http://www.theregister.co.uk/2011/12/05/borders_flogs_ipv4_addys

◮ IPv4 Address Trading Portals

e.g. http://addrex.net, http://www.iptrading.com, http://ipv4marketgroup.com

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

12 / 39

slide-15
SLIDE 15

b) IPv6 Deployment

◮ Server-side: 24% of Top 1000 websites reachable over IPv6

source: http://www.worldipv6launch.org/measurements/

◮ Client-side: 18% of Google visitors connect over IPv6

source: https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html https://www.akamai.com/uk/en/about/our- thinking/state-of-the-internet-report/state-of-the- internet-ipv6-adoption-visualization.jsp

13 / 39

slide-16
SLIDE 16

b) IPv6 Deployment (cont.)

source: https://blogs.akamai.com/2015/06/three-years-since-world-ipv6-launch-strong-ipv6-growth-continues.html

14 / 39

slide-17
SLIDE 17

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

15 / 39

slide-18
SLIDE 18

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

16 / 39

slide-19
SLIDE 19

Concept: Providing Internet Access for Private IPs

Internet Private Host e.g. 192.168.1.42

◮ outgoing packet: replace packet source with public endpoint 17 / 39

slide-20
SLIDE 20

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 17 / 39

slide-21
SLIDE 21

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

18 / 39

slide-22
SLIDE 22

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

18 / 39

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 Packet

src: dst: 131.159.15.49:80

◮ replace src IP (and port) in outgoing packets 18 / 39

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: 1.2.3.4 dst: 131.159.15.49:80

◮ replace src IP (and port) in outgoing packets 18 / 39

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: 1.2.3.4:4444 dst: 131.159.15.49:80

◮ replace src IP (and port) in outgoing packets 18 / 39

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 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 18 / 39

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 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 18 / 39

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: 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 18 / 39

slide-29
SLIDE 29

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 19 / 39

slide-30
SLIDE 30

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)

20 / 39

slide-31
SLIDE 31

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

21 / 39

slide-32
SLIDE 32

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

22 / 39

slide-33
SLIDE 33

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

23 / 39

slide-34
SLIDE 34

Example: Session Initiation Protocol (SIP)

INVITE message: establish a session (e.g. VoIP call) between peers INVITE s i p : Callee@200 . 3 . 4 . 5 SIP /2.0 Via : SIP /2.0/UDP 192.168.1.5:5060 s r c : < s i p : Caller@192.168.1.5 > dst : <s i p : Callee@200 .3.4.5 > CSeq : 1 INVITE Contact : <s i p : Caller@192 .168.1.5:5060 > Content−Type : a p p l i c a t i o n /sdp v=0

  • =A l i c e

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

24 / 39

slide-35
SLIDE 35

Example: File Transfer Protocol (FTP)

FTP Server FTP Client control connection FTP uses

◮ a persistent control connection 25 / 39

slide-36
SLIDE 36

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

25 / 39

slide-37
SLIDE 37

Problem mitigation

◮ port forwarding

◮ static entry in the NAT state table (manually or via protocol) ◮ requires support in the NAT and end hosts

26 / 39

slide-38
SLIDE 38

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

26 / 39

slide-39
SLIDE 39

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

26 / 39

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

◮ 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

26 / 39

slide-41
SLIDE 41

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

27 / 39

slide-42
SLIDE 42

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)

28 / 39

slide-43
SLIDE 43

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

29 / 39

slide-44
SLIDE 44

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 http://www.heise.de/netze/meldung/Kabel-Deutschland-stellt-Internetzugaenge-auf-IPv6-um-2069367.html

30 / 39

slide-45
SLIDE 45

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

31 / 39

slide-46
SLIDE 46

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

31 / 39

slide-47
SLIDE 47

IPv6 Transition Techniques: 464XLAT

Provider-side translation (PLAT)

◮ translate IPv4-translated addresses to IPv4 using NAT64 and

DNS64

31 / 39

slide-48
SLIDE 48

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 crimial prosecution based on IP address

◮ customers can interfere with each other

→ number of concurrent connections

◮ logging each mapping is expensive

→ bulk port allocation

32 / 39

slide-49
SLIDE 49

Test your own Connection

◮ Netalyzr

◮ Android application or web-based test (Java applet) ◮ JavaScript version in development ◮ more than 100 tests including NAT behavior ◮ netalyzr.icsi.berkeley.edu

33 / 39

slide-50
SLIDE 50

Outline

Meta IPv4 Address Scarcity NAT IPv6 Transition Techniques DHCP

34 / 39

slide-51
SLIDE 51

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 35 / 39

slide-52
SLIDE 52

DHCPv4 Protocol

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

Client DHCP Server

36 / 39

slide-53
SLIDE 53

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)

36 / 39

slide-54
SLIDE 54

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. 36 / 39

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

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

  • ffered configuration (L2 broadcast)

◮ implicitly denies offers of other servers ◮ is also used to extend the lease of a currently used configuration

36 / 39

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

  • 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

  • ffered 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

36 / 39

slide-57
SLIDE 57

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

37 / 39

slide-58
SLIDE 58

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

38 / 39

slide-59
SLIDE 59

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

39 / 39