idnits 2.17.1 draft-ietf-dhc-option-guidelines-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- 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 (September 18, 2013) is 3844 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-06) exists of draft-ietf-dhc-v4configuration-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-06 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-04 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group Google 4 Internet-Draft T. Mrugalski 5 Updates: 3315 (if approved) M. Siodelski 6 Intended status: BCP ISC 7 Expires: March 22, 2014 S. Jiang 8 Huawei Technologies Co., Ltd 9 S. Krishnan 10 Ericsson 11 September 18, 2013 13 Guidelines for Creating New DHCPv6 Options 14 draft-ietf-dhc-option-guidelines-14 16 Abstract 18 This document provides guidance to prospective DHCPv6 Option 19 developers to help them creating option formats that are easily 20 adoptable by existing DHCPv6 software. This document updates 21 RFC3315. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 22, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 5 60 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 6 62 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 7 63 5.2. Option with a single flag (boolean) . . . . . . . . . . . 8 64 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 8 65 5.4. Option with 32-bit integer value . . . . . . . . . . . . . 9 66 5.5. Option with 16-bit integer value . . . . . . . . . . . . . 10 67 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 10 68 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 10 69 5.8. Option with Text String . . . . . . . . . . . . . . . . . 11 70 5.9. Option with variable length data . . . . . . . . . . . . . 13 71 5.10. Option with DNS Wire Format Domain Name List . . . . . . . 13 72 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 14 73 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8. Choosing between FQDN and address . . . . . . . . . . . . . . 15 75 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . . 16 76 10. Additional States Considered Harmful . . . . . . . . . . . . . 17 77 11. Configuration changes occur at fixed times . . . . . . . . . . 18 78 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 19 79 13. Chartering Requirements and Advice for Responsible ADs . . . . 19 80 14. Considerations for Creating New Formats . . . . . . . . . . . 20 81 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 21 83 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 22 85 19. Clients Request their Options . . . . . . . . . . . . . . . . 23 86 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 24 87 21. Recommended sections in the new document . . . . . . . . . . . 24 88 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . . 25 89 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . . 26 90 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . . 26 91 22. Should the new document update existing RFCs? . . . . . . . . 26 92 23. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 94 25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 95 26. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 26.1. Normative References . . . . . . . . . . . . . . . . . . . 28 97 26.2. Informative References . . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Requirements Language 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 2. Introduction 108 Most protocol developers ask themselves if a protocol will work, or 109 work efficiently. These are important questions, but another less 110 frequently considered question is whether the proposed protocol 111 presents itself needless barriers to adoption by deployed software. 113 DHCPv6 [RFC3315] software implementors are not merely faced with the 114 task of handling a given option's format on the wire. The option 115 must fit into every stage of the system's process, starting with the 116 user interface used to enter the configuration up to the machine 117 interfaces where configuration is ultimately consumed. 119 Another frequently overlooked aspect of rapid adoption is whether the 120 option requires operators to be intimately familiar with the option's 121 internal format in order to use it? Most DHCPv6 software provides a 122 facility for handling unknown options at the time of publication. 123 The handling of such options usually needs to be manually configured 124 by the operator. But if doing so requires extensive reading (more 125 than can be covered in a simple FAQ for example), it inhibits 126 adoption. 128 So although a given solution would work, and might even be space, 129 time, or aesthetically optimal, a given option is presented with a 130 series of ever-worsening challenges to be adopted: 132 o If it doesn't fit neatly into existing config files. 134 o If it requires source code changes to be adopted, and hence 135 upgrades of deployed software. 137 o If it does not share its deployment fate in a general manner with 138 other options, standing alone in requiring code changes or 139 reworking configuration file syntaxes. 141 o If the option would work well in the particular deployment 142 environment the proponents currently envision, but has equally 143 valid uses in some other environment where the proposed option 144 format would fail or would produce inconsistent results. 146 There are many things DHCPv6 option creators can do to avoid the 147 pitfalls in this list entirely, or failing that, to make software 148 implementors lives easier and improve its chances for widespread 149 adoption. 151 3. When to Use DHCPv6 153 Principally, DHCPv6 carries configuration parameters for its clients. 154 Any knob, dial, slider, or checkbox on the client system, such as "my 155 domain name servers", "my hostname", or even "my shutdown 156 temperature" are candidates for being configured by DHCPv6. 158 The presence of such a knob isn't enough, because DHCPv6 also 159 presents the extension of an administrative domain - the operator of 160 the network to which the client is currently attached. Someone runs 161 not only the local switching network infrastructure that the client 162 is directly (or wirelessly) attached to, but the various methods of 163 accessing the external Internet via local assist services that the 164 network must also provide (such as domain name servers, or routers). 165 This means that, even if a configuration parameter can potentially 166 delivered by DHCPv6, it is necessary to evaluate whether it is 167 reasonable for this parameter to be under the control of the 168 administrator of whatever network a client is attached to at any 169 given time. 171 Note that the client is not required to configure any of these values 172 received via DHCPv6 (e.g., due to having these values locally 173 configured by its own administrator). But it needs to be noted that 174 overriding DHCPv6-provided values may cause the client to be denied 175 certain services in the network to which it has attached. The 176 possibility of having higher level of control over client node 177 configuration is one of the reasons that DHCPv6 is preferred in 178 enterprise networks. 180 4. General Principles 182 The primary guiding principle to follow in order to enhance an 183 option's adoptability is reuse. The option should be created in such 184 a way that does not require any new or special case software to 185 support. If old software currently deployed and in the field can 186 adopt the option through supplied configuration facilities then it's 187 fairly certain that new software can easily formally adopt it. 189 There are at least two classes of DHCPv6 options: simple options 190 which are provided explicitly to carry data from one side of the 191 DHCPv6 exchange to the other (such as nameservers, domain names, or 192 time servers), and a protocol class of options which require special 193 processing on the part of the DHCPv6 software or are used during 194 special processing (such as the Fully Qualified Domain Name (FQDN) 195 option [RFC4704]), and so forth; these options carry data that is the 196 result of a routine in some DHCPv6 software. 198 The guidelines laid out here should be applied in a relaxed manner 199 for the protocol class of options. Wherever special case code is 200 already required to adopt the DHCPv6 option, it is substantially more 201 reasonable to format the option in a less generic fashion, if there 202 are measurable benefits to doing so. 204 5. Reusing Other Options Formats 206 The easiest approach to manufacturing trivially deployable DHCPv6 207 Options is to assemble the option out of whatever common fragments 208 fit - possibly allowing a group of data elements to repeat to fill 209 the remaining space (if present) and so provide multiple values. 210 Place all fixed size values at the start of the option, and any 211 variable/indeterminate sized value at the tail end of the option. 213 This means that implementations will likely be able to reuse code 214 paths designed to support the other options. 216 There is a tradeoff between the adoptability of previously defined 217 option formats, and the advantages that new or specialized formats 218 can provide. In general, it is usually preferable to reuse 219 previously used option formats. 221 However, it isn't very practical to consider the bulk of DHCPv6 222 options already allocated, and consider which of those solve a 223 similar problem. So, the following list of common option format data 224 elements is provided as a shorthand. Please note that it is not 225 complete in terms of exampling every option format ever devised. 227 If more complex options are needed, those basic formats mentioned 228 here may be considered as primitives (or 'fragment types') that can 229 be used to build more complex formats. It should be noted that it is 230 often easier to implement two options with trivial formats than one 231 option with more complex format. That is not unconditional 232 requirement though. In some cases splitting one complex option into 233 two or more simple options introduces inter-option dependencies that 234 should be avoided. In such a case, it is usually better to keep one 235 complex option. 237 5.1. Option with IPv6 addresses 239 This option format is used to carry one or many IPv6 addresses. In 240 some cases the number of allowed address is limited (e.g. to one): 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | option-code | option-len | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 | ipv6-address | 248 | | 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | | 252 | ipv6-address | 253 | | 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | ... | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 1: Option with IPv6 address 261 Examples of use: 263 o DHCPv6 server unicast address (a single address only) [RFC3315] 265 o SIP Servers IPv6 Address List [RFC3319] 267 o DNS Recursive Name Server [RFC3646] 269 o NIS Servers [RFC3898] 271 o SNTP Servers [RFC4075] 273 o Broadcast and Multicast Service Controller IPv6 Address Option for 274 DHCPv6 [RFC4280] 276 o MIPv6 Home Agent Address [RFC6610] (a single address only) 278 o NTP server [RFC5908] (a single address only) 280 o NTP Multicast address [RFC5908] (a single address only) 282 5.2. Option with a single flag (boolean) 284 Sometimes it is useful to convey a single flag that can either take 285 on or off values. Instead of specifying an option with one bit of 286 usable data and 7 bits of padding, it is better to define an option 287 without any content. It is the presence or absence of the option 288 that conveys the value. This approach has the additional benefit of 289 absent option designating the default, i.e. administrator has to take 290 explicit actions to deploy the opposite of the default value. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | option-code | option-len | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Figure 2: Option for conveying boolean 299 Examples of use: 301 o DHCPv6 rapid-commit [RFC3315] 303 5.3. Option with IPv6 prefix 305 Sometimes there is a need to convey an IPv6 prefix. The information 306 to be carried by such an option includes the 128-bit IPv6 prefix 307 together with a length of this prefix taking values from 0 to 128. 308 Using the simplest approach, the option could convey this data in two 309 fixed length fields: one carrying prefix length, another carrying the 310 prefix. However, in many cases /64 or shorter prefixes are used. 311 This implies that the large part of the prefix data carried by the 312 option would have its bits set to zero and would be unused. In order 313 to avoid carrying unused data, it is recommended to store prefix in 314 the variable length data field. The appropriate option format is 315 defined as follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | option-code | option-length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | prefix6-len | ipv6-prefix | 323 +-+-+-+-+-+-+-+-+ (variable length) | 324 . . 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 3: Option with IPv6 Prefix 329 option-length is set to 1 + length of the IPv6 prefix. 331 prefix6-len is one octet long and specifies the length in bits of the 332 IPv6 prefix. Typically allowed values are 0 to 128. 334 ipv6-prefix field is a variable length field that specifies the IPv6 335 prefix. The length is (prefix6-len + 7) / 8. This field is padded 336 with zero bits up to the nearest octet boundary when prefix6-len is 337 not divisible by 8. 339 Examples of use: 341 o Default Mapping Rule [I-D.ietf-softwire-map-dhcp] 343 For example, the prefix 2001:db8::/60 would be encoded with an 344 option-length of 9, prefix6-len would be set to 60, the ipv6-prefix 345 would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00. 347 It should be noted that the IAPREFIX option defined by [RFC3633] uses 348 a full length 16-octet prefix field. The concern about option length 349 was not well understood at the time of its publication. 351 5.4. Option with 32-bit integer value 353 This option format can be used to carry 32 bit-signed or unsigned 354 integer value: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | option-code | option-len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | 32-bit-integer | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 4: Option with 32-bit-integer value 365 Examples of use: 367 o Information Refresh Time [RFC4242] 369 5.5. Option with 16-bit integer value 371 This option format can be used to carry 16-bit signed or unsigned 372 integer values: 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | option-code | option-len | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 16-bit-integer | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 5: Option with 16-bit integer value 383 Examples of use: 385 o Elapsed Time [RFC3315] 387 5.6. Option with 8-bit integer value 389 This option format can be used to carry 8-bit integer values: 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | option-code | option-len | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | 8-bit-integer | 396 +-+-+-+-+-+-+-+-+ 398 Figure 6: Option with 8-bit integer value 400 Examples of use: 402 o DHCPv6 Preference [RFC3315] 404 5.7. Option with URI 406 A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence 407 of characters that identifies an abstract or physical resource. The 408 term "Uniform Resource Locator" (URL) refers to the subset of URIs 409 that, in addition to identifying a resource, provide a means of 410 locating the resource by describing its primary access mechanism 411 (e.g., its network "location"). This option format can be used to 412 carry a single URI: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | option-code | option-len | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 . URI (variable length) . 420 | ... | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 7: Option with URI 425 Examples of use: 427 o Boot File URL [RFC5970] 429 An alternate encoding to support multiple URIs is available. An 430 option must be defined to use either the single URI format above or 431 the multiple URI format below depending on whether a single is always 432 sufficient or if multiple URIs are possible. 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | option-code | option-len | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 . . 439 . uri-data . 440 . . . . . 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 8: Option with multiple URIs 445 Each instance of the uri-data is formatted as follows: 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 448 | uri-len | URI | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 451 The uri-len is two octets long and specifies the length of the uri 452 data. 454 5.8. Option with Text String 456 A text string is a sequence of characters that have no semantics. 457 The encoding of the text string MUST be specified. Unless otherwise 458 specified, all text strings in newly defined options are expected to 459 be Unicode strings that are encoded using UTF-8 [RFC3629] in Net- 460 Unicode form [RFC5198]. Please note that all strings containing only 461 7 bit ASCII characters are also valid UTF-8 Net-Unicode strings. 463 If a data format has semantics other than just being text, it is not 464 a string. E.g., a FQDN is not a string, and a URI is also not a 465 string, because they have different semantics. A string must not 466 enclude any terminator (such as a null byte). This option format can 467 be used to carry a text string: 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | option-code | option-len | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 . String . 474 | ... | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Figure 9: Option with text string 479 Examples of use: 481 o Timezone Options for DHCPv6 [RFC4833] 483 An alternate encoding to support multiple text strings is available. 484 An option must be defined to use either the single text string format 485 above or the multiple text string format below depending on whether a 486 single is always sufficient or if multiple text strings are possible. 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | option-code | option-len | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 . . 493 . text-data . 494 . . . . . 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 Figure 10: Option with multiple text strings 499 Each instance of the text-data is formatted as follows: 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 502 | text-len | String | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 505 The text-len is two octets long and specifies the length of the 506 string. 508 5.9. Option with variable length data 510 This option can be used to carry variable length data of any kind. 511 Internal representation of carried data is option specific. Whenever 512 this format is used by the new option being defined, the data 513 encoding should be documented. 515 This option format provides a lot of flexibility to pass data of 516 almost any kind. Though, whenever possible it is highly recommended 517 to use more specialized options, with field types better matching 518 carried data types. 519 0 1 2 3 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | option-code | option-len | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 . . 525 . variable length data . 526 . . 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 Figure 11: Option with variable length data 531 Examples of use: 533 o Client Identifier [RFC3315] 535 o Server Identifier [RFC3315] 537 5.10. Option with DNS Wire Format Domain Name List 539 This option is used to carry 'domain search' lists or any host or 540 domain name. It uses the same format as described in Section 5.9, 541 but with the special data encoding, described in section 8 of 542 [RFC3315]. This data encoding supports carrying multiple instances 543 of hosts or domain names in a single option, by terminating each 544 instance with the byte value of 0. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | option-code | option-length | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | DNS Wire Format Domain Name List | 551 | ... | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 12: Option with DNS Wire Format Domain Name List 556 Examples of use: 558 o SIP Servers Domain Name List [RFC3319] (many domains) 560 o NIS Domain Name (many domains) [RFC3898] (many domains) 562 o DS-Lite AFTR location [RFC6334] (a single FQDN) 564 o Home Network Identifier [RFC6610] (a single FQDN) 566 o Home Agent FQDN [RFC6610] (a single FQDN) 568 6. Avoid Conditional Formatting 570 Placing an octet at the start of the option which informs the 571 software how to process the remaining octets of the option may appear 572 simple to the casual observer. But the only conditional formatting 573 methods that are in widespread use today are 'protocol' class 574 options. Therefore conditional formatting requires new code to be 575 written and complicates future interoperability should new 576 conditional formats be added; and existing code has to ignore 577 conditional format that it does not support. 579 7. Avoid Aliasing 581 Options are said to be aliases of each other if they provide input to 582 the same configuration parameter. A commonly proposed example is to 583 configure the location of some new service ("my foo server") using a 584 binary IP address, a domain name field, and an URL. This kind of 585 aliasing is undesirable, and is not recommended. 587 In this case, where three different formats are supposed, it more 588 than triples the work of the software involved, requiring support for 589 not merely one format, but support to produce and digest all three. 590 Furthermore, code development and testing must cover all possible 591 combinations of defined formats. Since clients cannot predict what 592 values the server will provide, they must request all formats. So in 593 the case where the server is configured with all formats, DHCPv6 594 message bandwidth is wasted on option contents that are redundant. 595 Also, the DHCPv6 option number space is wasted, as three new option 596 codes are required, rather than one. 598 It also becomes unclear which types of values are mandatory, and how 599 configuring some of the options may influence the others. For 600 example, if an operator configures the URL only, should the server 601 synthesize a domain name and IP address? 602 A single configuration value on a host is probably presented to the 603 operator (or other software on the machine) in a single field or 604 channel. If that channel has a natural format, then any alternative 605 formats merely make more work for intervening software in providing 606 conversions. 608 So the best advice is to choose the one method that best fulfills the 609 requirements, be that for simplicity (such as with an IP address and 610 port pair), late binding (such as with DNS), or completeness (such as 611 with a URL). 613 8. Choosing between FQDN and address 615 Some parameters may be specified as FQDN or an address. It is not 616 allowed to define both option types at the same time (see section 617 Section 7), so one of them must be chosen. This section is intended 618 to help make an informed decision in that regard. 620 On the specific subject of desiring to configure a value using a FQDN 621 instead of a binary IP address, note that most DHCPv6 server 622 implementations will happily accept a Domain Name entered by the 623 administrator, and use DNS resolution to render binary IP addresses 624 in DHCPv6 replies to clients. Consequently, consider the extra 625 packet overhead incurred on the client's end to perform DNS 626 resolution itself. The client may be operating on a battery and 627 packet transmission is a non-trivial use of power, and the extra RTT 628 delays the client must endure before the service is configured are at 629 least two factors to consider in making a decision on format. 631 Unless there are specific reasons to do otherwise, address should be 632 used. It is simpler to use, its validation is trivial (length of 16 633 constitutes a valid option), is explicit and does not allow any 634 ambiguity. It is faster (does not require extra resolution efforts), 635 so it is more efficient, which can be especially important for energy 636 restricted devices. 638 FQDN options are discouraged for options intended to configure hosts, 639 because hosts may have multiple provisioning domains (see 640 Section 12), and may get a different answer from the DNS depending on 641 the provisioning domain. This is particularly a problem when the 642 normal expected use of the option makes sense with private DNS 643 zone(s), as might be the case with a corporate VPN. 645 FQDN does require a resolution into an actual address. This implies 646 the question when the FQDN resolution should be taken. There are a 647 couple of possible answers: a) by the server, when it is started, b) 648 by the server, when it is about to send an option, c) by the client, 649 immediately after receiving an option, d) by the client, when the 650 content of the option is actually consumed. For a), b) and possibly 651 c), the option should really convey an address, not FQDN. The only 652 real incentive to use FQDN is case d). It is the only case that 653 allows possible changes in the DNS to be picked up by clients. 655 FQDN imposes a number of additional failure modes and issues that 656 should be dealt with: 658 1. The client must have a knowledge about available DNS servers. 659 That typically means that option DNS_SERVERS is mandatory. This 660 should be mentioned in the draft that defines new option. It is 661 possible that the server will return FQDN option, but not the DNS 662 Servers option. There should be a brief discussion about it; 664 2. The DNS may not be reachable; 666 3. DNS may be available, but may not have appropriate information 667 (e.g. no AAAA records for specified FQDN); 669 4. Address family must be specified (A, AAAA or any); 671 5. What should the client do if there are multiple records available 672 (use only the first one, use all, use one and switch to the 673 second if the first fails for whatever reason, etc.); 675 6. Multi-homed devices may be connected to different administrative 676 domains with each domain providing different information in DNS 677 (e.g. an enterprise network exposing private domains). Client 678 may send DNS queries to a different DNS server; 680 7. It should be mentioned if Internationalized Domain Names are 681 allowed. If they are, what kind of DNS option encoding should be 682 specified. 684 9. Encapsulated options in DHCPv6 686 Most options are conveyed in a DHCPv6 message directly. Although 687 there is no codified normative language for such options, they are 688 often referred to as top-level options. Many options may include 689 other options. Such inner options are often referred to as 690 encapsulated or nested options. Those options are sometimes called 691 sub-options, but this term actually means something else, and 692 therefore should never be used to describe encapsulated options. It 693 is recommended to use term "encapsulated" as this terminology is used 694 in [RFC3315]. The difference between encapsulated and sub-options 695 are that the former uses normal DHCPv6 option numbers, while the 696 latter uses option number space specific to a given parent option. 697 It should be noted that, contrary to DHCPv4, there is no shortage of 698 option numbers. Therefore almost all options share a common option 699 space. For example option type 1 meant different things in DHCPv4, 700 depending if it was located in top-level or inside of Relay Agent 701 Information option. There is no such ambiguity in DHCPv6 (with the 702 unfortunate exception of [RFC5908],which was published without 703 following the advice provided during the DHC working group review, 704 and contains many errors. [RFC5908] SHOULD NOT under any 705 circumstances be used as a template for future DHCP option 706 definitions. 708 From the implementation perspective, it is easier to implement 709 encapsulated options rather than sub-options, as the implementers do 710 not have to deal with separate option spaces and can use the same 711 buffer parser in several places throughout the code. 713 Such encapsulation is not limited to one level. There is at least 714 one defined option that is encapsulated twice: Identity Association 715 for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) 716 conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such 717 delegated prefix may contain an excluded prefix range that is 718 represented by PD_EXCLUDE option that is conveyed as encapsulated 719 inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward 720 to refer to such options as sub-sub-option or doubly encapsulated 721 option, therefore "encapsulated option" term is typically used, 722 regardless of the nesting level. 724 When defining a DHCP-based configuration mechanism for a protocol 725 that requires something more complex than a single option, it may be 726 tempting to group configuration values using sub-options. That 727 should preferably be avoided, as it increases complexity of the 728 parser. It is much easier, faster and less error prone to parse a 729 large number of options on a single (top-level) scope, than parse 730 options on several scopes. The use of sub-options should be avoided 731 as much as possible, but it is better to use sub-options rather than 732 conditional formatting. 734 It should be noted that currently there is no clear way defined for 735 requesting sub-options. Most known implementations are simply using 736 top-level ORO for requesting both top-level options and encapsulated 737 options. 739 10. Additional States Considered Harmful 741 DHCP is a protocol designed for provisioning clients. Less 742 experienced protocol designers often assume that it is easy to define 743 an option that will convey a different parameter for each client in a 744 network. Such problems arose during designs of MAP 745 [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While 746 it would be easier for provisioned clients to get ready to use per- 747 client option values, such requirement puts exceedingly large loads 748 on the server side. The new extensions may introduce new 749 implementation complexity and additional database state on the 750 server. Alternatives should be considered, if possible. As an 751 example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all 752 clients are provisioned with the same set of MAP options and each 753 provisioned client uses its unique address and delegated prefix to 754 generate client-specific information. Such a solution does not 755 introduce any additional state for the server and therefore scales 756 better. 758 It also should be noted that contrary to DHCPv4, DHCPv6 keeps several 759 timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) 760 contains T1 and T2 timers that designate time after which client will 761 initiate renewal. Those timers apply only to its own IA containers. 762 Refreshing other parameters should be initiated after a time 763 specified in the Information Refresh Time Option (defined in 764 [RFC4242]), carried in the Reply message and returned in response to 765 Information-Request message. Introducing additional timers make 766 deployment unnecessarily complex and SHOULD be avoided. 768 11. Configuration changes occur at fixed times 770 In general, DHCPv6 clients only refresh configuration data from the 771 DHCP server when the T1 timer expires. Although there is a 772 RECONFIGURE mechanism that allows a DHCP server to request that 773 clients initiate reconfiguration, support for this mechanism is 774 optional and cannot be relied upon. 776 Even when DHCP clients refresh their configuration information, not 777 all consumers of DHCP-sourced configuration data notice these 778 changes. For instance, if a server is started using parameters 779 received in an early DHCP transaction, but does not check for updates 780 from DHCP, it may well continue to use the same parameter 781 indefinitely. There are a few operating systems that take care of 782 reconfiguring services when the client moves to a new network(e.g. 783 based on mechanisms like [RFC4436], [RFC4957] or [RFC6059]), but it's 784 worth bearing in mind that a renew may not always result in the 785 client taking up new configuration information that it receives. 787 In light of the above, when designing an option you should take into 788 consideration the fact that your option may hold stale data that will 789 only be updated at an arbitrary time in the future. 791 12. Multiple provisioning domains 793 In some cases there could be more than one DHCPv6 server on a link, 794 with each providing a different set of parameters. One notable 795 example of such a case is a home network with a connection to two 796 independent ISPs. 798 The DHCPv6 protocol specification does not provide clear advice on 799 how to handle multiple provisioning sources. Although [RFC3315] 800 states that a client that receives more than one ADVERTISE message, 801 may respond to one or more of them, such capability has not been 802 observed in existing implementations. Existing clients will pick one 803 server and will continue configuration process with that server, 804 ignoring all other servers. 806 In addition, a node that acts as a DHCPv6 client may be connected to 807 more than one physical network. In this case, it will in most cases 808 operate a separate DHCP client state machine on each interface, 809 acquiring different, possibly conflicting information through each. 810 This information will not be acquired in any synchronized way. 812 Existing nodes cannot be assumed to systematically segregate 813 configuration information on the basis of its source; as a result, it 814 is quite possible that a node may receive an FQDN on one network 815 interface, but do the DNS resolution on a different network 816 interface, using different DNS servers. As a consequence, DNS 817 resolution done by the DHCP server is more likely to behave 818 predictably than DNS resolution done on a multi-interface or multi- 819 homed client. 821 This is a generic DHCP protocol issue and should not be dealt within 822 each option separately. This issue is better dealt with using a 823 protocol-level solution and fixing this problem should not be 824 attempted on a per option basis. Work is ongoing in the IETF to 825 provide a systematic solution to this problem. 827 13. Chartering Requirements and Advice for Responsible ADs 829 Adding a simple DHCP option is straightforward, and generally 830 something that any working group can do, perhaps with some help from 831 designated DHCP experts. However, when new fragment types need to be 832 devised, this requires the attention of DHCP experts, and should not 833 be done in a working group that doesn't have a quorum of such 834 experts. This is true whether the new fragment type has the same 835 structure as an existing fragment type, but has different semantics. 836 It is equally true when the new format has a new structure. 838 Responsible Area Directors for working groups that wish to add a work 839 item to a working group charter to define a new DHCP option should 840 get clarity from the working group as to whether the new option is a 841 simple DHCP option with no new fragment type or new fragment 842 semantics, or whether it in fact will require new fragment types. A 843 working group charter item should explicitly state which of these two 844 types is required; if it is not known at the time of chartering, the 845 charter should state that the working group will study the question 846 and recharter or seek help elsewhere if a new fragment type is to be 847 defined. 849 If a working group needs a new fragment type, it is preferable to 850 seek out a working group whose members already have sufficient 851 expertise to evaluate the new work and try to come up with a new 852 format that generalizes well and can be reused, rather than a single- 853 use fragment type. If such a working group is available, the work 854 should be chartered in that working group as a separate draft that 855 documents the new fragment type. The working group that needs the 856 new fragment type can then define their new option referencing the 857 new fragment type document. This work can generally be done in 858 parallel so as not to delay the process significantly. 860 In the event that there is no working group with DHCP expertise that 861 can define the new fragment type, the responsible AD should seek out 862 help from known DHCP experts within the IETF to provide advice and 863 frequent early review as the working group defines the new fragment 864 type. The new fragment type should still be done in a separate 865 document, even if it's done in the same working group, so as to 866 foster reuse of the new fragment type. The responsible AD should 867 work with the working group chairs and designated DHCP experts to 868 ensure that new fragment type document has in fact been carefully 869 reviewed by the experts and appears satisfactory. 871 Responsible area directors for working groups that are considering 872 defining options that actually update the DHCP protocol, as opposed 873 to simple options, should go through a process similar to that 874 described above when trying to determine where to do the work. Under 875 no circumstances should a working group be given a charter 876 deliverable to define a new DHCP option, and then on the basis of 877 that charter item actually make updates to the DHCP protocol. 879 14. Considerations for Creating New Formats 881 When defining new options, one specific consideration to evaluate is 882 whether or not options of a similar format would need to have 883 multiple or single values encoded (whatever differs from the current 884 option), and how that might be accomplished in a similar format. 886 When defining a new option, it is best to synthesize the option 887 format using fragment types already in use. However, in some cases 888 there may be no fragment type that accomplishes the intended purpose. 890 The matter of size considerations and option order are further 891 discussed in Section 15 and Section 17. 893 15. Option Size 895 DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through 896 its use of link-local addresses, it avoids many of the deployment 897 problems that plague DHCPv4, and is actually an UDP over IPv6 based 898 protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol, 899 but with layer 2 hacks). Second, RFC 3315 explicitly refers readers 900 to RFC 2460 Section 5, which describes an MTU of 1280 octets and a 901 minimum fragment reassembly of 1500 octets. It's feasible to suggest 902 that DHCPv6 is capable of having larger options deployed over it, and 903 at least no common upper limit is yet known to have been encoded by 904 its implementors. It is not really possible to describe a fixed 905 limit that cleanly divides workable option sizes from those that are 906 too big. 908 It is advantageous to prefer option formats which contain the desired 909 information in the smallest form factor that satisfies the 910 requirements. Common sense still applies here. It is better to 911 split distinct values into separate octets rather than propose overly 912 complex bit shifting operations to save several bits (or even an 913 octet or two) that would be padded to the next octet boundary anyway. 915 DHCPv6 does allow for multiple instances of a given option, and they 916 are treated as distinct values following the defined format, however 917 this feature is generally preferred to be restricted to protocol 918 class features (such as the IA_* series of options). In such cases, 919 it is better to define an option as an array if it is possible. It 920 is recommended to clarify (with normative language) whether a given 921 DHCPv6 option may appear once or multiple times. The default 922 assumption is only once. 924 In general, if a lot of data needs to be configured (i.e. large 925 option lengths), DHCPv6 may not be the best choice to deliver such 926 configuration information and SHOULD simply be used to deliver an URI 927 that specifies how to obtain the actual configuration information. 929 16. Singleton options 931 Although [RFC3315] states that each option type MAY appear more than 932 once, the original idea was that multiple instances are reserved for 933 stateful options, like IA_NA or IA_PD. For most other options it is 934 usually expected that they will appear at most once. Such options 935 are called singleton options. Sadly, RFCs have often failed to 936 clearly specify whether a given option can appear more than once or 937 not. Documents that define new options SHOULD state whether these 938 options are singletons or not. Unless otherwise specified, newly 939 defined options are considered to be singletons. 941 When deciding whether a single or multiple option instances are 942 allowed in a message, take into consideration how the content of the 943 option will be used. Depending on the service being configured it 944 may or may not make sense to have multiple values configured. If 945 multiple values make sense, it is better to explicitly allow that by 946 using option format that allows multiple values within one option 947 instance. 949 Allowing multiple option instances often leads to confusion. 950 Consider the following example. Basic DS-Lite architecture assumes 951 that the B4 element (DHCPv6 client) will receive AFTR option and 952 establish a single tunnel to configured tunnel termination point 953 (AFTR). During standardization process of [RFC6334] there was a 954 discussion whether multiple instances of DS-Lite tunnel option should 955 be allowed. This created an unfounded expectation that the clients 956 receiving multiple instances of the option will somehow know when one 957 tunnel endpoint goes off-line and do some sort of failover between 958 other values provided in other instances of the AFTR option. Others 959 assumed that if there are multiple options, the client will somehow 960 do a load balancing between provided tunnel endpoints. Neither 961 failover nor load balancing was defined for DS-Lite architecture, so 962 it caused confusion. It was eventually decided to allow only one 963 instance of the AFTR option. 965 17. Option Order 967 Option order, either the order among many DHCPv6 options or the order 968 of multiple instances of the same option, SHOULD NOT be significant 969 and MUST NOT be assumed. 971 As there is no explicit order for multiple instance of the same 972 option, an option definition SHOULD instead restrict ordering by 973 using a single option that contains ordered fields. 975 18. Relay Options 977 In DHCPv4, all relay options are organized as sub-options within DHCP 978 Relay Agent Information Option[RFC3046]. And an independent number 979 space called "DHCP Relay Agent Sub-options" is maintained by IANA. 980 Different from DHCPv4, in DHCPv6, Relay options are defined in the 981 same way as client/server options, and they too use the same number 982 space as client/server options. Future DHCPv6 Relay options MUST be 983 allocated from this single DHCPv6 Option number space. 985 E.g. the Relay-Supplied Options Option [RFC6422] may also contain 986 some DHCPv6 options as permitted, such as the EAP Re-authentication 987 Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440]. 989 19. Clients Request their Options 991 The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 992 that serves two purposes - to inform the server what options the 993 client supports and to inform what options the client is willing to 994 consume. 996 For some options, such as the options required for the functioning of 997 the DHCPv6 protocol itself, it doesn't make sense to require that 998 they be explicitly requested using the Option Request Option. In all 999 other cases, it is prudent to assume that any new option must be 1000 present on the relevant option request list if the client desires to 1001 receive it. 1003 It is tempting to add text that requires the client to include a new 1004 option in Option Request Option list, similar to this text: "Clients 1005 MUST place the foo option code on the Option Request Option list, 1006 clients MAY include option foo in their packets as hints for the 1007 server as values the desire, and servers MUST include option foo when 1008 the client requested it (and the server has been so configured)". 1009 Such text is discouraged as there are several issues with it. First, 1010 it assumes that client implementation that supports a given option 1011 will always want to use it. This is not true. The second and more 1012 important reason is that such text essentially duplicates mechanism 1013 already defined in [RFC3315]. It is better to simply refer to the 1014 existing mechanism rather than define it again. See Section 21 for 1015 proposed examples on how to do that. 1017 Creators of DHCPv6 options cannot not assume special ordering of 1018 options either as they appear in the option request option, or as 1019 they appear within the packet. Although it is reasonable to expect 1020 that options will be processed in the order they appear in ORO, 1021 server software is not required to sort DHCPv6 options into the same 1022 order in reply messages. 1024 It should also be noted that options values are never aligned within 1025 the DHCP packet, even the option code and option length may appear on 1026 odd byte boundaries. 1028 20. Transition Technologies 1030 Transition from IPv4 to IPv6 is progressing. Many transition 1031 technologies are proposed to speed it up. As a natural consequence 1032 there are also DHCP options proposed to provision those proposals. 1033 The inevitable question is whether the required parameters should be 1034 delivered over DHCPv4 or DHCPv6. Authors often don't give much 1035 thought about it and simply pick DHCPv6 without realizing the 1036 consequences. IPv6 is expected to stay with us for many decades, and 1037 so is DHCPv6. There is no mechanism available to deprecate an option 1038 in DHCPv6, so any options defined will stay with us as long as DHCPv6 1039 protocol itself. It seems likely that such options defined to 1040 transition from IPv4 will outlive IPv4 by many decades. From that 1041 perspective it is better to implement provisioning of the transition 1042 technologies in DHCPv4, which will be obsoleted together with IPv4. 1044 When the network infrastructure becomes IPv6-only, the support for 1045 IPv4-only nodes may still be needed. In such a scenario, a mechanism 1046 for providing IPv4 configuration information over IPv6-only networks 1047 such as [I-D.ietf-dhc-v4configuration] may be needed. 1049 21. Recommended sections in the new document 1051 There are three major entities in DHCPv6 protocol: server, relay 1052 agent, and client. It is very helpful for implementers to include 1053 separate sections that describe operation for those three major 1054 entities. Even when a given entity does not participate, it is 1055 useful to have a very short section stating that it must not send a 1056 given option and must ignore it when received. 1058 There is also a separate entity called requestor, which is a special 1059 client-like type that participates in leasequery protocol [RFC5007] 1060 and [RFC5460]. A similar section for the requestor is not required, 1061 unless the new option has anything to do with requestor (or it is 1062 likely that the reader may think that is has). It should be noted 1063 that while in the majority of deployments, requestor is co-located 1064 with relay agent, those are two separate entities from the protocol 1065 perspective and they may be used separately. There are stand-alone 1066 requestor implementations available. 1068 The following sections include proposed text for such sections. That 1069 text is not required to appear, but it is appropriate in most cases. 1070 Additional or modified text specific to a given option is often 1071 required. 1073 Although requestor is somewhat uncommon functionality, its existence 1074 should be noted, especially when allowing or disallowing options to 1075 appear in certain message or being sent by certain entities. 1076 Additional message types may appear in the future, besides types 1077 defined in [RFC3315]. Therefore authors are encouraged to 1078 familiarize themselves with a list of currently defined DHCPv6 1079 messages available on IANA website [iana]. 1081 Typically new options are requested by clients and assigned by the 1082 server, so there is no specific relay behavior. Nevertheless it is 1083 good to include a section for relay agent behavior and simply state 1084 that there are no additional requirements for relays. The same 1085 applies for client behavior if the options are to be exchanged 1086 between relay and server. 1088 Sections that contain option definitions MUST include formal 1089 verification procedure. Often it is very simple, e.g. option that 1090 conveys IPv6 address must be exactly 16 bytes long, but sometimes the 1091 rules are more complex. It is recommeded to refer to existing 1092 documents (e.g. section 8 of RFC3315 for domain name encoding) rather 1093 than trying to repeat such rules. 1095 21.1. DHCPv6 Client Behavior Text 1097 Clients MAY request option foo, as defined in [RFC3315], sections 1098 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to 1099 the reader, we mention here that the client includes requested option 1100 codes in Option Request Option. 1102 Optional text (if client's hints make sense): Client also MAY include 1103 option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION- 1104 REQUEST messages as a hint for the server regarding preferred option 1105 values. 1107 Optional text (if the option contains FQDN): If the client requests 1108 an option that conveys an FQDN, it is expected that the contents of 1109 that option will be resolved using DNS. Hence the following text may 1110 be useful: Clients that request option foo SHOULD also request option 1111 OPTION_DNS_SERVERS specified in [RFC3646]. 1113 Clients MUST discard option foo if it is invalid (i.e. did not pass 1114 validation steps defined in Section X.Y). 1116 Optional text (if option foo in expected to be exchanged between 1117 relays and servers): Option foo is exchanged between relays and 1118 servers only. Clients are not aware of the usage of option foo. 1120 Clients MUST ignore received option foo. 1122 21.2. DHCPv6 Server Behavior Text 1124 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 1125 regards to option assignment. As a convenience to the reader, we 1126 mention here that the server will send option foo only if configured 1127 with specific values for foo and the client requested it. 1129 Optional text: Option foo is a singleton. Servers MUST NOT send more 1130 than one instance of foo option. 1132 Optional text (if server is never supposed to receive option foo): 1133 Servers MUST ignore incoming foo option. 1135 21.3. DHCPv6 Relay Agent Behavior Text 1137 It's never appropriate for a relay agent to add options to a message 1138 heading toward the client, and relay agents don't actually construct 1139 Relay-Reply messages anyway. 1141 Optional text (if foo option is exchanged between clients and server 1142 or between requestors and servers): There are no additional 1143 requirements for relays. 1145 Optional text (if relays are expected to insert or consume option 1146 foo): Relay agents MAY include option foo in a Relay-Forw when 1147 forwarding packets from clients to the servers. 1149 22. Should the new document update existing RFCs? 1151 Authors often ask themselves a question whether their proposal 1152 updates exist RFCs, especially 3315. In April 2013 there were about 1153 80 options defined. Had all documents that defined them also updated 1154 RFC3315, comprehension of such a document set would be extremely 1155 difficult. It should be noted that "extends" and "updates" are two 1156 very different verbs. If a new draft defines a new option that 1157 clients request and servers provide, it merely extends current 1158 standards, so "updates 3315" is not required in the new document 1159 header. On the other hand, if a new document replaces or modifies 1160 existing behavior, it should be noted that it updates the other 1161 document. For example, [RFC6644] clearly updates [RFC3315] as it 1162 replaces existing with new text. 1164 23. Security Considerations 1166 DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes 1167 it possible for DHCPv6 software to discriminate between authentic 1168 endpoints and man-in-the-middle. Other authentication mechanisms may 1169 optionally be deployed. 1171 So, while creating a new option, it is prudent to assume that the 1172 DHCPv6 packet contents are always transmitted in the clear, and 1173 actual production use of the software will probably be vulnerable at 1174 least to man-in-the-middle attacks from within the network, even 1175 where the network itself is protected from external attacks by 1176 firewalls. In particular, some DHCPv6 message exchanges are 1177 transmitted to multicast addresses that are likely broadcast anyway. 1179 If an option is of a specific fixed length, it is useful to remind 1180 the implementer of the option data's full length. This is easily 1181 done by declaring the specific value of the 'length' tag of the 1182 option. This helps to gently remind implementers to validate option 1183 length before digesting them into likewise fixed length regions of 1184 memory or stack. 1186 If an option may be of variable size (such as having indeterminate 1187 length fields, such as domain names or text strings), it is advisable 1188 to explicitly remind the implementor to be aware of the potential for 1189 long options. Either define a reasonable upper limit (and suggest 1190 validating it), or explicitly remind the implementor that an option 1191 may be exceptionally long (to be prepared to handle errors rather 1192 than truncate values). 1194 For some option contents, out of bound values may be used to breach 1195 security. An IP address field might be made to carry a loopback 1196 address, or local multicast address, and depending on the protocol 1197 this may lead to undesirable results. A domain name field may be 1198 filled with contrived contents that exceed the limitations placed 1199 upon domain name formatting - as this value is possibly delivered to 1200 "internal configuration" records of the system, it may be implicitly 1201 trusted without being validated. 1203 Authors of drafts defining new DHCP options are therefore strongly 1204 advised to explicitly define validation measures that recipients of 1205 such options are required to do before processing such options. 1206 However, validation measures already defined by RFC3315 or other 1207 specifications referenced by the new option document are redundant, 1208 and can introduce errors, so authors are equally strongly advised to 1209 refer to the base specification for any such validation language 1210 rather than copying it into the new specification. 1212 24. IANA Considerations 1214 This document has no actions for IANA. 1216 25. Acknowledgements 1218 Authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, 1219 Bud Millwood and Ralph Droms for their comments. 1221 26. References 1223 26.1. Normative References 1225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1226 Requirement Levels", BCP 14, RFC 2119, March 1997. 1228 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1229 and M. Carney, "Dynamic Host Configuration Protocol for 1230 IPv6 (DHCPv6)", RFC 3315, July 2003. 1232 26.2. Informative References 1234 [I-D.ietf-dhc-v4configuration] 1235 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 1236 Over IPv6 Only Networks", 1237 draft-ietf-dhc-v4configuration-01 (work in progress), 1238 May 2013. 1240 [I-D.ietf-softwire-4rd] 1241 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 1242 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 1243 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 1244 progress), July 2013. 1246 [I-D.ietf-softwire-map-dhcp] 1247 Mrugalski, T., Deng, X., Troan, O., Bao, C., Dec, W., and 1248 l. leaf.yeh.sdo@gmail.com, "DHCPv6 Options for 1249 configuration of Softwire Address and Port Mapped 1250 Clients", draft-ietf-softwire-map-dhcp-04 (work in 1251 progress), July 2013. 1253 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 1254 RFC 3046, January 2001. 1256 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 1257 Protocol (DHCPv6) Options for Session Initiation Protocol 1258 (SIP) Servers", RFC 3319, July 2003. 1260 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1261 10646", STD 63, RFC 3629, November 2003. 1263 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1264 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1265 December 2003. 1267 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1268 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1269 December 2003. 1271 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 1272 Configuration Options for Dynamic Host Configuration 1273 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 1275 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1276 Resource Identifier (URI): Generic Syntax", STD 66, 1277 RFC 3986, January 2005. 1279 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 1280 Configuration Option for DHCPv6", RFC 4075, May 2005. 1282 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1283 Time Option for Dynamic Host Configuration Protocol for 1284 IPv6 (DHCPv6)", RFC 4242, November 2005. 1286 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 1287 Configuration Protocol (DHCP) Options for Broadcast and 1288 Multicast Control Servers", RFC 4280, November 2005. 1290 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1291 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1293 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 1294 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 1295 Option", RFC 4704, October 2006. 1297 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", 1298 RFC 4833, April 2007. 1300 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 1301 and A. Yegin, "Link-Layer Event Notifications for 1302 Detecting Network Attachments", RFC 4957, August 2007. 1304 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1305 "DHCPv6 Leasequery", RFC 5007, September 2007. 1307 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1308 Interchange", RFC 5198, March 2008. 1310 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 1311 February 2009. 1313 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 1314 Server Option for DHCPv6", RFC 5908, June 2010. 1316 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 1317 Options for Network Boot", RFC 5970, September 2010. 1319 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1320 Detecting Network Attachment in IPv6", RFC 6059, 1321 November 2010. 1323 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1324 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 1325 RFC 6334, August 2011. 1327 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 1328 RFC 6422, December 2011. 1330 [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication 1331 Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, 1332 December 2011. 1334 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1335 "Prefix Exclude Option for DHCPv6-based Prefix 1336 Delegation", RFC 6603, May 2012. 1338 [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. 1339 Lemon, "DHCP Options for Home Information Discovery in 1340 Mobile IPv6 (MIPv6)", RFC 6610, May 2012. 1342 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1343 DHCPv6 Reconfigure Messages", RFC 6644, July 2012. 1345 [iana] IANA, "DHCPv6 parameters (IANA webpage)", November 2003, 1346 . 1348 Authors' Addresses 1350 David W. Hankins 1351 Google, Inc. 1352 1600 Amphitheatre Parkway 1353 Mountain View, CA 94043 1354 USA 1356 Email: dhankins@google.com 1358 Tomek Mrugalski 1359 Internet Systems Consortium, Inc. 1360 950 Charter Street 1361 Redwood City, CA 94063 1362 USA 1364 Phone: +1 650 423 1345 1365 Email: tomasz.mrugalski@gmail.com 1367 Marcin Siodelski 1368 950 Charter Street 1369 Redwood City, CA 94063 1370 USA 1372 Phone: +1 650 423 1431 1373 Email: msiodelski@gmail.com 1375 Sheng Jiang 1376 Huawei Technologies Co., Ltd 1377 Q14, Huawei Campus, No.156 Beiqing Road 1378 Hai-Dian District, Beijing, 100095 1379 P.R. China 1381 Email: jiangsheng@huawei.com 1383 Suresh Krishnan 1384 Ericsson 1385 8400 Blvd Decarie 1386 Town of Mount Royal, Quebec 1387 Canada 1389 Email: suresh.krishnan@ericsson.com