idnits 2.17.1 draft-ietf-dhc-option-guidelines-12.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 (June 29, 2013) is 3953 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-05 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 -- 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: December 31, 2013 ISC 7 S. Jiang 8 Huawei Technologies Co., Ltd 9 S. Krishnan 10 Ericsson 11 June 29, 2013 13 Guidelines for Creating New DHCPv6 Options 14 draft-ietf-dhc-option-guidelines-12 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 December 31, 2013. 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 . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 4 60 4. General Principles . . . . . . . . . . . . . . . . . . . . . 4 61 5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 62 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . 5 63 5.2. Option with a single flag (boolean) . . . . . . . . . . . 6 64 5.3. Option with IPv6 prefix . . . . . . . . . . . . . . . . . 7 65 5.4. Option with 32-bit integer value . . . . . . . . . . . . 8 66 5.5. Option with 16-bit integer value . . . . . . . . . . . . 8 67 5.6. Option with 8-bit integer value . . . . . . . . . . . . . 8 68 5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 9 69 5.8. Option with Text String . . . . . . . . . . . . . . . . . 10 70 5.9. Option with variable length data . . . . . . . . . . . . 11 71 5.10. Option with DNS Wire Format Domain Name List . . . . . . 12 72 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 12 73 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. Choosing between FQDN and address . . . . . . . . . . . . . . 13 75 9. Encapsulated options in DHCPv6 . . . . . . . . . . . . . . . 15 76 10. Additional States Considered Harmful . . . . . . . . . . . . 16 77 11. Configuration changes occur at fixed times . . . . . . . . . 16 78 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 17 79 13. Chartering Requirements and Advice for Responsible ADs . . . 17 80 14. Considerations for Creating New Formats . . . . . . . . . . . 19 81 15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 16. Singleton options . . . . . . . . . . . . . . . . . . . . . . 20 83 17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 20 84 18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 21 85 19. Clients Request their Options . . . . . . . . . . . . . . . . 21 86 20. Transition Technologies . . . . . . . . . . . . . . . . . . . 22 87 21. Recommended sections in the new document . . . . . . . . . . 22 88 21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 23 89 21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 24 90 21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 24 91 22. Should the new document update existing RFCs? . . . . . . . . 24 92 23. Security Considerations . . . . . . . . . . . . . . . . . . . 25 93 24. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 94 25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 95 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 26.1. Normative References . . . . . . . . . . . . . . . . . . 26 97 26.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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 in addition to the existence of a configuration 166 parameter, one must also ask themselves if it is reasonable for this 167 parameter to be set by the directly attached network's 168 administrators. 170 Note that the client is not required to configure any of these values 171 received via DHCPv6 (for example, due to having a value manually 172 configured by its own operator). Bear in mind that doing so might 173 cause the client to be rejected network attachment privileges, and 174 this is one of the main reasons for the use of DHCPv6 in corporate 175 enterprises. 177 4. General Principles 179 The primary guiding principle to follow in order to enhance an 180 option's adoptability is reuse. The option should be created in such 181 a way that does not require any new or special case software to 182 support. If old software currently deployed and in the field can 183 adopt the option through supplied configuration facilities then it's 184 fairly certain that new software can easily formally adopt it. 186 There are at least two classes of DHCPv6 options: simple options 187 which are provided explicitly to carry data from one side of the 188 DHCPv6 exchange to the other (such as nameservers, domain names, or 189 time servers), and a protocol class of options which require special 190 processing on the part of the DHCPv6 software or are used during 191 special processing (such as the Fully Qualified Domain Name (FQDN) 192 option [RFC4704]), and so forth; these options carry data that is the 193 result of a routine in some DHCPv6 software. 195 The guidelines laid out here should be applied in a relaxed manner 196 for the protocol class of options. Wherever special case code is 197 already required to adopt the DHCPv6 option, it is substantially more 198 reasonable to format the option in a less generic fashion, if there 199 are measurable benefits to doing so. 201 5. Reusing Other Options 203 The easiest approach to manufacturing trivially deployable DHCPv6 204 Options is to assemble the option out of whatever common fragments 205 fit - possibly allowing a group of data elements to repeat to fill 206 the remaining space (if present) and so provide multiple values. 207 Place all fixed size values at the start of the option, and any 208 variable/indeterminate sized value at the tail end of the option. 210 This means that implementations will likely be able to reuse code 211 paths designed to support the other options. 213 There is a tradeoff between the adoptability of previously defined 214 option formats, and the advantages that new or specialized formats 215 can provide. In general, it is usually preferable to reuse 216 previously used option formats. 218 However, it isn't very practical to consider the bulk of DHCPv6 219 options already allocated, and consider which of those solve a 220 similar problem. So, the following list of common option format data 221 elements is provided as a shorthand. Please note that it is not 222 complete in terms of exampling every option format ever devised. 224 5.1. Option with IPv6 addresses 226 This option format is used to carry one or many IPv6 addresses. In 227 some cases the number of allowed address is limited (e.g. to one): 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | option-code | option-len | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 | ipv6-address | 236 | | 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 240 | ipv6-address | 241 | | 242 | | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | ... | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 1: Option with IPv6 address 249 Examples of use: 251 o DHCPv6 server unicast address (a single address only) [RFC3315] 253 o SIP Servers IPv6 Address List [RFC3319] 255 o DNS Recursive Name Server [RFC3646] 257 o NIS Servers [RFC3898] 259 o SNTP Servers [RFC4075] 261 o Broadcast and Multicast Service Controller IPv6 Address Option for 262 DHCPv6 [RFC4280] 264 o MIPv6 Home Agent Address [RFC6610] (a single address only) 266 o NTP server [RFC5908] (a single address only) 268 o NTP Multicast address [RFC5908] (a single address only) 270 5.2. Option with a single flag (boolean) 272 Sometimes it is useful to convey a single flag that can either take 273 on or off values. Instead of specifying an option with one bit of 274 usable data and 7 bits of padding, it is better to define an option 275 without any content. It is the presence or absence of the option 276 that conveys the value. This approach has the additional benefit of 277 absent option designating the default, i.e. administrator has to take 278 explicit actions to deploy the opposite of the default value. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | option-code | option-len | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 2: Option for conveying boolean 288 Examples of use: 290 o DHCPv6 rapid-commit [RFC3315] 292 5.3. Option with IPv6 prefix 294 Sometimes there is a need to convey an IPv6 prefix. The information 295 to be carried by such an option includes the 128-bit IPv6 prefix 296 together with a length of this prefix taking values from 0 to 128. 297 Using the simplest approach, the option could convey this data in two 298 fixed length fields: one carrying prefix length, another carrying the 299 prefix. However, in many cases /64 or shorter prefixes are used. 300 This implies that the large part of the prefix data carried by the 301 option would have its bits set to zero and would be unused. In order 302 to avoid carrying unused data, it is recommended to store prefix in 303 the variable length data field. The appropriate option format is 304 defined as follows: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | option-code | option-length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | prefix6-len | ipv6-prefix | 312 +-+-+-+-+-+-+-+-+ (variable length) | 313 . . 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 3: Option with IPv6 Prefix 318 option-length is set to 1 + length of the IPv6 prefix. 320 prefix6-len is one octet long and specifies the length in bits of the 321 IPv6 prefix. Typically allowed values are 0 to 128. 323 ipv6-prefix field is a variable length field that specifies the IPv6 324 prefix. The length is (prefix6-len + 7) / 8. This field is padded 325 with zero bits up to the nearest octet boundary when prefix6-len is 326 not divisible by 8. 328 Examples of use: 330 o Default Mapping Rule [I-D.ietf-softwire-map-dhcp] 332 For example, the prefix 2001:db8::/60 would be encoded with an 333 option-length of 9, prefix6-len would be set to 60, the ipv6-prefix 334 would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00. 336 It should be noted that the IAPREFIX option defined by [RFC3633] uses 337 a full length 16-octet prefix field. The concern about option length 338 was not well understood at the time of its publication. 340 5.4. Option with 32-bit integer value 342 This option format can be used to carry 32 bit-signed or unsigned 343 integer value: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | option-code | option-len | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | 32-bit-integer | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 4: Option with 32-bit-integer value 355 Examples of use: 357 o Information Refresh Time [RFC4242] 359 5.5. Option with 16-bit integer value 361 This option format can be used to carry 16-bit signed or unsigned 362 integer values: 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | option-code | option-len | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | 16-bit-integer | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 5: Option with 16-bit integer value 374 Examples of use: 376 o Elapsed Time [RFC3315] 378 5.6. Option with 8-bit integer value 380 This option format can be used to carry 8-bit integer values: 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | option-code | option-len | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | 8-bit-integer | 388 +-+-+-+-+-+-+-+-+ 390 Figure 6: Option with 8-bit integer value 392 Examples of use: 394 o DHCPv6 Preference [RFC3315] 396 5.7. Option with URI 398 A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence 399 of characters that identifies an abstract or physical resource. The 400 term "Uniform Resource Locator" (URL) refers to the subset of URIs 401 that, in addition to identifying a resource, provide a means of 402 locating the resource by describing its primary access mechanism 403 (e.g., its network "location"). This option format can be used to 404 carry a single URI: 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | option-code | option-len | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 . URI (variable length) . 412 | ... | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 7: Option with URI 417 Examples of use: 419 o Boot File URL [RFC5970] 421 An alternate encoding to support multiple URIs is available. An 422 option must be defined to use either the single URI format above or 423 the multiple URL format below depending on whether a single is always 424 sufficient or if multiple URLs are possible. 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | option-code | option-len | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 . . 432 . uri-data . 433 . . . . . 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 Figure 8: Option with multiple URIs 439 Each instance of the uri-data is formatted as follows: 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 442 | uri-len | URI | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 445 The uri-len is two octets long and specifies the length of the uri 446 data. 448 5.8. Option with Text String 450 A text string is a sequence of characters that have no semantics. 451 The encoding (such as 7-bit ASCII, NVT-ASCII, UTF-8) of the text 452 string MUST be specified. If a data format has semantics other than 453 just being text, it is not a string. E.g., a FQDN is not a string, 454 and a URI is also not a string, because they have different 455 semantics. A string must not enclude any terminator (such as a null 456 byte). This option format can be used to carry a text string: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | option-code | option-len | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 . String . 464 | ... | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 9: Option with text string 469 Examples of use: 471 o Timezone Options for DHCPv6 [RFC4833] 473 An alternate encoding to support multiple text strings is available. 474 An option must be defined to use either the single text string format 475 above or the multiple text string format below depending on whether a 476 single is always sufficient or if multiple text strings are possible. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | option-code | option-len | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 . . 484 . text-data . 485 . . . . . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 10: Option with multiple text strings 490 Each instance of the text-data is formatted as follows: 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 493 | text-len | String | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+ 496 The text-len is two octets long and specifies the length of the 497 string. 499 5.9. Option with variable length data 501 This option can be used to carry variable length data of any kind. 502 Internal representation of carried data is option specific. Whenever 503 this format is used by the new option being defined, the data 504 encoding should be documented. 506 This option format provides a lot of flexibility to pass data of 507 almost any kind. Though, whenever possible it is highly recommended 508 to use more specialized options, with field types better matching 509 carried data types. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | option-code | option-len | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 . . 517 . variable length data . 518 . . 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 Figure 11: Option with variable length data 523 Examples of use: 525 o Client Identifier [RFC3315] 527 o Server Identifier [RFC3315] 529 5.10. Option with DNS Wire Format Domain Name List 531 This option is used to carry 'domain search' lists or any host or 532 domain name. It uses the same format as described in Section 5.9, 533 but with the special data encoding, described in section 8 of 534 [RFC3315]. This data encoding supports carrying multiple instances 535 of hosts or domain names in a single option, by terminating each 536 instance with the byte value of 0. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | option-code | option-length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | DNS Wire Format Domain Name List | 544 | ... | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 12: Option with DNS Wire Format Domain Name List 549 Examples of use: 551 o SIP Servers Domain Name List [RFC3319] (many domains) 553 o NIS Domain Name (many domains) [RFC3898] (many domains) 555 o DS-Lite AFTR location [RFC6334] (a single FQDN) 557 o Home Network Identifier [RFC6610] (a single FQDN) 559 o Home Agent FQDN [RFC6610] (a single FQDN) 561 6. Avoid Conditional Formatting 563 Placing an octet at the start of the option which informs the 564 software how to process the remaining octets of the option may appear 565 simple to the casual observer. But the only conditional formatting 566 methods that are in widespread use today are 'protocol' class 567 options. Therefore conditional formatting requires new code to be 568 written and complicates future interoperability should new 569 conditional formats be added; and existing code has to ignore 570 conditional format that it does not support. 572 7. Avoid Aliasing 574 Options are said to be aliases of each other if they provide input to 575 the same configuration parameter. A commonly proposed example is to 576 configure the location of some new service ("my foo server") using a 577 binary IP address, a domain name field, and an URL. This kind of 578 aliasing is undesirable, and is not recommended. 580 In this case, where three different formats are supposed, it more 581 than triples the work of the software involved, requiring support for 582 not merely one format, but support to produce and digest all three. 583 Furthermore, code development and testing must cover all possible 584 combinations of defined formats. Since clients cannot predict what 585 values the server will provide, they must request all formats. So in 586 the case where the server is configured with all formats, DHCPv6 587 message bandwidth is wasted on option contents that are redundant. 588 Also, the DHCPv6 option space is wasted, as three new option codes 589 are required, rather than one. 591 It also becomes unclear which types of values are mandatory, and how 592 configuring some of the options may influence the others. For 593 example, if an operator configures the URL only, should the server 594 synthesize a domain name and IP address? 596 A single configuration value on a host is probably presented to the 597 operator (or other software on the machine) in a single field or 598 channel. If that channel has a natural format, then any alternative 599 formats merely make more work for intervening software in providing 600 conversions. 602 So the best advice is to choose the one method that best fulfills the 603 requirements, be that for simplicity (such as with an IP address and 604 port pair), late binding (such as with DNS), or completeness (such as 605 with a URL). 607 8. Choosing between FQDN and address 609 Some parameters may be specified as FQDN or an address. It is not 610 allowed to define both option types at the same time (see section 611 Section 7), so one of them must be chosen. This section is intended 612 to help make an informed decision in that regard. 614 On the specific subject of desiring to configure a value using a FQDN 615 instead of a binary IP address, note that most DHCPv6 server 616 implementations will happily accept a Domain Name entered by the 617 administrator, and use DNS resolution to render binary IP addresses 618 in DHCPv6 replies to clients. Consequently, consider the extra 619 packet overhead incurred on the client's end to perform DNS 620 resolution itself. The client may be operating on a battery and 621 packet transmission is a non-trivial use of power, and the extra RTT 622 delays the client must endure before the service is configured are at 623 least two factors to consider in making a decision on format. 625 Unless there are specific reasons to do otherwise, address should be 626 used. It is simpler to use, its validation is trivial (length of 16 627 constitutes a valid option), is explicit and does not allow any 628 ambiguity. It is faster (does not require extra resolution efforts), 629 so it is more efficient, which can be especially important for energy 630 restricted devices. 632 FQDN options are discouraged for options intended to configure hosts, 633 because hosts may have multiple provisioning domains (see 634 Section 12), and may get a different answer from the DNS depending on 635 the provisioning domain. This is particularly a problem when the 636 normal expected use of the option makes sense with private DNS 637 zone(s), as might be the case with a corporate VPN. 639 FQDN does require a resolution into an actual address. This implies 640 the question when the FQDN resolution should be taken. There are a 641 couple of possible answers: a) by the server, when it is started, b) 642 by the server, when it is about to send an option, c) by the client, 643 immediately after receiving an option, d) by the client, when the 644 content of the option is actually consumed. For a), b) and possibly 645 c), the option should really convey an address, not FQDN. The only 646 real incentive to use FQDN is case d). It is the only case that 647 allows possible changes in the DNS to be picked up by clients. 649 FQDN imposes a number of additional failure modes and issues that 650 should be dealt with: 652 1. The client must have a knowledge about available DNS servers. 653 That typically means that option DNS_SERVERS is mandatory. This 654 should be mentioned in the draft that defines new option. It is 655 possible that the server will return FQDN option, but not the DNS 656 Servers option. There should be a brief discussion about it; 658 2. The DNS may not be reachable; 660 3. DNS may be available, but may not have appropriate information 661 (e.g. no AAAA records for specified FQDN); 663 4. Address family must be specified (A, AAAA or any); 665 5. What should the client do if there are multiple records available 666 (use only the first one, use all, use one and switch to the 667 second if the first fails for whatever reason, etc.); 669 6. Multi-homed devices may be connected to different administrative 670 domains with each domain providing different information in DNS 671 (e.g. an enterprise network exposing private domains). Client 672 may send DNS queries to a different DNS server; 674 7. It should be mentioned if Internationalized Domain Names are 675 allowed. If they are, what kind of DNS option encoding should be 676 specified. 678 9. Encapsulated options in DHCPv6 680 Most options are conveyed in a DHCPv6 message directly. Although 681 there is no codified normative language for such options, they are 682 often referred to as top-level options. Many options may include 683 other options. Such inner options are often referred to as 684 encapsulated or nested options. Those options are sometimes called 685 sub-options, but this term actually means something else, and 686 therefore should never be used to describe encapsulated options. It 687 is recommended to use term "encapsulated" as this terminology is used 688 in [RFC3315]. The difference between encapsulated and sub-options 689 are that the former uses normal DHCPv6 option space codes, while the 690 latter uses option space specific to a given parent option. It 691 should be noted that, contrary to DHCPv4, there is no shortage of 692 option numbers. Therefore almost all options share a common option 693 space. For example option type 1 meant different things in DHCPv4, 694 depending if it was located in top-level or inside of Relay Agent 695 Information option. There is no such ambiguity in DHCPv6 (with the 696 unfortunate exception of [RFC5908], which never got proper review 697 from the DHC working group and contains many errors, and should not 698 under any circumstances be used as a template for future DHCP option 699 definitions). 701 From the implementation perspective, it is easier to implement 702 encapsulated options rather than sub-options, as the implementers do 703 not have to deal with separate option spaces and can use the same 704 buffer parser in several places throughout the code. 706 Such encapsulation is not limited to one level. There is at least 707 one defined option that is encapsulated twice: Identity Association 708 for Prefix Delegation (IA_PD, defined in [RFC3633], section 9) 709 conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 10). Such 710 delegated prefix may contain an excluded prefix range that is 711 represented by PD_EXCLUDE option that is conveyed as encapsulated 712 inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward 713 to refer to such options as sub-sub-option or doubly encapsulated 714 option, therefore "encapsulated option" term is typically used, 715 regardless of the nesting level. 717 When defining configuration means for more complex mechanisms, it may 718 be tempting to simply use sub-options. That should be avoided, as it 719 increases complexity of the parser. It is much easier, faster and 720 less error prone to parse a larger number of options on a single 721 (top-level) scope, than parse options on several scopes. The use of 722 sub-options should be avoided as much as possible, but it is better 723 to use sub-options rather than conditional formatting. 725 It should be noted that currently there is no clear way defined for 726 requesting sub-options. Most known implementations are simply using 727 top-level ORO for requesting both top-level options and encapsulated 728 options. 730 10. Additional States Considered Harmful 732 DHCP is a protocol designed for provisioning clients. Less 733 experienced protocol designers often assume that it is easy to define 734 an option that will convey a different parameter for each client in a 735 network. Such problems arose during designs of MAP 736 [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While 737 it would be easier for provisioned clients to get ready to use per 738 client option values, such requirement puts exceedingly large loads 739 on the server side. The new extensions may introduce new 740 implementation complexity and additional database state on the 741 server. Alternatives should be considered, if possible. As an 742 example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all 743 clients are provisioned with the same set of MAP options and each 744 provisioned client uses its unique address and delegated prefix to 745 generate client-specific information. Such a solution does not 746 introduce any additional state for the server and therefore scales 747 better. 749 It also should be noted that contrary to DHCPv4, DHCPv6 keeps several 750 timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) 751 contains T1 and T2 timers that designate time after which client will 752 initiate renewal. Those timers apply only to its own IA containers. 753 Refreshing other parameters should be initiated after a time 754 specified in the Information Refresh Time Option (defined in 755 [RFC4242]), carried in the Reply message and returned in response to 756 Information-Request message. Introducing additional timers make 757 deployment unnecessarily complex and SHOULD be avoided. 759 11. Configuration changes occur at fixed times 760 In general, DHCPv6 clients only refresh configuration data from the 761 DHCP server when the T1 timer expires. Although there is a 762 RECONFIGURE mechanism that allows a DHCP server to request that 763 clients initiate reconfiguration, support for this mechanism is 764 optional and cannot be relied upon. 766 Even when DHCP clients refresh their configuration information, not 767 all consumers of DHCP-sourced configuration data notice these 768 changes. For instance, if a server is started using parameters 769 received in an early DHCP transaction, but does not check for updates 770 from DHCP, it may well continue to use the same parameter 771 indefinitely. Modern notification systems take care of reconfiguring 772 services when the client moves to a new network, but it's worth 773 bearing in mind that a renew may not actually result in the client 774 taking up new configuration information that it receives. 776 In light of the above, when designing an option you should take into 777 consideration the fact that your option may hold stale data that will 778 only be updated at an arbitrary time in the future. 780 12. Multiple provisioning domains 782 In some cases there could be more than one DHCPv6 server on a link, 783 with each provisioning a different set of parameters. One notable 784 example of such a case is a home network with a connection to two 785 independent ISPs. 787 DHCPv6 was not initially designed with multiple provisioning domains. 788 Although [RFC3315] states that a client that receives more than one 789 ADVERTISE message, may respond to one or more of them, such 790 capability was never observed in any known implementations. Existing 791 clients will pick one server and will continue configuration process 792 with that server, ignoring all other servers. 794 This is a generic DHCP protocol issue and should not be dealt within 795 each option separately. This issue is better dealt with using a 796 protocol-level solution and fixing this problem should not be 797 attempted on a per option basis. 799 13. Chartering Requirements and Advice for Responsible ADs 800 Adding a simple DHCP option is straightforward, and generally 801 something that any working group can do, perhaps with some help from 802 designated DHCP experts. However, when new fragment types need to be 803 devised, this requires the attention of DHCP experts, and should not 804 be done in a working group that doesn't have a quorum of such 805 experts. This is true whether the new fragment type has the same 806 structure as an existing fragment type, but has different semantics. 807 It is equally true when the new format has a new structure. 809 Responsible Area Directors for working groups that wish to add a work 810 item to a working group charter to define a new DHCP option should 811 get clarity from the working group as to whether the new option is a 812 simple DHCP option with no new fragment type or new fragment 813 semantics, or whether it in fact will require new fragment types. A 814 working group charter item should explicitly state which of these two 815 types is required; if it is not known at the time of chartering, the 816 charter should state that the working group will study the question 817 and recharter or seek help elsewhere if a new fragment type is to be 818 defined. 820 If a working group needs a new fragment type, it is preferable to 821 seek out a working group whose members already have sufficient 822 expertise to evaluate the new work and try to come up with a new 823 format that generalizes well and can be reused, rather than a single- 824 use fragment type. If such a working group is available, the work 825 should be chartered in that working group as a separate draft that 826 documents the new fragment type. The working group that needs the 827 new fragment type can then define their new option referencing the 828 new fragment type document. This work can generally be done in 829 parallel so as not to delay the process significantly. 831 In the event that there is no working group with DHCP expertise that 832 can define the new fragment type, the responsible AD should seek out 833 help from known DHCP experts within the IETF to provide advice and 834 frequent early review as the working group defines the new fragment 835 type. The new fragment type should still be done in a separate 836 document, even if it's done in the same working group, so as to 837 foster reuse of the new fragment type. The responsible AD should 838 work with the working group chairs and designated DHCP experts to 839 ensure that new fragment type document has in fact been carefully 840 reviewed by the experts and appears satisfactory. 842 Responsible area directors for working groups that are considering 843 defining options that actually update the DHCP protocol, as opposed 844 to simple options, should go through a process similar to that 845 described above when trying to determine where to do the work. Under 846 no circumstances should a working group be given a charter 847 deliverable to define a new DHCP option, and then on the basis of 848 that charter item actually make updates to the DHCP protocol. 850 14. Considerations for Creating New Formats 852 When defining new options, one specific consideration to evaluate is 853 whether or not options of a similar format would need to have 854 multiple or single values encoded (whatever differs from the current 855 option), and how that might be accomplished in a similar format. 857 When defining a new option, it is best to synthesize the option 858 format using fragment types already in use. However, in some cases 859 there may be no fragment type that accomplishes the intended purpose. 861 The matter of size considerations and option order are further 862 discussed in Section 15 and Section 17. 864 15. Option Size 866 DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through 867 its use of link-local addresses, it avoids many of the deployment 868 problems that plague DHCPv4, and is actually an UDP over IPv6 based 869 protocol (compared to DHCPv4, which is mostly UDP over IPv4 protocol, 870 but with layer 2 hacks). Second, RFC 3315 explicitly refers readers 871 to RFC 2460 Section 5, which describes an MTU of 1280 octets and a 872 minimum fragment reassembly of 1500 octets. It's feasible to suggest 873 that DHCPv6 is capable of having larger options deployed over it, and 874 at least no common upper limit is yet known to have been encoded by 875 its implementors. It is impossible to describe any fixed limit that 876 cleanly divides those too big from the workable. 878 It is advantageous to prefer option formats which contain the desired 879 information in the smallest form factor that satisfies the 880 requirements. Common sense still applies here. It is better to 881 split distinct values into separate octets rather than propose overly 882 complex bit shifting operations to save several bits (or even an 883 octet or two) that would be padded to the next octet boundary anyway. 885 DHCPv6 does allow for multiple instances of a given option, and they 886 are treated as distinct values following the defined format, however 887 this feature is generally preferred to be restricted to protocol 888 class features (such as the IA_* series of options). In such cases, 889 it is better to define an option as an array if it is possible. It 890 is recommended to clarify (with normative language) whether a given 891 DHCPv6 option may appear once or multiple times. The default 892 assumption is only once. 894 Relay agents have to do fragment reassembly and fragmentation on 895 transmission. So while fragmentation is allowed, if a new option 896 results in significant fragmentation, it probably isn't a good choice 897 for DHCP configuration; instead DHCP should simply point to a URI 898 where the configuration information can be obtained. 900 16. Singleton options 902 Although [RFC3315] states that each option type MAY appear more than 903 once, the original idea was that multiple instances are reserved for 904 stateful options, like IA_NA or IA_PD. For most other options it is 905 usually expected that they will appear at most once. Such options 906 are called singleton options. Sadly, it is often not clearly 907 specified in RFCs that were published up to this date whether only 908 one or more option instances are allowed. Documents that define new 909 defined options SHOULD state whether new options are singletons or 910 not. Unless otherwise specified, new defined options are singletons. 912 When deciding whether a single or multiple option instances are 913 allowed in a message, take into consideration how the content of the 914 option will be used. Depending on the service being configured it 915 may or may not make sense to have multiple values configured. If 916 multiple values make sense, it is better to explicitly allow that by 917 using option format that allows multiple values within one option 918 instance. 920 Allowing multiple option instances often leads to confusion. 921 Consider the following example. Basic DS-Lite architecture assumes 922 that the B4 element (DHCPv6 client) will receive AFTR option and 923 establish a single tunnel to configured tunnel termination point 924 (AFTR). During standardization process of [RFC6334] there was a 925 discussion whether multiple instances of DS-Lite tunnel option should 926 be allowed. This created an unfounded expectation that the clients 927 receiving multiple instances of the option will somehow know when one 928 tunnel endpoint goes off-line and do some sort of failover between 929 other values provided in other instances of the AFTR option. Others 930 assumed that if there are multiple options, the client will somehow 931 do a load balancing between provided tunnel endpoints. Neither 932 failover nor load balancing was defined for DS-Lite architecture, so 933 it caused confusion. It was eventually decided to allow only one 934 instance of the AFTR option. 936 17. Option Order 937 Option order, either the order among many DHCPv6 options or the order 938 of multiple instances of the same option, SHOULD NOT be significant 939 and MUST NOT be assumed. An exception may be security relevant 940 options, which are often created last and put at the last position, 941 or whose location indicates the protected range. 943 As there is no explicit order for multiple instance of the same 944 option, an option definition SHOULD instead restrict the order within 945 the option by using a list of items rather than a single item. 947 18. Relay Options 949 In DHCPv4, all relay options are organized as sub-options within DHCP 950 Relay Agent Information Option[RFC3046]. And an independent number 951 space called "DHCP Relay Agent Sub-options" is maintained by IANA. 952 Different from DHCPv4, in DHCPv6, Relay options are defined in the 953 same way as client/server options, and they too use the same number 954 space as client/server options. Future DHCPv6 Relay options MUST be 955 allocated from this single DHCPv6 Option code space. 957 However, the Relay-Supplied Options Option [RFC6422] may also contain 958 some DHCPv6 options as permitted, such as the EAP Re-authentication 959 Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440]. 961 19. Clients Request their Options 963 The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 964 that serves two purposes - to inform the server what options the 965 client supports and to inform what options the client is willing to 966 consume. 968 It doesn't make sense for some options to be requested using Option 969 Request Option, such as those formed by elements of the protocol's 970 internal workings, or are formed on either end by DHCPv6-level 971 software engaged in some exchange of information. When in doubt, it 972 is prudent to assume that any new option must be present on the 973 relevant option request list if the client desires to receive it. 975 It is tempting to add text that requires the client to include a new 976 option in Option Request Option list, similar to this text: "Clients 977 MUST place the foo option code on the Option Request Option list, 978 clients MAY include option foo in their packets as hints for the 979 server as values the desire, and servers MUST include option foo when 980 the client requested it (and the server has been so configured)". 981 Such text is discouraged as there are several issues with it. First, 982 it assumes that client implementation that supports a given option 983 will always want to use it. This is not true. The second and more 984 important reason is that such text essentially duplicates mechanism 985 already defined in [RFC3315]. It is better to simply refer to the 986 existing mechanism rather than define it again. See Section 21 for 987 proposed examples on how to do that. 989 Creators of DHCPv6 options should not require special ordering of 990 options either in the relevant request option, or in the order of 991 options within the packet. Although it is reasonable to expect that 992 options will be processed in the order they appear in ORO, server 993 software is not required to sort DHCPv6 options into the same order 994 in reply messages. 996 It should also be noted that options values are never aligned within 997 the DHCP packet, even the option code and option length may appear on 998 odd byte boundaries. 1000 20. Transition Technologies 1002 Transition from IPv4 to IPv6 is progressing. Many transition 1003 technologies are proposed to speed it up. As a natural consequence 1004 there are also DHCP options proposed to provision those proposals. 1005 The inevitable question is whether the required parameters should be 1006 delivered over DHCPv4 or DHCPv6. Authors often don't give much 1007 thought about it and simply pick DHCPv6 without realizing the 1008 consequences. IPv6 is expected to stay with us for many decades, and 1009 so is DHCPv6. There is no mechanism available to deprecate an option 1010 in DHCPv6, so any options defined will stay with us as long as DHCPv6 1011 protocol itself. It seems likely that such options defined to 1012 transition from IPv4 will outlive IPv4 by many decades. From that 1013 perspective it is better to implement provisioning of the transition 1014 technologies in DHCPv4, which will be obsoleted together with IPv4. 1016 When the network infrastructure becomes IPv6-only, the support for 1017 IPv4-only nodes may still be needed. In this scenario, provisioning 1018 IPv4 configuration over IPv6-only networks 1019 [I-D.ietf-dhc-v4configuration] may be needed. 1021 21. Recommended sections in the new document 1023 There are three major entities in DHCPv6 protocol: server, relay 1024 agent, and client. It is very helpful for implementers to include 1025 separate sections that describe operation for those three major 1026 entities. Even when a given entity does not participate, it is 1027 useful to have a very short section stating that it must not send a 1028 given option and must ignore it when received. 1030 There is also a separate entity called requestor, which is a special 1031 client-like type that participates in leasequery protocol [RFC5007] 1032 and [RFC5460]. A similar section for the requestor is not required, 1033 unless the new option has anything to do with requestor (or it is 1034 likely that the reader may think that is has). It should be noted 1035 that while in the majority of deployments, requestor is co-located 1036 with relay agent, those are two separate entities from the protocol 1037 perspective and they may be used separately. There are stand-alone 1038 requestor implementations available. 1040 The following sections include proposed text for such sections. That 1041 text is not required to appear, but it is appropriate in most cases. 1042 Additional or modified text specific to a given option is often 1043 required. 1045 Although requestor is somewhat uncommon functionality, its existence 1046 should be noted, especially when allowing or disallowing options to 1047 appear in certain message or being sent by certain entities. 1048 Additional message types may appear in the future, besides types 1049 defined in [RFC3315]. Therefore authors are encouraged to 1050 familiarize themselves with a list of currently defined DHCPv6 1051 messages available on IANA website [iana]. 1053 Typically new options are requested by clients and assigned by the 1054 server, so there is no specific relay behavior. Nevertheless it is 1055 good to include a section for relay agent behavior and simply state 1056 that there are no additional requirements for relays. The same 1057 applies for client behavior if the options are to be exchanged 1058 between relay and server. 1060 Sections that contain option definitions MUST include formal 1061 verification procedure. Often it is very simple, e.g. option that 1062 conveys IPv6 address must be exactly 16 bytes long, but sometimes the 1063 rules are more complex. It is recommeded to refer to existing 1064 documents (e.g. section 8 of RFC3315 for domain name encoding) rather 1065 than trying to repeat such rules. 1067 21.1. DHCPv6 Client Behavior Text 1069 Clients MAY request option foo, as defined in [RFC3315], sections 1070 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5 and 22.7. As a convenience to 1071 the reader, we mention here that the client includes requested option 1072 codes in Option Request Option. 1074 Optional text (if client's hints make sense): Client also MAY include 1075 option foo in its SOLICIT, REQUEST, RENEW, REBIND and INFORMATION- 1076 REQUEST messages as a hint for the server regarding preferred option 1077 values. 1079 Optional text (if the option contains FQDN): If the client requests 1080 an option that conveys an FQDN, it is expected that the contents of 1081 that option will be resolved using DNS. Hence the following text may 1082 be useful: Clients that request option foo SHOULD also request option 1083 OPTION_DNS_SERVERS specified in [RFC3646]. 1085 Clients MUST discard option foo if it is invalid (i.e. did not pass 1086 validation steps defined in Section X.Y). 1088 Optional text (if option foo in expected to be exchanged between 1089 relays and servers): Option foo is exchanged between relays and 1090 servers only. Clients are not aware of the usage of option foo. 1091 Clients MUST ignore received option foo. 1093 21.2. DHCPv6 Server Behavior Text 1095 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 1096 regards to option assignment. As a convenience to the reader, we 1097 mention here that the server will send option foo only if configured 1098 with specific values for foo and the client requested it. 1100 Optional text: Option foo is a singleton. Servers MUST NOT send more 1101 than one instance of foo option. 1103 Optional text (if server is never supposed to receive option foo): 1104 Servers MUST ignore incoming foo option. 1106 21.3. DHCPv6 Relay Agent Behavior Text 1108 It's never appropriate for a relay agent to add options to a message 1109 heading toward the client, and relay agents don't actually construct 1110 Relay-Reply messages anyway. 1112 Optional text (if foo option is exchanged between clients and server 1113 or between requestors and servers): There are no additional 1114 requirements for relays. 1116 Optional text (if relays are expected to insert or consume option 1117 foo): Relay agents MAY include option foo in a Relay-Forw when 1118 forwarding packets from clients to the servers. 1120 22. Should the new document update existing RFCs? 1122 Authors often ask themselves a question whether their proposal 1123 updates exist RFCs, especially 3315. In April 2013 there were about 1124 80 options defined. Had all documents that defined them also updated 1125 RFC3315, comprehension of such a document set would be extremely 1126 difficult. It should be noted that "extends" and "updates" are two 1127 very different verbs. If a new draft defines a new option that 1128 clients request and servers provide, it merely extends current 1129 standards, so "updates 3315" is not required in the new document 1130 header. On the other hand, if a new document replaces or modifies 1131 existing behavior, it should be noted that it updates the other 1132 document. For example, [RFC6644] clearly updates [RFC3315] as it 1133 replaces existing with new text. 1135 23. Security Considerations 1137 DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes 1138 it possible for DHCPv6 software to discriminate between authentic 1139 endpoints and man-in-the-middle. Other authentication mechanisms may 1140 optionally be deployed. 1142 So, while creating a new option, it is prudent to assume that the 1143 DHCPv6 packet contents are always transmitted in the clear, and 1144 actual production use of the software will probably be vulnerable at 1145 least to man-in-the-middle attacks from within the network, even 1146 where the network itself is protected from external attacks by 1147 firewalls. In particular, some DHCPv6 message exchanges are 1148 transmitted to multicast addresses that are likely broadcast anyway. 1150 If an option is of a specific fixed length, it is useful to remind 1151 the implementer of the option data's full length. This is easily 1152 done by declaring the specific value of the 'length' tag of the 1153 option. This helps to gently remind implementers to validate option 1154 length before digesting them into likewise fixed length regions of 1155 memory or stack. 1157 If an option may be of variable size (such as having indeterminate 1158 length fields, such as domain names or text strings), it is advisable 1159 to explicitly remind the implementor to be aware of the potential for 1160 long options. Either define a reasonable upper limit (and suggest 1161 validating it), or explicitly remind the implementor that an option 1162 may be exceptionally long (to be prepared to handle errors rather 1163 than truncate values). 1165 For some option contents, out of bound values may be used to breach 1166 security. An IP address field might be made to carry a loopback 1167 address, or local multicast address, and depending on the protocol 1168 this may lead to undesirable results. A domain name field may be 1169 filled with contrived contents that exceed the limitations placed 1170 upon domain name formatting - as this value is possibly delivered to 1171 "internal configuration" records of the system, it may be implicitly 1172 trusted without being validated. 1174 Authors of drafts defining new DHCP options are therefore strongly 1175 advised to explicitly define validation measures that recipients of 1176 such options are required to do before processing such options. 1178 However, validation measures already defined by RFC3315 or other 1179 specifications referenced by the new option document are redundant, 1180 and can introduce errors, so authors are equally strongly advised to 1181 refer to the base specification for any such validation language 1182 rather than copying it into the new specification. 1184 24. IANA Considerations 1186 This document has no actions for IANA. 1188 25. Acknowledgements 1190 Authors would like to thank Simon Perreault, Bernie Volz and Ted 1191 Lemon for their comments. 1193 26. References 1195 26.1. Normative References 1197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1198 Requirement Levels", BCP 14, RFC 2119, March 1997. 1200 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1201 and M. Carney, "Dynamic Host Configuration Protocol for 1202 IPv6 (DHCPv6)", RFC 3315, July 2003. 1204 26.2. Informative References 1206 [I-D.ietf-dhc-v4configuration] 1207 Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration 1208 Over IPv6 Only Networks", draft-ietf-dhc- 1209 v4configuration-01 (work in progress), May 2013. 1211 [I-D.ietf-softwire-4rd] 1212 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 1213 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 1214 Solution (4rd)", draft-ietf-softwire-4rd-05 (work in 1215 progress), April 2013. 1217 [I-D.ietf-softwire-map-dhcp] 1218 Mrugalski, T., Troan, O., Dec, W., Bao, C., 1219 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 1220 for Mapping of Address and Port", draft-ietf-softwire-map- 1221 dhcp-03 (work in progress), February 2013. 1223 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 1224 3046, January 2001. 1226 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 1227 Protocol (DHCPv6) Options for Session Initiation Protocol 1228 (SIP) Servers", RFC 3319, July 2003. 1230 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1231 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1232 December 2003. 1234 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 1235 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 1236 December 2003. 1238 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 1239 Configuration Options for Dynamic Host Configuration 1240 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 1242 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1243 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1244 3986, January 2005. 1246 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 1247 Configuration Option for DHCPv6", RFC 4075, May 2005. 1249 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 1250 Time Option for Dynamic Host Configuration Protocol for 1251 IPv6 (DHCPv6)", RFC 4242, November 2005. 1253 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 1254 Configuration Protocol (DHCP) Options for Broadcast and 1255 Multicast Control Servers", RFC 4280, November 2005. 1257 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 1258 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 1259 Option", RFC 4704, October 2006. 1261 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 1262 4833, April 2007. 1264 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 1265 "DHCPv6 Leasequery", RFC 5007, September 2007. 1267 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 1268 2009. 1270 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 1271 Server Option for DHCPv6", RFC 5908, June 2010. 1273 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 1274 Options for Network Boot", RFC 5970, September 2010. 1276 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 1277 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 1278 RFC 6334, August 2011. 1280 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 1281 6422, December 2011. 1283 [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication 1284 Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, 1285 December 2011. 1287 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 1288 "Prefix Exclude Option for DHCPv6-based Prefix 1289 Delegation", RFC 6603, May 2012. 1291 [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. 1292 Lemon, "DHCP Options for Home Information Discovery in 1293 Mobile IPv6 (MIPv6)", RFC 6610, May 2012. 1295 [RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in 1296 DHCPv6 Reconfigure Messages", RFC 6644, July 2012. 1298 [iana] IANA, ., "DHCPv6 parameters (IANA webpage)", November 1299 2003, 1300 . 1302 Authors' Addresses 1304 David W. Hankins 1305 Google, Inc. 1306 1600 Amphitheatre Parkway 1307 Mountain View, CA 94043 1308 USA 1310 Email: dhankins@google.com 1312 Tomek Mrugalski 1313 Internet Systems Consortium, Inc. 1314 950 Charter Street 1315 Redwood City, CA 94063 1316 USA 1318 Phone: +1 650 423 1345 1319 Email: tomasz.mrugalski@gmail.com 1320 Marcin Siodelski 1321 950 Charter Street 1322 Redwood City, CA 94063 1323 USA 1325 Phone: +1 650 423 1431 1326 Email: msiodelski@gmail.com 1328 Sheng Jiang 1329 Huawei Technologies Co., Ltd 1330 Q14, Huawei Campus, No.156 Beiqing Road 1331 Hai-Dian District, Beijing, 100095 1332 P.R. China 1334 Email: jiangsheng@huawei.com 1336 Suresh Krishnan 1337 Ericsson 1338 8400 Blvd Decarie 1339 Town of Mount Royal, Quebec 1340 Canada 1342 Email: suresh.krishnan@ericsson.com