1 2 3 4 5 6 7 Network Working Group D. Hankins 8 Request for Comments: 5071 ISC 9 Category: Informational December 2007 10 11 12 Dynamic Host Configuration Protocol Options Used by PXELINUX 13 14 Status of This Memo 15 16 This memo provides information for the Internet community. It does 17 not specify an Internet standard of any kind. Distribution of this 18 memo is unlimited. 19 20 Abstract 21 22 This document describes the use by PXELINUX of some DHCP Option Codes 23 numbering from 208-211. 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 Hankins Informational [Page 1] 59 61 RFC 5071 PXELINUX Options December 2007 62 63 64 Table of Contents 65 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. MAGIC Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 5 72 3.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 5 73 4. Configuration File Option . . . . . . . . . . . . . . . . . . 5 74 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 6 76 4.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 77 4.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 6 78 4.5. Client and Server Behaviour . . . . . . . . . . . . . . . 6 79 5. Path Prefix Option . . . . . . . . . . . . . . . . . . . . . . 7 80 5.1. Description . . . . . . . . . . . . . . . . . . . . . . . 7 81 5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 7 82 5.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 83 5.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 8 84 5.5. Client and Server Behaviour . . . . . . . . . . . . . . . 8 85 6. Reboot Time Option . . . . . . . . . . . . . . . . . . . . . . 9 86 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 9 87 6.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 9 88 6.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 89 6.4. Response to RFC 3942 . . . . . . . . . . . . . . . . . . . 10 90 6.5. Client and Server Behaviour . . . . . . . . . . . . . . . 10 91 7. Specification Conformance . . . . . . . . . . . . . . . . . . 11 92 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 94 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 97 11.2. Informative References . . . . . . . . . . . . . . . . . . 12 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 Hankins Informational [Page 2] 116 118 RFC 5071 PXELINUX Options December 2007 119 120 121 1. Introduction 122 123 PXE, the Preboot eXecution Environment, is a first-stage network 124 bootstrap agent. PXE is loaded out of firmware on the client host, 125 and performs DHCP [3] queries to obtain an IP address. 126 127 Once on the network, it loads a second-stage bootstrap agent as 128 configured by DHCP header and option contents. 129 130 PXELINUX is one such second-stage bootstrap agent. Once PXE has 131 passed execution to it, PXELINUX seeks its configuration from a cache 132 of DHCP options supplied to the PXE first-stage agent, and then takes 133 action based upon those options. 134 135 Most frequently, this implies loading via Trivial File Transfer 136 Protocol (TFTP) [6] one or more images that are decompressed into 137 memory, then executed to pass execution to the final Host Operating 138 System. 139 140 PXELINUX uses DHCP options 208-211 to govern parts of this bootstrap 141 process, but these options are not requested by the PXE DHCP client 142 at the time it acquires its lease. At that time, the PXE bootloader 143 has no knowledge that PXELINUX is going to be in use, and even so, 144 would have no way to know what option(s) PXELINUX might digest. 145 Local installations that serve this PXELINUX image to its clients 146 must also configure their DHCP servers to provide these options even 147 though they are not on the DHCP Parameter Request List [4]. 148 149 These options are: 150 151 o "MAGIC" - 208 - An option whose presence and content verifies to 152 the PXELINUX bootloader that the options numbered 209-211 are for 153 the purpose as described herein. 154 155 o "ConfigFile" - 209 - Configures the path/filename component of the 156 configuration file's location, which this bootloader should use to 157 configure itself. 158 159 o "PathPrefix" - 210 - Configures a value to be prepended to the 160 ConfigFile to discern the directory location of the file. 161 162 o "RebootTime" - 211 - Configures a timeout after which the 163 bootstrap program will reboot the system (most likely returning it 164 to PXE). 165 166 Historically, these option codes numbering from 208-211 were 167 designated 'Site Local', but after publication of RFC3942 [8], they 168 were made available for allocation as new standard DHCP options. 169 170 171 172 Hankins Informational [Page 3] 173 175 RFC 5071 PXELINUX Options December 2007 176 177 178 This document marks these codes as assigned. 179 180 This direct assignment of option code values in the option 181 definitions below is unusual as it is not mentioned in DHCP Option 182 Code assignment guidelines [5]. This document's Option Code 183 assignments are done within RFC 3942's provisions for documenting 184 prior use of option codes within the new range (128-223 inclusive). 185 186 2. Terminology 187 188 o "first-stage bootloader" - Although a given bootloading order may 189 have many stages, such as where a BIOS boots a DOS Boot Disk, 190 which then loads a PXE executable, it is, in this example, only 191 the PXE executable that this document describes as the "first- 192 stage bootloader" -- in essence, this is the first stage of 193 booting at which DHCP is involved. 194 195 o "second-stage bootloader" - This describes a program loaded by the 196 first-stage bootloader at the behest of the DHCP server. 197 198 o "bootloader" and "network bootstrap agent" - These are synonyms, 199 excepting that "bootloader" is intentionally vague in that its 200 next form of bootstrapping may not in fact involve network 201 resources. 202 203 The key words "MAY", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" 204 in this document are to be interpreted as described in RFC 2119 [2]. 205 206 3. MAGIC Option 207 208 3.1. Description 209 210 If this option is provided to the PXE bootloader, then the value is 211 checked by PXELINUX to match the octet string f1:00:74:7e. If this 212 matches, then PXELINUX bootloaders will also consume options 209-211, 213 as described below. Otherwise, they are ignored. 214 215 This measure was intended to ensure that, as the 'Site Local' option 216 space is not allocated from a central authority, no conflict would 217 result in a PXELINUX bootloader improperly digesting options intended 218 for another purpose. 219 220 221 222 223 224 225 226 227 228 229 Hankins Informational [Page 4] 230 232 RFC 5071 PXELINUX Options December 2007 233 234 235 3.2. Packet Format 236 237 The MAGIC Option format is as follows: 238 239 Code Length m1 m2 m3 m4 240 +--------+--------+--------+--------+--------+--------+ 241 | 208 | 4 | 0xF1 | 0x00 | 0x74 | 0x7E | 242 +--------+--------+--------+--------+--------+--------+ 243 244 The code for this option is 208. The length is always four. 245 246 3.3. Applicability 247 248 This option is absolutely inapplicable to any other purpose. 249 250 3.4. Response to RFC 3942 251 252 The option code 208 will be adopted for this purpose and immediately 253 deprecated. Future standards action may return this option to an 254 available status should it be necessary. 255 256 A collision of the use of this option is harmless (at least from 257 PXELINUX' point of view) by design: if it does not match the 258 aforementioned magic value, the PXELINUX bootloader will take no 259 special action. 260 261 The PXELINUX project will deprecate the use of this option; future 262 versions of the software will not evaluate its contents. 263 264 It is reasonable to utilize this option code for another purpose, but 265 it is recommended to do this at a later time, given the desire to 266 avoid potential collisions in legacy user bases. 267 268 4. Configuration File Option 269 270 4.1. Description 271 272 Once the PXELINUX executable has been entered from the PXE 273 bootloader, it evaluates this option and loads a file of that name 274 via TFTP. The contents of this file serve to configure PXELINUX in 275 its next stage of bootloading (specifying boot image names, 276 locations, boot-time flags, text to present the user in menu 277 selections, etc). 278 279 In the absence of this option, the PXELINUX agent will search the 280 TFTP server (as determined by PXE prior to this stage) for a config 281 file of several default names. 282 283 284 285 286 Hankins Informational [Page 5] 287 289 RFC 5071 PXELINUX Options December 2007 290 291 292 4.2. Packet Format 293 294 The Configuration File Option format is as follows: 295 296 Code Length Config-file... 297 +--------+--------+--------+--------+--------+--------+ 298 | 209 | n | c1 | c2 | ... | c(n) | 299 +--------+--------+--------+--------+--------+--------+ 300 301 The code for this option is 209. The Config-file (c1..c(n)) is an 302 NVT-ASCII [1] printable string; it is not terminated by a zero or any 303 other value. 304 305 4.3. Applicability 306 307 Any bootloader, PXE or otherwise, that makes use of a separate 308 configuration file rather than containing all configurations within 309 DHCP options (which may be impossible due to the limited space 310 available for DHCP options) may conceivably make use of this option. 311 312 4.4. Response to RFC 3942 313 314 The code 209 will be adopted for this purpose. 315 316 4.5. Client and Server Behaviour 317 318 The Config File Option MUST be supplied by the DHCP server if it 319 appears on the Parameter Request List, but MUST also be supplied if 320 the server administrator believed it would later be useful to the 321 client (such as because the server is configured to offer a second- 322 stage boot image, which they know will make use of it). The option 323 MUST NOT be supplied if no value has been configured for it, or if a 324 value of zero length has been configured. 325 326 The DHCP client MUST only cache this option in a location the second- 327 stage bootloader may access. 328 329 The second-stage bootloader MUST, in concert with other DHCP options 330 and fields, use this option's value as a filename to be loaded via 331 TFTP and read for further second-stage-loader-specific configuration 332 parameters. The format and content of such a file is specific to the 333 second-stage bootloader, and as such, is out of scope of this 334 document. 335 336 337 338 339 340 341 342 343 Hankins Informational [Page 6] 344 346 RFC 5071 PXELINUX Options December 2007 347 348 349 5. Path Prefix Option 350 351 5.1. Description 352 353 In PXELINUX' case, it is often the case that several different 354 environments would have the same TFTP path prefix, but would have 355 different filenames (for example: hosts' bootloader images and config 356 files may be kept in a directory structure derived from their Media 357 Access Control (MAC) address). Consequently, it was deemed 358 worthwhile to deliver a TFTP path prefix configuration option, so 359 that these two things could be configured separately in a DHCP Server 360 configuration: the prefix and the possibly host-specific file 361 location. 362 363 The actual filename that PXELINUX requests from its TFTP server is 364 derived by prepending this value to the Config File Option above. 365 Once this config file is loaded and during processing, any TFTP file 366 paths specified within it are similarly processed -- prepending the 367 contents of this option. 368 369 5.2. Packet Format 370 371 The Path Prefix Option format is as follows: 372 373 Code Length Path-Prefix... 374 +--------+--------+--------+--------+--------+--------+ 375 | 210 | n | p1 | p2 | ... | p(n) | 376 +--------+--------+--------+--------+--------+--------+ 377 378 The code for this option is 210. The Path Prefix is an NVT-ASCII 379 printable string; it is not terminated by zero or any other value. 380 381 5.3. Applicability 382 383 This option came into existence because server administrators found 384 it useful to configure the prefix and suffix of the config file path 385 separately. A group of different PXE booting clients may use the 386 same path prefix, but different filenames, or vice versa. 387 388 The 'shortcut' this represents is worthwhile, but it is questionable 389 whether that needs to manifest itself on the protocol wire. 390 391 392 393 394 395 396 397 398 399 400 Hankins Informational [Page 7] 401 403 RFC 5071 PXELINUX Options December 2007 404 405 406 It only becomes interesting from a protocol standpoint if other 407 options are adopted that prefix this value as well -- performing a 408 kind of string compression is highly beneficial to the limited 409 available DHCP option space. 410 411 But it's clearly inapplicable to any current use of, e.g., the 412 FILENAME header contents or the DHCP Boot File Name option (#67). 413 Use of these fields is encoded on firmware of thousands of devices 414 that can't or are not likely to be upgraded. Altering any behaviour 415 here is likely to cause severe compatibility problems. 416 417 Although compression of the TFTP-loaded configuration file contents 418 is not a compelling factor, contrived configurations using these 419 values may also exist: where each of a large variety of different 420 clients load the same configuration file, with the same contents, but 421 due to a differently configured path prefix actually load different 422 images. Whether this sort of use is truly needed remains unproven. 423 424 5.4. Response to RFC 3942 425 426 The code 210 will be adopted for this purpose. 427 428 5.5. Client and Server Behaviour 429 430 The Path Prefix option MUST be supplied by the DHCP server if it 431 appears on the Parameter Request List, but MUST also be supplied if 432 the server administrator believed it would later be useful to the 433 client (such as because the server is configured to offer a second- 434 stage boot image that they know will make use of it). The option 435 MUST NOT be supplied if no value has been configured for it, or if a 436 value of zero length has been configured. 437 438 The DHCP client MUST only cache this option in a location where the 439 second-stage bootloader may access it. 440 441 The second-stage bootloader MUST prepend this option's value, if any, 442 to the contents of the ConfigFile option prior to obtaining the 443 resulting value via TFTP, or the default 'Config File Search Path', 444 which the second-stage bootloader iterates in the absence of a Config 445 File Option. The client MAY prepend the value to other configuration 446 directives within that file once it has been loaded. The client MUST 447 NOT prepend this option's value to any other DHCP option contents or 448 field, unless explicitly stated in a document describing that option 449 or field. 450 451 452 453 454 455 456 457 Hankins Informational [Page 8] 458 460 RFC 5071 PXELINUX Options December 2007 461 462 463 6. Reboot Time Option 464 465 6.1. Description 466 467 Should PXELINUX be executed, and then for some reason, be unable to 468 reach its TFTP server to continue bootstrapping, the client will, by 469 default, reboot itself after 300 seconds have passed. This may be 470 too long, too short, or inappropriate behaviour entirely, depending 471 on the environment. 472 473 By configuring a non-zero value in this option, admins can inform 474 PXELINUX of which specific timeout is desired. The client will 475 reboot itself if it fails to achieve its configured network resources 476 within the specified number of seconds. 477 478 This reboot will run through the system's normal boot-time execution 479 path, most likely leading it back to PXE and therefore PXELINUX. So, 480 in the general case, this is akin to returning the client to the DHCP 481 INIT state. 482 483 By configuring zero, the feature is disabled, and instead the client 484 chooses to remove itself from the network and wait indefinitely for 485 operator intervention. 486 487 It should be stressed that this is in no way related to configuring a 488 lease time. The perceived transition to INIT state is due to client 489 running state -- reinitializing itself -- not due to lease timer 490 activity. That is, it is not safe to assume that a PXELINUX client 491 will abandon its lease when this timer expires. 492 493 6.2. Packet Format 494 495 The Reboot Time Option format is as follows: 496 497 Code Length 498 +--------+--------+--------+--------+--------+--------+ 499 | 211 | 4 | Reboot Time | 500 +--------+--------+--------+--------+--------+--------+ 501 502 The code for this option is 211. The length is always four. The 503 Reboot Time is a 32-bit (4 byte) integer in network byte order. 504 505 506 507 508 509 510 511 512 513 514 Hankins Informational [Page 9] 515 517 RFC 5071 PXELINUX Options December 2007 518 519 520 6.3. Applicability 521 522 Any network bootstrap program in any sufficiently complex networking 523 environment could conceivably enter into such a similar condition, 524 either due to having its IP address stolen out from under it by a 525 rogue client on the network, by being moved between networks where 526 its PXE-derived DHCP lease is no longer valid, or any similar means. 527 528 It seems desirable for any network bootstrap agent to implement an 529 ultimate timeout for it to start over. 530 531 The client may, for example, get different working configuration 532 parameters from a different DHCP server upon restarting. 533 534 6.4. Response to RFC 3942 535 536 The code 211 will be adopted for this purpose. 537 538 6.5. Client and Server Behaviour 539 540 The Reboot Time Option MUST be supplied by the DHCP server if it 541 appears on the Parameter Request List, but MUST also be supplied if 542 the server administrator believed it would later be useful to the 543 client (such as because the server is configured to offer a second- 544 stage boot image that they know will make use of it). The option 545 MUST NOT be supplied if no value has been configured for it, or if it 546 contains a value of zero length. 547 548 The DHCP client MUST only cache this option in a location the second- 549 stage bootloader may access. 550 551 If the value of this option is nonzero, the second-stage bootloader 552 MUST schedule a timeout: after a number of seconds equal to this 553 option's value have passed, the second-stage bootloader MUST reboot 554 the system, ultimately returning the path of execution back to the 555 first-stage bootloader. It MUST NOT reboot the system once the 556 thread of execution has been passed to the host operating system (at 557 which point, this timeout is effectively obviated). 558 559 If the value of this option is zero, the second-stage bootloader MUST 560 NOT schedule such a timeout at all. Any second-stage bootloader that 561 finds it has encountered excessive timeouts attempting to obtain its 562 host operating system SHOULD disconnect itself from the network to 563 wait for operator intervention, but MAY continue to attempt to 564 acquire the host operating system indefinitely. 565 566 567 568 569 570 571 Hankins Informational [Page 10] 572 574 RFC 5071 PXELINUX Options December 2007 575 576 577 7. Specification Conformance 578 579 To conform to this specification, clients and servers MUST implement 580 the Configuration File, Path Prefix, and Reboot Time options as 581 directed. 582 583 The MAGIC option MAY NOT be implemented, as it has been deprecated. 584 585 8. Security Considerations 586 587 PXE and PXELINUX allow any entity acting as a DHCP server to execute 588 arbitrary code upon a system. At present, no PXE implementation is 589 known to implement authentication mechanisms [7] so that PXE clients 590 can be sure they are receiving configuration information from the 591 correct, authoritative DHCP server. 592 593 The use of TFTP by PXE and PXELINUX also lacks any form of 594 cryptographic signature -- so a 'Man in the Middle' attack may lead 595 to an attacker's code being executed on the client system. Since 596 this is not an encrypted channel, any of the TFTP loaded data may 597 also be exposed (such as in loading a "RAMDISK" image, which contains 598 /etc/passwd or similar information). 599 600 The use of the Ethernet MAC Address as the client's unique identity 601 may allow an attacker who takes on that identity to gain 602 inappropriate access to a client system's network resources by being 603 given by the DHCP server whatever 'keys' are required, in fact, to be 604 the target system (to boot up as though it were the target). 605 606 Great care should be taken to secure PXE and PXELINUX installations, 607 such as by using IP firewalls, to reduce or eliminate these concerns. 608 609 A nearby attacker might feed a "Reboot Time" option value of 1 second 610 to a mass of unsuspecting clients, to effect a Denial Of Service 611 (DoS) upon the DHCP server, but then again it may just as easily 612 supply these clients with rogue second-stage bootloaders that simply 613 transmit a flood of packets. 614 615 This document in and by itself provides no security, nor does it 616 impact existing DCHP security as described in RFC 2131 [3]. 617 618 9. IANA Considerations 619 620 IANA has done the following: 621 622 1. Moved DHCPv4 Option code 208 from 'Tentatively Assigned' to 623 'Assigned', referencing this document. IANA has marked this same 624 option code, 208, as Deprecated. 625 626 627 628 Hankins Informational [Page 11] 629 631 RFC 5071 PXELINUX Options December 2007 632 633 634 2. Moved DHCPv4 Option code 209 from 'Tentatively Assigned' to 635 'Assigned', referencing this document. 636 637 3. Moved DHCPv4 Option code 210 from 'Tentatively Assigned' to 638 'Assigned', referencing this document. 639 640 4. Moved DHCPv4 Option code 211 from 'Tentatively Assigned' to 641 'Assigned', referencing this document. 642 643 10. Acknowledgements 644 645 These options were designed and implemented for the PXELINUX project 646 by H. Peter Anvin, and he was instrumental in producing this 647 document. Shane Kerr has also provided feedback that has improved 648 this document. 649 650 11. References 651 652 11.1. Normative References 653 654 [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", 655 STD 8, RFC 854, May 1983. 656 657 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 658 Levels", BCP 14, RFC 2119, March 1997. 659 660 [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 661 March 1997. 662 663 [4] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 664 Extensions", RFC 2132, March 1997. 665 666 [5] Droms, R., "Procedures and IANA Guidelines for Definition of New 667 DHCP Options and Message Types", BCP 43, RFC 2939, 668 September 2000. 669 670 11.2. Informative References 671 672 [6] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, 673 July 1992. 674 675 [7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 676 RFC 3118, June 2001. 677 678 [8] Volz, B., "Reclassifying Dynamic Host Configuration Protocol 679 version 4 (DHCPv4) Options", RFC 3942, November 2004. 680 681 682 683 684 685 Hankins Informational [Page 12] 686 688 RFC 5071 PXELINUX Options December 2007 689 690 691 Author's Address 692 693 David W. Hankins 694 Internet Systems Consortium, Inc. 695 950 Charter Street 696 Redwood City, CA 94063 697 US 698 699 Phone: +1 650 423 1307 700 EMail: David_Hankins (a] isc.org 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 Hankins Informational [Page 13] 743 745 RFC 5071 PXELINUX Options December 2007 746 747 748 Full Copyright Statement 749 750 Copyright (C) The IETF Trust (2007). 751 752 This document is subject to the rights, licenses and restrictions 753 contained in BCP 78, and except as set forth therein, the authors 754 retain all their rights. 755 756 This document and the information contained herein are provided on an 757 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 758 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 759 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 760 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 761 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 762 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 763 764 Intellectual Property 765 766 The IETF takes no position regarding the validity or scope of any 767 Intellectual Property Rights or other rights that might be claimed to 768 pertain to the implementation or use of the technology described in 769 this document or the extent to which any license under such rights 770 might or might not be available; nor does it represent that it has 771 made any independent effort to identify any such rights. Information 772 on the procedures with respect to rights in RFC documents can be 773 found in BCP 78 and BCP 79. 774 775 Copies of IPR disclosures made to the IETF Secretariat and any 776 assurances of licenses to be made available, or the result of an 777 attempt made to obtain a general license or permission for the use of 778 such proprietary rights by implementers or users of this 779 specification can be obtained from the IETF on-line IPR repository at 780 http://www.ietf.org/ipr. 781 782 The IETF invites any interested party to bring to its attention any 783 copyrights, patents or patent applications, or other proprietary 784 rights that may cover technology that may be required to implement 785 this standard. Please address the information to the IETF at 786 ietf-ipr (a] ietf.org. 787 788 789 790 791 792 793 794 795 796 797 798 799 Hankins Informational [Page 14] 800 802
