idnits 2.17.1 draft-ietf-dhc-option-guidelines-17.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 (January 7, 2014) is 3724 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-03 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-07 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-06 -- 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 Group D. Hankins 3 Internet-Draft Google 4 Updates: 3315 (if approved) T. Mrugalski 5 Intended status: Best Current Practice M. Siodelski 6 Expires: July 11, 2014 ISC 7 S. Jiang 8 Huawei Technologies Co., Ltd 9 S. Krishnan 10 Ericsson 11 January 7, 2014 13 Guidelines for Creating New DHCPv6 Options 14 draft-ietf-dhc-option-guidelines-17 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. It also provides guidelines 21 for expert reviewers to evaluate new registrations. This document 22 updates RFC3315. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 11, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4 61 4. General Principles . . . . . . . . . . . . . . . . . . . . . 4 62 5. Reusing Other Options Formats . . . . . . . . . . . . . . . . 5 63 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 6 64 5.2. Option with a single flag (boolean) . . . . . . . . . . . 7 65 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7 66 5.4. Option with 32-bit integer value . . . . . . . . . . . . 8 67 5.5. Option with 16-bit integer value . . . . . . . . . . . . 9 68 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 9 69 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 9 70 5.8. Option with Text String . . . . . . . . . . . . . . . . . 11 71 5.9. Option with variable length data . . . . . . . . . . . . 12 72 5.10. Option with DNS Wire Format Domain Name List . . . . . . 12 73 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 13 74 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. Choosing between FQDN and address . . . . . . . . . . . . . . 14 76 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 17 77 10. Additional States Considered Harmful . . . . . . . . . . . . 18 78 11. Configuration changes occur at fixed times . . . . . . . . . 19 79 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 20 80 13. Chartering Requirements and Advice for Responsible Area 81 Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 14. Considerations for Creating New Formats . . . . . . . . . . . 21 83 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 22 85 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 23 86 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 24 87 19. Clients Request their Options . . . . . . . . . . . . . . . . 24 88 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 25 89 21. Recommended sections in the new document . . . . . . . . . . 25 90 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 26 91 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 27 92 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 27 93 22. Should the new document update existing RFCs? . . . . . . . . 27 94 23. Security Considerations . . . . . . . . . . . . . . . . . . . 28 95 24. Privacy considerations . . . . . . . . . . . . . . . . . . . 29 96 25. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 97 26. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 98 27. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 27.1. Normative References . . . . . . . . . . . . . . . . . . 30 100 27.2. Informative References . . . . . . . . . . . . . . . . . 30 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 103 1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Introduction 111 Most protocol developers ask themselves if a protocol will work, or 112 work efficiently. These are important questions, but another less 113 frequently considered question is whether the proposed protocol 114 presents itself needless barriers to adoption by deployed software. 116 DHCPv6 [RFC3315] software implementors are not merely faced with the 117 task of handling a given option's format on the wire. The option 118 must fit into every stage of the system's process, starting with the 119 user interface used to enter the configuration up to the machine 120 interfaces where configuration is ultimately consumed. 122 Another frequently overlooked aspect of rapid adoption is whether the 123 option requires operators to be intimately familiar with the option's 124 internal format in order to use it? Most DHCPv6 software provides a 125 facility for handling unknown options at the time of publication. 126 The handling of such options usually needs to be manually configured 127 by the operator. But if doing so requires extensive reading (more 128 than can be covered in a simple FAQ for example), it inhibits 129 adoption. 131 So although a given solution would work, and might even be space, 132 time, or aesthetically optimal, a given option is presented with a 133 series of ever-worsening challenges to be adopted: 135 o If it doesn't fit neatly into existing config files. 137 o If it requires source code changes to be adopted, and hence 138 upgrades of deployed software. 140 o If it does not share its deployment fate in a general manner with 141 other options, standing alone in requiring code changes or 142 reworking configuration file syntaxes. 144 o If the option would work well in the particular deployment 145 environment the proponents currently envision, but has equally 146 valid uses in some other environment where the proposed option 147 format would fail or would produce inconsistent results. 149 There are many things DHCPv6 option creators can do to avoid the 150 pitfalls in this list entirely, or failing that, to make software 151 implementors lives easier and improve its chances for widespread 152 adoption. 154 This document is envisaged as a help for protocol developers that 155 define new options and for expert reviewers that review submitted 156 proposals. 158 3. When to Use DHCPv6 160 Principally, DHCPv6 carries configuration parameters for its clients. 161 Any knob, dial, slider, or checkbox on the client system, such as "my 162 domain name servers", "my hostname", or even "my shutdown 163 temperature" are candidates for being configured by DHCPv6. 165 The presence of such a knob isn't enough, because DHCPv6 also 166 presents the extension of an administrative domain - the operator of 167 the network to which the client is currently attached. Someone runs 168 not only the local switching network infrastructure that the client 169 is directly (or wirelessly) attached to, but the various methods of 170 accessing the external Internet via local assist services that the 171 network must also provide (such as domain name servers, or routers). 172 This means that, even if a configuration parameter can potentially 173 delivered by DHCPv6, it is necessary to evaluate whether it is 174 reasonable for this parameter to be under the control of the 175 administrator of whatever network a client is attached to at any 176 given time. 178 Note that the client is not required to configure any of these values 179 received via DHCPv6 (e.g., due to having these values locally 180 configured by its own administrator). But it needs to be noted that 181 overriding DHCPv6-provided values may cause the client to be denied 182 certain services in the network to which it has attached. The 183 possibility of having higher level of control over client node 184 configuration is one of the reasons that DHCPv6 is preferred in 185 enterprise networks. 187 4. General Principles 189 The primary guiding principle to follow in order to enhance an 190 option's adoptability is reuse. The option should be created in such 191 a way that does not require any new or special case software to 192 support. If old software currently deployed and in the field can 193 adopt the option through supplied configuration facilities then it's 194 fairly certain that new software can easily formally adopt it. 196 There are at least two classes of DHCPv6 options: simple options 197 which are provided explicitly to carry data from one side of the 198 DHCPv6 exchange to the other (such as nameservers, domain names, or 199 time servers), and a protocol class of options which require special 200 processing on the part of the DHCPv6 software or are used during 201 special processing (such as the Fully Qualified Domain Name (FQDN) 202 option [RFC4704]), and so forth; these options carry data that is the 203 result of a routine in some DHCPv6 software. 205 The guidelines laid out here should be applied in a relaxed manner 206 for the protocol class of options. Wherever special case code is 207 already required to adopt the DHCPv6 option, it is substantially more 208 reasonable to format the option in a less generic fashion, if there 209 are measurable benefits to doing so. 211 5. Reusing Other Options Formats 213 The easiest approach to manufacturing trivially deployable DHCPv6 214 Options is to assemble the option out of whatever common fragments 215 fit - possibly allowing a group of data elements to repeat to fill 216 the remaining space (if present) and so provide multiple values. 217 Place all fixed size values at the start of the option, and any 218 variable/indeterminate sized value at the tail end of the option. 220 This means that implementations will likely be able to reuse code 221 paths designed to support the other options. 223 There is a tradeoff between the adoptability of previously defined 224 option formats, and the advantages that new or specialized formats 225 can provide. In general, it is usually preferable to reuse 226 previously used option formats. 228 However, it isn't very practical to consider the bulk of DHCPv6 229 options already allocated, and consider which of those solve a 230 similar problem. So, the following list of common option format data 231 elements is provided as a shorthand. Please note that it is not 232 complete in terms of exampling every option format ever devised. 234 If more complex options are needed, those basic formats mentioned 235 here may be considered as primitives (or 'fragment types') that can 236 be used to build more complex formats. It should be noted that it is 237 often easier to implement two options with trivial formats than one 238 option with more complex format. That is not unconditional 239 requirement though. In some cases splitting one complex option into 240 two or more simple options introduces inter-option dependencies that 241 should be avoided. In such a case, it is usually better to keep one 242 complex option. 244 5.1. Option with IPv6 addresses 246 This option format is used to carry one or many IPv6 addresses. In 247 some cases the number of allowed address is limited (e.g. to one): 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | option-code | option-len | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 | ipv6-address | 256 | | 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | | 260 | ipv6-address | 261 | | 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | ... | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 1: Option with IPv6 address 269 Examples of use: 271 o DHCPv6 server unicast address (a single address only) [RFC3315] 273 o SIP Servers IPv6 Address List [RFC3319] 275 o DNS Recursive Name Server [RFC3646] 277 o NIS Servers [RFC3898] 279 o SNTP Servers [RFC4075] 281 o Broadcast and Multicast Service Controller IPv6 Address Option for 282 DHCPv6 [RFC4280] 284 o MIPv6 Home Agent Address [RFC6610] (a single address only) 286 o NTP server [RFC5908] (a single address only) 287 o NTP Multicast address [RFC5908] (a single address only) 289 5.2. Option with a single flag (boolean) 291 Sometimes it is useful to convey a single flag that can take either 292 on or off values. Instead of specifying an option with one bit of 293 usable data and 7 bits of padding, it is better to define an option 294 without any content. It is the presence or absence of the option 295 that conveys the value. This approach has the additional benefit of 296 absent option designating the default, i.e. administrator has to take 297 explicit actions to deploy the opposite of the default value. 299 The absence of the option represents the default value and the 300 presence of the option represents the other value, but that does not 301 necessarily mean that absence is "off" (or "false") and presence is 302 "on" (or "true"). That is, if it's desired that the default value 303 for a bistable option is "true"/"on", then the presence of that 304 option would turn it off (make it false). If the option presence 305 signifies off/false state, that should be reflected in the option 306 name, e.g. OPTION_DISABLE_FOO. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | option-code | option-len | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Figure 2: Option for conveying boolean 316 Examples of use: 318 o DHCPv6 rapid-commit [RFC3315] 320 5.3. Option with IPv6 prefix 322 Sometimes there is a need to convey an IPv6 prefix. The information 323 to be carried by such an option includes the 128-bit IPv6 prefix 324 together with a length of this prefix taking values from 0 to 128. 325 Using the simplest approach, the option could convey this data in two 326 fixed length fields: one carrying prefix length, another carrying the 327 prefix. However, in many cases /64 or shorter prefixes are used. 328 This implies that the large part of the prefix data carried by the 329 option would have its bits set to zero and would be unused. In order 330 to avoid carrying unused data, it is recommended to store prefix in 331 the variable length data field. The appropriate option format is 332 defined as follows: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | option-code | option-length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | prefix6len | ipv6-prefix | 340 +-+-+-+-+-+-+-+-+ (variable length) | 341 . . 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 3: Option with IPv6 Prefix 346 option-length is set to 1 + length of the IPv6 prefix. 348 prefix6len is one octet long and specifies the length in bits of the 349 IPv6 prefix. Typically allowed values are 0 to 128. 351 ipv6-prefix field is a variable length field that specifies the IPv6 352 prefix. The length is (prefix6len + 7) / 8. This field is padded 353 with zero bits up to the nearest octet boundary when prefix6len is 354 not divisible by 8. 356 Examples of use: 358 o Default Mapping Rule [I-D.ietf-softwire-map-dhcp] 360 For example, the prefix 2001:db8::/60 would be encoded with an 361 option-length of 9, prefix6-len would be set to 60, the ipv6-prefix 362 would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00. 364 It should be noted that the IAPREFIX option defined by [RFC3633] uses 365 a full length 16-octet prefix field. The concern about option length 366 was not well understood at the time of its publication. 368 5.4. Option with 32-bit integer value 370 This option format can be used to carry 32 bit-signed or unsigned 371 integer value: 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 | 32-bit-integer | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Figure 4: Option with 32-bit-integer value 383 Examples of use: 385 o Information Refresh Time [RFC4242] 387 5.5. Option with 16-bit integer value 389 This option format can be used to carry 16-bit signed or unsigned 390 integer values: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | option-code | option-len | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | 16-bit-integer | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 5: Option with 16-bit integer value 402 Examples of use: 404 o Elapsed Time [RFC3315] 406 5.6. Option with 8-bit integer value 408 This option format can be used to carry 8-bit integer values: 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | option-code | option-len | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | 8-bit-integer | 416 +-+-+-+-+-+-+-+-+ 418 Figure 6: Option with 8-bit integer value 420 Examples of use: 422 o DHCPv6 Preference [RFC3315] 424 5.7. Option with URI 426 A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence 427 of characters that identifies an abstract or physical resource. The 428 term "Uniform Resource Locator" (URL) refers to the subset of URIs 429 that, in addition to identifying a resource, provide a means of 430 locating the resource by describing its primary access mechanism 431 (e.g., its network "location"). This option format can be used to 432 carry a single URI: 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | option-code | option-len | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 . URI (variable length) . 440 | ... | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 7: Option with URI 445 Examples of use: 447 o Boot File URL [RFC5970] 449 An alternate encoding to support multiple URIs is available. An 450 option must be defined to use either the single URI format above or 451 the multiple URI format below depending on whether a single is always 452 sufficient or if multiple URIs are possible. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | option-code | option-len | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 . . 460 . uri-data . 461 . . . . . 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 8: Option with multiple URIs 466 Each instance of the uri-data is formatted as follows: 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 469 | uri-len | URI | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 472 The uri-len is two octets long and specifies the length of the uri 473 data. Although URI format in theory supports up to 64k of data, in 474 practice large chunks of data may be problematic. See Section 15 for 475 details. 477 5.8. Option with Text String 479 A text string is a sequence of characters that have no semantics. 480 The encoding of the text string MUST be specified. Unless otherwise 481 specified, all text strings in newly defined options are expected to 482 be Unicode strings that are encoded using UTF-8 [RFC3629] in Net- 483 Unicode form [RFC5198]. Please note that all strings containing only 484 7 bit ASCII characters are also valid UTF-8 Net-Unicode strings. 486 If a data format has semantics other than just being text, it is not 487 a string. E.g., a FQDN is not a string, and a URI is also not a 488 string, because they have different semantics. A string must not 489 include any terminator (such as a null byte). The null byte is 490 treated as any other character and does not have any special meaning. 491 This option format can be used to carry a text string: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | option-code | option-len | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 . String . 499 | ... | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Figure 9: Option with text string 504 Examples of use: 506 o Timezone Options for DHCPv6 [RFC4833] 508 An alternate encoding to support multiple text strings is available. 509 An option must be defined to use either the single text string format 510 above or the multiple text string format below depending on whether a 511 single is always sufficient or if multiple text strings are possible. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | option-code | option-len | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 . . 519 . text-data . 520 . . . . . 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 10: Option with multiple text strings 525 Each instance of the text-data is formatted as follows: 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 528 | text-len | String | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 531 The text-len is two octets long and specifies the length of the 532 string. 534 5.9. Option with variable length data 536 This option can be used to carry variable length data of any kind. 537 Internal representation of carried data is option specific. Whenever 538 this format is used by the new option being defined, the data 539 encoding should be documented. 541 This option format provides a lot of flexibility to pass data of 542 almost any kind. Though, whenever possible it is highly recommended 543 to use more specialized options, with field types better matching 544 carried data types. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | option-code | option-len | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 . . 552 . variable length data . 553 . . 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 Figure 11: Option with variable length data 558 Examples of use: 560 o Client Identifier [RFC3315] 562 o Server Identifier [RFC3315] 564 5.10. Option with DNS Wire Format Domain Name List 566 This option is used to carry 'domain search' lists or any host or 567 domain name. It uses the same format as described in Section 5.9, 568 but with the special data encoding, described in section 8 of 569 [RFC3315]. This data encoding supports carrying multiple instances 570 of hosts or domain names in a single option, by terminating each 571 instance with the byte value of 0. 573 0 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | option-code | option-length | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | DNS Wire Format Domain Name List | 579 | ... | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 12: Option with DNS Wire Format Domain Name List 584 Examples of use: 586 o SIP Servers Domain Name List [RFC3319] (many domains) 588 o NIS Domain Name (many domains) [RFC3898] (many domains) 590 o LoST Server Domain name [RFC5223] 592 o LIS Domain name [RFC5986] 594 o DS-Lite AFTR location [RFC6334] (a single FQDN) 596 o Home Network Identifier [RFC6610] (a single FQDN) 598 o Home Agent FQDN [RFC6610] (a single FQDN) 600 6. Avoid Conditional Formatting 602 Placing an octet at the start of the option which informs the 603 software how to process the remaining octets of the option may appear 604 simple to the casual observer. But the only conditional formatting 605 methods that are in widespread use today are 'protocol' class 606 options. Therefore conditional formatting requires new code to be 607 written and complicates future interoperability should new 608 conditional formats be added; and existing code has to ignore 609 conditional format that it does not support. 611 7. Avoid Aliasing 613 Options are said to be aliases of each other if they provide input to 614 the same configuration parameter. A commonly proposed example is to 615 configure the location of some new service ("my foo server") using a 616 binary IP address, a domain name field, and an URL. This kind of 617 aliasing is undesirable, and is not recommended. 619 In this case, where three different formats are supposed, it more 620 than triples the work of the software involved, requiring support for 621 not merely one format, but support to produce and digest all three. 622 Furthermore, code development and testing must cover all possible 623 combinations of defined formats. Since clients cannot predict what 624 values the server will provide, they must request all formats. So in 625 the case where the server is configured with all formats, DHCPv6 626 message bandwidth is wasted on option contents that are redundant. 627 Also, the DHCPv6 option number space is wasted, as three new option 628 codes are required, rather than one. 630 It also becomes unclear which types of values are mandatory, and how 631 configuring some of the options may influence the others. For 632 example, if an operator configures the URL only, should the server 633 synthesize a domain name and IP address? 635 A single configuration value on a host is probably presented to the 636 operator (or other software on the machine) in a single field or 637 channel. If that channel has a natural format, then any alternative 638 formats merely make more work for intervening software in providing 639 conversions. 641 So the best advice is to choose the one method that best fulfills the 642 requirements, be that for simplicity (such as with an IP address and 643 port pair), late binding (such as with DNS), or completeness (such as 644 with a URL). 646 8. Choosing between FQDN and address 648 Some parameters may be specified as FQDN or an address. In most 649 cases one or the other should be used. This section discusses pros 650 and cons of each approach and is intended to help make an informed 651 decision in that regard. It is strongly discouraged to define both 652 option types at the same time (see Section 7), unless there is 653 sufficient motivation to do so. 655 There is no single recommendation that works for every case. It very 656 much depends on the nature of the parameter being configured. For 657 parameters that are network specific or represent certain aspects of 658 network infrastructure, like available mobility services, in most 659 cases addresses are a more usable choice. For parameters that can be 660 considered application specific configuration, like SIP servers, it 661 is usually better to use FQDN. 663 Applications are often better suited to deal with FQDN failures than 664 with address failures. Most operating systems provide a way to retry 665 FQDN resolution if the previous attempt fails. That type of error 666 recovery is supported by a great number of applications. On the 667 other hand, there is typically no API availble for applications to 668 reconfigure over DHCP to get a new address value if the one received 669 is no longer appropriate. This problem may be usually addressed by 670 providing a list of addresses, rather than just a single one. That, 671 on the other hand, requires defined procedure how multiple addresses 672 should be used (all at once, round robin, try first and fail over to 673 the next if it fails etc.). 675 FQDN provide a higher level of indirection and ambiguity. In many 676 cases that may be considered a benefit, but can be considered a flaw 677 in others. For example, one operator suggested to have the same name 678 being resolved to different addresses depending on the point of 679 attachement of the host doing resolution. This is one way to provide 680 localized addressing. However, in order to do this, it is necessary 681 to violate the DNS convention that a query on a particular name 682 should always return the same answer (aside from ordering of IP 683 addresses in the response, which is supposed to be varied by the name 684 server). This same locality of reference for configuration 685 information can be achieved directly using DHCP, since the DHCP 686 server must know the network topology in order to provide IP address 687 or prefix configuration. 689 The other type of ambiguity is related to multiple provisioning 690 domains (see Section 12). The stub resolver on the DHCP client 691 cannot at present be assumed to make the DNS query for a DHCP- 692 supplied FQDN on the same interface on which it received its DHCP 693 configuration, and may therefore get a different answer from the DNS 694 than was intended. 696 This is particularly a problem when the normal expected use of the 697 option makes sense with private DNS zone(s), as might be the case on 698 an enterprise network. It may also be the case that the client has 699 an explicit DNS server configured, and may therefore never query the 700 enterprise network's internal DNS server. 702 FQDN does require a resolution into an actual address. This implies 703 the question when the FQDN resolution should be conducted. There are 704 a couple of possible answers: a) by the server, when it is started, 705 b) by the server, when it is about to send an option, c) by the 706 client, immediately after receiving an option, d) by the client, when 707 the content of the option is actually consumed. For a), b) and 708 possibly c), the option should really convey an address, not FQDN. 709 The only real incentive to use FQDN is case d). It is the only case 710 that allows possible changes in the DNS to be picked up by clients. 712 If the parameter is expected to be used by constrained devices (low 713 power, battery operated, low capabilities) or in very lossy networks, 714 it may be appealing to drop the requirement of having DNS resolution 715 being performed and use addresses. Another example of a constrained 716 device is a network booted device, where despite the fact that the 717 node itself is very capable once it's booted, the boot prom is quite 718 constrained. 720 Another aspect that should be considered is time required for the 721 clients to notice any configuration changes. Consider a case where a 722 server configures a service A using address and service B using FQDN. 723 When an administrator decides to update the configuration, he or she 724 can update the DHCP server configuration to change both services. If 725 the clients do not support reconfigure (which is an optional feature 726 of RFC3315, but in some environments, e.g. cable modems, is 727 mandatory), the configuration will be updated on clients after T1 728 timer elapses. Depending on the nature of the change (is it a new 729 server added to a cluster of already operating servers or a new 730 server that replaces the only available server that crashed?), this 731 may be an issue. On the other hand, updating service B may be 732 achieved with DNS record update. That information may be cached by 733 caching DNS servers for up to TTL. Depending on the values of T1 and 734 TTL, one update may be faster than another. Furthermore, depending 735 on the nature of the change (planned modification or unexpected 736 failure), T1 or TTL may be lowered before the change to speed up new 737 configuration adoption. 739 Simply speaking protocol designers don't know what the TTL or the T1 740 time will be, so they can't make assumptions about whether a DHCP 741 option will be refreshed more quickly based on T1 or TTL. 743 Addresses have a benefit of being easier to implemented and handle by 744 the DHCP software. An address option is simpler to use, its 745 validation is trivial (multiple of 16 constitutes a valid option), is 746 explicit and does not allow any ambiguity. It is faster (does not 747 require extra round trip time), so it is more efficient, which can be 748 especially important for energy restricted devices. It also does not 749 require that the client implements DNS resolution. 751 FQDN imposes a number of additional failure modes and issues that 752 should be dealt with: 754 1. The client must have a knowledge about available DNS servers. 755 That typically means that option DNS_SERVERS [RFC3646] is 756 mandatory. This should be mentioned in the draft that defines 757 new option. It is possible that the server will return FQDN 758 option, but not the DNS Servers option. There should be a brief 759 discussion about it; 761 2. The DNS may not be reachable; 763 3. DNS may be available, but may not have appropriate information 764 (e.g. no AAAA records for specified FQDN); 766 4. Address family must be specified (A, AAAA or any); the 767 information being configured may require specific address family 768 (e.g. IPv6), but there may be a DNS record only of another type 769 (e.g. A only with IPv4 address). 771 5. What should the client do if there are multiple records available 772 (use only the first one, use all, use one and switch to the 773 second if the first fails for whatever reason, etc.); This may be 774 an issue if there is an expectation that the parameter being 775 configured will need exactly one address; 777 6. Multi-homed devices may be connected to different administrative 778 domains with each domain providing different information in DNS 779 (e.g. an enterprise network exposing private domains). Client 780 may send DNS queries to a different DNS server; 782 7. It should be mentioned if Internationalized Domain Names are 783 allowed. If they are, DNS option encoding should be specified. 785 Address options that are used with overly long T1 (renew timer) 786 values have some characteristics of hardcoded values. That is 787 strongly discouraged. See [RFC4085] for an in depth discussion. If 788 the option may appear in Information-Request, its lifetime should be 789 controlled using information refresh time option [RFC4242]. 791 One specific case that makes the choice between address and FQDN not 792 obvious is a DNSSEC bootstrap scenario. DNSSEC validation imposes a 793 requirement for clock sync (to the accuracy reasonably required to 794 consider signature inception and expiry times). This often implies 795 usage of NTP configuration. However, if the NTP is provided as FQDN, 796 there is no way to validate its DNSSEC signature. This is somewhat 797 weak argument though, as providing NTP server as an address is also 798 not verifiable using DNSSEC. If the thrustworthiness of the 799 configuration provided by DHCP server is in question, DHCPv6 offers 800 authentication mechanisms that allow server authentication. 802 9. Encapsulated options in DHCPv6 804 Most options are conveyed in a DHCPv6 message directly. Although 805 there is no codified normative language for such options, they are 806 often referred to as top-level options. Many options may include 807 other options. Such inner options are often referred to as 808 encapsulated or nested options. Those options are sometimes called 809 sub-options, but this term actually means something else, and 810 therefore should never be used to describe encapsulated options. It 811 is recommended to use term "encapsulated" as this terminology is used 812 in [RFC3315]. The difference between encapsulated and sub-options 813 are that the former uses normal DHCPv6 option numbers, while the 814 latter uses option number space specific to a given parent option. 815 It should be noted that, contrary to DHCPv4, there is no shortage of 816 option numbers. Therefore almost all options share a common option 817 space. For example option type 1 meant different things in DHCPv4, 818 depending if it was located in top-level or inside of Relay Agent 819 Information option. There is no such ambiguity in DHCPv6 (with the 820 exception of [RFC5908], which SHOULD NOT be used as a template for 821 future DHCP option definitions). 823 From the implementation perspective, it is easier to implement 824 encapsulated options rather than sub-options, as the implementers do 825 not have to deal with separate option spaces and can use the same 826 buffer parser in several places throughout the code. 828 Such encapsulation is not limited to one level. There is at least 829 one defined option that is encapsulated twice: Identity Association 830 for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) 831 conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such 832 delegated prefix may contain an excluded prefix range that is 833 represented by PD_EXCLUDE option that is conveyed as encapsulated 834 inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward 835 to refer to such options as sub-sub-option or doubly encapsulated 836 option, therefore "encapsulated option" term is typically used, 837 regardless of the nesting level. 839 When defining a DHCP-based configuration mechanism for a protocol 840 that requires something more complex than a single option, it may be 841 tempting to group configuration values using sub-options. That 842 should preferably be avoided, as it increases complexity of the 843 parser. It is much easier, faster and less error prone to parse a 844 large number of options on a single (top-level) scope, than parse 845 options on several scopes. The use of sub-options should be avoided 846 as much as possible, but it is better to use sub-options rather than 847 conditional formatting. 849 It should be noted that currently there is no clear way defined for 850 requesting sub-options. Most known implementations are simply using 851 top-level ORO for requesting both top-level options and encapsulated 852 options. 854 10. Additional States Considered Harmful 856 DHCP is a protocol designed for provisioning clients. Less 857 experienced protocol designers often assume that it is easy to define 858 an option that will convey a different parameter for each client in a 859 network. Such problems arose during designs of MAP 860 [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While 861 it would be easier for provisioned clients to get ready to use per- 862 client option values, such requirement puts exceedingly large loads 863 on the server side. The new extensions may introduce new 864 implementation complexity and additional database state on the 865 server. Alternatives should be considered, if possible. As an 866 example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all 867 clients are provisioned with the same set of MAP options and each 868 provisioned client uses its unique address and delegated prefix to 869 generate client-specific information. Such a solution does not 870 introduce any additional state for the server and therefore scales 871 better. 873 It also should be noted that contrary to DHCPv4, DHCPv6 keeps several 874 timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) 875 contains T1 and T2 timers that designate time after which client will 876 initiate renewal. Those timers apply only to its own IA containers. 877 Refreshing other parameters should be initiated after a time 878 specified in the Information Refresh Time Option (defined in 879 [RFC4242]), carried in the Reply message and returned in response to 880 Information-Request message. Introducing additional timers make 881 deployment unnecessarily complex and SHOULD be avoided. 883 11. Configuration changes occur at fixed times 885 In general, DHCPv6 clients only refresh configuration data from the 886 DHCP server when the T1 timer expires. Although there is a 887 RECONFIGURE mechanism that allows a DHCP server to request that 888 clients initiate reconfiguration, support for this mechanism is 889 optional and cannot be relied upon. 891 Even when DHCP clients refresh their configuration information, not 892 all consumers of DHCP-sourced configuration data notice these 893 changes. For instance, if a server is started using parameters 894 received in an early DHCP transaction, but does not check for updates 895 from DHCP, it may well continue to use the same parameter 896 indefinitely. There are a few operating systems that take care of 897 reconfiguring services when the client moves to a new network(e.g. 898 based on mechanisms like [RFC4436], [RFC4957] or [RFC6059]), but it's 899 worth bearing in mind that a renew may not always result in the 900 client taking up new configuration information that it receives. 902 In light of the above, when designing an option you should take into 903 consideration the fact that your option may hold stale data that will 904 only be updated at an arbitrary time in the future. 906 12. Multiple provisioning domains 908 In some cases there could be more than one DHCPv6 server on a link, 909 with each providing a different set of parameters. One notable 910 example of such a case is a home network with a connection to two 911 independent ISPs. 913 The DHCPv6 protocol specification does not provide clear advice on 914 how to handle multiple provisioning sources. Although [RFC3315] 915 states that a client that receives more than one ADVERTISE message, 916 may respond to one or more of them, such capability has not been 917 observed in existing implementations. Existing clients will pick one 918 server and will continue configuration process with that server, 919 ignoring all other servers. 921 In addition, a node that acts as a DHCPv6 client may be connected to 922 more than one physical network. In this case, it will in most cases 923 operate a separate DHCP client state machine on each interface, 924 acquiring different, possibly conflicting information through each. 925 This information will not be acquired in any synchronized way. 927 Existing nodes cannot be assumed to systematically segregate 928 configuration information on the basis of its source; as a result, it 929 is quite possible that a node may receive an FQDN on one network 930 interface, but do the DNS resolution on a different network 931 interface, using different DNS servers. As a consequence, DNS 932 resolution done by the DHCP server is more likely to behave 933 predictably than DNS resolution done on a multi-interface or multi- 934 homed client. 936 This is a generic DHCP protocol issue and should not be dealt within 937 each option separately. This issue is better dealt with using a 938 protocol-level solution and fixing this problem should not be 939 attempted on a per option basis. Work is ongoing in the IETF to 940 provide a systematic solution to this problem. 942 13. Chartering Requirements and Advice for Responsible Area Directors 944 Adding a simple DHCP option is straightforward, and generally 945 something that any working group can do, perhaps with some help from 946 designated DHCP experts. However, when new fragment types need to be 947 devised, this requires the attention of DHCP experts, and should not 948 be done in a working group that doesn't have a quorum of such 949 experts. This is true whether the new fragment type has the same 950 structure as an existing fragment type but has different semantics, 951 or the new format has a new structure. 953 Responsible Area Directors for working groups that wish to add a work 954 item to a working group charter to define a new DHCP option should 955 get clarity from the working group as to whether the new option will 956 require a new fragment type or new semantics, or whether it is a 957 simple DHCP option that fits existing definitions. 959 If a working group needs a new fragment type, it is preferable to see 960 if another working group exists whose members already have sufficient 961 expertise to evaluate the new work. If such a working group is 962 available, the work should be chartered in that working group 963 instead. If there is no other working group with DHCP expertise that 964 can define the new fragment type, the responsible AD should seek help 965 from known DHCP experts within the IETF to provide advice and 966 frequent early review as the original working group defines the new 967 fragment type. 969 In either case, the new option should be defined in a separate 970 document, and the work should focus on defining a new format that 971 generalizes well and can be reused, rather than a single-use fragment 972 type. The working group that needs the new fragment type can define 973 their new option referencing the new fragment type document, and the 974 work can generally be done in parallel, avoiding unnecessary delays. 975 Having the definition in its own document will foster reuse of the 976 new fragment type. 978 The responsible AD should work with all relevant working group chairs 979 and DHCP experts to ensure that the new fragment type document has in 980 fact been carefully reviewed by the experts and appears satisfactory. 982 Responsible area directors for working groups that are considering 983 defining options that actually update the DHCP protocol, as opposed 984 to simple options, should go through a process similar to that 985 described above when trying to determine where to do the work. Under 986 no circumstances should a working group be given a charter 987 deliverable to define a new DHCP option, and then on the basis of 988 that charter item actually make updates to the DHCP protocol. 990 14. Considerations for Creating New Formats 992 When defining new options, one specific consideration to evaluate is 993 whether or not options of a similar format would need to have 994 multiple or single values encoded (whatever differs from the current 995 option), and how that might be accomplished in a similar format. 997 When defining a new option, it is best to synthesize the option 998 format using fragment types already in use. However, in some cases 999 there may be no fragment type that accomplishes the intended purpose. 1001 The matter of size considerations and option order are further 1002 discussed in Section 15 and Section 17. 1004 15. Option Size 1006 DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through 1007 its use of link-local addresses, it avoids many of the deployment 1008 problems that plague DHCPv4, and is actually an UDP over IPv6 based 1009 protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol, 1010 but with layer 2 hacks). Second, RFC 3315 explicitly refers readers 1011 to RFC 2460 Section 5, which describes an MTU of 1280 octets and a 1012 minimum fragment reassembly of 1500 octets. It's feasible to suggest 1013 that DHCPv6 is capable of having larger options deployed over it, and 1014 at least no common upper limit is yet known to have been encoded by 1015 its implementors. It is not really possible to describe a fixed 1016 limit that cleanly divides workable option sizes from those that are 1017 too big. 1019 It is advantageous to prefer option formats which contain the desired 1020 information in the smallest form factor that satisfies the 1021 requirements. Common sense still applies here. It is better to 1022 split distinct values into separate octets rather than propose overly 1023 complex bit shifting operations to save several bits (or even an 1024 octet or two) that would be padded to the next octet boundary anyway. 1026 DHCPv6 does allow for multiple instances of a given option, and they 1027 are treated as distinct values following the defined format, however 1028 this feature is generally preferred to be restricted to protocol 1029 class features (such as the IA_* series of options). In such cases, 1030 it is better to define an option as an array if it is possible. It 1031 is recommended to clarify (with normative language) whether a given 1032 DHCPv6 option may appear once or multiple times. The default 1033 assumption is only once. 1035 In general, if a lot of data needs to be configured (for example, 1036 some option lengths are quite large), DHCPv6 may not be the best 1037 choice to deliver such configuration information and SHOULD simply be 1038 used to deliver a URI that specifies where to obtain the actual 1039 configuration information. 1041 16. Singleton options 1043 Although [RFC3315] states that each option type MAY appear more than 1044 once, the original idea was that multiple instances are reserved for 1045 stateful options, like IA_NA or IA_PD. For most other options it is 1046 usually expected that they will appear at most once. Such options 1047 are called singleton options. Sadly, RFCs have often failed to 1048 clearly specify whether a given option can appear more than once or 1049 not. 1051 Documents that define new options SHOULD state whether these options 1052 are singletons or not. Unless otherwise specified, newly defined 1053 options are considered to be singletons. If multiple instances are 1054 allowed, the document MUST explain how to use them. Care should be 1055 taken to not assume the they will be processed in the order they 1056 appear in the message. See Section 17 for more details. 1058 When deciding whether a single or multiple option instances are 1059 allowed in a message, take into consideration how the content of the 1060 option will be used. Depending on the service being configured it 1061 may or may not make sense to have multiple values configured. If 1062 multiple values make sense, it is better to explicitly allow that by 1063 using option format that allows multiple values within one option 1064 instance. 1066 Allowing multiple option instances often leads to confusion. 1067 Consider the following example. Basic DS-Lite architecture assumes 1068 that the B4 element (DHCPv6 client) will receive AFTR option and 1069 establish a single tunnel to configured tunnel termination point 1070 (AFTR). During standardization process of [RFC6334] there was a 1071 discussion whether multiple instances of DS-Lite tunnel option should 1072 be allowed. This created an unfounded expectation that the clients 1073 receiving multiple instances of the option will somehow know when one 1074 tunnel endpoint goes off-line and do some sort of failover between 1075 other values provided in other instances of the AFTR option. Others 1076 assumed that if there are multiple options, the client will somehow 1077 do a load balancing between provided tunnel endpoints. Neither 1078 failover nor load balancing was defined for DS-Lite architecture, so 1079 it caused confusion. It was eventually decided to allow only one 1080 instance of the AFTR option. 1082 17. Option Order 1084 Option order, either the order among many DHCPv6 options or the order 1085 of multiple instances of the same option, SHOULD NOT be significant. 1086 New documents MUST NOT assume any specific option processing order. 1088 As there is no explicit order for multiple instances of the same 1089 option, an option definition SHOULD instead restrict ordering by 1090 using a single option that contains ordered fields. 1092 As [RFC3315] does not impose option order, some implementations use 1093 hash tables to store received options (which is a conformant 1094 behavior). Depending on the hash implementation, the processing 1095 order is almost always different then the order in which options 1096 appeared in the packet on wire. 1098 18. Relay Options 1100 In DHCPv4, all relay options are organized as sub-options within DHCP 1101 Relay Agent Information Option[RFC3046]. And an independent number 1102 space called "DHCP Relay Agent Sub-options" is maintained by IANA. 1103 Different from DHCPv4, in DHCPv6, Relay options are defined in the 1104 same way as client/server options, and they too use the same option 1105 number space as client/server options. Future DHCPv6 Relay options 1106 MUST be allocated from this single DHCPv6 Option number space. 1108 E.g. the Relay-Supplied Options Option [RFC6422] may also contain 1109 some DHCPv6 options as permitted, such as the EAP Re-authentication 1110 Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440]. 1112 19. Clients Request their Options 1114 The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 1115 that serves two purposes - to inform the server what options the 1116 client supports and to inform what options the client is willing to 1117 consume. 1119 For some options, such as the options required for the functioning of 1120 the DHCPv6 protocol itself, it doesn't make sense to require that 1121 they be explicitly requested using the Option Request Option. In all 1122 other cases, it is prudent to assume that any new option must be 1123 present on the relevant option request list if the client desires to 1124 receive it. 1126 It is tempting to add text that requires the client to include a new 1127 option in Option Request Option list, similar to this text: "Clients 1128 MUST place the foo option code on the Option Request Option list, 1129 clients MAY include option foo in their packets as hints for the 1130 server as values the desire, and servers MUST include option foo when 1131 the client requested it (and the server has been so configured)". 1132 Such text is discouraged as there are several issues with it. First, 1133 it assumes that client implementation that supports a given option 1134 will always want to use it. This is not true. The second and more 1135 important reason is that such text essentially duplicates mechanism 1136 already defined in [RFC3315]. It is better to simply refer to the 1137 existing mechanism rather than define it again. See Section 21 for 1138 proposed examples on how to do that. 1140 Creators of DHCPv6 options cannot not assume special ordering of 1141 options either as they appear in the option request option, or as 1142 they appear within the packet. Although it is reasonable to expect 1143 that options will be processed in the order they appear in ORO, 1144 server software is not required to sort DHCPv6 options into the same 1145 order in reply messages. 1147 It should also be noted that options values are never aligned within 1148 the DHCP packet, even the option code and option length may appear on 1149 odd byte boundaries. 1151 20. Transition Technologies 1153 Transition from IPv4 to IPv6 is progressing. Many transition 1154 technologies are proposed to speed it up. As a natural consequence 1155 there are also DHCP options proposed to provision those proposals. 1156 The inevitable question is whether the required parameters should be 1157 delivered over DHCPv4 or DHCPv6. Authors often don't give much 1158 thought about it and simply pick DHCPv6 without realizing the 1159 consequences. IPv6 is expected to stay with us for many decades, and 1160 so is DHCPv6. There is no mechanism available to deprecate an option 1161 in DHCPv6, so any options defined will stay with us as long as DHCPv6 1162 protocol itself. It seems likely that such options defined to 1163 transition from IPv4 will outlive IPv4 by many decades. From that 1164 perspective it is better to implement provisioning of the transition 1165 technologies in DHCPv4, which will be obsoleted together with IPv4. 1167 When the network infrastructure becomes IPv6-only, the support for 1168 IPv4-only nodes may still be needed. In such a scenario, a mechanism 1169 for providing IPv4 configuration information over IPv6-only networks 1170 such as [I-D.ietf-dhc-v4configuration] may be needed. 1172 21. Recommended sections in the new document 1174 There are three major entities in DHCPv6 protocol: server, relay 1175 agent, and client. It is very helpful for implementers to include 1176 separate sections that describe operation for those three major 1177 entities. Even when a given entity does not participate, it is 1178 useful to have a very short section stating that it must not send a 1179 given option and must ignore it when received. 1181 There is also a separate entity called requestor, which is a special 1182 client-like type that participates in leasequery protocol [RFC5007] 1183 and [RFC5460]. A similar section for the requestor is not required, 1184 unless the new option has anything to do with requestor (or it is 1185 likely that the reader may think that is has). It should be noted 1186 that while in the majority of deployments, requestor is co-located 1187 with relay agent, those are two separate entities from the protocol 1188 perspective and they may be used separately. There are stand-alone 1189 requestor implementations available. 1191 The following sections include proposed text for such sections. That 1192 text is not required to appear, but it is appropriate in most cases. 1193 Additional or modified text specific to a given option is often 1194 required. 1196 Although requestor is somewhat uncommon functionality, its existence 1197 should be noted, especially when allowing or disallowing options to 1198 appear in certain message or being sent by certain entities. 1199 Additional message types may appear in the future, besides types 1200 defined in [RFC3315]. Therefore authors are encouraged to 1201 familiarize themselves with a list of currently defined DHCPv6 1202 messages available on IANA website [iana]. 1204 Typically new options are requested by clients and assigned by the 1205 server, so there is no specific relay behavior. Nevertheless it is 1206 good to include a section for relay agent behavior and simply state 1207 that there are no additional requirements for relays. The same 1208 applies for client behavior if the options are to be exchanged 1209 between relay and server. 1211 Sections that contain option definitions MUST include formal 1212 verification procedure. Often it is very simple, e.g. option that 1213 conveys IPv6 address must be exactly 16 bytes long, but sometimes the 1214 rules are more complex. It is recommeded to refer to existing 1215 documents (e.g. section 8 of RFC3315 for domain name encoding) rather 1216 than trying to repeat such rules. 1218 21.1. DHCPv6 Client Behavior Text 1220 Clients MAY request option foo, as defined in [RFC3315], sections 1221 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to 1222 the reader, we mention here that the client includes requested option 1223 codes in Option Request Option. 1225 Optional text (if client's hints make sense): Client also MAY include 1226 option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION- 1227 REQUEST messages as a hint for the server regarding preferred option 1228 values. 1230 Optional text (if the option contains FQDN): If the client requests 1231 an option that conveys an FQDN, it is expected that the contents of 1232 that option will be resolved using DNS. Hence the following text may 1233 be useful: Clients that request option foo SHOULD also request option 1234 OPTION_DNS_SERVERS specified in [RFC3646]. 1236 Clients MUST discard option foo if it is invalid (i.e. did not pass 1237 validation steps defined in Section X.Y). 1239 Optional text (if option foo in expected to be exchanged between 1240 relays and servers): Option foo is exchanged between relays and 1241 servers only. Clients are not aware of the usage of option foo. 1242 Clients MUST ignore received option foo. 1244 21.2. DHCPv6 Server Behavior Text 1246 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 1247 regards to option assignment. As a convenience to the reader, we 1248 mention here that the server will send option foo only if configured 1249 with specific values for foo and the client requested it. 1251 Optional text: Option foo is a singleton. Servers MUST NOT send more 1252 than one instance of foo option. 1254 Optional text (if server is never supposed to receive option foo): 1255 Servers MUST ignore incoming foo option. 1257 21.3. DHCPv6 Relay Agent Behavior Text 1259 It's never appropriate for a relay agent to add options to a message 1260 heading toward the client, and relay agents don't actually construct 1261 Relay-Reply messages anyway. 1263 Optional text (if foo option is exchanged between clients and server 1264 or between requestors and servers): There are no additional 1265 requirements for relays. 1267 Optional text (if relays are expected to insert or consume option 1268 foo): Relay agents MAY include option foo in a Relay-Forw when 1269 forwarding packets from clients to the servers. 1271 22. Should the new document update existing RFCs? 1273 Authors often ask themselves a question whether their proposal 1274 updates exist RFCs, especially 3315. In April 2013 there were about 1275 80 options defined. Had all documents that defined them also updated 1276 RFC3315, comprehension of such a document set would be extremely 1277 difficult. It should be noted that "extends" and "updates" are two 1278 very different verbs. If a new draft defines a new option that 1279 clients request and servers provide, it merely extends current 1280 standards, so "updates 3315" is not required in the new document 1281 header. On the other hand, if a new document replaces or modifies 1282 existing behavior, includes clarifications or other corrections, it 1283 should be noted that it updates the other document. For example, 1284 [RFC6644] clearly updates [RFC3315] as it replaces existing with new 1285 text. 1287 If in doubt, authors should try to answer a question whether 1288 implementor reading the base RFC alone (without reading the new 1289 draft) would be able to properly implement the software. If the base 1290 RFC is sufficient, that the new draft most probably does not update 1291 the base RFC. On the other hand, if reading your draft is necessary 1292 to properly implement the base RFC, then the new draft most likely 1293 updates the base RFC. 1295 23. Security Considerations 1297 DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes 1298 it possible for DHCPv6 software to discriminate between authentic 1299 endpoints and man-in-the-middle. Other authentication mechanisms may 1300 optionally be deployed. Sadly, as of late 2013, the authentication 1301 in DHCPv6 is rarely used and support for it is not common in existing 1302 implementations. Some specific deployment types make it mandatory 1303 (or parts of thereof, e.g. DOCSIS3.0 compatible cable modems require 1304 reconfigure-key support), so in certain cases specific authentication 1305 aspects can be relied upon. That is not true in the generic case, 1306 though. 1308 So, while creating a new option, it is prudent to assume that the 1309 DHCPv6 packet contents are always transmitted in the clear, and 1310 actual production use of the software will probably be vulnerable at 1311 least to man-in-the-middle attacks from within the network, even 1312 where the network itself is protected from external attacks by 1313 firewalls. In particular, some DHCPv6 message exchanges are 1314 transmitted to multicast addresses that are likely broadcast anyway. 1316 If an option is of a specific fixed length, it is useful to remind 1317 the implementer of the option data's full length. This is easily 1318 done by declaring the specific value of the 'length' tag of the 1319 option. This helps to gently remind implementers to validate option 1320 length before digesting them into likewise fixed length regions of 1321 memory or stack. 1323 If an option may be of variable size (such as having indeterminate 1324 length fields, such as domain names or text strings), it is advisable 1325 to explicitly remind the implementor to be aware of the potential for 1326 long options. Either define a reasonable upper limit (and suggest 1327 validating it), or explicitly remind the implementor that an option 1328 may be exceptionally long (to be prepared to handle errors rather 1329 than truncate values). 1331 For some option contents, out of bound values may be used to breach 1332 security. An IP address field might be made to carry a loopback 1333 address, or local multicast address, and depending on the protocol 1334 this may lead to undesirable results. A domain name field may be 1335 filled with contrived contents that exceed the limitations placed 1336 upon domain name formatting - as this value is possibly delivered to 1337 "internal configuration" records of the system, it may be implicitly 1338 trusted without being validated. 1340 Authors of drafts defining new DHCP options are therefore strongly 1341 advised to explicitly define validation measures that recipients of 1342 such options are required to do before processing such options. 1343 However, validation measures already defined by RFC3315 or other 1344 specifications referenced by the new option document are redundant, 1345 and can introduce errors, so authors are equally strongly advised to 1346 refer to the base specification for any such validation language 1347 rather than copying it into the new specification. 1349 Also see Section 24. 1351 24. Privacy considerations 1353 As discussed in Section 23 the DHCPv6 packets are typically 1354 transmitted in the clear, so they are susceptible to eavesdropping. 1355 This should be considered when defining options that may convey 1356 personally identifying information (PII) or any other type of 1357 sensitive data. 1359 If the transmission of sensitive or confidential content is required, 1360 it is still possible to secure communication between relay agents and 1361 servers. Relay agents and servers communicating with relay agents 1362 must support the use of IPsec Encapsulating Security Payload (ESP) 1363 with encryption in transport mode, according to Section 3.1.1 of 1364 [RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is 1365 almost universally ignored in real deployments. Even if the 1366 communication path between relay agents and server is secured, the 1367 path between clients and relay agents or server is not. 1369 Unless underlying transmission technology provides a secure 1370 transmission channel, the DHCPv6 options SHOULD NOT include PII or 1371 other sensitive information. If there are special circumstances that 1372 warrant sending such information over unsecured DHCPv6, the dangers 1373 MUST be clearly discussed in security considerations. 1375 25. IANA Considerations 1377 This document has no actions for IANA. 1379 26. Acknowledgements 1381 Authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, 1382 Bud Millwood, Ralph Droms, Barry Leiba, Benoit Claise, Brian 1383 Haberman, Richard Barnes, Stephen Farrell and Steward Bryant for 1384 their comments. 1386 27. References 1388 27.1. Normative References 1390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1391 Requirement Levels", BCP 14, RFC 2119, March 1997. 1393 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1394 and M. Carney, "Dynamic Host Configuration Protocol for 1395 IPv6 (DHCPv6)", RFC 3315, July 2003. 1397 27.2. Informative References 1399 [I-D.ietf-dhc-v4configuration] 1400 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 1401 Over IPv6 Only Networks", draft-ietf-dhc- 1402 v4configuration-03 (work in progress), December 2013. 1404 [I-D.ietf-softwire-4rd] 1405 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 1406 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 1407 Solution (4rd)", draft-ietf-softwire-4rd-07 (work in 1408 progress), October 2013. 1410 [I-D.ietf-softwire-map-dhcp] 1411 Mrugalski, T., Troan, O., Dec, W., Bao, C., 1412 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 1413 for configuration of Softwire Address and Port Mapped 1414 Clients", draft-ietf-softwire-map-dhcp-06 (work in 1415 progress), November 2013. 1417 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1418 3046, January 2001. 1420 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 1421 Protocol (DHCPv6) Options for Session Initiation Protocol 1422 (SIP) Servers", RFC 3319, July 2003. 1424 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1425 10646", STD 63, RFC 3629, November 2003. 1427 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1428 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1429 December 2003. 1431 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1432 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1433 December 2003. 1435 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 1436 Configuration Options for Dynamic Host Configuration 1437 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 1439 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1440 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1441 3986, January 2005. 1443 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 1444 Configuration Option for DHCPv6", RFC 4075, May 2005. 1446 [RFC4085] Plonka, D., "Embedding Globally-Routable Internet 1447 Addresses Considered Harmful", BCP 105, RFC 4085, June 1448 2005. 1450 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1451 Time Option for Dynamic Host Configuration Protocol for 1452 IPv6 (DHCPv6)", RFC 4242, November 2005. 1454 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 1455 Configuration Protocol (DHCP) Options for Broadcast and 1456 Multicast Control Servers", RFC 4280, November 2005. 1458 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1459 4303, December 2005. 1461 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1462 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1464 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 1465 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 1466 Option", RFC 4704, October 2006. 1468 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 1469 4833, April 2007. 1471 [RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., 1472 and A. Yegin, "Link-Layer Event Notifications for 1473 Detecting Network Attachments", RFC 4957, August 2007. 1475 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1476 "DHCPv6 Leasequery", RFC 5007, September 2007. 1478 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 1479 Interchange", RFC 5198, March 2008. 1481 [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering 1482 Location-to-Service Translation (LoST) Servers Using the 1483 Dynamic Host Configuration Protocol (DHCP)", RFC 5223, 1484 August 2008. 1486 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1487 2009. 1489 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 1490 Server Option for DHCPv6", RFC 5908, June 2010. 1492 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 1493 Options for Network Boot", RFC 5970, September 2010. 1495 [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 1496 Location Information Server (LIS)", RFC 5986, September 1497 2010. 1499 [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for 1500 Detecting Network Attachment in IPv6", RFC 6059, November 1501 2010. 1503 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1504 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 1505 RFC 6334, August 2011. 1507 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 1508 6422, December 2011. 1510 [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication 1511 Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, 1512 December 2011. 1514 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1515 "Prefix Exclude Option for DHCPv6-based Prefix 1516 Delegation", RFC 6603, May 2012. 1518 [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. 1519 Lemon, "DHCP Options for Home Information Discovery in 1520 Mobile IPv6 (MIPv6)", RFC 6610, May 2012. 1522 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1523 DHCPv6 Reconfigure Messages", RFC 6644, July 2012. 1525 [iana] IANA, , "DHCPv6 parameters (IANA webpage)", November 2003, 1526 . 1528 Authors' Addresses 1530 David W. Hankins 1531 Google, Inc. 1532 1600 Amphitheatre Parkway 1533 Mountain View, CA 94043 1534 USA 1536 Email: dhankins@google.com 1538 Tomek Mrugalski 1539 Internet Systems Consortium, Inc. 1540 950 Charter Street 1541 Redwood City, CA 94063 1542 USA 1544 Phone: +1 650 423 1345 1545 Email: tomasz.mrugalski@gmail.com 1547 Marcin Siodelski 1548 950 Charter Street 1549 Redwood City, CA 94063 1550 USA 1552 Phone: +1 650 423 1431 1553 Email: msiodelski@gmail.com 1555 Sheng Jiang 1556 Huawei Technologies Co., Ltd 1557 Q14, Huawei Campus, No.156 Beiqing Road 1558 Hai-Dian District, Beijing, 100095 1559 P.R. China 1561 Email: jiangsheng@huawei.com 1562 Suresh Krishnan 1563 Ericsson 1564 8400 Blvd Decarie 1565 Town of Mount Royal, Quebec 1566 Canada 1568 Email: suresh.krishnan@ericsson.com