idnits 2.17.1 draft-ietf-dhc-v6opts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 ([2]), 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 188: '...ting prefix size option MUST be first....' RFC 2119 keyword, line 214: '...subnet. Routers SHOULD be listed in o...' RFC 2119 keyword, line 217: '..., and the length MUST always be a mult...' RFC 2119 keyword, line 229: '... SHOULD be listed in order of prefer...' RFC 2119 keyword, line 232: '...ctets, and the length MUST always be a...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (22 November 1995) is 10383 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) ** Obsolete normative reference: RFC 1533 (ref. '1') (Obsoleted by RFC 2132) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-03 -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-ipv6-spec is -01, but you're referring to -02. ** Obsolete normative reference: RFC 1305 (ref. '4') (Obsoleted by RFC 5905) == Outdated reference: A later version (-06) exists of draft-ietf-ipngwg-discovery-03 ** Obsolete normative reference: RFC 1497 (ref. '9') (Obsoleted by RFC 1533) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1198 (ref. '11') == Outdated reference: A later version (-16) exists of draft-ietf-svrloc-protocol-07 Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins 2 INTERNET DRAFT IBM 3 22 November 1995 5 Options for DHCPv6 6 draft-ietf-dhc-v6opts-00.txt 8 Status of This Memo 10 This document is a submission to the Dynamic Host Configuration 11 Working Group of the Internet Engineering Task Force (IETF). Comments 12 should be submitted to the dhcp-v6@bucknell.edu mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 The Dynamic Host Configuration Protocol for IPv6 [2] (DHCPv6) 35 provides a framework for passing configuration information to hosts 36 on a TCP/IP network. Configuration parameters and other control 37 information are carried in tagged data items that are stored in the 38 "options" field of the DHCPv6 message. The data items themselves are 39 also called "options." 41 This document specifies the current set of DHCPv6 options. This 42 document will be periodically updated as new options are defined. 43 Each superseding document will include the entire current list of 44 valid options. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 54 2. DHCPv6 Option Field Format 1 56 3. Option specifications 2 57 3.1. Pad Option . . . . . . . . . . . . . . . . . . . . . . . 2 58 3.2. End Option . . . . . . . . . . . . . . . . . . . . . . . 2 59 3.3. Routing Prefix size . . . . . . . . . . . . . . . . . . . 2 60 3.4. Time Offset . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.5. Router Option . . . . . . . . . . . . . . . . . . . . . . 3 62 3.6. Domain Name Server Option . . . . . . . . . . . . . . . . 3 63 3.7. Host Name Option . . . . . . . . . . . . . . . . . . . . 4 64 3.8. Resource Location Server Option . . . . . . . . . . . . . 4 65 3.9. Boot File Size Option . . . . . . . . . . . . . . . . . . 4 66 3.10. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. IP Layer Parameters per Host 5 69 4.1. Maximum Datagram Reassembly Size . . . . . . . . . . . . 5 70 4.2. Default IP Time-to-live . . . . . . . . . . . . . . . . . 5 71 4.3. Path MTU Aging Timeout Option . . . . . . . . . . . . . . 5 73 5. IP Layer Parameters per Interface 6 74 5.1. Interface MTU Option . . . . . . . . . . . . . . . . . . 6 75 5.2. Static Route Option . . . . . . . . . . . . . . . . . . . 6 77 6. TCP Parameters 7 78 6.1. TCP Default TTL Option . . . . . . . . . . . . . . . . . 7 79 6.2. TCP Keepalive Interval Option . . . . . . . . . . . . . . 7 81 7. Application and Service Parameters 8 82 7.1. Network Time Protocol Servers Option . . . . . . . . . . 8 83 7.2. Vendor Specific Information . . . . . . . . . . . . . . . 8 84 7.3. X Window System Font Server Option . . . . . . . . . . . 9 85 7.4. X Window System Display Manager Option . . . . . . . . . 9 87 8. DHCPv6 Extensions 10 88 8.1. Requested IP Address . . . . . . . . . . . . . . . . . . 10 89 8.2. Parameter Request List . . . . . . . . . . . . . . . . . 10 90 8.3. Message . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 8.4. Maximum DHCPv6 Message Size . . . . . . . . . . . . . . . 11 92 8.5. Class-identifier . . . . . . . . . . . . . . . . . . . . 11 93 8.6. Client-identifier . . . . . . . . . . . . . . . . . . . . 12 94 8.7. Mobile Home Address Option . . . . . . . . . . . . . . . 12 96 9. Neighbor Discovery Extensions 13 98 10. Extensions 13 100 11. Acknowledgements 13 102 12. Security Considerations 13 104 Chair's Address 15 106 Author's Address 15 107 1. Introduction 109 This document specifies options for use with the Dynamic Host 110 Configuration Protocol for IP version 6, DHVPv6. The full 111 description of DHCPv6 packet formats may be found in the DHCPv6 112 specification document [2]. 114 This document defines the format of information in the last field of 115 DHCPv6 packets ('options'). The options defined within this document 116 specify a generalized use of this area for giving information useful 117 to a wide class of machines, operating systems and configurations. 118 Sites with a single DHCPv6 server that is shared among heterogeneous 119 clients may choose to define other, site- specific formats for the 120 use of the 'options' field. 122 Section 2 of this memo describes the formats of DHCPv6 options. 124 Information on registering new options is contained in section 10. 125 Although option numbers in this document correspond exactly to the 126 same option numbers in the options specification for IPv4 [1], there 127 is no requirement to keep numbering future options in any consistent 128 manner except purely as a matter of editorial and cross-referencing 129 convenience. 131 2. DHCPv6 Option Field Format 133 DHCPv6 options have the same format as the BOOTP "vendor extensions" 134 defined in RFC 1497 [9]. Options may be fixed length or variable 135 length. All options begin with a tag octet, which uniquely 136 identifies the option. Fixed-length options without data consist 137 of only a tag octet. Only options 0 and 255 are fixed length. All 138 other options are variable-length with a length octet following the 139 tag octet. The value of the length octet does not include the two 140 octets specifying the tag and length. The length octet is followed 141 by "length" octets of data. In the case of some variable-length 142 options the length field is a constant but must still be specified. 144 Any options defined subsequent to this document should contain a 145 length octet even if the length is fixed or zero. 147 All multi-octet quantities are in network byte-order. 149 Option codes 128 to 254 (decimal) are reserved for site-specific 150 options. 152 All of the options described in this document will also have their 153 default values specified, if any. 155 3. Option specifications 157 3.1. Pad Option 159 The pad option can be used to cause subsequent fields to align on 160 word boundaries. 162 The code for the pad option is 0, and its length is 1 octet. 164 Code 165 +-----+ 166 | 0 | 167 +-----+ 169 3.2. End Option 171 The end option marks the end of valid information in the vendor 172 field. Subsequent octets should be filled with pad options. 174 The code for the end option is 255, and its length is 1 octet. 176 Code 177 +-----+ 178 | 255 | 179 +-----+ 181 3.3. Routing Prefix size 183 The routing prefix size option specifies the length of the routing 184 prefix, counting the number of leading 1 bits to be applied to the 185 client's IPv6 address to get the routing prefix. 187 If both the routing prefix size and the router option are specified 188 in a DHCPv6 reply, the routing prefix size option MUST be first. 190 The code for the routing size prefix option is 1, and its length is 1 191 octet. 193 Code Len Prefix Size 194 +-----+-----+------+ 195 | 1 | 1 | size | 196 +-----+-----+------+ 198 3.4. Time Offset 200 The time offset field specifies the offset of the client's subnet 201 in seconds from Coordinated Universal Time (UTC). The offset is 202 expressed as a signed 32-bit integer. 204 The code for the time offset option is 2, and its length is 4 octets. 206 Code Len Time Offset 207 +-----+-----+-----+-----+-----+-----+ 208 | 2 | 4 | n1 | n2 | n3 | n4 | 209 +-----+-----+-----+-----+-----+-----+ 211 3.5. Router Option 213 The router option specifies a list of IP addresses for routers on the 214 client's subnet. Routers SHOULD be listed in order of preference. 216 The code for the router option is 3. The minimum length for the 217 router option is 16 octets, and the length MUST always be a multiple 218 of 16. 220 Code Len Address 1 Address 2 221 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 222 | 3 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... 223 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 225 3.6. Domain Name Server Option 227 The domain name server option specifies a list of Domain Name System 228 (STD 13, RFC 1035 [5]) name servers available to the client. Servers 229 SHOULD be listed in order of preference. 231 The code for the domain name server option is 6. The minimum 232 length for this option is 16 octets, and the length MUST always be a 233 multiple of 16. 235 Code Len Address 1 Address 2 236 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 237 | 6 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... 238 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 240 3.7. Host Name Option 242 This option specifies the name of the client. The name may or may 243 not be a fully qualified domain name (FQDN). See RFC 1035 [5] for 244 character set restrictions. 246 The code for this option is 12, and its minimum length is 1. 248 Code Len Host Name 249 +-----+-----+-----+-----+-----+-----+-----+-----+-- 250 | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ... 251 +-----+-----+-----+-----+-----+-----+-----+-----+-- 253 3.8. Resource Location Server Option 255 This option specifies a list of Resource Location servers [12] 256 available to the client. Servers SHOULD be listed in order of 257 preference. 259 The code for this option is 11. The minimum length for this option 260 is 16 octets, and the length MUST always be a multiple of 16. 262 Code Len Address 1 Address 2 263 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 264 | 11 | n | a1 | a2 | ... | a16 | a1 | a2 | ... | a16 | ... 265 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+---- 267 3.9. Boot File Size Option 269 This option specifies the length in 512-octet blocks of the default 270 boot image for the client. The file length is specified as an 271 unsigned 16-bit integer. 273 The code for this option is 13, and its length is 2. 275 Code Len File Size 276 +-----+-----+-----+-----+ 277 | 13 | 2 | l1 | l2 | 278 +-----+-----+-----+-----+ 280 3.10. Domain Name 282 This option specifies the domain name that client should use when 283 resolving hostnames via the Domain Name System. 285 The code for this option is 15. Its minimum length is 1. 287 Code Len Domain Name 288 +-----+-----+-----+-----+-----+-----+-- 289 | 15 | n | d1 | d2 | d3 | d4 | ... 290 +-----+-----+-----+-----+-----+-----+-- 292 4. IP Layer Parameters per Host 294 This section details the options that affect the operation of the IP 295 layer on a per-host basis. 297 4.1. Maximum Datagram Reassembly Size 299 This option specifies the maximum size datagram that the client 300 should be prepared to reassemble. The size is specified as a 16-bit 301 unsigned integer. The minimum value legal value is 576 [3]. 303 The code for this option is 22, and its length is 2. 305 Code Len Size 306 +-----+-----+-----+-----+ 307 | 22 | 2 | s1 | s2 | 308 +-----+-----+-----+-----+ 310 4.2. Default IP Time-to-live 312 This option specifies the default time-to-live that the client should 313 use on outgoing datagrams. The TTL is specified as an octet with a 314 value between 1 and 255. 316 The code for this option is 23, and its length is 1. 318 Code Len TTL 319 +-----+-----+-----+ 320 | 23 | 1 | ttl | 321 +-----+-----+-----+ 323 4.3. Path MTU Aging Timeout Option 325 This option specifies the timeout (in seconds) to use when aging Path 326 MTU values discovered by the mechanism defined in RFC 1191 [6]. The 327 timeout is specified as a 32-bit unsigned integer. 329 The code for this option is 24, and its length is 4. 331 Code Len Timeout 332 +-----+-----+-----+-----+-----+-----+ 333 | 24 | 4 | t1 | t2 | t3 | t4 | 334 +-----+-----+-----+-----+-----+-----+ 336 5. IP Layer Parameters per Interface 338 This section details the options that affect the operation of the IP 339 layer on a per-interface basis. It is expected that a client can 340 issue multiple requests, one per interface, in order to configure 341 interfaces with their specific parameters. 343 5.1. Interface MTU Option 345 This option specifies the MTU to use on this interface. The MTU is 346 specified as a 16-bit unsigned integer. The minimum legal value for 347 the MTU is 68. 349 The code for this option is 26, and its length is 2. 351 Code Len MTU 352 +-----+-----+-----+-----+ 353 | 26 | 2 | m1 | m2 | 354 +-----+-----+-----+-----+ 356 5.2. Static Route Option 358 This option specifies a list of static routes that the client 359 should install in its routing cache. If multiple routes to the same 360 destination are specified, they are listed in descending order of 361 priority. 363 The routes consist of a list of IP address pairs. The first address 364 is the destination address, and the second address is the router for 365 the destination. 367 The default route (0.0.0.0) is an illegal destination for a static 368 route. See section 3.5 for information about the router option. 370 The code for this option is 33. The minimum length of this option is 371 32, and the length MUST be a multiple of 16. 373 Code Len Destination 1 Router 1 375 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 376 | 33 | n | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | 377 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 378 Destination 2 Router 2 379 +-----+-----+-----+-----+-----+-----+-----+-----+--- 380 | d1 | d2 | ... | d16 | r1 | r2 | ... | r16 | ... 381 +-----+-----+-----+-----+-----+-----+-----+-----+--- 383 6. TCP Parameters 385 This section lists the options that affect the operation of the TCP 386 layer on a per-interface basis. 388 6.1. TCP Default TTL Option 390 This option specifies the default TTL that the client should use when 391 sending TCP segments. The value is represented as an 8-bit unsigned 392 integer. The minimum value is 1. 394 The code for this option is 37, and its length is 1. 396 Code Len TTL 397 +-----+-----+-----+ 398 | 37 | 1 | n | 399 +-----+-----+-----+ 401 6.2. TCP Keepalive Interval Option 403 This option specifies the interval (in seconds) that the client TCP 404 should wait before sending a keepalive message on a TCP connection. 405 The time is specified as a 32-bit unsigned integer. A value of zero 406 indicates that the client should not generate keepalive messages on 407 connections unless specifically requested by an application. 409 The code for this option is 38, and its length is 4. 411 Code Len Time 412 +-----+-----+-----+-----+-----+-----+ 413 | 38 | 4 | t1 | t2 | t3 | t4 | 414 +-----+-----+-----+-----+-----+-----+ 416 7. Application and Service Parameters 418 This section details some miscellaneous options used to configure 419 miscellaneous applications and services. 421 7.1. Network Time Protocol Servers Option 423 This option specifies a list of IP addresses indicating NTP [4] 424 servers available to the client. Servers SHOULD be listed in order 425 of preference. 427 The code for this option is 42. Its minimum length is 16, and the 428 length MUST be a multiple of 16. 430 Code Len Address 1 Address 2 431 +-----+-----+-----+-----+-----+-----+-----+-----+-- 432 | 42 | n | a1 | a2 | a3 | ... | a16 | a1 | ... 433 +-----+-----+-----+-----+-----+-----+-----+-----+-- 435 7.2. Vendor Specific Information 437 This option is used by clients and servers to exchange vendor- 438 specific information. The information is an opaque object of n 439 octets, presumably interpreted by vendor-specific code on the clients 440 and servers. The definition of this information is vendor specific. 441 The vendor is indicated in the class-identifier option. Servers 442 not equipped to interpret the vendor-specific information sent by a 443 client MUST ignore it (although it may be reported). Clients which 444 do not receive desired vendor-specific information SHOULD make an 445 attempt to operate without it, although they may do so (and announce 446 they are doing so) in a degraded mode. 448 If a vendor potentially encodes more than one item of information 449 in this option, then the vendor SHOULD encode the option using 450 "Encapsulated vendor-specific options" as described below: 452 The Encapsulated vendor-specific options field SHOULD be encoded as 453 a sequence of type/length/value fields of identical syntax to the 454 DHCPv6 options field with the following exceptions: 456 - Codes other than 0 or 255 MAY be redefined by the vendor 457 within the encapsulated vendor-specific extensions field, 458 but SHOULD conform to the tag-length-value syntax defined in 459 section 2. 461 - Code 255 (END), if present, signifies the end of the 462 encapsulated vendor extensions, not the end of the vendor 463 extensions field. If no code 255 is present, then the end of 464 the enclosing vendor-specific information field is taken as 465 the end of the encapsulated vendor-specific extensions field. 467 The code for this option is 43 and its minimum length is 1. 469 Code Len Vendor-specific information 470 +-----+-----+-----+-----+--- 471 | 43 | n | i1 | i2 | ... 472 +-----+-----+-----+-----+--- 474 When encapsulated vendor-specific extensions are used, the 475 information bytes 1-n have the following format: 477 Code Len Data item Code Len Data item Code 478 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 479 | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... | 480 +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ 482 7.3. X Window System Font Server Option 484 This option specifies a list of X Window System [11] Font servers 485 available to the client. Servers SHOULD be listed in order of 486 preference. 488 The code for this option is 48. The minimum length of this option is 489 16 octets, and the length MUST be a multiple of 16. 491 Code Len Address 1 Address 2 492 +-----+-----+-----+-----+-----+-----+-----+-----+--- 493 | 48 | n | a1 | a2 | ... | a16 | a1 | a2 | ... 494 +-----+-----+-----+-----+-----+-----+-----+-----+--- 496 7.4. X Window System Display Manager Option 498 This option specifies a list of IP addresses of systems that are 499 running the X Window System Display Manager [11] and are available to 500 the client. 502 Addresses SHOULD be listed in order of preference. 504 The code for the this option is 49. The minimum length of this 505 option is 16, and the length MUST be a multiple of 16. 507 Code Len Address 1 Address 2 508 +-----+-----+-----+-----+-----+-----+-----+-----+--- 509 | 49 | n | a1 | a2 | ... | a16 | a1 | a2 | ... 510 +-----+-----+-----+-----+-----+-----+-----+-----+--- 512 8. DHCPv6 Extensions 514 This section details the options that are specific to DHCPv6. 516 8.1. Requested IP Address 518 This option is used in a DHCPv6 [2] client request (DISCOVER) to 519 allow the client to request that a particular IP address be assigned. 521 The code for this option is 50, and its length is 16. 523 Code Len Address 524 +-----+-----+-----+-----+-----+-----+ 525 | 50 | n | a1 | a2 | ... | a16 | 526 +-----+-----+-----+-----+-----+-----+ 528 8.2. Parameter Request List 530 This option is used by a DHCPv6 client to request values for 531 specified configuration parameters. The list of requested parameters 532 is specified as n octets, where each octet is a valid DHCPv6 option 533 code as defined in this document. 535 The client MAY list the options in order of preference. The DHCPv6 536 server is not required to return the options in the requested order, 537 but MUST try to insert the requested options in the order requested 538 by the client. 540 The code for this option is 55. Its minimum length is 1. 542 Code Len Option Codes 543 +-----+-----+-----+-----+--- 544 | 55 | n | c1 | c2 | ... 545 +-----+-----+-----+-----+--- 547 8.3. Message 549 This option is used by a DHCPv6 server to provide an error message to 550 a DHCPv6 client in a CONF-RESPONSE message in the event of a failure. 552 A client may use this option in a CONF-RESPONSE message to indicate 553 the why the client declined the offered parameters. The message 554 consists of n octets of NVT ASCII [8] text, which the client may 555 display on an available output device. 557 The code for this option is 56 and its minimum length is 1. 559 Code Len Text 560 +-----+-----+-----+-----+--- 561 | 56 | n | c1 | c2 | ... 562 +-----+-----+-----+-----+--- 564 8.4. Maximum DHCPv6 Message Size 566 This option specifies the maximum length DHCPv6 message that it is 567 willing to accept. The length is specified as an unsigned 16-bit 568 integer. A client may use the maximum DHCPv6 message size option 569 in DISCOVER or CONF-REQUEST messages, but should not use the option 570 in CONF-RESPONSE messages (see [2] for DISCOVER, CONF-REQUEST, and 571 CONF-RESPONSE message formats). 573 The code for this option is 57, and its length is 2. The minimum 574 legal value is 576 octets. 576 Code Len Length 577 +-----+-----+-----+-----+ 578 | 57 | 2 | l1 | l2 | 579 +-----+-----+-----+-----+ 581 8.5. Class-identifier 583 This option is used by DHCPv6 clients to optionally identify the type 584 and configuration of a DHCPv6 client. The information is a string of 585 n octets, interpreted by servers. Vendors and sites may choose to 586 define specific class identifiers to convey particular configuration 587 or other identification information about a client. For example, the 588 identifier may encode the client's hardware configuration. Servers 589 not equipped to interpret the class-specific information sent by a 590 client MUST ignore it (although it may be reported). 592 The code for this option is 60, and its minimum length is 1. 594 Code Len Class-Identifier 595 +-----+-----+-----+-----+--- 596 | 60 | n | i1 | i2 | ... 597 +-----+-----+-----+-----+--- 599 8.6. Client-identifier 601 This option is used by DHCPv6 clients to specify their unique 602 identifier. DHCPv6 servers use this value to index their database 603 of address bindings. This value is expected to be unique for all 604 clients in an administrative domain. 606 It is expected that this field will typically contain a hardware type 607 and hardware address, but this is not required. Current legal values 608 for hardware types are defined in [10]. 610 The code for this option is 61, and its minimum length is 2. 612 Code Len Type Client-Identifier 613 +-----+-----+-----+-----+-----+--- 614 | 61 | n | t1 | i1 | i2 | ... 615 +-----+-----+-----+-----+-----+--- 617 8.7. Mobile Home Address Option 619 When this option is present in a client request message, the DHCPv6 620 server is asked to send an appropriate home address to the mobile 621 host. The DHCPv6 server, in its corresponding offering message, will 622 insert the requested address into the usual place for requested IP 623 addresses. The DHCPv6 server will typically notify the mobile host 624 of (one of) its home agents' addresses, as configured by the local 625 administration to be associated with the address given to the mobile 626 host. That home agent's IP address is inserted in the data field of 627 the mobile home address option. 629 It is anticipated that the mobile-IP working group will approve one 630 of the current proposals for allowing a mobile host, with its already 631 known mobile home address, to dynamically discover the location of a 632 home agent serving the home address. In that case, the DHCPv6 server 633 may be configured to send out mobile home addresses and expect that 634 the mobile host discover the home agent's address by whichever method 635 is approved by the working group. 637 It is also anticipated that many installations will allow several 638 home agents to serve the same mobile home addresses, for redundancy 639 or load sharing. For this reason, we have also allowed for the 640 possibility that the DHCPv6 server may wish to insert multiple home 641 agent addresses in the mobile home address option. 643 The format of the mobile home address option is as follows: 645 Code Len Home Agent Addresses (zero or more) 646 +----+----+ - -+ - -+-----+ - --+ - -+ - -+ - -+ 647 | 68 | n | a1 | a2 | ... | a16 | ... 648 +----+----+ - -+ - -+-----+ - --+ - -+ - -+ - -+ 650 The code for the mobile home address option is 68. The length is 651 16 octets multiplied by the number of home agents supplied in the 652 option, which may be zero or more. It is expected that the usual 653 length will be sixteen octets, containing a single home agent's 654 address. 656 9. Neighbor Discovery Extensions 658 This section contains option definitions for specifying parameters 659 that are useful with IPv6 Neighbor Discovery [7]. 661 10. Extensions 663 Additional generic data fields may be registered by contacting: 665 Internet Assigned Numbers Authority (IANA) 666 USC/Information Sciences Institute 667 4676 Admiralty Way 668 Marina del Rey, California 90292-6695 670 or by email as: iana@isi.edu 672 Implementation specific use of undefined generic types (including 673 those in the range 69-127) may conflict with other implementations, 674 and registration is required. 676 11. Acknowledgements 678 Quite a bit of this internet draft is copied directly from 679 RFC1533 [1], written by Steve Alexander and Ralph Droms. 681 12. Security Considerations 683 Security issues are not discussed in this memo. However, there 684 is an urgent need to define some security protocol for use with 685 DHCPv6, since otherwise malicious parties could create numerous 686 denial-of-service style attacks based on depleting available server 687 resources or providing corrupted or infected data to unsuspecting 688 clients. 690 References 692 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 693 Extensions. RFC 1533, October 1993. 695 [2] J. Bound. Dynamic Host Configuration Protocol for IPv6. 696 draft-ietf-dhc-dhcpv6-03.txt -- work in progress, November 1995. 698 [3] R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. 699 draft-ietf-ipngwg-ipv6-spec-02.txt - work in progress, June 700 1995. 702 [4] D. Mills. Network Time Protocol (Version 3). RFC 1305, March 703 1992. 705 [5] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND 706 SPECIFICATION. RFC 1035, November 1987. 708 [6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, 709 November 1990. 711 [7] T. Narten, E. Nordmark, and W. Simpson. IPv6 Neighbor 712 Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in 713 progress, November 1995. 715 [8] J. Postel and J. Reynolds. Telnet Protocol Specification. RFC 716 854, May 1983. 718 [9] J. Reynolds. BOOTP Vendor Information Extensions. RFC 1497, 719 August 1993. 721 [10] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October 722 1994. 724 [11] R. Scheifler. FYI On the X Window System. RFC 1198, January 725 1991. 727 [12] J. Veizades, S. Kaplan, and E. Guttman. Service Location 728 Protocol. draft-ietf-svrloc-protocol-07.txt - work in progress, 729 October 1995. 731 Chair's Addresses 733 The working group can be contacted via the current chair: 735 Ralph Droms 736 Computer Science Department 737 323 Dana Engineering 738 Bucknell University 739 Lewisburg, PA 17837 741 Phone: (717) 524-1145 742 EMail: droms@bucknell.edu 744 Author's Address 746 Questions about this memo can be directed to: 748 Charles Perkins 749 Room J1-A25 750 T. J. Watson Research Center 751 IBM Corporation 752 30 Saw Mill River Rd. 753 Hawthorne, NY 10532 755 Work: +1-914-784-7350 756 Fax: +1-914-784-7007 757 E-mail: perk@watson.ibm.com