ietf-corpus

rfc-1497

BOOTP Vendor Information Extensions

J. Reynolds
date1993-08 streamLegacy statusDRAFT STANDARD pages8 canonicalhttps://www.rfc-editor.org/rfc/rfc1497 doi10.17487/RFC1497
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 is a status report on the vendor information extensions used in the Bootstrap Protocol (BOOTP).

obsoleted by

obsoletes

updates

Extracted elements (29)

design-rationale §Comparison to Alternative Approaches

The BOOTP approach retains an advantage when all needed configuration can be returned in a single reply and consumed from a local table, and when an administrator needs centralized control over which hosts use which servers — a level of control that the multicast approach (which gives each server authority over which hosts to serve) cannot provide.

design-rationale §Comparison to Alternative Approaches

The document acknowledges that IP multicast would be a superior alternative to BOOTP extensions for service discovery: it eliminates dependency on a potentially unavailable or incorrect BOOTP server, reduces administrative overhead of keeping the BOOTP database current, and can reduce packet traffic. The main drawback is that IP multicasting was not widely implemented at the time.

multicast

design-rationale §BOOTP Vendor Information Format

The Extensions Path field (Tag 18) was introduced to overcome the 64-byte size constraint on the BOOTP vendor field, allowing an unconstrained-length file retrieved via TFTP to carry additional vendor extension data interpreted by the same rules.

interoperability-note §Extensions

Tag types 19–127 are defined as generic and unassigned; implementation-specific use without IANA registration risks conflict with other implementations using the same tag values for different purposes.

normative-requirement §BOOTP Vendor Information Format MUST NOT

All instances of Tag 18 (Extensions Path) within a TFTP extensions file must be ignored to prevent recursive or circular references.

normative-requirement §Extensions SHOULD

Care must be taken when selecting information for the vendor-specific area not to exceed the 64-byte length restriction; non-essential information may be excluded.

normative-requirement §Extensions REQUIRED

Implementation-specific use of undefined generic tag types in the range 19–127 may conflict with other implementations; registration with IANA is required.

registry

normative-requirement §BOOTP Vendor Information Format MUST

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

ip

protocol-element §BOOTP Vendor Information Format

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

dns

protocol-element §BOOTP Vendor Information Format

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

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

Extensions Path Field (Tag 18, Data: N bytes): Introduced in this edition; specifies a TFTP-retrievable file whose content is interpreted identically to the 64-octet vendor-extension field, except that the file length is unconstrained and any Tag 18 references within the file are ignored.

protocol-element §BOOTP Vendor Information Format

Gateway Field (Tag 3, Data: N address bytes): Specifies IP addresses of N/4 gateways for the subnet. If a preferred gateway exists, it should appear first.

ip, routing

protocol-element §BOOTP Vendor Information Format

Hostname Field (Tag 12, Data: N bytes): Specifies the name of the client; whether domain-qualified is site-specific.

dns

protocol-element §BOOTP Vendor Information Format

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

dns

protocol-element §BOOTP Vendor Information Format

Log Server Field (Tag 7, Data: N address bytes): Specifies IP addresses of N/4 MIT-LCS UDP log servers.

syslog

protocol-element §BOOTP Vendor Information Format

LPR Server Field (Tag 9, Data: N address bytes): Specifies IP addresses of N/4 Berkeley 4BSD printer servers.

protocol-element §BOOTP Vendor Information Format

Pad Field (Tag 0, no data): A single tag octet 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, Data: N bytes): Site-specific information interpreted on an implementation-specific basis; should follow all data with generic tags 0–127.

protocol-element §BOOTP Vendor Information Format

RLP Server Field (Tag 11, Data: N address bytes): Specifies IP addresses of N/4 Resource Location Protocol servers per RFC-887.

protocol-element §BOOTP Vendor Information Format

Root Path Field (Tag 17, Data: N bytes): A string specifying a pathname to mount as a root disk.

protocol-element §BOOTP Vendor Information Format

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

ip

protocol-element §BOOTP Vendor Information Format

Time Offset Field (Tag 2, Data: 4 bytes): Specifies the local subnet's offset from UTC in seconds as a signed 32-bit integer.

ntp

protocol-element §BOOTP Vendor Information Format

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

ntp

registry §Extensions

IANA maintains the registry of BOOTP vendor information extension tags. New generic data fields in the range 19–127 must be registered with IANA; contact is iana@isi.edu.

registry

security-consideration §Security Considerations

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

security

wire-format §BOOTP Vendor Information Format

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

wire-format §BOOTP Vendor Information Format

The first four bytes of the 64-octet vendor information field are reserved for the 'magic cookie' with value 99.130.83.99 (hex 63.82.53.63) in network byte order, identifying the interpretation mode for the succeeding data.

snmp

wire-format §BOOTP Vendor Information Format

The vendor information field is 64 octets and is structured as free-format, length-tagged sub-fields. Lengths are exclusive of the tag and length octets; all multi-byte quantities are in network byte order.