Dynamic Host Configuration Working. Internet-Draft September 2006 Expires: March 5, 2007

Transcription

1 Dynamic Host Configuration Working D. Hankins Group ISC Internet-Draft September 2006 Expires: March 5, 2007 Status of this Memo DHCP Option Processing, Explained draft-dhankins-atomic-dhcp-00 By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at The list of Internet-Draft Shadow Directories can be accessed at This Internet-Draft will expire on March 5, Copyright Notice Copyright (C) The Internet Society (2006) Abstract Most protocol developers ask themselves if a protocol will work, or work efficiently. These are important questions, but another less frequently considered is wether the proposed protocol changes present themselves barriers to adoption by deployed software (more importantly, needlessly so). This document seeks to provide information on the challenges to DHCP

2 Hankins Expires March 5, 2007 [Page 1] Option software implementers, and in doing so to provide guidance to prospective DHCP Option authors to help them produce options that are easily adoptable. Table of Contents 1. Introduction About ISC DHCP Atomic DHCP Bring in the Atoms Boolean Integers IP Addresses Text and Strings Encapsulation Domain Names Making Arrays Molecular Assembly Configuring Format Strings Illegal Combinations Legal Combinations Lessons Learned Conditional Formatting is Hard Its Probably Been Done Keep It Simple, Stupid Security Considerations Acknowledgements References Author's Address Intellectual Property and Copyright Statements

3 Hankins Expires March 5, 2007 [Page 2] 1. Introduction DHCP [1] Software Implementors are not merely faced with the task of encoding and decoding DHCP Options [2] within DHCP Packets. They must also mediate between the Systems Administrators and Option Consumers (from users to applications) to formulate and present the Option. Additionally, many Software Implementors are pressed for time, the chief component that decides how many new features can be put into software releases. There are many things you, the reader, can do to form your DHCP Options to make Software Implementors lives easier, and improve the chances that your Option is formally adopted in deployed software after it has been assigned an Option Code. In this document, the author intends to describe one Software Implementation, and how it has chosen to cope with the complexity of DHCP [1] Option Encoding, Configuration, and Consumption. In doing this, it is hoped that the reader will gain a better understanding of the challenges that might be faced by an Implementor in adopting the Options they plan to introduce. 2. About ISC DHCP The ISC DHCP software package was written by Ted Lemon. Since then, it has been taken under the wing of Internet Systems Consortium, Inc. ("ISC") where it has been maintained in the public interest by contributors and ISC employees. It includes a DHCP Server, Relay, and Client implementation, with a common library of DHCP protocol handling procedures.

4 The DHCP Client may be found on some Linux distributions, and FreeBSD 5 and earlier. Variations ("Forks") of older versions of the client may be found on several BSDs, including FreeBSD 6 and later. The DHCP Server implementation is the only one known to be in wide use by most Unix-based servers, and comes pre-installed on most Linux distributions. The Relay Agent implementation is not known to be in wide use, and even if it were, it makes no special handling of DHCP Options and so is not really a topic of this document. Hankins Expires March 5, 2007 [Page 3] 3. Atomic DHCP The ISC DHCP Software Suite has to allow: o Administrators to configure arbitrary DHCP Option Wire Formats for options that either were not published at the time the software released, or are of the System Administrator's invention (such as 'Site-Local' [3] options), or finally were of Vendor design (Vendor Encapsulated Options [2] or similar). o Pre-defined names and formats of options allocated by IANA and defined by the IETF Standards body. o Applications deriving their configuration parameters from values provided by these options to receive and understand their content. Often, the binary format on the wire is not helpful or digestable by, for example, 'ifconfig' or '/etc/resolv.conf'. To accomplish these goals, a common "Format String" is used to describe, in abstract, all of the above. Each byte in this format string is described in this document as a "DHCP Atom". You chain these 'atoms' together, forming a sort of molecular structure for a particular DHCP Option. Configuration Syntax language allows the user to construct such a format string without having to understand the meaning of each Atom, and determines both how the Atom is encoded on the wire, and how it is configured or presented.

5 As these Atoms are chained together to produce a single complex option format, the configuration and presentation of those options becomes defined by the sum of its parts. We will describe the 'Atoms' from this point of view - how they might be configured, as from scratch, and used on an ISC DHCP Server or Client Bring in the Atoms The following is a list of all of the Atoms that ISC DHCP has implemented as of this date, some in pre-release software. The author of any new option however should refer to the library of previously allocated DHCP options, per IETF RFCs, as a more accurate and up-to-date picture. We are going to describe the atoms from the point of view of a configuration file author, then individually how they will appear on the wire, and in values passed to applications or displayed to users. Hankins Expires March 5, 2007 [Page 4] In brief, all option codes are described with the following generic language: option [new_name] code [new_code] = [definition] ; Where [new_name] and [new_code] describe, respectively, how the option will be labeled in the config file, and how the option will be labeled in the DHCP wire format (the DHCP Option Code). This means that later in configuration, the administrator may configure: option [new_name] [values] ; Where the format and number of [values] are determined by the [definition] applied above. As an example then, an administrator might configure: option wpad code 252 = text ; option wpad " Site-Local Warning

6 Option Code 252 is within the 'Site-Local' [3] Option Space, and is unsuitable for use as a fixed option in released software. It is suitable only for allocation by Systems Administrators. It is provided here solely as an example of common Administrative use of this option space Boolean Boolean values are simple true/false conditions. This fits with several well known DHCP Options [2] which were intended to designate wether a given behaviour should be engaged in, or not. This format is configured with the [value] text "boolean". For example, a commonly known DHCP Option [2] may be configured thus: option ip-forwarding code 19 = boolean; Such manual configuration for this option however is not necessary, as it is encoded in a common table internally by default: { "ip-forwarding", "f", &dhcp_universe, 19 } The second field of this table, "f", is this option's Format String. 'f' is the single-byte atom used to describe boolean values, but you Hankins Expires March 5, 2007 [Page 5] might also see 'F', which is a special-case boolean value that is implied to always be true (regardless of value). Actual uses for 'F' are not known outside of the kludges for which it was necessary to create internally to software, and so there is no configuration language to specify one. On the wire, a boolean is encoded as a single octet. A value of 0 is encoded to impart a false condition, a value of 1 is encoded to impart a truth condition. In configuration language, boolean values are encoded in ASCII using the strings "true", "false", "enable", or "disable". For example: option ip-forwarding disable;

7 When presented, only the ASCII strings "true" or "false" are used. It should be stressed that although ISC DHCP encodes values of 0 and 1 to indicate false and truth, any non-zero value read from a DHCP Option will be taken to indicate truth (the least significant bit is not the only bit checked) Integers One of the easiest values to encode in an option are fixed length binary integers in network byte order. So long as by fixed-length you mean 8, 16, or 32 bits in length. Both 'unsigned' and 'signed' (two's compliment) values are possible, and an author should note which is intended (or else leave this open to site-local defaults or interpretation). These formats are configured with the [value] text: [unsigned/signed] integer [8/16/32] For example, some commonly known DHCP Options [2] may be configured thus: option time-offset code 2 = signed integer 32; option default-ip-ttl code 23 = unsigned integer 8; option interface-mtu code 26 = unsigned integer 16; option arp-cache-timeout code 36 = unsigned integer 32; But obviously such manual configuration is not necessary; these are provided internally by default in a common table: Hankins Expires March 5, 2007 [Page 6] { "time-offset", "l", &dhcp_universe, 2 }, { "default-ip-ttl", "B", &dhcp_universe, 23 } { "interface-mtu", "S", &dhcp_universe, 26 } { "arp-cache-timeout", "L", &dhcp_universe, 35 } Note the 'l', 'B', 'S', and 'L' values. These are 'format strings', and are the software's internal language to describe an option's Atomic structure. The actual full spectrum of single-byte Atoms is

8 'b', 'B', 's', 'S', 'l' and 'L'. Each of these describing the signed and unsigned variants of 1, 2, and 4-octet integers. On the wire, each of these integers is encoded in binary in least significant order ("network byte order"). Signed integers are encoded in twos-compliment. Regardless of their bit width or sign type, all of these options are configured and displayed similarly in ASCII strings. Administrators may configure values for these integer options using any decimal notation. Octal, hexadecimal, and base-10 are presently supported, and might appear as so: option time-offset option default-ip-ttl option interface-mtu option arp-cache-timeout -480; # base-10 decimal 0x7F; # hexadecimal 1500; # base-10 decimal 0666; # octal Once the option atom is received by a DHCP process and formatted to be presented, it is always presented in base-10 decimal, as an ASCII string, similarly to the above two base-10 examples. Wether the value is signed or unsigned determines the range of positive and negative values that might be produced IP Addresses Where would DHCP be without IP Addresses? An IPv4 address can be configured with the [value] text "ip-address". For IPv6 addresses, it is "ip6-address". For example, some commonly known DHCP Options [2] and DHCPv4 Options [4] may be configured thus: option dhcp.subnet-mask code 1 = ip-address; option dhcp6.unicast code 12 = ip6-address; But such manual configuration is not necessary, of course, because Hankins Expires March 5, 2007 [Page 7] the options' format are encoded in a common table internally to the

9 software by default: { "subnet-mask", "I", &dhcp_universe, 1 }, { "unicast", "6", &dhcpv6_universe, 12, 1 }, The single-byte atom 'I' is used internally to describe an IPv4 address, and '6' for IPv6 addresses. On the wire, the value is a 4-octet binary representation of an IPv4 address, or a 16-octet binary representation of an IPv6 address. Although configuration via hexadecimal, octal, or even decimal is permisslbe, the most common and appropriate configuration language for IPv4 addresses is "dotted quads." ASCII strings of four base-10 decimal numbers separated by ASCII '.' symbols. IPv6 uses a similar mechanism involving colons segregating 16-bit fields, and a mechanism to encode repeating zeroes. For example: option dhcp.subnet-mask ; option dhcp6.unicast fe80::1; Similarly, both address atoms are presented to applications in the same format - as text strings encoded as above Text and Strings Although 'text' and 'strings' are generally interchangeable words, they have been overloaded to indicate specific formatting intents. Text, then, is defined to mean an NVT-ASCII string. That is, a number of ASCII "printable" 1-octet characters, and no zero ("NULL") terminating octet. Meanwhile, 'string' characterizes a chain of octets that may represent an ASCII 'printable' string ("text"), but possibly may not, and would be better served by being described as an opaque field of octets. Text and String formats are configured with the [value] texts of "text" and "string" respectively. For example, some commonly known DHCP Options [2] may be configured thus: Hankins Expires March 5, 2007 [Page 8]

10 option host-name code 12 = text; option dhcp-client-identifier code 61 = string; But of course, neither of these manual configurations are necessary, as these options formats are encoded in a common table internally to the software by default: { "host-name", "t", &dhcp_universe, 12 } { "dhcp-client-identifier", "X", &dhcp_universe, 61 } Note the 't' and 'X' bytes, which form these options Format Strings. Note also that the 'X' format is the default format for all presently unknown, undocumented or unused option codes. Either text or string values can be configured using quoted ASCII strings, or hexadecimal chains of octets. For example, the above two options may be configured thus: option host-name "kaboom"; option dhcp-client-identifier 01:00:80:fc:55:4d:13; When presented, 'text' values are always emitted as printable ASCII strings. 'string' values are examined first. If they include only printable ASCII characters, they are provided as such. If they include any non-printable characters, they are provided in ASCII as hexadecimal chains of octets, identical to how the client-identifier option was configured above. It should be mentioned that 'text' types are subject to additional processing. RFC2131 [1] explicitly instructs implementations to strip trailing NULL values from NVT-ASCII strings in the event they are encountered...and so these values will be removed when the option is processed from the packet. Also, some specific client implementations that are known to misbehave when not presented with NULL terminations on text values are catered to. When this limitation is detected (generally by sensing that the client supplied its host-name with null termination), all text options output to the client are null terminated. Note that both of these formats are of indeterminable length (they both lack any form of termination). As such they may only appear last on a chain of Atoms, as any next atom would be impossible to sense the start of Encapsulation

11 Sometimes also called 'Sub-Options', encapsulated options are any condition where DHCP-mimicing option formats are placed inside DHCP Hankins Expires March 5, 2007 [Page 9] Option contents. To support such Encapsulation, the server must first present an alternative 'site option space', the device that maps the Encapsulated option codes into sub-option names. The [value] text for an Encapsulated option is: encapsulate "[option-space-name]" But this is an incomplete description of how to configure encapsulated options. So, here is an example of a Vendor Encapsulated Option [2]: option PXE.discovery-mcast-addr code 7 = unsigned integer 8; option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-oport code 2 = unsigned integer 16 option PXE.mtftp-sport code 3 = unsigned integer 16 option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option PXE.discovery-control code 6 = unsigned integer 8; class "pxeclients" { match if substring(option vendor-class-identifier, 0 9) = "PXEClient"; vendor-option-space PXE; } # Alternatively: #option vendor-encaps code 43 = encapsulate PXE; In the above example, manual configuration is necessary, because it is impossible (and possibly improper) for the internal tables to document all possible Vendor-Specific interpretations of option code 43, Vendor Encapsulated Options. Multiple Vendor-Encapsulated spaces may be supported by utilizing the vendor-option-space configuration directive. This automatically

12 aliases the configured option space into the option 43 encapsulation, as exampled above, if there is some good reason to think the client will use it. Obviously, only one option space is used to form option contents on the wire. For other options (or to not support multiple vendor option spaces), an option code may be explicitly defined to consume a specific option space. Hankins Expires March 5, 2007 [Page 10] In other examples, however, manual configuration is not necessary, because they've been described by an RFC and have a standard format. So they can be included in the software's default internal tables, for example: { "nwip-suboptions", "Enwip.", &dhcp_universe, 63 } The 'E' byte indicates the format of the option is encapsulated options. The following bytes up to the '.' byte indicate the name of the option space to be used for encapsulation. How this option space is configured to have a name that is meaningful is unimportant, but within that option space the NWIP Sub Options [5] may be defined: { "nsq-broadcast", "f", &nwip_universe, 5 }, { "preferred-dss", "IA", &nwip_universe, 6 }, { "nearest-nwip-server", "IA", &nwip_universe, 7 }, { "autoretries", "B", &nwip_universe, 8 }, { "autoretry-secs", "B", &nwip_universe, 9 }, { "nwip-1-1", "f", &nwip_universe, 10 } { "primary-dss", "I", &nwip_universe, 11 } On the wire, an encapsulated option itself contains DHCP-like suboptions. That is, single code bytes, single length bytes, followed by that number of octets. The meaning and format of those octets depends upon the definition in the encapsulated option space. One doesn't normally configure an encapsulated option...rather one configures the encapsulated option space, in the format specific to each option in that space. But if one did, one would use a colonseparated hexadecimal string. Examples: option PXE.mtftp-ip ;

13 # Alternatively. #option vendor-encapsulated-options 01:04:00:00:00; option nwip.nsq-broadcast true; option nwip.nearest-nwip-server ; # Alternatively. #option nwip-suboptions 05:01:01:07:04:0A:00:00:01; One also doesn't normally present an encapsulated option...rather one consumes the individual option from its option space, and so that option is presented depending upon its specific format. But if you did, likewise to configuring, it would be presented as a colonseparated hexadecimal string. Hankins Expires March 5, 2007 [Page 11] For each suboption, you can look at presentation examples elsewhere in this document. For whole-option consumption however, it would look (identically as above) like so: Domain Names 01:04:00:00:00:00 05:01:01:07:04:0A:00:00:01 DNS Domain Names are commonly transported in both DHCPv4 and DHCPv6 for many different purposes, and in a variety of formats. They are also configured by the user and require DHCP software to perform DNS requests. Most DHCPv4 options are encoded using the 't' atom, as simple text strings. One DHCpv4 option, the Domain Search List [6] option, encodes a list of domain names in RFC1035 [7] "compressed" format (compression pointers are relative to the start of the individual optoin's contents). Meanwhile, DHCPv6 [4] clearly illustrates that while RFC1035 [7] format for domain names is to be used, compression pointers are not to be utilized.

14 In the interests of reusing code and simplicity overall, these are both combined into the 'D' atom. The presence or lack of compression is illustrated by the 'c' flag to this atom. When the compression flag is present, the software will produce fields on-the-wire that contain compression pointers. Without this flag, they simply list domain names one after the other. Both with and without the flag, any compression pointers found within fields found on the wire will be evaluated against the contents of the option in question. Both formats might be configured using the following syntax: # DHCPv4 domain-search option. option dhcp.domain-search code 119 = domain-list compressed; # DHCPv6 sip-servers dns names option. option dhcp6.sip-servers-names code 21 = domain-list; And are configured by default within sources as: { "domain-search", "Dc", &dhcp_universe, 119, 1 }, Hankins Expires March 5, 2007 [Page 12] { "sip-servers-names", "D", &dhcpv6_universe, 21, 1 }, Administrators configure these values as a quoted list of strings: option dhcp.domain-search "apple.com", "eng two.apple.com"; option dhcp6.sip-servers-names "sip1.example.com", "sip2.example.com"; On the wire, they will appear as RFC1035 [7] formatted strings of labels, including root labels. The "Dc" option will appear with compression pointers as applicable. In taking these option off the wire, it depends upon their intended use in how they will appear. If the option is intended to be stored in a machine-readable location where configuration state can be cached (the 'dhclient.leases' file), they are represented the same way as they are configured above, and

15 are octally escaped as necessary for software configuration language. If the option is going to be emitted to another application, or written into eg /etc/resolv.conf, then the option is flattened into a text string, separated by spaces, and each label is decimal-escaped as neccessary: apple.com. eng\032two.apple.com. sip1.example.com. sip2.example.com. Note the doamin-search example that contains a space in one label Making Arrays Once you have constructed an option that contains one configuration value: # Contains source and destination addresses. option strawman.strawgirl code 5 = ip-address, ip-address; You might want to allow more than one such value be configured. To do this, we make an array out of the existing configuration atoms, essentially allowing it to repeat itself. Any atom that is already of indeterminate length (such as 't', 'x', or 'D' atoms) is illegal in arrays. To turn our example into an array, we simply change the syntax slightly, depending on what you're after: Hankins Expires March 5, 2007 [Page 13] # A list of source/dest addresses. option srawman.strawgirl code 5 = array of ip-address, ip-address; # One source address and a list of dest addresses. option srawman.strawgirl code 5 = ip-address, array-of ip-address; Here we see that the first option requires that any legal value be a multiple of two addresses. Each discrete configuration item is one pair of addresses. In the second example, we see that the option

16 must only be a multiple of four in length, and contain at least two addresses. Arrays are entered into configuration language using commas to delineate between fields, as exampled above. On the wire, each individual atom of each type, whatever it be, is concatenated to produce the wire format. The presentation format to the user again depends on each individual atom's presentation, and is merely concatenated together with spaces and/or commas inbetween Molecular Assembly Configuring Format Strings Think carefully about the data you need to impart between DHCP speaking systems (be it between servers or clients or relays). Put all of the fixed-length values at the top. Put all the variablelength values at the end. If there are more than one variable-length value, you may either choose to switch to an Encapsulated-Options scheme (recommended) or you may also choose to encode the new variable length values with length bytes (note that this essentially is what Encapsulated options do). Are any of the fields within your option of variable format? That is, must you digest the option contents in order to understand the rest of the option? Again, this is another excellent candidate for Encapsulated Options schemes. Sure, from a protocol standpoint it works to encode the format of the option within the option, it is not impossible to decode or encode this. But, since your encoding-dujour has probably not been done before, it's unlikely that any implementation will have the tools already developed. Special-case code must then be created. Hankins Expires March 5, 2007 [Page 14] Now, look at the option you have created, and the order in which the data fields appear. Is it reasonable to ask a systems administrator to type imaginable values for each field, as though into a configuration file or similar means? At some end in the DHCP

17 equation, it must be typed into configuration by a human, and it must be digested by the application you have in mind Illegal Combinations The basic rule of thumb for an illegal combination is that only one undefined size Atom is allowed, at the end of the option. That is to say, the format string "dt" would be illegal, because there is no way to distinguish when the 'd' Atom stops and where the 't' Atom starts. Likewise, 'ta' would be illegal because it's not possible to create an array of Atoms whose size themself is undefined Legal Combinations The single most compilcated format string deployed in the server today is "fto". A perfectly legal syntax, because it does not combine multiple variable length Atoms, but rather makes a single variable length Atom's presence optional. The FQDN Option, as an example, is substantially more complicated, but needfully so. In order to support this option, a DHCP server must itself be advanced enough to support Dynamic DNS. It is a machine-generated, machine-consumed option. It is unreasonable to ask a human to configure the flags fields and contents of the option. So, the FQDN Option, as an example, has been implemented with a form of virtual Encapsulation. That is, it is treated like an Encapsulated option in the way user configuration interacts with it, but special-case functions assemble the saved option caches into an FQDN-Option-Formatted field when the time comes. But, if you were going to configure it with Atoms, it would be done something like "BBBd". Think on that. If your DHCP Option substantially more complicated than this? If so, needfully so? Wether or not your option can be quickly and easily configured using the Atomic syntax I've introduced here determines not only your chances of having your option included in future software releases, but also wether or not your option will be usable immediately on the DHCP Servers deployed in the field today. That is, DHCP Servers running today's software, which only allows a Systems Administrator to configure the Atoms outlined here. That means if your option doesn't fit, they're going to wind up Hankins Expires March 5, 2007 [Page 15]

18 configuring your option by hand in hex! Is that a barrier to the adoption of your option? 4. Lessons Learned 4.1. Conditional Formatting is Hard Options that include values that determine conditionally how the rest of the option contents are to be interpreted are hard to implement: they are always special cases that must be engineered for individually Its Probably Been Done Before creating your option, take some time to review the bulk of the DHCP options contained in RFC2132 [2] and later works, and look for any similarities to what you're trying to accomplish. Redoing what's been done in a contrived or better way is admirable, but is unlikely to get your option implemented quickly. Emulating what's already been done advances your chances that implementors can simply reuse code Keep It Simple, Stupid Even if that means ignoring the above advice. It may be that the option is only going to be processed by machines, which when implemented are going to have to understand its specific format anyway. In such a case, seek implementation simplicity. 5. Security Considerations Do not split DHCP Atoms. Leading scientists have measured the amount of energy it takes to form a single DHCP Atom as approaching infinite (at least, it is not measurable by any science we possess today). The entirety of this energy would be released at once in the event a DHCP Atom was split. It would be bad. 6. Acknowledgements The implementation described herein was written by Ted Lemon in cooperation with Nominum, Inc. Without this contribution to the public benefit, neither the implementation nor this document would be possible.

19 Hankins Expires March 5, 2007 [Page 16] 7. References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March [3] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July [5] Droms, R. and K. Fong, "NetWare/IP Domain Name and Information", RFC 2242, November [6] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November [7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

20 Hankins Expires March 5, 2007 [Page 17] Author's Address David W. Hankins Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA US Phone:

21 Hankins Expires March 5, 2007 [Page 18] Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity

22 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hankins Expires March 5, 2007 [Page 19]