idnits 2.17.1 draft-ietf-dhc-dhcpv6exts-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 6) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '... SHOULD, MAY, MUST NOT, etc) are oft...' RFC 2119 keyword, line 163: '... it MUST still be specified. There ...' RFC 2119 keyword, line 165: '...to this document MUST contain a two-oc...' RFC 2119 keyword, line 168: '...nized extensions MUST be silently igno...' RFC 2119 keyword, line 172: '... implementations MUST assume that that...' (99 more instances...) -- The draft header indicates that this document obsoletes draft-ietf-dhc-dhcpv6exts-11.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- No information found for rfcdraft-ietf-dhc-dhcpv6exts-11.txt - is the name correct? -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (5 May 2000) is 8756 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Offset' on line 776 ** Obsolete normative reference: RFC 1533 (ref. '1') (Obsoleted by RFC 2132) ** Obsolete normative reference: RFC 1826 (ref. '2') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-15 ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '6') == Outdated reference: A later version (-08) exists of draft-ietf-ipngwg-dns-lookups-07 ** Downref: Normative reference to an Historic draft: draft-ietf-ipngwg-dns-lookups (ref. '7') ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2402 (ref. '11') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '12') ** Obsolete normative reference: RFC 2030 (ref. '13') (Obsoleted by RFC 4330) ** Downref: Normative reference to an Informational RFC: RFC 1129 (ref. '14') ** Obsolete normative reference: RFC 1305 (ref. '15') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '18') ** Obsolete normative reference: RFC 2462 (ref. '19') (Obsoleted by RFC 4862) Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Bound 2 INTERNET DRAFT Compaq Computer Corp. 3 DHC Working Group M. Carney 4 Obsoletes: draft-ietf-dhc-dhcpv6exts-11.txt Sun Microsystems, Inc 5 C. Perkins 6 Nokia Research Center 7 5 May 2000 8 Extensions for the Dynamic Host Configuration Protocol for IPv6 9 draft-ietf-dhc-dhcpv6exts-12.txt 10 Status of This Memo 12 This document is a submission by the Dynamic Host Configuration 13 Working Group of the Internet Engineering Task Force (IETF). Comments 14 should be submitted to the dhcp-v6@bucknell.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The Dynamic Host Configuration Protocol for IPv6 [4] (DHCP) provides 37 a framework for passing configuration information to hosts on 38 a TCP/IP network. Configuration parameters and other control 39 information are carried in typed data items that are stored in the 40 ``extensions'' field of the DHCP message. The data items themselves 41 are also called ``extensions.'' This document specifies the initial 42 set of DHCP extensions, which will be periodically updated as new 43 extensions are defined until this document reaches proposed standard. 45 After that time, individual extensions will be defined in separate 46 documents, to be reviewed by the DHCP WG (if it still exists) and the 47 IESG. 49 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. DHCP Extension Field Format 2 58 3. DHCP Relay Considerations 4 60 4. Releasable Resource Extensions 4 61 4.1. IP Address Extension . . . . . . . . . . . . . . . . . . 4 62 4.1.1. IP Address Lifetimes . . . . . . . . . . . . . . 8 63 4.1.2. Client Considerations . . . . . . . . . . . . . . 9 64 4.1.3. Server Considerations . . . . . . . . . . . . . . 11 66 5. General Extensions 14 67 5.1. IEEE 1003.1 POSIX Timezone Extension . . . . . . . . . . 14 68 5.1.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 15 69 5.1.2. An Example: . . . . . . . . . . . . . . . . . . . 16 70 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 17 71 5.3. Domain Name Suffix Extension . . . . . . . . . . . . . . 17 72 5.4. Service Location Protocol Directory Agent Extension . . . 17 73 5.5. Service Location Protocol Service Scope Extension . . . . 19 74 5.6. Network Time Protocol Servers Extension . . . . . . . . . 22 75 5.7. Network Information Service (NIS) Domain Name Extension . 22 76 5.8. Network Information Service (NIS) Servers Extension . . . 23 77 5.9. Network Information Service V2 (NIS+) Domain Extension . 23 78 5.10. Network Information Service V2 (NIS+) Servers Extension . 23 79 5.11. TCP-specific Extensions . . . . . . . . . . . . . . . . . 24 80 5.11.1. TCP Keepalive Interval Extension . . . . . . . . 24 82 6. DHCP-specific Extensions 24 83 6.1. Maximum DHCP Message Size Extension . . . . . . . . . . . 25 84 6.2. DHCP Retransmission and Configuration Parameter Extension 25 85 6.3. Extension Request Extension (ERE) . . . . . . . . . . . . 26 86 6.3.1. Client Considerations . . . . . . . . . . . . . . 26 87 6.3.2. Server Considerations . . . . . . . . . . . . . . 26 88 6.4. Subnet Prefix Extension . . . . . . . . . . . . . . . . . 26 89 6.4.1. Client Considerations . . . . . . . . . . . . . . 27 90 6.4.2. Server Considerations . . . . . . . . . . . . . . 27 91 6.5. Platform Specific Information Extension . . . . . . . . . 27 92 6.6. Platform Class Identifier Extension . . . . . . . . . . . 28 93 6.6.1. Client Considerations . . . . . . . . . . . . . . 29 94 6.6.2. Server Considerations . . . . . . . . . . . . . . 29 95 6.7. User Class Identifier Extension . . . . . . . . . . . . . 29 96 6.7.1. Client Considerations . . . . . . . . . . . . . . 30 97 6.7.2. Server Considerations . . . . . . . . . . . . . . 30 98 6.8. Reconfigure Multicast Address Extension . . . . . . . . . 30 99 6.9. Renumber DHCP Server Address Extension . . . . . . . . . 31 100 6.10. Client-Server Authentication Extension . . . . . . . . . 31 101 6.11. Client Key Selection Extension . . . . . . . . . . . . . 32 103 7. Security Considerations 33 104 7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 105 7.2. Default Authentication Algorithm . . . . . . . . . . . . 33 107 8. IANA Considerations 34 109 9. Acknowledgements 35 111 10. Full Copyright Statement 35 113 Chair's Address 39 115 Authors' Addresses 39 116 1. Introduction 118 This document specifies extensions for use with the Dynamic Host 119 Configuration Protocol for IP version 6 (DHCP). The DHCP message 120 formats are described in the DHCP protocol document [4]. In this 121 document, several words are used to signify the requirements of the 122 specification, in accordance with RFC 2119 [5]. These words (MUST, 123 SHOULD, MAY, MUST NOT, etc) are often capitalized. 125 This document defines the overall format of information in the 126 ``extensions'' field of DHCP messages. The extensions defined 127 within this document specify a generalized way to distribute 128 information useful to a wide class of devices, operating systems 129 and configurations. Sites with a DHCP server that is shared among 130 heterogeneous clients may choose to define other, site-specific 131 formats for the use of the ``extensions'' field. 133 Section 2 of this memo describes the formats of DHCP extensions. 134 Information on registering new extensions is contained in section 8. 135 The other sections organize the format descriptions of various 136 extensions according to their general type, as follows: 138 o Releasable Resource Extensions (section 4) 139 o General Extensions (section 5) 141 * TCP-specific Extensions 143 o DHCP-specific Extensions (section 6) 145 Future applications will make extensive use of an ever-increasing 146 number and variety of network services. It is expected that client 147 requirements for locating these network services will be satisfied 148 by the Service Location Protocol [20], and not the DHCP. The DHCP 149 is expected to be used for the kinds of configuration that enable 150 clients to become fully functional as self-contained network 151 entities. 152 2. DHCP Extension Field Format 154 Extensions may be fixed length or variable length. All extensions 155 begin with a ``Type'' field, which is a an two octet unsigned 156 network-order integer that uniquely identifies the extension. Every 157 extension has a two octet unsigned network-order integer ``Length'' 158 field following the ``Type'' field. The ``Length'' field contains 159 the number of octets of extension data that follow the ``Length'' 160 field. Thus, the ``Length'' field value does not include the number 161 of octets needed to carry the ``Type'' and ``Length'' fields. For 162 some extensions, the ``Length'' field is always the same number, but 163 it MUST still be specified. There is no requirement for alignment of 164 data fields within existing DHCP extensions. Any extensions defined 165 subsequent to this document MUST contain a two-octet ``Length'' field 166 even if the value it would contain would always be fixed or zero. 168 Unrecognized extensions MUST be silently ignored by skipping over the 169 number of octets specified in the ``Length'' field, and processing 170 continued for subsequent extensions. Unless and until specified 171 otherwise by use of the ``Maximum DHCP message size'' extension 172 (section 6.1), DHCP implementations MUST assume that that the maximum 173 DHCP message size including extensions is limited to 1280 octets. 175 All multi-octet quantities are in network-order. 177 Extension Type 0 (zero) is reserved. 179 There can be 65535 different extensions, which are divided up into 180 the following ranges: 182 Releasable Resource Range (1--8192) 184 Extensions carrying data which identifies a resource which is 185 leased by the server to a client for a finite period of time 186 known as a ``lease''. The client agrees to stop using the 187 resource when the lease expires, and the server guarantees that 188 it will not allocate the resource to another client until the 189 lease expires or the client signals that it is done using the 190 resource. 192 A server MUST NOT return a releasable resource to a client 193 unless the client explicitly requests an instance of that 194 resource from the server. This requirement ensures that only 195 clients capable of managing a releasable resource receive them. 197 A client MUST remember which server allocated the client a 198 releasable resource, in order to contact that server to extend 199 the lease on the resource or release the resource back to the 200 server when it is finished with it. 202 As of this writing, the only example of a type of releasable 203 resource is an IP address, carried in the ``IP Address 204 Extension'' (section 4.1). See the ``DHCP for IPv6'' companion 205 document ([4]) for more details. 207 General Range (8193-49152) 209 Extensions in this range are informational in nature, and may 210 point to resources which may be shared by any number of nodes. 211 General extension proposals are reviewed by the DHC WG and IESG 212 for general usefulness to the IETF community at large. 214 Servers MAY return any general range extension to clients if 215 administrative policy requires it; however, a server SHOULD 216 only return general extensions if the client requests them 217 using the ``Extension Request Extension'' (ERE) (section 6.3). 219 Examples of general extensions include Domain Name Service 220 parameters, Network Time Protocol (NTP, [14]) parameters, 221 those carrying information pertaining to the DHCP, such 222 as the ``Maximum DHCP Message Size'' (section 6.1), ``DHCP 223 Retransmission and Configuration Parameter'' (section 6.2, and 224 ``Platform Specific Information'' (section 6.5) Extensions. 226 Site-specific Range (49153--65535) 228 Extensions in this range are reserved for use by Site managers 229 (administrators of the DHCP domain). Their type and content is 230 entirely up to the administrator. DHCP implementations SHOULD 231 permit the definition of site-specific extensions, including 232 such information as data type and format. Note that both 233 client and server implementations MAY need to be configured in 234 order to properly exchange site extensions. 236 A server SHOULD only return site-specific extensions to the 237 client if it explicitly requests them using the ``Extension 238 Request Extension'' (ERE) (section 6.3). 240 All of the extensions described in this document MUST also have 241 their default values specified, if any. Whenever an extension is 242 received as part of a DHCP message, any reserved fields of the 243 message MUST be ignored, and processing continued as if the reserved 244 fields were zero. Typically, the value of the ``Type'' field is 245 shown directly in the format illustration, and for some fixed-length 246 extensions the value of the ``Length'' field is also shown in the 247 format illustration for the extension. 248 3. DHCP Relay Considerations 250 The DHCP Relay MUST NOT change any information in any DHCP Extension 251 fields. All Extension information flows between DHCP Server and DHCP 252 Client without modification by any Relay. 253 4. Releasable Resource Extensions 255 Releasable resource extensions contain data identifying a specific 256 resource leased by the server to the client for a specific period of 257 time known as a ``lease''. Because the allocation of such extensions 258 requires extension-specific management of the lease by both the 259 client and the server, these extensions MUST only be returned to the 260 client if they have been explicitly requested by the client. 262 How the resource and its lease is managed is resource-specific 263 (extension-specific). 265 A client MUST remember in non-volatile storage which server allocated 266 which releasable resource, in order to appropriately manage the lease 267 associated with that resource. 269 As of this writing, the only example of a releasable resource is 270 an IP address, which is carried in the ``IP Address Extension'', 271 discussed below. 272 4.1. IP Address Extension 274 The IP address extension is used by clients and servers to refer to 275 a particular IP address and related information such as the status 276 of the host name associated with the IP address. All information 277 relevant to a particular IP address allocation has been collected 278 together within the ``IP address'' extension. 280 The ``lease'' feature of the ``IP address'' extension is implemented 281 by the ``Preferred lifetime'' and ``Valid lifetime'' fields. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type = 1 | Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | status |C|I|L|Q|A|P| reserved |scope| prefix-len | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | (if present) | 291 | IP address (16 octets) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | (if present) preferred lifetime (4 octets) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | (if present) valid lifetime (4 octets) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | (if present) DNS name (variable length) ... 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Type 1 301 Length (unsigned integer, variable) The length of the Extension 302 in octets. 304 status The receiver's result of its attempt to honor the 305 sender's request. 307 C If the ``C'' bit is set, the field containing the IP 308 address is present in the extension. 310 I If the ``I'' bit is set, the client is informing the 311 server that the IP address listed *was not* received from 312 DHCP (e.g. received from Stateless Autoconfiguration, 313 or manually configured). The ``I'' bit MUST NOT be set 314 if the ``C'' bit is not set (IP address field MUST be 315 present). The ``L'' bit MUST NOT be set if the ``I'' bit 316 is set. 318 L If the ``L'' bit is set, the preferred and valid 319 lifetimes are present in the extension. 321 Q If the ``Q'' bit is set, the fields included by the 322 client are required, and must be made available by the 323 server or else the extension must be rejected. 325 A If the ``A'' bit is set, the client requests that 326 the server updates DNS with a new AAAA/A6 record, as 327 specified by the client's FQDN. 329 P If the ``P'' bit is set, the client requests that the 330 server updates DNS with a new PTR record, as specified by 331 the client's FQDN. 333 reserved MUST be zero. 335 scope 336 This 3-bit field is used by the client to request an IP 337 address of a certain scope. The 3 bits form a number 338 (0--7) which can have the following settings: 340 0 Don't Care 342 1 Globally-scoped address 344 2 Site local-scoped address 346 3 reserved 348 4 reserved 350 5 reserved 352 6 reserved 354 7 reserved 356 prefix-len 357 If the IP address field is present (the ``C'' bit is 358 set), a non-zero prefix-len is the number of left-most 359 bits of the IP address which make up the subnet prefix. 360 Otherwise, if the ``C'' bit is not set, prefix-len MUST 361 be zero. The prefix-len field is 7-bits in length. 363 IP address 364 The IP address to be conveyed to the receiver from the 365 sender. (16 octets long). 367 preferred lifetime 368 The preferred lifetime of the IP address in seconds. 370 valid lifetime 371 The valid lifetime of the IP address in seconds. 373 DNS name 374 The DNS name (a string of NVT-ASCII octets) associated 375 with the IP address. 377 The following values for the status field are defined within this 378 document: 380 0 request granted, no errors 382 1 IP address is already in use by a different node 384 2 Extension settings (bit combinations) illegal 386 3 IP address scope requested is not available 388 4 IP address requested by client is not available 390 18 Security parameters failed for this client 392 20 Resource AAAA/A6 Record Parameter Problem 394 21 Resource PTR Record Parameter Problem 396 23 DNS name string error 398 24 dynDNS Not Implemented 400 25 Authoritative DNS Server could not be found 402 33 The name server was unable to interpret the request 403 due to a format error. 405 34 dynDNS unavailable at this time (SERVFAIL) 407 35 Some name that ought to exist, does not exist 408 (NXDOMAIN) 410 36 The name server does not support the specified Opcode 411 (NOTIMP) 413 37 The name server refuses to perform the specified 414 operation for policy or security reasons (REFUSED) 416 38 Some name that ought not to exist, does exist 417 (YXDOMAIN) 419 39 Some RRset that ought not to exist, does exist 420 (YXRRSET) 422 40 Some RRset that ought to exist, does not exist 423 (NXRRSET) 425 41 The server is not authoritative for the zone named in 426 the Zone Section (NOTAUTH) 428 42 A name used in the Prerequisite or Update Section 429 is not within the zone denoted by the Zone Section 430 (NOTZONE) 432 Status values 33 through 42 are described more fully within Dynamic 433 Updates to DNS (RFC 2136 [21]). Up-to-date values for the values 434 of the status field are specified in the most recent ``Assigned 435 Numbers'' document [17]. 437 The DNS name can be a host name, which does not contain the ``.'' 438 ASCII character as a separator between DNS hierarchy components. 439 Any name containing the ``.'' is treated as a Fully Qualified 440 Domain Name (FQDN). The length of the DNS name may be determined by 441 subtracting, from the Length, the length of those fixed length fields 442 which are present. 444 If the ``Q'' bit is set, the values or actions requested by the C, I, 445 L, A, P bits and the scope field are required, and MUST be provided, 446 or the extension MUST be rejected with the appropriate ``status'' 447 field value, indicating the reason why the server was unable to 448 fulfill the required extension attributes. The ``Q'' bit is NEVER 449 used by the server in ``IP address'' extensions it generates. 451 A DHCP client can include an IP address in its IP Address extension 452 and set the ``I'' bit and the ``A'' bit and/or ``P'' bit to ask the 453 DHCP Server to use the information contained in the extension to 454 update the DNS on the client's behalf. This would be done for IP 455 addresses obtained by a method other than the DHCP, such as Stateless 456 Address Autoconfiguration, RFC 2462 [19]. 458 If the client wishes to have its FQDN associated with one of several 459 existing IP addresses which it has received from the DHCP Server, the 460 client MUST supply that IP address in the IP address extension along 461 with the FQDN. 463 By default, the client SHOULD update the AAAA/A6 (See [7] for 464 information about the A6 record type) record, and the server SHOULD 465 update the PTR record. The IP Address extension permit clients and 466 servers to use a different behavior than the default through the use 467 of the 'Q' and 'A' bits and associated fields. 468 4.1.1. IP Address Lifetimes 470 The lifetime value contained in the ``preferred'' and ``valid'' 471 fields is a value relative to when the sender sent the message 472 containing the ``IP address'' extension. The receiver adds these 473 times to the current clock time in order to determine the absolute 474 times for the ``preferred'' and ``valid'' lifetimes. 476 4.1.2. Client Considerations 478 Sent in a DHCP Request Message 480 In a DHCP Request message (for each IP address extension), a 481 client MUST initialize the ``status'' field value to zero. 483 A client may include multiple IP Address extensions in a single 484 DHCP Request, in order to request as many IP addresses of 485 varying scopes or subnet prefixes as it requires. 487 In a DHCP Request (for each address extension), a client MAY: 489 o Request that any IP address of a specific scope be 490 returned. The client does this by setting the scope 491 value to the desired value. The ``C'' bit and prefix-len 492 fields MUST NOT be set, as the client is not requesting a 493 particular IP address. 495 o Request the lease of some IP address on a specific network 496 (subnet prefix) or a specific IP address (interface ID 497 specified). The client does this by setting the ``C'' bit 498 and including the desired information in the ``IP address'' 499 and ``prefix-len'' fields in the extension. Note that 500 the client MUST set the prefix-len field to the number of 501 left-most bits representing the subnet prefix, even if it 502 is requesting a specific IP address. 504 o Ask that the IP address returned have the ``preferred'' 505 and ``valid'' lifetimes suggested by the client. The 506 client does this by setting the ``L'' bit and including the 507 desired lifetime values in the ``preferred'' and ``valid'' 508 lifetime fields. The client MUST use the lifetimes 509 returned by the DHCP server. 511 o Request that the DHCP server perform a DNS AAAA/A6 record 512 update (``A'' bit is set) and/or DNS PTR record update 513 (``P'' bit is set) for either an IP address the server will 514 assign (``I'' bit not set) or the IP address the client 515 has provided (``I'' bit set) which it acquired through a 516 means other than DHCP, for the host name or Fully Qualified 517 Domain Name (FQDN) the client has provided. 519 o Specify that the attributes of the request carried by the 520 ``IP address'' extension are required by the client by 521 setting the ``Q'' bit. 523 Received in a DHCP Reply Message in response to a DHCP Request 525 When the client receives an IP address extension within a DHCP 526 Reply message, it first validates that the bits / fields set in 527 the extension are valid. If they aren't, the client generates 528 a DHCP Release message including the ill-formed IP address 529 extension, and sets the ``status'' field to 2, and sends it to 530 the server. If the extension is valid, the client inspects 531 the ``status'' field value to see whether the client's request 532 has been granted. If the status is nonzero, the client should 533 log the error, and display the error condition for action by 534 the user and/or the network administrator. Non-zero status 535 almost always indicates that the client will be need to modify 536 its request before it could be satisfied by the replying DHCP 537 server, or alternatively that the replying DHCP server will 538 need to be given updated configuration information for the 539 client. 541 Upon reception of a new IP address, the client MUST perform 542 Duplicate Address Detection (DAD) as specified in RFC 543 2462 [19]. If the IP address has already been allocated to the 544 client and the client is merely requesting a renewal of the 545 lifetime of the IP address, the client MUST NOT perform DAD, as 546 it is using this IP address. If the client finds that the new 547 IP address is in use by another node, the client forms a DHCP 548 Release message including the IP address extension containing 549 the in-use IP address, and sets the ``status'' field value 550 to 1, and sends the Release to the DHCP server. 552 If the client receives an IP address with zero valid lifetime 553 and: 555 - The DHCP Reply message has been authenticated, the client 556 MUST immediately discontinue using that IP address. 558 - The DHCP Reply message has no authentication, the client 559 sets the valid lifetime for the address to 2 hours. 561 When the preferred lifetime of an IP address leased from the 562 DHCP server is 80% exhausted, the client SHOULD begin sending 563 DHCP requests to the server requesting a renewal of the lease 564 on that IP address. If the client is unsuccessful at its 565 attempts and the valid lifetime expires, the client MUST 566 immediately stop using that IP address. 568 Sent in a DHCP Release Message 570 A client sends IP address extension(s) in a DHCP Release 571 message when: 573 o It is releasing an IP address back to the server because it 574 is finished using it. 576 o It has discovered through DAD that the IP address assigned 577 by the DHCP server is already being used by a different 578 node. 580 o The IP address extension received from the DHCP server has 581 an illegal combination of bit/fields settings. 583 o The client wishes to delete the DNS records associated with 584 the IP address/hostname it will present to the server. 585 4.1.3. Server Considerations 587 This section contains information specifying the handling of the ``IP 588 Address'' extension by DHCP servers. 590 Note that a server implementation MUST scan its client bindings from 591 time to time to locate bindings whose lifetimes have expired. Those 592 bindings SHOULD be deleted, and any DNS operations performed which 593 are recorded in those bindings MUST be reversed. 595 The DHCP Advertise Message and the ``IP address'' Extension 597 The ``IP address'' extension is not used in the DHCP Advertise 598 message. 600 Received in a DHCP Request Message 602 When a server processes an ``IP address'' extension within a 603 DHCP Request, the server first validates the combination of 604 bits / fields contained within the extension. If these bits / 605 fields are set incorrectly, the server generates a DHCP Reply 606 message, which includes the incorrect IP address extension 607 from the client's request, with the ``status'' field set to 2, 608 thereby notifying the client of the error. If the IP address 609 extension is correct, the server processes the extension as 610 follows: 612 o If no IP address field is present, then the client is 613 requesting that the server allocate an IP address of the 614 scope identified by the ``scope'' field value. If the IP 615 address field is present and the ``I'' bit is not set, then 616 the client is requesting the assignment of: 618 * A specific IP address (interface ID present) 619 * Any IP address in the specified network (interface ID 620 is zero) 622 The prefix-len field specifies the length of the subnet 623 prefix in either case. 625 The server consults its allocation tables and attempts 626 to select an IP address meeting the client's request 627 which is appropriate for the link to which the client is 628 attached. The link can be determined by the contents of 629 the relay-agent address and prefix-len fields of the DHCP 630 Request message. If these fields are set, then the client 631 is off-link, otherwise the client is attached to one of the 632 same links as the server. 634 o If the client is requesting that the server update the DNS 635 on its behalf (either for the IP address the server will 636 assign or the one it provided which was acquired through 637 some other means (not the DHCP)), the server makes the 638 appropriate DNS dynamic update requests and records the 639 status of the update within the ``status'' field of the IP 640 address extension it will include in the DHCP Reply message 641 sent to the client. If the ``Q'' bit is set, then the 642 server will ensure that the DNS operation has completed 643 successfully before responding to the client. If the ``Q'' 644 bit is not set, then the server SHOULD register the update 645 request with the DNS, and MAY immediately return its DHCP 646 Reply without waiting for the result of the DNS operation. 648 If the client has requested that the server perform 649 DNS updates as part of the IP address allocation and 650 configuration, the server MUST maintain this fact as part 651 of the client's binding. Then, if the client eventually 652 releases the IP address by sending a DHCP Release message 653 or the lifetimes associated with the IP address expire 654 because the client has not renewed them, the server MUST 655 perform the reverse service by updating DNS again to remove 656 the changes it has made on the client's behalf. 658 o If the client has set the ``Q'' bit, then all fields 659 within the IP address extension which represent attributes 660 of interest to the client are requirements, and must be 661 met, otherwise a DHCP Reply message is generated with the 662 ``status'' field set identifying the portion of the request 663 the server could not fulfill. Note that if more than one 664 attribute of the request could not be provided, the server 665 can only identify one of the problems in the ``status'' 666 field. 668 Sent in a DHCP Reply Message in response to a DHCP Request 670 If the server is assigning an IP address (or extending the 671 lifetimes of an existing IP address binding the client holds), 672 the server MUST include an IP address extension for the IP 673 address with the following settings: 675 - the preferred lifetime 677 - the valid lifetime 679 If the DHCP Reply is a response to a DHCP Release, the 680 lifetimes MUST both be zero. 682 If the server has performed DNS operations on behalf of the 683 client, it sets the ``A'' and ``P'' bits if the AAAA/A6 record 684 and PTR record respectively have been updated by the DNS. 686 The ``status'' field of the extension MUST be set by the server 687 indicating the result of the server's attempt to honor the 688 client's IP address-related request. 690 If the server receives a DHCP Request from one of its clients 691 whose address it wishes to invalidate, it can cause the client 692 to discontinue use of the old address by including valid and 693 preferred lifetimes with a value of zero. 695 To perform renumbering, the server will include two IP address 696 extensions, one to reduce the preferred and valid lifetimes 697 for the old address, and another to give the client its new 698 address. 700 Received in a DHCP Release Message 702 When a server processes an ``IP address'' extension within a 703 DHCP Release, the server first validates the combination of 704 bits / fields contained within the extension. If these bits / 705 fields are set incorrectly, the server generates a DHCP Reply 706 message, which includes the incorrect IP address extension 707 from the client's request, with the ``status'' field set to 2, 708 thereby notifying the client of the error. If the IP address 709 extension is correct, the server continues to processes the 710 extension. 712 The client generates a DHCP Release for the following reasons: 714 o Client is finished with the IP address. In this case, the 715 client has determined it no longer needs the IP address, 716 and is returning it to the server for use by other clients. 718 The server removes the IP address from the client's 719 binding, returning it to the general pool of IP addresses. 720 If the server has performed DNS operations on behalf of the 721 client regarding this IP address, the server contacts the 722 DNS service and deletes the changes it has made regarding 723 the FQDN/IP address. The server generates a DHCP Reply 724 including the client's IP address extension, with the 725 ``status'' field set to indicate the results of the release 726 operation. 728 o Client has discovered through DAD that the IP address is 729 already in use by another node. The server MUST mark 730 the errant IP address as unavailable for assignment, and 731 SHOULD generate a log message indicating the problem to 732 the administrator. The server then generates a DHCP Reply 733 message containing the client's IP address extension, with 734 the ``status'' field set to 0 to indicate that it has 735 received the client's release. 737 o The client has requested that the DHCP server serve as a 738 DNS update proxy for a name associated with an IP address 739 that it acquired outside of the DHCP. The server will undo 740 the DNS operations it performed on behalf of this client, 741 deletes its knowledge of those operations, and generates 742 a DHCP Reply message including the client's IP address 743 extension with the ``status'' field set to indicate the 744 result of the release operation. 746 The ``IP Address'' Extension and the DHCP Reconfigure-init 747 Messages 749 A server MUST NOT include an ``IP address'' extension in DHCP 750 Reconfigure or DHCP Reconfigure-init messages. IP addresses 751 may be changed during the DHCP Request/Reply exchange set in 752 motion by DHCP Reconfigure-init message(s). 753 5. General Extensions 755 General extensions (in the range 8193-49152) are important for many 756 DHCP clients, and are not specific to any upper-level protocol. 757 5.1. IEEE 1003.1 POSIX Timezone Extension 759 This extension allows delivery of timezone information in the form of 760 a IEEE 1003.1 POSIX Timezone specifier, as detailed in section 5.1.1. 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type = 8193 | Length | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | IEEE 1003.1 POSIX Timezone string (variable length) ... 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 If a DHCP client finds that the POSIX Timezone extension value is 770 misformatted, it SHOULD notify the the user of the problem and MUST 771 discard the entire extension value. 772 5.1.1. IEEE 1003.1 POSIX Timezone specifier 774 The format of the IEEE 1003.1 POSIX timezone string is specified as 776 StdOffset[Dst[Offset],[Start[/Time],End[/Time]]] 778 where '[' and ']' enclose optional fields, '|' indicates choice 779 of exactly one of the alternatives, ',' and '/' represent literal 780 characters present in the string, and: 782 Std three or more octets for the standard timezone (Std). 783 Any characters (or case) except a leading colon, digits, 784 comma, minus or plus sign are allowed. 786 Offset Indicates the value one must add to local time to 787 arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset 788 following Std is required. Digits are always interpreted 789 as decimal number. If preceded by a '-', the timezone is 790 east of the Prime Meridian, otherwise it is west ('+' is 791 optional) The permissible values for hh[:mm[:ss]] are as 792 follows: 794 hh 0 <= hh <= 23 796 mm 0 <= mm <= 60 798 ss 0 <= ss <= 60 800 Offset has no default value. 802 Dst three or more octets for the daylight savings timezone. 803 If Dst is missing, then daylight savings time does not 804 apply in this locale. If no Offset follows Dst, then 805 Dst is assumed to be one hour ahead of standard time. 806 Any characters (or case) except a leading colon, digits, 807 comma, minus or plus sign are allowed. 809 Start Indicates the day of the year, in one of the formats 810 indicated below, when to change to daylight savings time. 811 The ``Time'' field (which follows immediately after a 812 ``/'' character, if present) indicates when the change is 813 made, in local time. 815 End Indicate the day of the year, in one of the formats 816 indicated below, when to change back from daylight 817 savings time. The ``Time'' field (which follows 818 immediately after a ``/'' character, if present) 819 indicates when the change is made, in local time. 821 Time Time has the same format as Offset, except that no 822 leading ``-'' or ``+'' is permitted. The default is 823 02:00:00. 825 The day of the year can be given in one of the following formats: 827 Jn The julian day n, (1 <= n <= 365). Leap days are not 828 counted. 830 n Zero-based julian day, (0 <= n <= 365). Leap days are 831 counted so it is possible to refer to Feb 29. 833 Mm.n.d The ``d''th day, (0 <= d <= 6) of week ``n'' of month 834 ``m'' of the year (1 <= n <= 5, 1 <= m <= 12, where week 835 5 means last ``d'' day in month ``m'' which may occur in 836 either the fourth or the fifth week. Week ``1'' is the 837 first week in which the ``d'' day occurs. 838 5.1.2. An Example: 840 For Eastern USA time zone, 1986, the Posix timezone string is as 841 follows: 843 EST5EDT4,116/02:00:00,298/02:00:00 845 Here, ``5'' is the Offset for Std, and ``4'' is the Offset for Dst. 846 Start is the 116th day at 2am, and End is 298th day at 2am. 848 5.2. Domain Name Server Extension 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type = 8194 | Length | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Domain Name System server addresses | 856 | (16 octets each) | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 The Domain Name Server extension specifies a list of Domain Name 859 System (STD13 [16]) name servers available to the client. Servers 860 SHOULD be listed in order of preference. 862 The minimum Length for this extension is 16 octets, and MUST always 863 be a multiple of 16. 864 5.3. Domain Name Suffix Extension 866 This extension specifies the default domain name suffix that client 867 should use when resolving hostnames via the Domain Name System. 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Type = 8195 | Length | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Domain Name Suffix (variable length) ... | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 The minimum length for this extension is 1. The domain name is a 877 NVT-ASCII string, ``Length'' octets in size. If the Domain Name 878 Suffix extension is not specified, and the IP Address extension 879 received by a client contains a FQDN, then the client MAY take the 880 part of the FQDN after the first ``.'' octet as the Domain Name 881 Suffix. 882 5.4. Service Location Protocol Directory Agent Extension 884 Entities using the Service Location Protocol (SLP) [20] need to find 885 out the address of one or more Directory Agents in order to transact 886 messages, and possibly the correct scope to be used in conjunction 887 with the service attributes which are exchanged using the Service 888 Location Protocol. 890 The Directory Agent extension requests or specifies a Directory Agent 891 (DA), along with zero or more scopes supported by that DA. Note 892 that this extension MAY be included multiple times in the same DHCP 893 Request or DHCP Reply. If so, then the extensions SHOULD be included 894 in order of decreasing preference. 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Type = 8196 | Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 |D|F|M|T| reserved | DA length | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Directory Agent (variable length) ... 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | (if present) Typed-Scope-List (variable length) ... 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 Length (unsigned integer, variable) The length of the Extension 908 in octets. 910 D If the ``D'' bit is set, the Directory Agent field and 911 the DA Length fields are present. 913 F If the ``F'' bit is set, the Directory Agent is indicated 914 by including its variable length host name or Fully 915 Qualified Domain Name (FQDN) instead of its IP address. 917 M If the ``M'' bit is set, the Directory Agent address 918 MUST be present, and multicast methods for discovering 919 Directory Agents MUST NOT be used. 921 T If the ``T'' bit is set, the Typed-Scope-List is present. 923 rsv reserved; ignored upon reception; MUST be sent as zero 925 DA Length 926 The length (in octets) of the Directory Agent field. 928 Directory Agent 929 The FQDN, host name, or IP address of the Directory 930 Agent. 932 Typed-Scope-List 933 The string denoting the typed-scope-list formatted 934 as explained in the description of the service scope 935 extension (section 5.5). 937 In order to simplify administration of the configuration of DAs for 938 clients using SLP, the DA can be indicated by presenting its host 939 name or FQDN instead of its IP address. This allows renumbering to 940 proceed more smoothly as outlined in RFC1900 [6]. When the FQDN or 941 host name is used, the server sets the ``F'' bit. The host name can 942 be distinguished from the FQDN by the presence of a ``.'' character. 943 In any case, the DA length field is set to be the length of the 944 Directory Agent field. When the ``F'' bit is not set, the DA Length 945 MUST be 16. 947 Note that more than one Directory Agent extension may be present in 948 a DHCP message. Each such extension may have the same or different 949 typed-scope-list. The client may request any Directory Agent with 950 a particular scope, by including the Directory Agent extension in a 951 DHCP Request message with no Directory Agent address included (the 952 ``D'' bit set to zero), and a nonempty typed-scope-list. The length 953 of the Typed-Scope-List is only indicated implicitly by the overall 954 length of the extension. 956 The format of the Typed-Scope-List field is described in the service 957 scope extension (section 5.5). 959 The ``M'' bit MUST NOT be set when the extension is used as part of a 960 DHCP Request message. 962 Extension type 8196 MUST include one or more scopes if a DA address 963 is returned. Using extension type 8196, it is not possible for 964 different service types on the same node to be configured with 965 different directory agents. In other words, all service agents of 966 the same service type on the same node will be configured with the 967 same directory agent. 968 5.5. Service Location Protocol Service Scope Extension 970 This extension indicates a scope that should be used by a Service 971 Agent (SA) as described in RFC 2165 [20], when responding to Service 972 Request messages as specified by the Service Location Protocol (SLP). 974 This extension MAY be included multiple times in the same DHCP 975 Request or DHCP Reply. 977 0 1 2 3 978 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 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Type = 8197 | Length | 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Typed-Scope-List ... 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Length (unsigned integer, variable) The length of the Extension 985 in octets. 987 Typed-Scope-List 988 In Service Location Protocol (SLP) [20], multiple 989 service types can be hosted on the same network node. 990 It is possible that different service types on the same 991 computer would be administered from different scopes. 992 Thus, extension types 8196 and 8197 have additional 993 syntax to allow this more detailed style of service 994 configuration. 996 In particular, the list of scopes contained in the 997 extensions is syntactically separated into lists 998 pertaining to each service type. 1000 Grammatically, a typed-scope-list extension in a DHCP 1001 Reply is structured as follows: 1003 typed-scope-list = one or more 1004 maybe-typed-scope-items, 1005 separated by commas 1006 maybe-typed-scope-item = 1007 typed-scope-item, 1008 or scope-list 1009 typed-scope-item = '(' service-type 1010 '=' scope-list ')' 1011 scope-list = one or more 1012 scope-items, comma-separated 1013 A typed-scope-list extension in a DHCP Request is 1014 structured as follows: 1016 typed-scope-list = one or more 1017 maybe-typed-scope-items, 1018 separated by commas 1019 maybe-typed-scope-item = typed-scope-item, 1020 or maybe-empty-scope-list 1021 typed-scope-item = '(' service-type '=' 1022 maybe-empty-scope-list ')' 1023 maybe-empty-scope-list = zero or 1024 more scope-items, comma-separated 1025 A service type has the format defined in RFC 2609 ([9]), 1026 and a scope-item has the format defined in RFC 2608 1027 ([10]) for ``strval''. Basically, a scope-item is 1028 a character string that has alphanumeric characters 1029 not including control characters or `(',`)',`,', 1030 \',`!',`<',`=',`>', or `"' Service schemes are special 1031 cases of schemes as defined for general URLs in RFC 1738 1032 ([3]). 1034 The typed-scope-list MAY contain both untyped-scope-lists 1035 and typed-scope-lists. Each scope-item in each 1036 untyped-scope-list applies to every service type on the 1037 node. The string containing the typed-scope-list is NOT 1038 null-terminated. The typed-scope-list string must be 1039 UTF-8 character encoded. 1041 As an example, the scope-list ``A,B,C'' denotes scopes A, 1042 B and C for all service types on the client. In a DHCP 1043 Request, this scope string would indicate that the client 1044 wishes a directory agent which supports ANY of these 1045 three scopes. In a DHCP Reply, the scope indicates that 1046 the directory agent supports ALL of the three scopes. 1048 Suppose instead that service types ``netman'' and 1049 ``proxystuff'' are residing on a DHCP client. Then, the 1050 typed-scope-list in a DHCP Reply could be: 1052 (netman=mgmt),(proxystuff=math-dept,labs) 1053 Assuming the DHCP client with two service types 1054 ``netman'' and ``proxystuff'' did not make any scope 1055 restriction, a corresponding typed-scope-list in a DHCP 1056 Request could be: 1058 (netman=),(proxystuff=) 1059 asking for scopes for those service types. 1061 The Typed-Scope-List is described in section 5.5. The DHCP 1062 client (i.e., user agent or service agent) which receives this 1063 extension will use the indicated scope for in all SLP requests and 1064 registrations. 1066 DHCP clients MAY use extension 8197 to request scopes for one or 1067 more particular service types. Note that more than one Service 1068 Scope extension may be present in a DHCP message. The length of the 1069 typed-scope-list is only indicated implicitly by the overall length 1070 of the extension. 1071 5.6. Network Time Protocol Servers Extension 1073 This extension specifies a list of IP addresses indicating NTP [13] 1074 servers available to the client. Servers SHOULD be listed in order 1075 of preference. 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Type = 8198 | Length | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | NTP server addresses | 1083 | (16 octets each) | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 The minimum Length for this extension is 16, and the Length MUST be a 1086 multiple of 16. 1087 5.7. Network Information Service (NIS) Domain Name Extension 1089 This extension specifies the name of the client's NIS domain. The 1090 domain is formatted as a character string consisting of characters 1091 from the NVT-ASCII character set. The minimum length for this 1092 extension is 1. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Type = 8199 | Length | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | NIS Domain Name (variable length) ... 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 5.8. Network Information Service (NIS) Servers Extension 1104 This extension specifies a list of IP addresses indicating NIS 1105 servers available to the client. Servers SHOULD be listed in order 1106 of preference. 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Type = 8200 | Length | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | NIS server addresses | 1114 | (16 octets each) | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 The minimum Length for this extension is 16, and the length MUST be a 1117 multiple of 16. 1118 5.9. Network Information Service V2 (NIS+) Domain Extension 1120 This extension specifies the name of the client's NIS+ domain. The 1121 domain is formatted as a character string consisting of characters 1122 from the NVT-ASCII character set. The minimum Length for this 1123 extension is 1. 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Type = 8201 | Length | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | NIS+ Client Domain Name (variable length) ... 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 5.10. Network Information Service V2 (NIS+) Servers Extension 1135 This extension specifies a list of IP addresses indicating NIS+ 1136 servers available to the client. Servers SHOULD be listed in order 1137 of preference. 1139 0 1 2 3 1140 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 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Type = 8202 | Length | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | NIS+ server addresses | 1145 | (16 octets each) | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 The minimum Length for this extension is 16, and the length MUST be a 1148 multiple of 16. 1149 5.11. TCP-specific Extensions 1151 This section lists the extensions that affect the operation of the 1152 TCP layer on a per-interface basis. 1153 5.11.1. TCP Keepalive Interval Extension 1155 0 1 2 3 1156 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 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 | Type = 8203 | Length | 1159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1160 | Keepalive Time Interval | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 This extension specifies the interval (in seconds) that the 1163 client TCP should wait before sending a keepalive message on a TCP 1164 connection. The time is specified as a 32-bit unsigned integer. 1165 A value of zero indicates that the client should not generate 1166 keepalive messages on connections unless specifically requested by an 1167 application. 1169 The length for this extension is 4. 1170 6. DHCP-specific Extensions 1172 This section details the extensions that are used by the DHCP. 1174 6.1. Maximum DHCP Message Size Extension 1176 This extension specifies the maximum size in octets of any DHCP 1177 message that the sender of the extension is willing to accept. 1178 The size is specified as an unsigned 32-bit integer. A client 1179 may use the maximum DHCP message size extension in DHCP Request 1180 messages, but MUST NOT use the extension in other DHCP messages. 1182 0 1 2 3 1183 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 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Type = 8204 | Length = 4 | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Max DHCP Message Length | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 The Length for this extension is 4. The minimum permissible value is 1190 1280, as specified in RFC 2460 [8]. 1191 6.2. DHCP Retransmission and Configuration Parameter Extension 1193 This extension allows configuration of values for DHCP 1194 retransmission and configuration variables, as specified for 1195 use when sending or receiving DHCP messages. These variables 1196 are discussed in detail in the section on ``Configuration 1197 Variables'' in the ``DHCP for IPv6'' companion document [4]. 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Type = 8205 | Length | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Configuration Variable Identifier (2 octets) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | New Variable Value (8 octets) | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 The length for this extension is 10 octets. The ``Configuration 1209 Variable Identifier'' field carries an unsigned 16-bit network-order 1210 integer representing the configuration variable. The ``New Variable 1211 Value'' field carries a 64-bit network-order integer representing the 1212 value of the configuration variable. If a client uses this extension 1213 in a DHCP Request message, then the ``New Variable Value'' field 1214 MUST be 0 (zero). If a client does not receive a setting for the 1215 ``Configuration Variable Identifier'' it has requested, it MUST use 1216 the default values defined in the ``Configuration Variables'' section 1217 of the ``DHCP for IPv6'' document [4]. 1218 6.3. Extension Request Extension (ERE) 1220 The ``Extension Request Extension'' (ERE) MAY be used by DHCP 1221 implementations to indicate which DHCP extensions they are interested 1222 in (client), or what DHCP information (e.g. extensions) are 1223 available (server). 1225 0 1 2 3 1226 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 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Type = 8206 | Length | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | A | B | C | D | E | ... 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 The extension contains a list of extension ``Type'' values indicating 1233 the extension of interest. Since an extension ``Type'' field is 1234 an unsigned two-octet network-order integer, each extension is 1235 identified by two-octets. Thus, the Length field MUST always be 1236 an even number. Extension types listed in the ERE are listed in 1237 priority order, with the extensions of highest priority listed before 1238 those of lower priority. One and only one ERE extension is permitted 1239 within a DHCP message. 1240 6.3.1. Client Considerations 1242 If the client implementation supports it, the client SHOULD generate 1243 a Extensions Request Extension identifying which extensions it is 1244 interested in and include it in its DHCP Request messages. 1245 6.3.2. Server Considerations 1247 If a server receives a DHCP request with an ERE extension present, 1248 the server SHOULD attempt to provide valid values for all the 1249 information requested. 1250 6.4. Subnet Prefix Extension 1252 The ``Subnet Prefix'' extension is a DHCP server-only extension used 1253 to advertise what networks are available on the client's link. Each 1254 extension carries a single subnet prefix. 1256 0 1 2 3 1257 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 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Type = 8207 | Length | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Prefix Len (number of left-most bits) (1 octet) | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Subnet Prefix Octets (variable number of octets) | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 A subnet prefix is specified by the ``Subnet Prefix Octets'' field 1266 and the ``Prefix-Len'' field. The ``Subnet Prefix Octets'' field 1267 is large enough to contain all the bits of the subnet prefix. Any 1268 unused bits in the last octet of this field MUST be set to off 1269 (zero). 1271 The length of this extension is variable. 1272 6.4.1. Client Considerations 1274 Clients MAY use the ``Subnet Prefix'' extension value to request 1275 one or more IP addresses on that network. A client does this by 1276 forming an ``IP address'' extension with the value of the ``Subnet 1277 Prefix Octets'' field copied into the high-order portion of the ``IP 1278 address'' field (``C'' bit set) and the ``Prefix-len'' value copied 1279 into the ``prefix-len'' field of the ``IP address'' extension for 1280 each IP address desired on the advertised network. 1281 6.4.2. Server Considerations 1283 In response to a client's DHCP Solicit message (``P'' bit set), 1284 a server SHOULD return one ``Prefix'' extension for each of the 1285 networks it is configured to manage that exist on the client's link 1286 in the resultant DHCP Advertise message. A server SHOULD NOT include 1287 ``Prefix'' extensions in its Advertise messages if the client has not 1288 requested them (``P'' bit NOT set). 1290 If a server receives a DHCP Request message with ``Prefix'' 1291 extension(s), that DHCP Request message MUST be dropped. 1292 6.5. Platform Specific Information Extension 1294 A platform is defined as the combination of hardware and operating 1295 system (OS). 1297 This extension is used by clients and servers to exchange 1298 client-platform-specific information. The information is an opaque 1299 collection of data, presumably interpreted by platform-specific code 1300 on the clients. The definition of this information is platform 1301 specific. Clients identify their platform through the use of the 1302 Platform Class identifier extension (see Section 6.6). Clients which 1303 do not receive platform specific information SHOULD make an attempt 1304 to operate without it, although they may do so (and announce that 1305 they are doing so) in a degraded mode. 1307 If a platform vendor encodes more than one item of information in 1308 this extension, then the vendor MUST encode the extension using 1309 ``Encapsulated platform-specific extensions'' as described below. 1310 The ``Encapsulated platform-specific extensions'' field MUST be 1311 encoded as a sequence of type/length/value fields of identical syntax 1312 to the form defined for DHCP extensions (see section 2), encapsulated 1313 within the ``Platform Specific Information Extension''. 1315 0 1 2 3 1316 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 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Type = 8208 | Length | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Platform-specific extension information ... 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 The minimum length for this extension is 4. 1324 DHCP servers which support the configuration of ``Platform Specific 1325 Information'' extensions, and which have been configured with 1326 configuration information specific to some number of ``Platform Class 1327 Identifiers'' MUST select and return only those platform-specific 1328 extensions which match the ``Platform Class Identifier'' provided by 1329 the DHCP client. 1330 6.6. Platform Class Identifier Extension 1332 This extension is used by a DHCP client to identify the hardware type 1333 and operating system platform it is hosted on. The extension value 1334 itself is an opaque value to a DHCP server, and is only used by the 1335 DHCP server to "lookup" Platform Specific Extensions associated with 1336 clients of a certain platform class. DHCP servers SHOULD also allow 1337 the association of other extensions (Releasable, General, etc) with 1338 clients of a certain platform class. 1340 Note that unlike the ``User Class Identifier'' (see section 6.7, the 1341 ``Platform Class Identifier'' does not need to be echoed back to the 1342 DHCP client because there can be one and only one ``Platform Class 1343 Identifier'' for a client. 1345 0 1 2 3 1346 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 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type = 8209 | Length | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Platform Class Identifier ... 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 The minimum length for this extension is 4. 1354 The ``Platform Class Identifier'' is a string of UTF-8 characters 1355 of Length octets. The ``Platform Class Identifier'' represents the 1356 hardware and operating system class of which the client is a member. 1358 In order to prevent collisions in the ``Platform Class Identifier'' 1359 namespace, DHCP client vendors MUST prefix their ``Platform Class 1360 Identifiers'' with their stock symbol or some other globally 1361 recognized organizational identifier. For example, ``Platform Class 1362 Identifiers'' for Sun Microsystems Inc platforms would be prefaced 1363 by ``SUNW'', the NASDAQ stock symbol for Sun. Those associated with 1364 Microsoft platforms would be prefaced by ``MSFT''. 1365 6.6.1. Client Considerations 1367 If the client wishes platform-specific data, it includes a platform 1368 class identifier extension identifying its platform type. 1369 6.6.2. Server Considerations 1371 Servers not equipped to interpret the platform class identifier 1372 specified by a client MUST ignore it (although it may be reported 1373 to the DHCP administrator). Otherwise, servers SHOULD respond with 1374 the set of extensions corresponding to the platform class identifier 1375 specified by the client. 1376 6.7. User Class Identifier Extension 1378 This extension is used by a DHCP client to optionally identify the 1379 type or category of user or applications it represents. 1381 Network administrators may define specific user class identifiers to 1382 convey information about a client's software configuration or about 1383 its user's preferences. For example, an identifier may specify that 1384 a particular machine hosting a DHCP client is a member of the class 1385 ``accounting auditors'', which have special service needs such as a 1386 particular database server or printer. 1388 0 1 2 3 1389 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 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Type = 8210 | Length | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | User Class Identifier ... 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 The minimum length for this extension is 4. 1397 The user class identifier is a UTF-8 string of Length octets. 1398 The value of the ``User Class Identifier'' is selected by the 1399 administrator of the DHCP domain containing the all members of this 1400 class. Thus, a ``User Class Identifier'' need only be unique within 1401 the DHCP domain, although the administrator MAY choose to prefix the 1402 ``User Class Identifier'' with the department name in order to reduce 1403 the possibility of ``User Class Identifier'' name space collisions. 1404 6.7.1. Client Considerations 1406 If the client is configured to request user class-specific data, it 1407 includes a User Class identifier extension for each user class it is 1408 configured with. 1409 6.7.2. Server Considerations 1411 Servers not equipped to interpret the user class identifier specified 1412 by a client MUST ignore it (although it may be reported to the 1413 network administrator). Otherwise, servers SHOULD respond with 1414 the set of extensions corresponding to the user class identifier 1415 specified by the client. Further, if the server responds with the 1416 set of extensions corresponding to the given user class identifier, 1417 it MUST echo the client's user class identifier extension back to the 1418 client. 1419 6.8. Reconfigure Multicast Address Extension 1421 A DHCP server can instruct its clients to join one or more multicast 1422 groups for the purposes of receiving DHCP Reconfigure or DHCP 1423 Reconfigure-init messages. The DHCP server accomplishes this by 1424 returning a ``Reconfigure Multicast Address Extension'' for each 1425 multicast address associated with the group. See the ``DHCP for 1426 IPv6'' document [4] for more details on the use of this extension. 1428 0 1 2 3 1429 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 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Type = 8211 | Length = 16 | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Reconfigure Multicast Address | 1434 | (16 octets) | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 The Length for this extension is 16. 1437 6.9. Renumber DHCP Server Address Extension 1439 A DHCP server can instruct its clients to change their internal 1440 records to reflect the server's newly renumbered IP address, by using 1441 the ``Renumber DHCP Server Address Extension''. This extension 1442 SHOULD be sent in the DHCP Reconfigure message. 1444 The server includes both its previous IP address and its new IP 1445 address. Providing the previous IP address allows clients to update 1446 only those resource associations owned by this server. 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | Type = 8212 | Length = 32 | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Previous DHCP Server Address | 1454 | (16 octets) | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | New DHCP Server Address | 1457 | (16 octets) | 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 The Length for this extension is 32. 1460 6.10. Client-Server Authentication Extension 1462 Exactly one ``Client-Server Authentication Extension'' MAY be present 1463 in any DHCP message transmitted between a client and server (or 1464 vice-versa). If present, it MUST be the last extension. 1466 0 1 2 3 1467 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 1468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1469 | Type = 8213 | Length | 1470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1471 | Security Parameters Index (SPI) | 1472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1473 | Replay Protection | 1474 | (8 octets) | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Authenticator (variable length) ... 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 Length (unsigned integer, variable) 4 for the SPI, plus 8 for 1479 the replay protection, plus the number of octets in the 1480 Authenticator. 1482 SPI A Security Parameters Index (SPI) [2] identifying a 1483 security context from among those available between the 1484 DHCP client and server. 1486 Replay Protection 1487 A 64-bit timestamp (in Network Time Protocol (NTP) [15] 1488 format) (see section 7.1). 1490 Authenticator 1491 (variable length) (See Section 7.2.) 1493 This authentication extension remedies the inability of IPsec (RFC 1494 2402 [11]) to provide for non end-to-end authentication, since 1495 authentication is needed even when the client has no IPv6 address 1496 with enough scope to reach the DHCP server. The extension can be 1497 originated by either the client or server to authenticate the rest of 1498 the data in the DHCP message. The default authentication algorithm, 1499 which MUST be supported by all clients and servers, is defined in 1500 section 7.2. 1502 SPI values 0 through 255 are reserved and, if used, MUST conform 1503 to the security context defined by that value in the most recent 1504 Assigned Numbers RFC (e.g., STD1 [17]). 1505 6.11. Client Key Selection Extension 1507 A DHCP server may wish to indicate to a prospective client which 1508 SPI it must use to authenticate subsequent messages, using the 1509 ``Client-Server Authentication Extension''. In such cases, the 1510 server includes the ``Client Key Selection Extension'' in its DHCP 1511 Advertise message. 1513 0 1 2 3 1514 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 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 | Type = 8214 | Length = 4 | 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | Security Parameters Index (SPI) | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 The Security Parameters Index (SPI) [2] identifies a security 1521 context between a pair of nodes among the contexts available in the 1522 security association defined between the DHCP client and server. 1524 SPI values 0 through 255 are reserved and, if used, MUST conform to 1525 the security context defined by that value as defined in the most 1526 recent Assigned Numbers RFC (e.g.,STD1 [17]). 1527 7. Security Considerations 1529 A security protocol is urgently needed for use with DHCP, since 1530 otherwise malicious parties could create numerous denial-of-service 1531 style attacks based on depleting available server resources or 1532 providing corrupted or infected data to unsuspecting clients. The 1533 following sections discuss aspects of security relevant for users 1534 of the Client-Server Authentication extension 6.10. See also the 1535 Security Considerations in the companion specification [4]. 1536 7.1. Replay Protection 1538 A 64-bit timestamp, in Network Time Protocol [15](NTP) format, is 1539 used to protect against replay of previous authenticated messages 1540 by malicious agents. The NTP timestamp value used in the extension 1541 MUST be chosen, and verified, to be larger than values used by the 1542 originator in previous Client-Server Authentication extensions. 1543 On the other hand, the timestamp value MUST also be chosen (and 1544 verified) to be no greater than one year more than the last known 1545 value (if any) used by the originator. 1546 7.2. Default Authentication Algorithm 1548 The default authentication algorithm is HMAC [12], using 1549 keyed-MD5 [18]. Given a secret key K, and "data" the information to 1550 be authenticated, HMAC_result is computed as follows: 1552 1. opad := 0x36363636363636363636363636363636 (128 bits) 1554 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 1556 3. zero_extended_key := K extended by zeroes to be 128 bits long 1558 4. opadded_key := zero_extended_key XOR opad 1560 5. ipadded_key := zero_extended_key XOR ipad 1562 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 1564 The key K is the shared secret defined by the security association 1565 between the client and server and by the SPI value specified in 1566 the Authentication Extension. The "data" is the stream of octets 1567 in all previous fields in the DHCP message and extensions. The 1568 authenticator is the 128-bit value HMAC_result. 1569 8. IANA Considerations 1571 This document MAY be superseded by new documents for DHCP extensions, 1572 which will then include the entire current list of valid extensions. 1573 This section details the method for specifying new extensions. 1575 Implementation specific use of undefined extensions (all those in the 1576 range 86-32767 inclusive) may conflict with other implementations, 1577 and registration is required. 1579 The following steps MUST be followed by the author of any new DHCP 1580 extension, in order to obtain acceptance of the extension as a part 1581 of the DHCP Internet Standard: 1583 1. The author documents the new extension as an Internet Draft. 1585 2. The author submits the Internet Draft for review through the 1586 IETF standards process as defined in "Internet Official Protocol 1587 Standards" [17]. The new extension will be submitted for 1588 eventual acceptance as an Internet Standard. 1590 3. The author requests a number for the new extension from IANA by 1591 contacting: 1593 Internet Assigned Numbers Authority (IANA) 1594 USC/Information Sciences Institute 1595 4676 Admiralty Way 1596 Marina del Rey, California 90292-6695 1597 or by email as: iana@isi.edu 1599 4. The new extension progresses through the IETF standards 1600 process; the new extension will be reviewed by the Dynamic Host 1601 Configuration Working Group (if that group still exists), or as 1602 an Internet Draft not submitted by an IETF working group. 1604 5. If the new extension fails to gain acceptance as an Internet 1605 Standard, the assigned extension number will be returned to IANA 1606 for reassignment. 1608 This procedure for defining new extensions will ensure that: 1610 * allocation of new extension numbers is coordinated from a single 1611 authority, 1613 * new extensions are reviewed for technical correctness and 1614 appropriateness, and 1616 * documentation for new extensions is complete and published. 1617 9. Acknowledgements 1619 The original form of this internet draft was copied directly from 1620 RFC1533 [1], written by Steve Alexander and Ralph Droms. Thanks to 1621 Mike Carney for his many helpful comments, as well as contributing 1622 the design of the Platform Specific Information and Platform Class 1623 Identifier. Thanks to Erik Guttman for his helpful suggestions 1624 for the Service Location extensions. Thanks to Ralph Droms, Matt 1625 Crawford, Thomas Narten, and Erik Nordmark for their careful review 1626 as part of the Last Call process. 1627 10. Full Copyright Statement 1629 Copyright (C) The Internet Society (1997). All Rights Reserved. 1631 This document and translations of it may be copied and furnished to 1632 others, and derivative works that comment on or otherwise explain it 1633 or assist in its implementation may be prepared, copied, published 1634 and distributed, in whole or in part, without restriction of any 1635 kind, provided that the above copyright notice and this paragraph 1636 are included on all such copies and derivative works. However, 1637 this document itself may not be modified in any way, such as by 1638 removing the copyright notice or references to the Internet Society 1639 or other Internet organizations, except as needed for the purpose 1640 of developing Internet standards in which case the procedures 1641 for copyrights defined in the Internet Standards process must be 1642 followed, or as required to translate it into languages other than 1643 English. 1645 The limited permissions granted above are perpetual and will not be 1646 revoked by the Internet Society or its successors or assigns. 1648 This document and the information contained herein is provided on an 1649 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1650 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1651 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1652 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1653 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1655 References 1657 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 1658 Extensions. Request for Comments (Proposed Standard) 1533, 1659 Internet Engineering Task Force, October 1993. 1661 [2] R. Atkinson. IP Authentication Header. Request for Comments 1662 (Proposed Standard) 1826, Internet Engineering Task Force, 1663 August 1995. 1665 [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 1666 Locators (URL). Request for Comments (Proposed Standard) 1738, 1667 Internet Engineering Task Force, December 1994. 1669 [4] J. Bound, M. Carney, and C. Perkins. DHCP for IPv6. 1670 draft-ietf-dhc-dhcpv6-15.txt, May 2000. (work in progress). 1672 [5] S. Bradner. Key words for use in RFCs to Indicate Requirement 1673 Levels. Request for Comments (Best Current Practice) 2119, 1674 Internet Engineering Task Force, March 1997. 1676 [6] B. Carpenter and Y. Rekhter. Renumbering Needs Work. Request 1677 for Comments (Informational) 1900, Internet Engineering Task 1678 Force, February 1996. 1680 [7] M. Crawford, C. Huitema, and S. Thomson. DNS Extensions to 1681 Support IPv6 Address Aggregation and Renumbering. 1682 draft-ietf-ipngwg-dns-lookups-07.txt, 2000. (work in progress). 1684 [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) 1685 Specification. Request for Comments (Draft Standard) 2460, 1686 Internet Engineering Task Force, December 1998. 1688 [9] E. Guttman, C. Perkins, and J. Kempf. Service Templates and 1689 Service: Schemes. Request for Comments (Proposed Standard) 1690 2609, Internet Engineering Task Force, June 1999. 1692 [10] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service 1693 Location Protocol, Version 2. Request for Comments (Proposed 1694 Standard) 2608, Internet Engineering Task Force, June 1999. 1696 [11] S. Kent and R. Atkinson. IP Authentication Header. Request for 1697 Comments (Proposed Standard) 2402, Internet Engineering Task 1698 Force, November 1998. 1700 [12] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 1701 for Message Authentication. Request for Comments 1702 (Informational) 2104, Internet Engineering Task Force, 1703 February 1997. 1705 [13] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for 1706 IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, 1707 Internet Engineering Task Force, October 1996. 1709 [14] D. L. Mills. Internet time synchronization: The Network Time 1710 Protocol. Request for Comments 1129, Internet Engineering Task 1711 Force, October 1989. 1713 [15] David L. Mills. Network Time Protocol (version 3) 1714 Specification, Implementation. Request for Comments (Draft 1715 Standard) 1305, Internet Engineering Task Force, March 1992. 1717 [16] P. V. Mockapetris. Domain names - concepts and facilities. 1718 Request for comments (standard), Internet Engineering Task 1719 Force, November 1987. 1721 [17] J. Reynolds and R. Braden. Internet Official Protocol Sandards. 1722 Request for comments (proposed standard), Internet Engineering 1723 Task Force, March 2000. 1725 [18] R. Rivest. The MD5 Message-Digest Algorithm. Request for 1726 Comments (Informational) 1321, Internet Engineering Task Force, 1727 April 1992. 1729 [19] S. Thomson and T. Narten. IPv6 Stateless Address 1730 Autoconfiguration. Request for Comments (Draft Standard) 2462, 1731 Internet Engineering Task Force, December 1998. 1733 [20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 1734 Location Protocol. Request for Comments (Proposed Standard) 1735 2165, Internet Engineering Task Force, June 1997. 1737 [21] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic 1738 Updates in the Domain Name System (DNS UPDATE). Request for 1739 Comments (Proposed Standard) 2136, Internet Engineering Task 1740 Force, April 1997. 1742 Chair's Addresses 1744 The working group can be contacted via the current chair: 1746 Ralph Droms 1747 Computer Science Department 1748 323 Dana Engineering 1749 Bucknell University 1750 Lewisburg, PA 17837 1752 Phone: (717) 524-1145 1753 EMail: droms@bucknell.edu 1755 Authors' Addresses 1757 Questions about this memo can be directed to: 1759 Jim Bound 1760 Compaq Computer Corporation 1761 Mail Stop: ZK03-3/U14 1762 110 Spitbrook Road 1763 Nashua, NH 03062 1764 USA 1765 Phone: +1-603-884-0400 1766 Email: bound@zk3.dec.com 1768 Mike Carney 1769 Sun Microsystems, Inc 1770 Mail Stop: UMPK17-202 1771 901 San Antonio Road 1772 Palo Alto, CA 94303-4900 1773 USA 1774 Phone: +1-650-786-4171 1775 Email: mwc@eng.sun.com 1777 Charles E. Perkins 1778 Communications Systems Lab 1779 Nokia Research Center 1780 313 Fairchild Drive 1781 Mountain View, California 94043 1782 USA 1783 Phone: +1-650 625-2986 1784 EMail: charliep@iprg.nokia.com 1785 Fax: +1 650 625-2502