📄 draft-ietf-dhc-dhcpv6-28.txt
字号:
SOL_TIMEOUT 1 sec Initial Solicit timeout SOL_MAX_RT 120 secs Max Solicit timeout value REQ_TIMEOUT 1 sec Initial Request timeout REQ_MAX_RT 30 secs Max Request timeout value REQ_MAX_RC 10 Max Request retry attempts CNF_MAX_DELAY 1 sec Max delay of first Confirm CNF_TIMEOUT 1 sec Initial Confirm timeout CNF_MAX_RT 4 secs Max Confirm timeout CNF_MAX_RD 10 secs Max Confirm duration REN_TIMEOUT 10 secs Initial Renew timeout REN_MAX_RT 600 secs Max Renew timeout value REB_TIMEOUT 10 secs Initial Rebind timeout REB_MAX_RT 600 secs Max Rebind timeout value INF_MAX_DELAY 1 sec Max delay of first Information-request INF_TIMEOUT 1 sec Initial Information-request timeout INF_MAX_RT 120 secs Max Information-request timeout value REL_TIMEOUT 1 sec Initial Release timeout REL_MAX_RC 5 MAX Release attempts DEC_TIMEOUT 1 sec Initial Decline timeout DEC_MAX_RC 5 Max Decline attempts REC_TIMEOUT 2 secs Initial Reconfigure timeout REC_MAX_RC 8 Max Reconfigure attempts HOP_COUNT_LIMIT 32 Max hop count in a Relay-forward messageDroms (ed.), et al. Expires 30 Apr 2003 [Page 10] Internet Draft DHCP for IPv6 (-28) 2 Nov 20026. Client/Server Message Formats All DHCP messages sent between clients and servers share an identical fixed format header and a variable format area for options. All values in the message header and in options are in network byte order. Options are stored serially in the options field, with no padding between the options. Options are byte-aligned but are not aligned in any other way such as on 2 or 4 byte boundaries. The following diagram illustrates the format of DHCP messages sent between clients and servers: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | transaction-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type Identifies the DHCP message type; the available message types are listed in section 5.3. transaction-id The transaction ID for this message exchange. options Options carried in this message; options are described in section 22.7. Relay Agent/Server Message Formats Relay agents exchange messages with servers to relay messages between clients and servers that are not connected to the same link. All values in the message header and in options are in network byte order. Options are stored serially in the options field, with no padding between the options. Options are byte-aligned but are not aligned in any other way such as on 2 or 4 byte boundaries.Droms (ed.), et al. Expires 30 Apr 2003 [Page 11] Internet Draft DHCP for IPv6 (-28) 2 Nov 2002 There are two relay agent messages, which share the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type | hop-count | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | link-address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | peer-address | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following sections describe the use of the Relay Agent message header.7.1. Relay-forward Message The following table defines the use of message fields in a Relay-forward message. msg-type RELAY-FORW hop-count Number of relay agents that have relayed this message link-address A global or site-local address that will be used by the server to identify the link on which the client is located. peer-address The address of the client or relay agent from which the message to be relayed was received options MUST include a "Relay Message option" (see section 22.10); MAY include other options added by the relay agentDroms (ed.), et al. Expires 30 Apr 2003 [Page 12] Internet Draft DHCP for IPv6 (-28) 2 Nov 20027.2. Relay-reply Message The following table defines the use of message fields in a Relay-reply message. msg-type RELAY-REPL hop-count Copied from the Relay-forward message link-address Copied from the Relay-forward message peer-address Copied from the Relay-forward message options MUST include a "Relay Message option"; see section 22.10; MAY include other options8. Representation and Use of Domain Names So that domain names may be encoded uniformly, a domain name or a list of domain names is encoded using the technique described in section 3.1 of RFC1035 [14]. A domain name or list of domain names in DHCP MUST NOT be stored in compressed form as described in section 4.1.4 of RFC1035.9. DHCP Unique Identifier (DUID) Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified. See sections 22.2 and 22.3 for the representation of a DUID in a DHCP message. Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs. Clients and servers MUST NOT restrict DUIDs to the types defined in this document as additional DUID types may be defined in the future. The DUID is carried in an option because it may be variable length and because it is not required in all DHCP messages. The DUID is designed to be unique across all DHCP clients and servers, and stable for any specific client or server - that is, the DUID used by a client or server SHOULD NOT change over time if at all possible; for example, a device's DUID should not change as a result of a change in the device's network hardware. The motivation for having more than one type of DUID is that the DUID must be globally unique, and must also be easy to generate. The sort of globally-unique identifier that is easy to generate for any given device can differ quite widely. Also, some devices may not containDroms (ed.), et al. Expires 30 Apr 2003 [Page 13] Internet Draft DHCP for IPv6 (-28) 2 Nov 2002 any persistent storage. Retaining a generated DUID in such a device is not possible, so the DUID scheme must accommodate such devices.9.1. DUID Contents A DUID consists of a two-octet type code represented in network byte order, followed by a variable number of octets that make up the actual identifier. A DUID can be no more than 128 octets long (not including the type code). The following types are currently defined: 1 Link-layer address plus time 2 Vendor-assigned unique ID based on Enterprise Number 3 Link-layer address Formats for the variable field of the DUID for each of the above types are shown below.9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT] This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC826 [18]. Both the time and the hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC2464 [4]. The following diagram illustrates the format of a DUID-LLT: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | hardware type (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The choice of network interface can be completely arbitrary, as long as that interface provides a globally unique link-layer address for the link type, and the same DUID-LLT SHOULD be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID-LLT.Droms (ed.), et al. Expires 30 Apr 2003 [Page 14] Internet Draft DHCP for IPv6 (-28) 2 Nov 2002 Clients and servers using this type of DUID MUST store the DUID-LLT in stable storage, and MUST continue to use this DUID-LLT even if the network interface used to generate the DUID-LLT is removed. Clients and servers that do not have any stable storage MUST NOT use this type of DUID. Clients and servers that use this DUID SHOULD attempt to configure the time prior to generating the DUID, if that is possible, and MUST use some sort of time source (for example, a real-time clock) in generating the DUID, even if that time source could not be configured prior to generating the DUID. The use of a time source makes it unlikely that two identical DUID-LLTs will be generated if the network interface is removed from the client and another client then uses the same network interface to generate a DUID-LLT. A collision between two DUID-LLTs is very unlikely even if the clocks haven't been configured prior to generating the DUID.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -