idnits 2.17.1 draft-ietf-dhc-option-guidelines-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 470: '... that clients MUST place the new opt...' RFC 2119 keyword, line 471: '... option, clients MAY include the new o...' RFC 2119 keyword, line 472: '...s they desire, and servers MAY respond...' 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 (February 24, 2009) is 5539 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 (==), 4 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 February 24, 2009 5 Intended status: Informational 6 Expires: August 28, 2009 8 Guidelines for Creating New DHCP Options 9 draft-ietf-dhc-option-guidelines-05 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 28, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document seeks to provide guidance to prospective DHCP Option 49 authors, to help them in producing option formats that are easily 50 adoptable. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. When to Use DHCP . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. General Principles . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Reusing Other Options . . . . . . . . . . . . . . . . . . . . 5 58 5. Conditional Formatting is Hard . . . . . . . . . . . . . . . . 7 59 6. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. New Formats . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. The Dangers of Sub Options . . . . . . . . . . . . . . . . . . 8 62 9. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 10. Clients Request their Options . . . . . . . . . . . . . . . . 11 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 13. Informative References . . . . . . . . . . . . . . . . . . . . 12 67 Appendix A. Background on ISC DHCP . . . . . . . . . . . . . . . 15 68 A.1. Atomic DHCP . . . . . . . . . . . . . . . . . . . . . . . 16 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 1. Introduction 73 Most protocol developers ask themselves if a protocol will work, or 74 work efficiently. These are important questions, but another less 75 frequently considered question is whether the proposed protocol 76 presents itself needless barriers to adoption by deployed software. 78 DHCPv4 [RFC2131] and DHCPv6 [RFC3315] software implementors are not 79 merely faced with the task of a given option's format on the wire. 80 The option must "fit" into every stage of the system's process, which 81 includes user interface considerations. To help understand the 82 potential implementation challenges of any new DHCP Option, one 83 implementation's approach to tackling DHCP Option formats 84 (Appendix A) has been included as an Appendix. 86 Another more frequently overlooked aspect of rapid adoption is the 87 question: Would the option would require operators to be intimately 88 familiar with the option's internal format in order to make use of 89 it? Most DHCP software provides a facility for "unknown options" at 90 the time of publication to be configured by hand by an operator. But 91 if doing so requires extensive reading (more than can be covered in a 92 simple FAQ for example), it inhibits adoption. 94 So although a given solution would work, and might even be space, 95 time, or aesthetically optimal, a given option is presented with a 96 series of ever-worsening challenges to be adopted; 98 o If it doesn't fit neatly into existing config files. 100 o If it requries new source code changes to be adopted, and hence 101 upgrades of deployed software. 103 o If it does not share its deployment fate in a general manner with 104 other options, creating a pressing need for code changes, or 105 reworking configuration file syntaxes. 107 There are many things DHCP option authors can do to form DHCP Options 108 to stay off this list entirely, or failing that, to make software 109 implementors lives easier and improve its chances for widespread 110 adoption. 112 2. When to Use DHCP 114 Principally, DHCP carries configuration parameters for its clients. 115 Any knob, dial, slider, or checkbox on the client system, such as "my 116 domain name servers", "my hostname", or even "my shutdown 117 temperature" are candidates for being configured by DHCP. 119 The presence of such a knob isn't enough, because DHCP also presents 120 the extension of an administrative domain - the operator of the 121 network to which the client is currently attached. Someone runs not 122 only the local switching network infrastructure that the client is 123 directly (or wirelessly) attached to, but the various methods of 124 accessing the external Internet via local assist services that 125 network must also provide (such as domain name servers, or routers). 126 This means that in addition to the existence of a configuration 127 parameter, one must also ask themselves if it is reasonable for this 128 parameter to be set by some DHCP server operators, which roughly 129 translates to the local network administrator. 131 Bear in mind that the client still reserves the right to ignore 132 values received via DHCP (for example, due to having a value manually 133 configured by its own operator), and that at least one main use case 134 for DHCP is the corporate enterprise. So even if the local Net 135 Cafe's operator is not a likely source of the candidate 136 configuration, there may be other DHCP servers in a client's lifetime 137 which are. 139 3. General Principles 141 The primary principle to follow in order to enhance an option's 142 adoptability is certainly simplification. But more specifically, to 143 create the option in such a way that it should not require any new or 144 special case software to support. If old software currently deployed 145 and in the field can adopt the option through supplied configuration 146 conveniences then it's fairly well assured that new software can 147 easily formally adopt it. 149 There are at least two classes of DHCP options: A bulk class of 150 options which are provided explicitly to carry data from one side of 151 the DHCP exchange to the other (such as nameservers, domain names, or 152 time servers), and a protocol class of options which require special 153 processing on the part of the DHCP software or are used during 154 special processing (such as the FQDN options ([RFC4702], [RFC4704]), 155 DHCPv4 message type option [RFC2132], link selection options 156 ([RFC3011], [RFC3527]), and so forth). 158 The guidelines laid out here should be understood to be relaxed for 159 the protocol class of options. Wherever special-case-code is already 160 required to adopt the DHCP option, it is substantially more 161 reasonable to format the option in a less generic fashion, if there 162 are measurable benefits to doing so. 164 4. Reusing Other Options 166 In DHCPv4, there are now nearly one hundred and thirty options, at 167 least as IETF standards, which might be used as an example. There is 168 also one handy document [RFC2132] containing many option definitions. 170 There is a tradeoff between the adoptability of previously defined 171 option formats, and the advantages new or specialized formats can 172 provide. In the balance, it is usually preferrable to reuse 173 previously used option formats. 175 However, it isn't very practical to consider the bulk of DHCP options 176 already allocated, and consider which of those solve a similar 177 problem. So, the following list of common option format fragments is 178 provided as a shorthand. Please note that it is not complete in 179 terms of exampling every option format ever devised...it is only a 180 list of option format fragments which are used in two or more 181 options. 183 +---------------+-------+-------------------------------------------+ 184 | Fragment | Size | Types of Uses | 185 +---------------+-------+-------------------------------------------+ 186 | ipv4-address | 4 | Default gateway, requested address, | 187 | | | subnet mask [RFC2132], addresses of | 188 | | | servers ([RFC2132], [RFC2241], [RFC2242], | 189 | | | [RFC3495], [RFC3634], [RFC4174]), as a | 190 | | | component in a list of routes [RFC3442]. | 191 | ipv6-address | 16 | DHCPv6 server unicast address [RFC3315], | 192 | | | addresses of servers ([RFC3319], | 193 | | | [RFC3646], [RFC3898], [RFC4075], | 194 | | | [RFC4280]). | 195 | 32-bit | 4 | Signed or unsigned varieties. Used for | 196 | integer | | timezone time offset [RFC2132] | 197 | | | (deprecated by [RFC4833]). Other uses for | 198 | | | host configuration values such as path | 199 | | | MTU aging timeouts, ARP cache timeouts, | 200 | | | TCP keepalive intervals [RFC2132]. Also | 201 | | | used by the DHCPv4 protocol for relative | 202 | | | times, and times since epoch. | 203 | 16-bit | 2 | Client configuration parameters, such as | 204 | integer | | MTU, maximum datagram reassembly limits, | 205 | | | the DHCPv4 maximum message size | 206 | | | [RFC2132], or the elapsed time option | 207 | | | [RFC3315] in DHCPv6. | 208 | 8-bit integer | 1 | Used for host configuration parameters, | 209 | | | such as the default IP TTL, default TCP | 210 | | | TTL, NetBIOS node type [RFC2132]. Also | 211 | | | used for protocol features, such as the | 212 | | | DHCPv4 Option Overload (as flags), DHCP | 213 | | | Message Type (as an enumeration) or | 214 | | | DHCPv6 Preference [RFC3315]. | 215 | NVT-ASCII | unlim | This is the kitchen sink of common | 216 | Text | | fragments. Common uses are for filenames | 217 | | | (such as TFTP paths), host or domain | 218 | | | names (but this should be discouraged), | 219 | | | or protocol features such as textual | 220 | | | messages such as verbose error | 221 | | | indicators. Since the size of this format | 222 | | | cannot be determined (it is not NULL | 223 | | | terminated), it consumes any remaining | 224 | | | space in the option. | 225 | DNS Wire | unlim | Presently used for 'domain search' lists | 226 | Format Domain | | in both DHCPv4 [RFC3397] and DHCPv6 | 227 | Name List | | [RFC3646], but also used in DHCPv6 for | 228 | [RFC1035] | | any host or domain name. A field | 229 | | | formatted this way may have a determinate | 230 | | | length if the number of root labels is | 231 | | | limited, but use of this format as being | 232 | | | a determinate length should be | 233 | | | discouraged in DHCPv4, less so in DHCPv6. | 234 | 'suboption' | unlim | The Relay Agent Information Option | 235 | encapsulation | | [RFC3046], vendor options [RFC2132], | 236 | | | Vendor Identified Vendor SubOptions | 237 | | | ([RFC3925], [RFC3315]). Commonly used for | 238 | | | situations where the full format cannot | 239 | | | be known initially, such as where there | 240 | | | seems to be some room for later protocol | 241 | | | work to expand the amount of information | 242 | | | carried, or where the full extent of data | 243 | | | carried is defined in a private | 244 | | | specification (such as with vendor | 245 | | | options). Encapsulations do not use 'PAD' | 246 | | | and 'END' options in DHCPv4, and there | 247 | | | are no such options in DHCPv6, so this | 248 | | | format also is of indeterminate length. | 249 +---------------+-------+-------------------------------------------+ 251 Table 1: Common Option Fragments 253 The easiest approach to manufacturing trivially deployable DHCP 254 Options is to assemble the option out of whatever common fragments 255 fit - possibly allowing a group of fragments to repeat to fill the 256 remaining space (if present) and so provide multiple values. Place 257 all fixed size values at the start of the option, and any variable/ 258 indeterminate sized values at the tail end of the option. 260 This estimates that implementations will be able to reuse code paths 261 designed to support the other options. 263 5. Conditional Formatting is Hard 265 Placing a byte at the start of the option which informs the software 266 how to process the remaining bytes of the option may appear simple to 267 the casual observer. But the only conditional formatting methods 268 that are in widepsread use today are 'protocol' class options. So 269 conditional formatting requires new code to be written, as well as 270 introduces an implementation problem; as it requires that all 271 speakers implement all current and future conditional formats. 273 Conditional formatting is absolutely not recommended, except in cases 274 where the DHCP option has already been deployed, and all but one 275 conditional format is deprecated. 277 6. Avoid Aliasing 279 Options are said to be aliases of each other if they provide input to 280 the same configuration parameter. A commonly proposed example is to 281 configure the location of some new service ("my foo server") using a 282 binary IP address, a domain name field, and a URL. This kind of 283 aliasing is undesirable, and is best avoided. 285 In this case, where three different formats are supposed, it triples 286 the work of the software involved, requiring support for not merely 287 one format, but support to produce and digest all three. Since 288 clients cannot predict what values the server will provide, they must 289 request all formats...so in the case where the server is configured 290 with all formats, DHCP option space is wasted on option contents that 291 are redundant. 293 It also becomes unclear which types of values are mandatory, and how 294 configuring some of the options may influence the others. For 295 example, if an operator configures the URL only, should the server 296 synthesize a domain name and IP address? 298 A single configuration value on a host is probably presented to the 299 operator (or other software on the machine) in a single field or 300 channel. If that channel has a natural format, then any alternative 301 formats merely make more work for intervening software in providing 302 conversions. 304 So the best advice is to choose the one method that best fulfills the 305 requirements, be that for simplicity (such as with an IP address and 306 port pair), late binding (such as with DNS), or completeness (such as 307 with a URL). 309 7. New Formats 311 If the Option simply will not fit into any existing work, the last 312 recourse is to create a new format to fit. 314 When doing so, it is not enough to gauge whether or not the option 315 format will work in the context of the option presently being 316 considered. It is equally important to consider if the new format's 317 fragments might reasonably have any other uses, and if so, to create 318 the option with the foreknowledge that its parts may later become a 319 common fragment. 321 One specific consideration to evaluate, is whether or not options of 322 a similar format would need to have multiple or single values encoded 323 (whatever differs from the current option), and how that might be 324 accomplished in a similar format. 326 8. The Dangers of Sub Options 328 Some DHCP options, such as the DHCPv4 Relay Agent Information Option 329 [RFC3046] are defined to contain a series of DHCP options, possibly 330 using code tags specific to that option (but not in some limited 331 "protocol feature" cases in DHCPv6 [RFC3315]). These are commonly 332 referred to as Encapsulated Option Spaces or more simply, Sub 333 Options. 335 Sub options seem very attractive, because they allow the encoding of 336 multiple variable length fields within the single "parent" option. 337 However, DHCP software will only include these options on an "all or 338 nothing" basis, there is no well deployed mechanism for "Sub Option 339 Parameter Request Lists", and the software will not include the 340 entire option if there is not sufficient space for only the last sub- 341 option to fit in the DHCP packet. 343 Consequently, it is not advisable to group options that may not be 344 requested at the same time by the same client under an encapsulated 345 space. 347 Another attraction sub options present is ease of extending the 348 configuration value for later, related configuration. This must be 349 weighed against the cost associated with asking IANA to maintain the 350 space's internally assigned option codes. Generally, the cost to 351 IANA is greater, as it is unlikely that most options will be later 352 extended. 354 The use of sub-options is not a solution to aliasing problems. Sub- 355 options that contain multiple configuration values that alias the 356 same configuration element actually makes matters worse. The only 357 solution to aliasing problems is to select a single option format, or 358 where that is literally impossible, to use multiple DHCP options. In 359 this way, clients may place only the options they support on their 360 parameter request list, in the order they support them. Later 361 protocol maintenance may incorporate a means to select a single DHCP 362 option code out of a list of aliased options. 364 Additionaly, DHCPv4 option concatenation (described in detail below) 365 has not been defined in any DHCPv4 sub-options space. Currently 366 there is some DHCP software which does concatenate multiple DHCP 367 options present in a sub-option space. There is also software that 368 treats multiple DHCP option codes present in a sub-option as 369 individual single options. So there is no reliably predictable 370 default behaviour. 372 Because no sub-options space has yet been defined that includes the 373 possibility of having more than one instance of an option of the same 374 code, any attempt to do so is discouraged. 376 9. Option Size 378 DHCPv4 [RFC2131] options payload space is limited, as there are a 379 number of unaddressed deployment problems with DHCPv4 packet sizes. 380 The end result is that you should build your option to the assumption 381 that the packet will be no larger than 576 bytes. This means that 382 the options payload space will be 312 bytes, which you will have to 383 share with other options. This space can be extended by making use 384 of Option Overloading [RFC2132], which allows the use of the BOOTP 385 FILE and SNAME header fields for carrying DHCPv4 options (adding 192 386 bytes), but these header fields will not be available for overloading 387 if they have been configured to carry a value. 389 DHCPv6 [RFC3315] is much better off. First, through its use of link- 390 local addresses, it steps aside many of the deployment problems that 391 plague DHCPv4, and looks a great deal more like any other UDP based 392 application; oblivious to packet sizes up to 64KB. Second, RFC3315 393 explicitly refers readers to RFC2460 Section 5, which describes an 394 MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. 396 It's much more feasible to suggest that DHCPv6 is capable of having 397 larger options deployed over it, and at least no common upper limit 398 is yet known to have been encoded by its implementors. It is 399 impossible to describe any fixed limit that cleanly divides those too 400 big from the workable. 402 So in either protocol, it is advantageous to prefer option formats 403 which contain the desired information in the smallest form factor 404 that solves the requirements. One example is to use a 4-octet IPv4 405 address rather than a fully qualified domain name, because many DHCP 406 servers will perform DNS resolution on configured FQDN's (so the DNS 407 recursive lookup is performed anyway). There may be motivations to 408 use the fully qualified domain name anyway, such as if the intended 409 RRSET is not an address, or if the client must refresh the name more 410 frequently than common lease renewal periods. 412 When it is not possible to compress the configuration contents either 413 because of the simple size of the parameters, or because it is 414 expected that very large configurations are valid, it may be 415 preferrable to use a second stage configuration. Some examples of 416 this are to provide TFTP server and pathnames, or a URL, which the 417 client will load and process externally to the DHCP protocol. 419 The DHCPv4 code and length tags are each a single byte. As the 420 length field describes the length of the DHCP option's contents (not 421 including the code and length bytes), any option whose contents' 422 length exceeds 255 bytes can not be contained in a single option. 423 These 'long options' will simply be fragmented into multiple options 424 within the packet. DHCP software processing these fragments will 425 concatenate them, in the order they appear as defined by RFC2131 426 [RFC2131], prior to evaluating their contents. This is an important 427 distinction that is sometimes overlooked by authors - these multiple 428 options are not individually formatted precisely as you have defined, 429 but rather one option that has been split along any arbitrary point 430 into multiple containers. When documenting an example, then, try to 431 make sure that the division point you select as an example does not 432 lie on a clean division of your option contents - place it at an 433 offset so as to reinforce that these values must be concatenated 434 rather than processed individually. 436 DHCPv4 option fragments are a basic protocol feature, so there 437 usually is no reason to mention this feature in new option 438 definitions, and no requirement for every option definition to be 439 presented as a series of fragments. It is only recommended to 440 reinforce the existence of DHCP option fragmentation when the 441 potential for large options is likely. In this case, try to choose a 442 large example data value. 444 Note that option fragmentation is also a very common side-effect of 445 running out of options space, and moving to overloaded FILE or SNAME 446 fields. Although the option may be considerably shorter than 255 447 bytes, if it does not fit in the remaining space then software may 448 consume all remaining options space with one option fragment, and 449 place the remainder in an overloaded field. 451 10. Clients Request their Options 453 The DHCPv4 Parameter Request List [RFC2132], and the DHCPv6 Option 454 Request Option (OPTION_ORO) [RFC3315], are both options that serve 455 two purposes - to inform the server what option(s) the client 456 supports and is willing to digest, and in what order of priority the 457 client places those option contents (in the event that they will not 458 fit in the packet, later options are to be dropped). 460 It doesn't make sense for some options to appear on this parameter 461 request list, such as those formed by elements of the protocol's 462 internal workings, or are formed on either end by DHCP-level software 463 engaged in some exchange of information. When in any form of doubt, 464 assume that any new option must be present on the relevant option 465 request list if the client desires it. 467 It is a frequent mistake of option draft authors, then, to create 468 text that implies that a server will simply provide the new option, 469 and clients will digest it. Generally, it's best to also specify 470 that clients MUST place the new option code on the relevant list 471 option, clients MAY include the new option in their packets to 472 servers with hints as to values they desire, and servers MAY respond 473 with the option contents (if they have been so configured). 475 Under only the most dire of circumstances should a new option 476 definition require special ordering of options either in the relevant 477 request option, or in the order of options within the packet. 478 Although the request option does imply a priority, which might be 479 processed in order, a server may shuffle options around in a DHCPv4 480 packet in order to make them fit, and server software may sort DHCPv6 481 options into strange orders. There is not one universal approach. 483 11. Security Considerations 485 DHCP does have an Authentication mechanism ([RFC3118], [RFC3315], 486 [RFC4030]), where it is possible for DHCP software to discriminate 487 between authentic endpoints and men in the middle. 489 However, at this date the mechanism is poorly deployed. It also does 490 not provide end-to-end encryption. 492 So, while creating a new option, bear in mind that DHCP packet 493 contents are always transmitted in the clear, and actual production 494 use of the software will probably be vulnerable at least to man-in- 495 the-middle attacks from within the network, even where the network 496 itself is protected from external attacks by firewalls. In 497 particular, some DHCP message exchanges are transmitted to broadcast 498 or multicast addresses that are likely broadcast anyway. 500 If an option is of a specific fixed length, it is useful to remind 501 the implementer of the option data's full length. This is easily 502 done by declaring the specific value of the 'length' tag of the 503 option. This helps to gently remind implementers to validate option 504 length before digesting them into likewise fixed length regions of 505 memory or stack. 507 If an option may be of variable size (such as having indeterminate 508 length fields, such as domain names or text strings), it is advisable 509 to explicitly remind the implementor to be aware of the potential for 510 long options. Either define a reasonable upper limit (and suggest 511 validating it), or explicitly remind the implementor that an option 512 may be exceptionally long (to be prepared to handle errors rather 513 than truncate values). 515 For some option contents, "insane values" may be used to breach 516 security. An IP address field might be made to carry a loopback 517 address, or local broadcast address, and depending on the protocol 518 this may lead to undesirable results. A domain name field may be 519 filled with contrived contents that exceed the limitations placed 520 upon domain name formatting...as this value is possibly delivered to 521 "internal configuration" records of the system, it may be trusted, 522 rather than validated. 524 So it behooves an option's definition to contain any validation 525 measures as can reasonably be made. 527 12. IANA Considerations 529 This document has no actions for IANA. 531 13. Informative References 533 [RFC1035] Mockapetris, P., "Domain names - implementation and 534 specification", STD 13, RFC 1035, November 1987. 536 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 537 RFC 2131, March 1997. 539 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 540 Extensions", RFC 2132, March 1997. 542 [RFC2241] Provan, D., "DHCP Options for Novell Directory Services", 543 RFC 2241, November 1997. 545 [RFC2242] Droms, R. and K. Fong, "NetWare/IP Domain Name and 546 Information", RFC 2242, November 1997. 548 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 549 RFC 3011, November 2000. 551 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 552 RFC 3046, January 2001. 554 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 555 Messages", RFC 3118, June 2001. 557 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 558 and M. Carney, "Dynamic Host Configuration Protocol for 559 IPv6 (DHCPv6)", RFC 3315, July 2003. 561 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 562 Protocol (DHCPv6) Options for Session Initiation Protocol 563 (SIP) Servers", RFC 3319, July 2003. 565 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 566 Protocol (DHCP) Domain Search Option", RFC 3397, 567 November 2002. 569 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 570 Static Route Option for Dynamic Host Configuration 571 Protocol (DHCP) version 4", RFC 3442, December 2002. 573 [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration 574 Protocol (DHCP) Option for CableLabs Client 575 Configuration", RFC 3495, March 2003. 577 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 578 "Link Selection sub-option for the Relay Agent Information 579 Option for DHCPv4", RFC 3527, April 2003. 581 [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, 582 "Key Distribution Center (KDC) Server Address Sub-option 583 for the Dynamic Host Configuration Protocol (DHCP) 584 CableLabs Client Configuration (CCC) Option", RFC 3634, 585 December 2003. 587 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 588 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 589 December 2003. 591 [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) 592 Configuration Options for Dynamic Host Configuration 593 Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. 595 [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for 596 Dynamic Host Configuration Protocol version 4 (DHCPv4)", 597 RFC 3925, October 2004. 599 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 600 Protocol version 4 (DHCPv4) Options", RFC 3942, 601 November 2004. 603 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 604 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 605 Option", RFC 4030, March 2005. 607 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 608 Configuration Option for DHCPv6", RFC 4075, May 2005. 610 [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic 611 Host Configuration Protocol (DHCP) Option for the Internet 612 Storage Name Service", RFC 4174, September 2005. 614 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 615 Configuration Protocol (DHCP) Options for Broadcast and 616 Multicast Control Servers", RFC 4280, November 2005. 618 [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host 619 Configuration Protocol (DHCP) Client Fully Qualified 620 Domain Name (FQDN) Option", RFC 4702, October 2006. 622 [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for 623 IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) 624 Option", RFC 4704, October 2006. 626 [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", 627 RFC 4833, April 2007. 629 Appendix A. Background on ISC DHCP 631 The ISC DHCP software package was mostly written by Ted Lemon in 632 cooperation with Nominum, Inc. Since then, it has been given to 633 Internet Systems Consortium, Inc. ("ISC") where it has been 634 maintained in the public interest by contributors and ISC employees. 636 It includes a DHCP Server, Relay, and Client implementation, with a 637 common library of DHCP protocol handling procedures. 639 The DHCP Client may be found on some Linux distributions, and FreeBSD 640 5 and earlier. Variations ("Forks") of older versions of the client 641 may be found on several BSDs, including FreeBSD 6 and later. 643 The DHCP Server implementation is known to be in wide use by many 644 Unix-based servers, and comes pre-installed on most Linux 645 distributions. 647 The ISC DHCP Software Suite has to allow: 649 o Administrators to configure arbitrary DHCP Option Wire Formats for 650 options that either were not published at the time the software 651 released, or are of the System Administrator's invention (such as 652 'Site-Local' [RFC3942] options), or finally were of Vendor design 653 (Vendor Encapsulated Options [RFC2132] or similar). 655 o Pre-defined names and formats of options allocated by IANA and 656 defined by the IETF Standards body. 658 o Applications deriving their configuration parameters from values 659 provided by these options to receive and understand their content. 660 Often, the binary format on the wire is not helpful or digestable 661 by, for example, 'ifconfig' or '/etc/resolv.conf'. 663 So, one can imagine that this would require a number of software 664 functions: 666 1. To read operator-written configuration value into memory. 668 2. To write the in-memory representation into protocol wire format. 670 3. To read the protocol wire format into memory. 672 4. To write the in-memory format to persistent storage (to cache 673 across reboots for example). 675 5. To write the in-memory format to a format that can be consumed by 676 applications. 678 If every option were formatted differently and uniquely, then we 679 would have to write 5 functions for every option. As there is the 680 potential for as many as 254 DHCPv4 options, or 65536 DHCPv6 options, 681 not to mention the various encapsulated spaces ("suboptions"), this 682 is not scalable. 684 One simple trick is to make the in-memory format the same as the wire 685 format. This reduces the number of functions required from 5 to 3. 686 This is not always workable - sometimes an intermediate format is 687 required, but it is a good general case. 689 Another simple trick is to use the same (or very nearly the same) 690 format for persistent storage as is used to convey parameters to 691 applications. This reduces the number of functions again from 3 to 692 2. 694 This is still an intractable number of functions per each DHCP 695 option, even without the entire DHCP option space populated. So, we 696 need a way to reduce this to small orders. 698 A.1. Atomic DHCP 700 To accomplish these goals, a common "Format String" is used to 701 describe, in abstract, all of the above. Each byte in this format 702 string represents a "DHCP Atom". We chain these 'atoms' together, 703 forming a sort of molecular structure for a particular DHCP Option. 705 The Configuration Syntax allows the user to construct such a format 706 string without having to understand how the Atom is encoded on the 707 wire, and how it is configured or presented. 709 You can reasonably imagine that the various common formats of DHCP 710 options described above (Table 1) each have an Atom associated with 711 it. There are special use Atoms, such as one to repeat the previous 712 Atoms indefinitely (for example, for options with multiple IPv4 713 addresses one after the other), and one which makes the previous Atom 714 optional. 716 As the software encounters a format string, it processes each Atom 717 individually to read, formulate in memory, or write to output the 718 various option contents. 720 The format strings themselves are either hard coded by the software 721 in a table of option definitions, or are compiled at runtime through 722 configuration syntax generated by the operator. 724 option .