idnits 2.17.1 draft-ietf-dhc-option-guidelines-08.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 -- 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 19, 2012) is 4328 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 635, but no explicit reference was found in the text -- 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) == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-06 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-00 == Outdated reference: A later version (-03) exists of draft-mdt-softwire-map-dhcp-option-02 Summary: 0 errors (**), 0 flaws (~~), 5 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 Intended status: Informational M. Siodelski 6 Expires: December 21, 2012 ISC 7 S. Jiang 8 Huawei Technologies Co., Ltd 9 S. Krishnan 10 Ericsson 11 June 19, 2012 13 Guidelines for Creating New DHCPv6 Options 14 draft-ietf-dhc-option-guidelines-08 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. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 21, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . . 4 59 4. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Option with IPv6 addresses . . . . . . . . . . . . . . . . 5 62 5.2. Option with 32-bit integer value . . . . . . . . . . . . . 6 63 5.3. Option with 16-bit integer value . . . . . . . . . . . . . 7 64 5.4. Option with 8-bit integer value . . . . . . . . . . . . . 7 65 5.5. Option with variable length data . . . . . . . . . . . . . 7 66 5.6. Option with DNS Wire Format Domain Name List . . . . . . . 8 67 6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . . 9 68 7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 9 69 8. Suboptions in DHCPv6 . . . . . . . . . . . . . . . . . . . . . 10 70 9. Additional States Considered Harmful . . . . . . . . . . . . . 11 71 10. Is DHCPv6 dynamic? . . . . . . . . . . . . . . . . . . . . . . 11 72 11. Multiple provisioning domains . . . . . . . . . . . . . . . . 11 73 12. Considerations for Creating New Formats . . . . . . . . . . . 12 74 13. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 14. Clients Request their Options . . . . . . . . . . . . . . . . 13 76 15. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 17.1. Informative References . . . . . . . . . . . . . . . . . . 15 80 17.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Introduction 91 Most protocol developers ask themselves if a protocol will work, or 92 work efficiently. These are important questions, but another less 93 frequently considered question is whether the proposed protocol 94 presents itself needless barriers to adoption by deployed software. 96 DHCPv6 [RFC3315] software implementors are not merely faced with the 97 task of handling a given option's format on the wire. The option 98 must fit into every stage of the system's process, starting with the 99 user interface used to enter the configuration upto the machine 100 interfaces where configuration is ultimately consumed. 102 Another frequently overlooked aspect of rapid adoption is whether the 103 option requires operators to be intimately familiar with the option's 104 internal format in order to use it? Most DHCPv6 software provides a 105 facility for handling unknown options at the time of publication. 106 The handling of such options usually needs to be manually configured 107 by the operator. But if doing so requires extensive reading (more 108 than can be covered in a simple FAQ for example), it inhibits 109 adoption. 111 So although a given solution would work, and might even be space, 112 time, or aesthetically optimal, a given option is presented with a 113 series of ever-worsening challenges to be adopted; 115 o If it doesn't fit neatly into existing config files. 117 o If it requries new source code changes to be adopted, and hence 118 upgrades of deployed software. 120 o If it does not share its deployment fate in a general manner with 121 other options, standing alone in requiring code changes or 122 reworking configuration file syntaxes. 124 There are many things DHCPv6 option creators can do to avoid the 125 pitfalls in this list entirely, or failing that, to make software 126 implementors lives easier and improve its chances for widespread 127 adoption. 129 3. When to Use DHCPv6 131 Principally, DHCPv6 carries configuration parameters for its clients. 132 Any knob, dial, slider, or checkbox on the client system, such as "my 133 domain name servers", "my hostname", or even "my shutdown 134 temperature" are candidates for being configured by DHCPv6. 136 The presence of such a knob isn't enough, because DHCPv6 also 137 presents the extension of an administrative domain - the operator of 138 the network to which the client is currently attached. Someone runs 139 not only the local switching network infrastructure that the client 140 is directly (or wirelessly) attached to, but the various methods of 141 accessing the external Internet via local assist services that 142 network must also provide (such as domain name servers, or routers). 143 This means that in addition to the existence of a configuration 144 parameter, one must also ask themselves if it is reasonable for this 145 parameter to be set by the directly attached network's 146 administrators. 148 Note that the client still reserves the right to ignore values 149 received via DHCPv6 (for example, due to having a value manually 150 configured by its own operator). Bear in mind that doing so might 151 cause the client to be rejected network attachment privileges, and 152 this is one main reason for the use of DHCPv6 in corporate 153 enterprises. 155 4. General Principles 157 The primary guiding principle to follow in order to enhance an 158 option's adoptability is simplification. More specifically, the 159 option should be created in such a way that does not require any new 160 or special case software to support. If old software currently 161 deployed and in the field can adopt the option through supplied 162 configuration facilities then it's fairly certain that new software 163 can easily formally adopt it. 165 There are at least two classes of DHCPv6 options: A bulk class of 166 options which are provided explicitly to carry data from one side of 167 the DHCPv6 exchange to the other (such as nameservers, domain names, 168 or time servers), and a protocol class of options which require 169 special processing on the part of the DHCPv6 software or are used 170 during special processing (such as the Fully Qualified Domain Name 171 (FQDN) option [RFC4704]), and so forth; these options carry data that 172 is the result of a routine in some DHCPv6 software. 174 The guidelines laid out here should be applied in a relaxed manner 175 for the protocol class of options. Wherever special case code is 176 already required to adopt the DHCPv6 option, it is substantially more 177 reasonable to format the option in a less generic fashion, if there 178 are measurable benefits to doing so. 180 5. Reusing Other Options 182 The easiest approach to manufacturing trivially deployable DHCPv6 183 Options is to assemble the option out of whatever common fragments 184 fit - possibly allowing a group of fragments to repeat to fill the 185 remaining space (if present) and so provide multiple values. Place 186 all fixed size values at the start of the option, and any variable/ 187 indeterminate sized value at the tail end of the option. 189 This estimates that implementations will be able to reuse code paths 190 designed to support the other options. 192 There is a tradeoff between the adoptability of previously defined 193 option formats, and the advantages that new or specialized formats 194 can provide. In general, it is usually preferrable to reuse 195 previously used option formats. 197 However, it isn't very practical to consider the bulk of DHCPv6 198 options already allocated, and consider which of those solve a 199 similar problem. So, the following list of common option format 200 fragments is provided as a shorthand. Please note that it is not 201 complete in terms of exampling every option format ever devised...it 202 is only a list of option format fragments which are used in two or 203 more options. 205 5.1. Option with IPv6 addresses 207 This option format is used to carry one or many IPv6 addresses: 209 0 1 2 3 210 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 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | option-code | option-len | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | | 215 | ipv6-address | 216 | | 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 | ipv6-address | 221 | | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | ... | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: Option with IPv6 address 229 Examples of use: 231 o DHCPv6 server unicast address [RFC3315] 233 o SIP Servers IPv6 Address List [RFC3319] 235 o DNS Recursive Name Server [RFC3646] 237 o NIS Servers [RFC3898] 239 o SNTP Servers [RFC4075] 241 o Broadcast and Multicast Service Controller IPv6 Address Option for 242 DHCPv6 [RFC4280] 244 5.2. Option with 32-bit integer value 246 This option format can be used to carry 32 bit-signed or unsigned 247 integer value: 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | option-code | option-len | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | 32-bit-integer | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: Option with 32-bit-integer value 258 Examples of use: 260 o Information Refresh Time [RFC4242] 262 5.3. Option with 16-bit integer value 264 This option format can be used to carry 16-bit signed or unsigned 265 integer values: 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | option-code | option-len | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | 16-bit-integer | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 3: Option with 16-bit integer value 276 Examples of use: 278 o Elapsed Time [RFC3315] 280 5.4. Option with 8-bit integer value 282 This option format can be used to carry 8-bit integer values: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | option-code | option-len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 8-bit-integer | 289 +-+-+-+-+-+-+-+-+ 291 Figure 4: Option with 8-bit integer value 293 Examples of use: 295 o DHCPv6 Preference [RFC3315] 297 5.5. Option with variable length data 299 This option can be used to carry variable length data of any kind. 300 Internal representation of carried data is option specific. Some of 301 the existing DHCPv6 options use NVT-ASCII strings to encode: 302 filenames, host or domain names, protocol features or textual 303 messages such as verbose error indicators. 305 This option format provides a lot of flexibility to pass data of 306 almost any kind. Though, whenever possible it is highly recommended 307 to use more specialized options, with field types better matching 308 carried data types. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | option-code | option-len | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 . . 315 . variable length data . 316 . . 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Figure 5: Option with variale length data 321 Examples of use: 323 o Client Identifier [RFC3315] 325 o Server Identifier [RFC3315] 327 o Boot File URL [RFC5970] 329 5.6. Option with DNS Wire Format Domain Name List 331 This option is used to carry 'domain search' lists or any host or 332 domain name: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | option-code | option-length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | DNS Wire Format Domain Name List | 339 | ... | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 6: Option with DNS Wire Format Domain Name List 344 Examples of use: 346 o SIP Servers Domain Name List [RFC3319] 348 o NIS Domain Name [RFC3898] 350 6. Avoid Conditional Formatting 352 Placing a octet at the start of the option which informs the software 353 how to process the remaining octets of the option may appear simple 354 to the casual observer. But the only conditional formatting methods 355 that are in widespread use today are 'protocol' class options. So 356 conditional formatting requires new code to be written, as well as 357 introduces an implementation problem; as it requires that all 358 speakers implement all current and future conditional formats. 360 Conditional formatting is not recommended, except in cases where the 361 DHCPv6 option has already been deployed experimentally, and all but 362 one conditional format is deprecated. 364 7. Avoid Aliasing 366 Options are said to be aliases of each other if they provide input to 367 the same configuration parameter. A commonly proposed example is to 368 configure the location of some new service ("my foo server") using a 369 binary IP address, a domain name field, and a URL. This kind of 370 aliasing is undesirable, and is not recommended. 372 In this case, where three different formats are supposed, it more 373 than triples the work of the software involved, requiring support for 374 not merely one format, but support to produce and digest all three. 375 Furthermore, code development and testing must cover all possible 376 combinations of defined formats. Since clients cannot predict what 377 values the server will provide, they must request all formats... so 378 in the case where the server is configured with all formats, DHCPv6 379 option space is wasted on option contents that are redundant. 381 It also becomes unclear which types of values are mandatory, and how 382 configuring some of the options may influence the others. For 383 example, if an operator configures the URL only, should the server 384 synthesize a domain name and IP address? 386 A single configuration value on a host is probably presented to the 387 operator (or other software on the machine) in a single field or 388 channel. If that channel has a natural format, then any alternative 389 formats merely make more work for intervening software in providing 390 conversions. 392 So the best advice is to choose the one method that best fulfills the 393 requirements, be that for simplicity (such as with an IP address and 394 port pair), late binding (such as with DNS), or completeness (such as 395 with a URL). 397 On the specific subject of desiring to configure a value using a FQDN 398 instead of a binary IP address, note that most DHCPv6 server 399 implementations will happily accept a Domain Name entered by the 400 administrator, and use DNS resolution to render binary IP addresses 401 in DHCPv6 replies to clients. Consequently, consider the extra 402 packet overhead incurred on the client's end to perform DNS 403 resolution itself. The client may be operating on a battery and 404 packet transmission is a non-trivial use of power, and the extra RTT 405 delays the client must endure before the service is configured are at 406 least two factors to consider in making a decision on format. 408 8. Suboptions in DHCPv6 410 Most options are conveyed in a DHCPv6 message directly. Although 411 there is no codified normative language for such options, they are 412 often referred to as top-level options. Many options may include 413 other options. Such inner options are often referred to as sub- 414 options. It should be noted that, contrary to DHCPv4, there is no 415 shortage of option numbers. Therefore all options share a common 416 option space. For example option type 1 meant different things in 417 DHCPv4, depending if it was located in top-level or inside of Relay 418 Agent Information option. There is no such ambiguity in DHCPv6. 420 Such encapsulation mechanism is not limited to one level. There is 421 at least one defined option that is encapsulated twice: Identity 422 Association for Prefix Delegation (IA_PD, defined in [RFC3633], 423 section 9) conveys IA Prefix (IAPREFIX, defined in [RFC3633], section 424 10). Such delegated prefix may contain an excluded prefix range that 425 is represented by PD_EXCLUDE option that is conveyed as sub-option 426 inside IAPREFIX (PD_EXCLUDE, defined in [RFC6603]). It seems awkward 427 to refer to such options as sub-sub-option, therefore "sub-option" 428 term is typically used, regardless of the nesting level. 430 When defining configuration means for more complex mechanisms, it may 431 be tempting to simply use sub-options. That should usually be 432 avoided, as it increases complexity of the parser. It is much 433 easier, faster and less error prone to parse larger number of options 434 on a single (top-level) scope, than parse options on several scopes. 435 The use of sub-options should be avoided as much as possible but it 436 is better to use sub-options rather than conditional formatting. 438 It should be noted that currently there is no clear way defined for 439 requesting sub-options. Most known implementations are simply using 440 top-level ORO for requesting both top-level options and sub-options. 442 9. Additional States Considered Harmful 444 DHCP is a protocol designed for provisioning nodes. Less experienced 445 protocol designers often assume that it is easy to define an option 446 that will convey a different parameter for each node in a network. 447 Such problems arose during designs of MAP 448 [I-D.mdt-softwire-map-dhcp-option] and 4rd [I-D.ietf-softwire-4rd]. 449 While it would be easier for provisioned nodes to get ready to use 450 per node option values, such requirement puts exceedingly large loads 451 on the server side. Alternatives should be considered, if possible. 452 As an example, [I-D.mdt-softwire-map-dhcp-option] was designed in a 453 way that all nodes are provisioned with the same set of MAP options 454 and each provisioned node uses its unique address and delegated 455 prefix to generate node-specific information. Such solution does not 456 introduce any additional state for the server and therefore scales 457 better. 459 It also should be noted that contrary to DHCPv4, DHCPv6 keeps several 460 timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) 461 contains T1 and T2 timers that designate time after which client will 462 initiate renewal. Those timers apply only to its own IA containers. 463 For renewing other parameters, please use Information Refresh Time 464 Option (defined in [RFC4242]). Introducing additional timers make 465 deployment unnecessarily complex. Please try to avoid it. 467 10. Is DHCPv6 dynamic? 469 DHCPv6 stands for Dynamic Host Configuration Protocol for IPv6. 470 Contrary to its name, is many contexts it is not dynamic. While 471 designing DHCPv6 options, it is worth noting that there is no 472 reliable way to instantly notify clients that something has happened, 473 e.g. parameter value has changed. There is a RECONFIGURE mechanism, 474 but it has several serious drawbacks that makes its use difficult. 475 First, its support is optional and many client implementations do not 476 support it. To use reconfigure mechanism, server must use its secret 477 nonce. That means that provisioning server is the only one that can 478 initiate reconfiguration. Other servers do not know it and cannot 479 trigger reconfiguration. Therefore the only reliable way for clients 480 to refresh their configuration is to wait till T1 expires. 482 11. Multiple provisioning domains 484 In some cases there could be more than one DHCPv6 server on a link, 485 with each provisioning a different set of parameters. One notable 486 example of such case is a home network with a connection to two 487 independent ISPs. 489 DHCPv6 was not initially designed with multiple provisioning domains. 490 Although [RFC3315] states that a client that receives more than one 491 ADVERTISE message, may respond to one or more, such capability was 492 never observed in any known implementations. Existing clients will 493 pick one server and will continue configuration process with that 494 server, ignoring all other servers. 496 This is a generic DHCP protocol issue and should not be dealt within 497 each option separately. This issue is better dealt with using a 498 protocol-level solution and fixing this problem should not be 499 attempted on a per option basis. 501 12. Considerations for Creating New Formats 503 If the option simply will not fit into any existing work by using 504 fragments, the last recourse is to create a new format to fit. 506 When doing so, it is not enough to gauge whether or not the option 507 format will work in the context of the option presently being 508 considered. It is equally important to consider if the new format's 509 fragments might reasonably have any other uses, and if so, to create 510 the option with the foreknowledge that its parts may later become a 511 common fragment. 513 One specific consideration to evaluate is whether or not options of a 514 similar format would need to have multiple or single values encoded 515 (whatever differs from the current option), and how that might be 516 accomplished in a similar format. 518 13. Option Size 520 DHCPv6 [RFC3315] allows for packet sizes up to 64KB. First, through 521 its use of link-local addresses, it steps aside many of the 522 deployment problems that plague DHCPv4, and is actually an UDP over 523 IPv6 based protocol (compared to DHCPv4, which is mostly UDP over 524 IPv4 protocol, but with layer 2 hacks). Second, RFC 3315 explicitly 525 refers readers to RFC 2460 Section 5, which describes an MTU of 1280 526 octets and a minimum fragment reassembly of 1500 octets. It's 527 feasible to suggest that DHCPv6 is capable of having larger options 528 deployed over it, and at least no common upper limit is yet known to 529 have been encoded by its implementors. It is impossible to describe 530 any fixed limit that cleanly divides those too big from the workable. 532 It is advantageous to prefer option formats which contain the desired 533 information in the smallest form factor that satisfies the 534 requirements. 536 DHCPv6 does allow for multiple instances of a given option, and they 537 are treated as distinct values following the defined format, however 538 this feature is generally preferred to be restricted to protocol 539 class features (such as the IA_* series of options). In such cases, 540 it is better to define an option as an array if it is possible. It 541 is recommended to clarify (with normative language) whether a given 542 DHCPv6 option may appear once or multiple times. 544 14. Clients Request their Options 546 The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315], is an option 547 that serves two purposes - to inform the server what options the 548 client supports and is willing to consume. 550 It doesn't make sense for some options to appear on this Option 551 Request Option, such as those formed by elements of the protocol's 552 internal workings, or are formed on either end by DHCPv6-level 553 software engaged in some exchange of information. When in doubt, it 554 is prudent to assume that any new option must be present on the 555 relevant option request list if the client desires to receive it. 557 It is a frequent mistake of option draft authors, then, to create 558 text that implies that a server will simply provide the new option, 559 and clients will digest it. Generally, it's best to also specify 560 that clients MUST place the new option code on the relevant list 561 option, clients MAY include the new option in their packets to 562 servers with hints as to values they desire, and servers MAY respond 563 with the option contents (if they have been so configured). 565 Creators of DHCPv6 options MUST NOT require special ordering of 566 options either in the relevant request option, or in the order of 567 options within the packet. Although it is reasonable to expect that 568 options will be processed in the order they appear in ORO, server 569 software is not required to sort DHCPv6 options into the same order 570 in reply messages. It should be noted that any requirement regarding 571 option ordering will break down most existing implementations, as 572 "order is not important" was one of the design priciples of DHCPv6 573 and many implementations follow it. For example, there are existing 574 implementations that use hash maps for storing options, so forcing 575 any particular order is not feasible without great deal of work. If 576 options must be processed in any specific order (e.g. due to inter- 577 dependency), use of option encapsulation should be considered. 579 15. Security Considerations 581 DHCPv6 does have an Authentication mechanism ([RFC3315]) that makes 582 it possible for DHCPv6 software to discriminate between authentic 583 endpoints and men in the middle. Other authentication mechanisms may 584 optionally be deployed. For example, the Secure DHCPv6 585 [I-D.ietf-dhc-secure-dhcpv6], based on Cryptographically Generated 586 Addresses (CGA) [RFC3972], can provide source address ownership 587 validation, message origin authentication and message integrity 588 without requiring symmetric key pairs or supporting from any key 589 management system. However, as of now, the mechanism is not widely 590 deployed. It also does not provide end-to-end encryption. 592 So, while creating a new option, it is prudent to assume that the 593 DHCPv6 packet contents are always transmitted in the clear, and 594 actual production use of the software will probably be vulnerable at 595 least to man-in-the-middle attacks from within the network, even 596 where the network itself is protected from external attacks by 597 firewalls. In particular, some DHCPv6 message exchanges are 598 transmitted to multicast addresses that are likely broadcast anyway. 600 If an option is of a specific fixed length, it is useful to remind 601 the implementer of the option data's full length. This is easily 602 done by declaring the specific value of the 'length' tag of the 603 option. This helps to gently remind implementers to validate option 604 length before digesting them into likewise fixed length regions of 605 memory or stack. 607 If an option may be of variable size (such as having indeterminate 608 length fields, such as domain names or text strings), it is advisable 609 to explicitly remind the implementor to be aware of the potential for 610 long options. Either define a reasonable upper limit (and suggest 611 validating it), or explicitly remind the implementor that an option 612 may be exceptionally long (to be prepared to handle errors rather 613 than truncate values). 615 For some option contents, out of bound values may be used to breach 616 security. An IP address field might be made to carry a loopback 617 address, or local broadcast address, and depending on the protocol 618 this may lead to undesirable results. A domain name field may be 619 filled with contrived contents that exceed the limitations placed 620 upon domain name formatting... as this value is possibly delivered to 621 "internal configuration" records of the system, it may be implicitly 622 trusted without being validated. 624 So it behooves an option's definition to contain any validation 625 measures as can reasonably be made. 627 16. IANA Considerations 629 This document has no actions for IANA. 631 17. References 633 17.1. Informative References 635 [RFC1035] Mockapetris, P., "Domain names - implementation and 636 specification", STD 13, RFC 1035, November 1987. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 642 and M. Carney, "Dynamic Host Configuration Protocol for 643 IPv6 (DHCPv6)", RFC 3315, July 2003. 645 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 646 Protocol (DHCPv6) Options for Session Initiation Protocol 647 (SIP) Servers", RFC 3319, July 2003. 649 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 650 Host Configuration Protocol (DHCP) version 6", RFC 3633, 651 December 2003. 653 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 654 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 655 December 2003. 657 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 658 Configuration Options for Dynamic Host Configuration 659 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 661 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 662 RFC 3972, March 2005. 664 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 665 Configuration Option for DHCPv6", RFC 4075, May 2005. 667 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 668 Time Option for Dynamic Host Configuration Protocol for 669 IPv6 (DHCPv6)", RFC 4242, November 2005. 671 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 672 Configuration Protocol (DHCP) Options for Broadcast and 673 Multicast Control Servers", RFC 4280, November 2005. 675 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 676 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 677 Option", RFC 4704, October 2006. 679 [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 680 Options for Network Boot", RFC 5970, September 2010. 682 [RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, 683 "Prefix Exclude Option for DHCPv6-based Prefix 684 Delegation", RFC 6603, May 2012. 686 17.2. Informative References 688 [I-D.ietf-dhc-secure-dhcpv6] 689 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 690 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 691 March 2012. 693 [I-D.ietf-softwire-4rd] 694 Despres, R., Penno, R., Lee, Y., Chen, G., and S. Jiang, 695 "IPv4 Residual Deployment via IPv6 - a unified Stateless 696 Solution (4rd)", draft-ietf-softwire-4rd-00 (work in 697 progress), May 2012. 699 [I-D.mdt-softwire-map-dhcp-option] 700 Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C. 701 Bao, "DHCPv6 Options for Mapping of Address and Port", 702 draft-mdt-softwire-map-dhcp-option-02 (work in progress), 703 January 2012. 705 Authors' Addresses 707 David W. Hankins 708 Google, Inc. 709 1600 Amphitheatre Parkway 710 Mountain View, CA 94043 711 USA 713 Email: dhankins@google.com 714 Tomasz Mrugalski 715 Internet Systems Consortium, Inc. 716 950 Charter Street 717 Redwood City, CA 94063 718 USA 720 Phone: +1 650 423 1345 721 Email: tomasz.mrugalski@gmail.com 723 Marcin Siodelski 725 Phone: 726 Email: msiodelski@gmail.com 728 Sheng Jiang 729 Huawei Technologies Co., Ltd 730 Q14, Huawei Campus, No.156 Beiqing Road 731 Hai-Dian District, Beijing, 100095 732 P.R. China 734 Email: jiangsheng@huawei.com 736 Suresh Krishnan 737 Ericsson 738 8400 Blvd Decarie 739 Town of Mount Royal, Quebec 740 Canada 742 Email: suresh.krishnan@ericsson.com