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