CSEE W4140Networking Laboratory

Lecture 9: NAT and DHCP

Jong Yul Kim04.05.2010

Today’s lecture

Network Address Translator (NAT)

Dynamic Host Configuration Protocol (DHCP)

Private Networks

H1

R1

H2

10.0.1.3

10.0.1.1

10.0.1.2

H3

R2

H4

10.0.1.310.0.1.2

Private network 1

Internet

H5

10.0.1.1Private network 1

213.168.112.3

128.195.4.119 128.143.71.21

Private IP addresses used are:10.0.0.0 – 10.255.255.255

172.16.0.0 – 172.31.255.255192.168.0.0 – 192.168.255.255

Not globally unique or routable

The first RFC on NAT is RFC 1631. A short-term solution to fix the IP address

depletion problem. The main idea is to reuse IP addresses “… very small percentage of hosts in a stub domain

are communicating outside of the domain at any given time.”

“… only a subset of the IP addresses inside a stub domain, need to be translated into IP addresses that are globally unique when outside communications is required.”

Network Address Translator

Network Address Translator Advantages

Can be installed incrementally without changes to either hosts or routers.

Disadvantages Takes away end-to-end connectivity of IP

addresses “(A few unusual applications may require

changes.)” RFC 1631 was published in May 1994

Basic Operation of NAT

•Host

•private address: 10.0.1.2•public address: 128.143.71.21

Public Host

Private Network Internet

64.236.24.4

NATDevice

PrivateAddress

PublicAddress

10.0.1.1 128.59.16.21

•Source = 10.0.1.2•Destination = 64.236.24.4

•Source = 10.0.1.2•Destination = 64.236.24.4•Source = 128.143.71.21•Destination = 64.236.24.4

•Source = 128.143.71.21•Destination = 64.236.24.4

•Source = 64.236.24.4•Destination = 128.59.16.21

•Source = 64.236.24.4•Destination = 10.0.0.2

•Source = 64.236.24.4•Destination = 128.59.16.21•Source = 64.236.24.4•Destination = 128.59.16.21•Source = 64.236.24.4•Destination = 128.59.16.21•Source = 64.236.24.4•Destination = 10.0.0.2

Pooling of IP addresses Scenario: Corporate network has many hosts but

only a small number of public IP addresses

NAT solution: Corporate network is managed with a private

address space NAT device, located at the boundary between the

corporate network and the public Internet, manages a pool of public IP addresses

When a host from the corporate network sends an IP datagram to a host in the public Internet, the NAT device picks a public IP address from the address pool, and binds this address to the private address of the host

Pooling of IP addresses

H1

private address: 10.0.1.2public address:

H5

Privatenetwork

Internet

Source = 10.0.1.2Destination = 213.168.112.3

Source = 128.143.71.21Destination = 213.168.112.3

public address: 213.168.112.3NATdevice

PrivateAddress

PublicAddress

10.0.1.2

Pool of addresses: 128.143.71.0-128.143.71.30

Supporting migration between network service providers

Scenario: In practice (using CIDR), the IP addresses in a corporate network are obtained from the service provider. Changing the service provider requires changing all IP addresses in the network.

NAT solution: Assign private addresses to the hosts of the corporate

network NAT device has address translation entries which bind

the private address of a host to the public address. Migration to a new network service provider merely

requires an update of the NAT device. The migration is not noticeable to the hosts on the network.

Supporting migration between network service providers

Host

private address: 10.0.1.2public address: 128.14.71.21

Source = 10.0.1.2Destination = 213.168.112.3

NAT device

Private Address

PublicAddress

10.0.1.2 128.14.71.21

128.14.71.21

Source = 128.14.71.21Destination = 213.168.112.3

Private network

ISP 1allocates address

block 128.14.71.0/24 to private network:

Supporting migration between network service providers

Host

private address: 10.0.1.2public address: 128.14.71.21

150.140.4.120

Source = 10.0.1.2Destination = 213.168.112.3

NAT device

Private Address

PublicAddress

10.0.1.2128.14.71.21150.140.4.120

128.14.71.21150.140.4.120

Source = 150.140.4.120Destination = 213.168.112.3

ISP 2allocates address block

150.140.4.0/24 to private network:

Private network

ISP 1allocates address

block 128.14.71.0/24 to private network:

IP masquerading Also called: Network address and port

translation (NAPT), port address translation (PAT).

Scenario: Single public IP address is mapped to multiple hosts in a private network.

NAT solution: Assign private addresses to the hosts of the

corporate network NAT device modifies the port numbers for

outgoing traffic

IP masquerading

H1

private address: 10.0.1.2

Private network

Source = 10.0.1.2Source port = 2001

Source = 128.143.71.21Source port = 2100

NATdevice

PrivateAddress

PublicAddress

10.0.1.2/2001 128.143.71.21/2100

10.0.1.3/3020 128.143.71.21/4444

H2

private address: 10.0.1.3

Source = 10.0.1.3Source port = 3020

Internet

Source = 128.143.71.21Destination = 4444

128.143.71.21

IP Masquerading(NAPT/PAT)

Problems of NAT

NAT and FTP

NAT and UDP applications

NAT and FTP

H1 H2

public address:128.143.72.21

FTP client FTP server

PORT 128.143.72.21/1027

200 PORT command successful

public address:128.195.4.120

RETR myfile

150 Opening data connection

establish data connection

Normal FTP operation

Data channelinitiated by server

NAT and FTP

H1

Private network

NAT device

H2

private address: 10.0.1.3public address: 128.143.72.21

Internet

FTP client FTP server

PORT 10.0.1.3/1027 PORT 128.143.72.21/1027

200 PORT command successful200 PORT command successful

RETR myfile RETR myfile

150 Opening data connection

FTP failing because of NAT

Data channelinitiated by server

NAT Behavioral Requirements for Unicast UDP (RFC 4787)

NATs do not handle UDP well

Categorizes NATs based on mapping and filtering behavior

NAT device stores the address and port translation tables (Mapping)

NAT devices selectively discard incoming traffic (Filtering)

Endpoint-independent Mapping

NATN1:n1Y1:y1N1:n1 Y1:y2N1:n1 Z1:z1N1:n1 Z1:z2

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

Endpoint-independent mapping

X1:x1 Y1:y1

X1:x1 Z1:z1X1:x1 Y1:y2

X1:x1 Z1:z2

Endpoint-independent Filtering

NAT

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

X1:x1 N1:n1 Y1:y1

Y1:y2 N1:n1

Z1:z1 N1:n1

Address-dependent Mapping

NAT

X1:x1 Y1:y1

X1:x1 Z1:z1

N1:n1 Y1:y1N1:n1 Y1:y2N1:n2 Z1:z1N1:n2 Z1:z2

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

Address-dependent mapping

X1:x1 Y1:y2

X1:x1 Z1:z2

Address-dependent Filtering

NAT

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

(1) X1:x1 N1:n1 Y1:y1

Y1:y2 N1:n1

Z1:z1 N1:n1

Address and port dependent Mapping

NAT

N1:n1 Y1:y1N1:n2 Y1:y2N1:n3 Z1:z1N1:n4 Z1:z2

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

Address and port dependent

X1:x1 Y1:y1

X1:x1 Z1:z1X1:x1 Y1:y2

X1:x1 Z1:z2

Address and port dependent Filtering

NAT

IPaddr: X1

IPaddr: Y1

IPaddr: Z1

(1) X1:x1 N1:n1 Y1:y1

Z1:z1 N1:n1

Y1:y1 N1:n1

Y1:y2 N1:n1

Concerns about NAT Performance

Modifying the IP header by changing the IP address requires that NAT boxes recalculate the IP header checksum.

Modifying port number requires that NAT boxes recalculate TCP checksum.

Fragmentation Care must be taken that a datagram that is

fragmented before it reaches the NAT device, is not assigned a different IP address or different port numbers for each of the fragments.

Concerns about NAT End-to-end connectivity

NAT destroys universal end-to-end reachability of hosts on the Internet.

A host in the public Internet often cannot initiate communication to a host in a private network.

The problem is worse, when two hosts that are in a private network need to communicate with each other.

NAT and applications NAT break applications such as file transfer, VoIP

DHCP

Dynamic Assignment of IP addresses

Dynamic assignment of IP addresses is desirable for several reasons: IP addresses are assigned on-demand Avoid manual IP configuration Support mobility of laptops

BOOTP BOOTstrap Protocol (BOOTP)

From 1985 Host can configure its IP parameters at boot time. 3 services.

IP address assignment. Detection of the IP address for a serving machine. The name of a file to be loaded and executed by the client

machine (boot file name)

Not only assign IP address, but also default router, network mask, etc.

Sent as UDP messages (UDP Port 67 (server) and 68 (host))

Use limited broadcast address (255.255.255.255): These addresses are never forwarded

DHCP Dynamic Host Configuration Protocol

(DHCP) From 1993 An extension of BOOTP, very similar to DHCP Same port numbers as BOOTP Extensions:

Supports temporary allocation (“leases”) of IP addresses

DHCP client can acquire all IP configuration parameters needed to operate

DHCP is the preferred mechanism for dynamic assignment of IP addresses

DHCP can interoperate with BOOTP clients.

BOOTP Interaction

BOOTP can be used for downloading memory image for diskless workstations

Assignment of IP addresses to hosts is static

Argon00:a0:24:71:e4:44 BOOTP Server

BOOTP Request00:a0:24:71:e4:44Sent to 255.255.255.255

Argon128.143.137.144

00:a0:24:71:e4:44 DHCP ServerBOOTP Response:IP address: 128.143.137.144Server IP address: 128.143.137.100Boot file name: filename

(a) (b)

Argon128.143.137.14400:a0:24:71:e4:44 DHCP Server

128.143.137.100

TFTP“filename”

(c)

DHCP Interaction (simplified)Argon

00:a0:24:71:e4:44 DHCP Server

DHCP Request00:a0:24:71:e4:44Sent to 255.255.255.255

Argon128.143.137.144

00:a0:24:71:e4:44 DHCP ServerDHCP Response:IP address: 128.143.137.144Default gateway: 128.143.137.1Netmask: 255.255.0.0

DHCP Pros It relieves the network administrator of a great deal of manual

configuration work.

The ability for a device to be moved from network to network and to automatically obtain valid configuration parameters for the current network can be of great benefit to mobile users.

Because IP addresses are only allocated when clients are actually active, it is possible, by the use of reasonably short lease times and the fact that mobile clients do not need to be allocated more than one address, to reduce the total number of addresses in use in an organization.

DHCP Cons

DNS cannot be used for DHCP configured hosts.

DHCP Message Type

Value Message Type

1 DHCPDISCOVER

2 DHCPOFFER

3 DHCPREQUEST

4 DHCPDECLINE

5 DHCPACK

6 DHCPNAK

7 DHCPRELEASE

8 DHCPINFORM

Message Types DHCPDISCOVER: Broadcast by a client to find available

DHCP servers. DHCPOFFER: Response from a server to a DHCPDISCOVER

and offering IP address and other parameters. DHCPREQUEST: Message from a client to servers that does

one of the following: Requests the parameters offered by one of the servers and

declines all other offers. Verifies a previously allocated address after a system or

network change (a reboot for example). Requests the extension of a lease on a particular address.

Contd. DHCPACK: Acknowledgement from server to client with

parameters, including IP address. DHCPNACK: Negative acknowledgement from server to client,

indicating that the client's lease has expired or that a requested IP address is incorrect.

DHCPDECLINE: Message from client to server indicating that the offered address is already in use.

DHCPRELEASE: Message from client to server canceling remainder of a lease and relinquishing network address.

DHCPINFORM: Message from a client that already has an IP address (manually configured for example), requesting further configuration parameters from the DHCP server.

Client Server Interactions The client broadcasts a DHCPDISCOVER message on its local

physical subnet. The DHCPDISCOVER message may include some options

such as network address suggestion or lease duration. Each server may respond with a DHCPOFFER message that

includes an available network address (your IP address) and other configuration options. The servers record the address as offered to the client to

prevent the same address being offered to other clients in the event of further DHCPDISCOVER messages being received before the first client has completed its configuration.

Contd. The client receives one or more DHCPOFFER

messages from one or more servers. The client chooses one based on the configuration

parameters offered and broadcasts a DHCPREQUEST message that includes the server identifier option to indicate which message it has selected and the requested IP address option, taken from your IP address in the selected offer.

In the event that no offers are received, if the client has knowledge of a previous network address, the client may reuse that address if its lease is still valid, until the lease expires.

Contd. The servers receive the DHCPREQUEST broadcast

from the client. Those servers not selected by the DHCPREQUEST

message use the message as notification that the client has declined that server's offer.

The server selected in the DHCPREQUEST message commits the binding for the client to persistent storage and responds with a DHCPACK message containing the configuration parameters for the requesting client.

Contd. The combination of client hardware and

assigned network address constitute a unique identifier for the client's lease and are used by both the client and server to identify a lease referred to in any DHCP messages.

The your IP address field in the DHCPACK messages is filled in with the selected network address.

Contd. The client receives the DHCPACK message with

configuration parameters. The client performs a final check on the parameters, for

example with ARP for allocated network address, and notes the duration of the lease and the lease identification cookie specified in the DHCPACK message. At this point, the client is configured.

If the client detects a problem with the parameters in the DHCPACK message (the address is already in use on the network, for example), the client sends a DHCPDECLINE message to the server and restarts the configuration process.

Contd. The client should wait a minimum of ten seconds

before restarting the configuration process to avoid excessive network traffic.

On receipt of a DHCPDECLINE, the server must mark the offered address as unavailable (and possibly inform the system administrator that there is a configuration problem).

If the client receives a DHCPNAK message, the client restarts the configuration process.

Contd.

The client may choose to relinquish its lease on a network address by sending a DHCPRELEASE message to the server.

The client identifies the lease to be released by including its network address and its hardware address.

BOOTP/DHCP Message Format

Number of Seconds

OpCode Hardware Type

Your IP address

Unused (in BOOTP)Flags (in DHCP)

Gateway IP address

Client IP address

Server IP address

Hardware AddressLength

Hop Count

Server host name (64 bytes)

Client hardware address (16 bytes)

Boot file name (128 bytes)

Transaction ID

Options

(There are >100 different options)

Message Fields code: Indicates a request or a reply

1 Request 2 Reply

HWtype: The type of hardware, for example: 1 Ethernet 6 IEEE 802 networks

length: Hardware address length in bytes. E.g., Ethernet and token-ring both use 6 bytes.

hops: The client sets this to 0. It is incremented by a router that relays the request to another server and is used to identify loops. RFC 951 suggests that a value of 3 indicates a loop.

Contd. Transaction ID: A random number used to match this boot request

with the response it generates. Seconds: Set by the client. It is the elapsed time in seconds since the

client started its boot process. Flags field: The most significant bit of the flags field is used as a

broadcast flag. All other bits must be set to zero, and are reserved for future use. Normally, DHCP servers attempt to deliver DHCP messages directly to a client using unicast delivery. The destination address in the IP header is set to the DHCP your IP address and the MAC address is set to the DHCP client hardware address. If a host is unable to receive a unicast IP datagram until it knows its IP address, then this broadcast bit must be set (=1) to indicate to the server that the DHCP reply must be sent as an IP and MAC broadcast. Otherwise this bit must be set to zero.

Contd. Client IP address: Set by the client. Either its known IP address,

or 0.0.0.0. Your IP address: Set by the server if the client IP address field

was0.0.0.0. Server IP address: Set by the server. Router IP address: This is the address of a BOOTP relay agent,

not a general IP router to be used by the client. It is set by the forwarding agent when BOOTP forwarding is being used

Client hardware address: Set by the client. DHCP defines a client identifier option that is used for client identification. If this option is not used the client is identified by its MAC address.

Contd. Server host name: Optional server host name terminated by

X'00'. Boot file name: The client either leaves this null or specifies a

generic name, such as router, indicating the type of boot file to be used. In a DHCPDISCOVER request this is set to null. The server returns a fully qualified directory path name in a DHCPOFFER request. The value is terminated by X'00'.

Options: Subnet Mask, Name Server, Hostname, Domain Name, Forward On/Off, Default IP TTL, Broadcast Address, Static Route, Ethernet Encapsulation, X Window Manager, X Window Font, DHCP Msg Type, DHCP Renewal Time, DHCP Rebinding, Time SMTP-Server, SMTP-Server, Client FQDN,

Printer Name, …

Main Points of Lab 7 NAT

Configuring NAT in Cisco and Linux How NAT behaves in various situations

DHCP Configuring a Linux box as a DHCP server Observing DHCP relay agents

Setting up a SOHO network using NAT and DHCP

Homework

Prelab 8 due this Friday Please write your own answers!

Lab report 7 due next week before labs