Option Name
|
Code
|
Data Length
|
Description
|
Referencia
|
Vendor Extension Options
| ||||
Pad | 0 | 1 octet | Causes the subsequent fields to align on word boundaries. | RFC 2132 |
End | 255 | 1 octet | End of valid information in the vendor field. Subsequent octets should be filled with the Pad options. | RFC 2132 |
Subnet Mask | 1 | 4 octets | Client's subnet mask, as per RFC 950. If both the Subnet Mask and the Router option are specified in a DHCP reply, the Subnet Mask option must be first. | RFC 2132 |
Time Offset | 2 | 4 octets | Offset of the client's subnet, in seconds, from Universal Time (UT). The offset is expressed as a twos-complement 32-bit integer. A positive offset indicates a location east of the zero meridian and a negative offset indicates a location west of the zero meridian. | RFC 2132 |
Router | 3 | 4 octet minimum; multiples of 4 | List of IP addresses for routers on the client's subnet. Routers should be in order of preference. | RFC 2132 |
Time Server | 4 | 4 octet minimum; multiples of 4 | List of RFC 868 compliant time servers available to the client. Servers should be in order of preference. | RFC 2132 |
Name Server Option | 5 | 4 octet minimum; multiples of 4 | List of IEN 116 name servers available to the client. Servers should be in order of preference. | RFC 2132 |
Domain Name Server | 6 | 4 octet minimum; multiples of 4 | List of Domain Name System (STD 13, RFC 1035) name servers available to the client. Servers should be in order of preference. | RFC 2132 |
Log Server | 7 | 4 octet minimum; multiples of 4 | List of MIT-LCS UDP log servers available to the client. Servers should be in order of preference. | RFC 2132 |
Cookie Server | 8 | 4 octet minimum; multiples of 4 | List of RFC 865-compliant cookie servers available to the client. Servers should be in order of preference. | RFC 2132 |
LPR Server | 9 | 4 octet minimum; multiples of 4 | List of RFC 1179-compliant line printer servers available to the client. Servers should be in order of preference. | RFC 2132 |
Impress Server | 10 | 4 octet minimum; multiples of 4 | List of Imagen Impress servers available to the client. Servers should be in order of preference. | RFC 2132 |
Resource Location Server | 11 | 4 octet minimum; multiples of 4 | List of RFC 887-compliant resource location servers available to the client. Servers should be in order of preference. | RFC 2132 |
Host Name | 12 | 4 octet minimum; multiples of 4 | Name of the client. The name may or may not be qualified with the local domain name. See RFC 1035 for the character set restrictions. | RFC 2132 |
Boot File Size | 13 | 2 octets | Number of 512-octet blocks in the default boot file. | RFC 2132 |
Merit Dump File | 14 | 1 octet minimum | Path name of a file to which the client's core image should be placed in the event the client crashes. The path is formatted as a character string consisting of characters from the NVT ASCII character set. | RFC 2132 |
Domain Name | 15 | 1 octet minimum | Domain name that the client should use when resolving hostnames through the Domain Name System. | RFC 2132 |
Swap Server | 16 | 4 octets | IP address of the client's swap server. | RFC 2132 |
Root Path | 17 | 1 octet minimum | Path name that contains the client's root disk. The path is formatted as a character string consisting of characters from the NVT ASCII character set. | RFC 2132 |
IP Layer Parameters Per Host Options
| ||||
Extensions Path | 18 | 1 octet minimum | Uses a string to specify a file, retrievable through TFTP. The file contains information that can be interpreted in the same way as the 64-octet vendor-extension field within the BOOTP response, with the following exceptions: the length of the file is unconstrained, and all references to instances of this option in the file are ignored. | RFC 2132 |
IP Forwarding Enable/Disable | 19 | 1 octet | Specifies whether the client should configure its IP layer for packet forwarding. Values: 0=disable; 1=enable | RFC 2132 |
Non-Local Source Routing Enable/Disable | 20 | 1 octet | Specifies whether the client should configure its IP layer to allow forwarding of datagrams with non-local source routes. Values: 0=disable; 1=enable | RFC 2132 |
Policy Filter | 21 | 8 octet minimum; multiples of 8 | Policy filters for non-local source routing. The filters consist of a list of IP addresses and masks that specify destination/mask pairs with which 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. | RFC 2132 |
Maximum Datagram Reassembly Size | 22 | 2 octets | Maximum size datagram that the client should be prepared to reassemble. Value: 576 minimum | RFC 2132 |
Default IP Time-to-Live | 23 | 1 octet | Default TTL that the client should use on outgoing datagrams. Values: 1 to 255 | RFC 2132 |
Path MTU Aging Timeout | 24 | 4 octets | Timeout (in seconds) to use when aging Path MTU values (defined in RFC 1191). | RFC 2132 |
Path MTU Plateau Table | 25 | 2 octets minimum; multiples of 2 | Table of MTU sizes to use when performing Path MTU Discovery as defined in RFC 1191. The table is formatted as a list of 16-bit unsigned integers, ordered from smallest to largest. Value: 68 minimum | RFC 2132 |
IP Layer Parameters Per Interface Options
| ||||
Interface MTU | 26 | 2 octets | Maximum time to live to use on this interface. | RFC 2132 |
All Subnets Are Local | 27 | 1 octet | Specifies whether or not the client can assume that all subnets of the IP network to which the client is connected use the same MTU as the subnet of that network to which the client is directly connected. Values: 1=all subnets share same MTU; 0=some directly-connected subnets can have smaller MTUs | RFC 2132 |
Broadcast Address | 28 | 4 octets | Broadcast address in use on the client's subnet. | RFC 2132 |
Perform Mask Discovery | 29 | 1 octet | Specifies whether or not the client should perform subnet mask discovery using ICMP. Values: 0=disable; 1=enable | RFC 2132 |
Mask Supplier | 30 | 1 octet | Specifies whether or not the client should respond to subnet mask requests using ICMP. Values: 0=do not respond; 1=respond | RFC 2132 |
Perform Router Discovery | 31 | 1 octet | Specifies whether or not the client should solicit routers using the Router Discovery mechanism defined in RFC 1256. Values: 0=disable; 1=enable | RFC 2132 |
Router Solicitation Address | 32 | 4 octets | Address to which the client should transmit router solicitation requests. | RFC 2132 |
Static Route | 33 | 8 octet minimum; multiples of 8 | List of static routes that the client should install in its routing cache. If multiple routes to the same destination are specified, they are in descending order of priority. The routes consist of a list of IP address pairs. The first address is the destination address, and the second address is the router for the destination. The default route (0.0.0.0) is an illegal destination for a static route. | RFC 2132 |
Link Layer Parameters Per Interface
| ||||
Trailer Encapsulation | 34 | 1 octet | Specifies whether or not the client should negotiate the use of trailers (RFC 893) when using the ARP protocol. Values: 0=do not use; 1=use | RFC 2132 |
ARP Cache Timeout | 35 | 4 octets | Timeout in seconds for ARP cache entries. | RFC 2132 |
Ethernet Encapsulation | 36 | 1 octet | Specifies whether or not the client should use Ethernet Version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is an Ethernet. Value: 0=use RFC 894 encapsulation; 1=use RFC 1042 encapsulation | RFC 2132 |
TCP Parameters
| ||||
TCP Default TTL | 37 | 1 octet | Default TTL that the client should use when sending TCP segments. Value: minimum 1 | RFC 2132 |
TCP Keepalive Interval | 38 | 4 octets | Interval (in seconds) that the client TCP should wait before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer. A value of zero indicates that the client should not generate keepalive messages on connections unless specifically requested by an application. Value: 32-bit unsigned; 0=do not generate keepalive messages unless specifically requested. | RFC 2132 |
TCP Keepalive Garbage | 39 | 1 octet | Specifies the whether or not the client should send TCP keep-alive messages with an octet of garbage for compatibility with older implementations. Values: 0=do not send; 1=send | RFC 2132 |
Application and Service Parameters
| ||||
Network Information Service Domain | 40 | 1 octet minimum | Name of the client's NIS domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. | RFC 2132 |
Network Information Servers | 41 | 4 octet minimum; multiples of 4 | List of IP addresses indicating NIS servers available to the client. Servers should be in order of preference. | RFC 2132 |
Network Time Protocol Servers | 42 | 4 octet minimum; multiples of 4 | List of IP addresses indicating NTP servers that are available to the client. Servers should be in order of preference. | RFC 2132 |
Vendor-Specific Information | 43 | 1 octet minimum | "This option is used by clients and servers to exchange vendor-specific information. The information is an opaque object of n octets, presumably interpreted by vendor-specific code on the clients and servers. The definition of this information is vendor specific. The vendor is indicated in the vendor-class-identifier option. Servers not equipped to interpret the vendor-specific information sent by a client must ignore it (although it can be reported). Clients that do not receive desired vendor-specific information should make an attempt to operate without it, although they can do so (and announce they are doing so) in a degraded mode. If a vendor potentially encodes more than one item of information in this option, then the vendor should encode the option using encapsulated vendor-specific options as described here. The encapsulated vendor-specific options field should be encoded as a sequence of code/length/value fields of identical syntax to the DHCP options field with the following exceptions: •There should not be a magic cookie field in the encapsulated vendor-specific extensions field. •Codes other than 0 or 255 can be redefined by the vendor within the encapsulated vendor-specific extensions field, but 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." | RFC 1533, RFC 2132 |
NetBIOS over TCP/IP Name Server | 44 | 4 octet minimum; multiples of 4 | List of RFC 1001/1002 NBNS name servers in order of preference. | RFC 1533, RFC 2132 |
NetBIOS over TCP/IP Datagram Distribution Server | 45 | 4 octet minimum; multiples of 4 | List of RFC 1001/1002 NBDD servers in order of preference. | RFC 1533, RFC 2132 |
NetBIOS over TCP/IP Node Type | 46 | 1 octet | "Allows NetBIOS over TCP/IP client, which are configured as described in RFC 1001/1002. Values: Single octet in hexadecimal that identifies the client type: •0x1=B-node (broadcast node) •0x2=P-node (point-to-point node) •0x4=M-node (mixed node) •0x8=H-node" | RFC 1533, RFC 2132 |
NetBIOS over TCP/IP Scope | 47 | 1 octet minimum | NetBIOS over TCP/IP scope parameter for the client as specified in RFC 1001/1002. | RFC 1533, RFC 2132 |
X Window System Font Server | 48 | 4 octet minimum; multiples of 4 | List of X Window System Font servers available to the client. Servers should be in order of preference. | RFC 1533, RFC 2132 |
X Window System Display Manager | 49 | 4 octet minimum; multiples of 4 | List of IP addresses of systems that are running the X Window System Display Manager and are available to the client. Addresses should be in order of preference. | RFC 1533, RFC 2132 |
Network Information Service+ Domain | 64 | 1 octet minimum | Name of the client's NIS+ domain. The domain is formatted as a character string consisting of characters from the NVT ASCII character set. | RFC 2132 |
Network Information Service+ Servers | 65 | 4 octet minimum; multiples of 4 | List of IP addresses indicating NIS+ servers available to the client. Servers should be in order of preference. | RFC 2132 |
Mobile IP Home Agent | 68 | 0 octets minimum; multiples of 4; expected, 4 octets (single home agent's address) | List of IP addresses indicating mobile IP home agents available to the client. Agents should be in order of preference. Value: 32-bit address; 0=no home agents available | RFC 2132 |
Simple Mail Transport Protocol (SMTP) Server | 69 | 4 octet minimum; multiples of 4 | List of SMTP servers available to the client. Servers should be in order of preference. | RFC 2132 |
Post Office Protocol (POP3) Server | 70 | 4 octet minimum; multiples of 4 | List of POP3 servers available to the client. Servers should be in order of preference. | RFC 2132 |
Network News Transport Protocol (NNTP) Server | 71 | 4 octet minimum; multiples of 4 | List of NNTP servers available to the client. Servers should be in order of preference. | RFC 2132 |
Default World Wide Web (WWW) Server | 72 | 4 octet minimum; multiples of 4 | List of World Wide Web (WWW) servers available to the client. Servers should be in order of preference. | RFC 2132 |
Default Finger Server | 73 | 4 octet minimum; multiples of 4 | List of Finger servers available to the client. Servers should be in order of preference. | RFC 2132 |
Default Internet Relay Chat Server | 74 | 4 octet minimum; multiples of 4 | List of IRC servers available to the client. Servers should be in order of preference. | RFC 2132 |
StreetTalk Server | 75 | 4 octet minimum; multiples of 4 | List of StreetTalk servers available to the client. Servers should be in order of preference. | RFC 2132 |
StreetTalk Directory Assistance (STDA) Server | 76 | 4 octet minimum; multiples of 4 | List of STDA servers available to the client. Servers should be in order of preference. | RFC 2132 |
DHCP. Opciones
A continuación se incluye una tabla con las opciones DHCP por categorías. Se incluyen las opciones DHCP y las extensiones de información del fabricante de BOOTP.
Etiquetas:
Protocolos,
Util
__________________________ Artículos relacionados: _________________________
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario
Nota: solo los miembros de este blog pueden publicar comentarios.