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