ietf-corpus

rfc-1395

BOOTP Vendor Information Extensions

J. Reynolds
date1993-01 streamLegacy statusDRAFT STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc1395 doi10.17487/RFC1395
This RFC is a slight revision and extension of RFC-1048 by Philip Prindeville, who should be credited with the original work in this memo. This memo will be updated as additional tags are defined. This edition introduces Tag 14 for Merit Dump File, Tag 15 for Domain Name, Tag 16 for Swap Server and Tag 17 for Root Path. This memo is a status report on the vendor information extensions used int the Bootstrap Protocol (BOOTP).

obsoleted by

obsoletes

updates

Extracted elements (27)

design-rationale §Comparison to Alternative Approaches

IP multicast was considered as an alternative to BOOTP extensions for locating network services; multicast eliminates dependence on a BOOTP server, reduces administrative overhead, and can be more efficient. The main drawback cited is that IP multicasting was not widely implemented at the time of this RFC.

multicast

design-rationale §Comparison to Alternative Approaches

The BOOTP approach is most efficient when all configuration information needed by a client host is returned in a single BOOTP reply, allowing each software module to read from a local table rather than issuing individual service discovery requests.

interoperability-note §Extensions

Use of undefined generic tag types (range 18-127) without registration may conflict with other BOOTP implementations. Nonessential options such as hostname and quote-of-the-day server may be omitted and discovered later via RLP or DNS WKS records.

normative-requirement §Extensions REQUIRED

Implementation-specific use of undefined generic tag types in the range 18-127 may conflict with other implementations, and registration with IANA is required before using these tags.

registry

normative-requirement §BOOTP Vendor Information Format MUST

The Subnet Mask field (Tag 1) MUST precede the Gateway field (Tag 3) in the vendor information area if both are present.

ip

normative-requirement §Extensions MUST

When selecting information for the vendor-specific area, care must be taken not to exceed the 64-byte length restriction of the BOOTP vendor information field.

protocol-element §BOOTP Vendor Information Format

Boot File Size Field (Tag 13, 2 bytes): A two-octet network-order value specifying the number of 512-octet blocks in the default boot file, informing the BOOTP client of the boot image size.

protocol-element §BOOTP Vendor Information Format

Domain Name Server Field (Tag 6, N address bytes): Specifies the IP addresses of N/4 DNS domain name servers per RFC-1034.

dns

protocol-element §BOOTP Vendor Information Format

Domain Name (Tag 15, N bytes): Specifies the domain name of the client for DNS resolution per RFC-1034. Introduced in this edition of the RFC.

dns

protocol-element §BOOTP Vendor Information Format

End Field (Tag 255, no data): Marks the end of usable data in the vendor information area; the remainder of the field should be filled with PAD (zero) octets.

protocol-element §BOOTP Vendor Information Format

Gateway Field (Tag 3, N address bytes): Specifies the IP addresses of N/4 gateways for the subnet; if one gateway is preferred, it should appear first in the list.

ip

protocol-element §BOOTP Vendor Information Format

Hostname Field (Tag 12, N bytes): Specifies the name of the client; the name may or may not be domain-qualified, which is a site-specific decision.

dns

protocol-element §BOOTP Vendor Information Format

IEN-116 Name Server Field (Tag 5, N address bytes): Specifies the IP addresses of N/4 IEN-116 name servers.

dns

protocol-element §BOOTP Vendor Information Format

Log Server Field (Tag 7, N bytes), Cookie/Quote Server Field (Tag 8, N bytes), LPR Server Field (Tag 9, N bytes), Impress Server Field (Tag 10, N bytes), and RLP Server Field (Tag 11, N bytes) each specify the IP addresses of N/4 servers of their respective type.

protocol-element §BOOTP Vendor Information Format

Merit Dump File (Tag 14, N bytes): Specifies the name of a file to which this client's core should be dumped. Introduced in this edition of the RFC.

protocol-element §BOOTP Vendor Information Format

Pad Field (Tag 0, no data): A single-octet padding tag with no associated data, used to align subsequent fields to word boundaries required by the target machine.

protocol-element §BOOTP Vendor Information Format

Reserved Fields (Tags 128-254, N bytes): Reserved for additional site-specific information interpreted on an implementation-specific basis; these should follow all data using generic tags 0-127.

protocol-element §BOOTP Vendor Information Format

Root Path (Tag 17, N bytes): A string specifying a pathname to mount as a root disk. Introduced in this edition of the RFC.

protocol-element §BOOTP Vendor Information Format

Subnet Mask Field (Tag 1, 4 bytes): Specifies the net and local subnet mask per RFC-950. This field must precede the Gateway field if both are present.

ip

protocol-element §BOOTP Vendor Information Format

Swap Server (Tag 16, 4 bytes): Carries the IP address of a swap server for the client. Introduced in this edition of the RFC.

ip

protocol-element §BOOTP Vendor Information Format

Time Offset Field (Tag 2, 4 bytes): Specifies the signed 32-bit integer offset of the local subnet in seconds from Coordinated Universal Time (UTC).

ntp

protocol-element §BOOTP Vendor Information Format

Time Server Field (Tag 4, N address bytes): Specifies the IP addresses of N/4 time servers per RFC-868.

ntp

registry §Extensions

Additional generic data field tags may be registered by contacting IANA (iana@isi.edu). Registration is required for any use of generic tag types in the range 18-127 to avoid implementation conflicts.

registry

security-consideration §Security Considerations

Security issues are explicitly not discussed in this memo; no authentication or integrity mechanisms are specified for BOOTP vendor information extensions.

security

wire-format §BOOTP Vendor Information Format

Fixed-length fields with no data consist of a single tag octet only (e.g., Pad, End); fixed-length fields with data consist of one tag octet, one length octet, and length octets of data.

wire-format §BOOTP Vendor Information Format

The 64-octet vendor information field uses a free-format, length-tagged sub-field encoding. Each variable-length sub-field consists of one tag octet, one length octet, and length octets of data; lengths are exclusive of tag and length octets; all multi-byte quantities are in network byte order.

wire-format §BOOTP Vendor Information Format

The vendor information area begins with a 4-octet 'magic cookie' with value 99.130.83.99 (hex 63.82.53.63) in network byte order, identifying the interpretation mode for the subsequent vendor data.

dns, ip