RFC2131 日本語訳
2131 Dynamic Host Configuration Protocol. R. Droms. March 1997. (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396, RFC4361) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Droms Request for Comments: 2131 Bucknell University Obsoletes: 1541 March 1997 Category: Standards Track
Network Working Group R. Droms Request for Comments: 2131 Bucknell University Obsoletes: 1541 March 1997 Category: Standards Track
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol
Status of this memo
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.
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
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework 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].
The Dynamic Host Configuration Protocol (DHCP) provides a framework 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
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Configuration parameters repository . . . . . . . . . . . . . 11
2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
3.1 Client-server interaction - allocating a network address. . . 13
3.2 Client-server interaction - reusing a previously allocated
network address . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Interpretation and representation of time values. . . . . . . 20
3.4 Obtaining parameters with externally configured network
address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
4. Specification of the DHCP client-server protocol. . . . . . . 22
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Configuration parameters repository . . . . . . . . . . . . . 11 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13 3.1 Client-server interaction - allocating a network address. . . 13 3.2 Client-server interaction - reusing a previously allocated network address . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Interpretation and representation of time values. . . . . . . 20 3.4 Obtaining parameters with externally configured network address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22 4. Specification of the DHCP client-server protocol. . . . . . . 22
Droms Standards Track [Page 1] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 1] 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. . . . . . . . . . . . . . . . . . . . . 26
4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
List of Figures
1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
3. Timeline diagram of messages exchanged between DHCP client and
servers when allocating a new network address. . . . . . . . . 15
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. . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
4. Client messages from various states. . . . . . . . . . . . . . 33
5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44 A. Host Configuration Parameters . . . . . . . . . . . . . . . .45 List of Figures 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11 3. Timeline diagram of messages exchanged between DHCP client and servers when allocating a new network address. . . . . . . . . 15 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. . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28 4. Client messages from various states. . . . . . . . . . . . . . 33 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
1. Introduction
1. Introduction
The Dynamic Host Configuration Protocol (DHCP) provides configuration 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.
The Dynamic Host Configuration Protocol (DHCP) provides configuration 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.
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.
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
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
Droms Standards Track [Page 2] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 2] RFC 2131 Dynamic Host Configuration Protocol March 1997
mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.
mechanism for discovery of addresses that are already in use. IP hosts may not always be able to defend their network addresses, so that such a distributed address allocation scheme cannot be guaranteed to avoid allocation of duplicate network addresses.
DHCP supports three mechanisms for IP address allocation. In "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.
DHCP supports three mechanisms for IP address allocation. In "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.
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.
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.
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.
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
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.
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.
Droms Standards Track [Page 3] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 3] RFC 2131 Dynamic Host Configuration Protocol March 1997
1.2 Related Work
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].
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.
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.
In other related work, the path minimum transmission unit (MTU) 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.
In other related work, the path minimum transmission unit (MTU) 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
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.
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] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 4] 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.
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 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.
DHCP is not intended for use in configuring routers.
1.4 Requirements
1.4 Requirements
Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are:
Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are:
o "MUST"
o "MUST"
This word or the adjective "REQUIRED" means that the
item is an absolute requirement of this specification.
This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification.
o "MUST NOT"
o "MUST NOT"
This phrase means that the item is an absolute prohibition
of this specification.
This phrase means that the item is an absolute prohibition of this specification.
o "SHOULD"
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.
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"
o "SHOULD NOT"
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.
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] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 5] RFC 2131 Dynamic Host Configuration Protocol March 1997
o "MAY"
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.
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
1.5 Terminology
This document uses the following terms:
This document uses the following terms:
o "DHCP client"
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address.
o "DHCP server"
o "DHCP server"
A DHCP server is an Internet host that returns configuration
parameters to DHCP clients.
A DHCP server is an Internet host that returns configuration parameters to DHCP clients.
o "BOOTP relay agent"
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.
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"
o "binding"
A binding is a collection of configuration parameters, including
at least an IP address, associated with or "bound to" a DHCP
client. Bindings are managed by DHCP servers.
A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers.
1.6 Design goals
1.6 Design goals
The following list gives general design goals for DHCP.
The following list gives general design goals for DHCP.
o DHCP should be a mechanism rather than a policy. DHCP must
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.
o DHCP should be a mechanism rather than a policy. DHCP must 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.
Droms Standards Track [Page 6] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 6] RFC 2131 Dynamic Host Configuration Protocol March 1997
o Clients should require no manual configuration. Each client
should be able to discover appropriate local configuration
parameters without user intervention and incorporate those
parameters into its own configuration.
o Clients should require no manual configuration. Each client 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.
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.
o DHCP should not require a server on each subnet. To allow for
scale and economy, DHCP must work across routers or through the
intervention of BOOTP relay agents.
o DHCP should not require a server on each subnet. To allow for scale and economy, DHCP must work across routers or through the intervention of BOOTP relay agents.
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.
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.
o DHCP must coexist with statically configured, non-participating
hosts and with existing network protocol implementations.
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 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.
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:
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 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. A
DHCP client should, whenever possible, be assigned the same
configuration parameters (e.g., network address) in response
to each request,
o Retain DHCP client configuration across DHCP client reboot. A DHCP client should, whenever possible, be assigned the same configuration parameters (e.g., network address) in response to each request,
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 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 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 Support fixed or permanent allocation of configuration parameters to specific clients.
Droms Standards Track [Page 7] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 7] RFC 2131 Dynamic Host Configuration Protocol March 1997
2. Protocol Summary
2. Protocol Summary
From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. RFC 1542 [2] details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4.
From the client's point of view, DHCP is an extension of the BOOTP mechanism. This behavior allows existing BOOTP clients to interoperate with DHCP servers without requiring any change to the clients' initialization software. RFC 1542 [2] details the interactions between BOOTP and DHCP clients and servers [9]. There are some new, optional transactions that optimize the interaction between DHCP clients and servers that are described in sections 3 and 4.
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.
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 finite lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.
There are two primary differences between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for serial reassignment of network addresses to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate.
DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor extensions" field, which were formerly referred to as "vendor extensions," are now termed simply "options."
DHCP introduces a small change in terminology intended to clarify the meaning of one of the fields. What was the "vendor extensions" field in BOOTP has been re-named the "options" field in DHCP. Similarly, the tagged data items that were used inside the BOOTP "vendor extensions" field, which were formerly referred to as "vendor extensions," are now termed simply "options."
Droms Standards Track [Page 8] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 8] RFC 2131 Dynamic Host Configuration Protocol March 1997
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | op (1) | htype (1) | hlen (1) | hops (1) | +---------------+---------------+---------------+---------------+ | xid (4) | +-------------------------------+-------------------------------+ | secs (2) | flags (2) | +-------------------------------+-------------------------------+ | ciaddr (4) | +---------------------------------------------------------------+ | yiaddr (4) | +---------------------------------------------------------------+ | siaddr (4) | +---------------------------------------------------------------+ | giaddr (4) | +---------------------------------------------------------------+ | | | chaddr (16) | | | | | +---------------------------------------------------------------+ | | | sname (64) | +---------------------------------------------------------------+ | | | file (128) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+
Figure 1: Format of a DHCP message
Figure 1: Format of a DHCP message
DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where 'chaddr' is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The 'client identifier' is an opaque key, not to be interpreted by the server; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. The 'client identifier' chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a 'client identifier' in one message, it MUST use that same identifier in all subsequent messages, to ensure that all servers correctly identify the client.
DHCP defines a new 'client identifier' option that is used to pass an explicit client identifier to a DHCP server. This change eliminates the overloading of the 'chaddr' field in BOOTP messages, where 'chaddr' is used both as a hardware address for transmission of BOOTP reply messages and as a client identifier. The 'client identifier' is an opaque key, not to be interpreted by the server; for example, the 'client identifier' may contain a hardware address, identical to the contents of the 'chaddr' field, or it may contain another type of identifier, such as a DNS name. The 'client identifier' chosen by a DHCP client MUST be unique to that client within the subnet to which the client is attached. If the client uses a 'client identifier' in one message, it MUST use that same identifier in all subsequent messages, to ensure that all servers correctly identify the client.
Droms Standards Track [Page 9] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 9] RFC 2131 Dynamic Host Configuration Protocol March 1997
DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.
DHCP clarifies the interpretation of the 'siaddr' field as the address of the server to use in the next step of the client's bootstrap process. A DHCP server may return its own address in the 'siaddr' field, if the server is prepared to supply the next bootstrap service (e.g., delivery of an operating system executable image). A DHCP server always returns its own address in the 'server identifier' option.
FIELD OCTETS DESCRIPTION ----- ------ -----------
FIELD OCTETS DESCRIPTION ----- ------ -----------
op 1 Message op code / message type.
1 = BOOTREQUEST, 2 = BOOTREPLY
htype 1 Hardware address type, see ARP section in "Assigned
Numbers" RFC; e.g., '1' = 10mb ethernet.
hlen 1 Hardware address length (e.g. '6' for 10mb
ethernet).
hops 1 Client sets to zero, optionally used by relay agents
when booting via a relay agent.
xid 4 Transaction ID, a random number chosen by the
client, used by the client and server to associate
messages and responses between a client and a
server.
secs 2 Filled in by client, seconds elapsed since client
began address acquisition or renewal process.
flags 2 Flags (see figure 2).
ciaddr 4 Client IP address; only filled in if client is in
BOUND, RENEW or REBINDING state and can respond
to ARP requests.
yiaddr 4 'your' (client) IP address.
siaddr 4 IP address of next server to use in bootstrap;
returned in DHCPOFFER, DHCPACK by server.
giaddr 4 Relay agent IP address, used in booting via a
relay agent.
chaddr 16 Client hardware address.
sname 64 Optional server host name, null terminated string.
file 128 Boot file name, null terminated string; "generic"
name or null in DHCPDISCOVER, fully qualified
directory-path name in DHCPOFFER.
options var Optional parameters field. See the options
documents for a list of defined options.
op 1 Message op code / message type. 1 = BOOTREQUEST, 2 = BOOTREPLY htype 1 Hardware address type, see ARP section in "Assigned Numbers" RFC; e.g., '1' = 10mb ethernet. hlen 1 Hardware address length (e.g. '6' for 10mb ethernet). hops 1 Client sets to zero, optionally used by relay agents when booting via a relay agent. xid 4 Transaction ID, a random number chosen by the client, used by the client and server to associate messages and responses between a client and a server. secs 2 Filled in by client, seconds elapsed since client began address acquisition or renewal process. flags 2 Flags (see figure 2). ciaddr 4 Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. yiaddr 4 'your' (client) IP address. siaddr 4 IP address of next server to use in bootstrap; returned in DHCPOFFER, DHCPACK by server. giaddr 4 Relay agent IP address, used in booting via a relay agent. chaddr 16 Client hardware address. sname 64 Optional server host name, null terminated string. file 128 Boot file name, null terminated string; "generic" name or null in DHCPDISCOVER, fully qualified directory-path name in DHCPOFFER. options var Optional parameters field. See the options documents for a list of defined options.
Table 1: Description of fields in a DHCP message
テーブル1: DHCPメッセージにおける、分野の記述
The 'options' field is now variable length. A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP
'オプション'分野は現在可変な長さです。 DHCPクライアントは少なくとも長さの312八重奏の'オプション'分野でDHCPメッセージを受け取る用意ができていなければなりません。 この要件は、DHCPクライアントが最大576の八重奏に関するメッセージを受け取る用意ができていなければならないのを含意します、最小のIP
Droms Standards Track [Page 10] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[10ページ]。
datagram size an IP host must be prepared to accept [3]. DHCP clients may negotiate the use of larger DHCP messages through the 'maximum DHCP message size' option. The options field may be further extended into the 'file' and 'sname' fields.
[3]を受け入れるようにIPが接待するデータグラムサイズを準備しなければなりません。 DHCPクライアントは、より大きいDHCPメッセージの'最大のDHCPメッセージサイズ'オプションによる使用を交渉するかもしれません。 オプション分野はさらに'ファイル'と'sname'分野に広げられるかもしれません。
In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured.
初期の構成(クライアントのTCP/IPソフトウェアが完全に構成される前に)にDHCPを使用しているクライアントの場合では、DHCPはクライアントのTCP/IPソフトウェアの創造的な使用とRFC1122の寛容な解釈を必要とします。 TCP/IPソフトウェアSHOULDはIPアドレスが構成される前にクライアントのハードウェア・アドレスに提供されたどんなIPパケットも、IP層に受け入れて、送ります。 DHCPサーバとBOOTP中継エージェントはTCP/IPソフトウェアが構成される前にハードウェアユニキャストデータグラムを受け入れることができないクライアントへのメッセージをDHCPに提供できないかもしれません。
To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. Figure 2 gives the format of the 'flags' field.
TCP/IPソフトウェアが前のパラグラフで議論するように構成される前にIPユニキャストデータグラムを受け入れることができない何人かのクライアントの周りで働くために、DHCPは'旗'分野[21]を使用します。 一番左ビットはBROADCAST(B)旗と定義されます。 このドキュメントのセクション4.1でこの旗の意味論について議論します。 旗の分野の残っているビットは今後の使用のために予約されます。 それらをクライアントによってゼロに設定されて、サーバと中継エージェントは無視しなければなりません。 図2は'旗'分野の書式を与えます。
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B| MBZ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag
B: BROADCAST旗
MBZ: MUST BE ZERO (reserved for future use)
MBZ: ゼロでなければなりません。(今後の使用のために、予約されます)
Figure 2: Format of the 'flags' field
図2: '旗'分野の形式
2.1 Configuration parameters repository
2.1 構成パラメタ倉庫
The first service provided by DHCP is to provide persistent storage of network parameters for network clients. The model of DHCP persistent storage is that the DHCP service stores a key-value entry for each client, where the key is some unique identifier (for example, an IP subnet number and a unique identifier within the subnet) and the value contains the configuration parameters for the client.
DHCPによって提供されたファーストサービスは回路パラメータの永続的なストレージをネットワーククライアントに提供することです。 DHCPの永続的なストレージのモデルはDHCPサービスが各クライアントのためのキー値エントリーを保存するということです。(そこでは、キーが何らかのユニークな識別子(例えば、IPサブネット番号とサブネットの中のユニークな識別子)であり、値はクライアントへの設定パラメータを保管しています)。
For example, the key might be the pair (IP-subnet-number, hardware- address) (note that the "hardware-address" should be typed by the
例えば、キーが組であるかもしれない(IPサブネット番号、ハードウェアアドレス)、(「ハードウェア・アドレス」によってタイプされるべきであることに注意してください。
Droms Standards Track [Page 11] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[11ページ]。
type of hardware to accommodate possible duplication of hardware addresses resulting from bit-ordering problems in a mixed-media, bridged network) allowing for serial or concurrent reuse of a hardware address on different subnets, and for hardware addresses that may not be globally unique. Alternately, the key might be the pair (IP-subnet-number, hostname), allowing the server to assign parameters intelligently to a DHCP client that has been moved to a different subnet or has changed hardware addresses (perhaps because the network interface failed and was replaced). The protocol defines that the key will be (IP-subnet-number, hardware-address) unless the client explicitly supplies an identifier using the 'client identifier' option. A client can query the DHCP service to retrieve its configuration parameters. The client interface to the configuration parameters repository consists of protocol messages to request configuration parameters and responses from the server carrying the configuration parameters.
複雑なメディアの、そして、ブリッジしているネットワークでビットを配置する問題から生じるハードウェア・アドレスの可能な複製を収容するハードウェアのタイプ) 異なったサブネット、およびグローバルにユニークでないかもしれないハードウェア・アドレスのためのハードウェア・アドレスの連続の、または、同時発生の再利用を考慮します。 交互に、キーは組であるかもしれません(IPサブネット番号、ホスト名)、サーバが知的に異なったサブネットに動かされたか、またはハードウェア・アドレスを変えたDHCPクライアントにパラメタを割り当てるのを許容して(恐らく、ネットワーク・インターフェースは失敗して、取り替えたので)。 プロトコルはそれを定義します。クライアントが'クライアント識別子'オプションを使用することで明らかに識別子を提供しないと、キーがあるでしょう(IPサブネット番号、ハードウェア・アドレス)。 クライアントは、設定パラメータを検索するためにDHCPサービスについて質問できます。 設定パラメータ倉庫へのクライアントインタフェースは設定パラメータを運ぶサーバから設定パラメータと応答を要求するプロトコルメッセージから成ります。
2.2 Dynamic allocation of network addresses
ネットワーク・アドレスの2.2動的割当て
The second service provided by DHCP is the allocation of temporary or permanent network (IP) addresses to clients. The basic mechanism for the dynamic allocation of network addresses is simple: a client requests the use of an address for some period of time. The allocation mechanism (the collection of DHCP servers) guarantees not to reallocate that address within the requested time and attempts to return the same network address each time the client requests an address. In this document, the period over which a network address is allocated to a client is referred to as a "lease" [11]. The client may extend its lease with subsequent requests. The client may issue a message to release the address back to the server when the client no longer needs the address. The client may ask for a permanent assignment by asking for an infinite lease. Even when assigning "permanent" addresses, a server may choose to give out lengthy but non-infinite leases to allow detection of the fact that the client has been retired.
DHCPによって提供されたセカンドサービスはクライアントへの一時的であるか永久的なネットワーク(IP)アドレスの配分です。 ネットワーク・アドレスの動的割当てのための基本的機構は簡単です: クライアントはアドレスのいつかの期間の使用を要求します。 配分メカニズム(DHCPサーバの収集)は、要求された時中にアドレスをそれに再割当てして、各回同じネットワーク・アドレスにクライアント要求を返す試みにアドレスは再割当てしないのを保証します。 本書では、ネットワーク・アドレスがクライアントに割り当てられる期間は「リース」[11]と呼ばれます。 クライアントはその後の要求でリースを広げるかもしれません。 クライアントがもうアドレスを必要としないと、クライアントはアドレスをサーバにリリースして戻すメッセージを発行するかもしれません。 クライアントは、無限のリースを求めることによって、永久的な課題を求めるかもしれません。 「永久的な」アドレスを割り当てるときさえ、サーバは、クライアントが退職しているという事実の検出を許すために長い、しかし、非無限のリースを配るのを選ぶかもしれません。
In some environments it will be necessary to reassign network addresses due to exhaustion of available addresses. In such environments, the allocation mechanism will reuse addresses whose lease has expired. The server should use whatever information is available in the configuration information repository to choose an address to reuse. For example, the server may choose the least recently assigned address. As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.
いくつかの環境で、利用可能なアドレスの疲労困憊のためネットワーク・アドレスを再選任するのが必要でしょう。 そのような環境で、配分メカニズムはリースが期限が切れたアドレスを再利用するでしょう。 サーバは、再利用するアドレスを選ぶのに設定情報倉庫でどんな利用可能な情報も使用するべきです。 例えば、アドレスが最近割り当てられる場合、サーバは最も最少に選ばれるかもしれません。 一貫性チェックとして、例えば、ICMPエコー要求と共にアドレスを割り当てる前に割り当てサーバSHOULDは再利用されたアドレスを調べます、そして、クライアントSHOULDは新たに受け取られたアドレスを調べます、例えば、ARPと共に。
Droms Standards Track [Page 12] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[12ページ]。
3. The Client-Server Protocol
3. クライアント/サーバプロトコル
DHCP uses the BOOTP message format defined in RFC 951 and given in table 1 and figure 1. The 'op' field of each DHCP message sent from a client to a server contains BOOTREQUEST. BOOTREPLY is used in the 'op' field of each DHCP message sent from a server to a client.
DHCPはRFC951で定義されて、テーブル1と図1で与えられたBOOTPメッセージ・フォーマットを使用します。 発信して、サーバへのクライアントがBOOTREQUEST. BOOTREPLYを含むというそれぞれのDHCPメッセージの'オプアート'分野はサーバからクライアントに送られたそれぞれのDHCPメッセージの'オプアート'分野で使用されます。
The first four octets of the 'options' field of the DHCP message contain the (decimal) values 99, 130, 83 and 99, respectively (this is the same magic cookie as is defined in RFC 1497 [17]). The remainder of the 'options' field consists of a list of tagged parameters that are called "options". All of the "vendor extensions" listed in RFC 1497 are also DHCP options. RFC 1533 gives the complete set of options defined for use with DHCP.
DHCPメッセージの'オプション'分野の最初の4つの八重奏がそれぞれ(小数)値99、130、83、および99を含んでいます。(これはRFC1497[17])で定義される同じ魔法のクッキーです。 'オプション'分野の残りは「オプション」と呼ばれるタグ付けをされたパラメタのリストから成ります。 また、RFC1497に記載された「ベンダー拡大」のすべてがDHCPオプションです。 RFC1533はDHCPとの使用のために定義された完全なオプションを与えます。
Several options have been defined so far. One particular option - the "DHCP message type" option - must be included in every DHCP message. This option defines the "type" of the DHCP message. Additional options may be allowed, required, or not allowed, depending on the DHCP message type.
いくつかのオプションが今までのところ、定義されました。 あらゆるDHCPメッセージに1つの特定のオプション(「DHCPメッセージタイプ」オプション)を含まなければなりません。 このオプションはDHCPメッセージの「タイプ」を定義します。 DHCPメッセージタイプに頼っていて、追加オプションは、許容されていないか、必要でない、許容できません。
Throughout this document, DHCP messages that include a 'DHCP message type' option will be referred to by the type of the message; e.g., a DHCP message with 'DHCP message type' option type 1 will be referred to as a "DHCPDISCOVER" message.
このドキュメント中では、'DHCPメッセージタイプ'オプションを含んでいるDHCPメッセージがメッセージのタイプによって示されるでしょう。 例えば'DHCPメッセージタイプ'オプションタイプ1があるDHCPメッセージは"DHCPDISCOVER"メッセージと呼ばれるでしょう。
3.1 Client-server interaction - allocating a network address
3.1クライアント/サーバ相互作用--ネットワーク・アドレスを割り当てること。
The following summary of the protocol exchanges between clients and servers refers to the DHCP messages described in table 2. The timeline diagram in figure 3 shows the timing relationships in a typical client-server interaction. If the client already knows its address, some steps may be omitted; this abbreviated interaction is described in section 3.2.
クライアントとサーバの間のプロトコル交換の以下の概要はテーブル2で説明されたDHCPメッセージを示します。 3図のスケジュールダイヤグラムは典型的なクライアント/サーバ相互作用でタイミング関係を示しています。 クライアントが既にアドレスを知るなら、数ステップは省略されるかもしれません。 この簡略化された相互作用はセクション3.2で説明されます。
1. The client broadcasts a DHCPDISCOVER message on its local physical
subnet. The DHCPDISCOVER message MAY include options that suggest
values for the network address and lease duration. BOOTP relay
agents may pass the message on to DHCP servers not on the same
physical subnet.
1. クライアントは地方の物理的なサブネットに関するDHCPDISCOVERメッセージを放送します。 DHCPDISCOVERメッセージはネットワーク・アドレスとリース持続時間のために値を示すオプションを含むかもしれません。 BOOTP中継エージェントは同じどんな物理的なサブネットでもDHCPサーバにメッセージを通過しないかもしれません。
2. Each server may respond with a DHCPOFFER message that includes an
available network address in the 'yiaddr' field (and other
configuration parameters in DHCP options). Servers need not
reserve the offered network address, although the protocol will
work more efficiently if the server avoids allocating the offered
network address to another client. When allocating a new address,
servers SHOULD check that the offered network address is not
2. 各サーバは'yiaddr'分野(そして、DHCPオプションにおける他の設定パラメータ)に利用可能なネットワーク・アドレスを含んでいるDHCPOFFERメッセージで反応するかもしれません。 サーバは提供されたネットワーク・アドレスを予約する必要はありません、サーバが、提供されたネットワーク・アドレスを別のクライアントに割り当てるのを避けると、プロトコルが、より効率的に働くでしょうが。 新しいアドレスを割り当てるとき、サーバSHOULDは、提供されたネットワーク・アドレスがそうでないことをチェックします。
Droms Standards Track [Page 13] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[13ページ]。
already in use; e.g., the server may probe the offered address
with an ICMP Echo Request. Servers SHOULD be implemented so that
network administrators MAY choose to disable probes of newly
allocated addresses. The server transmits the DHCPOFFER message
to the client, using the BOOTP relay agent if necessary.
既に使用中に。 例えば、サーバはICMP Echo Requestと共に提供されたアドレスを調べるかもしれません。 サーバSHOULD、ネットワーク管理者が、新たに割り当てられたアドレスの徹底的調査を無効にするのを選ぶことができるように、実装されてください。 必要なら、BOOTP中継エージェントを使用して、サーバはDHCPOFFERメッセージをクライアントに送ります。
Message Use ------- ---
メッセージ使用------- ---
DHCPDISCOVER - Client broadcast to locate available servers.
DHCPDISCOVER--クライアントは、利用可能なサーバの場所を見つけるように放送しました。
DHCPOFFER - Server to client in response to DHCPDISCOVER with
offer of configuration parameters.
DHCPOFFER--設定パラメータの申し出があるDHCPDISCOVERに対応したクライアントへのサーバ。
DHCPREQUEST - Client message to servers either (a) requesting
offered parameters from one server and implicitly
declining offers from all others, (b) confirming
correctness of previously allocated address after,
e.g., system reboot, or (c) extending the lease on a
particular network address.
DHCPREQUEST--特定のネットワーク・アドレスでリースを広げるサーバ例えば、すべての他のものから1つのサーバからパラメタを提供している、それとなく減退している申し出を要求する(a)、以前にの正当性がアドレスを割り当てたと確認した後(b)、システムリブート、または(c)へのクライアントメッセージ。
DHCPACK - Server to client with configuration parameters,
including committed network address.
DHCPACK--遂行されたネットワーク・アドレスを含む設定パラメータをもっているクライアントへのサーバ。
DHCPNAK - Server to client indicating client's notion of network
address is incorrect (e.g., client has moved to new
subnet) or client's lease as expired
DHCPNAK--ネットワーク・アドレスに関するクライアントの概念が間違っているか(例えば、クライアントは新しいサブネットに移行しました)、またはクライアントのリースが満期であることを示すクライアントへのサーバ
DHCPDECLINE - Client to server indicating network address is already
in use.
DHCPDECLINE--ネットワーク・アドレスを示すサーバへのクライアントは既に使用中です。
DHCPRELEASE - Client to server relinquishing network address and
cancelling remaining lease.
DHCPRELEASE--ネットワーク・アドレスを放棄するサーバとリースのままで残っている取り消しへのクライアント。
DHCPINFORM - Client to server, asking only for local configuration
parameters; client already has externally configured
network address.
DHCPINFORM--サーバへのローカルの設定パラメータだけを求めるクライアント クライアントは既に外部的にネットワーク・アドレスを構成しました。
Table 2: DHCP messages
テーブル2: DHCPメッセージ
Droms Standards Track [Page 14] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[14ページ]。
Server Client Server
(not selected) (selected)
サーバClient Server(選択されません)(選択されます)
v v v
| | |
| Begins initialization |
| | |
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
| | |
Determines | Determines
configuration | configuration
| | |
|\ | ____________/ |
| \________ | /DHCPOFFER |
| DHCPOFFER\ |/ |
| \ | |
| Collects replies |
| \| |
| Selects configuration |
| | |
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
| | |
| | Commits configuration
| | |
| | _____________/|
| |/ DHCPACK |
| | |
| Initialization complete |
| | |
. . .
. . .
| | |
| Graceful shutdown |
| | |
| |\ ____________ |
| | DHCPRELEASE \|
| | |
| | Discards lease
| | |
v v v
Figure 3: Timeline diagram of messages exchanged between DHCP
client and servers when allocating a new network address
v vに対して| | | | 初期化を始めます。| | | | | _____________/|\____________ | |/DHCPDISCOVER| DHCPDISCOVER\| | | | 決定します。| 構成を決定します。| 構成| | | |\ | ____________/ | | \________ | /DHCPOFFER| | DHCPOFFER\|/ | | \ | | | 回答を集めます。| | \| | | 構成を選択します。| | | | | _____________/|\____________ | |/DHCPREQUEST| DHCPREQUEST\| | | | | | 構成を遂行します。| | | | | _____________/| | |/DHCPACK| | | | | 初期設定完全です。| | | | . . . . . . | | | | 優雅な閉鎖| | | | | |\ ____________ | | | DHCPRELEASE\| | | | | | リースを捨てます。| | | v v対図3: 新しいネットワーク・アドレスを割り当てるときDHCPクライアントとサーバの間で交換されたメッセージのスケジュールダイヤグラム
Droms Standards Track [Page 15] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[15ページ]。
3. The client receives one or more DHCPOFFER messages from one or more
servers. The client may choose to wait for multiple responses.
The client chooses one server from which to request configuration
parameters, based on the configuration parameters offered in the
DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
that MUST include the 'server identifier' option to indicate which
server it has selected, and that MAY include other options
specifying desired configuration values. The 'requested IP
address' option MUST be set to the value of 'yiaddr' in the
DHCPOFFER message from the server. This DHCPREQUEST message is
broadcast and relayed through DHCP/BOOTP relay agents. To help
ensure that any BOOTP relay agents forward the DHCPREQUEST message
to the same set of DHCP servers that received the original
DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
value in the DHCP message header's 'secs' field and be sent to the
same IP broadcast address as the original DHCPDISCOVER message.
The client times out and retransmits the DHCPDISCOVER message if
the client receives no DHCPOFFER messages.
3. クライアントは1つ以上のサーバから1つ以上のDHCPOFFERメッセージを受け取ります。 クライアントは、複数の応答を待つのを選ぶかもしれません。 クライアントは設定パラメータを要求する1つのサーバを選びます、DHCPOFFERメッセージで提供された設定パラメータに基づいて。 クライアントはそれがどのサーバを選択したかを示すために'サーバ識別子'オプションを含まなければならなくて、必要な構成値を指定する別の選択肢を含むかもしれないDHCPREQUESTメッセージを、放送します。 '要求されたIPアドレス'オプションはサーバからのDHCPOFFERメッセージの'yiaddr'の値へのセットであるに違いありません。このDHCPREQUESTメッセージは、DHCP/BOOTP中継エージェントを通して放送されて、リレーされます。 どんなBOOTP中継エージェントもオリジナルのDHCPDISCOVERメッセージを受け取った同じセットのDHCPサーバにDHCPREQUESTメッセージを転送するのを確実にするのを助けるために、DHCPREQUESTメッセージをDHCPメッセージヘッダーの'secs'分野で同じ値を使用して、オリジナルのDHCPDISCOVERメッセージと同じIP放送演説に送らなければなりません。 そして、クライアント回のアウト、クライアントがDHCPOFFERメッセージを全く受け取らないなら、DHCPDISCOVERメッセージを再送します。
4. 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. The combination of 'client identifier' or
'chaddr' 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.
Any configuration parameters in the DHCPACK message SHOULD NOT
conflict with those in the earlier DHCPOFFER message to which the
client is responding. The server SHOULD NOT check the offered
network address at this point. The 'yiaddr' field in the DHCPACK
messages is filled in with the selected network address.
4. サーバはクライアントからDHCPREQUEST放送を受けます。 DHCPREQUESTメッセージによって選択されなかったそれらのサーバはクライアントがそのサーバの申し出を断ったという通知としてメッセージを使用します。 DHCPREQUESTメッセージで選択されたサーバは、クライアントのために永続的なストレージに結合を遂行して、DHCPACKメッセージが設定パラメータを含んでいて、要求しているクライアントのために反応します。 'クライアント識別子'か'chaddr'の組み合わせと割り当てられたネットワーク・アドレスはクライアントのリースのためのユニークな識別子を構成して、クライアントとサーバの両方によって使用されて、どんなDHCPメッセージでも言及されたリースを特定します。 DHCPACKメッセージSHOULD NOTのどんな設定パラメータもクライアントが応じている以前のDHCPOFFERメッセージのそれらと衝突します。 サーバSHOULD NOTはここに提供されたネットワーク・アドレスをチェックします。 DHCPACKメッセージの'yiaddr'分野は選択されたネットワーク・アドレスで記入されます。
If the selected server is unable to satisfy the DHCPREQUEST message
(e.g., the requested network address has been allocated), the
server SHOULD respond with a DHCPNAK message.
選択されたサーバがDHCPREQUESTメッセージを満たすことができないなら(例えば要求されたネットワーク・アドレスを割り当てました)、サーバSHOULDはDHCPNAKメッセージで応じます。
A server MAY choose to mark addresses offered to clients in
DHCPOFFER messages as unavailable. The server SHOULD mark an
address offered to a client in a DHCPOFFER message as available if
the server receives no DHCPREQUEST message from that client.
サーバは、入手できないとしてDHCPOFFERメッセージでクライアントに提供されたアドレスにマークするのを選ぶかもしれません。 サーバがそのクライアントからDHCPREQUESTメッセージを全く受け取らないなら、サーバSHOULDは利用可能であるとしてDHCPOFFERメッセージでクライアントに提供されたアドレスにマークします。
5. The client receives the DHCPACK message with configuration
parameters. The client SHOULD perform a final check on the
parameters (e.g., ARP for allocated network address), and notes the
duration of the lease specified in the DHCPACK message. At this
5. クライアントは設定パラメータでDHCPACKメッセージを受け取ります。 クライアントSHOULDはパラメタ(例えば、割り当てられたネットワーク・アドレスのためのARP)、およびリースの持続時間がDHCPACKメッセージで指定したメモに最終的なチェックを実行します。 これで
Droms Standards Track [Page 16] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[16ページ]。
point, the client is configured. If the client detects that the
address is already in use (e.g., through the use of ARP), the
client MUST send a DHCPDECLINE message to the server and restarts
the configuration process. The client SHOULD wait a minimum of ten
seconds before restarting the configuration process to avoid
excessive network traffic in case of looping.
指してください、そして、クライアントは構成されます。 クライアントがそれを検出するならアドレスが既に使用中であり(例えば、ARPの使用による)、クライアントは、DHCPDECLINEメッセージをサーバに送らなければならなくて、コンフィギュレーションプロセスを再開します。 コンフィギュレーションプロセスを再開する前に、クライアントSHOULDは、ループの場合に過度のネットワークトラフィックを避けるのを最低10秒待ちます。
If the client receives a DHCPNAK message, the client restarts the
configuration process.
クライアントがDHCPNAKメッセージを受け取るなら、クライアントはコンフィギュレーションプロセスを再開します。
The client times out and retransmits the DHCPREQUEST message if the
client receives neither a DHCPACK or a DHCPNAK message. The client
retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process. The client SHOULD notify the
user that the initialization process has failed and is restarting.
そして、クライアント回、外、クライアントがDHCPACKもDHCPNAKメッセージも受け取らないなら、DHCPREQUESTメッセージを再送します。 再送信アルゴリズムによると、クライアントはセクション4.1でDHCPREQUESTを再送します。 クライアントは、あきらめるクライアント(そして、そのクライアントのユーザ)が待つことを引き起こさないサーバに連絡するという適切な確率をひどく長く与えることができるくらいの回前にDHCPREQUESTを再送するのを選ぶべきです。 例えば、セクション4.1で説明されるように再送するクライアントは4回DHCPREQUESTメッセージを再送するかもしれません、60秒の総遅れのために、初期化手順を再開する前に。 再送信アルゴリズムを使った後にクライアントがDHCPACKもDHCPNAKメッセージも受け取らないなら、クライアントは、INIT状態に先祖帰りをして、初期化プロセスを再開します。 クライアントSHOULDは初期化プロセスが失敗して、再開しているようにユーザに通知します。
6. 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 with its 'client identifier',
or 'chaddr' and network address in the DHCPRELEASE message. If the
client used a 'client identifier' when it obtained the lease, it
MUST use the same 'client identifier' in the DHCPRELEASE message.
6. クライアントは、ネットワーク・アドレスでDHCPRELEASEメッセージをサーバに送ることによってリースを放棄するのを選ぶかもしれません。クライアントは、DHCPRELEASEメッセージで'クライアント識別子'か、'chaddr'とネットワーク・アドレスでリリースされるためにリースを特定します。 リースを得たとき、クライアントが'クライアント識別子'を使用したなら、それはDHCPRELEASEメッセージの同じ'クライアント識別子'を使用しなければなりません。
3.2 Client-server interaction - reusing a previously allocated network
address
3.2クライアント/サーバ相互作用--以前に割り当てられたネットワーク・アドレスを再利用すること。
If a client remembers and wishes to reuse a previously allocated network address, a client may choose to omit some of the steps described in the previous section. The timeline diagram in figure 4 shows the timing relationships in a typical client-server interaction for a client reusing a previously allocated network address.
クライアントが覚えていて、以前に割り当てられたネットワーク・アドレスを再利用したいなら、クライアントは、前項で説明されたステップのいくつかを省略するのを選ぶかもしれません。 4図のスケジュールダイヤグラムは、クライアントのための典型的なクライアント/サーバ相互作用におけるタイミング関係が以前に割り当てられたネットワーク・アドレスを再利用するのを示します。
Droms Standards Track [Page 17] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[17ページ]。
1. The client broadcasts a DHCPREQUEST message on its local subnet.
The message includes the client's network address in the
'requested IP address' option. As the client has not received its
network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
relay agents pass the message on to DHCP servers not on the same
subnet. If the client used a 'client identifier' to obtain its
address, the client MUST use the same 'client identifier' in the
DHCPREQUEST message.
1. クライアントは地方のサブネットに関するDHCPREQUESTメッセージを放送します。 メッセージは'要求されたIPアドレス'オプションにクライアントのネットワーク・アドレスを含んでいます。 クライアントがネットワーク・アドレスを受け取っていないとき、それは'ciaddr'分野に記入してはいけません。 BOOTP中継エージェントはどんな同じサブネットでもDHCPサーバにメッセージを通過しません。 クライアントがアドレスを得るのに'クライアント識別子'を使用したなら、クライアントはDHCPREQUESTメッセージの同じ'クライアント識別子'を使用しなければなりません。
2. Servers with knowledge of the client's configuration parameters
respond with a DHCPACK message to the client. Servers SHOULD NOT
check that the client's network address is already in use; the
client may respond to ICMP Echo Request messages at this point.
2. クライアントの設定パラメータに関する知識があるサーバはDHCPACKメッセージでクライアントに反応します。 サーバSHOULD NOTは、クライアントのネットワーク・アドレスが既に使用中であることをチェックします。 クライアントはここにICMP Echo Requestメッセージに応じるかもしれません。
Server Client Server
サーバクライアントサーバ
v v v
| | |
| Begins |
| initialization |
| | |
| /|\ |
| _________ __/ | \__________ |
| /DHCPREQU EST | DHCPREQUEST\ |
|/ | \|
| | |
Locates | Locates
configuration | configuration
| | |
|\ | /|
| \ | ___________/ |
| \ | / DHCPACK |
| \ _______ |/ |
| DHCPACK\ | |
| Initialization |
| complete |
| \| |
| | |
| (Subsequent |
| DHCPACKS |
| ignored) |
| | |
| | |
v v v
v vに対して| | | | 始まります。| | 初期化| | | | | /|\ | | _________ __/ | \__________ | | 米国東部標準時の/DHCPREQU| DHCPREQUEST\| |/ | \| | | | 場所を見つけます。| 構成の場所を見つけます。| 構成| | | |\ | /| | \ | ___________/ | | \ | /DHCPACK| | \ _______ |/ | | DHCPACK\| | | 初期設定| | 完全| | \| | | | | | (その後、| | DHCPACKS|、|、無視、) | | | | | | | v vに対して
Figure 4: Timeline diagram of messages exchanged between DHCP
client and servers when reusing a previously allocated
network address
図4: 以前に割り当てられたネットワーク・アドレスを再利用するときDHCPクライアントとサーバの間で交換されたメッセージのスケジュールダイヤグラム
Droms Standards Track [Page 18] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[18ページ]。
If the client's request is invalid (e.g., the client has moved
to a new subnet), servers SHOULD respond with a DHCPNAK message to
the client. Servers SHOULD NOT respond if their information is not
guaranteed to be accurate. For example, a server that identifies a
request for an expired binding that is owned by another server SHOULD
NOT respond with a DHCPNAK unless the servers are using an explicit
mechanism to maintain coherency among the servers.
クライアントの要求が無効であるなら(例えば、クライアントは新しいサブネットに移行しました)、サーバSHOULDはDHCPNAKメッセージでクライアントに応じます。 それらの情報が正直なところ保証されないなら、サーバSHOULD NOTは応じます。 例えば、サーバがサーバの中で一貫性を維持するのに明白なメカニズムを使用していない場合SHOULD NOTがDHCPNAKと共に反応させる別のサーバによって所有されている満期の結合を求める要求を特定するサーバ。
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the 0xffffffff broadcast address
because the client may not have a correct network address or subnet
mask, and the client may not be answering ARP requests.
Otherwise, the server MUST send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. The
relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even
if the client has moved to a new network.
'giaddr'がDHCPREQUESTメッセージの0×0であるなら、クライアントはサーバと同じサブネットにいます。クライアントが正しいネットワーク・アドレスかサブネットマスクを持っていないかもしれないので、サーバはDHCPNAKメッセージを0xffffffff放送演説に放送しなければなりません、そして、クライアントはARPに要求に答えていないかもしれません。 さもなければ、サーバはBOOTP中継エージェントのIPアドレスにDHCPNAKメッセージを送らなければなりません、'giaddr'に記録されるように。 中継エージェントは順番に直接クライアントのハードウェア・アドレスにメッセージを転送するでしょう、クライアントが新しいネットワークに移行したとしてもDHCPNAKを提供できるように。
3. The client receives the DHCPACK message with configuration
parameters. The client performs a final check on the parameters
(as in section 3.1), and notes the duration of the lease specified
in the DHCPACK message. The specific lease is implicitly identified
by the 'client identifier' or 'chaddr' and the network address. At
this point, the client is configured.
3. クライアントは設定パラメータでDHCPACKメッセージを受け取ります。 クライアントは、パラメタ(セクション3.1のように)に最終的なチェックを実行して、リースの持続時間がDHCPACKメッセージで指定したことに注意します。 特定のリースは'クライアント識別子'か'chaddr'とネットワーク・アドレスによってそれとなく特定されます。 ここに、クライアントは構成されます。
If the client detects that the IP address in the DHCPACK message
is already in use, the client MUST send a DHCPDECLINE message to the
server and restarts the configuration process by requesting a
new network address. This action corresponds to the client
moving to the INIT state in the DHCP state diagram, which is
described in section 4.4.
クライアントがそれを検出するならDHCPACKメッセージのIPアドレスが既に使用中であり、クライアントは、DHCPDECLINEメッセージをサーバに送らなければならなくて、新しいネットワーク・アドレスを要求することによって、コンフィギュレーションプロセスを再開します。 この動作はセクション4.4で説明されるDHCP州のダイヤグラムによるINIT状態に移行するクライアントに文通されます。
If the client receives a DHCPNAK message, it cannot reuse its
remembered network address. It must instead request a new
address by restarting the configuration process, this time
using the (non-abbreviated) procedure described in section
3.1. This action also corresponds to the client moving to
the INIT state in the DHCP state diagram.
クライアントがDHCPNAKメッセージを受け取るなら、それは覚えていられたネットワーク・アドレスを再利用できません。 それは、代わりにコンフィギュレーションプロセス(セクション3.1で説明された(非簡略化される)の手順を用いる今回)を再開することによって、新しいアドレスを要求しなければなりません。 また、この動作はDHCP州のダイヤグラムによるINIT状態に移行するクライアントに文通されます。
The client times out and retransmits the DHCPREQUEST message if
the client receives neither a DHCPACK nor a DHCPNAK message. The
client retransmits the DHCPREQUEST according to the retransmission
algorithm in section 4.1. The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
そして、クライアント回、外、クライアントがDHCPACKもDHCPNAKメッセージも受け取らないなら、DHCPREQUESTメッセージを再送します。 再送信アルゴリズムによると、クライアントはセクション4.1でDHCPREQUESTを再送します。 クライアントは、あきらめるクライアント(そして、そのクライアントのユーザ)が待つことを引き起こさないサーバに連絡するという適切な確率をひどく長く与えることができるくらいの回前にDHCPREQUESTを再送するのを選ぶべきです。 例えば、セクション4.1で説明されるように再送するクライアントは再送するかもしれません。
Droms Standards Track [Page 19] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[19ページ]。
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing
the retransmission algorithm, the client MAY choose to use the
previously allocated network address and configuration parameters
for the remainder of the unexpired lease. This corresponds to
moving to BOUND state in the client state transition diagram shown
in figure 5.
DHCPREQUEST message four times, for a total delay of 60 seconds, before restarting the initialization procedure. If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease. This corresponds to moving to BOUND state in the client state transition diagram shown in figure 5.
4. 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 with its
'client identifier', or 'chaddr' and network address in the
DHCPRELEASE message.
4. 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 with its 'client identifier', or 'chaddr' and network address in the DHCPRELEASE message.
Note that in this case, where the client retains its network
address locally, the client will not normally relinquish its
lease during a graceful shutdown. Only in the case where the
client explicitly needs to relinquish its lease, e.g., the client
is about to be moved to a different subnet, will the client send
a DHCPRELEASE message.
Note that in this case, where the client retains its network address locally, the client will not normally relinquish its lease during a graceful shutdown. Only in the case where the client explicitly needs to relinquish its lease, e.g., the client is about to be moved to a different subnet, will the client send a DHCPRELEASE message.
3.3 Interpretation and representation of time values
3.3 Interpretation and representation of time values
A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent "infinity".
A client acquires a lease for a network address for a fixed period of time (which may be infinite). Throughout the protocol, times are to be represented in units of seconds. The time value of 0xffffffff is reserved to represent "infinity".
As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client's local clock. Representing relative times in units of seconds in an unsigned 32 bit word gives a range of relative times from 0 to approximately 100 years, which is sufficient for the relative times to be measured using DHCP.
As clients and servers may not have synchronized clocks, times are represented in DHCP messages as relative times, to be interpreted with respect to the client's local clock. Representing relative times in units of seconds in an unsigned 32 bit word gives a range of relative times from 0 to approximately 100 years, which is sufficient for the relative times to be measured using DHCP.
The algorithm for lease duration interpretation given in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is drift between the two clocks, the server may consider the lease expired before the client does. To compensate, the server may return a shorter lease duration to the client than the server commits to its local database of client information.
The algorithm for lease duration interpretation given in the previous paragraph assumes that client and server clocks are stable relative to each other. If there is drift between the two clocks, the server may consider the lease expired before the client does. To compensate, the server may return a shorter lease duration to the client than the server commits to its local database of client information.
3.4 Obtaining parameters with externally configured network address
3.4 Obtaining parameters with externally configured network address
If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message
If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message
Droms Standards Track [Page 20] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 20] RFC 2131 Dynamic Host Configuration Protocol March 1997
to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without: allocating a new address, checking for an existing binding, filling in 'yiaddr' or including lease time parameters. The servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message.
to obtain other local configuration parameters. Servers receiving a DHCPINFORM message construct a DHCPACK message with any local configuration parameters appropriate for the client without: allocating a new address, checking for an existing binding, filling in 'yiaddr' or including lease time parameters. The servers SHOULD unicast the DHCPACK reply to the address given in the 'ciaddr' field of the DHCPINFORM message.
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.
The server SHOULD check the network address in a DHCPINFORM message for consistency, but MUST NOT check for an existing lease. The server forms a DHCPACK message containing the configuration parameters for the requesting client and sends the DHCPACK message directly to the client.
3.5 Client parameters in DHCP
3.5 Client parameters in DHCP
Not all clients require initialization of all parameters listed in Appendix A. Two techniques are used to reduce the number of parameters transmitted from the server to the client. First, most of the parameters have defaults defined in the Host Requirements RFCs; if the client receives no parameters from the server that override the defaults, a client uses those default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in. If the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any subsequent DHCPREQUEST messages.
Not all clients require initialization of all parameters listed in Appendix A. Two techniques are used to reduce the number of parameters transmitted from the server to the client. First, most of the parameters have defaults defined in the Host Requirements RFCs; if the client receives no parameters from the server that override the defaults, a client uses those default values. Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in. If the client includes a list of parameters in a DHCPDISCOVER message, it MUST include that list in any subsequent DHCPREQUEST messages.
The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the 'options' field of the message) indicate that the 'file' and 'sname' fields are to be used for options.
The client SHOULD include the 'maximum DHCP message size' option to let the server know how large the server may make its DHCP messages. The parameters returned to a client may still exceed the space allocated to options in a DHCP message. In this case, two additional options flags (which must appear in the 'options' field of the message) indicate that the 'file' and 'sname' fields are to be used for options.
The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag number.
The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag number.
In addition, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the 'requested IP address' option to suggest that a particular IP address be assigned, and may include the 'IP address lease time' option to suggest the lease time it would like. Other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. However, additional options may
In addition, the client may suggest values for the network address and lease time in the DHCPDISCOVER message. The client may include the 'requested IP address' option to suggest that a particular IP address be assigned, and may include the 'IP address lease time' option to suggest the lease time it would like. Other options representing "hints" at configuration parameters are allowed in a DHCPDISCOVER or DHCPREQUEST message. However, additional options may
Droms Standards Track [Page 21] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 21] RFC 2131 Dynamic Host Configuration Protocol March 1997
be ignored by servers, and multiple servers may, therefore, not return identical values for some options. The 'requested IP address' option is to be filled in only in a DHCPREQUEST message when the client is verifying network parameters obtained previously. The client fills in the 'ciaddr' field only when correctly configured with an IP address in BOUND, RENEWING or REBINDING state.
be ignored by servers, and multiple servers may, therefore, not return identical values for some options. The 'requested IP address' option is to be filled in only in a DHCPREQUEST message when the client is verifying network parameters obtained previously. The client fills in the 'ciaddr' field only when correctly configured with an IP address in BOUND, RENEWING or REBINDING state.
If a server receives a DHCPREQUEST message with an invalid 'requested IP address', the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the 'message' option.
If a server receives a DHCPREQUEST message with an invalid 'requested IP address', the server SHOULD respond to the client with a DHCPNAK message and may choose to report the problem to the system administrator. The server may include an error message in the 'message' option.
3.6 Use of DHCP in clients with multiple interfaces
3.6 Use of DHCP in clients with multiple interfaces
A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces.
A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces.
3.7 When clients should use DHCP
3.7 When clients should use DHCP
A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge.
A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge.
If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.
If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem.
4. Specification of the DHCP client-server protocol
4. Specification of the DHCP client-server protocol
In this section, we assume that a DHCP server has a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage.
In this section, we assume that a DHCP server has a block of network addresses from which it can satisfy requests for new addresses. Each server also maintains a database of allocated addresses and leases in local permanent storage.
4.1 Constructing and sending DHCP messages
4.1 Constructing and sending DHCP messages
DHCP clients and servers both construct DHCP messages by filling in fields in the fixed format section of the message and appending tagged data items in the variable length option area. The options area includes first a four-octet 'magic cookie' (which was described in section 3), followed by the options. The last option must always
DHCP clients and servers both construct DHCP messages by filling in fields in the fixed format section of the message and appending tagged data items in the variable length option area. The options area includes first a four-octet 'magic cookie' (which was described in section 3), followed by the options. The last option must always
Droms Standards Track [Page 22] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 22] RFC 2131 Dynamic Host Configuration Protocol March 1997
be the 'end' option.
be the 'end' option.
DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68). A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages.
DHCP uses UDP as its transport protocol. DHCP messages from a client to a server are sent to the 'DHCP server' port (67), and DHCP messages from a server to a client are sent to the 'DHCP client' port (68). A server with multiple network address (e.g., a multi-homed host) MAY use any of its network addresses in outgoing DHCP messages.
The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to to accept any of its network addresses as identifying that server in a DHCP message. To accommodate potentially incomplete network connectivity, a server MUST choose an address as a 'server identifier' that, to the best of the server's knowledge, is reachable from the client. For example, if the DHCP server and the DHCP client are connected to the same subnet (i.e., the 'giaddr' field in the message from the client is zero), the server SHOULD select the IP address the server is using for communication on that subnet as the 'server identifier'. If the server is using multiple IP addresses on that subnet, any such address may be used. If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was recieved as the 'server identifier' (unless the server has other, better information on which to make its choice). DHCP clients MUST use the IP address provided in the 'server identifier' option for any unicast requests to the DHCP server.
The 'server identifier' field is used both to identify a DHCP server in a DHCP message and as a destination address from clients to servers. A server with multiple network addresses MUST be prepared to to accept any of its network addresses as identifying that server in a DHCP message. To accommodate potentially incomplete network connectivity, a server MUST choose an address as a 'server identifier' that, to the best of the server's knowledge, is reachable from the client. For example, if the DHCP server and the DHCP client are connected to the same subnet (i.e., the 'giaddr' field in the message from the client is zero), the server SHOULD select the IP address the server is using for communication on that subnet as the 'server identifier'. If the server is using multiple IP addresses on that subnet, any such address may be used. If the server has received a message through a DHCP relay agent, the server SHOULD choose an address from the interface on which the message was recieved as the 'server identifier' (unless the server has other, better information on which to make its choice). DHCP clients MUST use the IP address provided in the 'server identifier' option for any unicast requests to the DHCP server.
DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.
DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0.
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.
If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.
If the options in a DHCP message extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field, with value 1, 2 or 3, as specified in RFC 1533. If the
If the options in a DHCP message extend into the 'sname' and 'file' fields, the 'option overload' option MUST appear in the 'options' field, with value 1, 2 or 3, as specified in RFC 1533. If the
Droms Standards Track [Page 23] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 23] RFC 2131 Dynamic Host Configuration Protocol March 1997
'option overload' option is present in the 'options' field, the options in the 'options' field MUST be terminated by an 'end' option, and MAY contain one or more 'pad' options to fill the options field. The options in the 'sname' and 'file' fields (if in use as indicated by the 'options overload' option) MUST begin with the first octet of the field, MUST be terminated by an 'end' option, and MUST be followed by 'pad' options to fill the remainder of the field. Any individual option in the 'options', 'sname' and 'file' fields MUST be entirely contained in that field. The options in the 'options' field MUST be interpreted first, so that any 'option overload' options may be interpreted. The 'file' field MUST be interpreted next (if the 'option overload' option indicates that the 'file' field contains DHCP options), followed by the 'sname' field.
'option overload' option is present in the 'options' field, the options in the 'options' field MUST be terminated by an 'end' option, and MAY contain one or more 'pad' options to fill the options field. The options in the 'sname' and 'file' fields (if in use as indicated by the 'options overload' option) MUST begin with the first octet of the field, MUST be terminated by an 'end' option, and MUST be followed by 'pad' options to fill the remainder of the field. Any individual option in the 'options', 'sname' and 'file' fields MUST be entirely contained in that field. The options in the 'options' field MUST be interpreted first, so that any 'option overload' options may be interpreted. The 'file' field MUST be interpreted next (if the 'option overload' option indicates that the 'file' field contains DHCP options), followed by the 'sname' field.
The values to be passed in an 'option' tag may be too long to fit in the 255 octets available to a single option (e.g., a list of routers in a 'router' option [21]). Options may appear only once, unless otherwise specified in the options document. The client concatenates the values of multiple instances of the same option into a single parameter list for configuration.
The values to be passed in an 'option' tag may be too long to fit in the 255 octets available to a single option (e.g., a list of routers in a 'router' option [21]). Options may appear only once, unless otherwise specified in the options document. The client concatenates the values of multiple instances of the same option into a single parameter list for configuration.
DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server. For example, in a 10Mb/sec Ethernet internetwork, the delay before the first retransmission SHOULD be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non-integer randomization value. The delay before the next retransmission SHOULD be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process.
DHCP clients are responsible for all message retransmission. The client MUST adopt a retransmission strategy that incorporates a randomized exponential backoff algorithm to determine the delay between retransmissions. The delay between retransmissions SHOULD be chosen to allow sufficient time for replies from the server to be delivered based on the characteristics of the internetwork between the client and the server. For example, in a 10Mb/sec Ethernet internetwork, the delay before the first retransmission SHOULD be 4 seconds randomized by the value of a uniform random number chosen from the range -1 to +1. Clients with clocks that provide resolution granularity of less than one second may choose a non-integer randomization value. The delay before the next retransmission SHOULD be 8 seconds randomized by the value of a uniform number chosen from the range -1 to +1. The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. The client MAY provide an indication of retransmission attempts to the user as an indication of the progress of the configuration process.
The 'xid' field is used by the client to match incoming DHCP messages with pending requests. A DHCP client MUST choose 'xid's in such a way as to minimize the chance of using an 'xid' identical to one used by another client. For example, a client may choose a different, random initial 'xid' each time the client is rebooted, and subsequently use sequential 'xid's until the next reboot. Selecting a new 'xid' for each retransmission is an implementation decision. A client may choose to reuse the same 'xid' or select a new 'xid' for each retransmitted message.
The 'xid' field is used by the client to match incoming DHCP messages with pending requests. A DHCP client MUST choose 'xid's in such a way as to minimize the chance of using an 'xid' identical to one used by another client. For example, a client may choose a different, random initial 'xid' each time the client is rebooted, and subsequently use sequential 'xid's until the next reboot. Selecting a new 'xid' for each retransmission is an implementation decision. A client may choose to reuse the same 'xid' or select a new 'xid' for each retransmitted message.
Droms Standards Track [Page 24] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 24] RFC 2131 Dynamic Host Configuration Protocol March 1997
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).
Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using uicast delivery. The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. Unfortunately, some client implementations are unable to receive such unicast IP datagrams until the implementation has been configured with a valid IP address (leading to a deadlock in which the client's IP address cannot be delivered until the client has been configured with an IP address).
A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21].
A client that cannot receive unicast IP datagrams until its protocol software has been configured with an IP address SHOULD set the BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or DHCPREQUEST messages that client sends. The BROADCAST bit will provide a hint to the DHCP server and BOOTP relay agent to broadcast any messages to the client on the client's subnet. A client that can receive unicast IP datagrams before its protocol software has been configured SHOULD clear the BROADCAST bit to 0. The BOOTP clarifications document discusses the ramifications of the use of the BROADCAST bit [21].
A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link- layer broadcast address as the link-layer destination address.
A server or relay agent sending or relaying a DHCP message directly to a DHCP client (i.e., not to a relay agent specified in the 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags' field. If this bit is set to 1, the DHCP message SHOULD be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address. If the BROADCAST bit is cleared to 0, the message SHOULD be sent as an IP unicast to the IP address specified in the 'yiaddr' field and the link-layer address specified in the 'chaddr' field. If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link- layer broadcast address as the link-layer destination address.
4.2 DHCP server administrative controls
4.2 DHCP server administrative controls
DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server
DHCP servers are not required to respond to every DHCPDISCOVER and DHCPREQUEST message they receive. For example, a network administrator, to retain stringent control over the clients attached to the network, may choose to configure DHCP servers to respond only to clients that have been previously registered through some external mechanism. The DHCP specification describes only the interactions between clients and servers when the clients and servers choose to interact; it is beyond the scope of the DHCP specification to describe all of the administrative controls that system administrators might want to use. Specific DHCP server
Droms Standards Track [Page 25] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 25] RFC 2131 Dynamic Host Configuration Protocol March 1997
implementations may incorporate any controls or policies desired by a network administrator.
implementations may incorporate any controls or policies desired by a network administrator.
In some environments, a DHCP server will have to consider the values of the vendor class options included in DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client.
In some environments, a DHCP server will have to consider the values of the vendor class options included in DHCPDISCOVER or DHCPREQUEST messages when determining the correct parameters for a particular client.
A DHCP server needs to use some unique identifier to associate a client with its lease. The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option. Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box.
A DHCP server needs to use some unique identifier to associate a client with its lease. The client MAY choose to explicitly provide the identifier through the 'client identifier' option. If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client. It is crucial for a DHCP client to use an identifier unique within the subnet to which the client is attached in the 'client identifier' option. Use of 'chaddr' as the client's unique identifier may cause unexpected results, as that identifier may be associated with a hardware interface that could be moved to a new client. Some sites may choose to use a manufacturer's serial number as the 'client identifier', to avoid unexpected changes in a clients network address due to transfer of hardware interfaces among computers. Sites may also choose to use a DNS name as the 'client identifier', causing address leases to be associated with the DNS name rather than a specific hardware box.
DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP SHOULD provide a mechanism for the user to select directly the 'vendor class identifier' values.
DHCP clients are free to use any strategy in selecting a DHCP server among those from which the client receives a DHCPOFFER message. The client implementation of DHCP SHOULD provide a mechanism for the user to select directly the 'vendor class identifier' values.
4.3 DHCP server behavior
4.3 DHCP server behavior
A DHCP server processes incoming DHCP messages from a client based on the current state of the binding for that client. A DHCP server can receive the following messages from a client:
A DHCP server processes incoming DHCP messages from a client based on the current state of the binding for that client. A DHCP server can receive the following messages from a client:
o DHCPDISCOVER
o DHCPDISCOVER
o DHCPREQUEST
o DHCPREQUEST
o DHCPDECLINE
o DHCPDECLINE
o DHCPRELEASE
o DHCPRELEASE
o DHCPINFORM
o DHCPINFORM
Droms Standards Track [Page 26] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 26] RFC 2131 Dynamic Host Configuration Protocol March 1997
Table 3 gives the use of the fields and options in a DHCP message by a server. The remainder of this section describes the action of the DHCP server for each possible incoming message.
Table 3 gives the use of the fields and options in a DHCP message by a server. The remainder of this section describes the action of the DHCP server for each possible incoming message.
4.3.1 DHCPDISCOVER message
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address SHOULD be chosen as follows:
When a server receives a DHCPDISCOVER message from a client, the server chooses a network address for the requesting client. If no address is available, the server may choose to report the problem to the system administrator. If an address is available, the new address SHOULD be chosen as follows:
o The client's current address as recorded in the client's current
binding, ELSE
o The client's current address as recorded in the client's current binding, ELSE
o The client's previous address as recorded in the client's (now
expired or released) binding, if that address is in the server's
pool of available addresses and not already allocated, ELSE
o The client's previous address as recorded in the client's (now expired or released) binding, if that address is in the server's pool of available addresses and not already allocated, ELSE
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, ELSE
o The address requested in the 'Requested IP Address' option, if that address is valid and not already allocated, ELSE
o A new address allocated from the server's pool of available
addresses; the address is selected based on the subnet from which
the message was received (if 'giaddr' is 0) or on the address of
the relay agent that forwarded the message ('giaddr' when not 0).
o A new address allocated from the server's pool of available addresses; the address is selected based on the subnet from which the message was received (if 'giaddr' is 0) or on the address of the relay agent that forwarded the message ('giaddr' when not 0).
As described in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or may refuse to allocate an address to a particular client even though free addresses are available.
As described in section 4.2, a server MAY, for administrative reasons, assign an address other than the one requested, or may refuse to allocate an address to a particular client even though free addresses are available.
Note that, in some network architectures (e.g., internets with more than one IP subnet assigned to a physical network segment), it may be the case that the DHCP client should be assigned an address from a different subnet than the address recorded in 'giaddr'. Thus, DHCP does not require that the client be assigned as address from the subnet in 'giaddr'. A server is free to choose some other subnet, and it is beyond the scope of the DHCP specification to describe ways in which the assigned IP address might be chosen.
Note that, in some network architectures (e.g., internets with more than one IP subnet assigned to a physical network segment), it may be the case that the DHCP client should be assigned an address from a different subnet than the address recorded in 'giaddr'. Thus, DHCP does not require that the client be assigned as address from the subnet in 'giaddr'. A server is free to choose some other subnet, and it is beyond the scope of the DHCP specification to describe ways in which the assigned IP address might be chosen.
While not required for correct operation of DHCP, the server SHOULD NOT reuse the selected network address before the client responds to the server's DHCPOFFER message. The server may choose to record the address as offered to the client.
While not required for correct operation of DHCP, the server SHOULD NOT reuse the selected network address before the client responds to the server's DHCPOFFER message. The server may choose to record the address as offered to the client.
The server must also choose an expiration time for the lease, as follows:
The server must also choose an expiration time for the lease, as follows:
Droms Standards Track [Page 27] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 27] RFC 2131 Dynamic Host Configuration Protocol March 1997
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
o IF the client has not requested a specific lease in the DHCPDISCOVER message and the client already has an assigned network address, the server returns the lease expiration time previously assigned to that address (note that the client must explicitly request a specific lease to extend the expiration time on a previously assigned address), ELSE
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default
lease time, ELSE
o IF the client has not requested a specific lease in the DHCPDISCOVER message and the client does not have an assigned network address, the server assigns a locally configured default lease time, ELSE
o IF the client has requested a specific lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select
another lease.
o IF the client has requested a specific lease in the DHCPDISCOVER message (regardless of whether the client has an assigned network address), the server may choose either to return the requested lease (if the lease is acceptable to local policy) or select another lease.
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 0
DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' 'flags' from 'flags' from 'flags' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
message message message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Field DHCPOFFER DHCPACK DHCPNAK ----- --------- ------- ------- 'op' BOOTREPLY BOOTREPLY BOOTREPLY 'htype' (From "Assigned Numbers" RFC) 'hlen' (Hardware address length in octets) 'hops' 0 0 0 'xid' 'xid' from client 'xid' from client 'xid' from client DHCPDISCOVER DHCPREQUEST DHCPREQUEST message message message 'secs' 0 0 0 'ciaddr' 0 'ciaddr' from 0 DHCPREQUEST or 0 'yiaddr' IP address offered IP address 0 to client assigned to client 'siaddr' IP address of next IP address of next 0 bootstrap server bootstrap server 'flags' 'flags' from 'flags' from 'flags' from client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST message message message 'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST message message message 'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST message message message 'sname' Server host name Server host name (unused) or options or options 'file' Client boot file Client boot file (unused) name or options name or options 'options' options options
Droms Standards Track [Page 28] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms Standards Track [Page 28] RFC 2131 Dynamic Host Configuration Protocol March 1997
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
MUST NOT (DHCPINFORM)
Use 'file'/'sname' fields MAY MAY MUST NOT
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MAY
Vendor class identifier MAY MAY MAY
Server identifier MUST MUST MUST
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
オプションDHCPOFFER DHCPACK DHCPNAK------ --------- ------- ------- IPアドレスがそうしなければならなくないよう要求する、NOTがそうしなければならない、時間がそうしなければならないリースがそうしなければならないIPアドレス(DHCPREQUEST)が使用しなければならないNOTがサイズが使用しなければならなくない識別子5月の5月の5月のServer識別子がそうしなければならないMessage SHOULD SHOULD SHOULD Client識別子ではなく、リストがそうしなければならなくないDHCPOFFER DHCPACK DHCPNAK Parameter要求がそうしなければならなくないタイプがそうしなければならないMAY MAY MUST NOT DHCPメッセージがそうしなければならなくない分野がそうしなければならなくない'sname'5月のVendorのクラスがそうしなければならない/がそうしなければならない'ファイル'Maximumメッセージを使用しなければならない、(DHCPINFORM)NOTがそうしなければならない、どんなAll他のものも5月の5月にそうしなくなければならなくはありません。
Table 3: Fields and options used by DHCP servers
テーブル3: DHCPサーバによって使用される分野とオプション
Once the network address and lease have been determined, the server constructs a DHCPOFFER message with the offered configuration parameters. It is important for all DHCP servers to return the same parameters (with the possible exception of a newly allocated network address) to ensure predictable client behavior regardless of which server the client selects. The configuration parameters MUST be selected by applying the following rules in the order given below. The network administrator is responsible for configuring multiple DHCP servers to ensure uniform responses from those servers. The server MUST return to the client:
ネットワーク・アドレスとリースがいったん決定するようになると、サーバは提供された設定パラメータでDHCPOFFERメッセージを構成します。 すべてのDHCPサーバがクライアントが選択するどのサーバにかかわらず予測できるクライアントの振舞いを確実にするかために、同じパラメタ(新たに割り当てられたネットワーク・アドレスの可能な例外がある)を返すのは、重要です。 以下に与えられたオーダーにおける以下の規則を適用することによって、設定パラメータを選択しなければなりません。 ネットワーク管理者はそれらのサーバから一定の応答を確実にするために複数のDHCPサーバを構成するのに責任があります。 サーバはクライアントに戻らなければなりません:
o The client's network address, as determined by the rules given
earlier in this section,
o クライアントは、ネットワーク・アドレスであって、より早くこのセクションで与えられた規則で断固としています。
o The expiration time for the client's lease, as determined by the
rules given earlier in this section,
o クライアントのリースのための、より早くこのセクションで与えられた規則で決定するような満了時間
o Parameters requested by the client, according to the following
rules:
o 以下の規則に従って、パラメタはクライアントから要求しました:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE
-- サーバがパラメタのためにデフォルト値によって明らかに構成されたなら、サーバは'オプション'分野での適切なオプションにその値を含まなければなりません、ELSE
-- IF the server recognizes the parameter as a parameter
defined in the Host Requirements Document, the server MUST
include the default value for that parameter as given in the
Host Requirements Document in an appropriate option in the
'option' field, ELSE
-- サーバが、パラメタがHost Requirements Documentで定義されたパラメタであると認めるなら、サーバはHost Requirements Documentで'オプション'分野での適切なオプションで与えるようにそのパラメタのためのデフォルト値を含まなければなりません、ELSE
-- The server MUST NOT return a value for that parameter,
-- サーバはそのパラメタのために値を返してはいけません。
Droms Standards Track [Page 29] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[29ページ]。
The server MUST supply as many of the requested parameters as
possible and MUST omit any parameters it cannot provide. The
server MUST include each requested parameter only once unless
explicitly allowed in the DHCP Options and BOOTP Vendor
Extensions document.
サーバは、できるだけ多くの要求されたパラメタを提供しなければならなくて、それが提供できないどんなパラメタも省略しなければなりません。 DHCP OptionsとBOOTP Vendor Extensionsドキュメントに明らかに許容されていない場合、サーバは一度だけそれぞれの要求されたパラメタを含まなければなりません。
o Any parameters from the existing binding that differ from the Host
Requirements Document defaults,
o それを縛る存在からのどんなパラメタもHost Requirements Documentデフォルトと異なっています。
o Any parameters specific to this client (as identified by
the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
or DHCPREQUEST message), e.g., as configured by the network
administrator,
o ネットワーク管理者による例えば、このクライアント(DHCPDISCOVERかDHCPREQUESTメッセージの'chaddr'か'クライアント識別子'のコンテンツによって特定されるように)、構成にされるとして特定のどんなパラメタ
o Any parameters specific to this client's class (as identified
by the contents of the 'vendor class identifier'
option in the DHCPDISCOVER or DHCPREQUEST message),
e.g., as configured by the network administrator; the parameters
MUST be identified by an exact match between the client's vendor
class identifiers and the client's classes identified in the
server,
o ネットワーク管理者によるこのクライアントのクラス(DHCPDISCOVERかDHCPREQUESTメッセージにおける'ベンダークラス識別子'オプションのコンテンツによって特定されるように)、構成される例えば、として特定のどんなパラメタも。 クライアントのベンダークラス識別子とサーバで特定されたクライアントのクラスとの完全な一致でパラメタを特定しなければなりません。
o Parameters with non-default values on the client's subnet.
o 非デフォルト値がクライアントのサブネットにあるパラメタ。
The server MAY choose to return the 'vendor class identifier' used to determine the parameters in the DHCPOFFER message to assist the client in selecting which DHCPOFFER to accept. The server inserts the 'xid' field from the DHCPDISCOVER message into the 'xid' field of the DHCPOFFER message and sends the DHCPOFFER message to the requesting client.
サーバは、どのDHCPOFFERを選択するかにクライアントを助けるDHCPOFFERメッセージのパラメタが受け入れることを決定するのに使用される'ベンダークラス識別子'を返すのを選ぶかもしれません。 サーバは、'xid'野原をDHCPDISCOVERメッセージからDHCPOFFERメッセージの'xid'分野に挿入して、DHCPOFFERメッセージを要求しているクライアントに送ります。
4.3.2 DHCPREQUEST message
4.3.2 DHCPREQUESTメッセージ
A DHCPREQUEST message may come from a client responding to a DHCPOFFER message from a server, from a client verifying a previously allocated IP address or from a client extending the lease on a network address. If the DHCPREQUEST message contains a 'server identifier' option, the message is in response to a DHCPOFFER message. Otherwise, the message is a request to verify or extend an existing lease. If the client uses a 'client identifier' in a DHCPREQUEST message, it MUST use that same 'client identifier' in all subsequent messages. If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.
DHCPREQUESTメッセージは以前に割り当てられたIPアドレスについて確かめるクライアント、または、サーバからDHCPOFFERメッセージに応じているクライアントか、ネットワーク・アドレスでリースを広げるクライアントから来るかもしれません。 DHCPREQUESTメッセージが'サーバ識別子'オプションを含んでいるなら、メッセージはDHCPOFFERメッセージに対応しています。 さもなければ、メッセージは既存のリースを確かめるか、または広げるという要求です。 クライアントがDHCPREQUESTメッセージの'クライアント識別子'を使用するなら、それはすべてのその後のメッセージのその同じ'クライアント識別子'を使用しなければなりません。 クライアントがDHCPDISCOVERメッセージで要求されたパラメタのリストを入れたなら、それはすべてのその後のメッセージにそのリストを含まなければなりません。
Droms Standards Track [Page 30] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[30ページ]。
Any configuration parameters in the DHCPACK message SHOULD NOT conflict with those in the earlier DHCPOFFER message to which the client is responding. The client SHOULD use the parameters in the DHCPACK message for configuration.
DHCPACKメッセージSHOULD NOTのどんな設定パラメータもクライアントが応じている以前のDHCPOFFERメッセージのそれらと衝突します。 クライアントSHOULDは構成にDHCPACKメッセージのパラメタを使用します。
Clients send DHCPREQUEST messages as follows:
クライアントは以下のメッセージをDHCPREQUESTに送ります:
o DHCPREQUEST generated during SELECTING state:
o SELECTINGの間に生成されたDHCPREQUESTは以下を述べます。
Client inserts the address of the selected server in 'server
identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
filled in with the yiaddr value from the chosen DHCPOFFER.
'ciaddr'がゼロであるに違いない、クライアントは'サーバ識別子'に選択されたサーバのアドレスを挿入して、yiaddr値で選ばれたDHCPOFFERから'要求されたIPアドレス'に記入しなければなりません。
Note that the client may choose to collect several DHCPOFFER
messages and select the "best" offer. The client indicates its
selection by identifying the offering server in the DHCPREQUEST
message. If the client receives no acceptable offers, the client
may choose to try another DHCPDISCOVER message. Therefore, the
servers may not receive a specific DHCPREQUEST from which they can
decide whether or not the client has accepted the offer. Because
the servers have not committed any network address assignments on
the basis of a DHCPOFFER, servers are free to reuse offered
network addresses in response to subsequent requests. As an
implementation detail, servers SHOULD NOT reuse offered addresses
and may use an implementation-specific timeout mechanism to decide
when to reuse an offered address.
クライアントがいくつかのDHCPOFFERメッセージを集めて、「最も良い」申し出を選択するのを選ぶかもしれないことに注意してください。 クライアントは、DHCPREQUESTメッセージの提供サーバを特定することによって、選択を示します。 クライアントがどんな許容できる申し出も受けないなら、クライアントは、別のDHCPDISCOVERメッセージを試みるのを選ぶかもしれません。 したがって、サーバはそれらが、クライアントが申し出を受け入れたかどうか決めることができる特定のDHCPREQUESTを受けないかもしれません。 サーバがDHCPOFFERに基づいてどんなネットワーク・アドレス課題も遂行していないので、サーバは無料でその後の要求に対応して提供されたネットワーク・アドレスを再利用できます。 実装の詳細として、サーバSHOULD NOT再利用は、アドレスを提供して、いつ提供されたアドレスを再利用するかを決めるのに実装特有のタイムアウトメカニズムを使用するかもしれません。
o DHCPREQUEST generated during INIT-REBOOT state:
o INIT-REBOOTの間に生成されたDHCPREQUESTは以下を述べます。
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST be filled in with client's notion of its previously
assigned address. 'ciaddr' MUST be zero. The client is seeking to
verify a previously allocated, cached configuration. Server SHOULD
send a DHCPNAK message to the client if the 'requested IP address'
is incorrect, or is on the wrong network.
'サーバ識別子'に記入してはいけなくて、以前に割り当てられたアドレスに関するクライアントの概念で'要求されたIPアドレス'オプションに記入しなければなりません。 'ciaddr'はゼロであるに違いありません。 クライアントは以前に、割り当てて、キャッシュされた構成について確かめようとしています。 '要求されたIPアドレス'は不正確であるか、または間違ったネットワークにあるなら、サーバSHOULDがDHCPNAKメッセージをクライアントに送ります。
Determining whether a client in the INIT-REBOOT state is on the
correct network is done by examining the contents of 'giaddr', the
'requested IP address' option, and a database lookup. If the DHCP
server detects that the client is on the wrong net (i.e., the
result of applying the local subnet mask or remote subnet mask (if
'giaddr' is not zero) to 'requested IP address' option value
doesn't match reality), then the server SHOULD send a DHCPNAK
message to the client.
'giaddr'について中身を調べる、'要求されたIPアドレス'オプション、およびデータベースルックアップでINIT-REBOOT状態のクライアントが正しいネットワークの一員であるかを決定します。 DHCPサーバがそれを検出するなら、クライアントは間違ったネットにいて(すなわち、地方のサブネットマスクかリモートサブネットマスク('giaddr'がゼロでないなら)を'要求されたIPアドレス'オプション価値に適用するという結果は現実に合っていません)、次に、サーバSHOULDはDHCPNAKメッセージをクライアントに送ります。
Droms Standards Track [Page 31] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[31ページ]。
If the network is correct, then the DHCP server should check if
the client's notion of its IP address is correct. If not, then the
server SHOULD send a DHCPNAK message to the client. If the DHCP
server has no record of this client, then it MUST remain silent,
and MAY output a warning to the network administrator. This
behavior is necessary for peaceful coexistence of non-
communicating DHCP servers on the same wire.
ネットワークが正しいなら、DHCPサーバは、IPアドレスに関するクライアントの概念が正しいかどうかチェックするべきです。 そうでなければ、そして、サーバSHOULDはDHCPNAKメッセージをクライアントに送ります。 DHCPサーバにこのクライアントの記録が全くないなら、それは、静かなままで残らなければならなくて、ネットワーク管理者に警告を出力するかもしれません。 この振舞いが同じワイヤにおける非交信しているDHCPサーバの平和共存に必要です。
If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST broadcast the
DHCPNAK message to the 0xffffffff broadcast address because the
client may not have a correct network address or subnet mask, and
the client may not be answering ARP requests.
'giaddr'がDHCPREQUESTメッセージの0×0であるなら、クライアントはサーバと同じサブネットにいます。クライアントが正しいネットワーク・アドレスかサブネットマスクを持っていないかもしれないので、サーバはDHCPNAKメッセージを0xffffffff放送演説に放送しなければなりません、そして、クライアントはARPに要求に答えていないかもしれません。
If 'giaddr' is set in the DHCPREQUEST message, the client is on a
different subnet. The server MUST set the broadcast bit in the
DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
client, because the client may not have a correct network address
or subnet mask, and the client may not be answering ARP requests.
'giaddr'がDHCPREQUESTメッセージに設定されるなら、クライアントは異なったサブネットにいます。 サーバは放送ビットをDHCPNAKにはめ込まなければなりません、中継エージェントがDHCPNAKをクライアントに放送するように、クライアントが正しいネットワーク・アドレスかサブネットマスクを持っていないかもしれなくて、またクライアントがARPに要求に答えていないかもしれないので。
o DHCPREQUEST generated during RENEWING state:
o RENEWINGの間に生成されたDHCPREQUESTは以下を述べます。
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message will
be unicast, so no relay agents will be involved in its
transmission. Because 'giaddr' is therefore not filled in, the
DHCP server will trust the value in 'ciaddr', and use it when
replying to the client.
'サーバ識別子'に記入してはいけなくて、クライアントのIPアドレスで''オプションに記入してはいけない'要求されたIPアドレスciaddr'に記入しなければなりません。 この状況で、クライアントは、完全に構成されて、リースを広げようとしています。 このメッセージがユニキャストになるので、中継エージェントは全くトランスミッションにかかわらないでしょう。 したがって、'giaddr'が記入されないので、クライアントに答えるとき、DHCPサーバは、'ciaddr'で値を信じて、それを使用するでしょう。
A client MAY choose to renew or extend its lease prior to T1. The
server may choose not to extend the lease (as a policy decision by
the network administrator), but should return a DHCPACK message
regardless.
クライアントは、T1の前でリースを更新するか、または広げるのを選ぶかもしれません。 サーバは、リース(ネットワーク管理者による政策決定としての)を広げないのを選ぶかもしれませんが、不注意にDHCPACKメッセージを返すべきです。
o DHCPREQUEST generated during REBINDING state:
o REBINDINGの間に生成されたDHCPREQUESTは以下を述べます。
'server identifier' MUST NOT be filled in, 'requested IP address'
option MUST NOT be filled in, 'ciaddr' MUST be filled in with
client's IP address. In this situation, the client is completely
configured, and is trying to extend its lease. This message MUST
be broadcast to the 0xffffffff IP broadcast address. The DHCP
server SHOULD check 'ciaddr' for correctness before replying to
the DHCPREQUEST.
'サーバ識別子'に記入してはいけなくて、クライアントのIPアドレスで''オプションに記入してはいけない'要求されたIPアドレスciaddr'に記入しなければなりません。 この状況で、クライアントは、完全に構成されて、リースを広げようとしています。 0xffffffff IP放送演説にこのメッセージを放送しなければなりません。 DHCPサーバSHOULDはDHCPREQUESTに答える前に、正当性がないかどうか'ciaddr'をチェックします。
Droms Standards Track [Page 32] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[32ページ]。
The DHCPREQUEST from a REBINDING client is intended to accommodate
sites that have multiple DHCP servers and a mechanism for
maintaining consistency among leases managed by multiple servers.
A DHCP server MAY extend a client's lease only if it has local
administrative authority to do so.
REBINDINGクライアントからのDHCPREQUESTが複数のサーバでリースの中で一貫性を維持するための複数のDHCPサーバとメカニズムを管理するサイトに対応することを意図します。 それにそうするローカルの管理権威がある場合にだけ、DHCPサーバはクライアントのリースを広げるかもしれません。
4.3.3 DHCPDECLINE message
4.3.3 DHCPDECLINEメッセージ
If the server receives a DHCPDECLINE message, the client has discovered through some other means that the suggested network address is already in use. The server MUST mark the network address as not available and SHOULD notify the local system administrator of a possible configuration problem.
サーバがDHCPDECLINEメッセージを受け取るなら、クライアントは、提案されたネットワーク・アドレスが既に使用中であるとある他の手段で発見しました。 サーバは、利用可能でないとしてネットワークがアドレスであるとマークしなければなりません、そして、SHOULDは可能な設定問題についてローカルシステム管理者に通知します。
4.3.4 DHCPRELEASE message
4.3.4 DHCPRELEASEメッセージ
Upon receipt of a DHCPRELEASE message, the server marks the network address as not allocated. The server SHOULD retain a record of the client's initialization parameters for possible reuse in response to subsequent requests from the client.
DHCPRELEASEメッセージを受け取り次第、サーバは、割り当てられないようにネットワークがアドレスであるとマークします。 サーバSHOULDはクライアントからのその後の要求に対応して可能な再利用のためのクライアントの初期化パラメタに関する記録を保有します。
4.3.5 DHCPINFORM message
4.3.5 DHCPINFORMメッセージ
The server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes other parameters in the DHCPACK message as defined in section 4.3.1.
サーバは、直接DHCPINFORMメッセージの'ciaddr'分野で与えられたアドレスにDHCPACKメッセージを送ることによって、DHCPINFORMメッセージに反応します。 サーバはリース満了時間をクライアントに送ってはいけません、そして、SHOULD NOTは'yiaddr'に記入します。 サーバはセクション4.3.1で定義されるようにDHCPACKメッセージに他のパラメタを含んでいます。
4.3.6 Client messages
4.3.6 クライアントメッセージ
Table 4 details the differences between messages from clients in various states.
テーブル4は様々な州のクライアントからメッセージの違いを詳しく述べます。
--------------------------------------------------------------------- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | --------------------------------------------------------------------- |broad/unicast |broadcast |broadcast |unicast |broadcast | |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | |requested-ip |MUST |MUST |MUST NOT |MUST NOT | |ciaddr |zero |zero |IP address |IP address| ---------------------------------------------------------------------
--------------------------------------------------------------------- | |イニットリブート|選択|更新します。|縛り直すこと| --------------------------------------------------------------------- |広い/ユニキャスト|放送|放送|ユニキャスト|放送| |サーバ-ip|必須NOT|必須|必須NOT|必須NOT| |要求されたip|必須|必須|必須NOT|必須NOT| |ciaddr|ゼロ|ゼロ|IPアドレス|IPアドレス| ---------------------------------------------------------------------
Table 4: Client messages from different states
テーブル4: 異なった州からのクライアントメッセージ
Droms Standards Track [Page 33] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[33ページ]。
4.4 DHCP client behavior
4.4 DHCPクライアントの振舞い
Figure 5 gives a state-transition diagram for a DHCP client. A client can receive the following messages from a server:
図5はDHCPクライアントのために状態遷移ダイヤグラムを与えます。 クライアントはサーバから以下のメッセージを受け取ることができます:
o DHCPOFFER
o DHCPOFFER
o DHCPACK
o DHCPACK
o DHCPNAK
o DHCPNAK
The DHCPINFORM message is not shown in figure 5. A client simply sends the DHCPINFORM and waits for DHCPACK messages. Once the client has selected its parameters, it has completed the configuration process.
DHCPINFORMメッセージは5が中で計算するのが示されません。 クライアントは、単にDHCPINFORMを送って、DHCPACKメッセージを待ちます。 クライアントがいったんパラメタを選択すると、それはコンフィギュレーションプロセスを完成しました。
Table 5 gives the use of the fields and options in a DHCP message by a client. The remainder of this section describes the action of the DHCP client for each possible incoming message. The description in the following section corresponds to the full configuration procedure previously described in section 3.1, and the text in the subsequent section corresponds to the abbreviated configuration procedure described in section 3.2.
テーブル5はクライアントでDHCPメッセージにおける分野とオプションの使用を与えます。 このセクションの残りはそれぞれの可能な入力メッセージのためにDHCPクライアントの動作について説明します。 以下のセクションの記述は以前にセクション3.1で説明された完全な構成手順に対応しています、そして、その後のセクションのテキストはセクション3.2で説明された簡略化された構成手順に一致しています。
Droms Standards Track [Page 34] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[34ページ]。
-------- -------
| | +-------------------------->| |<-------------------+
| INIT- | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | |
| REBOOTING | | | | SELECTING |<----+ |
| | | / | | |DHCPOFFER/ |
----------- | / ----------- | |Collect |
| | / | | | replies |
DHCPACK/ | / +----------------+ +-------+ |
Record lease, set| | v Select offer/ |
timers T1, T2 ------------ send DHCPREQUEST | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | |
to leasing server | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figure 5: State-transition diagram for DHCP clients
-------- ------- | | +-------------------------->| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ | イニット| | +-------------------->| イニット| | | リブート|DHCPNAK/+---------->| | <、-、--+ | | |再開| | ------- | | -------- | DHCPNAK/| | | | 申し出を捨ててください。| -/はDHCPDISCOVERを送ります。| -/はDHCPREQUESTを送ります。| | | | | | DHCPACK v| | ----------- | (受け入れません。)/ ----------- | | | | | DHCPDECLINEを送ってください。| | | | リブートします。| | | | 選択| <、-、-、--+ | | | | / | | |DHCPOFFER/| ----------- | / ----------- | |集まってください。| | | / | | | 返信| DHCPACK/| / +----------------+ +-------+ | 設定されて、リースを記録してください。| | Select申し出/に対して| タイマT1、T2------------ DHCPREQUESTを送ってください。| | | +----->|、| DHCPNAK、Leaseの満期の/| | | | 要求| 停止ネットワーク| DHCPOFFER/| | | | 破棄------------ | | | | | | ----------- | | +--------+ DHCPACK/| | | | 設定されて、リースを記録してください。-----| 縛り直すこと| | | タイマT1、T2/| | | | | DHCPACK/----------- | | Recordリースに対して、^を設定してください。| +---------------->。------- /タイマT1、T2| | +----->| | <、-、--+ | | | | 縛られます。| <、-、--+ | | DHCPOFFER、DHCPACK| | | T2は/DHCPNAK/DHCPNAK/破棄を吐き出します。------- | 放送Haltネットワーク| | | | DHCPREQUEST| +-------+ | DHCPACK/| | 設定されて、T1はリースを吐き出すか、または記録します。| | DHCPREQUESTタイマT1、T2を送ってください。| | サーバを賃貸するのに| | | | ---------- | | | | |------------+ | +->| 更新します。| | | |----------------------------+ ---------- 図5: DHCPクライアントのための状態遷移ダイヤグラム
Droms Standards Track [Page 35] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[35ページ]。
4.4.1 Initialization and allocation of network address
4.4.1 ネットワーク・アドレスの初期設定と配分
The client begins in INIT state and forms a DHCPDISCOVER message. The client SHOULD wait a random time between one and ten seconds to desynchronize the use of DHCP at startup. The client sets 'ciaddr' to 0x00000000. The client MAY request specific parameters by including the 'parameter request list' option. The client MAY suggest a network address and/or lease time by including the 'requested IP address' and 'IP address lease time' options. The client MUST include its hardware address in the 'chaddr' field, if necessary for delivery of DHCP reply messages. The client MAY include a different unique identifier in the 'client identifier' option, as discussed in section 4.2. If the client included a list of requested parameters in a DHCPDISCOVER message, it MUST include that list in all subsequent messages.
クライアントは、INIT状態で始まって、DHCPDISCOVERメッセージを形成します。 クライアントSHOULDは始動でDHCPの使用を反連動させる1〜10秒の無作為の時間を待っています。 クライアントは'ciaddr'を0×00000000に設定します。 クライアントは、'パラメタ要求リスト'オプションを含んでいることによって、特定のパラメタを要求するかもしれません。 クライアントは、'要求されたIPアドレス'と'IPアドレスリース時間'オプションを含んでいることによって、ネットワーク・アドレス、そして/または、リース時間を勧めるかもしれません。 クライアントは必要ならDHCP応答メッセージの配送のための'chaddr'分野でハードウェア・アドレスを入れなければなりません。 クライアントはセクション4.2で議論するように'クライアント識別子'オプションで異なったユニークな識別子を入れるかもしれません。 クライアントがDHCPDISCOVERメッセージで要求されたパラメタのリストを入れたなら、それはすべてのその後のメッセージにそのリストを含まなければなりません。
The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client records its own local time for later use in computing the lease expiration. The client then broadcasts the DHCPDISCOVER on the local hardware broadcast address to the 0xffffffff IP broadcast address and 'DHCP server' UDP port.
クライアントは、無作為のトランザクション識別子を生成して、記録して、'xid'分野にその識別子を挿入します。 クライアントは自分自身リース満了を計算することにおける後の使用のための現地時間ののを記録します。 そして、クライアントはローカルのハードウェア放送演説で0xffffffff IP放送演説と'DHCPサーバ'UDPポートにDHCPDISCOVERを放送します。
If the 'xid' of an arriving DHCPOFFER message does not match the 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message must be silently discarded. Any arriving DHCPACK messages must be silently discarded.
到着しているDHCPOFFERメッセージの'xid'が最新のDHCPDISCOVERメッセージの'xid'に合っていないなら、静かにDHCPOFFERメッセージを捨てなければなりません。 静かにどんな到着しているDHCPACKメッセージも捨てなければなりません。
The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the 'server identifier' option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent.
クライアントは、期間の間、DHCPOFFERメッセージを集めて、(ことによると多く)の入って来るDHCPOFFERメッセージ(例えば、最初のDHCPOFFERメッセージか以前中古のサーバからのDHCPOFFERメッセージ)から1つのDHCPOFFERメッセージを選択して、DHCPOFFERメッセージにおける'サーバ識別子'オプションからサーバアドレスを抜粋します。 クライアントが集めるタイム・オーバーは通信します、そして、あるDHCPOFFERを選択するのに使用されるメカニズムは実装に依存しています。
Droms Standards Track [Page 36] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[36ページ]。
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client 'xid' from server selected by
DHCPOFFER message client
'secs' 0 or seconds since 0 or seconds since 0
DHCP process started DHCP process started
'flags' Set 'BROADCAST' Set 'BROADCAST' 0
flag if client flag if client
requires broadcast requires broadcast
reply reply
'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
client's network address client's network
network address (BOUND/RENEW/REBIND) address
(DHCPINFORM) (DHCPRELEASE)
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'options' options options (unused)
分野DHCPDISCOVER DHCPREQUEST DHCPDECLINE、DHCPINFORM DHCPRELEASE----- ------------ ----------- ----------- オプションであるなら、示されるなら(未使用の)、'sname/で示されるところでは、''sname/ファイル'オプションをファイルしてください。 そうでなければ、オプション。 'オプションであるなら示されるなら(未使用の)'sname/ファイル'で示されるところに'オプションをファイルしてください'というそうでなければ、未使用の未使用のsname/ファイル'オプション。 そうでなければ、オプション。 そうでなければ、未使用の未使用の'オプション'オプションオプション(未使用)です。
Droms Standards Track [Page 37] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[37ページ]。
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST (in MUST
(DISCOVER) SELECTING or (DHCPDECLINE),
MUST NOT INIT-REBOOT) MUST NOT
(INFORM) MUST NOT (in (DHCPRELEASE)
BOUND or
RENEWING)
IP address lease time MAY MAY MUST NOT
(DISCOVER)
MUST NOT
(INFORM)
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
DHCPINFORM DHCPRELEASE
Client identifier MAY MAY MAY
Vendor class identifier MAY MAY MUST NOT
Server identifier MUST NOT MUST (after MUST
SELECTING)
MUST NOT (after
INIT-REBOOT,
BOUND, RENEWING
or REBINDING)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MAY MAY MUST NOT
オプションDHCPDISCOVER DHCPREQUEST DHCPDECLINE、DHCPINFORM DHCPRELEASE------ ------------ ----------- ----------- 5月がそうしなければならないIPアドレスが要求した、(コネがタイプしなければならない、(DISCOVER) SELECTINGか(DHCPDECLINE)、MUST NOT INIT-REBOOT)(INFORM)使用ではなく、5月の5月の時間がそうしてはいけないIPアドレスリース(DISCOVER)がそうしなければならないNOT((DHCPRELEASE)BOUNDかRENEWINGの)が(INFORM)でないのも'ファイルする'か、または'snameしなければならない'というMAY MAY MAY DHCPが通信させる分野はDHCPDISCOVER/DHCPREQUEST DHCPDECLINE/DHCPINFORM DHCPRELEASE Clientをタイプしなければなりません; Maximumメッセージサイズではなく、(後INIT-REBOOT、BOUND、RENEWINGまたはREBINDING)パラメタ要求リスト5月の5月ではなく、Server識別子ではなく、5月の5月がそうしなければならない識別子がそうしてはいけないVendorのクラスがそうしなければならない5月(後MUST SELECTING)がそうしなければならない5月の5月がそうしなければならない識別子は5月の5月がそうしてはいけないMessage SHOULD NOT SHOULD NOT SHOULD Site-詳細All他のものではなく、5月の5月の5月がそうしなければならない5月にそうしてはいけません。
Table 5: Fields and options used by DHCP clients
テーブル5: DHCPクライアントによって使用された分野とオプション
If the parameters are acceptable, the client records the address of the server that supplied the parameters from the 'server identifier' field and sends that address in the 'server identifier' field of a DHCPREQUEST broadcast message. Once the DHCPACK message from the server arrives, the client is initialized and moves to BOUND state. The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER message. The client records the lease expiration time as the sum of the time at which the original request was sent and the duration of the lease from the DHCPACK message. The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the
パラメタが許容できるなら、クライアントは'サーバ識別子'分野からパラメタを提供して、DHCPREQUEST同報メッセージの'サーバ識別子'分野でそのアドレスを送るサーバのアドレスを記録します。 サーバからのDHCPACKメッセージがいったん到着すると、クライアントは、初期化されて、BOUND状態に移行します。 DHCPREQUESTメッセージはDHCPOFFERメッセージと同じ'xid'を含んでいます。 クライアントはオリジナルの要求が送られた時の合計とリースの持続時間としてDHCPACKメッセージからリース満了時間を記録します。 クライアントSHOULDは、アドレスが確実に既に使用中にならないようにするために提案されたアドレスにチェックを実行します。 例えば、クライアントがARPをサポートするネットワークの一員であるなら、クライアントは提案された要求に関するARP要求を出すかもしれません。 提案されたアドレスを求めるARP要求を放送するとき、クライアントは、同じサブネットで他のホストでARPキャッシュを混乱させるのを避けるために送付者のハードウェア・アドレスとしてそれ自身のハードウェア・アドレスに記入して、送付者のIPアドレスとして0に記入しなければなりません。 the
Droms Standards Track [Page 38] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[38ページ]。
network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet.
ネットワーク・アドレスは使用中であるように見えて、クライアントはDHCPDECLINEメッセージをサーバに送らなければなりません。クライアントSHOULDは、クライアントの新しいIPアドレスを発表して、クライアントのサブネットでホストのどんな時代遅れのARPキャッシュエントリーもクリアするためにARP回答を放送します。
4.4.2 Initialization with known network address
4.4.2 知られているネットワーク・アドレスによる初期設定
The client begins in INIT-REBOOT state and sends a DHCPREQUEST message. The client MUST insert its known network address as a 'requested IP address' option in the DHCPREQUEST message. The client may request specific configuration parameters by including the 'parameter request list' option. The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client records its own local time for later use in computing the lease expiration. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. The client then broadcasts the DHCPREQUEST on the local hardware broadcast address to the 'DHCP server' UDP port.
クライアントは、INIT-REBOOT状態で始まって、DHCPREQUESTメッセージを送ります。 クライアントは'要求されたIPアドレス'オプションとして知られているネットワーク・アドレスをDHCPREQUESTメッセージに挿入しなければなりません。 クライアントは、'パラメタ要求リスト'オプションを含んでいることによって、特定の設定パラメータを要求するかもしれません。 クライアントは、無作為のトランザクション識別子を生成して、記録して、'xid'分野にその識別子を挿入します。 クライアントは自分自身リース満了を計算することにおける後の使用のための現地時間ののを記録します。 クライアントはDHCPREQUESTメッセージで'サーバ識別子'を入れてはいけません。 そして、クライアントはローカルのハードウェア放送演説で'DHCPサーバ'UDPポートにDHCPREQUESTを放送します。
Once a DHCPACK message with an 'xid' field matching that in the client's DHCPREQUEST message arrives from any server, the client is initialized and moves to BOUND state. The client records the lease expiration time as the sum of the time at which the DHCPREQUEST message was sent and the duration of the lease from the DHCPACK message.
'xid'分野がクライアントのDHCPREQUESTメッセージでそれに合っているDHCPACKメッセージがどんなサーバからもいったん到着すると、クライアントは、初期化されて、BOUND状態に移行します。 クライアントはDHCPREQUESTメッセージが送られた時の合計とリースの持続時間としてDHCPACKメッセージからリース満了時間を記録します。
4.4.3 Initialization with an externally assigned network address
4.4.3 外部的に割り当てられたネットワーク・アドレスによる初期設定
The client sends a DHCPINFORM message. The client may request specific configuration parameters by including the 'parameter request list' option. The client generates and records a random transaction identifier and inserts that identifier into the 'xid' field. The client places its own network address in the 'ciaddr' field. The client SHOULD NOT request lease time parameters.
クライアントはDHCPINFORMメッセージを送ります。 クライアントは、'パラメタ要求リスト'オプションを含んでいることによって、特定の設定パラメータを要求するかもしれません。 クライアントは、無作為のトランザクション識別子を生成して、記録して、'xid'分野にその識別子を挿入します。 クライアントは'ciaddr'分野にそれ自身のネットワーク・アドレスを置きます。 クライアントSHOULD NOTはリース時間パラメタを要求します。
The client then unicasts the DHCPINFORM to the DHCP server if it knows the server's address, otherwise it broadcasts the message to the limited (all 1s) broadcast address. DHCPINFORM messages MUST be directed to the 'DHCP server' UDP port.
DHCPサーバへのDHCPINFORMはそれであるならサーバのアドレスを知っています。クライアントの当時のユニキャスト、さもなければ、それは限られた(すべての1)放送演説にメッセージを放送します。 'DHCPサーバ'UDPポートにDHCPINFORMメッセージを向けなければなりません。
Once a DHCPACK message with an 'xid' field matching that in the client's DHCPINFORM message arrives from any server, the client is initialized.
'xid'分野がクライアントのDHCPINFORMメッセージでそれに合っているDHCPACKメッセージがどんなサーバからもいったん到着すると、クライアントは初期化されます。
If the client does not receive a DHCPACK within a reasonable period of time (60 seconds or 4 tries if using timeout suggested in section 4.1), then it SHOULD display a message informing the user of the problem, and then SHOULD begin network processing using suitable
クライアントは適正な期間以内にDHCPACKを受け取らないで(セクション4.1で示されたタイムアウトを使用するなら、60秒か4秒が試みます)、次に、それはディスプレイaメッセージが適当なネットワーク処理使用を始めることを問題、および次に、SHOULDのユーザに知らせるSHOULDです。
Droms Standards Track [Page 39] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[39ページ]。
defaults as per Appendix A.
Appendix Aに従ってデフォルト。
4.4.4 Use of broadcast and unicast
4.4.4 放送とユニキャストの使用
The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages, unless the client knows the address of a DHCP server. The client unicasts DHCPRELEASE messages to the server. Because the client is declining the use of the IP address supplied by the server, the client broadcasts DHCPDECLINE messages.
DHCPクライアントはDHCPDISCOVER、DHCPREQUEST、およびDHCPINFORMメッセージを放送します、クライアントがDHCPサーバのアドレスを知らない場合。クライアントユニキャストDHCPRELEASEはサーバへ通信します。クライアントがサーバによって供給されたIPアドレスの使用を断っているので、クライアントはDHCPDECLINEメッセージを放送します。
When the DHCP client knows the address of a DHCP server, in either INIT or REBOOTING state, the client may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. The client may also use unicast to send DHCPINFORM messages to a known DHCP server. If the client receives no response to DHCP messages sent to the IP address of a known DHCP server, the DHCP client reverts to using the IP broadcast address.
DHCPクライアントがINITかREBOOTING状態のどちらかでDHCPサーバのアドレスを知っているとき、クライアントはIP放送演説よりむしろDHCPDISCOVERかDHCPREQUESTのそのアドレスを使用するかもしれません。 また、クライアントは、知られているDHCPサーバへのメッセージをDHCPINFORMに送るのにユニキャストを使用するかもしれません。クライアントが知られているDHCPサーバのIPアドレスに送られたDHCPメッセージへの応答を全く受けないなら、DHCPクライアントはIP放送演説を使用するのに先祖帰りをします。
4.4.5 Reacquisition and expiration
4.4.5 Reacquisitionと満了
The client maintains two times, T1 and T2, that specify the times at which the client tries to extend its lease on its network address. T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server. T1 MUST be earlier than T2, which, in turn, MUST be earlier than the time at which the client's lease will expire.
クライアントは2回、T1、およびT2を維持して、それはクライアントがネットワーク・アドレスでリースを広げようとする回を指定します。 T1はクライアントがRENEWING状態に入って、元々クライアントのネットワーク・アドレスを発行したサーバに連絡するのを試みる時です。 T2はクライアントがREBINDING状態に入って、サーバいずれもT1 MUSTに連絡するのを試みる時です。クライアントのリースが期限が切れる時より順番に初期でなければならないどちらというT2より早くいてくださいか。
To avoid the need for synchronized clocks, T1 and T2 are expressed in options as relative times [2].
連動している時計の必要性を避けるために、T1とT2は相対的な時勢[2]としてオプションで急送されます。
At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message.
時間T1のときに、クライアントは、RENEWING状態に移行して、リースを広げるためにDHCPREQUESTメッセージをサーバに送ります(ユニキャストで)。 クライアントは'ciaddr'分野を現在のネットワーク・アドレスへのDHCPREQUESTにはめ込みます。 クライアントはDHCPREQUESTメッセージがリース満了時間の計算のために送られる現地時間を記録します。 クライアントはDHCPREQUESTメッセージで'サーバ識別子'を入れてはいけません。
Any DHCPACK messages that arrive with an 'xid' that does not match the 'xid' of the client's DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message. The client has successfully reacquired its network address, returns to BOUND state and may continue network processing.
クライアントのDHCPREQUESTメッセージの'xid'に合っていない'xid'と共に到着するどんなDHCPACKメッセージも静かに捨てられます。 クライアントがサーバからDHCPACKを受け取るとき、クライアントはクライアントがDHCPREQUESTメッセージを送った時の合計とDHCPACKメッセージにおけるリースの持続時間としてリース満了時間を計算します。 クライアントは、首尾よくネットワーク・アドレスを再取得して、BOUND状態に戻って、ネットワーク処理を続けるかもしれません。
Droms Standards Track [Page 40] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[40ページ]。
If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message.
どんなDHCPACKも時間T2の前で到着しないなら、クライアントは、REBINDING状態に移行して、リースを広げるDHCPREQUESTメッセージを送ります(放送で)。 クライアントは'ciaddr'分野を現在のネットワーク・アドレスへのDHCPREQUESTにはめ込みます。 クライアントはDHCPREQUESTメッセージで'サーバ識別子'を入れてはいけません。
Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition.
回のT1とT2はサーバでオプションで構成可能です。 T1は(_リースの0.5*持続時間_)をデフォルトとします。 T2は(_リースの0.875*持続時間_)をデフォルトとします。 回のT1とT2 SHOULD、一定の価値の周りにいくつかの無作為の「むく毛」がある状態で選ばれて、クライアント「再-獲得」の同期を避けてください。
A client MAY choose to renew or extend its lease prior to T1. The server MAY choose to extend the client's lease according to policy set by the network administrator. The server SHOULD return T1 and T2, and their values SHOULD be adjusted from their original values to take account of the time remaining on the lease.
クライアントは、T1の前でリースを更新するか、または広げるのを選ぶかもしれません。 サーバは、方針セットに従ってネットワーク管理者でクライアントのリースを広げるのを選ぶかもしれません。 サーバSHOULDはT1、T2、およびそれらの値のSHOULDを返します。それらの元の値から調整されて、リースに残りながら、時間を考慮に入れてください。
In both RENEWING and REBINDING states, if the client receives no response to its DHCPREQUEST message, the client SHOULD wait one-half of the remaining time until T2 (in RENEWING state) and one-half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message.
RENEWINGとREBINDING州の両方では、クライアントがDHCPREQUESTメッセージへの応答を全く受けないなら、クライアントSHOULDは残っている時のT2(RENEWING状態の)と残りの半分が時間(REBINDING状態の)を賃貸するまでの半分のときに待ちます、最低60秒まで、DHCPREQUESTメッセージを再送する前に。
If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem.
クライアントがDHCPACKを受け取る前にリースが期限が切れるなら、クライアントは、INIT状態に移行して、すぐに、いかなる他のネットワーク処理も止めなければならなくて、まるでクライアントが非初期化されるかのようにネットワーク初期化パラメタを要求します。 次に、クライアントが前のネットワーク・アドレスをそのクライアントに割り当てながらDHCPACKを受け取るなら、クライアントSHOULDはネットワーク処理を続けています。 新しいネットワーク・アドレスをクライアントに与えるなら、前のネットワーク・アドレスを使用し続けてはいけません、そして、SHOULDは問題について地元のユーザに通知します。
4.4.6 DHCPRELEASE
4.4.6 DHCPRELEASE
If the client no longer requires use of its assigned network address (e.g., the client is gracefully shut down), the client sends a DHCPRELEASE message to the server. Note that the correct operation of DHCP does not depend on the transmission of DHCPRELEASE messages.
クライアントがもう割り当てられたネットワーク・アドレスの使用を必要としないなら(例えばクライアントは優雅に止められます)、クライアントはDHCPRELEASEメッセージをサーバに送ります。DHCPの正しい操作がDHCPRELEASEメッセージの伝達によらないことに注意してください。
Droms Standards Track [Page 41] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[41ページ]。
5. Acknowledgments
5. 承認
The author thanks the many (and too numerous to mention!) members of the DHC WG for their tireless and ongoing efforts in the development of DHCP and this document.
作者はDHCPとこのドキュメントの開発における彼らの精力的で進行中の取り組みについてDHC WGの多くの(そして、言及できないくらい多数です!)メンバーに感謝します。
The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John Mendonca in organizing DHCP interoperability testing sessions are gratefully acknowledged.
DHCP相互運用性テストセッションを計画することにおけるJアラード、マイク・カーニー、デーヴLapp、フレッドLien、およびジョンMendoncaの取り組みは感謝して承認されます。
The development of this document was supported in part by grants from the Corporation for National Research Initiatives (CNRI), Bucknell University and Sun Microsystems.
このドキュメントの開発はNational Research Initiatives(CNRI)、Bucknell大学、およびサン・マイクロシステムズのために社から交付金で一部後押しされていました。
6. References
6. 参照
[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
1983.
[1]Acetta、M.、「リソース位置のプロトコル」、RFC887、米カーネギーメロン大学、1983年12月。
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[2] アレクサンダー、S.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC1533、ラックマン技術Inc.、Bucknell大学(1993年10月)。
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, USC/Information Sciences
Institute, October 1989.
[3] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、STD3、RFC1122、科学が設けるUSC/情報、10月1989日
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC 1123, USC/Information
Sciences Institute, October 1989.
[4] ブレーデン、R.、エディタ、「インターネットホストのための要件--アプリケーションとサポート、STD3、RFC1123、USC/情報科学研究所(1989インチ年10月)。
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
[5] ブラウネル、D、「ダイナミックな逆アドレス解決プロトコル(DRARP)」は進行中で働いています。
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
[6] 新来者、D.とR.Droms、「インターネットディレクトリサービスへの一定のアクセス」Proc20(4): 50--59、1990ACM SIGCOMM90年(コンピュータCommunications Reviewの増刊)、年について。
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[7] 耕地、B.とJ.ギルモアと「プロトコル(BOOTP)を独力で進んでください」とRFC951とスタンフォードと太陽マイクロシステムズ、1985年9月。
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
PARC, September 1991.
[8] デアリング、S.、「ICMPルータ発見メッセージ」、RFC1256、ゼロックスPARC、1991年9月。
[9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
[9]Droms、D.、「DHCPとBOOTPの間のInteroperation」、RFC1534、Bucknell大学、1993年10月。
Droms Standards Track [Page 42] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[42ページ]。
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC 903, Stanford, June 1984.
[10] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」RFC903、スタンフォード、1984年6月。
[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989.
[11] グレーC.、およびD.Cheritonは「以下を賃貸します」。 「分配されたファイルのための効率的なフォールトトレラントメカニズムは一貫性をキャッシュします」、Procで。. オペレーティングシステムデザイン、1989に関する第12ACMシンポジウムについて。
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, USC/Information Sciences Institute, November 1987.
[12]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、科学が設けるUSC/情報、11月1987日
[13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, USC/Information Sciences
Institute, November 1987.
[13]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、科学が設けるUSC/情報、11月1987日
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[14] ムガール人J.、およびS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress.
[15] モーガン、R.、「イーサネットの付属ホストのためのダイナミックなIPアドレス課題」が進行中で働いています。
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[16] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、科学が1981年9月に設けるUSC/情報。
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
USC/Information Sciences Institute, August 1993.
[17] レイノルズ、J.、「BOOTP売り主情報拡張子」、USC/情報科学が1993年8月に設けるRFC1497。
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[18] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989.
[19] ジェフリー・シラーとマークローゼンスタイン。 イーサネットにおける使用のためのIP AddressesのDynamic Assignmentのためのプロトコル。 (アティナプロジェクト、MITから利用可能)です。, 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
June 1981.
[20]Sollins、K.、「TFTPプロトコル(改正2)」、RFC783、NIC、1981年6月。
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
[21]Wimer、W.、「明確化と拡大、プロトコルを独力で進んでください、」、RFC1542、カーネギメロン大学、10月1993
7. Security Considerations
7. セキュリティ問題
DHCP is built directly on UDP and IP which are as yet inherently insecure. Furthermore, DHCP is generally intended to make maintenance of remote and/or diskless hosts easier. While perhaps not impossible, configuring such hosts with passwords or keys may be difficult and inconvenient. Therefore, DHCP in its current form is quite insecure.
DHCPは直接本来まだ不安定なUDPとIPに造られます。 その上、一般に、DHCPがリモートな、そして/または、ディスクレスなホストのメインテナンスをより簡単にすることを意図します。 恐らく不可能でない間、パスワードかキーでそのようなホストを構成するのは、難しくて、不便であるかもしれません。 したがって、現在のフォームでのDHCPはかなり不安定です。
Droms Standards Track [Page 43] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[43ページ]。
Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on. Clearly, once this seed information is in place, an attacker can further compromise affected systems.
権限のないDHCPサーバは容易にセットアップされるかもしれません。 そのようなサーバは、次に、不正確であるように誤って潜在的に破壊的な情報をクライアントに送るか、またはIPアドレス、不正確なルーティング情報(パロディールータなどを含んでいる)、不正確なドメインネームサーバアドレス(パロディーネームサーバなどの)などをコピーできます。 明確に、この種子情報が適所にいったんあると、攻撃者はさらに影響を受けるシステムに感染することができます。
Malicious DHCP clients could masquerade as legitimate clients and retrieve information intended for those legitimate clients. Where dynamic allocation of resources is used, a malicious client could claim all resources for itself, thereby denying resources to legitimate clients.
悪意があるDHCPクライアントは、正統のクライアントのふりをして、それらの正統のクライアントのために意図する情報を検索できました。 リソースの動的割当てが使用されているところでは、悪意があるクライアントはすべてのリソースのそれ自体に代金を請求することができました、その結果、正統のクライアントに対してリソースを否定します。
8. Author's Address
8. 作者のアドレス
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
ラルフDromsコンピュータ理学部323ダナ・工学Bucknell大学リューイスバーグ、PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
以下に電話をしてください。 (717) 524-1145 メールしてください: droms@bucknell.edu
Droms Standards Track [Page 44] RFC 2131 Dynamic Host Configuration Protocol March 1997
Droms規格は1997年のDynamic Host Configuration Protocol行進のときにRFC2131を追跡します[44ページ]。
A. Host Configuration Parameters
A。 ホスト設定パラメータ
IP-layer_parameters,_per_host:_
IP層_パラメタ、_ホストあたりの_: _
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
6 サブネットマスク(アドレスマスク)HRC3.3.1.6MTU整数HRC3.3.3AllサブネットMTUオンであるかオフなHRC3.3.3Broadcastは、HRC3.2.2.9Performルータ発見オンであるかオフなRD5.1Router懇願アドレス(アドレス)RD5.1Defaultルータで/で風味0×00000000/0xffffffff HRC3.3.6Performマスク発見オンであるかオフなHRC3.2.2.9Beがマスク供給者であると扱います、以下のリスト ルータアドレス(アドレス)HRC3.3.1.6好みのレベル整数HRC3.3.1.6のStaticルート、以下のリスト 目的地(ホスト/サブネット/ネット)のHRC3.3.1.2目的地マスク(アドレスマスク)HRC3.3.1.2サービスのタイプ整数HRC3.3.1.2が最初にルータ(アドレス)HRCを飛び越す、3.3、.1、.2、無視、/では、HRC3.3.1で/オフMTU6.6にMTU6.6がPMTU発見を実行する.2PMTU整数を向け直します。
Link-layer_parameters,_per_interface:_ Trailers on/off HRC 2.3.1 ARP cache timeout integer HRC 2.3.2.1 Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
リンクレイヤ_パラメタ、_インタフェースあたりの_: _TrailersオンであるかオフなHRC2.3.1ARPキャッシュタイムアウト整数HRC2.3.2.1イーサネットカプセル化(RFC894/RFC1042)HRC2.3.3
TCP_parameters,_per_host:_ TTL integer HRC 4.2.2.19 Keep-alive interval integer HRC 4.2.3.6 Keep-alive data size 0/1 HRC 4.2.3.6
TCP_パラメタ、_ホストあたりの_: _TTL整数HRC4.2.2.19は間隔整数HRC4.2.3.6生きているKeepデータサイズ0/1HRC4.2.3.6を生かします。
Key:
キー:
MTU = Path MTU Discovery (RFC 1191, Proposed Standard) RD = Router Discovery (RFC 1256, Proposed Standard)
MTUは経路MTU発見(RFC1191、提案された標準)=ルータ第発見と等しいです。(RFC1256標準で提案されて、
Droms Standards Track [Page 45]
Droms標準化過程[45ページ]
一覧
スポンサーリンク
