idnits 2.17.1 draft-ietf-dhc-option-guidelines-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 715. 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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 396: '... that clients MUST place the new opt...' RFC 2119 keyword, line 397: '... option, clients MAY include the new o...' RFC 2119 keyword, line 398: '...s they desire, and servers MAY respond...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 21, 2008) is 5698 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dynamic Host Configuration Working D. Hankins 3 Group ISC 4 Internet-Draft August 21, 2008 5 Intended status: Informational 6 Expires: February 22, 2009 8 Guidelines for Creating New DHCP Options 9 draft-ietf-dhc-option-guidelines-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 22, 2009. 36 Abstract 38 This document seeks to provide guidance to prospective DHCP Option 39 authors, to help them in producing option formats that are easily 40 adoptable. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3 46 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 47 4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 4 48 5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7 49 6. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 50 7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 51 8. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 9. Clients Request their Options . . . . . . . . . . . . . . . . 9 53 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 54 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 55 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 11 56 Appendix A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . 12 57 12. Informative References . . . . . . . . . . . . . . . . . . . . 13 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 59 Intellectual Property and Copyright Statements . . . . . . . . . . 17 61 1. Introduction 63 Most protocol developers ask themselves if a protocol will work, or 64 work efficiently. These are important questions, but another less 65 frequently considered is whether the proposed protocol presents 66 itself needless barriers to adoption by deployed software. 68 DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not 69 merely faced with the task of a given option's format on the wire. 70 The option must 'fit' into every stage of the system's process, which 71 includes user interface considerations. As an aide to understanding 72 the potential implementation challenges of any new DHCP Option, one 73 implementation's approach to tackling DHCP Option formats 74 (Appendix A) has been included in an Appendix. 76 Another, and more frequently overlooked, aspect of rapid adoption is 77 whether or not the option would require operators to be intimately 78 familiar with the option's internal format in order to make use of 79 it. Most DHCP software provides a facility for "unknown options" at 80 the time of publication to be configured by hand by an operator. But 81 if doing so requires extensive reading (more than can be covered in a 82 simple FAQ for example), it inhibits adoption. 84 So although a given solution would work, and might even be space, 85 time, or aesthetically optimal, a given option is going to have a 86 rough time being adopted by deployed software if it requires code 87 changes. A rougher time still, if it does not share its deployment 88 fate in a general manner with other options of pressing need. 90 There are many things DHCP option authors can do to form DHCP Options 91 to make software implementors lives easier, and improve the chances 92 that the Option is formally adopted in deployed software after it has 93 been assigned an Option Code. 95 2. When to Use DHCP 97 Principally, DHCP carries configuration parameters for its clients. 98 Any knob, dial, slider, or checkbox on the client system, such as "my 99 domain name servers", "my hostname", or even "my shutdown 100 temperature" are candidates for being configured by DHCP. 102 The presence of such a knob isn't enough, however, because 103 secondarily, DHCP also presents the extension of an administrative 104 domain - that of the systems operator of the network to which the 105 client is currently attached. Someone runs not only the local 106 switching network infrastructure that the client is directly (or 107 wirelessly) attached to, but the various methods of accessing the 108 external Internet via local assist services that network must also 109 provide (such as domain name servers, or routers). This means that 110 in addition to the existence of a configuration parameter, one must 111 also ask themselves if it is reasoanble for this parameter to be set 112 by the DHCP server operator. 114 Bear in mind that the client still reserves the right to over-ride or 115 ignore values received via DHCP (for example, due to having a 116 manually configured value by its operator), and that at least one 117 main use case for DHCP is the corporate enterprise - so even if the 118 local Net Cafe is not a suitable source of this configuration, it is 119 likely that the client will at some point return to a network whose 120 operator is also the system's rightful master. 122 3. General Principles 124 The primary principle to follow in order to enhance an option's 125 adoptability is certainly simplification. But more specifically, to 126 create the option in such a way that it should not require any new or 127 special case software to support. If old software currently deployed 128 and in the field can adopt the option through supplied configuration 129 conveniences then it's fairly well assured that new software can 130 easily formally adopt it. 132 There are at least two classes of DHCP options. A bulk class of 133 options which are provided explicitly to carry data from one side of 134 the DHCP exchange to the other (such as nameservers, domain names, or 135 time servers), and a protocol class of options which require special 136 processing on the part of the DHCP software or are used during 137 special processing (such as the FQDN options ([RFC4702], [RFC4704]), 138 DHCPv4 message type option [RFC2132], link selection options 139 ([RFC3011], [RFC3527]), and so forth). 141 The guidelines laid out here should be understood to be relaxed for 142 the protocol class of options. Wherever special-case-code is already 143 required to adopt the DHCP option, it is substantially more 144 reasonable to format the option in a less generic fashion, if there 145 are measurable benefits to doing so. 147 4. Reusing Other Options 149 In DHCPv4, there are now nearly one hundred and thirty options, at 150 least as IETF standards, which might be used as an example. There is 151 also one handy document [RFC2132] containing many option definitions. 153 Although some may not like the way an old option that solves a 154 similar problem was approached, and it may waste space or processing 155 time or have ugly characteristics, it can usually be said that 156 duplicating that which has already been adopted has the greatest 157 chance of being adopted quickly and easily. 159 So it is preferrable to consider the bulk of DHCP options already 160 allocated, and consider which of those solve a similar problem. It 161 may even be that an option that solves the problem already exists. 163 But as there are so many options to choose from, this isn't entirely 164 practical. So, the following list of common option formats is 165 provided as a shorthand. Please note that it is not complete in 166 terms of exampling every option format ever devised...it is only a 167 list of option format fragments which are used in two or more 168 options. 170 Common Option Fragments 172 +---------------+-------+-------------------------------------------+ 173 | Fragment | Size | Types of Uses | 174 +---------------+-------+-------------------------------------------+ 175 | ipv4-address | 4 | Default gateway, requested address, | 176 | | | subnet mask [RFC2132], addresses of | 177 | | | servers ([RFC2132], [RFC2241], [RFC2242], | 178 | | | [RFC3495], [RFC3634], [RFC4174]), as a | 179 | | | component in a list of routes [RFC3442]. | 180 | ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], | 181 | | | addresses of servers ([RFC3319], | 182 | | | [RFC3646], [RFC3898], [RFC4075], | 183 | | | [RFC4280]). | 184 | 32-bit | 4 | Signed or unsigned varieties. Deprecated | 185 | integer | | [RFC4833] use for timezone time offset | 186 | | | [RFC2132]. Other uses for host | 187 | | | configuration values such as path mtu | 188 | | | aging timeouts, arp cache timeouts, tcp | 189 | | | keepalive intervals [RFC2132]. Also used | 190 | | | by the DHCPv4 protocol for relative | 191 | | | times, and times since epoch. | 192 | 16-bit | 2 | Client configuration parameters, such as | 193 | integer | | MTU, maximum datagram reassembly limits, | 194 | | | the DHCPv4 maximum message size | 195 | | | [RFC2132], or the elapsed time option | 196 | | | [RFC3315] in DHCPv6. | 197 | 8-bit integer | 1 | Used for host configuration parameters, | 198 | | | such as the default IP TTL, default TCP | 199 | | | TTL, NetBIOS node type [RFC2132]. Also | 200 | | | used for protocol features, such as the | 201 | | | DHCPv4 Option Overload (as flags), DHCP | 202 | | | Message Type (as an enumeration) or | 203 | | | DHCPv6 Preference [RFC3315]. | 204 | NVT-Ascii | unlim | This is the kitchen sink of common | 205 | Text | | fragments. Common uses are for filenames | 206 | | | (such as TFTP paths), host or domain | 207 | | | names (but this should be discouraged), | 208 | | | or protocol features such as textual | 209 | | | messages such as verbose error | 210 | | | indicators. Since the size of this format | 211 | | | cannot be determined (it is not NULL | 212 | | | terminated), it consumes any remaining | 213 | | | space in the option. | 214 | DNS Wire | unlim | Presently used for 'domain search' lists | 215 | Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 | 216 | Name List | | [RFC3646], but also used in DHCPv6 for | 217 | [RFC1035] | | any host or domain name. A field | 218 | | | formatted this way may have a determinate | 219 | | | length if the number of root labels is | 220 | | | limited, but use of this format as being | 221 | | | a determinate length should be | 222 | | | discouraged in DHCPv4, less so in DHCPv6. | 223 | 'suboption' | unlim | The Relay Agent Information Option | 224 | encapsulation | | [RFC3046], vendor options [RFC2132], | 225 | | | Vendor Identified Vendor SubOptions | 226 | | | ([RFC3925], [RFC3315]). Commonly used for | 227 | | | situations where the full format cannot | 228 | | | be known initially, such as where there | 229 | | | seems to be some room for later protocol | 230 | | | work to expand the amount of information | 231 | | | carried, or where the full extent of data | 232 | | | carried is defined in a private | 233 | | | specification (such as with vendor | 234 | | | options). Encapsulations do not use 'PAD' | 235 | | | and 'END' options in DHCPv4, and there | 236 | | | are no such options in DHCPv6, so this | 237 | | | format also is of indeterminate length. | 238 +---------------+-------+-------------------------------------------+ 240 Table 1 242 One approach to manufacturing simple DHCP Options is to assemble the 243 option out of whatever common fragments fit - possibly allowing one 244 or more fragments to repeat to fill the remaining space (if present) 245 and so provide multiple values. Place all fixed size values at the 246 start of the option, and any variable/indeterminate sized values at 247 the tail end of the option. If there are more than one variable/ 248 indeterminate length values, consider the use of multiple options or 249 suboptions. 251 This estimates that implementations will be able to reuse code paths 252 designed to support the other options. 254 5. Conditional Formatting is Hard 256 Placing a byte at the start of the option which informs the software 257 how to process the remaining bytes of the option may appear simple to 258 the casual observer. But there are no such conditional formatting 259 methods in existence today, so it must therefore require new, special 260 case code, be written for this purpose. 262 Wherever possible, used fixed length buffers to carry the information 263 desired. Obviously, this becomes less possible as the fixed length 264 buffer approaches large sizes, at least in DHCPv4, where DHCP packet 265 space is limited. 267 6. Aliasing 269 Providing multiple different formats of the same configuration 270 information, such as an IP address, name, or URL, which are all 271 intended to provide the same location information, is undesirable. 273 In this case, where three different formats are supposed, it triples 274 the work of the software involved, requiring support for not merely 275 one format, but support to produce and digest all three. Since 276 clients cannot predict what values the server will provide, they must 277 request all formats...so in the case where the server is configured 278 with all formats, DHCP option space is wasted on option contents that 279 are redundant. 281 It also becomes unclear which types of values are mandatory, and how 282 configuring some of the options may influence the others. For 283 example, if an operator configures the URL only, should the server 284 synthesize a domain name and ip address? 286 A single configuration value on a host is probably presented to the 287 operator (or other software on the machine) in a single field or 288 channel. If that channel has a natural format, then any alternative 289 formats merely make more work for intervening software in providing 290 conversions. 292 So the best advice is to choose the one method that best fulfills the 293 requirements, be that for simplicity (such as with an ip address), 294 late binding (such as with DNS), or completeness (such as with a 295 URL). 297 7. New Formats 299 If the Option simply will not fit into any existing work, the last 300 recourse is to contrive a new format to fit. 302 When doing so, it is not enough to gauge whether or not the option 303 format will work in the context of the option presently being 304 considered. It is equally important to consider if the new format 305 might reasonably have any other uses, and if so, to create the option 306 with the foreknowledge that it may later become a common fragment. 308 One specific consideration to evaluate, is whether or not options of 309 a similar format would need to have multiple or single values encoded 310 (whatever differs from the current option), and how that might be 311 accomplished in a similar format. 313 8. Option Size 315 DHCPv4 [RFC2131] options payload space is limited, as there are a 316 number of unaddressed deployment problems with DHCPv4 packet sizes. 317 The end result is that you should build your option to the assumption 318 that the packet will be no larger than 576 bytes. This means that 319 the options payload space will be 312 bytes, which you will have to 320 share with other options. This space can be extended by making use 321 of Option Overloading [RFC2132], which allows the use of the BOOTP 322 FILE and SNAME header fields for carrying DHCPv4 options (adding 192 323 bytes), but these header fields will not be available for overloading 324 if they have been configured to carry a value. 326 DHCPv6 [RFC3315] carries a much more relaxed restriction, as it 327 appears ready and able to accept packet sizes up to 64KB, putting 328 options payload space at very nearly the same number (there are very 329 few, and small, header fields). But it is still undesirable to 330 produce fragments, and it's still very possible that the client's MTU 331 is not very large (or that client software is not prepared to retain 332 a 64KB buffer). So it is still best advice to design options to a 333 ~500 byte payload limitation. 335 This is easily accomplished by preferring option formats which 336 contain the desired information in the smallest form factor, in the 337 absence of other motivations. One example is to use a 4-octet IPv4 338 address rather than a fully qualified domain name. There may be 339 motivations to use the fully qualified domain name anyway, such as 340 externally supplied load balancers, or other protocol features. 342 When it is not possible to compress the configuration contents either 343 because of the number of optional parameters that must be identified, 344 or because it is expected that very large configurations are valid, 345 it may be preferrable to use a second stage configuration. Some 346 examples of this are to provide TFTP server and pathnames, or a URL, 347 which the client will load and process externally to the DHCP 348 protocol. 350 In the case where a DHCPv4 option may, or will, exceed 255 bytes in 351 length (and thus exceed the 'length' field's ability to contain it), 352 a DHCPv4 option will simply be fragmented into multiple options 353 within the packet. DHCP software processing these fragments will 354 concatenate them, in the order they appear as defined by RFC2131 355 [RFC2131], prior to evaluating their contents. This is an important 356 distinction that is sometimes overlooked by authors - these multiple 357 options do not represent multiple options formatted precisely as you 358 have defined, but rather one option that has been split along any 359 arbitrary point into multiple containers. When documenting an 360 example, then, try to make sure that the division point you select as 361 an example does not lie on a clean division of your option contents - 362 place it at an offset so as to reinforce that these values must be 363 concatenated rather than processed individually. 365 DHCPv4 option fragments are a basic protocol feature, so there 366 usually is no reason to mention this feature in new option 367 definitions, unless of course the option is very likely to exceed 255 368 bytes, or the documented example(s) are this big. 370 Note that option fragmentation is also a very common side-effect of 371 running out of options space, and moving to overloaded FILE or SNAME 372 fields. Although the option may be considerably shorter than 255 373 bytes, if it does not fit in the remaining space then software may 374 consume all remaining options space with one option fragment, and 375 place the remainder in an overloaded field. 377 9. Clients Request their Options 379 In both DHCP protocols, there exists as part of the protocol 380 definition an option whose purpose is twofold - to inform the server 381 what option(s) the client supports and is willing to digest, and in 382 what order of priority the client places those option contents (in 383 the event that they will not fit in the packet, later options are to 384 be dropped). 386 It doesn't make sense for some options to appear on this parameter 387 request list, such as those are formed by elements of the protocol's 388 internal workings, or are formed on either end by DHCP-level software 389 engaged in some exchange of information. When in any form of doubt, 390 assume that any new option must be present on the relevant option 391 request list if the client desires it. 393 It is a frequent mistake of option draft authors, then, to create 394 text that implies that a server will simply provide the new option, 395 and clients will digest it. Generally, it's best to also specify 396 that clients MUST place the new option code on the relevant list 397 option, clients MAY include the new option in their packets to 398 servers with hints as to values they desire, and servers MAY respond 399 with the option contents if they have been so configured. 401 10. Security Considerations 403 DHCP does have an Authentication mechanism ([RFC3118], [RFC3315], 404 [RFC4030]), where it is possible for DHCP software to discriminate 405 between authentic endpoints and men in the middle. 407 However, at this date the mechanism is poorly deployed. It also does 408 not provide end-to-end encryption. 410 So, while creating a new option, bear in mind that DHCP packet 411 contents are always transmitted in the clear, and actual production 412 use of the software will probably be vulnerable at least to men in 413 the middle attacks from within the network, even where the network 414 itself is protected from external attacks by firewalls. In 415 particular, some DHCP message exchanges are transmitted to broadcast 416 or multicast addresses that are likely broadcast anyway. 418 If an option is of a specific fixed length, it is useful to remind 419 the implementer of the option data's full length. This is easily 420 done by declaring the specific value of the 'length' tag of the 421 option. This helps to gently remind implementers to validate option 422 length before digesting them into likewise fixed length regions of 423 memory or stack. 425 If an option may be of variable size (such as having indeterminate 426 length fields, such as domain names or text strings), it is advisable 427 to explicitly remind the implementor to be aware of the potential for 428 long options. Either by defining a reasonable upper limit, or 429 explicitly reminding the implementor that an option may be 430 exceptionally long. 432 For some option contents, "insane values" may be used to breach 433 security. An IP address field might be made to carry a loopback 434 address, or local broadcast address, and depending on the protocol 435 this may lead to undesirable results. A domain name field may be 436 filled with contrived contents that exceed the limitations placed 437 upon domain name formatting...as this value is possibly delivered to 438 "internal configuration" records of the system, it may be trusted, 439 rather than validated. 441 So it behooves an option's definition to contain any validation 442 measures as can reasonably be made. 444 11. IANA Considerations 446 This document has no actions for IANA. 448 Appendix A. Background on ISC DHCP 450 The ISC DHCP software package was mostly written by Ted Lemon in 451 cooperation with Nominum, Inc. Since then, it has been given to 452 Internet Systems Consortium, Inc. ("ISC") where it has been 453 maintained in the public interest by contributors and ISC employees. 455 It includes a DHCP Server, Relay, and Client implementation, with a 456 common library of DHCP protocol handling procedures. 458 The DHCP Client may be found on some Linux distributions, and FreeBSD 459 5 and earlier. Variations ("Forks") of older versions of the client 460 may be found on several BSDs, including FreeBSD 6 and later. 462 The DHCP Server implementation is known to be in wide use by many 463 Unix-based servers, and comes pre-installed on most Linux 464 distributions. 466 The ISC DHCP Software Suite has to allow: 468 o Administrators to configure arbitrary DHCP Option Wire Formats for 469 options that either were not published at the time the software 470 released, or are of the System Administrator's invention (such as 471 'Site-Local' [RFC3942] options), or finally were of Vendor design 472 (Vendor Encapsulated Options [RFC2132] or similar). 474 o Pre-defined names and formats of options allocated by IANA and 475 defined by the IETF Standards body. 477 o Applications deriving their configuration parameters from values 478 provided by these options to receive and understand their content. 480 Often, the binary format on the wire is not helpful or digestable 481 by, for example, 'ifconfig' or '/etc/resolv.conf'. 483 So, one can imagine that this would require a number of software 484 functions: 486 1. To read operator-written configuration value into memory. 488 2. To write the in-memory representation into protocol wire format. 490 3. To read the protocol wire format into memory. 492 4. To write the in-memory format to persistent storage (to cache 493 across reboots for example). 495 5. To write the in-memory format to a format that can be consumed by 496 applications. 498 If every option were formatted differently and uniquely, then we 499 would have to write 6 functions for every option. As there is the 500 potential for as many as 254 DHCPv4 options, or 65536 DHCPv6 options, 501 not to mention the various encapsulated spaces ("suboptions"), this 502 is not scalable. 504 One simple trick is to make the in-memory format the same as the wire 505 format. This reduces the number of functions required from 5 to 4. 506 This is not always workable - sometimes an intermediary format is 507 required, but it is a good general case. 509 Another simple trick is to use the same (or very nearly the same) 510 format for persistent storage as is used to convey parameters to 511 applications. This reduces the number of functions again from 4 to 512 3. 514 This is still an intractable number of functions per each DHCP 515 option. So, we need a way to reduce this to small orders. 517 Appendix A.1. Atomic DHCP 519 To accomplish these goals, a common "Format String" is used to 520 describe, in abstract, all of the above. Each byte in this format 521 string represents a "DHCP Atom". We chain these 'atoms' together, 522 forming a sort of molecular structure for a particular DHCP Option. 524 Configuration Syntax language allows the user to construct such a 525 format string without having to understand how the Atom is encoded on 526 the wire, and how it is configured or presented. 528 You can reasonably imagine that the various common formats of DHCP 529 options described above (Table 1) each have an Atom associated with 530 it. There are special use Atoms, such as one to repeat the previous 531 Atoms indefinitely (for example, for options with multiple IPv4 532 addresses one after the other), and one which makes the previous Atom 533 optional. 535 As the software encounters a format string, it processes each Atom 536 individually to read, formulate in memory, or write to output the 537 various option contents. 539 The format strings themselves are either hard coded by the software 540 in a table of option definitions, or are compiled at runtime through 541 configuration syntax generated by the operator. 543 option [space].[option] code [number] = [definition]; 545 The "space" refers to the option space, which may be the DHCPv4 546 option space, the DHCPv6 option space, or any suboption space such as 547 the DHCPv4 Relay Agent Information suboptions or similar. 549 The "option" refers to the option's symbolic name within that space. 551 The code number refers to the binary code assigned to this option. 553 The definition is a complex statement that brings together DHCP 554 Atoms, many of which are the aforementioned common formats, that 555 compose this option. For example, here are two predefined options, 556 as they might have been configured for use by an operator if the 557 software did not already support them. 559 option dhcp.path-mtu-plateau-table code 25 = 560 array of unsigned integer 16; 561 option dhcp.static-routes code 33 = array of { ip-address, 562 ip-address }; 564 option dhcp.path-mtu-plataeu-table 4352, 1500, 576; 565 option dhcp.static-routes 10.10.10.10 10.10.10.9, 566 10.10.10.11 10.10.10.9; 568 12. Informative References 570 [RFC1035] Mockapetris, P., "Domain names - implementation and 571 specification", STD 13, RFC 1035, November 1987. 573 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 574 RFC 2131, March 1997. 576 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 577 Extensions", RFC 2132, March 1997. 579 [RFC2241] Provan, D., "DHCP Options for Novell Directory Services", 580 RFC 2241, November 1997. 582 [RFC2242] Droms, R. and K. Fong, "NetWare/IP Domain Name and 583 Information", RFC 2242, November 1997. 585 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 586 RFC 3011, November 2000. 588 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 589 RFC 3046, January 2001. 591 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 592 Messages", RFC 3118, June 2001. 594 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 595 and M. Carney, "Dynamic Host Configuration Protocol for 596 IPv6 (DHCPv6)", RFC 3315, July 2003. 598 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 599 Protocol (DHCPv6) Options for Session Initiation Protocol 600 (SIP) Servers", RFC 3319, July 2003. 602 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 603 Protocol (DHCP) Domain Search Option", RFC 3397, 604 November 2002. 606 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 607 Static Route Option for Dynamic Host Configuration 608 Protocol (DHCP) version 4", RFC 3442, December 2002. 610 [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration 611 Protocol (DHCP) Option for CableLabs Client 612 Configuration", RFC 3495, March 2003. 614 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 615 "Link Selection sub-option for the Relay Agent Information 616 Option for DHCPv4", RFC 3527, April 2003. 618 [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, 619 "Key Distribution Center (KDC) Server Address Sub-option 620 for the Dynamic Host Configuration Protocol (DHCP) 621 CableLabs Client Configuration (CCC) Option", RFC 3634, 622 December 2003. 624 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 625 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 626 December 2003. 628 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 629 Configuration Options for Dynamic Host Configuration 630 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 632 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 633 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 634 RFC 3925, October 2004. 636 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 637 Protocol version 4 (DHCPv4) Options", RFC 3942, 638 November 2004. 640 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 641 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 642 Option", RFC 4030, March 2005. 644 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 645 Configuration Option for DHCPv6", RFC 4075, May 2005. 647 [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 648 Host Configuration Protocol (DHCP) Option for the Internet 649 Storage Name Service", RFC 4174, September 2005. 651 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 652 Configuration Protocol (DHCP) Options for Broadcast and 653 Multicast Control Servers", RFC 4280, November 2005. 655 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 656 Configuration Protocol (DHCP) Client Fully Qualified 657 Domain Name (FQDN) Option", RFC 4702, October 2006. 659 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 660 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 661 Option", RFC 4704, October 2006. 663 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", 664 RFC 4833, April 2007. 666 Author's Address 668 David W. Hankins 669 Internet Systems Consortium, Inc. 670 950 Charter Street 671 Redwood City, CA 94063 672 US 674 Phone: +1 650 423 1307 675 Email: David_Hankins@isc.org 677 Full Copyright Statement 679 Copyright (C) The IETF Trust (2008). 681 This document is subject to the rights, licenses and restrictions 682 contained in BCP 78, and except as set forth therein, the authors 683 retain all their rights. 685 This document and the information contained herein are provided on an 686 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 687 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 688 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 689 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 690 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 691 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 693 Intellectual Property 695 The IETF takes no position regarding the validity or scope of any 696 Intellectual Property Rights or other rights that might be claimed to 697 pertain to the implementation or use of the technology described in 698 this document or the extent to which any license under such rights 699 might or might not be available; nor does it represent that it has 700 made any independent effort to identify any such rights. Information 701 on the procedures with respect to rights in RFC documents can be 702 found in BCP 78 and BCP 79. 704 Copies of IPR disclosures made to the IETF Secretariat and any 705 assurances of licenses to be made available, or the result of an 706 attempt made to obtain a general license or permission for the use of 707 such proprietary rights by implementers or users of this 708 specification can be obtained from the IETF on-line IPR repository at 709 http://www.ietf.org/ipr. 711 The IETF invites any interested party to bring to its attention any 712 copyrights, patents or patent applications, or other proprietary 713 rights that may cover technology that may be required to implement 714 this standard. Please address the information to the IETF at 715 ietf-ipr@ietf.org.