RFC 2132
DHCP Options and BOOTP Vendor Extensions
RFC 2132: DHCP Options and BOOTP Vendor Extensions ๐
Okay bestie, this is the RFC that lists all the DHCP options and BOOTP vendor extensions. Here's the title block ๐
- Network Working Group ๐ธ
- Authors: S. Alexander (Silicon Graphics, Inc.) and R. Droms (Bucknell University) ๐ง
- Category: Standards Track โจ
- Date: March 1997 ๐
- Obsoletes: RFC 1533 ๐
Status of this memo ๐
Okay so this document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements ๐ซถ If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ๐
Abstract ๐ฆ
The Dynamic Host Configuration Protocol (DHCP) [1] gives us a framework for passing configuration info to hosts on a TCP/IP network ๐ The config parameters and other control info ride along in tagged data items that get stored in the 'options' field of the DHCP message. Those data items are also called "options," and yes, they're iconic ๐
This document lists the current set of DHCP options. Future options will get their own RFCs ๐ The current list of valid options also lives at ftp://ftp.isi.edu/in-notes/iana/assignments [22] ๐
All of the vendor information extensions in RFC 1497 [2] can be used as DHCP options. RFC 1497's definitions are included in this doc, and this doc supersedes RFC 1497 ๐ซถ Every DHCP option defined here can also be used as a BOOTP vendor information extension, except for the ones specific to DHCP in section 9 ๐
Table of Contents ๐๏ธ
1. Introduction .............................................. 2
2. BOOTP Extension/DHCP Option Field Format .................. 4
3. RFC 1497 Vendor Extensions ................................ 5
4. IP Layer Parameters per Host .............................. 11
5. IP Layer Parameters per Interface ........................ 13
6. Link Layer Parameters per Interface ....................... 16
7. TCP Parameters ............................................ 17
8. Application and Service Parameters ........................ 18
9. DHCP Extensions ........................................... 25
10. Defining new extensions ................................... 31
11. Acknowledgements .......................................... 31
12. References ................................................ 32
13. Security Considerations ................................... 33
14. Authors' Addresses ........................................ 341. Introduction โจ
Okay, so this doc has options for both the Dynamic Host Configuration Protocol and the Bootstrap Protocol ๐
The full DHCP packet formats are in the DHCP specification [1], and the full BOOTP packet formats are in the BOOTP specification [3]. This document defines the format of the info in the last field of DHCP packets ('options') and of BOOTP packets ('vend'). The rest of this section sets up a generalized way to use that area, for giving info that's useful to a wide range of machines, operating systems and configs. Sites with one DHCP or BOOTP server shared among heterogeneous clients can choose to define other, site-specific formats for the 'options' field ๐ง
Section 2 describes the formats of DHCP options and BOOTP vendor extensions. Section 3 covers options defined in earlier docs for use with BOOTP (all of which can also be used with DHCP). Sections 4-8 define new options meant for both DHCP and BOOTP. Section 9 defines options used only in DHCP ๐ธ
References that further describe most of the options in sections 2-6 are in section 12. The use of the options in section 9 is described in the DHCP specification [1] ๐
Info on registering new options is in section 10 ๐
This document updates the definition of DHCP/BOOTP options from RFC1533. The classing mechanism now includes vendor classes, as described in section 8.4 and 9.13 ๐ฆ The new procedure for defining new DHCP/BOOTP options is described in section 10. Several new options were added, including NIS+ domain and servers, Mobile IP home agent, SMTP server, TFTP server and Bootfile server ๐ Text giving definitions used throughout the doc was added in section 1.1. Text stressing that client-identifiers need to be unique was added to section 9.14 ๐
1.1 Requirements ๐
Throughout this doc, the words that define how important a requirement is get capitalized. Here they are, with what each one means ๐ซถ
- "MUST" ๐ This word or the adjective "REQUIRED" means the item is an absolute requirement of this specification.
- "MUST NOT" ๐ This phrase means the item is an absolute prohibition of this specification.
- "SHOULD" โจ This word or the adjective "RECOMMENDED" means there may be valid reasons in particular circumstances to ignore this item. But the full implications should be understood and the case carefully weighed before choosing a different course.
- "SHOULD NOT" ๐ This phrase means there may be valid reasons in particular circumstances when the listed behavior is acceptable or even useful. But the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
- "MAY" ๐ฆ This word or the adjective "OPTIONAL" means this item is truly optional. One vendor may include the item because a particular marketplace requires it or because it enhances the product, for example. Another vendor may omit the same item ๐
1.2 Terminology ๐
This document uses the following terms ๐
- "DHCP client" ๐ง A DHCP client, or "client," is an Internet host that uses DHCP to get config parameters such as a network address.
- "DHCP server" ๐ A DHCP server (or "server") is an Internet host that returns config parameters to DHCP clients.
- "binding" ๐ A binding is a collection of config parameters, including at least an IP address, that is associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers ๐ซถ
2. BOOTP Extension/DHCP Option Field Format ๐ธ
Okay, so DHCP options have the same format as the BOOTP 'vendor extensions' defined in RFC 1497 [2] ๐ Options can be fixed length or variable length. Every option starts with a tag octet, which uniquely identifies the option. Fixed-length options without data are just a tag octet. Only options 0 and 255 are fixed length. Every other option is variable-length, with a length octet right after the tag octet. The value of the length octet doesn't count the two octets for the tag and length. The length octet is followed by "length" octets of data ๐ฆ
Options with NVT ASCII data SHOULD NOT include a trailing NULL. However, the receiver of those options MUST be ready to delete trailing nulls if they show up. The receiver MUST NOT require a trailing null to be included in the data. For some variable-length options the length field is a constant, but it still has to be specified ๐
Any options defined after this document MUST contain a length octet, even if the length is fixed or zero ๐ซถ
All multi-octet quantities are in network byte-order ๐ฆ
When used with BOOTP, the first four octets of the vendor information field are assigned to the "magic cookie" (as suggested in RFC 951). This field tells you the mode in which the data that follows should be interpreted. The magic cookie is the 4 octet dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in network byte order ๐ฎ
99.130.83.99(decimal, dotted) =63.82.53.63(hexadecimal, dotted)
All of the "vendor extensions" defined in RFC 1497 are also DHCP options ๐
Option codes 128 to 254 (decimal) are reserved for site-specific options ๐ง
Except for the options in section 9, every option can be used with either DHCP or BOOTP ๐
Lots of these options have default values specified in other docs. RFC 1122 [4] specifies default values for most IP and TCP config parameters ๐
Many options supply one or more 32-bit IP addresses. Using IP addresses instead of fully-qualified Domain Names (FQDNs) may make future renumbering of IP hosts harder. The doc discourages using these addresses at sites that may need renumbering ๐
3. RFC 1497 Vendor Extensions ๐
This section lists the vendor extensions defined in RFC 1497. They're defined here for completeness ๐
3.1. Pad Option ๐ซง
The pad option can be used to make subsequent fields align on word boundaries ๐ธ
The code for the pad option is 0, and its length is 1 octet ๐ง
Code
+-----+
| 0 |
+-----+3.2. End Option ๐
The end option marks the end of valid info in the vendor field. Subsequent octets should be filled with pad options ๐ฆ
The code for the end option is 255, and its length is 1 octet ๐
Code
+-----+
| 255 |
+-----+3.3. Subnet Mask ๐ญ
The subnet mask option specifies the client's subnet mask, as per RFC 950 [5] ๐ซถ
If both the subnet mask and the router option are specified in a DHCP reply, the subnet mask option MUST be first ๐
The code for the subnet mask option is 1, and its length is 4 octets ๐
Code Len Subnet Mask
+-----+-----+-----+-----+-----+-----+
| 1 | 4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+3.4. Time Offset โฐ
The time offset field specifies the offset of the client's subnet in seconds from Coordinated Universal Time (UTC). The offset is a two's complement 32-bit integer. A positive offset means a location east of the zero meridian, and a negative offset means a location west of the zero meridian ๐
The code for the time offset option is 2, and its length is 4 octets ๐
Code Len Time Offset
+-----+-----+-----+-----+-----+-----+
| 2 | 4 | n1 | n2 | n3 | n4 |
+-----+-----+-----+-----+-----+-----+3.5. Router Option ๐ฐ๏ธ
The router option specifies a list of IP addresses for routers on the client's subnet. Routers SHOULD be listed in order of preference ๐ซถ
The code for the router option is 3. The minimum length for the router option is 4 octets, and the length MUST always be a multiple of 4 โจ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.6. Time Server Option ๐ฐ๏ธ
The time server option specifies a list of RFC 868 [6] time servers available to the client. Servers SHOULD be listed in order of preference ๐
The code for the time server option is 4. The minimum length for this option is 4 octets, and the length MUST always be a multiple of 4 ๐ธ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.7. Name Server Option โจ
okay so the name server option hands the client a list of IEN 116 [7] name servers it can use ๐ฅ๏ธ Servers SHOULD be listed in order of preference. bestie, that ordering is a whole vibe ๐
the code is 5, the minimum length is 4 octets, and the length MUST always be a multiple of 4. lowkey iconic layout ๐ฆ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.8. Domain Name Server Option ๐ธ
the domain name server option gives the client a list of Domain Name System (STD 13, RFC 1035 [8]) name servers ๐ again, servers SHOULD be listed in order of preference. the ordering keeps showing up, so it's clearly important ๐ซถ
the code is 6, the minimum length is 4 octets, and the length MUST always be a multiple of 4. same energy as the last one, literally ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.9. Log Server Option ๐
the log server option lists MIT-LCS UDP log servers the client can use ๐ Servers SHOULD be listed in order of preference. ๐
the code is 7, the minimum length is 4 octets, and the length MUST always be a multiple of 4 โจ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.10. Cookie Server Option ๐ช
this one gives the client a list of RFC 865 [9] cookie servers ๐ฅ Servers SHOULD be listed in order of preference. the vibes are immaculate ๐
the code line in this section says "log server option" and the number is 8. minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐ง
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.11. LPR Server Option ๐จ๏ธ
the LPR server option points the client at a list of RFC 1179 [10] line printer servers ๐ Servers SHOULD be listed in order of preference. ๐
code 9, minimum length 4 octets, and the length MUST always be a multiple of 4. printing has never looked this cute โจ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.12. Impress Server Option ๐
this option gives a list of Imagen Impress servers available to the client ๐๏ธ Servers SHOULD be listed in order of preference. ๐ซถ
the code is 10. minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.13. Resource Location Server Option ๐บ๏ธ
this option lists RFC 887 [11] Resource Location servers for the client ๐ Servers SHOULD be listed in order of preference. literally the most consistent option in the whole doc, I'm obsessed ๐ญ
code 11, minimum length 4 octets, and the length MUST always be a multiple of 4 ๐ฆ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.14. Host Name Option ๐ท๏ธ
this option tells everyone the name of the client ๐งธ the name may or may not be qualified with the local domain name. if you want the preferred way to get the domain name, check section 3.17 โจ and for character set restrictions, see RFC 1035 ๐
the code is 12, and its minimum length is 1 ๐
Code Len Host Name
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--3.15. Boot File Size Option ๐ฆ
this option says how big the default boot image is for the client, measured in 512-octet blocks ๐ง the file length is an unsigned 16-bit integer, so no drama there ๐
the code is 13, and its length is 2 โจ
Code Len File Size
+-----+-----+-----+-----+
| 13 | 2 | l1 | l2 |
+-----+-----+-----+-----+3.16. Merit Dump File ๐ซ
this option names the path of a file where the client's core image gets dumped if the client crashes ๐ the path is a character string made of characters from the NVT ASCII character set, which is very serious and very correct ๐ซก
the code is 14, and its minimum length is 1 ๐ธ
Code Len Dump File Pathname
+-----+-----+-----+-----+-----+-----+---
| 14 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---3.17. Domain Name ๐
this option gives the domain name the client should use when resolving hostnames through the Domain Name System ๐ main character energy, honestly ๐
the code is 15, and its minimum length is 1 ๐
Code Len Domain Name
+-----+-----+-----+-----+-----+-----+--
| 15 | n | d1 | d2 | d3 | d4 | ...
+-----+-----+-----+-----+-----+-----+--3.18. Swap Server ๐
this specifies the IP address of the client's swap server ๐ซง
the code is 16 and its length is 4 ๐ฆ
Code Len Swap Server Address
+-----+-----+-----+-----+-----+-----+
| 16 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+3.19. Root Path ๐ณ
this option names the path where the client's root disk lives ๐พ the path is a character string made of characters from the NVT ASCII character set ๐ค
the code is 17, and its minimum length is 1 ๐ง
Code Len Root Disk Pathname
+-----+-----+-----+-----+-----+-----+---
| 17 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---3.20. Extensions Path ๐๏ธ
okay so this is a string naming a file you can grab over TFTP ๐ that file holds info that gets read the same way as the 64-octet vendor-extension field in the BOOTP response, with a couple of exceptions ๐
- the length of the file is unconstrained;
- all references to Tag 18 (i.e., instances of the BOOTP Extensions Path field) within the file are ignored.
the code is 18, and its minimum length is 1 โจ
Code Len Extensions Pathname
+-----+-----+-----+-----+-----+-----+---
| 18 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---4. IP Layer Parameters per Host ๐
this section covers the options that affect how the IP layer works on a per-host basis ๐ฅ๏ธโจ
4.1. IP Forwarding Enable/Disable Option ๐
this option says whether the client should set up its IP layer for packet forwarding. a value of 0 means disable IP forwarding, and a value of 1 means enable IP forwarding ๐
the code is 19, and its length is 1 ๐
Code Len Value
+-----+-----+-----+
| 19 | 1 | 0/1 |
+-----+-----+-----+4.2. Non-Local Source Routing Enable/Disable Option ๐งญ
this option says whether the client should set up its IP layer to allow forwarding of datagrams with non-local source routes. if you want the discussion of this topic, see Section 3.3.5 of [4] ๐ a value of 0 means disallow forwarding of such datagrams, and a value of 1 means allow forwarding ๐
the code is 20, and its length is 1 ๐
Code Len Value
+-----+-----+-----+
| 20 | 1 | 0/1 |
+-----+-----+-----+4.3. Policy Filter Option ๐ก๏ธ
this option sets policy filters for non-local source routing ๐ฆ the filters are a list of IP addresses and masks, which are destination/mask pairs used to filter incoming source routes ๐ซถ
any source routed datagram whose next-hop address does not match one of the filters should be discarded by the client ๐๏ธ
see [4] for further information ๐
the code is 21. the minimum length is 8, and the length MUST be a multiple of 8 โจ
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Address 2 Mask 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---4.4. Maximum Datagram Reassembly Size ๐งฉ
this option sets the maximum size datagram the client should be ready to reassemble ๐ฆ the size is a 16-bit unsigned integer. the minimum legal value is 576 ๐
the code is 22, and its length is 2 ๐ธ
Code Len Size
+-----+-----+-----+-----+
| 22 | 2 | s1 | s2 |
+-----+-----+-----+-----+4.5. Default IP Time-to-live โณ
this option sets the default time-to-live the client should use on outgoing datagrams โ๏ธ the TTL is an octet with a value between 1 and 255 ๐ข
the code is 23, and its length is 1 ๐
Code Len TTL
+-----+-----+-----+
| 23 | 1 | ttl |
+-----+-----+-----+4.6. Path MTU Aging Timeout Option ๐ฐ๏ธ
this option sets the timeout, in seconds, used when aging Path MTU values found by the mechanism in RFC 1191 [12] ๐ท the timeout is a 32-bit unsigned integer ๐ซง
the code is 24, and its length is 4 ๐
Code Len Timeout
+-----+-----+-----+-----+-----+-----+
| 24 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+4.7. Path MTU Plateau Table Option ๐ช
this option gives a table of MTU sizes to use when doing Path MTU Discovery as defined in RFC 1191 ๐ the table is a list of 16-bit unsigned integers, ordered from smallest to largest ๐ the minimum MTU value cannot be smaller than 68 ๐
the code is 25. its minimum length is 2, and the length MUST be a multiple of 2 ๐
Code Len Size 1 Size 2
+-----+-----+-----+-----+-----+-----+---
| 25 | n | s1 | s2 | s1 | s2 | ...
+-----+-----+-----+-----+-----+-----+---5. IP Layer Parameters per Interface ๐
this section covers the options that affect how the IP layer works on a per-interface basis โจ it is expected that a client can issue multiple requests, one per interface, so each interface can get its own specific parameters ๐ซถ
5.1. Interface MTU Option ๐ง
this option sets the MTU to use on this interface ๐ the MTU is an unsigned 16-bit integer, and the minimum legal value for the MTU is 68 ๐
the code is 26, and its length is 2 โจ
Code Len MTU
+-----+-----+-----+-----+
| 26 | 2 | m1 | m2 |
+-----+-----+-----+-----+5.2. All Subnets are Local Option ๐ธ
okay so this one is all about whether the client can just assume that every subnet on its IP network uses the same MTU as the subnet it's directly plugged into ๐ฆ a value of 1 means yes, they all share the same MTU, and a value of 0 means bestie should assume some subnets might have smaller MTUs โจ
The code for this option is 27, and its length is 1.
Code Len Value
+-----+-----+-----+
| 27 | 1 | 0/1 |
+-----+-----+-----+5.3. Broadcast Address Option ๐ฃ
this one tells the client which broadcast address is in use on its subnet ๐ the legal values for broadcast addresses are specified in section 3.2.1.3 of [4], so go check that if you're curious ๐ง
The code for this option is 28, and its length is 4.
Code Len Broadcast Address
+-----+-----+-----+-----+-----+-----+
| 28 | 4 | b1 | b2 | b3 | b4 |
+-----+-----+-----+-----+-----+-----+5.4. Perform Mask Discovery Option ๐
this option decides whether the client should do subnet mask discovery using ICMP ๐ a 0 means no mask discovery, and a 1 means yes, go find that mask ๐
The code for this option is 29, and its length is 1.
Code Len Value
+-----+-----+-----+
| 29 | 1 | 0/1 |
+-----+-----+-----+5.5. Mask Supplier Option ๐ง
this is the flip side of the last one ๐ it says whether the client should respond to subnet mask requests using ICMP. A 0 means don't respond, and a 1 means go ahead and respond ๐ซถ
The code for this option is 30, and its length is 1.
Code Len Value
+-----+-----+-----+
| 30 | 1 | 0/1 |
+-----+-----+-----+5.6. Perform Router Discovery Option ๐งญ
this one controls whether the client goes out and solicits routers using the Router Discovery mechanism from RFC 1256 [13] ๐บ๏ธ a 0 means the client should not do router discovery, and a 1 means it should ๐
The code for this option is 31, and its length is 1.
Code Len Value
+-----+-----+-----+
| 31 | 1 | 0/1 |
+-----+-----+-----+5.7. Router Solicitation Address Option ๐ฎ
this option is the address the client sends its router solicitation requests to ๏ฟฝล very specific, very cute ๐
The code for this option is 32, and its length is 4.
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 32 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+5.8. Static Route Option ๐ฃ๏ธ
this option gives the client a list of static routes to install in its routing cache, so it already knows where to go ๐บ๏ธ if you list several routes to the same destination, they go in descending order of priority, so the first one is the VIP ๐
The routes are a list of IP address pairs. The first address is the destination address, and the second address is the router for that destination.
The default route (0.0.0.0) is an illegal destination for a static route. Not allowed, bestie ๐ โโ๏ธ Also see section 3.5 for information about the router option.
The code for this option is 33. The minimum length of this option is 8, and the length MUST be a multiple of 8.
Code Len Destination 1 Router 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Destination 2 Router 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---6. Link Layer Parameters per Interface ๐
this section is the lineup of options that affect the data link layer on a per-interface basis ๐
6.1. Trailer Encapsulation Option ๐๏ธ
this one says whether the client should negotiate trailers (RFC 893 [14]) when it's using ARP ๐ค a 0 means don't try to use trailers, and a 1 means go for it ๐ฅ
The code for this option is 34, and its length is 1.
Code Len Value
+-----+-----+-----+
| 34 | 1 | 0/1 |
+-----+-----+-----+6.2. ARP Cache Timeout Option โฐ
this option sets how long ARP cache entries live, in seconds ๐ฐ๏ธ the time is a 32-bit unsigned integer, so it's a whole lotta seconds ๐ญ
The code for this option is 35, and its length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+
| 35 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+6.3. Ethernet Encapsulation Option ๐งฉ
if the interface is an Ethernet, this option picks the encapsulation: Ethernet Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) ๐ a 0 means use RFC 894 encapsulation, and a 1 means use RFC 1042 encapsulation โจ
The code for this option is 36, and its length is 1.
Code Len Value
+-----+-----+-----+
| 36 | 1 | 0/1 |
+-----+-----+-----+7. TCP Parameters ๐ฆ
this section lists the options that affect the TCP layer on a per-interface basis, so it's TCP's glow-up list ๐
7.1. TCP Default TTL Option โณ
this one is the default TTL the client uses when it sends TCP segments ๐ฆ it's an 8-bit unsigned integer, and the minimum value is 1 ๐
The code for this option is 37, and its length is 1.
Code Len TTL
+-----+-----+-----+
| 37 | 1 | n |
+-----+-----+-----+7.2. TCP Keepalive Interval Option ๐
this option is how long, in seconds, the client's TCP waits before it sends a keepalive message on a TCP connection ๐ซถ the time is a 32-bit unsigned integer. A value of zero means the client shouldn't make keepalive messages on connections unless an application specifically asks for them ๐ธ
The code for this option is 38, and its length is 4.
Code Len Time
+-----+-----+-----+-----+-----+-----+
| 38 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+7.3. TCP Keepalive Garbage Option ๐๏ธ
this one is about whether the client sends TCP keepalive messages with one octet of garbage in them, so older implementations stay happy ๐งธ a 0 means no garbage octet, and a 1 means yes, include the garbage octet ๐
The code for this option is 39, and its length is 1.
Code Len Value
+-----+-----+-----+
| 39 | 1 | 0/1 |
+-----+-----+-----+8. Application and Service Parameters ๐ง
this section is a grab bag of miscellaneous options for configuring miscellaneous applications and services ๐
8.1. Network Information Service Domain Option ๐ท๏ธ
this option gives the name of the client's NIS [17] domain ๐ it's a character string made of characters from the NVT ASCII character set ๐ค
The code for this option is 40. Its minimum length is 1.
Code Len NIS Domain Name
+-----+-----+-----+-----+-----+-----+---
| 40 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---8.2. Network Information Servers Option ๐ฅ๏ธ
this one is a list of IP addresses for the NIS servers the client can use ๐ป servers SHOULD be listed in order of preference, so put your fave first ๐
The code for this option is 41. Its minimum length is 4, and the length MUST be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.3. Network Time Protocol Servers Option โฑ๏ธ
this option is a list of IP addresses for NTP [18] servers the client can reach ๐ again, servers SHOULD be listed in order of preference ๐ท
The code for this option is 42. Its minimum length is 4, and the length MUST be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.4. Vendor Specific Information ๐ญ
okay this one is a whole saga ๐ it's how clients and servers swap vendor-specific info. The info is an opaque object of n octets, which is basically a mystery box that only vendor code knows how to open ๐ the vendor is named in the vendor class identifier option, and the definition is vendor specific ๐
servers that can't interpret the vendor info a client sent MUST ignore it (although it may still get reported) ๐ and clients that don't get the vendor info they wanted SHOULD try to operate without it, though they may do so, and announce that they're doing it, in a degraded mode ๐ญ
if a vendor is packing more than one item into this option, they SHOULD encode it using "Encapsulated vendor-specific options," which goes like this ๐ง
The Encapsulated vendor-specific options field SHOULD be encoded as a sequence of code/length/value fields with the same syntax as the DHCP options field, with these exceptions:
- There SHOULD NOT be a "magic cookie" field in the encapsulated vendor-specific extensions field.
- Codes other than 0 or 255 MAY be redefined by the vendor within the encapsulated vendor-specific extensions field, but they SHOULD conform to the tag-length-value syntax defined in section 2.
- Code 255 (END), if present, signifies the end of the encapsulated vendor extensions, not the end of the vendor extensions field. If no code 255 is present, then the end of the enclosing vendor-specific information field is taken as the end of the encapsulated vendor-specific extensions field.
The code for this option is 43, and its minimum length is 1.
Code Len Vendor-specific information
+-----+-----+-----+-----+---
| 43 | n | i1 | i2 | ...
+-----+-----+-----+-----+---When encapsulated vendor-specific extensions are used, the information bytes 1-n have the following format:
Code Len Data item Code Len Data item Code
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+8.5. NetBIOS over TCP/IP Name Server Option ๐ฎ
this option is a list of NBNS name servers from RFC 1001/1002 [19] [20], listed in order of preference ๐ the minimum length is 4 octets, and the length must always be a multiple of 4 โจ
The code for this option is 44. The minimum length of the option is 4 octets, and the length must always be a multiple of 4.
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----8.6. NetBIOS over TCP/IP Datagram Distribution Server Option
okay so this one hands the client a list of RFC 1001/1002 NBDD servers ๐ listed in order of preference โจ the code is 45, the minimum length is 4 octets, and the length has to always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
| 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----8.7. NetBIOS over TCP/IP Node Type Option
this is the option that lets NetBIOS over TCP/IP clients that can be configured get configured the way RFC 1001/1002 describes ๐ฆ the value is one single octet that tells you the client's node type, and here's the lineup:
Value Node Type
----- ---------
0x1 B-node
0x2 P-node
0x4 M-node
0x8 H-nodequick reminder that the 0x means base-16 (hexadecimal) ๐ง
the code is 46 and the length is always 1 ๐
Code Len Node Type
+-----+-----+-----------+
| 46 | 1 | see above |
+-----+-----+-----------+8.8. NetBIOS over TCP/IP Scope Option
this one carries the NetBIOS over TCP/IP scope parameter for the client, as RFC 1001/1002 lays out ๐ธ if you're wondering what characters are allowed, check [19], [20], and [8] for the character-set restrictions ๐
the code is 47 and the minimum length is 1 โจ
Code Len NetBIOS Scope
+-----+-----+-----+-----+-----+-----+----
| 47 | n | s1 | s2 | s3 | s4 | ...
+-----+-----+-----+-----+-----+-----+----8.9. X Window System Font Server Option
this option gives the client a list of X Window System [21] Font servers it can use ๐ฅ๏ธ servers SHOULD be listed in order of preference, so it's giving organized ๐
the code is 48 and the minimum length is 4 octets. the length MUST be a multiple of 4 ๐ฅ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---8.10. X Window System Display Manager Option
this one lists IP addresses of systems that are running the X Window System Display Manager and are available to the client ๐
addresses SHOULD be listed in order of preference ๐
the code for this option is 49. the minimum length is 4, and the length MUST be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---8.11. Network Information Service+ Domain Option
this option names the client's NIS+ [17] domain ๐ the domain is a character string made of characters from the NVT ASCII character set, so no funny business there โจ
the code is 64 and the minimum length is 1 ๐
Code Len NIS Client Domain Name
+-----+-----+-----+-----+-----+-----+---
| 64 | n | n1 | n2 | n3 | n4 | ...
+-----+-----+-----+-----+-----+-----+---8.12. Network Information Service+ Servers Option
this option gives the client a list of IP addresses for NIS+ servers it can reach ๐ธ servers SHOULD be listed in order of preference, bestie ๐ซถ
the code is 65. the minimum length is 4, and the length MUST be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.13. Mobile IP Home Agent option
this one lists IP addresses of mobile IP home agents that are available to the client ๐ง agents SHOULD be listed in order of preference ๐
the code is 68. the minimum length is 0, which means no home agents are available, and the length MUST be a multiple of 4 ๐ญ it's expected that the usual length is four octets, which holds a single home agent's address ๐ฆ
Code Len Home Agent Addresses (zero or more)
+-----+-----+-----+-----+-----+-----+--
| 68 | n | a1 | a2 | a3 | a4 | ...
+-----+-----+-----+-----+-----+-----+--8.14. Simple Mail Transport Protocol (SMTP) Server Option
this option hands over a list of SMTP servers available to the client ๐ servers SHOULD be listed in order of preference, periodt โจ
the code for the SMTP server option is 69. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐ฅ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.15. Post Office Protocol (POP3) Server Option
this one gives the client a list of POP3 servers ๐ฌ servers SHOULD be listed in order of preference ๐
the code for the POP3 server option is 70. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.16. Network News Transport Protocol (NNTP) Server Option
this option lists NNTP servers that are available to the client ๐๏ธ servers SHOULD be listed in order of preference โจ
the code for the NNTP server option is 71. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.17. Default World Wide Web (WWW) Server Option
this option gives the client a list of WWW servers ๐ servers SHOULD be listed in order of preference, iykyk ๐
the code for the WWW server option is 72. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐ฆ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.18. Default Finger Server Option
this one lists Finger servers that are available to the client ๐ง servers SHOULD be listed in order of preference ๐
the code for the Finger server option is 73. the minimum length is 4 octets, and the length MUST always be a multiple of 4 โญ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.19. Default Internet Relay Chat (IRC) Server Option
this option gives the client a list of IRC servers ๐ฌ servers SHOULD be listed in order of preference, because the group chat has rules ๐ซถ
the code for the IRC server option is 74. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.20. StreetTalk Server Option
this option lists StreetTalk servers available to the client ๐ servers SHOULD be listed in order of preference ๐
the code for the StreetTalk server option is 75. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--8.21. StreetTalk Directory Assistance (STDA) Server Option
this one gives the client a list of STDA servers ๐ servers SHOULD be listed in order of preference, no cap ๐
the code for the StreetTalk Directory Assistance server option is 76. the minimum length is 4 octets, and the length MUST always be a multiple of 4 ๐ธ
Code Len Address 1 Address 2
+-----+-----+-----+-----+-----+-----+-----+-----+--
| 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+--9. DHCP Extensions โจ
this section is all about the options that are specific to DHCP ๐ง
9.1. Requested IP Address
this option shows up in a client request (DHCPDISCOVER) so the client can ask for a particular IP address to be assigned ๐
the code for this option is 50, and its length is 4 ๐
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 50 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+9.2. IP Address Lease Time
this option shows up in a client request (DHCPDISCOVER or DHCPREQUEST) so the client can ask for a lease time on the IP address ๐ฆ in a server reply (DHCPOFFER), the DHCP server uses this option to say what lease time it's willing to offer ๐
the time is in seconds and is written as a 32-bit unsigned integer โฐ
the code for this option is 51, and its length is 4 โจ
Code Len Lease Time
+-----+-----+-----+-----+-----+-----+
| 51 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+9.3. Option Overload
this is the signal that the DHCP 'sname' or 'file' fields are being overloaded, which just means they're secretly carrying DHCP options ๐ a DHCP server adds this option when the returned parameters won't fit in the usual space set aside for options ๐ฅ
if this option is present, the client reads the specified extra fields after it's finished reading the standard option fields ๐ซถ
the code for this option is 52, and its length is 1. the legal values are:
Value Meaning
----- --------
1 the 'file' field is used to hold options
2 the 'sname' field is used to hold options
3 both fields are used to hold options Code Len Value
+-----+-----+-----+
| 52 | 1 |1/2/3|
+-----+-----+-----+9.4 TFTP server name
this option identifies a TFTP server when the 'sname' field in the DHCP header has been used for DHCP options ๐ก
the code for this option is 66, and its minimum length is 1 ๐
Code Len TFTP server
+-----+-----+-----+-----+-----+---
| 66 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---9.5 Bootfile name
this option identifies a bootfile when the 'file' field in the DHCP header has been used for DHCP options ๐งธ
the code for this option is 67, and its minimum length is 1 ๐
Code Len Bootfile name
+-----+-----+-----+-----+-----+---
| 67 | n | c1 | c2 | c3 | ...
+-----+-----+-----+-----+-----+---9.6. DHCP Message Type ๐
okay so this option is how a DHCP message says what kind of message it is ๐ the code is 53 and the length is 1 โจ these are the legal values:
Value Message Type
----- ------------
1 DHCPDISCOVER
2 DHCPOFFER
3 DHCPREQUEST
4 DHCPDECLINE
5 DHCPACK
6 DHCPNAK
7 DHCPRELEASE
8 DHCPINFORM Code Len Type
+-----+-----+-----+
| 53 | 1 | 1-9 |
+-----+-----+-----+9.7. Server Identifier ๐ซถ
this one shows up in DHCPOFFER and DHCPREQUEST messages, and it may optionally be in DHCPACK and DHCPNAK messages too ๐ฆ servers put it in the DHCPOFFER so the client can tell lease offers apart ๐ฅ clients then use the contents of the 'server identifier' field as the destination address for any DHCP messages unicast to that server ๐ when a client wants one of several offers, it puts this option in a DHCPREQUEST to say which one it picked ๐
the identifier is the IP address of the selected server.
the code is 54 and the length is 4.
Code Len Address
+-----+-----+-----+-----+-----+-----+
| 54 | 4 | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+9.8. Parameter Request List ๐
clients use this one to ask for values for specific configuration parameters ๐ง the list is n octets, and each octet is a valid DHCP option code defined in this document โจ
the client MAY list the options in order of preference. the DHCP server is not required to send them back in the requested order, but it MUST try to insert the requested options in the order the client asked for ๐
the code is 55 and its minimum length is 1.
Code Len Option Codes
+-----+-----+-----+-----+---
| 55 | n | c1 | c2 | ...
+-----+-----+-----+-----+---9.9. Message ๐ฌ
servers use this to send an error message to a client inside a DHCPNAK when something goes wrong ๐ญ a client may also use it in a DHCPDECLINE to explain why it turned down the offered parameters ๐ the message is n octets of NVT ASCII text, and the client can display it on an available output device ๐ธ
the code is 56 and its minimum length is 1.
Code Len Text
+-----+-----+-----+-----+---
| 56 | n | c1 | c2 | ...
+-----+-----+-----+-----+---9.10. Maximum DHCP Message Size ๐
this option says the longest DHCP message the sender is willing to accept ๐ฆ the length is an unsigned 16-bit integer โจ a client may use it in DHCPDISCOVER or DHCPREQUEST messages, but should not use it in DHCPDECLINE messages ๐
the code is 57 and its length is 2. the minimum legal value is 576 octets.
Code Len Length
+-----+-----+-----+-----+
| 57 | 2 | l1 | l2 |
+-----+-----+-----+-----+9.11. Renewal (T1) Time Value โฐ
this one sets the time from address assignment until the client moves into the RENEWING state ๐
the value is in seconds and is a 32-bit unsigned integer. the code is 58 and its length is 4.
Code Len T1 Interval
+-----+-----+-----+-----+-----+-----+
| 58 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+9.12. Rebinding (T2) Time Value ๐
same vibe as T1, but this one sets the time from address assignment until the client moves into the REBINDING state ๐ธ
the value is in seconds and is a 32-bit unsigned integer. the code is 59 and its length is 4.
Code Len T2 Interval
+-----+-----+-----+-----+-----+-----+
| 59 | 4 | t1 | t2 | t3 | t4 |
+-----+-----+-----+-----+-----+-----+9.13. Vendor class identifier ๐ท๏ธ
clients use this to optionally say what vendor type and configuration they are ๐ the info is a string of n octets, and servers interpret it ๐ง vendors can define their own vendor class identifiers to share configuration or identification details, like encoding the client's hardware setup ๐
servers that can't interpret the class-specific info a client sends MUST ignore it (although it may be reported). servers that respond SHOULD only use option 43 to send vendor-specific info back to the client ๐ โโ๏ธโจ
the code is 60 and its minimum length is 1.
Code Len Vendor class Identifier
+-----+-----+-----+-----+---
| 60 | n | i1 | i2 | ...
+-----+-----+-----+-----+---9.14. Client-identifier ๐ชช
this is how clients say who they are, and servers use it as the index into their database of address bindings ๐๏ธ it's expected to be unique across an administrative domain ๐
servers SHOULD treat identifiers as opaque objects ๐ซฃ
the client identifier MAY be made of type-value pairs, similar to the 'htype'/'chaddr' fields defined in [3] ๐ for example, it MAY be a hardware type plus a hardware address. in that case the type field SHOULD be one of the ARP hardware types defined in STD2 [22]. a hardware type of 0 (zero) should be used when the value field holds an identifier that isn't a hardware address (like a fully qualified domain name) ๐
for clients to be identified correctly, each client-identifier MUST be unique among the client-identifiers used on the subnet the client is attached to ๐จ vendors and system administrators are responsible for picking identifiers that meet this uniqueness requirement ๐
the code is 61 and its minimum length is 2.
Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+---
| 61 | n | t1 | i1 | i2 | ...
+-----+-----+-----+-----+-----+---10. Defining new extensions ๐งฉ
okay so if you're writing a brand new DHCP option and want it to become part of the DHCP Internet Standard, here's the process ๐ฆ
- the author devises the new option.
- the author requests a number for the new option from IANA by contacting:
Internet Assigned Numbers Authority (IANA) USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, California 90292-6695
or by email as: iana@iana.org
- the author documents the new option, using the newly obtained option number, as an Internet Draft.
- the author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" (STD 1). the new option will be submitted for eventual acceptance as an Internet Standard.
- the new option progresses through the IETF standards process; it will be reviewed by the Dynamic Host Configuration Working Group (if that group still exists), or as an Internet Draft not submitted by an IETF working group.
- if the new option fails to gain acceptance as an Internet Standard, the assigned option number will be returned to IANA for reassignment.
this procedure is how the process makes sure that:
- allocation of new option numbers is coordinated from a single authority,
- new options are reviewed for technical correctness and appropriateness, and
- documentation for new options is complete and published.
11. Acknowledgements ๐
huge thanks to the many (and too numerous to mention!) members of the DHC WG for their tireless and ongoing work on DHCP and this document ๐ซถ
the efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John Mendonca in organizing DHCP interoperability testing sessions are gratefully acknowledged ๐
the development of this document was supported in part by grants from the Corporation for National Research Initiatives (CNRI), Bucknell University and Sun Microsystems ๐
12. References ๐
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997.
[2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497, USC/Information Sciences Institute, August 1993.
[3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951, Stanford University and Sun Microsystems, September 1985.
[4] Braden, R., Editor, "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.
[5] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, USC/Information Sciences Institute, August 1985.
[6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC 868, USC/Information Sciences Institute, SRI, May 1983.
[7] Postel, J., "Name Server", IEN 116, USC/Information Sciences Institute, August 1979.
[8] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
[9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865, USC/Information Sciences Institute, May 1983.
[10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The Wollongong Group, August 1990.
[11] Accetta, M., "Resource Location Protocol", RFC 887, CMU, December 1983.
[12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, DECWRL, Stanford University, November 1990.
[13] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.
[14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893, U. C. Berkeley, April 1984.
[15] Hornig, C., "Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC 894, Symbolics, April 1984.
[16] Postel, J. and J. Reynolds, "Standard for the Transmission of IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, February 1988.
[17] Sun Microsystems, "System and Network Administration", March 1990.
[18] Mills, D., "Internet Time Synchronization: The Network Time Protocol", RFC 1305, UDEL, March 1992.
[19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001, March 1987.
[20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service on a TCP/UDP transport: Detailed Specifications", STD 19, RFC 1002, March 1987.
[21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198, MIT Laboratory for Computer Science, January 1991.
[22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, July 1992.
13. Security Considerations ๐
security issues are not discussed in this memo ๐ (I know, I know, very dramatic for a security section, but that's the whole entry! ๐)
14. Authors' Addresses ๐ฎ
Steve Alexander Silicon Graphics, Inc. 2011 N. Shoreline Boulevard Mailstop 510 Mountain View, CA 94043-1389
Phone: (415) 933-6172 EMail: sca@engr.sgi.com
Ralph Droms Bucknell University Lewisburg, PA 17837
Phone: (717) 524-1145 EMail: droms@bucknell.edu
๐ฆ where this page comes from
- ietf: rfc2132 1997-03
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms