Network Working Group
`Request for Comments: 2131
`Obsoletes: 1541
`
`Category: Standards Track
`
`R. Droms
`
`Bucknell University
`March 1997
`
`Dynamic Host Configuration Protocol
`
`Status of this memo
`
`This document specifies an Internet standards track protocol for the
`Internet community, and requests discussion and suggestions for
`improvements. Please refer to the current edition of the "Internet
`Official Protocol Standards" (STD 1)
`for the standardization state
`and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
`
`(DHCP) provides a framework
`The Dynamic Host Configuration Protocol
`for passing configuration information to hosts on a TCPIP network.
`DHCP is based on the Bootstrap Protocol
`(BOOTP)
`[7], adding the
`capability of automatic allocation of reusable network addresses and
`additional configuration options [19].
`DHCP captures the behavior of
`BOOTP relay agents [7, 21], and DHCP participants can interoperate
`with BOOTP participants [9].
`
`Table of Contents
`
`NosWNE
`
`hb
`
`IooO
`
`GWWw
`
`mWWWw
`
`2
`3
`4
`4
`5
`6
`6
`8
`11
`12
`13
`13
`
`17
`20
`
`20
`21
`22
`22
`22
`
`  ÿ
`ÿ

 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`  ÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ 
` ÿ
`   
`!"  ÿ#$ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ%&'ÿ(()
`&  ÿ*&
`+&+ÿ,&
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`& ÿ-ÿ
`  & 
`ÿ.
`*& ÿÿ' ÿ 
`ÿÿÿ,' ÿ+ 
`ÿ   ÿ&
`ÿ/
` 
` ÿ&
`+&+ÿ&ÿÿÿ'
`ÿÿÿ/
` 
` ÿ
`  0ÿ&
`+ÿ  ÿ+   
`ÿ&
`+ÿ   
`ÿ
`ÿÿÿ  
`ÿÿ. & ÿ  ÿÿ' ÿ 
`ÿ +  
`ÿÿ' ÿ1/
` 
` 
`ÿÿÿ!  &ÿ.ÿ*&
`+&+1ÿ2*,ÿ3ÿÿ' ÿ&
`+&+ 4& 
`ÿ&
`ÿÿÿ&
`+ÿ& ÿÿ' ÿÿÿ  "  
`ÿÿ' ÿ ÿ ÿ
`   +
`5"&
`ÿÿÿ,' ÿ
`& ÿ-ÿ
`  & 
`ÿ.ÿ2-.3ÿ + ÿ&ÿ& 
`ÿÿÿÿ&
`ÿ
`  & 
`ÿ
`& 
`ÿÿ'ÿ
`ÿ&ÿ,./.ÿ
`  
`ÿÿÿ-.ÿ ÿ"& +ÿ
`ÿ' ÿ&ÿ.ÿ2!!,.3ÿ6)70ÿ&++
`ÿ'
`ÿÿÿ&&"   ÿÿ& & ÿ&& 
`ÿÿ &" ÿ
`  ÿ&++  ÿ&
`+
`ÿÿÿ&++  
`&ÿ
`  & 
`ÿ 
`ÿ6(7ÿÿ-.ÿ&  ÿ' ÿ" '& ÿ
`ÿÿÿ!!,.ÿ & ÿ&
`ÿ6)0ÿ70ÿ&
`+ÿ-.ÿ&  &
`ÿ&
`ÿ
`  &
`ÿÿÿ 'ÿ!!,.ÿ&  &
`ÿ6(7
`,&" ÿÿ
`
`
`ÿÿÿÿÿ/
`+  
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ'&
` ÿÿ8#$ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ & +ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ$
`ÿÿÿÿ." ÿ+ 
`  
`ÿ&
`+ÿ  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ$
`ÿÿÿ$ÿ   
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ#
`ÿÿÿ#ÿ, 
` ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ9
`ÿÿÿ9ÿ  
`ÿ&ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ9
`ÿÿÿÿÿ.ÿ* & ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ:
`
`WWWNHNNPPPREEE
`ÿÿÿÿ
`  & 
`ÿ&&  ÿ   ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ
`& ÿ&& 
`ÿÿ
`  ÿ&++  ÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿÿ,' ÿ
`;*  ÿ.ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ
`;  ÿ
` & 
`ÿ;ÿ&&
`ÿ&ÿ
`  ÿ&++ ÿÿÿ
`ÿÿÿÿ
`;  ÿ
` & 
`ÿ;ÿ 
`ÿ&ÿÿ    ÿ&& +
`ÿÿÿÿÿÿÿ
`  ÿ&++ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ)
`ÿÿÿÿ/
`  & 
`ÿ&
`+ÿ  
`& 
`ÿÿ  ÿ& ÿÿÿÿÿÿÿ<
`ÿÿÿ$ÿ!"&
`
`ÿ&&  ÿ 'ÿ = 
`& ÿ
`   +ÿ
`  
`ÿÿÿÿÿÿÿ&++ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ<
`ÿÿÿ#ÿ
`ÿ&&  ÿ
`ÿ-.ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ9ÿ ÿÿ-.ÿ
`ÿ
`ÿ 'ÿ   ÿ
` & ÿÿÿÿÿÿÿÿ
`ÿÿÿ)ÿ'
`ÿ
`ÿ' +ÿ  ÿ-.ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ$ÿÿ*   & 
`ÿÿ' ÿ-.ÿ
`;  ÿÿÿÿÿÿÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ*&
`+&+ÿ,&ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ6.& ÿ7
`
`Introduction.
`Changes to RFC1541.
`Related Work.
`.
`Problem definition and issues
`Requirements.
`Terminology
`Design goals.
`Protocol Summary.
`Configuration parameters “repository
`Dynamic allocation of network addresses
`The Client-Server Protocol.
`.
`.
`Client-server interaction - allocating a “network: address.
`Client-server interaction - reusing a previously allocated
`network address
`.
`.
`Interpretation and representation of. time values.
`Obtaining parameters with externally configured network
`address
`.
`Client parameters in “DHCP
`.
`Use of DHCP in clients with multiple interfaces
`When clients should use DHCP.
`Specification of the DHCP client-serverYr protocol.
`
`Droms
`
`Standards Track
`
`[Page 1]
`
`Page 1 of 45
`
`Exhibit 1012
`IPR2023-00581
`U.S. Patent 8,886,772
`
`Exhibit 1012
`IPR2023-00581
`U.S. Patent 8,886,772
`
`Page 1 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`4.1 Constructing and sending DHCP messages. .......... . 22
`4.2 DHCP server administrative controls ........ .. .. . 25
`4.3 DHCP server behavior.
`.
`.
`2.
`2.
`2 ee ee ee ee ee ee eee 26
`4.4 DHCP client behavior.
`.
`.
`. 2...
`1 ee ee ee we ee ee ee 84
`5. Acknowledgments.
`. ..... 2. ee ee ee ee ee ee ew ee 042
`6. References ...
`ee ee ee ee eee AD
`7. Security Considerations. wee ee eee ee ee ee ee ee 2 AB
`8. Author’s Address...
`wee ee ee eee ee ee LAA
`A. Host Configuration Parameters ee ee ee ee ee ee ee 48
`t of Figures
`1. Format of a DHCP message .........-. 2.245454 548488+8
`2. Format of the ’flags’ field. ....
`3. Timeline diagram of messages exchanged between DHCP client and
`servers when allocating a new network address. ..
`4. Timeline diagram of messages exchanged between DHCP client and
`servers when reusing a previously allocated network address.
`. 18
`5. State-transition diagram for DHCP clients. .......... 34
`List of Tables
`1. Description of fields in a DHCP message. ........... 10
`2. DHCP messages. ..
`woe ee ee we ee wl ee 14
`3. Fields and options used. by DHCP servers.
`.
`.
`. 2...
`2 es es 28
`4. Client messages from various states. ............ . 33
`5. Fields and options used by DHCP clients. ...........37
`
`9
`11
`
`15
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿÿÿÿ  

ÿ
` ÿ 

ÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿÿ ÿ
`


`

ÿ  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ!
`ÿÿÿÿÿ ÿ"
`

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ#
`ÿÿÿÿÿ 

 ÿ"
`

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ!ÿÿ$ % & ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ#ÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿÿ' 

ÿ 


`

 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ(ÿÿ$)ÿ$ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ$ÿÿÿ 


`

 ÿ
`
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ!
`*

ÿÿ


`ÿÿÿÿ 
`ÿÿ
`ÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ 
`ÿÿÿ)
`)ÿ

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ+



ÿ

`
`ÿÿ
`ÿ, 
` ÿ"& ÿÿ 

 ÿ
` 
`ÿÿÿÿÿÿ ÿ& ÿ
`
`

ÿ
`ÿ &ÿ &%ÿ
`ÿÿÿÿÿÿÿÿÿ!
`ÿÿÿÿ+



ÿ

`
`ÿÿ
`ÿ, 
` ÿ"& ÿÿ 

 ÿ
` 
`ÿÿÿÿÿÿ ÿ& ÿ

ÿ
`ÿ-

ÿ
`
`ÿ &%ÿ
`ÿÿ(
`ÿÿÿ!ÿ'
`.
` 



 ÿ

`
`ÿÿÿ 

 ÿÿÿÿÿÿÿÿÿÿÿ
`*

ÿÿ+
`"
`ÿÿÿÿ 

-

 ÿÿ

ÿ

ÿ
`ÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿ/
`ÿÿÿÿÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿÿ

ÿ
` ÿ-

 ÿÿ"ÿÿ ÿÿÿÿÿÿÿÿÿÿÿÿ(
`ÿÿÿÿ

 ÿ
`ÿÿ
`

ÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿÿÿ!ÿ

ÿ
` ÿ-

 ÿÿ"ÿÿ 

 ÿÿÿÿÿÿÿÿÿÿÿÿ
`ÿ0  


`ÿÿÿ+ÿ
`

ÿÿ 


`

 ÿ ÿ12ÿ-

ÿ  


`


`ÿÿÿ-
`
`ÿÿ0  ÿÿÿÿ  

ÿÿ&ÿ -  3ÿ
`
`ÿÿÿ- ÿÿ



ÿ.-



ÿ  


`

 ÿ-
`
`ÿÿ
`
`ÿÿÿÿ ÿÿ
`ÿÿ
` ÿ
`ÿ 
`

ÿÿ
`
`

 ÿÿ &%
`ÿÿÿ
`ÿÿ
`ÿÿÿÿ

ÿ"

ÿ ÿ
`ÿ 

 . ÿ4ÿ&ÿ


`ÿÿ 
`ÿÿÿÿ
`
`ÿ &%ÿ
`ÿ
` ÿ

ÿ  


`

 ÿ-
`
`
`ÿÿÿÿ
`

`ÿ  

ÿÿÿ+ÿÿ
`

ÿÿ


`ÿÿÿ  4ÿÿÿ5 5ÿÿÿ
`ÿÿ-



ÿ



`

6
`


`ÿÿÿ-
`
`ÿÿ4ÿ
` ÿÿÿ5 

 5ÿÿÿ
`ÿ
`ÿÿÿ7

ÿ



`

6
`

 ÿ-
`
`ÿÿ
`ÿÿ 
`ÿÿÿ$ÿÿÿ ÿ
` ÿ
`ÿ
`ÿÿ ÿ ÿ,-

ÿ  


`ÿÿÿÿÿÿ"ÿ
`ÿÿ
`


`ÿÿ+ÿ



ÿÿ
`&
`ÿ
` 
`ÿÿÿ- ÿ

- 
`

 ÿ

ÿÿ0  ÿ&ÿ- ÿ

`"
`ÿÿÿ-
`

 ÿ

ÿ
` ÿÿ&ÿ
`&ÿÿ- ÿÿÿ7
`ÿÿÿ ÿ,
`-4ÿ0ÿ7

ÿÿ

ÿÿ
` ÿ-
`
`ÿ&



ÿ
`ÿÿÿ- ÿ

- 
`

 ÿ&
`ÿÿ8
`ÿ0ÿ
` ÿ"ÿÿ ÿ
` 
`ÿÿÿ






`ÿ%

ÿÿ &%ÿ
`&
`4ÿ
`ÿÿÿ-
`
`
`ÿÿÿ
` ÿ"ÿÿÿ
`ÿÿ
` ÿ  ÿ
`ÿÿ$4
`ÿÿÿ



"ÿ
`ÿ
`
`

 ÿ ÿ- ÿ ÿ
`ÿ-

9 
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ'
` 
`ÿ+
` %ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ:
`ÿ;
`
`A host should not act as a DHCP server unless explicitly configured
`to do so by a system administrator.
`The diversity of hardware and
`protocol implementations in the Internet would preclude reliable
`operation if random hosts were allowed to respond to DHCP requests.
`For example,
`IP requires the setting of many parameters within the
`protocol implementation software. Because IP can be used on many
`dissimilar kinds of network hardware, values for those parameters
`cannot be guessed or assumed to have correct defaults. Also,
`distributed address allocation schemes depend on a polling/defense
`
`Introduction
`
`(DHCP) provides configuration
`The Dynamic Host Configuration Protocol
`parameters to Internet hosts.
`DHCP consists of two components: a
`protocol for delivering host-specific configuration parameters from a
`DHCP server to a host and a mechanism for allocation of network
`addresses to hosts.
`
`DHCP is built on a client-server model, where designated DHCP server
`hosts allocate network addresses and deliver configuration parameters
`to dynamically configured hosts. Throughout the remainder of this
`document,
`the term "server" refers to a host providing initialization
`parameters through DHCP, and the term "client" refers to a host
`requesting initialization parameters from a DHCP server.
`
`Droms
`
`Standards Track
`
`[Page 2]
`
`Page 2 of 45
`
`Page 2 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`mechanism for discovery of addresses that are already in use.
`hosts may not always be able to defend their network addresses,
`that such a distributed address allocation scheme cannot be
`guaranteed to avoid allocation of duplicate network addresses.
`
`IP
`so
`
`[In
`DHCP supports three mechanisms for IP address allocation.
`“automatic allocation", DHCP assigns a permanent IP address to a
`client.
`In "dynamic allocation", DHCP assigns an IP address to a
`client for a limited period of time (or until the client explicitly
`relinquishes the address).
`In "manual allocation", a client’s IP
`address is assigned by the network administrator, and DHCP is used
`simply to convey the assigned address to the client.
`A particular
`network will use one or more of these mechanisms, depending on the
`policies of the network administrator.
`
`The format of DHCP messages is based on the format of BOOTP messages,
`to capture the BOOTP relay agent behavior described as part of the
`BOOTP specification [7, 21] and to allow interoperability of existing
`BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
`the necessity of having a DHCP server on each physical network
`segment.
`
`1.1 Changes to RFC 1541
`
`This document updates the DHCP protocol specification that appears in
`RFC1541.
`A new DHCP message type, DHCPINFORM, has been added; see
`section 3.4, 4.3 and 4.4 for details.
`The classing mechanism for
`identifying DHCP clients to DHCP servers has been extended to include
`"vendor" classes as defined in sections 4.2 and 4.3.
`The minimum
`lease time restriction has been removed. Finally, many editorial
`changes have been made to clarify the text as a result of experience
`gained in DHCP interoperability tests.
`
`Dynamic allocation is the only one of the three mechanisms that
`allows automatic reuse of an address that is no longer needed by the
`client to which it was assigned. Thus, dynamic allocation is
`particularly useful for assigning an address to a client that will be
`connected to the network only temporarily or for sharing a limited
`pool of IP addresses among a group of clients that do not need
`permanent IP addresses. Dynamic allocation may also be a good choice
`for assigning an IP address to a new client being permanently
`connected to a network where IP addresses are sufficiently scarce
`that it is important to reclaim them when old clients are retired.
`Manual allocation allows DHCP to be used to eliminate the error-prone
`process of manually configuring hosts with IP addresses in
`environments where (for whatever reasons) it is desirable to manage
`IP address assignment outside of the DHCP mechanisms.
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿÿÿ 
`

ÿÿ

 ÿÿ
`ÿ
`ÿ
`ÿ
`
`ÿ

ÿÿÿ 
`ÿÿÿÿ
`ÿ ÿ
`!
`ÿ"ÿ
`"ÿÿ ÿ

ÿ !#ÿ
`$ÿ
`ÿÿÿ
`ÿ ÿ
`ÿ



"ÿ
`ÿ
`
`

 ÿ ÿ
` ÿ"
`ÿÿÿ
`
` ÿÿ
`

ÿ
`
`

 ÿÿ%

`ÿ !#ÿ
`
`ÿÿÿÿ%%ÿÿ 
`

ÿÿ ÿ
`ÿ
`
`

 ÿÿ
`ÿÿÿ&
`
`

ÿ
`
`

 &$ÿÿ
`

 ÿ
`ÿ%
`  ÿ ÿ
`ÿÿ
`
`ÿÿÿ 

 ÿÿ ÿ&
`

ÿ
`
`

 &$ÿÿ
`

 ÿ
` ÿ ÿ
`ÿÿ
`
`ÿÿÿ 

 ÿÿ
`ÿ



ÿ%

ÿÿ

ÿ'ÿ 

ÿÿ 

 ÿ(%


`ÿÿÿ

)

ÿÿ
`*ÿÿ ÿ&
` 
`ÿ
`
`

 &$ÿ
`ÿ 

 +ÿ 
`ÿÿÿ
`ÿ

ÿ
`

 ÿ"ÿÿ !#ÿ
`


`$ÿ
` ÿÿ

ÿ
`ÿÿÿ

%ÿÿ  ÿÿ
`

 ÿ
`ÿÿÿ 

 ÿÿ,ÿ%
`


`
`ÿÿÿ !#ÿ!

ÿÿ ÿÿÿÿÿ 
`

$ÿ% 

ÿ ÿ
`ÿÿÿ%

ÿÿÿ !#ÿ
`


`
`ÿÿÿ
`

ÿ
`
`

 ÿ

ÿÿ ÿ ÿÿÿÿ 
`

ÿ
`
`ÿÿÿ
`!ÿ
`
`

ÿÿÿ
` ÿ
`ÿ
`ÿ

ÿ ÿ ÿ ÿ"ÿ
`ÿÿÿ 

 ÿÿ!

ÿ

ÿ!
`ÿ
`

 ÿÿ-$ÿ
`

ÿ
`
`

 ÿ


`ÿÿÿ%
`


`ÿÿÿ
`



ÿ
` ÿ
`ÿÿ
`ÿ 

 ÿ
`ÿ!

ÿ"
`ÿÿÿ   ÿÿÿ !#ÿ ÿ%
`

ÿÿÿ
`

ÿ
`ÿ




`ÿÿÿ%ÿÿ ÿ
`ÿ
` ÿ
`ÿ%ÿÿ 

 ÿ
`ÿÿ ÿ 
`ÿÿÿ%
`  ÿ ÿ
`ÿÿ
`

ÿ
`
`

 ÿ
`ÿ
`ÿ"ÿ
`ÿÿ 


`ÿÿÿÿ
`



ÿ
` ÿ ÿ
`ÿÿ
`ÿ !ÿ 

 ÿ"

ÿ%
`  
`ÿÿÿ   ÿÿ
`ÿ !#ÿ!ÿ ÿ
`ÿ
`ÿ

 ÿ
` 
`ÿÿÿ
`ÿ

ÿ

ÿ

%
` ÿÿ 
`

ÿÿ! ÿÿ 

 ÿ
`ÿ


`ÿÿÿ
` 
`ÿ
`
`

 ÿ
`!ÿÿÿ"ÿÿÿ



`ÿÿ.% 
`ÿÿÿ% ÿÿ
` 
`ÿ  



ÿÿ!

ÿ ÿ
`ÿ

`ÿÿÿ 

  ÿ!ÿ'ÿ!
`ÿ
` *ÿ

ÿ

ÿ


`"ÿÿ
`
`
`ÿÿÿ ÿ
`ÿ
`

  ÿ

ÿÿÿÿ 
`


`ÿÿÿ-ÿ
`ÿÿÿ
`ÿ

ÿ"
`ÿ ÿÿ
`ÿÿ/00-ÿ
`$
`ÿÿÿÿ
`%ÿÿ/00-ÿ
`ÿ
` ÿ"
`

ÿ 

"ÿ
`ÿ%
`ÿÿ
`ÿÿÿ/00-ÿ%



`

 ÿ1$ÿ2ÿ
` ÿÿ
`!ÿ

%
`"



ÿÿ(




`ÿÿÿ/00-ÿ 

 ÿ!

ÿÿÿÿ3

ÿ/00-ÿ
`ÿ
` ÿ



`
`ÿÿÿÿ  

ÿÿ
`

ÿ
`ÿÿÿ ÿ
` ÿ%

`ÿ !#
`ÿÿÿ 
`ÿ
` ÿÿ ÿ45
`ÿÿÿ-

ÿ  ÿ%
`ÿÿÿ% ÿ%



`

 ÿ
`ÿ
`%%
`ÿ

`ÿÿÿ 45ÿÿ,ÿ !ÿÿ
`ÿ%$ÿ 6 0$ÿ
`ÿ" ÿ
`7ÿ
`ÿÿÿ 

 ÿ5$ÿ5ÿ
` ÿ55ÿÿ
`

ÿÿ-ÿ 
`

ÿ 
`

ÿ
`ÿÿÿ

 



ÿÿ 

 ÿÿÿÿ
`ÿ" ÿ( ÿÿ


`ÿÿÿ& &ÿ 
`ÿ
`ÿ

ÿ

ÿ 

 ÿ5ÿ
` ÿ5ÿÿ-ÿ


`ÿÿÿ
`ÿ

ÿ



 ÿ
`ÿ" ÿÿÿ

`$ÿ
` ÿ



`
`ÿÿÿ 
` ÿ
`ÿ" ÿ
`ÿÿ 
`

ÿÿ(ÿ
`ÿ
`ÿÿÿ(%

 
`ÿÿÿ
`

ÿ

ÿÿ

%
`"



ÿ
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ8
` 
`ÿ-
` #ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ1
`ÿ2
`
`Droms
`
`Standards Track
`
`[Page 3]
`
`Page 3 of 45
`
`Page 3 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`1.2 Related Work
`
`There are several Internet protocols and related mechanisms that
`address some parts of the dynamic host configuration problem.
`The
`Reverse Address Resolution Protocol
`(RARP)
`[10]
`(through the
`extensions defined in the Dynamic RARP (DRARP)
`[5]) explicitly
`addresses the problem of network address discovery, and includes an
`automatic IP address assignment mechanism.
`The Trivial File Transfer
`Protocol
`(TFTP)
`[20] provides for transport of a boot image from a
`boot server.
`The Internet Control Message Protocol
`(ICMP)
`[16]
`provides for informing hosts of additional routers via "ICMP
`redirect" messages.
`ICMP also can provide subnet mask information
`through the "ICMP mask request" message and other information through
`the (obsolete)
`"ICMP information request" message. Hosts can locate
`routers through the ICMP router discovery mechanism [8].
`
`BOOTP is a transport mechanism for a collection of configuration
`information.
`BOOTP is also extensible, and official extensions [17]
`have been defined for several configuration parameters. Morgan has
`proposed extensions to BOOTP for dynamic IP address assignment
`[15].
`The Network Information Protocol
`(NIP), used by the Athena project at
`MIT,
`is a distributed mechanism for dynamic IP address assignment
`[19].
`The Resource Location Protocol RLP [1] provides for location
`of higher level services.
`Sun Microsystems diskless workstations use
`a boot procedure that employs RARP, TFTP and an RPC mechanism called
`“bootparams" to deliver configuration information and operating
`system code to diskless hosts.
`(Sun Microsystems, Sun Workstation
`and SunOS are trademarks of Sun Microsystems, Inc.)
`Some Sun
`networks also use DRARP and an auto-installation mechanism to
`automate the configuration of new hosts in an existing network.
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿ
`ÿ
`ÿÿÿ!ÿ
`ÿ"
`ÿ#  ÿ$ ÿ
` ÿ
`ÿ 
`

ÿ
`
`ÿÿÿ
`ÿÿ$
`ÿÿÿ
`

ÿÿ  


`

 ÿ$%ÿÿ!
`ÿÿÿ"ÿ&ÿ

 ÿ ÿ'&(ÿ)*+ÿ'ÿ
`ÿÿÿ, 

 ÿ

ÿ

ÿÿ
`

ÿ&ÿ'&(ÿ)-+(ÿ,$


`ÿÿÿ
`ÿÿ$%ÿÿ . ÿ
`ÿ

 "/ÿ
` ÿ

ÿ
`
`ÿÿÿ
`
`

ÿ#ÿ
`ÿ
`

  ÿ 
`

ÿÿ!ÿ!

"

`ÿ

ÿ!
` 
`ÿÿÿ ÿ'! !(ÿ)*+ÿ$"

ÿÿ
` $ÿÿ
`ÿ%ÿ


`ÿÿ
`
`ÿÿÿ%ÿ"ÿÿ!ÿ#  ÿ ÿ
`ÿ ÿ'#(ÿ)0+
`ÿÿÿ$"

ÿÿ



ÿÿÿ
`




`ÿÿ"

`ÿ1#
`ÿÿÿ

 1ÿ
`ÿÿ#ÿ
`ÿ
` ÿ$"

ÿ% ÿ
` ÿ


`


`ÿÿÿÿÿ1#ÿ
` ÿ21ÿ
`ÿ
` ÿÿ


`

 ÿ
`ÿÿÿÿ'%(ÿ1#ÿ


`

 ÿ21ÿ
`ÿÿÿ
` ÿ
`
`ÿÿÿÿÿÿ#ÿÿ

 "ÿ 
`

ÿ)3+
`ÿÿÿ455!ÿ

ÿ
`ÿ
` $ÿ 
`

ÿÿ
`ÿ  

 ÿÿ  


`


`ÿÿÿ


`

 ÿÿ455!ÿ

ÿ
`ÿ, 

%/ÿ
` ÿ

`ÿ, 

 ÿ)+
`ÿÿÿ
`"ÿ% ÿ

ÿÿ"
`ÿ  


`

 ÿ$
`
`ÿÿ
` ÿ
`
`ÿÿÿ$$ÿ, 

 ÿÿ455!ÿÿ
`

ÿ#ÿ
`ÿ
`

  ÿ)-+
`ÿÿÿ!ÿ6. ÿ# 
`

 ÿ ÿ'6#(/ÿÿ%ÿÿ&
`ÿ$7 ÿ
`
`ÿÿÿ#!/ÿ

ÿ
`ÿ



%ÿ 
`

ÿÿ
`

ÿ#ÿ
`ÿ
`

  
`ÿÿÿ)+ÿÿ!ÿ ÿ8
`

 ÿ ÿ8ÿ)+ÿ$"

ÿÿ
`


`ÿÿÿÿ

ÿ"ÿ"

ÿÿ9 ÿ

ÿ

 ÿ. 
`

 ÿ
`ÿÿÿ
`ÿ%ÿ$ ÿ
`ÿ$ÿ&/ÿ! !ÿ
` ÿ
` ÿÿ 
`

ÿ
`
`ÿÿÿ1%$
`
`1ÿÿ

"ÿ  


`

 ÿ


`

 ÿ
` ÿ$
`


`ÿÿÿÿ ÿÿ

 ÿÿÿ'9 ÿ

/ÿ9 ÿ 
`


`ÿÿÿ
` ÿ9 59ÿ
`ÿ
`
` ÿÿ9 ÿ

/ÿ# (ÿÿ9ÿ9
`ÿÿÿ . ÿ
`ÿÿ&ÿ
` ÿ
` ÿ
`:


`
`

 ÿ 
`

ÿ
`ÿÿÿ
`
`ÿÿ  


`

 ÿÿ .ÿÿ

ÿ
` ÿ,



ÿ . 
`ÿÿÿ# ÿÿ
`ÿ. /ÿÿ$
`ÿ

ÿ
` 



 ÿ

ÿ'!;(
`ÿÿÿ

 "ÿ
`

ÿ
` ÿ

ÿÿ!;ÿÿ
` ÿ
`%


`ÿ

 
`ÿÿÿ$
`ÿ)<+ÿÿ!ÿ&ÿ

 ÿ ÿ'&(ÿ
`ÿ% ÿ$$
`ÿÿÿ
`ÿ
`ÿ
` $ÿ$ ÿÿ ÿ
`

 ÿ
` ÿ 

 ÿ)0+
`ÿÿÿ

`/ÿÿÿ2

 ÿ ÿ)/ÿ<+ÿ 

 ÿ$



`ÿÿÿ2

 ÿÿÿ  


`

 ÿ
` ÿÿ
`ÿ 
`

ÿ
`ÿÿÿ



`ÿ  


`

 ÿÿ

 ÿ
`ÿ%ÿ



 ÿ
` ÿ


`ÿÿÿÿ

ÿ

 ÿÿ$$ÿÿ 

 ÿ.

ÿÿ  


`


`ÿÿÿ$
`
`ÿ

ÿ

ÿÿÿ2

 ÿ ÿÿ&ÿ%
`


`ÿÿÿ$
`
`ÿ"

`ÿ/ÿ
`ÿÿ 

 ÿÿ%ÿ
`%ÿÿ, 
` ÿ$
` 
`ÿÿÿ.

ÿ
` ÿÿÿ

ÿÿ#  ÿÿ!ÿ!=#ÿ
` ÿ$
`
`
`ÿÿÿ$$

ÿ%ÿÿ
`ÿ

ÿ

ÿ&$$ 

,ÿ&
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ9
` 
`ÿ!
` ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ)
`ÿ<+
`
`(MTU)
`the path minimum transmission unit
`In other related work,
`discovery algorithm can determine the MTU of an arbitrary internet
`path [14].
`The Address Resolution Protocol
`(ARP) has been proposed
`as a transport protocol for resource location and selection [6].
`Finally,
`the Host Requirements RFCs
`[3, 4] mention specific
`requirements for host reconfiguration and suggest a scenario for
`initial configuration of diskless hosts.
`
`1.3 Problem definition and issues
`
`DHCP is designed to supply DHCP clients with the configuration
`parameters defined in the Host Requirements RFCs. After obtaining
`parameters via DHCP, a DHCP client should be able to exchange packets
`with any other host in the Internet.
`The TCP/IP stack parameters
`supplied by DHCP are listed in Appendix A.
`
`Droms
`
`Standards Track
`
`[Page 4]
`
`Page 4 of 45
`
`Page 4 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`Not all of these parameters are required for a newly initialized
`client.
`A client and server may negotiate for the transmission of
`only those parameters required by the client or specific to a
`particular subnet.
`
`DHCP allows but does not require the configuration of client
`parameters not directly related to the IP protocol.
`DHCP also does
`not address registration of newly configured clients with the Domain
`Name System (DNS)
`[12, 13].
`
`DHCP is not intended for use in configuring routers.
`
`1.4 Requirements
`
`the words that are used to define the
`Throughout this document,
`significance of particular requirements are capitalized. These words
`are:
`
`o "MUST"
`
`This word or the adjective "REQUIRED" means that the
`item is an absolute requirement of this specification.
`
`o "MUST NOT"
`
`This phrase means that the item is an absolute prohibition
`of this specification.
`
`o "SHOULD"
`
`This word or the adjective "RECOMMENDED" means that there
`may exist valid reasons in particular circumstances to ignore
`this item, but the full implications should be understood and
`the case carefully weighed before choosing a different course.
`
`o "SHOULD NOT"
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿÿÿÿ
`ÿÿÿ
`
`ÿ
`ÿ

 ÿÿ
`ÿ !ÿ



`

"
`ÿÿÿ 

 #ÿÿ$ÿ 

 ÿ
` ÿ%ÿ
`ÿ 

`ÿÿÿ
` 



 ÿ
`ÿÿÿ ÿÿ
`
`ÿ

 ÿ&ÿÿ 

 ÿÿ



ÿÿ
`
`ÿÿÿ
`


`ÿ& #
`ÿÿÿÿ
`!ÿ&ÿ ÿ ÿ

ÿÿ  


`

 ÿÿ 

 
`ÿÿÿ
`
`ÿ ÿ

 ÿ
` ÿÿÿ'ÿ #ÿÿÿ
`ÿ 
`ÿÿÿ ÿ
` ÿ


`

 ÿÿ !ÿ  

 ÿ 

 ÿ!

ÿÿ
`

`ÿÿÿ
`ÿ(ÿ)(*ÿ+,ÿ-#
`ÿÿÿÿ

ÿ ÿ

  ÿÿÿ

ÿ  



ÿ#
`#.ÿ

 
`ÿÿÿ/ÿ

ÿ   ,ÿÿ! ÿ
`ÿ
`ÿ ÿÿ 

ÿ
`ÿÿÿ





` ÿÿ
`


`ÿ

 ÿ
`ÿ
`


`

" #ÿÿ/ÿ! 
`ÿÿÿ
`0
`ÿÿÿÿÿÿÿ12(/1
`ÿÿÿÿÿÿÿÿ/

ÿ! ÿÿÿ
` 3 

%ÿ1452'41ÿ
` ÿ
`ÿ
`ÿÿÿÿÿÿÿÿ

ÿ

ÿ
` ÿ
`&ÿ

 ÿÿ

ÿ



`

 #
`ÿÿÿÿÿÿÿ12(/ÿ6/1
`ÿÿÿÿÿÿÿÿ/

ÿ
`ÿ
` ÿ
`ÿÿ

ÿ

ÿ
` ÿ
`&ÿ

&




`ÿÿÿÿÿÿÿÿÿ

ÿ



`

 #
`ÿÿÿÿÿÿÿ1(6271
`ÿÿÿÿÿÿÿÿ/

ÿ! ÿÿÿ
` 3 

%ÿ146441ÿ
` ÿ
`ÿ
`ÿÿÿÿÿÿÿÿ
`ÿ8

ÿ%
`

ÿ
` ÿ

ÿ
`


`ÿ

 
` ÿÿ

 
`ÿÿÿÿÿÿÿÿ

ÿ

,ÿ&ÿÿÿ



`

 ÿ ÿ&ÿ  ÿ
`
`ÿÿÿÿÿÿÿÿÿ
`ÿ
`ÿ!

 ÿ&ÿ 

ÿ
`ÿ

 ÿ #
`ÿÿÿÿÿÿÿ1(627ÿ6/1
`ÿÿÿÿÿÿÿÿ/

ÿ
`ÿ
` ÿ
`ÿÿ
`ÿ8

ÿ%
`

ÿ
` ÿ

`ÿÿÿÿÿÿÿÿ
`


`ÿ

 
` ÿ! ÿÿ

 ÿ&
`%

ÿ

ÿ
` 
`&
`ÿÿÿÿÿÿÿÿÿ% ÿ,ÿ&ÿÿÿ



`

 ÿ ÿ&ÿ 
`ÿÿÿÿÿÿÿÿ
` ÿÿ
`ÿ
`ÿ!

 ÿ&ÿ

 

ÿ
` ÿ&
`%


`ÿÿÿÿÿÿÿÿ  

& ÿ!

ÿ

ÿ
`&#
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ(
`
` ÿ/
` 9ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ+
`ÿ:-
`
`This phrase means that there may exist valid reasons in
`particular circumstances when the listed behavior is acceptable
`or even useful, but the full implications should be understood
`and the case carefully weighed before implementing any behavior
`described with this label.
`
`Droms
`
`Standards Track
`
`[Page 5]
`
`Page 5 of 45
`
`Page 5 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`o "MAY"
`
`This word or the adjective "OPTIONAL" means that this item is
`truly optional.
`One vendor may choose to include the item
`because a particular marketplace requires it or because it
`enhances the product, for example; another vendor may omit the
`same item.
`
`1.5 Terminology
`
`This document uses the following terms:
`
`o "DHCP client"
`
`A DHCP client is an Internet host using DHCP to obtain
`configuration parameters such as a network address.
`
`o "DHCP server"
`
`A DHCP server is an Internet host that returns configuration
`parameters to DHCP clients.
`
`o "BOOTP relay agent"
`
`A BOOTP relay agent or relay agent is an Internet host or router
`that passes DHCP messages between DHCP clients and DHCP servers.
`DHCP is designed to use the same relay agent behavior as specified
`in the BOOTP protocol specification.
`
`o "binding"
`
`including
`A binding is a collection of configuration parameters,
`at least an IP address, associated with or "bound to" a DHCP
`client. Bindings are managed by DHCP servers.
`
`1.6 Design goals
`
`The following list gives general design goals for DHCP.
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿÿÿÿÿÿÿ
`ÿÿÿÿÿÿÿÿ

ÿ !ÿÿ"ÿ
`!#" 

$"ÿ%&%'(ÿ"
` ÿ
`ÿ

ÿ

"ÿ


`ÿÿÿÿÿÿÿÿÿ)


`*ÿÿ% "ÿ$" !ÿ
`ÿ "ÿÿ

!"ÿ"ÿ

"
`ÿÿÿÿÿÿÿÿ+"
`"ÿ
`ÿ)
`


`ÿ
`,")
` "ÿ"-

"ÿ

ÿÿ+"
`"ÿ


`ÿÿÿÿÿÿÿÿ" 
` "ÿ"ÿ)! .ÿÿ"/
`)"0ÿ
` "ÿ$" !ÿ
`ÿ

ÿ"
`ÿÿÿÿÿÿÿÿ
`"ÿ

"*
`*1ÿ"


`ÿÿÿ

ÿ! " ÿ"ÿ"ÿ

ÿ"2
`ÿÿÿÿÿÿÿÿ 

" 
`ÿÿÿÿÿÿÿÿ 

" ÿ

ÿ
` ÿ& " "ÿÿ

ÿÿÿ+
`

`ÿÿÿÿÿÿ  


`

 ÿ)
`
`""ÿ ÿ
`ÿ
`ÿ " ,ÿ
`!!"*
`ÿÿÿÿÿÿÿÿ"$"
`ÿÿÿÿÿÿÿÿ"$"ÿ

ÿ
` ÿ& " "ÿÿ
`ÿ" ÿ  


`


`ÿÿÿÿÿÿ)
`
`""ÿÿÿ 

" *
`ÿÿÿÿÿÿÿ3%%ÿ"
`ÿ
`" 
`ÿÿÿÿÿÿÿ3%%ÿ"
`ÿ
`" ÿÿ"
`ÿ
`" ÿ

ÿ
` ÿ& " "ÿÿÿ"
`ÿÿÿÿÿÿ
`ÿ)
`"ÿÿ"
`"ÿ+" "" ÿÿ 

" ÿ
` !ÿÿ"$"*
`ÿÿÿÿÿÿÿ

ÿ!"

 "!ÿÿ"ÿ"ÿ
`"ÿ"
`ÿ
`" ÿ+"
`$

ÿ
`ÿ)"



"!
`ÿÿÿÿÿÿ

ÿ"ÿ3%%ÿ) ÿ)"



`

 *
`ÿÿÿÿÿÿÿ+

!


`ÿÿÿÿÿÿÿ+

!

ÿ

ÿ
`ÿ " 

 ÿÿ  


`

 ÿ)
`
`"".ÿ

!


`ÿÿÿÿÿÿ
`ÿ"
`ÿ
` ÿ&ÿ
`!!".ÿ
`

`"!ÿ

ÿÿ+ !ÿÿ
`ÿ
`ÿÿÿÿÿÿ 

" *ÿÿ3

!

ÿ
`"ÿ
`
`"!ÿ+ÿÿ"$"*
`*4ÿ"

 ÿ
`
`ÿÿÿ"ÿ

ÿ

ÿ

$"ÿ" "
`ÿ!"

 ÿ
`ÿÿ*
`ÿÿÿÿÿÿÿÿ!ÿ+"ÿ
`ÿ" 
`

ÿ
`"ÿ
` ÿ
`ÿ)

*ÿÿÿ
`ÿÿÿÿÿÿÿÿ
` ÿ
`ÿ"ÿ
`!


`ÿ  ÿ$"ÿ  


`


`ÿÿÿÿÿÿÿÿ)
`
`""ÿ ""ÿ!"

"!0ÿ"**.ÿ
`ÿ"ÿ
`!


`
`ÿÿÿÿÿÿÿÿ!ÿ+"ÿ
`+"ÿÿ"  "ÿ
`ÿ)

"ÿ  "

ÿ
`
`


`ÿÿÿÿÿÿÿÿ
` !ÿ
` "ÿÿ
`ÿ" "ÿ ""ÿ!"

"!*
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ5
` !
`!ÿ
` ,ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ6
`"ÿ47
`
`DHCP must
`o DHCP should be a mechanism rather than a policy.
`allow local system administrators control over configuration
`parameters where desired; e.g.,
`local system administrators
`should be able to enforce local policies concerning allocation
`and access to local resources where desired.
`
`Standards Track
`
`[Page 6]
`
`Page 6 of 45
`
`Page 6 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`Each client
`o Clients should require no manual configuration.
`should be able to discover appropriate local configuration
`parameters without user intervention and incorporate those
`parameters into its own configuration.
`
`o Networks should require no manual configuration for individual
`clients. Under normal circumstances,
`the network manager
`should not have to enter any per-client configuration
`parameters.
`
`To allow for
`o DHCP should not require a server on each subnet.
`scale and economy, DHCP must work across routers or through the
`intervention of BOOTP relay agents.
`
`o DHCP must coexist with statically configured, non-participating
`hosts and with existing network protocol implementations.
`
`o DHCP must interoperate with the BOOTP relay agent behavior as
`described by RFC 951 and by RFC 1542 [21].
`
`o DHCP must provide service to existing BOOTP clients.
`
`The following list gives design goals specific to the transmission of
`the network layer parameters.
`DHCP must:
`
`o Guarantee that any specific network address will not be in
`use by more than one DHCP client at a time,
`
`o Retain DHCP client configuration across DHCP client reboot.
`DHCP client should, whenever possible, be assigned the same
`configuration parameters (e.g., network address)
`in response
`to each request,
`
`A
`
`o Retain DHCP client configuration across server reboots, and,
`whenever possible, a DHCP client should be assigned the same
`configuration parameters despite restarts of the DHCP mechanism,
`
`o Allow automated assignment of configuration parameters to new
`clients to avoid hand configuration for new clients,
`
`o Support fixed or permanent allocation of configuration
`parameters to specific clients.
`
`o A DHCP client must be prepared to receive multiple responses
`to a request for configuration parameters.
`Some installations
`may include multiple, overlapping DHCP servers to enhance
`reliability and increase performance.
`
` ÿÿÿÿÿÿÿÿÿÿÿ
`

ÿÿ 


`

 ÿ ÿÿÿÿÿÿÿÿÿ
` ÿ
`ÿÿÿÿÿÿÿ

 ÿÿ

ÿ ÿ
` 
`ÿ  


`

 ÿÿ
` ÿ 

 
`ÿÿÿÿÿÿÿÿÿ!ÿ
`!ÿÿ

 "ÿ
`###

`ÿ
`ÿ  


`


`ÿÿÿÿÿÿÿÿ#
`
`ÿ$

ÿÿ

" 

 ÿ
` ÿ

#
`ÿ
`ÿÿÿÿÿÿÿÿ#
`
`ÿ

ÿ

ÿ$ ÿ  


`

 
`ÿÿÿÿÿÿÿ%$&ÿÿ

ÿ ÿ
` 
`ÿ  


`

 ÿÿ



"


`
`ÿÿÿÿÿÿÿÿ 

 ÿÿ' ÿ 
`ÿ

 
` (ÿÿ $&ÿ
`
`
`ÿÿÿÿÿÿÿÿÿ ÿ
`"ÿÿ ÿ
` ÿ#) 

 ÿ  


`


`ÿÿÿÿÿÿÿÿ#
`
`
`ÿÿÿÿÿÿÿÿÿ ÿ

ÿ
`ÿ"ÿ ÿ
` ÿ! ÿÿ*ÿ
`$ÿ
`ÿÿÿÿÿÿÿÿ
`ÿ
` ÿ  (ÿÿÿ$&ÿ
` ÿÿÿÿ
`ÿÿÿÿÿÿÿÿ

" 

 ÿÿ+,,*ÿ
`ÿ
` 
`ÿÿÿÿÿÿÿ-ÿÿ 

 ÿÿ!ÿ##
`ÿÿ 

"ÿ

#ÿ# 
`ÿÿÿÿÿÿÿÿÿ
`ÿÿÿ  


`

 ÿ#
`
`ÿÿ.ÿ


`
`

 
`ÿÿÿÿÿÿÿÿ
`ÿ

ÿ

#(ÿ"
`##

ÿÿ"ÿÿ 
` 
`ÿÿÿÿÿÿÿÿ

`!



ÿ
` ÿ


`ÿ#
` 
`ÿÿÿÿÿÿÿÿÿ /

ÿ$

ÿ
`

`ÿ  

(ÿ  )#
`

#
`


`ÿÿÿÿÿÿÿÿÿ
` ÿ$

ÿ/



ÿ $&ÿ# ÿ

# 
`

 
`ÿÿÿÿÿÿÿÿÿ

#
`ÿ$

ÿÿ+,,*ÿ
`ÿ
` ÿ!
`"

ÿ
`
`ÿÿÿÿÿÿÿÿ 

!ÿ!ÿ ÿ0ÿ
` ÿ!ÿ ÿ01ÿ23
`ÿÿÿÿÿÿÿÿÿ#"

ÿ"

ÿÿ/



ÿ+,,*ÿ 

 
`ÿÿÿ*ÿ$

ÿ

ÿ

"ÿ

 ÿ
`ÿ#



ÿÿÿ
` 



 ÿ
`ÿÿÿÿ $&ÿ
`ÿ#
`
`ÿÿÿ4
`ÿÿÿÿÿÿÿ5
`
` ÿ
`ÿ
` ÿ#



ÿ $&ÿ
`ÿ$

ÿ ÿ!ÿ

`ÿÿÿÿÿÿÿÿÿ!ÿÿ
` ÿ ÿÿ 

 ÿ
`ÿ
`ÿ

(
`ÿÿÿÿÿÿÿ
`

ÿÿ 

 ÿ  


`

 ÿ
` ÿÿ 

 ÿ!ÿÿ-
`ÿÿÿÿÿÿÿÿÿ 

 ÿ(ÿ$ "ÿ#

!(ÿ!ÿ
`

 ÿÿ
`
`ÿÿÿÿÿÿÿÿ  


`

 ÿ#
`
`ÿ6(ÿ $&ÿ
`7ÿ

ÿ# 
`ÿÿÿÿÿÿÿÿÿ
` ÿ(
`ÿÿÿÿÿÿÿ
`

ÿÿ 

 ÿ  


`

 ÿ
` ÿ"ÿ!(ÿ
` (
`ÿÿÿÿÿÿÿÿ$ "ÿ#

!(ÿ
`ÿÿ 

 ÿÿ!ÿ
`

 ÿÿ
`
`ÿÿÿÿÿÿÿÿ  


`

 ÿ#
`
`ÿ#

ÿ
`ÿÿÿÿ 
`

(
`ÿÿÿÿÿÿÿ-$ÿ
`
`ÿ
`

  ÿÿ  


`

 ÿ#
`
`ÿÿ $
`ÿÿÿÿÿÿÿÿ 

 ÿÿ
`"

ÿ
` ÿ  


`

 ÿÿ $ÿ 

 (
`ÿÿÿÿÿÿÿ.##ÿ

/ÿÿ#
`  ÿ
`
`

 ÿÿ  


`


`ÿÿÿÿÿÿÿÿ#
`
`ÿÿ#



ÿ 

 
`ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ.
` 
`ÿ*
` &ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ2
`ÿ3
`
`Droms
`
`Standards Track
`
`[Page 7]
`
`Page 7 of 45
`
`Page 7 of 45
`
`

`

`RFC 2131
`
`Dynamic Host Configuration Protocol
`
`March 1997
`
`Protocol Summary
`
`Figure 1 gives the format of a DHCP message and table 1 describes
`each of the fields in the DHCP message.
`The numbers in parentheses
`indicate the size of each field in octets.
`The names for the fields
`given in the figure will be used throughout this document to refer to
`the fields in DHCP messages.
`
`There are two primary differences between DHCP and BOOTP. First,
`DHCP defines mechanisms through which clients can be assigned a
`network address for a f