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