Transcript CSEE W4140 Networking Laboratory

CSEE W4140
Networking Laboratory
Lecture 9: NAT and DHCP
Jong Yul Kim
04.01.2009
Announcements
 Final Project Topics
 Project topics will be on class website by today
 You’re welcome to come up with your own topics
 Final project will not be like the labs you’ve been
doing.
 No step-by-step guide
 Need to write 3 reports
 5 weeks to deliver a demo and a good report
 More interactions with staff
 Same 20% of total grade as final exam
Announcements
 Final Project Schedule
 April 3 (2 days from today)
 select project and team (two students per team)
 April 8 (a week from now)
 submit a one page project proposal report stating the
problem, equipment requirements, and deliverables
 April 22 (3 weeks from now )
 submit an interim report stating your approach to the
problem and planned experiment architecture
 May 8 (5 weeks from now)
 demo and submit the final report
Today’s lecture
 Network Address Translator (NAT)
 Dynamic Host Configuration Protocol
(DHCP)
Private Networks
H1
10.0.1.2
Private IP addresses used are:
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
Not globally unique
or routable
H2
H3
H4
10.0.1.2
10.0.1.3
10.0.1.1
10.0.1.3
10.0.1.1
Private network 1
Private network 1
Internet
R1
128.195.4.119
128.143.71.21
213.168.112.3
H5
R2
Network Address Translator
 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
 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
Private Network
•Source
•Destination
= 10.0.1.2
= 64.236.24.4
•Source
•Destination
•private address: 10.0.1.2
•public address: 128.143.71.21
•Host
= 64.236.24.4
•Source
•Destination = 10.0.0.2
Internet
128.143.71.21
= 10.0.1.2
= 64.236.24.4
•Source
•Destination
= 128.143.71.21
= 64.236.24.4
NAT
Device
= 64.236.24.4
•Source
•Destination = 128.59.16.21
10.0.0.2
Private
Address
Public
Address
10.0.1.1
128.59.16.21
= 64.236.24.4
•Source
•Destination = 128.59.16.21
Public Host
64.236.24.4
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
Private
network
Internet
Source
= 10.0.1.2
Destination = 213.168.112.3
Source
= 128.143.71.21
Destination = 213.168.112.3
NAT
device
private address: 10.0.1.2
public address:
H1
public address:
213.168.112.3
H5
Private
Address
Public
Address
10.0.1.2
Pool of addresses: 128.143.71.0-128.143.71.30
Static mapping
Dynamic mapping
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
Source
= 128.14.71.21
Destination = 213.168.112.3
Source
= 10.0.1.2
Destination = 213.168.112.3
private address:
public address:
10.0.1.2
128.14.71.21
128.14.71.21
Host
NAT
device
Private network
Private
Address
10.0.1.2
Public
Address
128.14.71.21
ISP 1
allocates address
block
128.14.71.0/24 to
private network:
Supporting migration between
network service providers
Source
= 10.0.1.2
Destination = 213.168.112.3
private address:
public address:
10.0.1.2
128.14.71.21
150.140.4.120
128.14.71.21
150.140.4.120
X
ISP 1
allocates address
block
128.14.71.0/24 to
private network:
Host
NAT
device
Private network
Source
= 150.140.4.120
Destination = 213.168.112.3
Private
Address
Public
Address
10.0.1.2
128.14.71.21
150.140.4.120
ISP 2
allocates address block
150.140.4.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
IP Masquerading
(NAPT/PAT)
Problems of NAT
 NAT and FTP
 NAT and UDP applications
NAT and FTP
 Normal FTP operation
Data channel
initiated by
server
NAT and FTP
 FTP failing because of NAT
Private network
FTP client
private address: 10.0.1.3
public address: 128.143.72.21
Internet
FTP server
NAT
device
H1
H2
PORT 10.0.1.3/1027
PORT 128.143.72.21/1027
200 PORT command successful
200 PORT command successful
RETR myfile
RETR myfile
150 Opening data connection
Data channel
initiated 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
IPaddr: Y1
IPaddr: X1
X1:x1 Y1:y1
X1:x1 Y1:y2
X1:x1 Z1:z1
X1:x1 Z1:z2
Endpoint-independent
mapping
NAT
N1:n1Y1:y1
N1:n1 Y1:y2
N1:n1 Z1:z1
N1:n1 Z1:z2
IPaddr: Z1
Endpoint-independent Filtering
X1:x1 N1:n1 Y1:y1
IPaddr: X1
IPaddr: Y1
Y1:y2 N1:n1
Z1:z1 N1:n1
NAT
IPaddr: Z1
Address-dependent Mapping
IPaddr: Y1
IPaddr: X1
X1:x1 Y1:y1
X1:x1 Y1:y2
X1:x1 Z1:z1
X1:x1 Z1:z2
Address-dependent
mapping
NAT
N1:n1 Y1:y1
N1:n1 Y1:y2
N1:n2 Z1:z1
N1:n2 Z1:z2
IPaddr: Z1
Address-dependent Filtering
(1) X1:x1 N1:n1 Y1:y1
IPaddr: Y1
IPaddr: X1
Y1:y2 N1:n1
Z1:z1 N1:n1
NAT
IPaddr: Z1
Address and port dependent
Mapping
IPaddr: Y1
IPaddr: X1
X1:x1 Y1:y1
X1:x1 Y1:y2
X1:x1 Z1:z1
X1:x1 Z1:z2
NAT
Address and port
dependent
N1:n1 Y1:y1
N1:n2 Y1:y2
N1:n3 Z1:z1
N1:n4 Z1:z2
IPaddr: Z1
Address and port dependent
Filtering
(1) X1:x1 N1:n1 Y1:y1
IPaddr: X1
IPaddr: Y1
Y1:y1 N1:n1
Y1:y2 N1:n1
Z1:z1 N1:n1
NAT
IPaddr: Z1
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
(a)
Argon
00:a0:24:71:e4:44
BOOTP Server
Argon
128.143.137.144
00:a0:24:71:e4:44
(b)
DHCP Server
BOOTP Response:
IP address: 128.143.137.144
Server IP address: 128.143.137.100
Boot file name: filename
BOOTP Request
00:a0:24:71:e4:44
Sent to 255.255.255.255
(c)
 BOOTP can be used for
downloading memory
image for diskless
workstations
 Assignment of IP
addresses to hosts is
static
DHCP Interaction (simplified)
Argon
128.143.137.144
00:a0:24:71:e4:44
DHCP Server
DHCP Response:
IP address: 128.143.137.144
Default gateway: 128.143.137.1
Netmask: 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
 Uses UDP, an unreliable and insecure
protocol.
 DNS cannot be used for DHCP
configured hosts.
BOOTP/DHCP Message Format
OpCode
Hardware Type
Number of Seconds
Hardware Address
Hop Count
Length
Unused (in BOOTP)
Flags (in DHCP)
Transaction ID
Client IP address
Your IP address
Server IP address
Gateway IP address
Client hardware address (16 bytes)
Server host name (64 bytes)
Boot file name (128 bytes)
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, …
DHCP Message Type
 Message type is
Value Message Type
sent as an option.
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 in case of looping.
 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.
Homework
 Prelab 7 due this Friday
 Please write your own answers!
 Lab report 6 due next week before
labs
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