of the 'chaddr' field and/or the 'class-identifier' option included
in the DHCPDISCOVER or DHCPREQUEST messages when determining the
correct parameters for a particular client. For example, an
organization might have a separate bootstrap server for each type of
client it uses, requiring the DHCP server to examine the 'class-
identifier' to determine which bootstrap server address to return in
the 'siaddr' field of a DHCPOFFER or DHCPACK message.
A DHCP server must use some unique identifier to associate a client
with its lease. The client may choose to explicitly provide the
identifier through the 'client identifier' option. If the client
does not provide a 'client identifier' option, the server MUST use
the contents of the 'chaddr' field to identify the client.
DHCP clients are free to use any strategy in selecting a DHCP server
among those from which the client receives a DHCPOFFER message. The
client implementation of DHCP should provide a mechanism for the user
to select directly the 'class-identifier' value.
4.3 DHCP server behavior
A DHCP server processes incoming DHCP messages from a client based on
the current state of the binding for that client. A DHCP server can
receive the following messages from a client:
o DHCPDISCOVER
o DHCPREQUEST
o DHCPDECLINE
o DHCPRELEASE
Table 3 gives the use of the fields and options in a DHCP message by
a server. The remainder of this section describes the action of the
DHCP server for each possible incoming message.
4.3.1 DHCPDISCOVER message
When a server receives a DHCPDISCOVER message from a client, the
server chooses a network address for the requesting client. If no
address is available, the server may choose to report the problem to
the system administrator and may choose to reply to the client with a
DHCPNAK message. If the server chooses to respond to the client, it
may include an error message in the 'message' option. If an address
is available, the new address should be chosen as follows:
o The client's previous address as recorded in the client's binding,
if that address is in the server's pool of available addresses and
not already allocated, else
o The address requested in the 'Requested IP Address' option, if that
address is valid and not already allocated, else
o A new address allocated from the server's pool of available
addresses.
Field DHCPOFFER DHCPACK DHCPNAK
----- --------- ------- -------
'op' BOOTREPLY BOOTREPLY BOOTREPLY
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' 'xid' from client 'xid' from client 'xid' from client
DHCPDISCOVER DHCPREQUEST DHCPREQUEST
message message message
'secs' 0 0 0
'ciaddr' 0 'ciaddr' from 'ciaddr' from
DHCPREQUEST or 0 DHCPREQUEST or 0
'yiaddr' IP address offered IP address 0
to client assigned to client
'siaddr' IP address of next IP address of next 0
bootstrap server bootstrap server
'flags' if 'giaddr' is not 0 then 'flags' from client message else 0
'giaddr' 0 0 0
'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
client client DHCPREQUEST client DHCPREQUEST
DHCPDISCOVER message message
message
'sname' Server host name Server host name (unused)
or options or options
'file' Client boot file Client boot file (unused)
name or options name or options
'options' options options
Option DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
Requested IP address MUST NOT MUST NOT MUST NOT
IP address lease time MUST MUST MUST NOT
Use 'file'/'sname' MAY MAY MUST NOT
fields
DHCP message type DHCPOFFER DHCPACK DHCPNAK
Parameter request list MUST NOT MUST NOT MUST NOT
Message SHOULD SHOULD SHOULD
Client identifier MUST NOT MUST NOT MUST NOT
Class identifier MUST NOT MUST NOT MUST NOT
Server identifier MUST MAY MAY
Maximum message size MUST NOT MUST NOT MUST NOT
All others MAY MAY MUST NOT
Table 3: Fields and options used by DHCP servers
As described in section 4.2, a server MAY, for administrative
reasons, assign an address other than the one requested, or may
refuse to allocate an address to a particular client even though free
addresses are available.
While not required for correct operation of DHCP, the server should
not reuse the selected network address before the client responds to
the server's DHCPOFFER message. The server may choose to record the
address as offered to the client.
The server must also choose an expiration time for the lease, as
follows:
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client already has an assigned network
address, the server returns the lease expiration time previously
assigned to that address (note that the client must explicitly
request a specific lease to extend the expiration time on a
previously assigned address), ELSE
o IF the client has not requested a specific lease in the
DHCPDISCOVER message and the client does not have an assigned
network address, the server assigns a locally configured default
lease time, ELSE
o IF the client has requested a specific lease in the DHCPDISCOVER
message (regardless of whether the client has an assigned network
address), the server may choose either to return the requested
lease (if the lease is acceptable to local policy) or select
another lease.
Once the network address and lease have been determined, the server
constructs a DHCPOFFER message with the offered configuration
parameters. It is important for all DHCP servers to return the same
parameters (with the possible exception of a newly allocated network
address) to ensure predictable host behavior regardless of the which
server the client selects. The configuration parameters MUST be
selected by applying the following rules in the order given below.
The network administrator is responsible for configuring multiple
DHCP servers to ensure uniform responses from those servers. The
server MUST return to the client:
o The client's network address, as determined by the rules given
earlier in this section, and the subnet mask for the network to
which the client is connected,
o The expiration time for the client's lease, as determined by the
rules given earlier in this section,
o Parameters requested by the client, according to the following
rules:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field, ELSE
-- IF the server recognizes the parameter as a parameter
defined in the Host Requirements Document, the server MUST
include the default value for that parameter as given in the
Host Requirements Document in an appropriate option in the
'option' field, ELSE
-- The server MUST NOT return a value for that parameter,
o Any parameters from the existing binding that differ from the Host
Requirements documents defaults,
o Any parameters specific to this client (as identified by
the contents of 'chaddr' in the DHCPDISCOVER or DHCPREQUEST
message), e.g., as configured by the network administrator,
o Any parameters specific to this client's class (as identified
by the contents of the 'class identifier' option in the
DHCPDISCOVER or DHCPREQUEST message), e.g., as configured by
the network administrator; the parameters MUST be identified
by an exact match between the client's 'client class' and the
client class identified in the server,
o Parameters with non-default values on the client's subnet.
The server inserts the 'xid' field from the DHCPDISCOVER message into
the 'xid' field of the DHCPOFFER message and sends the DHCPOFFER
message to the requesting client.
4.3.2 DHCPREQUEST message
A DHCPREQUEST message may come from a client responding to a
DHCPOFFER message from a server, or from a client verifying a
previously allocated IP address. If the DHCPREQUEST message contains
a 'server identifier' option, the message is in response to a
DHCPOFFER message. Otherwise, the message is a request to renew or
extend an existing lease.
Consider first the case of a DHCPREQUEST message in response to a
DHCPOFFER message. If the server is identified in the 'server
identifier' option in the DHCPREQUEST message, the server checks to
confirm that the requested parameters are acceptable. Usually, the
requested parameters will match those returned to the client in the
DHCPOFFER message; however, the client may choose to request a
different lease duration. Also, there is no requirement that the
server cache the parameters from the DHCPOFFER message. The server
must simply check that the parameters requested in the DHCPREQUEST
are acceptable. If the parameters are acceptable, the server records
the new client binding and returns a DHCPACK message to the client.
If the requested parameters are unacceptable, e.g., the requested
lease time is unacceptable to local policy, the server sends a
DHCPNAK message to the client. The server may choose to return an
error message in the 'message' option.
If a different server is identified in the 'server identifier' field,
the client has selected a different server from which to obtain
configuration parameters. The server may discard any information it
may have cached about the client's request, and may free the network
address that it had offered to the client.
Note that the client may choose to collect several DHCPOFFER messages
and select the "best" offer. The client indicates its selection by
identifying the offering server in the DHCPREQUEST message. If the
client receives no acceptable offers, the client may choose to try
another DHCPDISCOVER message. Therefore, the servers may not receive
a specific DHCPREQUEST from which they can decide whether or not the
client has accepted the offer. Because the servers have not
committed any network address assignments on the basis of a
DHCPOFFER, servers are free to reuse offered network addresses in
response to subsequent requests. As an implementation detail,
servers should not reuse offered addresses and may use an
implementation-specific timeout mechanism to decide when to reuse an
offered address.
In the second case, when there is no 'server identifier' option, the
client is renewing or extending a previously allocated IP address.
The server checks to confirm that the requested parameters are
acceptable. If the parameters specified in the DHCPREQUEST message
match the previous parameters, or if the request for an extension of
the lease (indicated by an extended 'IP address lease time' option)
is acceptable, the server returns a DHCPACK message to the requesting
client. Otherwise, the server returns a DHCPNAK message to the
client. In particular, if the previously allocated network address
in the 'ciaddr' field from the client does not match the network
address recorded by the server for that client, the server sends a
DHCPNAK to the client.
A DHCP server chooses the parameters to return in a DHCPACK message
according to the same rules as used in constructing a DHCPOFFER
message, as given in section 4.3.1.
4.3.3 DHCPDECLINE message
If the server receives a DHCPDECLINE message, the client has
discovered through some other means that the suggested network
address is already in use. The server MUST mark the network address
as not allocated and SHOULD notify the local system administrator of
a possible configuration problem.
4.3.4 DHCPRELEASE message
Upon receipt of a DHCPRELEASE message, the server marks the network
address as not allocated. The server should retain a record of the
client's initialization parameters for possible reuse in response to
subsequent requests from the client.
4.4 DHCP client behavior
Figure 5 gives a state-transition diagram for a DHCP client. A
client can receive the following messages from a server:
o DHCPOFFER
o DHCPACK
o DHCPNAK
Table 4 gives the use of the fields and options in a DHCP message by
a client. The remainder of this section describes the action of the
DHCP client for each possible incoming message. The description in
the following section corresponds to the full configuration procedure
previously described in section 3.1, and the text in the subsequent
section corresponds to the abbreviated configuration procedure
described in section 3.2.
4.4.1 Initialization and allocation of network address
The client begins in INIT state and forms a DHCPDISCOVER message.
The client should wait a random time between one and ten seconds to
desynchronize the use of DHCP at startup. The client sets 'ciaddr'
to 0x00000000. The client MAY request specific parameters by
including the 'parameter request list' option. The client MAY
suggest a network address and/or lease time by including the
'requested IP address' and 'IP address lease time' options. The
client MUST include its hardware address in the 'chaddr' field for
use in delivery of DHCP reply messages. The client MAY include a
different unique identifier in the 'client identifier' option. If
the client does not include the 'client identifier' option, the
server will use the contents of the 'chaddr' field to identify the
client's lease.
The client generates and records a random transaction identifier and
inserts that identifier into the 'xid' field. The client records its
own local time for later use in computing the lease expiration. The
client then broadcasts the DHCPDISCOVER on the local hardware
broadcast address to 0xffffffff IP broadcast address and 'DHCP
server' UDP port.
If the 'xid' of an arriving DHCPOFFER message does not match the
'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
must be silently discarded. Any arriving DHCPACK messages must be
silently discarded.
The client collects DHCPOFFER messages over a period of time, selects
one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
from the previously used server) and extracts the server address from
the 'server identifier' option in the DHCPOFFER message. The time
over which the client collects messages and the mechanism used to
select one DHCPOFFER are implementation dependent. The client may
perform a check on the suggested address to ensure that the address
is not already in use. For example, if the client is on a network
that supports ARP, the client may issue an ARP request for the
suggested request. When broadcasting an ARP request for the
suggested address, the client must fill in its own hardware address
as the sender's hardware address, and 0 as the sender's IP address,
to avoid confusing ARP caches in other hosts on the same subnet. If
the network address appears to be in use, the client sends a
DHCPDECLINE message to the server and waits for another DHCPOFFER. As
the client does not have a valid network address, the client must
broadcast the DHCPDECLINE message.
-------- -------
| | +-------------------------->| |<-------------------+
| INIT/ | | +-------------------->| INIT | |
| REBOOT |DHCPNAK/ +---------->| |<---+ |
| |Restart| | ------- | |
-------- | DHCPNAK/ | | |
| Discard offer | -/Send DHCPDISCOVER |
-/Send DHCPREQUEST | | |
| | | DHCPACK v | |
----------- | (not accept.)/ ----------- | |
| | | Send DHCPDECLINE | | | |
| REBOOTING | | | | SELECTING | | |
| | | / | | | |
----------- | / ----------- | |
| | / | | |
DHCPACK/ | / +----------------+ | |
Record lease, | | v | |
set timers ------------ | |
| +----->| | DHCPNAK, Lease expired/ |
| | | REQUESTING | Halt network |
DHCPOFFER/ | | | |
Discard ------------ | |
| | | | ----------- |
| +--------+ DHCPACK/ | | |
| Record lease, set -----| REBINDING | |
| timers T1, T2 / | | |
| | DHCPACK/ ----------- |
| v Record lease, set ^ |
+----------------> ------- /Timers T1,T2 | |
+----->| |<---+ | |
| | BOUND |<---+ | |
DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
DHCPNAK/Discard ------- | Broadcast Halt network
| | | | DHCPREQUEST |
+-------+ | DHCPACK/ | |
T1 expires/ Record lease, set | |
Send DHCPREQUEST timers T1, T2 | |
to leasing server | | |
| ---------- | |
| | |------------+ |
+->| RENEWING | |
| |----------------------------+
----------
Figure 5: State-transition diagram for DHCP clients
Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
----- ------------ ----------- -----------
'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
'htype' (From "Assigned Numbers" RFC)
'hlen' (Hardware address length in octets)
'hops' 0 0 0
'xid' selected by client selected by client selected by
client
'secs' (opt.) (opt.) 0
'flags' Set 'BROADCAST' Set 'BROADCAST'
flag if client flag if client
requires broadcast requires broadcast
reply reply
0
'ciaddr' 0 previously ciaddr
allocated newtork
address
'yiaddr' 0 0 0
'siaddr' 0 0 0
'giaddr' 0 0 0
'chaddr' client's hardware client's hardware client's
hardware
address address address
'sname' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
unused unused
'file' options, if options, if (unused)
indicated in indicated in
'sname/file' 'sname/file'
option; otherwise option; otherwise
'generic' name or 'generic' name or
null null
'options' options options (unused)
Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
DHCPRELEASE
------ ------------ ----------- -----------
Requested IP address MAY MUST NOT MUST NOT
IP address lease time MAY MAY MUST NOT
Use 'file'/'sname' fields MAY MAY MAY
DHCP message type DHCPDISCOVER DHCPREQUEST DHCPDECLINE/
DHCPRELEASE
Client identifier MAY MAY MAY
Class identifier SHOULD SHOULD MUST NOT
Server identifier MUST NOT MUST (after MUST
DHCPDISCOVER),
MUST NOT (when
renewing)
Parameter request list MAY MAY MUST NOT
Maximum message size MAY MAY MUST NOT
Message SHOULD NOT SHOULD NOT SHOULD
Site-specific MAY MAY MUST NOT
All others MUST NOT MUST NOT MUST NOT
Table 4: Fields and options used by DHCP clients
If the parameters are acceptable, the client records the address of
the server that supplied the parameters from the 'server identifier'
field and sends that address in the 'server identifier' field of a
DHCPREQUEST broadcast message. Once the DHCPACK message from the
server arrives, the client is initialized and moves to BOUND state.
The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
message. The client records the lease expiration time as the sum of
the time at which the original request was sent and the duration of
the lease from the DHCPOFFER message. The client SHOULD broadcast an
ARP reply to announce the client's new IP address and clear any
outdated ARP cache entries in hosts on the client's subnet.
4.4.2 Initialization with known network address
The client begins in INIT-REBOOT state and sends a DHCPREQUEST message
with the 'ciaddr' field set to the client's network address. The
client may request specific configuration parameters by including
the 'parameter request list' option. The client generates and records a
random transaction identifier and inserts that identifier into the 'xid'
field. The client records its own local time for later use in
computing the lease expiration. The client MUST NOT incldue a 'server
identifier' in the DHCPREQUEST message. The client then broadcasts
the DHCPREQUEST on the local hardware broadcast address to the 'DHCP
server' UDP port.
Once a DHCPACK message with an 'xid' field matching that in the
client's DHCPREQUEST message arrives from any server, the client is
initialized and moves to BOUND state. The client records the lease
expiration time as the sum of the time at which the DHCPREQUEST
message was sent and the duration of the lease from the DHCPACK
message.
4.4.3 Initialization with a known DHCP server address
When the DHCP client knows the address of a DHCP server, in either
INIT or REBOOTING state, the client may use that address in the
DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. If
the client receives no response to DHCP messages sent to the IP
address of a known DHCP server, the DHCP client reverts to using the
IP broadcast address.
4.4.4 Reacquisition and expiration
The client maintains two times, T1 and T2, that specify the times at
which the client tries to extend its lease on its network address. T1
is the time at which the client enters the RENEWING state and attempts
to contact the server that originally issued the client's network
address. T2 is the time at which the client enters the REBINDING
state and attempts to contact any server.
At time T1 after the client accepts the lease on its network address,
the client moves to RENEWING state and sends (via unicast) a
DHCPREQUEST message to the server to extend its lease. The client
generates a random transaction identifier and inserts that identifier
into the 'xid' field in the DHCPREQUEST. The client records the local
time at which the DHCPREQUEST message is sent for computation of the
lease expiration time. The client MUST NOT include a 'server
identifier' in the DHCPREQUEST message.
Any DHCPACK messages that arrive with an 'xid' that does not match
the 'xid' of the client's DHCPREQUEST message are silently discarded.
When the client receives a DHCPACK from the server, the client
computes the lease expiration time as the sum of the time at which the
client sent the DHCPREQUEST message and the duration of the lease in
the DHCPACK message. The client has successfully reacquired its
network address, returns to BOUND state and may continue network
processing.
If no DHCPACK arrives before time T2 (T2 > T1) before the expiration
of the client's lease on its network address, the client moves to
REBINDING state and sends (via broadcast) a DHCPREQUEST message to
extend its lease. The client sets the 'ciaddr' field in the
DHCPREQUEST to its current network address. The client MUST NOT
include a 'server identifier' in the DHCPREQUEST message.
Times T1 and T2 are configurable by the server through options. T1
defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
duration_of_lease). Times T1 and T2 should be chosen with some random
"fuzz" around a fixed value, to avoid synchronization of client
reacquisition.
In both RENEWING and REBINDING state, if the client receives no
response to its DHCPREQUEST message, the client should wait one-half
the remaining time until the expiration of T1 (in RENEWING state) and
T2 (in REBINDING state) down to a minimum of 60 seconds, before
retransmitting the DHCPREQUEST message.
If the lease expires before the client receives a DHCPACK, the client
moves to INIT state, MUST immediately stop any other network
processing and requests network initialization parameters as if the
client were uninitialized. If the client then receives a DHCPACK
allocating that client its previous network address, the client SHOULD
continue network processing. If the client is given a new network
address, it MUST NOT continue using the previous network address and
SHOULD notify the local users of the problem.
4.4.5 DHCPRELEASE
If the client no longer requires use of its assigned network address
(e.g., the client is gracefully shut down), the client sends a
DHCPRELEASE message to the server. Note that the correct operation of
DHCP does not depend on the transmission of DHCPRELEASE messages.
5. Acknowledgments
Greg Minshall, Leo McLaughlin and John Veizades have patiently
contributed to the the design of DHCP through innumerable discussions,
meetings and mail conversations. Jeff Mogul first proposed the
client-server based model for DHCP. Steve Deering searched the
various IP RFCs to put together the list of network parameters
supplied by DHCP. Walt Wimer contributed a wealth of practical
experience with BOOTP and wrote a document clarifying the behavior of
BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail,
pointing out several inconsistencies in earlier specifications of the
protocol. Steve Alexander reviewed Walker's analysis and the fixes to
the protocol based on Walker's work. And, of course, all the members
of the Dynamic Host Configuration Working Group of the IETF have
contributed to the design of the protocol through discussion and
review of the protocol design.
6. References
[1] Acetta, M., "Resource Location Protocol", RFC887, CMU, December
1983.
[2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC1533, Lachman Technology, Inc., Bucknell
University, October 1993.
[3] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC1122, USC/Information Sciences
Institute, October 1989.
[4] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support, STD 3, RFC1123, USC/Information
Sciences Institute, October 1989.
[5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
(DRARP)", Work in Progress.
[6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
Communications Review), 20(4):50--59, 1990.
[7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC951,
Stanford and SUN Microsystems, September 1985.
[8] Deering, S., "ICMP Router Discovery Messages", RFC1256, Xerox
PARC, September 1991.
[9] Droms, D., "Interoperation between DHCP an BOOTP" RFC1534,
Bucknell University, October 1993.
[10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
Address Resolution Protocol", RFC903, Stanford, June 1984.
[11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
Mechanism for Distributed File Cache Consistency", In Proc. of
the Twelfth ACM Symposium on Operating Systems Design, 1989.
[12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC1034, USC/Information Sciences Institute, November 1987.
[13] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC1035, USC/Information Sciences
Institute, November 1987.
[14] Mogul J., and S. Deering, "Path MTU Discovery", RFC1191,
November 1990.
[15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
Hosts", Work in Progress.
[16] Postel, J., "Internet Control Message Protocol", STD 5, RFC792,
USC/Information Sciences Institute, September 1981.
[17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC1497,
USC/Information Sciences Institute, August 1993.
[18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC1340,
USC/Information Sciences Institute, July 1992.
[19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
Assignment of IP Addresses for use on an Ethernet. (Available
from the Athena Project, MIT), 1989.
[20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC783, NIC,
June 1981.
[21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC1542, Carnegie Mellon University, October 1993.
7. Security Considerations
DHCP is built directly on UDP and IP which are as yet inherently
insecure. Furthermore, DHCP is generally intended to make
maintenance of remote and/or diskless hosts easier. While perhaps
not impossible, configuring such hosts with passwords or keys may be
difficult and inconvenient. Therefore, DHCP in its current form is
quite insecure.
Unauthorized DHCP servers may be easily set up. Such servers can
then send false and potentially disruptive information to clients
such as incorrect or duplicate IP addresses, incorrect routing
information (including spoof routers, etc.), incorrect domain
nameserver addresses (such as spoof nameservers), and so on.
Clearly, once this seed information is in place, an attacker can
further compromise affected systems.
Malicious DHCP clients could masquerade as legitimate clients and
retrieve information intended for those legitimate clients. Where
dynamic allocation of resources is used, a malicious client could
claim all resources for itself, thereby denying resources to
legitimate clients.
8. Author's Address
Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837
Phone: (717) 524-1145
EMail: droms@bucknell.edu
A. Host Configuration Parameters
IP-layer_parameters,_per_host:_
Be a router on/off HRC 3.1
Non-local source routing on/off HRC 3.3.5
Policy filters for
non-local source routing (list) HRC 3.3.5
Maximum reassembly size integer HRC 3.3.2
Default TTL integer HRC 3.2.1.7
PMTU aging timeout integer MTU 6.6
MTU plateau table (list) MTU 7
IP-layer_parameters,_per_interface:_
IP address (address) HRC 3.3.1.6
Subnet mask (address mask) HRC 3.3.1.6
MTU integer HRC 3.3.3
All-subnets-MTU on/off HRC 3.3.3
Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
Perform mask discovery on/off HRC 3.2.2.9
Be a mask supplier on/off HRC 3.2.2.9
Perform router discovery on/off RD 5.1
Router solicitation address (address) RD 5.1
Default routers, list of:
router address (address) HRC 3.3.1.6
preference level integer HRC 3.3.1.6
Static routes, list of:
destination (host/subnet/net) HRC 3.3.1.2
destination mask (address mask) HRC 3.3.1.2
type-of-service integer HRC 3.3.1.2
first-hop router (address) HRC 3.3.1.2
ignore redirects on/off HRC 3.3.1.2
PMTU integer MTU 6.6
perform PMTU discovery on/off MTU 6.6
Link-layer_parameters,_per_interface:_
Trailers on/off HRC 2.3.1
ARP cache timeout integer HRC 2.3.2.1
Ethernet encapsulation (RFC894/RFC1042) HRC 2.3.3
TCP_parameters,_per_host:_
TTL integer HRC 4.2.2.19
Keep-alive interval integer HRC 4.2.3.6
Keep-alive data size 0/1 HRC 4.2.3.6
Key:
MTU = Path MTU Discovery (RFC1191, Proposed Standard)
RD = Router Discovery (RFC1256, Proposed Standard)