[dhcwg] Revised updates for transmisssion and retransmission
Ralph Droms <rdroms@cisco.com> Mon, 17 September 2001 13:51 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12511; Mon, 17 Sep 2001 09:51:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00520; Mon, 17 Sep 2001 09:46:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00489 for <dhcwg@optimus.ietf.org>; Mon, 17 Sep 2001 09:46:11 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12419 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 09:46:08 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA28520 for <dhcwg@ietf.org>; Mon, 17 Sep 2001 09:44:51 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010917094320.00b4dc08@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Sep 2001 09:44:32 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Subject: [dhcwg] Revised updates for transmisssion and retransmission
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Here is the text for transmission and
retransmission, based on Bernies's
feedback. I copied come of Bernie's comments
back into this text, along with my responses
and edited text.
Several of Bernie's comments referred to
issues that will be addressed by or
otherwise depends on the text being
generated for IAs. Additional changes
to this text will be made once the text
for IAs has been finalized.
- Ralph
7.5. Configuration Variables
This section presents a table of client and server configuration
variables and the default or initial values for these variables.
BV> Didn't we want to drop this retransmission parameter option
BV> since it opens up many cans of worms as per the San Diego IETF?
RD> Dropped sentence: "The client-specific variables MAY be configured
RD> on the server and MAY be delivered to the client through the "DHCP
RD> Retransmission Parameter Option" in a Reply message.
Parameter Default Description
-------------------------------------
MIN_SOL_DELAY 1 MIN (secs) to delay 1st mesg
MAX_SOL_DELAY 5 MAX (secs) to delay 1st mesg
ADV_TIMEOUT 500 SOL Retrans timer (msecs)
ADV_MAX_RT 30 MAX timer value (secs)
SOL_MAX_ATTEMPTS 0 MAX attempts (0 = infinite)
REP_TIMEOUT 250 Retrans timer (msecs) for Reply
REP_MAX_RT 0 MAX Retrans time (0 = infinite)
REQ_MAX_ATTEMPTS 10 MAX Request/Confirm/Renew/Rebind attempts
REL_MSG_ATTEMPTS 5 MAX Release/Decline attempts
SRVR_PREF_WAIT 2 Advertise Collect timer (secs)
13. Reliability of Client Initiated Message Exchanges
DHCP clients are responsible for reliable delivery of messages in the
client-initiated message exchanges described in sections 14 and 15.
If a DHCP client fails to receive an expected response from a server,
the client must retransmit its message. This section describes the
retransmission strategy to be used by clients in client-initiated
message exchanges.
The client begins the message exchange by transmitting a message to
the server. The message exchange terminates when either the client
successfully receives the appropriate response or responses from a
server or servers, or when the message exchange is considered to have
failed according to the retransmission mechanism described below.
The client retransmission behavior is controlled and describe by five
variables:
RT Retransmission timeout
IRT Initial retransmission time
MRC Maximum retransmission count
MRT Maximum retransmission time
MRD Maximum retransmission duration
RAND Randomization factor
With each message transmission or retransmission, the client sets RT
according to the rules given below. If RT expires before the message
exchange terminates, the client recomputes RT and retransmits the
message.
Each of the computations of a new RT include a randomization factor
(RAND), which is a random number chosen with a uniform distribution
between -0.1 and +0.1. The randomization factor is included to
minimize synchronization of messages transmitted by DHCP clients.
The algorithm for choosing a random number does not need to be
cryptographically sound. The algorithm SHOULD produce a different
sequence of numbers from each invocation of the DHCP client.
RT for the first message transmission is based on IRT:
RT = IRT + RAND*IRT
RT for each subsequent message transmission is based on the previous
value of RT:
RT = RTprev + RAND*RTprev
MRT specifies an upper bound on the value of RT. If MRT has a value
of 0, there is no upper limit on the value of RT. Otherwise:
if (RT > MRT)
RT = MRT + RAND*MRT
MRC specifies an upper bound on the number of times a client may
retransmit a message. If MRC has a value of 0, the client MUST
continue to retransmit the original message until a response is
received. Otherwise, the message exchange fails if the client
attempts to transmit the original message more than MRC times.
MRD specifies an upper bound on the length of time a client may
retransmit a message. If MRD has a value of 0, the client MUST
continue to retransmit the original message until a response is
received. Otherwise, the message exchange fails if the client
attempts to transmit the original message more than MRD seconds.
BV> Just to be clear, might be good to say that EITHER or BOTH of
BV> MRC or MRD can stop retransmissions? In most cases it appears
BV> that only one is active, but it is always possible that both
BV> could be.
RD> Added following paragraph.
If both MRC and MRD are non-zero, the message exchange fails whenever
either of the conditions specified in the previous paragraph are met.
14. DHCP Server Solicitation
This section describes how a client locates servers. The behavior
of client and server implementations is discussed, along with the
messages they use.
[...]
14.3. Client Behavior
A client uses the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached.
BV> While probably not something that is needed in this section, we
BV> really don't have much text to describe the "transaction-ID". All
BV> we generally say is to "generate a transaction ID". However, we
BV> should make it clear to clients that they should attempt to
BV> generate "unique" transaction ids. Unique here is best if it is
BV> over a long period of time, but it must be longer than any cache
BV> times in servers. Probably the best rule of thumb is for clients
BV> to use to generate this number by incrementing it. Then the only
BV> issue is what to set it to when (re)booting - especially if there
BV> is no means to remember the last used number.
RD> Added section 14.3.1
14.3.1. Use of Transaction-ID field
The "transaction-ID" field holds a value used by clients and servers
to synchronize server responses to client messages. A client SHOULD
choose a different transaction-ID for each new message it sends. A
client MUST leave the transaction-ID unchanged in retransmissions of
messages.
14.3.2. Creation of Solicit messages
The client sets the "msg-type" field to SOLICIT. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.
The client includes a DUID option to identify itself to the server.
The client MUST include options for any IAs to which it wants the
server to assign addresses. The client may include addresses in the
IAs as a hint to the server about addresses for which the client
may have a preference. The client MAY include an Option Request
Option in the Solicit message. The client MUST NOT include any other
options except those specifically allowed as defined by specific
options.
14.3.3. Transmission of Solicit Messages
The client sends the Solicit message to the All_DHCP_Agents multicast
address. The client MUST use an address assigned to the interface
for which the client is interested in obtaining configuration
information as the source address in the IP header of the datagram
carrying the Rebind message, with the destination port set to 547.
The source port selection can be arbitrary, although it SHOULD be
possible using a client configuration facility to set a specific
source port value.
The client's first Solicit message on the interface MUST be delayed
by a random amount of time between MIN_SOL_DELAY and MAX_SOL_DELAY.
This random delay desynchronizes clients which start at the same time
(e.g., after a power outage).
The client transmits the message according to section 13, using the
following parameters:
IRT ADV_TIMEOUT
MRC 0
MRT ADV_MAX_RT
MRD 0
The mechanism in section 13 is modified as follows for use in the
transmission of Solicit messages. The message exchange is not
terminated by the receipt of an Advertise before ADV_TIMEOUT has
BV> ADV_MSG_TIMEOUT doesn't exist. I think you renamed it to
BV> ADV_TIMEOUT? ADV_MSG_TIMEOUT is used many times.
RD> Fixed all references to ADV_MSG_TIMEOUT
elapsed. Rather, the client collects Advertise messages until
ADV_TIMEOUT has elapsed. The first RT MUST be selected to be
strictly greater than ADV_TIMEOUT by choosing RAND to be strictly
greater than 0.
BV> Did you mean MRD, not MRT? MRT limits the time of a single
BV> retransmission. Also, the "If the DHCP client is otherwise configured"
BV> made me re-read the paragraph several times. Perhaps there is a better
BV> way to state this? "If the DHCP client is configured with a non-zero
BV> MRC or MRD, ...".
BV> Oh, might you want to say "SOL_MAX_ATTEMPTS" instead of MRC?
RD> Edited text in following paragraph to
A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client
is configured with either MRC or MRD set to a value other than
0, it MUST stop trying to configure the interface if the message
exchange fails. After the DHCP client stops trying to configure the
interface, it MAY choose to restart the reconfiguration process after
some external event, such as user input, system restart, or when the
client is attached to a new link.
14.3.4. Receipt of Advertise messages
BV> Also, this Retransmit logic is a bit weird beause of SRVR_PREF_WAIT.
BV> Does it make sense to state something like "A client only retransmits
BV> a Solicit if it fails to receive any Advertises before the retransmission
BV> timer expires. If a client receives one or more Advertise messages, it
BV> then must wait SRVR_PREF_WAIT seconds from the time of the transmit
BV> for any additional Advertise messages before proceeding."
RD> Edited following paragraph
A client only retransmits a Solicit message if it does not receive
an Advertise within SRVR_PREF_WAIT seconds after sending a Solicit
message. A client MUST collect Advertise messages for SRVR_PREF_WAIT
seconds, unless it receives an Advertise message with a preference
value of 255. The preference value is carried in the Preference
option (section 19.5). Any Solicit that does not include a
Preference option is considered to have a preference value of 0. If
the client receives an Advertise message with a preference value of
255, then the client MAY act immediately on that Advertise message
without waiting for any more additional Advertise messages.
Upon receipt of one or more validated Advertise messages, the client
selects one or more Advertise messages based upon the following
criteria.
- Those Advertise messages with the highest server preference value
are preferred over all other Advertise messages.
- Within a group of Advertise messages with the same server
preference value, a client MAY select those servers whose
Advertise messages advertise information of interest to the
client. For example, the client may choose a server that
returned an advertisement with configuration options of interest
to the client.
Once a client has selected Advertise message(s), the client will
typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was
received, and so on. Depending on the requirements of the client's
invoking user, the client MAY initiate a configuration exchange with
the server(s) immediately, or MAY defer this exchange until later.
If the client needs to select an alternate server in the case that a
chosen server does not respond, the client chooses the server with
the next highest preference value.
The client MAY choose a less-preferred server if that server has a
better set of advertised parameters, such as the available addresses
advertised in IAs.
[...]
15. DHCP Client-Initiated Configuration Exchange
[...]
15.3. Client Behavior
[...]
15.3.1. Creation and transmission of Request messages
If the client is using stateful address configuration and needs
either an initial set of addresses or additional addresses, it
MUST send a Request message to obtain new addresses and other
configuration information. The client includes one or more IAs in
the Request message, to which the server assigns new addresses. The
server then returns IA(s) to the client in a Reply message.
The client generates a transaction ID and inserts this value in the
"transaction-ID" field.
The client places the address of the destination server in the
"server-address" field.
The client adds a DUID option to identify itself to the server. The
client adds any other appropriate options, including one or more IA
options (if the client is requesting that the server assign it some
network addresses). The list of addresses in each included IA MUST
be empty. If the client is not requesting that the server assign it
any addresses, the client omits the IA option.
If the client has a source address that can be used by the server
as a return address and the client has received a Client Unicast
option (section 19.12) from the server, the client SHOULD unicast
the Request message to the server. Otherwise, the client sends the
Request message to the All_DHCP_Agents multicast address. The client
MUST use an address assigned to the interface for which the client
is interested in obtaining configuration information as the source
address in the IP header of the datagram carrying the Rebind message,
with the destination port set to 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC REQ_MAX_ATTEMPTS
MRT REP_MAX_RT
MRD 0
If the message exchange fails, the client MAY choose one of the
following actions:
- Select another server from a list of servers known to the client;
e. g., servers that responded with an Advertise message
- Initiate the server discovery described in section 14
- Terminate the configuration process and report failure
15.3.2. Creation and transmission of Confirm messages
Whenever a client may have moved to a new link, its IPv6 addresses
and other configuration information may no longer be valid. Examples
of times when a client may have moved to a new link include:
o The client reboots
o The client is physically disconnected from a wired connection
o The client returns from sleep mode
o The client using a wireless technology changes cells
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs,
in its Confirm message. Any responding servers will indicate the
acceptability of the addresses with the status in the IA it returns
to the client.
The client sets the "msg-type" field to CONFIRM. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.
The client sets the "server-address" field to 0.
The client adds a DUID option to identify itself to the server. The
client adds any appropriate options, including one or more IA options
(if the client is requesting that the server confirm the validity of
some network addresses). If the client does include any IA options,
it MUST include the list of addresses the client currently has
associated with that IA.
The client MUST use an address assigned to the interface for which
the client is interested in obtaining configuration information as
the source address in the IP header of the datagram carrying the
Rebind message, with the destination port set to 547. The source
port selection can be arbitrary, although it SHOULD be possible using
a client configuration facility to set a specific source port value.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC REQ_MSG_ATTEMPTS
MRT REP_MAX_RT
MRD 0
If the message exchange fails, the client MUST restart the
configuration process by locating a DHCP server as described
in section 14. The client SHOULD report the failure of the
configuration process to the application layer.
15.3.3. Creation and transmission of Renew messages
IPv6 addresses assigned to a client through an IA use the same
preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server assigns preferred and valid
lifetimes to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client sends a Renew message to the server containing
an "IA option" for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to the
server's administrative configuration. The server may also add new
addresses to the IA. The server may remove addresses from the IA by
setting the preferred and valid lifetimes of those addresses to zero.
The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and
T2 parameters assigned to an IA. If the server does not assign an
explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
shortest preferred lifetime of any address assigned to the IA and
T2 defaults to 0.875 times the shortest preferred lifetime of any
address assigned to the IA.
At time T1 for an IA, the client initiates a Request/Reply message
exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned to
the IA in its Request message.
The client sets the "msg-type" field to RENEW. The client generates a
transaction ID and inserts this value in the "transaction-ID" field.
The client places the address of the destination server in the
"server-address" field.
The client adds a DUID option to identify itself to the server. The
client adds any appropriate options, including one or more IA options
(if the client is requesting that the server extend the lease on some
IAs; note that the client may check the status of other configuration
parameters without asking for lease extensions). If the client does
include any IA options, it MUST include the list of addresses the
client currently has associated with that IA.
If the client has a source address that can be used by the server
as a return address and the client has received a Client Unicast
option (section 19.12) from the server, the client SHOULD unicast
the Renew message to the server. Otherwise, the client sends the
Renew message to the All_DHCP_Agents multicast address. The client
MUST use an address assigned to the interface for which the client
is interested in obtaining configuration information as the source
address in the IP header of the datagram carrying the Rebind message,
with the destination port set to 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC 0
MRT REP_MAX_RT
MRD 0
The mechanism in section 13 is modified as follows for use in the
transmission of Renew messages. The message exchange is terminated
when time T2 is reached (see section 15.3.4), at which time the
client begins a Rebind message exchange.
15.3.4. Creation and transmission of Rebind messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded),
the client initiates a Rebind/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the
IA in its Rebind message. The client sends this message to the
All_DHCP_Agents multicast address.
The client sets the "msg-type" field to REBIND. The client generates
a transaction ID inserts this value in the "transaction-ID" field.
The client sets the "server-address" field to 0.
The client adds a DUID option to identify itself to the server.
The client adds any appropriate options, including one or more IA
options. If the client does include any IA options (if the client is
requesting that the server extend the lease on some IAs; note that
the client may check the status of other configuration parameters
without asking for lease extensions), it MUST include the list of
addresses the client currently has associated with that IA.
The client MUST use an address assigned to the interface for which
the client is interested in obtaining configuration information as
the source address in the IP header of the datagram carrying the
Rebind message, with the destination port set to 547. The source
port selection can be arbitrary, although it SHOULD be possible using
a client configuration facility to set a specific source port value.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC 0
MRT REP_MAX_RT
MRD 0
The mechanism in section 13 is modified as follows for use in the
transmission of Renew messages. The message exchange is terminated
when the lease for the IA expires (see section 11), at which time the
client has several alternative actions to choose from:
- When the lease on the IA expires, the client may choose to use a
Solicit message to locate a new DHCP server and send a Request
for the expired IA to the new server
- Some addresses in the IA may have lifetimes that extend beyond
the lease of the IA, so the client may choose to continue to use
those addresses; once all of the addresses have expired, the
client may choose to locate a new DHCP server
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs
15.3.5. Receipt of Reply message in response to a Request, Confirm,
Renew or Rebind message
[...]
15.3.6. Creation and transmission of Release messages
The client sets the "msg-type" field to RELEASE. The client generates
a transaction ID and places this value in the "transaction-ID" field.
The client places the IP address of the server that allocated the
address(es) in the "server-address" field.
The client adds a DUID option to identify itself to the server. The
client includes options containing the IAs it is releasing in the
"options" field. The addresses to be released MUST be included in
the IAs. The appropriate "status" field in the options MUST be set
to indicate the reason for the release.
The client MUST NOT use any of the addresses in the IAs in the
message as the source address in the Release message or in any
subsequently transmitted message.
If the client has a source address that can be used by the server
as a return address and the client has received a Client Unicast
option (section 19.12) from the server, the client SHOULD unicast
the Release message to the server. Otherwise, the client sends the
Release message to the All_DHCP_Agents multicast address. The client
MUST use an address for the interface to which the IAs in the Release
message are assigned as the source address for the Release message,
with the destination port set to 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
A client MAY choose to wait for a Reply message from the server in
response to the Release message. If the client does wait for a
Reply, the client MAY choose to retransmit the Release message.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC REL_MSG_ATTEMPTS
MRT REP_MAX_RT
MRD 0
The client MUST abandon the attempt to release addresses if the
Release message exchange fails.
The client MUST stop using all of the addresses in the IA(s) being
released as soon as the client begins the Release message exchange
process. If an IA is released but the Reply from a DHCP server
is lost, the client will retransmit the Release message, and the
server may respond with a Reply indicating a status of "Nobinding".
Therefore, the client does not treat a Reply message with a status
of "Nobinding" in a Release message exchange as if it indicates an
error.
Note that if the client fails to release the IA, the addresses
assigned to the IA will be reclaimed by the server when the lease
associated with it expires.
15.3.7. Receipt of Reply message in response to a Release message
Upon receipt of a valid Reply message, the client can consider the
Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release.
15.3.8. Creation and transmission of Decline messages
The client sets the "msg-type" field to DECLINE. The client generates
a transaction ID and places this value in the "transaction-ID" field.
The client places the IP address of the server that allocated the
address(es) in the "server-address" field.
The client adds a DUID option to identify itself to the server. The
client includes options containing the IAs it is declining in the
"options" field. The addresses to be released MUST be included in
the IAs. The appropriate "status" field in the options MUST be set
to indicate the reason for declining the address.
The client MUST NOT use any of the addresses in the IAs in the
message as the source address in the Decline message or in any
subsequently transmitted message.
If the client has a source address that can be used by the server
as a return address and the client has received a Client Unicast
option (section 19.12) from the server, the client SHOULD unicast
the Decline message to the server. Otherwise, the client sends the
Decline message to the All_DHCP_Agents multicast address. The client
MUST use an address for the interface to which the IAs in the Release
message are assigned as the source address for the Decline message,
with the destination port set to 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
The client transmits the message according to section 13, using the
following parameters:
IRT REP_TIMEOUT
MRC REL_ATTEMPTS
MRT REP_MAX_RT
MRD 0
The client MUST abandon the attempt to decline addresses if the
Decline message exchange fails.
15.3.9. Receipt of Reply message in response to a Decline message
Upon receipt of a valid Reply message, the client can consider the
Decline event successful.
[...]
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg