Transcript pptx

CMPT 471
Networking II
DHCP
© Janice Regan, 2006-2013
1
Bootstrapping Autoconfiguration




Bootstrapping is a process by which a client (diskless or with
limited storage) can obtain information ranging from IP addresses
to bootloading files (from a server or servers)
Bootstrapping uses this information to load OS into volatile storage
and customize the environment for a particular host (configure the
host)
At one time configuration of host specific information like
addresses, was done manually as each host was added to a
network or network information was updated.
Autoconfiguration allows us to automate this procedure, or isolate
the need for updates to one or more configuration servers.
Automation of these procedures is now also important for
supporting mobility of hosts.
© Janice Regan, 2006-2013
2
Protocols: 1
 Protocols used for bootstrapping include RARP and
BOOTP (BOOTstrap Protocol).
 RARP, Reverse Address Resolution Protocol, (RFC
903) is limited, supplying only IP address of the booting
host. This is adequate only on very simple networks
 RARP was superceded by BOOTP which could supply
more information (RFC 951, 1542, 2132), but was
appropriate only when
 workstations rarely move from network to network
 Each workstation had its own fixed IP address
© Janice Regan, 2006-2013
3
Protocols: 2
 Networks today do not conform to either of these
constraints.

Workstations are commonly moved from network to network
 Workstations will want an IP address from the network they are
attached to, not a static IP address
 To extend the functionality of BOOTP, DHCP (Dynamic
Host Configuration Protocol) was developed
 DHCP is fully backward compatible with BOOTP,
providing necessary extensions to that protocol.
© Janice Regan, 2006-2013
4
DHCP configuration
 Hosts of a particular hardware type will have a common
operating system/environment. They will also need host
specific configuration information
 In addition to the IP address BOOTP and DHCP servers
can supply other configuration information including
netmask (prefix length), gateway address, desired IP
address, DNS server address, bootstrap file name and
other information (some vendor specific)
 BOOTP and DHCP messages are encapsulated in UDP
packets which are in turn encapsulated in IP packets
© Janice Regan, 2006-2013
5
Encapsulation BOOTP or DHCP
BOOTP or DHCP message
Ethernet header
UDP header
BOOTP or DHCP message
IP header
UDP header
BOOTP or DHCP message
IP header
UDP header
BOOTP or DHCP message
© Janice Regan, 2006-2013
6
Uses
 BOOTP / DHCP can be used to boot a host with
very little non volatile (permanent) memory.
 A minimal version of the OS can be stored in the
permanent memory and used at boot to request a
full boot image and configuration
 BOOTP / DHCP can be used on a host which
requires only configuration information
 Host had complete OS and all common required
software elements.
 Host needs host specific configuration information
© Janice Regan, 2006-2013
7
Sending the DHCP request
 DHCP messages are sent in IP packets through




port 67
DHCP is being used to determine the IP
address of the booting host
Therefore, DCHP requests must be broadcast to
the local network
The DHCP server will receive the request if it is
on the local network
The DHCP server need not be on the local
network segment. DHCP relay agents (routers or
multihomed hosts) can forward DHCP requests
and replies to other network segments
© Janice Regan, 2006-2013
8
Sending the DHCP reply
 The DHCP server knows the IP address of the booting




host, so it can address a unicast IP packet to that host
The booting host does not know its own IP address and
IP specifies (RFC 1122) that a host should drop packets
not destined for one of its own IP addresses.
This seems to imply that the reply must also be
broadcast. However, RFC 1122 does not specifically
state what should happen if the host does not know its
own IP address
The later BOOTP specification (RFC 1542) does specify
that IP packets should not be ignored if the host does
not yet know its own IP address
BOOTP and DHCP replies are usually unicast, but can
be broadcast. They are sent through port 68
© Janice Regan, 2006-2013
9
But how does IP layer get a packet
not sent to its IP address?
 The host sending the DHCP reply will
 know the IP address of the host that sent the DHCP
request
 assign the IP address for this host (so now it knows
both the IP and Ethernet addresses of the
requesting host)
 In most cases insert the IP/ethernet address
information into the ARP cache of the machine
constructing the DHCP reply
 Be able to unicast a reply to the requesting
host
© Janice Regan, 2006-2013
10
But how does IP layer get a packet
not sent to its IP address?
 When the DHCP reply is received
 The Ethernet address the reply is delivered
to is the host making the DHCP request
 The Ethernet packet has its header removed
and the remaining data is passed to the IP
layer
 The IP destination address in the DHCP
request is the IP of the requesting machine
but the requesting machine does not know
this yet.
© Janice Regan, 2006-2013
11
Two step boot process
 The DHCP server maintains a static database of network




information that can be sent to the booting host in the DHCP
reply
The DHCP reply provides information necessary to obtain a
boot image, not the boot image itself.
DHCP allows this information to be used to access and
download a boot image.
Boot image may reside on the DHCP server or on another
host
Allows configuration of multiple groups of machines with
similar hardware or software needs (ie different kernel)
© Janice Regan, 2006-2013
12
DHCP message structure
© Janice Regan, 2006-2013
Comer 2000: fig 23.5
13
DHCP message structure: 1
 OP field is 1 for BOOTP request, 2 for BOOTP reply
 HTYPE (hardware type as for ARP), HLEN (in octets),





and Client address specify the booting hosts hardware
address
Hops is set to 0 by the booting host and incremented by
the DHCP relay agent before forwarding to an adjacent
network
Transaction id is used to match requests and replies
Secs is the # of seconds since the first DHCP request
Only one flag is used. It determines if the reply is to be
broadcast or unicast (default is unicast)
Client IP address is either 0.0.0.0 or an IP address
being requested by the booting client
© Janice Regan, 2006-2013
14
DHCP message structure: 2
 Your ip address is the IP address supplied by the server
(may not be the requested address). Must be included
since it cannot be recovered if the reply is broadcast
 Server IP address is used to indicate where the boot
image can be obtained
 Router IP address is used by a relay agent. Booting
host sets to 0.0.0.0, first relay agent inserts its own IP
address before forwarding to adjacent network. DHCP
server returns reply to first relay agent which is
responsible for unicast or broadcast on the local
network segment.
© Janice Regan, 2006-2013
15
BOOTP message structure: 3
 Server Name is used if a response is requested from a
specific BOOTP server
 Boot file name, booting host specifies type of boot file,
server sends address of image
 Vendor Specific Information Field: Includes options.
This is where netmask, server addresses (DNS,
NIS,…), and actual vendor specific data is inserted.
Maximum length of field is 64 bytes. If more than 64
bytes of options are needed the BOOTP server can
specify a file containing the option and vendor specific
information. Each option in the field or the file is given
as a tag, a length, and the data
© Janice Regan, 2006-2013
16
Structure of options: samples
Option code
Option length (octets)
Option data
51
4
Lease time
53
1
Option data
1
4
Subnet mask
6
4
DNS server IP address
50
4
requested IP address
3
8
1st and 2nd router IP address
Message type
255
© Janice Regan, 2006-2013
17
Message type
 The message type is specified as an option.
 The option has option code 53, length 1, and data








DHCPOFFER
DHCPPACK
DHCPREQUEST
DHCPDISCOVER
DHCPDECLINE
DHCPNAK
DHCPRELEASE
DHCPINFORM
2
5
3
1
4
6
7
8
 The IP type field indicates DHCP, not the type of DHCP
message
© Janice Regan, 2006-2013
18
Dynamic Configuration
 BOOTP is based upon a static database
configured by the network administrator
 To make the system work in networks where
hosts are added or removed frequently or in
large networks you really want a dynamic,
automatically updated system. In such a system
the administrator no longer needs to manually
update the system each time a change occurs.
 DHCP is the extension to BOOTP that allows
dynamic
configuration.
© Janice Regan, 2006-2013
19
Lifetime of Dynamic Entries
 Three timers are used within DHCP
 Lease time: the length of time for which the assigned
IP address will remain valid (seconds)
 Renewal time: length of time before the client should
request an extension of the lease time from its
chosen DHCP server (seconds). Default is 50% of
Lease time.
 Rebinding time: length of time before the client should
request an extension of lease from all accessible
DHCP servers (seconds). Default is 87.5% of Lease
time
© Janice Regan, 2006-2013
20
DHCP: use of renewal timer
 If client’s renewal time expires
 Client requests extension from it’s DHCP server
(Request unicast to DHCP server)
 if no reply is received request is transmitted with
exponential backoff (4, 8, 16, …, 64 seconds) until a
response is received or a set number of
retransmission occur
 If lease extension is granted update lease time,
renewal time and rebinding time to reflect extension
 If lease is not extended terminate lease (send
DHCPRELEASE message
© Janice Regan, 2006-2013
21
Use of rebinding timer
 If client’s rebinding timer expires
 Client broadcasts an extension request to all DHCP
servers



if no reply is received request is transmitted with
exponential backoff (4, 8, 16, … 64 seconds) until a
response is received or until a set number of
retransmission occurs
If lease extension is granted update lease time,
renewal time, rebinding time and identity of selected
DHCP server to reflect extension granted by a
different server
If lease is not extended terminate lease (send
DHCPRELEASE message)
© Janice Regan, 2006-2013
22
DHCP state machine
INIT
REBOOT
DHCPREQUEST
DHCPNAK
©Comer
Janice 2000:
Regan,fig
2006-2013
23.4
23
Initial configuration: Summary
 Client begins in INITIALIZE, if it boots without a valid IP
address (no address, expired address or invalid
address)
© Janice Regan, 2006-2013
24
Initial configuration: Summary
 Four messages are exchanged.
 A DHPDISCOVER message is broadcast by the host
 Each server/relay client finds an IP address for the
host and sends it to the host in a DHCPOFFER
message
 The host chooses a server from received offer
messages (usually takes the first) then broadcasts a
DHCPREQUEST
 When the server receives the DHCPREQUEST
message it confirms the IP address assignment by
sending a DHCPACK back to the host.
© Janice Regan, 2006-2013
25
Initial configuration: 1
 A DHPDISCOVER message is broadcast so it reaches
all DHCP servers or relay clients on the attached
network





Ethernet: destination address all 1’s, source address is
ethernet address of host making DHCP request
IP: source address 0.0.0.0, destination address
255.255.255.255
UDP : source port 68, destination port 67
Client address and your address 0.0.0.0, client hardware
address is the Ethernet address of the host making the DHCP
request
Options: needs Message type and parameter request list
© Janice Regan, 2006-2013
26
Initial configuration: 2
 Each server/relay client finds an IP address for the host
and sends it to the host in a DHCPOFFER message
 Ethernet: destination address is the client Ethernet
address, source address is Ethernet address of replying
DHCP server
 IP: source address is the address of the replying server,
destination address is the client address (or broadcast)
 UDP : source port 68, destination port 67
 Client address 0.0.0.0 and your address is set, client
hardware address as for DHCPDISCOVER packet
 Options: needs Message type, lease time, renewal time,
server IP address, rebinding time, any subnet mask
© Janice Regan, 2006-2013
27
Initial configuration: 3


The client chooses a server from received offer messages (usually
takes the first) then broadcasts a DHCPREQUEST including the
server address and suggested least time and rebinding time
The chosen server chooses an IP address, places the address and
configuration information into its database and replies with a
DHCPACK containing the information



It is recommended that the server probe the IP address it is assigning
to the client
Other servers know that they have not been chosen and release
the IP address they offered for later use.
When the client receives the DHCPACK it is recommended that it
should use an ARP request to confirm its assigned address is not
in use.
© Janice Regan, 2006-2013
28
Initial configuration: 4
client
DHCP DISCOVER
DHCP REQUEST
DHCP PACK
DHCP OFFER
Selected
router
client
DHCP DISCOVER
DHCP REQUEST
Offered Address
DHCP OFFER
returned to pool
unselected
router
© Janice Regan, 2006-2013
29
Initial configuration: transitions
INIT
REBOO
T
DHCPREQUEST
©Comer
Janice 2000:
Regan,fig
2006-2013
23.4
DHCPNAK
30
DHCP message structure
© Janice Regan, 2006-2013
Comer 2000: fig 23.5
31
Rebooting before lease expires
 When a client is rebooted or turned on and it has
recorded a previous lease

It checks to see if the has expired
 If the lease has expired it goes to INIT state and begins
negotiating a new IP address
 If the lease has not expired it goes into INIT-REBOOT state
and attempts to confirm the lease is still valid



The client broadcasts a DHCPREQUEST, including the IP
address to be confirmed as a requested IP address in the options
When the server receives the request it checks that the address
is available and is on the correct network then sends a
DHCPACK if it is.
When the client receives the DHCPACK it is recommended that it
should use an ARP request to confirm its assigned address is not
in use.
© Janice Regan, 2006-2013
32
Reboot before lease expires: transitions
INIT
REBOOT
DHCPREQUEST
©Comer
Janice 2000:
Regan,fig
2006-2013
23.4
DHCPNAK
33
DHCP message structure
© Janice Regan, 2006-2013
Comer 2000: fig 23.5
34
Moving to a new network
 When a client is rebooted or turned on and it has
recorded a previous lease

It checks to see if the has expired
 If the lease has not expired it goes into INIT-REBOOT state
and attempts to confirm the lease is still valid

The client broadcasts a DHCPREQUEST, including the IP
address to be confirmed as a requested IP address in the
options

When the server receives the request it checks if the
address is on the correct network since the host has
moved it is not

The server sends a DCHPNAK to the client

The client moves into the INIT state and start a new
initialization
© Janice Regan, 2006-2013
35
Moving to a new network:
transitions
INIT
REBOO
T
DHCPREQUEST
©Comer
Janice 2000:
Regan,fig
2006-2013
23.4
DHCPNAK
36
Extending a lease: 1
 When the client negotiates the lease a renewal
time and a rebinding time can be set (default is
½ lease time and 87.5% of lease time)
 At the renewal time is reached the client sends
a DHCPREQUEST message to the specified
server requesting that the lease be extended
 If the server agrees it sends a DHCPACK back to
the client to extend the lease
 If the server disagrees it sends a DHCPNAK and the
client must disconnect from the network terminating
the lease
37
© Janice Regan, 2006-2013
Extending a lease: 2
 If the server does not reply to the DHCPREQUEST sent
to renew the lease
 the client will retransmit (unicast) with exponential
backoff (after 4, 8, 16, … seconds).
 Eventually the client will enter rebind state



then DHCPREQUESTS are broadcast to all servers.
If another server can extend the lease that server will
respond an renew the lease and move the client back to
the bound state
If no server responds and the lease expires the client
returns to the initialize state
© Janice Regan, 2006-2013
38
Extending a lease: transitions
INIT
REBOO
T
DHCPREQUEST
© Janice
ComerRegan,
2000: 2006-2013
fig 23.4
DHCPNAK
39
Releasing a lease: transitions
INIT
REBOO
T
DHCPREQUEST
© Janice
ComerRegan,
2000: 2006-2013
fig 23.4
DHCPNAK
40
DHCP software
 A commonly used DHCP package used
on linux networks is the ISC (Internet
software consortium) DHCP package
 To help understand how this package is
used read the linux documentation for



The DHCP relay agent, dhcrelay (posted)
The DHCP client, dhclient
The DHCP server, dhcpd
© Janice Regan, 2006-2013
41