idnits 2.17.1 draft-ietf-dhc-option-guidelines-09.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 (December 20, 2012) is 4143 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-04 == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- 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: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group Google 4 Internet-Draft T. Mrugalski 5 Updates: 3315 (if approved) M. Siodelski 6 Intended status: Standards Track ISC 7 Expires: June 23, 2013 S. Jiang 8 Huawei Technologies Co., Ltd 9 S. Krishnan 10 Ericsson 11 December 20, 2012 13 Guidelines for Creating New DHCPv6 Options 14 draft-ietf-dhc-option-guidelines-09 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 June 23, 2013. 40 Copyright Notice 42 Copyright (c) 2012 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 variable length data . . . . . . . . . . . . . 9 69 5.8. Option with DNS Wire Format Domain Name List . . . . . . . 10 70 5.9. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 10 71 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 11 72 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8. Choosing between FQDN and address . . . . . . . . . . . . . . 12 74 9. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 14 75 10. Additional States Considered Harmful . . . . . . . . . . . . . 14 76 11. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 15 77 12. Multiple provisioning domains . . . . . . . . . . . . . . . . 15 78 13. Considerations for Creating New Formats . . . . . . . . . . . 16 79 14. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 15. Clients Request their Options . . . . . . . . . . . . . . . . 16 81 16. Transition Technologies . . . . . . . . . . . . . . . . . . . 17 82 17. Security Considerations . . . . . . . . . . . . . . . . . . . 18 83 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 84 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 85 20. Informative References . . . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. Introduction 96 Most protocol developers ask themselves if a protocol will work, or 97 work efficiently. These are important questions, but another less 98 frequently considered question is whether the proposed protocol 99 presents itself needless barriers to adoption by deployed software. 101 DHCPv6 [RFC3315] software implementors are not merely faced with the 102 task of handling a given option's format on the wire. The option 103 must fit into every stage of the system's process, starting with the 104 user interface used to enter the configuration up to the machine 105 interfaces where configuration is ultimately consumed. 107 Another frequently overlooked aspect of rapid adoption is whether the 108 option requires operators to be intimately familiar with the option's 109 internal format in order to use it? Most DHCPv6 software provides a 110 facility for handling unknown options at the time of publication. 111 The handling of such options usually needs to be manually configured 112 by the operator. But if doing so requires extensive reading (more 113 than can be covered in a simple FAQ for example), it inhibits 114 adoption. 116 So although a given solution would work, and might even be space, 117 time, or aesthetically optimal, a given option is presented with a 118 series of ever-worsening challenges to be adopted; 120 o If it doesn't fit neatly into existing config files. 122 o If it requries new source code changes to be adopted, and hence 123 upgrades of deployed software. 125 o If it does not share its deployment fate in a general manner with 126 other options, standing alone in requiring code changes or 127 reworking configuration file syntaxes. 129 There are many things DHCPv6 option creators can do to avoid the 130 pitfalls in this list entirely, or failing that, to make software 131 implementors lives easier and improve its chances for widespread 132 adoption. 134 3. When to Use DHCPv6 136 Principally, DHCPv6 carries configuration parameters for its clients. 137 Any knob, dial, slider, or checkbox on the client system, such as "my 138 domain name servers", "my hostname", or even "my shutdown 139 temperature" are candidates for being configured by DHCPv6. 141 The presence of such a knob isn't enough, because DHCPv6 also 142 presents the extension of an administrative domain - the operator of 143 the network to which the client is currently attached. Someone runs 144 not only the local switching network infrastructure that the client 145 is directly (or wirelessly) attached to, but the various methods of 146 accessing the external Internet via local assist services that 147 network must also provide (such as domain name servers, or routers). 148 This means that in addition to the existence of a configuration 149 parameter, one must also ask themselves if it is reasonable for this 150 parameter to be set by the directly attached network's 151 administrators. 153 Note that the client still reserves the right to ignore values 154 received via DHCPv6 (for example, due to having a value manually 155 configured by its own operator). Bear in mind that doing so might 156 cause the client to be rejected network attachment privileges, and 157 this is one main reason for the use of DHCPv6 in corporate 158 enterprises. 160 4. General Principles 162 The primary guiding principle to follow in order to enhance an 163 option's adoptability is simplification. More specifically, the 164 option should be created in such a way that does not require any new 165 or special case software to support. If old software currently 166 deployed and in the field can adopt the option through supplied 167 configuration facilities then it's fairly certain that new software 168 can easily formally adopt it. 170 There are at least two classes of DHCPv6 options: A bulk class of 171 options which are provided explicitly to carry data from one side of 172 the DHCPv6 exchange to the other (such as nameservers, domain names, 173 or time servers), and a protocol class of options which require 174 special processing on the part of the DHCPv6 software or are used 175 during special processing (such as the Fully Qualified Domain Name 176 (FQDN) option [RFC4704]), and so forth; these options carry data that 177 is the result of a routine in some DHCPv6 software. 179 The guidelines laid out here should be applied in a relaxed manner 180 for the protocol class of options. Wherever special case code is 181 already required to adopt the DHCPv6 option, it is substantially more 182 reasonable to format the option in a less generic fashion, if there 183 are measurable benefits to doing so. 185 5. Reusing Other Options 187 The easiest approach to manufacturing trivially deployable DHCPv6 188 Options is to assemble the option out of whatever common fragments 189 fit - possibly allowing a group of fragments to repeat to fill the 190 remaining space (if present) and so provide multiple values. Place 191 all fixed size values at the start of the option, and any variable/ 192 indeterminate sized value at the tail end of the option. 194 This estimates that implementations will be able to reuse code paths 195 designed to support the other options. 197 There is a tradeoff between the adoptability of previously defined 198 option formats, and the advantages that new or specialized formats 199 can provide. In general, it is usually preferrable to reuse 200 previously used option formats. 202 However, it isn't very practical to consider the bulk of DHCPv6 203 options already allocated, and consider which of those solve a 204 similar problem. So, the following list of common option format 205 fragments is provided as a shorthand. Please note that it is not 206 complete in terms of exampling every option format ever devised...it 207 is only a list of option format fragments which are used in two or 208 more options. 210 5.1. Option with IPv6 addresses 212 This option format is used to carry one or many IPv6 addresses. In 213 some cases the number of allowed address is limited (e.g. to one): 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | option-code | option-len | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 | ipv6-address | 222 | | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | | 226 | ipv6-address | 227 | | 228 | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | ... | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1: Option with IPv6 address 235 Examples of use: 237 o DHCPv6 server unicast address [RFC3315] 239 o SIP Servers IPv6 Address List [RFC3319] 241 o DNS Recursive Name Server [RFC3646] 243 o NIS Servers [RFC3898] 245 o SNTP Servers [RFC4075] 247 o Broadcast and Multicast Service Controller IPv6 Address Option for 248 DHCPv6 [RFC4280] 250 o MIPv6 Home Agent Address [RFC6610] (a single address only) 252 o NTP server [RFC5908] (a single address only) 254 o NTP Multicast address [RFC5908] (a single address only) 256 5.2. Option with a single flag (boolean) 258 Sometimes it is useful to convey a single flag that can either take 259 on or off values. Instead of specifying an option with one bit of 260 usable data and 7 bits of padding, it is better to define an option 261 without any content. It is the presence or absence of the option 262 that conveys the value. This approach has the additional benefit of 263 absent option designating the default, i.e. administrator has to take 264 explicit actions to deploy the oposite of the default value. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | option-code | option-len | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2: Option for conveying boolean 273 Examples of use: 275 o DHCPv6 rapid-commit [RFC3315] 277 5.3. Option with IPv6 prefix 279 Sometimes there is a need to convey IPv6 prefix. The information 280 that should be delivered to the user is a 128-bit IPv6 prefix 281 together with a prefix length that takes values from 0 to 128. Using 282 the simplest approach, the option would convey that information as 283 is. However, in many cases /64 or shorter prefixes are used. That 284 means that remaining 128 - prefix length bits are zeros. That means 285 that in typical case case of /64 prefixes the option would contains 286 at least 8 bytes of useless zeros. That should be avoided. For that 287 reason the recommended format for storing prefixes is as follows: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | OPTION_MAP_DMR | option-length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | prefix6-len | ipv6-prefix | 295 +-+-+-+-+-+-+-+-+ (variable length) | 296 . . 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Figure 3: Option with IPv6 Prefix 301 Option-length is set to 1 + length of the IPv6 prefix. Prefix6-len 302 it one octet long and specifies prefix length of the IPv6 prefix 303 expressed in bits. Typically allowed values are 0 to 128. 305 ipv6-prefix field is a variable length field that specifies the IPv6 306 prefix. This field is padded with zeros up to the nearest octet 307 boundary when prefix6-len is not divisible by 8. 309 Examples of use: 311 o Default Mapping Rule [I-D.ietf-softwire-map-dhcp] 313 It should be noted that Prefix Delegation mechanism used in [RFC3633] 314 uses constant length prefixes. The concern about option length was 315 not well understood at the time of its publication. 317 5.4. Option with 32-bit integer value 319 This option format can be used to carry 32 bit-signed or unsigned 320 integer value: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | option-code | option-len | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | 32-bit-integer | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 4: Option with 32-bit-integer value 331 Examples of use: 333 o Information Refresh Time [RFC4242] 335 5.5. Option with 16-bit integer value 337 This option format can be used to carry 16-bit signed or unsigned 338 integer values: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | option-code | option-len | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | 16-bit-integer | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 5: Option with 16-bit integer value 349 Examples of use: 351 o Elapsed Time [RFC3315] 353 5.6. Option with 8-bit integer value 355 This option format can be used to carry 8-bit integer values: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | option-code | option-len | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | 8-bit-integer | 363 +-+-+-+-+-+-+-+-+ 365 Figure 6: Option with 8-bit integer value 367 Examples of use: 369 o DHCPv6 Preference [RFC3315] 371 5.7. Option with variable length data 373 This option can be used to carry variable length data of any kind. 374 Internal representation of carried data is option specific. Some of 375 the existing DHCPv6 options use NVT-ASCII strings to encode: 376 filenames, host or domain names, protocol features or textual 377 messages such as verbose error indicators. 379 This option format provides a lot of flexibility to pass data of 380 almost any kind. Though, whenever possible it is highly recommended 381 to use more specialized options, with field types better matching 382 carried data types. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | option-code | option-len | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 . . 389 . variable length data . 390 . . 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 7: Option with variale length data 395 Examples of use: 397 o Client Identifier [RFC3315] 399 o Server Identifier [RFC3315] 401 o Boot File URL [RFC5970] 403 5.8. Option with DNS Wire Format Domain Name List 405 This option is used to carry 'domain search' lists or any host or 406 domain name: 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | option-code | option-length | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | DNS Wire Format Domain Name List | 413 | ... | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 8: Option with DNS Wire Format Domain Name List 418 Examples of use: 420 o SIP Servers Domain Name List [RFC3319] (many domains) 422 o NIS Domain Name (many domains) [RFC3898] (many domains) 424 o DS-Lite AFTR location [RFC6334] (a single FQDN) 426 o Home Network Identifier [RFC6610] (a single FQDN) 428 o Home Agent FQDN [RFC6610] (a single FQDN) 430 5.9. Option with IPv6 Prefix 432 Some options need to convey IPv6 prefix. Such a prefix includes the 433 prefix itself and a prefix length. The simple approach would be to 434 define a 128 bit field denoting a prefix, followed by a 8 bit field 435 that specifies prefix length. This approach was used in 436 OPTION_IAPREFIX, defined in [RFC3633]. That approach is no longer 437 recommended and should not be used anymore. 439 In many cases configured prefix lengths are /64 or even shorter. 440 That means that every option conveys many zeroes bits that are 441 useless. For example for /48 there are 10 bytes of useless data. 442 This waste is mulitpled by the number of option instances in a 443 message. Therefore a different approach should be used. Prefixes 444 should be conveyed as 8 bit prefix length field that is followed by 445 variable length prefix. 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | option-code | option-length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | prefix6-len | | 453 +-+-+-+-+-+-+-+-+ ipv6-prefix | 454 | (variable length) | 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 9: Option with IPv6 Prefix 460 The following description of the fields can be included in the draft: 462 o prefix6-len: 8 bits long field expressing the bit mask length of 463 the IPv6 prefix specified in the ipv6-prefix field. 465 o ipv6-prefix: a variable length field that specifies the IPv6 466 prefix for (explain purpose of the prefix). The field is padded 467 with zeros up to the nearest octet boundary when prefix6-len is 468 not divisible by 8. 470 It should be pointed out that similar optimization does not provide 471 useful savings in case of IPv4 prefixes. IPv4 prefixes should be 472 sent as a 32 bits fields. 474 6. Avoid Conditional Formatting 476 Placing a octet at the start of the option which informs the software 477 how to process the remaining octets of the option may appear simple 478 to the casual observer. But the only conditional formatting methods 479 that are in widespread use today are 'protocol' class options. So 480 conditional formatting requires new code to be written, as well as 481 introduces an implementation problem; as it requires that all 482 speakers implement all current and future conditional formats. 484 Conditional formatting is not recommended, except in cases where the 485 DHCPv6 option has already been deployed experimentally, and all but 486 one conditional format is deprecated. 488 7. Avoid Aliasing 490 Options are said to be aliases of each other if they provide input to 491 the same configuration parameter. A commonly proposed example is to 492 configure the location of some new service ("my foo server") using a 493 binary IP address, a domain name field, and a URL. This kind of 494 aliasing is undesirable, and is not recommended. 496 In this case, where three different formats are supposed, it more 497 than triples the work of the software involved, requiring support for 498 not merely one format, but support to produce and digest all three. 499 Furthermore, code development and testing must cover all possible 500 combinations of defined formats. Since clients cannot predict what 501 values the server will provide, they must request all formats... so 502 in the case where the server is configured with all formats, DHCPv6 503 option space is wasted on option contents that are redundant. 505 It also becomes unclear which types of values are mandatory, and how 506 configuring some of the options may influence the others. For 507 example, if an operator configures the URL only, should the server 508 synthesize a domain name and IP address? 510 A single configuration value on a host is probably presented to the 511 operator (or other software on the machine) in a single field or 512 channel. If that channel has a natural format, then any alternative 513 formats merely make more work for intervening software in providing 514 conversions. 516 So the best advice is to choose the one method that best fulfills the 517 requirements, be that for simplicity (such as with an IP address and 518 port pair), late binding (such as with DNS), or completeness (such as 519 with a URL). 521 8. Choosing between FQDN and address 523 Some parameters may be specified as FQDN or an address. It is not 524 allowed to define both option types at the same time (see section 525 Section 7), so one of them must be chosen. This section is intended 526 as a help to make an informed decision in that regard. 528 On the specific subject of desiring to configure a value using a FQDN 529 instead of a binary IP address, note that most DHCPv6 server 530 implementations will happily accept a Domain Name entered by the 531 administrator, and use DNS resolution to render binary IP addresses 532 in DHCPv6 replies to clients. Consequently, consider the extra 533 packet overhead incurred on the client's end to perform DNS 534 resolution itself. The client may be operating on a battery and 535 packet transmission is a non-trivial use of power, and the extra RTT 536 delays the client must endure before the service is configured are at 537 least two factors to consider in making a decision on format. 539 Unless there are specific reasons to do otherwise, address should be 540 used. It is simpler to use, its validation is trivial (length of 16 541 constitutes a valid option), is explicit and does not allow any 542 ambiguity. It is faster (does not require extra resolution efforts), 543 so it is more efficient, which can be especially important for energy 544 restricted devices. 546 FQDN does require a resolution into an actual address. This implies 547 number of questions that should be answered. First is when should 548 the resolution be taken. There are couple possible answers: a) by 549 the server, when it is started, b) by the server, when it is about to 550 send an option, c) by the client, immediately after receiving an 551 option, d) by the client, when the content of the option is actually 552 consumed. For a), b) and possibly c), the option should really 553 convey an address, not FQDN. The only real incentive to use FQDN is 554 case d). It is the only case that allows possible changes in the DNS 555 to be picked up by clients. 557 FQDN imposes number of additional failure modes and issues that 558 should be dealt with: 560 The client must have a knowledge about available DNS servers. 561 That typically means that option DNS_SERVERS is mandatory. This 562 should be mentioned in the draft that defines new option. It is 563 possible that the server will return FQDN option, but not the DNS 564 Servers option. There should be a brief discussion about it; 566 The DNS may not be reachable; 568 DNS may be available, but may not have appropriate information 569 (e.g. no AAAA records for specified FQDN) 571 Address family must be specified (A, AAAA or any); 573 What should the client do if there are multiple records available 574 (use only the first one, use all, use one and switch to the second 575 if the first fails for whatever reason, etc.); 577 Multi-homed devices may be connected to different administrative 578 domains with each domain providing a different information in DNS 579 (e.g. an enterprise network exposing private domains). Client may 580 send DNS queries to a different DNS server; 582 It should be mentioned if Internationalized Domain Names are 583 allowed. If they are, what kind of DNS option encoding should be 584 specified. 586 9. Suboptions in DHCPv6 588 Most options are conveyed in a DHCPv6 message directly. Although 589 there is no codified normative language for such options, they are 590 often referred to as top-level options. Many options may include 591 other options. Such inner options are often referred to as sub- 592 options. It should be noted that, contrary to DHCPv4, there is no 593 shortage of option numbers. Therefore all options share a common 594 option space. For example option type 1 meant different things in 595 DHCPv4, depending if it was located in top-level or inside of Relay 596 Agent Information option. There is no such ambiguity in DHCPv6 (with 597 the exception of [RFC5908]). 599 Such encapsulation mechanism is not limited to one level. There is 600 at least one defined option that is encapsulated twice: Identity 601 Association for Prefix Delegation (IA_PD, defined in [RFC3633], 602 section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 603 10). Such delegated prefix may contain an excluded prefix range that 604 is represented by PD_EXCLUDE option that is conveyed as sub-option 605 inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward 606 to refer to such options as sub-sub-option, therefore "sub-option" 607 term is typically used, regardless of the nesting level. 609 When defining configuration means for more complex mechanisms, it may 610 be tempting to simply use sub-options. That should usually be 611 avoided, as it increases complexity of the parser. It is much 612 easier, faster and less error prone to parse larger number of options 613 on a single (top-level) scope, than parse options on several scopes. 614 The use of sub-options should be avoided as much as possible but it 615 is better to use sub-options rather than conditional formatting. 617 It should be noted that currently there is no clear way defined for 618 requesting sub-options. Most known implementations are simply using 619 top-level ORO for requesting both top-level options and sub-options. 621 10. Additional States Considered Harmful 623 DHCP is a protocol designed for provisioning nodes. Less experienced 624 protocol designers often assume that it is easy to define an option 625 that will convey a different parameter for each node in a network. 626 Such problems arose during designs of MAP 627 [I-D.ietf-softwire-map-dhcp] and 4rd [I-D.ietf-softwire-4rd]. While 628 it would be easier for provisioned nodes to get ready to use per node 629 option values, such requirement puts exceedingly large loads on the 630 server side. Alternatives should be considered, if possible. As an 631 example, [I-D.ietf-softwire-map-dhcp] was designed in a way that all 632 nodes are provisioned with the same set of MAP options and each 633 provisioned node uses its unique address and delegated prefix to 634 generate node-specific information. Such solution does not introduce 635 any additional state for the server and therefore scales better. 637 It also should be noted that contrary to DHCPv4, DHCPv6 keeps several 638 timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) 639 contains T1 and T2 timers that designate time after which client will 640 initiate renewal. Those timers apply only to its own IA containers. 641 For renewing other parameters, please use Information Refresh Time 642 Option (defined in [RFC4242]). Introducing additional timers make 643 deployment unnecessarily complex. Please try to avoid it. 645 11. Is DHCPv6 dynamic? 647 DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. 648 Contrary to its name, is many contexts it is not dynamic. While 649 designing DHCPv6 options, it is worth noting that there is no 650 reliable way to instantly notify clients that something has happened, 651 e.g. parameter value has changed. There is a RECONFIGURE mechanism, 652 but it has several serious drawbacks that makes its use difficult. 653 First, its support is optional and many client implementations do not 654 support it. To use reconfigure mechanism, server must use its secret 655 nonce. That means that provisioning server is the only one that can 656 initiate reconfiguration. Other servers do not know it and cannot 657 trigger reconfiguration. Therefore the only reliable way for clients 658 to refresh their configuration is to wait till T1 expires. 660 12. Multiple provisioning domains 662 In some cases there could be more than one DHCPv6 server on a link, 663 with each provisioning a different set of parameters. One notable 664 example of such case is a home network with a connection to two 665 independent ISPs. 667 DHCPv6 was not initially designed with multiple provisioning domains. 668 Although [RFC3315] states that a client that receives more than one 669 ADVERTISE message, may respond to one or more, such capability was 670 never observed in any known implementations. Existing clients will 671 pick one server and will continue configuration process with that 672 server, ignoring all other servers. 674 This is a generic DHCP protocol issue and should not be dealt within 675 each option separately. This issue is better dealt with using a 676 protocol-level solution and fixing this problem should not be 677 attempted on a per option basis. 679 13. Considerations for Creating New Formats 681 If the option simply will not fit into any existing work by using 682 fragments, the last recourse is to create a new format to fit. 684 When doing so, it is not enough to gauge whether or not the option 685 format will work in the context of the option presently being 686 considered. It is equally important to consider if the new format's 687 fragments might reasonably have any other uses, and if so, to create 688 the option with the foreknowledge that its parts may later become a 689 common fragment. 691 One specific consideration to evaluate is whether or not options of a 692 similar format would need to have multiple or single values encoded 693 (whatever differs from the current option), and how that might be 694 accomplished in a similar format. 696 14. Option Size 698 DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through 699 its use of link-local addresses, it steps aside many of the 700 deployment problems that plague DHCPv4, and is actually an UDP over 701 IPv6 based protocol (compared to DHCPv4, which is mostly UDP over 702 IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly 703 refers readers to RFC 2460 Section 5, which describes an MTU of 1280 704 octets and a minimum fragment reassembly of 1500 octets. It's 705 feasible to suggest that DHCPv6 is capable of having larger options 706 deployed over it, and at least no common upper limit is yet known to 707 have been encoded by its implementors. It is impossible to describe 708 any fixed limit that cleanly divides those too big from the workable. 710 It is advantageous to prefer option formats which contain the desired 711 information in the smallest form factor that satisfies the 712 requirements. 714 DHCPv6 does allow for multiple instances of a given option, and they 715 are treated as distinct values following the defined format, however 716 this feature is generally preferred to be restricted to protocol 717 class features (such as the IA_* series of options). In such cases, 718 it is better to define an option as an array if it is possible. It 719 is recommended to clarify (with normative language) whether a given 720 DHCPv6 option may appear once or multiple times. 722 15. Clients Request their Options 724 The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 725 that serves two purposes - to inform the server what options the 726 client supports and is willing to consume. 728 It doesn't make sense for some options to appear on this Option 729 Request Option, such as those formed by elements of the protocol's 730 internal workings, or are formed on either end by DHCPv6-level 731 software engaged in some exchange of information. When in doubt, it 732 is prudent to assume that any new option must be present on the 733 relevant option request list if the client desires to receive it. 735 It is a frequent mistake of option draft authors, then, to create 736 text that implies that a server will simply provide the new option, 737 and clients will digest it. Generally, it's best to also specify 738 that clients MUST place the new option code on the Option Request 739 Option list, clients MAY include the new option in their packets to 740 servers with hints as values they desire, and server MAY include the 741 option when the client requested it (and the server has been so 742 configured). 744 Example: Clients MUST place the foo option code on the Option Request 745 Option list, clients MAY include option foo in their packets as hints 746 for the server as values the desire, and servers MAY include option 747 foo when the client requested it (and the server has been so 748 configured). 750 Creators of DHCPv6 options MUST NOT require special ordering of 751 options either in the relevant request option, or in the order of 752 options within the packet. Although it is reasonable to expect that 753 options will be processed in the order they appear in ORO, server 754 software is not required to sort DHCPv6 options into the same order 755 in reply messages. It should be noted that any requirement regarding 756 option ordering will break down most existing implementations, as 757 "order is not important" was one of the design priciples of DHCPv6 758 and many implementations follow it. For example, there are existing 759 implementations that use hash maps for storing options, so forcing 760 any particular order is not feasible without great deal of work. If 761 options must be processed in any specific order (e.g. due to inter- 762 dependency), use of option encapsulation should be considered. 764 16. Transition Technologies 766 Transition from IPv4 to IPv6 is progressing, albeit at somewhat 767 disappointing pace. Many transition technologies are proposed to 768 speed it up. As a natural consequence there are also DHCP options 769 proposed to provision those proposals. The inevitable question is 770 that whether the required parameters should be delivered over DHCPv4 771 or DHCPv6. Authors often don't give much thought about it and simply 772 pick DHCPv6 without realizing the consequences. IPv6 is expected to 773 stay with us for many decades, and so is DHCPv6. There is no 774 mechanism available to deprecate an option in DHCPv6, so any options 775 defined will stay with us as long as DHCPv6 protocol itself. It 776 seems likely that such options defined to transition from IPv4 will 777 outlive IPv4 by many decades. From that perspective it is better to 778 implement provisioning of the transition technologies in DHCPv4, 779 which will be obsoleted together with IPv4. 781 17. Security Considerations 783 DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes 784 it possible for DHCPv6 software to discriminate between authentic 785 endpoints and men in the middle. Other authentication mechanisms may 786 optionally be deployed. For example, the Secure DHCPv6 787 [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated 788 Addresses (CGA) [RFC3972], can provide source address ownership 789 validation, message origin authentication and message integrity 790 without requiring symmetric key pairs or supporting from any key 791 management system. However, as of now, the mechanism is not widely 792 deployed. It also does not provide end-to-end encryption. 794 So, while creating a new option, it is prudent to assume that the 795 DHCPv6 packet contents are always transmitted in the clear, and 796 actual production use of the software will probably be vulnerable at 797 least to man-in-the-middle attacks from within the network, even 798 where the network itself is protected from external attacks by 799 firewalls. In particular, some DHCPv6 message exchanges are 800 transmitted to multicast addresses that are likely broadcast anyway. 802 If an option is of a specific fixed length, it is useful to remind 803 the implementer of the option data's full length. This is easily 804 done by declaring the specific value of the 'length' tag of the 805 option. This helps to gently remind implementers to validate option 806 length before digesting them into likewise fixed length regions of 807 memory or stack. 809 If an option may be of variable size (such as having indeterminate 810 length fields, such as domain names or text strings), it is advisable 811 to explicitly remind the implementor to be aware of the potential for 812 long options. Either define a reasonable upper limit (and suggest 813 validating it), or explicitly remind the implementor that an option 814 may be exceptionally long (to be prepared to handle errors rather 815 than truncate values). 817 For some option contents, out of bound values may be used to breach 818 security. An IP address field might be made to carry a loopback 819 address, or local broadcast address, and depending on the protocol 820 this may lead to undesirable results. A domain name field may be 821 filled with contrived contents that exceed the limitations placed 822 upon domain name formatting... as this value is possibly delivered to 823 "internal configuration" records of the system, it may be implicitly 824 trusted without being validated. 826 So it behooves an option's definition to contain any validation 827 measures as can reasonably be made. 829 18. IANA Considerations 831 This document has no actions for IANA. 833 19. Acknowledgements 835 Authors would like to thank Simon Perreault, Bernie Volz and Ted 836 Lemon for their comments. 838 20. Informative References 840 [I-D.ietf-dhc-secure-dhcpv6] 841 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 842 draft-ietf-dhc-secure-dhcpv6-07 (work in progress), 843 September 2012. 845 [I-D.ietf-softwire-4rd] 846 Jiang, S., Despres, R., Penno, R., Lee, Y., Chen, G., and 847 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 848 Solution (4rd)", draft-ietf-softwire-4rd-04 (work in 849 progress), October 2012. 851 [I-D.ietf-softwire-map-dhcp] 852 Mrugalski, T., Troan, O., Bao, C., Dec, W., and L. Yeh, 853 "DHCPv6 Options for Mapping of Address and Port", 854 draft-ietf-softwire-map-dhcp-01 (work in progress), 855 August 2012. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 861 and M. Carney, "Dynamic Host Configuration Protocol for 862 IPv6 (DHCPv6)", RFC 3315, July 2003. 864 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 865 Protocol (DHCPv6) Options for Session Initiation Protocol 866 (SIP) Servers", RFC 3319, July 2003. 868 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 869 Host Configuration Protocol (DHCP) version 6", RFC 3633, 870 December 2003. 872 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 873 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 874 December 2003. 876 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 877 Configuration Options for Dynamic Host Configuration 878 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 880 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 881 RFC 3972, March 2005. 883 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 884 Configuration Option for DHCPv6", RFC 4075, May 2005. 886 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 887 Time Option for Dynamic Host Configuration Protocol for 888 IPv6 (DHCPv6)", RFC 4242, November 2005. 890 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 891 Configuration Protocol (DHCP) Options for Broadcast and 892 Multicast Control Servers", RFC 4280, November 2005. 894 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 895 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 896 Option", RFC 4704, October 2006. 898 [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) 899 Server Option for DHCPv6", RFC 5908, June 2010. 901 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 902 Options for Network Boot", RFC 5970, September 2010. 904 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 905 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", 906 RFC 6334, August 2011. 908 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 909 "Prefix Exclude Option for DHCPv6-based Prefix 910 Delegation", RFC 6603, May 2012. 912 [RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. 913 Lemon, "DHCP Options for Home Information Discovery in 914 Mobile IPv6 (MIPv6)", RFC 6610, May 2012. 916 Authors' Addresses 918 David W. Hankins 919 Google, Inc. 920 1600 Amphitheatre Parkway 921 Mountain View, CA 94043 922 USA 924 Email: dhankins@google.com 926 Tomasz Mrugalski 927 Internet Systems Consortium, Inc. 928 950 Charter Street 929 Redwood City, CA 94063 930 USA 932 Phone: +1 650 423 1345 933 Email: tomasz.mrugalski@gmail.com 935 Marcin Siodelski 937 Phone: 938 Email: msiodelski@gmail.com 940 Sheng Jiang 941 Huawei Technologies Co., Ltd 942 Q14, Huawei Campus, No.156 Beiqing Road 943 Hai-Dian District, Beijing, 100095 944 P.R. China 946 Email: jiangsheng@huawei.com 947 Suresh Krishnan 948 Ericsson 949 8400 Blvd Decarie 950 Town of Mount Royal, Quebec 951 Canada 953 Email: suresh.krishnan@ericsson.com