Unit 3.

1
Dynamic Host Configuration
Protocol (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
Reverse Address Resolution Protocol (RARP)
It is an absolute protocol
Works similar to ARP
Broadcast a request for the IP address associated with a
given MAC address
RARP server responds with an IP address
Only assigns IP address (not the default router and
subnetmask)

ARP Ethernet MAC

IP address
address
(32 bit)
(48 bit)
RARP
BOOTP
 BOOTstrap Protocol (BOOTP)
 It is an IPv4 network protocol
 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
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
Argon
(a)
Interaction Argon
128.143.137.144
(b)
00:a0:24:71:e4:44 BOOTP Server 00:a0:24:71:e4:44 DHCP Server
BOOTP Response:
IP address: 128.143.137.144
BOOTP Request
00:a0:24:71:e4:44 Server IP address: 128.143.137.100
Sent to 255.255.255.255 Boot file name: filename

BOOTP can be used for

Argon (c) downloading memory
image for diskless
128.143.137.144
00:a0:24:71:e4:44 DHCP Server

TFTP workstations
Assignment of IP
“filename”

128.143.137.100
addresses to hosts is static
DHCP Interaction
Argon
00:a0:24:71:e4:44 DHCP Server

DHCP Request
00:a0:24:71:e4:44
Sent to 255.255.255.255

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
BOOTP/DHCP Message Format
OpCode Hardware Type
Hardware Address
Hop Count
Length
Unused (in BOOTP)
Number of Seconds
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 sent as an option. 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.
 DHCP Operation DHCP Client
00:a0:24:71:e4:44 DHCP Server
 DCHP DISCOVER DHCPDISCOVER
Sent to 255.255.255.255

DHCP Server

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

DHCPOFFER
• DCHP OFFER

DHCP Server
 DHCP Operation DHCP Client
00:a0:24:71:e4:44 DHCP Server
DHCPREQUEST

• DCHP DISCOVER DHCPACK

At this time, the DHCP DHCP Server

client can start to use the IP
address
DHCP Client
00:a0:24:71:e4:44 DHCP Server
DHCPREQUEST

• Renewing a Lease DHCPACK

(sent when 50% of lease

has expired)
If DHCP server sends DHCP Server
DHCPNACK, then
address is released.
 DHCP Operation
DHCP Client
00:a0:24:71:e4:44 DHCP Server
• DCHP RELEASE DHCPRELEASE

At this time, the DHCP

client has released the IP
DHCP Server
address
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.
Lease Renewal
 When a server sends the DHCPACK to a client with IP address and
configuration parameters, it also registers the start of the lease time
for that address.
 This lease time is passed to the client as one of the options in the
DHCPACK message, together with two timer values, T1 and T2.
 The client is rightfully entitled to use the given address for the
duration of the lease time.
Contd.
 On applying the receive configuration, the client also starts the timers
T1 and T2. At this time, the client is in the BOUND state.
 Times T1 and T2 are options configurable by the server but T1 must be
less than T2, and T2 must be less than the lease time.
 According to RFC 2132, T1 defaults to (0.5 * lease time) and T2 defaults
to (0.875 * lease time).
Contd.
 When timer T1 expires, the client will send a DHCPREQUEST
(unicast) to the server that offered the address, asking to
extend the lease for the given configuration. The client is
now in the RENEWING state
 The server would usually respond with a DHCPACK message
indicating the new lease time, and timers T1 and T2 are reset
at the client accordingly.
 The server also resets its record of the lease time.
 Under normal circumstances, an active client would
continually renew its lease in this way indefinitely, without
the lease ever expiring.
Contd.
If no DHCPACK is received until timer T2
expires, the client enters the REBINDING
state.
Client now broadcasts a DHCPREQUEST
message to extend its lease.
This request can be confirmed by a
DHCPACK message from any DHCP server
on the network.
Contd.
If the client does not receive a DHCPACK
message after its lease has expired, it has
to stop using its current TCP/IP
configuration.
The client may then return to the INIT
state, issuing a DHCPDISCOVER broadcast
to try and obtain any valid address.
Reusing a Previously allocated
address
 The client broadcasts a DHCPREQUEST message on its local
subnet.
 The DHCPREQUEST message includes the client's
previously used network address.
 If the client’s lease is still current, the server with knowledge
of the client's configuration parameters responds with a
DHCPACK message to the client, renewing the lease at the
same time.
 The client must then proceed to test for the IP address.
 If the client's lease has expired, the server with knowledge of
the client responds with DHCPNACK.
 The client then must initiate a new IP address allocation
process.
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.
DNS
History
 ARPANET utilized a central file HOSTS.TXT
 Contains names to addresses mapping
 Maintained by SRI’s NIC (Stanford-Research-Institute:
Network-Information-Center)

 Administrators email changes to NIC

 NIC updates HOSTS.TXT periodically
 Administrators FTP (download) HOSTS.TXT
History
 As the system grew, HOSTS.TXT had problems with:
 Scalability (traffic and load)
 Name collisions
 Consistency

 In 1984, Paul Mockapetris released the first version

(RFCs 882 and 883, superseded by 1034 and 1035 …)
DNS
The “Domain Name System”
What Internet users use to reference anything by
name on the Internet
The mechanism by which Internet software translates
names to attributes such as addresses
DNS
A globally distributed, scalable, reliable database
Comprised of three components
A “name space”
Servers making that name space available
Resolvers (clients) which query the servers about the
name space
DNS as a Lookup Mechanism
Users generally prefer names to numbers

Computers prefer numbers to names

DNS provides the mapping between the two

I have “x”, give me “y”
DNS as a Database
Keys to the database are “domain names”
www.foo.com, 18.in-addr.arpa, 6.4.e164.arpa
Over 200,000,000 domain names are stored
Each domain name contains one or more attributes
Known as “resource records”
Each attribute individually retrievable
Global Distribution
Data is maintained locally, but retrievable globally
No single computer has all DNS data
DNS lookups can be performed by any device
Remote DNS data is locally cachable to improve
performance
Loose Coherency
Each version of a subset of the database (a zone)
has a serial number
 The serial number is incremented on each database change

Changes to the master copy of the database are

propagated to replicas according to timing set by
the zone administrator
Cached data expires according to timeout set by
zone administrator
Scalability
No limit to the size of the database
No limit to the number of queries
Tens of thousands of queries handled easily every
second
Queries distributed among masters, slaves, and
caches
Reliability
Data is replicated
Data from master is copied to multiple slaves
Clients can query
Master server
Any of the copies at slave servers
Clients will typically query local caches
DNS protocols can use either UDP or TCP
If UDP, DNS protocol handles retransmission,
sequencing, etc.
Dynamicity
Database can be updated dynamically
Add/delete/modify of any record
Only master can be dynamically updated

Modification of the master database triggers

replication
 Distributed, Hierarchical Database
Root DNS Servers

com DNS servers org DNS servers edu DNS servers

yahoo.com pbs.org poly.edu umass.edu

amazon.com
DNS servers DNS servers DNS servers DNS servers
DNS servers

Client wants IP for www.amazon.com; 1st approx:

client queries a root server to find com DNS server
client queries com DNS server to get amazon.com DNS
server
client queries amazon.com DNS server to get IP address
for www.amazon.com
 DNS: Root name servers
 contacted by local name server that can not resolve name
 root name server:
 contacts authoritative name server if name mapping not known
 gets mapping
 returns mapping to local name server
a Verisign, Dulles, VA

c Cogent, Herndon, VA (also LA) k RIPE London (also 16 other locations)

d U Maryland College Park, MD i Autonomica, Stockholm (plus
28 other locations)
g US DoD Vienna, VA
e NASA Mt View, CA m WIDE Tokyo (also Seoul,
h ARL Aberdeen, MD Paris, SF)
f Internet Software C. Palo Alto,
CA (and 36 other locations) j Verisign, ( 21 locations)

• 13 root name
servers worldwide
b USC-ISI Marina del Rey, CA

l ICANN Los Angeles, CA

TLD and Authoritative Servers
Top-level domain (TLD) servers:
 responsible for com, org, net, edu, etc, and all top-
level country domains uk, fr, ca, jp.
Network Solutions maintains servers for com TLD
Educause for edu TLD
Authoritative DNS servers:
organization’s DNS servers, providing authoritative
hostname to IP mappings for organization’s servers
(e.g., Web, mail).
can be maintained by organization or service
provider
Local Name Server
does not strictly belong to hierarchy
each ISP (residential ISP, company, university) has
one.
also called “default name server”
when host makes DNS query, query is sent to its local
DNS server
acts as proxy, forwards query into hierarchy
DNS Queries
Recursive:
The client machine sends a request to the local name
server, which, if it does not find the address in its
database, sends a request to the root name server,
which, in turn, will route the query to an intermediate
or authoritative name server. Note that the root name
server can contain some hostname to IP address
mappings. The intermediate name server always knows
who the authoritative name server is.
DNS Queries
Iterative:
The local server queries the root server. If address not
in its database, will have the name/address of an
intermediate or authoritative name server and forward
that information to the local name server so that it can
directly communicate with the intermediate or
authoritative name server. This is to prevent the
overloading of the root servers that handle millions of
requests.
 root DNS
server

• recursive query: 2 3

 puts burden of name 7 6

resolution on contacted TLD DNS
name server server

 heavy load? local DNS server

5 4
dns.poly.edu
1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu
gaia.cs.umass.edu
DNS name resolution example root DNS
server

2
Host at cis.poly.edu 3
TLD DNS
wants IP address for 4 server
gaia.cs.umass.edu 5

• iterated query: local DNS server

dns.poly.edu
 contacted server replies 7 6
1 8
with name of server to
contact authoritative DNS server

 “I don’t know this name, dns.cs.umass.edu

requesting host
but ask this server” cis.poly.edu
gaia.cs.umass.edu
DNS: caching and updating records
once (any) name server learns mapping, it caches
mapping
cache entries timeout (disappear) after some time
TLD servers typically cached in local name servers
 Thus root name servers not often visited
update/notify mechanisms under design by IETF
 RFC 2136
 http://www.ietf.org/html.charters/dnsind-charter.html
Operation of DNS
DNS uses caching to increase the speed with which it
does the translation.
The DNS data is stored in the database in the form of
resource records (RR). The RRs are directly inserted
in the DNS messages.
The RRs are a 4 tuple that consist of: {name, value,
type, TTL}.
RRs
TTL: time to live, used to indicate when an RR
can be removed from the DNS cache.
Type =
A - then NAME is a hostname and Value its IP address
NS - then NAME is a domain name and Value is the IP
address of an authoritative name server
CNAME - then NAME is an alias for a host and Value is
the canonical name for the host
MX - then NAME is an alias for an email host and Value
is the the canonical name for the email server
DNS records
DNS: distributed db storing resource records (RR)

RR format: (name, value, type, ttl)

o Type=A o Type=CNAME
o name is hostname o name is alias name for some
“canonical” (the real) name, eg.,
o value is IP address www.ibm.com is really
servereast.backup2.ibm.com
o Type=NS o value is canonical name
o name is domain (eg.,
foo.com) o Type=MX
o value is hostname of
o value is name of mailserver
authoritative name
associated with name
server for this
domain
DNS protocol, messages
DNS protocol : query and reply messages, both with same message format

• msg header
 identification: 16 bit # for
query, reply to query uses
same #

 flags:

 query or reply

 recursion desired

 recursion available

 reply is authoritative
DNS protocol, messages
Name, type fields
for a query
RRs in response
to query
records for
authoritative
servers
additional
“helpful”
info that may be
used
Message Fields
Identification - identifies a query and is copied in the
reply message to match it to the query at the client
side.
Flags - one bit flag set to indicate whether the
message is a query or a reply. Another bit to identify if
reply is from an authoritative sender or not. A third
bit is used to indicate that recursion method is
desired.
Fields
Questions - contains the name that is being
queried and the type, ie type A or MX.
Answers - contains the RRs for the name(s) that
were requested
Authority - contains records of authoritative
servers
Additional Info - e.g., if type of query is MX, then
this info can be a Type - A RR containing the IP
address of the canonical hostname
Inserting records into
example: new startup “Network Utopia”
register name networkuptopia.com at DNS registrar (e.g.,
Network Solutions)
 provide names, IP addresses of authoritative name server
(primary and secondary)
 registrar inserts two RRs into com TLD server:

(networkutopia.com, dns1.networkutopia.com, NS)

(dns1.networkutopia.com, 212.212.212.1, A)

create authoritative server Type A record for

www.networkuptopia.com; Type MX record for
networkutopia.com