doc/rfc5071.txt

   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 \f
  60 RFC 5071                    PXELINUX Options               December 2007
  61
  62
  63 Table 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
 114 Hankins                      Informational                      [Page 2]
 115 \f
 116 RFC 5071                    PXELINUX Options               December 2007
 117
 118
 119 1.  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
 170 Hankins                      Informational                      [Page 3]
 171 \f
 172 RFC 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
 183 2.  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
 203 3.  MAGIC Option
 204
 205 3.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
 226 Hankins                      Informational                      [Page 4]
 227 \f
 228 RFC 5071                    PXELINUX Options               December 2007
 229
 230
 231 3.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
 242 3.3.  Applicability
 243
 244    This option is absolutely inapplicable to any other purpose.
 245
 246 3.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
 264 4.  Configuration File Option
 265
 266 4.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
 282 Hankins                      Informational                      [Page 5]
 283 \f
 284 RFC 5071                    PXELINUX Options               December 2007
 285
 286
 287 4.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
 300 4.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
 307 4.4.  Response to RFC 3942
 308
 309    The code 209 will be adopted for this purpose.
 310
 311 4.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
 338 Hankins                      Informational                      [Page 6]
 339 \f
 340 RFC 5071                    PXELINUX Options               December 2007
 341
 342
 343 5.  Path Prefix Option
 344
 345 5.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
 363 5.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
 375 5.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
 394 Hankins                      Informational                      [Page 7]
 395 \f
 396 RFC 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
 417 5.4.  Response to RFC 3942
 418
 419    The code 210 will be adopted for this purpose.
 420
 421 5.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
 450 Hankins                      Informational                      [Page 8]
 451 \f
 452 RFC 5071                    PXELINUX Options               December 2007
 453
 454
 455 6.  Reboot Time Option
 456
 457 6.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
 485 6.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
 506 Hankins                      Informational                      [Page 9]
 507 \f
 508 RFC 5071                    PXELINUX Options               December 2007
 509
 510
 511 6.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
 525 6.4.  Response to RFC 3942
 526
 527    The code 211 will be adopted for this purpose.
 528
 529 6.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
 562 Hankins                      Informational                     [Page 10]
 563 \f
 564 RFC 5071                    PXELINUX Options               December 2007
 565
 566
 567 7.  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
 575 8.  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
 608 9.  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
 618 Hankins                      Informational                     [Page 11]
 619 \f
 620 RFC 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
 632 10.  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
 639 11.  References
 640
 641 11.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
 659 11.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
 674 Hankins                      Informational                     [Page 12]
 675 \f
 676 RFC 5071                    PXELINUX Options               December 2007
 677
 678
 679 Author'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
 730 Hankins                      Informational                     [Page 13]
 731 \f
 732 RFC 5071                    PXELINUX Options               December 2007
 733
 734
 735 Full 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
 751 Intellectual 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
 786 Hankins                      Informational                     [Page 14]
 787 \f