idnits 2.17.1 draft-ietf-dhc-pxelinux-03.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 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The MAGIC option MAY NOT be implemented, as it has been deprecated. -- 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 2007) is 6123 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 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 2007 5 Intended status: Informational 6 Expires: January 2, 2008 8 Dynamic Host Configuration Protocol Options Used by PXELINUX 9 draft-ietf-dhc-pxelinux-03 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 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes the use by PXELINUX of some DHCP Option Codes 43 numbering from 208-211. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5 52 3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 53 3.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 5 54 4. Configuration File Option . . . . . . . . . . . . . . . . . . 5 55 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6 57 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 58 4.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 6 59 4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6 60 5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 62 5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 63 5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 64 5.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 8 65 5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8 66 6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 8 67 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9 69 6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 9 70 6.4. Response to RFC3942 . . . . . . . . . . . . . . . . . . . 10 71 6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10 72 7. Specification Conformance . . . . . . . . . . . . . . . . . . 10 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 Intellectual Property and Copyright Statements . . . . . . . . . . 14 82 1. Introduction 84 PXE, the Preboot eXecution Environment, is a first-stage network 85 bootstrap agent. PXE is loaded out of firmware on the client host, 86 and performs DHCP [1] queries to obtain an IP Address. 88 Once on the network, it loads a second-stage bootstrap agent as 89 configured by DHCP header and option contents. 91 PXELINUX is one such second-stage bootstrap agent. Once PXE has 92 passed execution to it, PXELINUX seeks its configuration from a cache 93 of DHCP Options supplied to the PXE first-stage agent, and then takes 94 action based upon those options. 96 Most frequently, this implies loading via TFTP [6] one or more images 97 which are decompressed into memory and executed to pass execution to 98 the final Host Operating System. 100 PXELINUX uses DHCP Options 208-211 to govern parts of this bootstrap 101 process, but these options are not requested by the PXE DHCP Client 102 at the time it acquires its lease...at that time, the PXE bootloader 103 has no knowledge that PXELINUX is going to be in use, and even so 104 would have no way to know what option(s) PXELINUX might digest. 105 Local installations that serve this PXELINUX image to its clients 106 must also configure their DHCP Servers to provide these options even 107 though they are not on the DHCP Parameter Request List [2]. 109 These options are: 111 o "MAGIC" - 208 - An option whose presence and content verifies to 112 the PXELINUX bootloader that the options numbered 209-211 are for 113 the purpose as described herein. 115 o "ConfigFile" - 209 - Configures the path/filename component of the 116 configuration file's location which this bootloader should use to 117 configure itself. 119 o "PathPrefix" - 210 - Configures a value to be prepended to the 120 ConfigFile, to discern the directory location of the file. 122 o "RebootTime" - 211 - Configures a timeout after which the 123 bootstrap program will reboot the system (most likely returning it 124 to PXE). 126 Historically, these option codes numbering from 208-211 were 127 designated 'Site Local', but after publication of RFC3942 [7], they 128 were made available for allocation as new standard DHCP Options. 129 This document marks these codes as assigned. 131 This direct assignment of option code values in the option 132 definitions below is unusual as it is not mentioned in DHCP Option 133 Code assignment guidelines [3]. This document's Option Code 134 assignments are done within RFC3942's provisions for documenting 135 prior use of option codes within the new range (128-223 inclusive). 137 2. Terminology 139 o "first-stage bootloader" - Although a given boot loading order may 140 have many stages, such as where a BIOS boots a DOS Boot Disk which 141 then loads a PXE executable, it is in this example only the PXE 142 executable that this document describes as the "first-stage 143 bootloader" - in essence, this is the first stage of booting at 144 which DHCP is involved. 146 o "second-stage bootloader" - This describes a program loaded by the 147 first-stage bootloader at the behest of the DHCP Server. 149 o "bootloader" and "network bootstrap agent" - These are synonyms, 150 excepting that "bootloader" is intentionally vague in that its 151 next form of bootstrapping may not in fact involve network 152 resources. 154 The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" 155 in this document are to be interpreted as described in RFC2119 [4]. 157 3. MAGIC Option 159 3.1. Description 161 If this option is provided to the PXE bootloader, then the value is 162 checked by PXELINUX to match the octet string f1:00:74:7e. If this 163 matches, then PXELINUX bootloaders will also consume options 209-211, 164 as described below. Otherwise, they are ignored. 166 This measure was intended to ensure that, as the 'Site Local' option 167 space is not allocated from a central authority, no conflict would 168 result in a PXELINUX bootloader improperly digesting options intended 169 for another purpose. 171 3.2. Packet Format 173 The MAGIC Option format is as follows: 175 Code Length m1 m2 m3 m4 176 +--------+--------+--------+--------+--------+--------+ 177 | 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E | 178 +--------+--------+--------+--------+--------+--------+ 180 The code for this option is 208. The length is always four. 182 3.3. Applicability 184 This option is absolutely inapplicable to any other purpose. 186 3.4. Response to RFC3942 188 The option code 208 will be adopted for this purpose and immediately 189 deprecated. Future standards action may return this option to an 190 available status should it be necessary. 192 A collision of the use of this option is harmless (at least from 193 PXELINUX' point of view) by design: if it does not match the 194 aforementioned magic value, the PXELINUX bootloader will take no 195 special action. 197 The PXELINUX project will deprecate the use of this option, future 198 versions of the software will not evaluate its contents. 200 It is reasonable to utilize this option code for another purpose, but 201 it is recommended to do this at a later time, given the desire to 202 avoid potential collisions in legacy userbases. 204 4. Configuration File Option 206 4.1. Description 208 Once the PXELINUX executable has been entered from the PXE 209 bootloader, it evaluates this option and loads a file of that name 210 via TFTP. The contents of this file serve to configure PXELINUX in 211 its next stage of bootloading (specifying boot image names, 212 locations, boot-time flags, text to present the user in menu 213 selections, etc). 215 In the absence of this option, the PXELINUX agent will search the 216 TFTP Server (as determined by PXE prior to this stage) for a config 217 file of several default names. 219 4.2. Packet Format 221 The Configuration File Option format is as follows: 223 Code Length Config-file... 224 +--------+--------+--------+--------+--------+--------+ 225 | 209 | n | c1 | c2 | ... | c(n) | 226 +--------+--------+--------+--------+--------+--------+ 228 The code for this option is 209. The Config-file (c1..c(n)) is an 229 NVT-ASCII [5] printable string, it is not terminated by a zero or any 230 other value. 232 4.3. Applicability 234 Any bootloader, PXE or otherwise, that makes use of a separate 235 configuration file rather than containing all configuration within 236 DHCP options (which may be impossible due to the limited space 237 available for DHCP options) may conceivably make use of this option. 239 4.4. Response to RFC3942 241 The code 209 will be adopted for this purpose. 243 4.5. Client and Server Behaviour 245 The Config File Option MUST be supplied by the DHCP Server if it 246 appears on the Parameter Request List, but MUST also be supplied if 247 the server administrator believed it would later be useful to the 248 client (such as because the server is configured to offer a second- 249 stage boot image which they know will make use of it). The option 250 MUST NOT be supplied if no value has been configured for it, or if a 251 value of zero length has been configured. 253 The DHCP Client MUST only cache this option in a location the second- 254 stage bootloader may access it. 256 The second-stage bootloader MUST, in concert with other DHCP Options 257 and fields, use this option's value as a filename to be loaded via 258 TFTP and read for further second-stage-loader-specific configuration 259 parameters. The format and content of such a file is specific to the 260 second-stage bootloader, and as such is out of scope of this 261 document. 263 5. Path Prefix Option 264 5.1. Description 266 In PXELINUX' case, it is often the case that several different 267 environments would have the same TFTP path prefix, but would have 268 different filenames (for example: hosts' bootloader images and config 269 files may be kept in a directory structure derived from their MAC 270 Address). Consequently, it was deemed worthwhile to deliver a TFTP 271 path prefix configuration option, so that these two things could be 272 configured separately in DHCP Server configuration: the prefix and 273 the possibly-host-specific file location. 275 The actual filename that PXELINUX requests from its TFTP server is 276 derived by prepending this value to the Config File Option above. 277 Once this config file is loaded and during processing, any TFTP file 278 paths specified within it are similarly processed - prepending the 279 contents of this option. 281 The contents of the Path Prefix option are also prepended to all 282 configured filename locations within the PXELINUX configuration file. 284 5.2. Packet Format 286 The Path Prefix Option format is as follows: 288 Code Length Path-Prefix... 289 +--------+--------+--------+--------+--------+--------+ 290 | 210 | n | p1 | p2 | ... | p(n) | 291 +--------+--------+--------+--------+--------+--------+ 293 The code for this option is 210. The Path Prefix is an NVT-ASCII 294 printable string, it is not terminated by zero or any other value. 296 5.3. Applicability 298 This option came into existence because server administrators found 299 it useful to configure the prefix and suffix of the config file path 300 separately. A group of different PXE booting clients may use the 301 same path prefix, but different filenames, or vice versa. 303 The 'shortcut' this represents is worthwhile, but it is questionable 304 whether that needs to manifest itself on the protocol wire. 306 It only becomes interesting from a protocol standpoint if other 307 options are adopted which prefix this value as well - performing a 308 kind of string compression is highly beneficial to the limited 309 available DHCP option space. 311 But it's clearly inapplicable to any current use of e.g. the FILENAME 312 header contents, or the DHCP Boot File Name option (#67). Use of 313 these fields is encoded on firmware of thousands of devices which 314 can't or are not likely to be upgraded. Altering any behaviour here 315 is likely to cause severe compatibility problems. 317 Although compression of the TFTP-loaded configuration file contents 318 is not a compelling factor, contrived configurations using these 319 values may also exist: Where each of a large variety of different 320 clients load the same configuration file, with the same contents, but 321 due to a differently configured path prefix actually load different 322 images. Whether this sort of use is truly needed remains unproven. 324 5.4. Response to RFC3942 326 The code 210 will be adopted for this purpose. 328 5.5. Client and Server Behaviour 330 The Path Prefix option MUST be supplied by the DHCP Server if it 331 appears on the Parameter Request List, but MUST also be supplied if 332 the server administrator believed it would later be useful to the 333 client (such as because the server is configured to offer a second- 334 stage boot image which they know will make use of it). The option 335 MUST NOT be supplied if no value has been configured for it, or if a 336 value of zero length has been configured. 338 The DHCP Client MUST only cache this option in a location where the 339 second-stage bootloader may access it. 341 The second-stage bootloader MUST prepend this option's value, if any, 342 to the contents of the ConfigFile option prior to obtaining the 343 resulting value via TFTP, or the default 'Config File Search Path' 344 which the second-stage bootloader iterates in the absence of a Config 345 File Option. The client MAY prepend the value to other configuration 346 directives within that file once it has been loaded. The client MUST 347 NOT prepend this option's value to any other DHCP option contents or 348 field, unless explicitly stated in a document describing that option 349 or field. 351 6. Reboot Time Option 353 6.1. Description 355 Should PXELINUX be executed, and then for some reason be unable to 356 reach its TFTP server to continue bootstrapping, the client will by 357 default reboot itself after 300 seconds have passed. This may be too 358 long, too short, or inappropriate behaviour entirely, depending on 359 the environment. 361 By configuring a non-zero value in this option, admins can inform 362 PXELINUX of what specific timeout is desired. The client will reboot 363 itself if it fails to achieve its configured network resources within 364 the specified number of seconds. 366 This reboot will run through the system's normal boot-time execution 367 path, most likely leading it back to PXE and therefore PXELINUX. So, 368 in the general case, this is akin to returning the client to the DHCP 369 INIT state. 371 By configuring zero, the feature is disabled, and instead the client 372 chooses to remove itself from the network and wait indefinitely for 373 operator intervention. 375 It should be stressed that this is in no way related to configuring a 376 lease-time. The perceived transition to INIT state is due to client 377 running state - reinitializing itself - not due to lease timer 378 activity. That is, it is not safe to assume that a PXELINUX client 379 will abandon its lease when this timer expires. 381 6.2. Packet Format 383 The Reboot Time Option format is as follows: 385 Code Length 386 +--------+--------+--------+--------+--------+--------+ 387 | 211 | 4 | Reboot Time | 388 +--------+--------+--------+--------+--------+--------+ 390 The code for this option is 211. The length is always four. The 391 Reboot Time is a 32-bit (4 byte) integer in network byte order. 393 6.3. Applicability 395 Any network bootstrap program in any sufficiently complex networking 396 environment could conceivably enter into such a similar condition. 397 Either due to having its IP address stolen out from under it by a 398 rogue client on the network, by being moved between networks where 399 its PXE-derived DHCP lease is no longer valid, or any similar means. 401 It seems desirable for any network bootstrap agent to implement an 402 ultimate timeout for it to start over. 404 The client may, for example, get different, working configuration 405 parameters from a different DHCP server upon restarting. 407 6.4. Response to RFC3942 409 The code 211 will be adopted for this purpose. 411 6.5. Client and Server Behaviour 413 The Reboot Time Option MUST be supplied by the DHCP Server if it 414 appears on the Parameter Request List, but MUST also be supplied if 415 the server administrator believed it would later be useful to the 416 client (such as because the server is configured to offer a second- 417 stage boot image which they know will make use of it). The option 418 MUST NOT be supplied if no value has been configured for it, or if it 419 contains a value of zero length. 421 The DHCP Client MUST only cache this option in a location the second- 422 stage bootloader may access it. 424 If the value of this option is nonzero, the second-stage bootloader 425 MUST schedule a timeout: after a number of seconds equal to this 426 option's value have passed, the second-stage bootloader MUST reboot 427 the system, ultimately returning the path of execution back to the 428 first-stage bootloader. It MUST NOT reboot the system once the 429 thread of execution has been passed to the host operating system (at 430 which point this timeout is effectively obviated). 432 If the value of this option is zero, the second-stage bootloader MUST 433 NOT schedule such a timeout at all. Any second-stage bootloader that 434 finds it has encountered excessive timeouts attempting to obtain its 435 host operating system SHOULD disconnect itself from the network to 436 wait for operator intervention, but MAY continue to attempt to 437 acquire the host operating system indefinitely. 439 7. Specification Conformance 441 To conform to this specification, clients and servers MUST implement 442 the Configuration File, Path Prefix, and Reboot Time options as 443 directed. 445 The MAGIC option MAY NOT be implemented, as it has been deprecated. 447 8. Security Considerations 449 PXE and PXELINUX allow any entity acting as a DHCP server to execute 450 arbitrary code upon a system. At present, no PXE implementation is 451 known to implement Authentication mechanisms [8] so that PXE clients 452 can be sure they are receiving configuration information from the 453 correct, authoritative DHCP Server. 455 The use of TFTP by PXE and PXELINUX also lacks any form of 456 cryptographic signature - so a 'Man in the Middle' attack may lead to 457 an attacker's code being executed on the client system. Since this 458 is not an encrypted channel, any of the TFTP loaded data may also be 459 exposed (such as in loading a "RAMDISK" image, which contains /etc/ 460 passwd or similar information). 462 The use of the Ethernet MAC Address as the client's unique identity 463 may allow an attacker who takes on that identity to gain 464 inappropriate access to a client system's network resources by being 465 given by the DHCP Server whatever 'keys' are required to in fact be 466 the target system (to boot up as though it were the target). 468 Great care should be taken to secure PXE and PXELINUX installations, 469 such as by using IP Firewalls, to reduce or eliminate these concerns. 471 A nearby attacker might feed a "Reboot Time" option value of 1 second 472 to a mass of unsuspecting clients, to effect a Denial Of Service upon 473 the DHCP Server, but then again it may just as easily supply these 474 clients with rogue second-stage bootloaders which simply transmit a 475 flood of packets. 477 This document in and by itself provides no security, nor does it 478 impact existing DCHP security as described in RFC2131 [1]. 480 9. IANA Considerations 482 IANA is requested to: 484 1. Move DHCPv4 Option code 208 from 'Tentatively Assigned' to 485 'Assigned', referencing this document. IANA is also requested to 486 mark this same option code, 208, as Deprecated. 488 2. Move DHCPv4 Option code 209 from 'Tentatively Assigned' to 489 'Assigned', referencing this document. 491 3. Move DHCPv4 Option code 210 from 'Tentatively Assigned' to 492 'Assigned', referencing this document. 494 4. Move DHCPv4 Option code 211 from 'Tentatively Assigned' to 495 'Assigned', referencing this document. 497 10. Acknowledgements 499 These options were designed and implemented for the PXELINUX project 500 by H. Peter Anvin, and he was instrumental in producing this 501 document. Shane Kerr has also provided feedback which has improved 502 this document. 504 11. References 506 11.1. Normative References 508 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 509 March 1997. 511 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 512 Extensions", RFC 2132, March 1997. 514 [3] Droms, R., "Procedures and IANA Guidelines for Definition of New 515 DHCP Options and Message Types", BCP 43, RFC 2939, 516 September 2000. 518 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 519 Levels", BCP 14, RFC 2119, March 1997. 521 [5] Postel, J. and J. Reynolds, "Telnet Protocol Specification", 522 STD 8, RFC 854, May 1983. 524 11.2. Informative References 526 [6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, 527 July 1992. 529 [7] Volz, B., "Reclassifying Dynamic Host Configuration Protocol 530 version 4 (DHCPv4) Options", RFC 3942, November 2004. 532 [8] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 533 RFC 3118, June 2001. 535 Author's Address 537 David W. Hankins 538 Internet Systems Consortium, Inc. 539 950 Charter Street 540 Redwood City, CA 94063 541 US 543 Phone: +1 650 423 1307 544 Email: David_Hankins@isc.org 546 Full Copyright Statement 548 Copyright (C) The IETF Trust (2007). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Acknowledgment 588 Funding for the RFC Editor function is provided by the IETF 589 Administrative Support Activity (IASA).