Subject: RE: Spec text for Reconfigure-init

From: Ralph Droms <[email-masked]>
Date: Sat, 09 Jun 2001 10:01:27 -0400

Bernie - thanks for the feedback.  I'm still waiting for other reviews of 
this text.

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Soapbox: It is *CRUCIAL* that we get feedback from
other WG members *AS SOON AS POSSIBLE*.    In addition
to this Reconfigure-init text, I will be posting some
text excerpts about authentication and DHCPv6 options.
We need you to read and comment on those excerpts so
we can complete the next rev of the draft.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

Here are my responses to your (Bernie's) comments:

1) OK; text to be added pointing out that transaction-id of 
Reconfigure-init will be unused by client

2) I don't know that we have an upper bound on DHCPv6 message size that is 
smaller than the IPv6 UDP datagram size (in contrast with the DHCPv4 
message size limit, which was imposed for compatibility with BOOTP and 
circa 1990 IPv4 stacks).  I don't think the DHCPv6 message size is an issue.

3) I think the semantics should be to reconfigure all addresses (regardless 
of source) *AND* all DHCP-supplied configuration parameters on the 
interface over which the Reconfigure-init message was received.

- Ralph

At 05:09 PM 6/7/2001 -0500, Bernie Volz (EUD) wrote:

>Ralph:
>
>Sorry for the slow response ... some comments (I haven't seen other 
>feedback yet?):
>
>1) This text still does not state that the transaction-id of the 
>Reconfigure-Init is meaningless. It should.
>
>2) What if the number of IAs that might need to be included exceed the 
>packet size? Do we want to provide a means for a client to send multiple 
>Requests in this case. Hopefully, this is not a common occurrance. I would 
>leave the obligation to handle this at the client and it is not a server 
>issue. A server assumes a Reconfigure-Init is done when a Request is 
>received from the client. A client's reconfiguration is not complete until 
>it has done a Request (or multiple Requests) on all of the IAs for the 
>interface. Impacts section 14.3.2.
>
>3) As discussed later (see BV>), we need to clarify exactly what 
>Reconfigure-Init means:
>         a) Reconfigure *ALL* addresses on that particular interface 
> regardless of the server OR
>         b) Reconfigure only the addresses on that particular interface 
> obtained from that server.
>
>There could be cases where there are multiple servers and clients even 
>obtained addresses from multiple servers (because a server was temporarily 
>down, for example). So, we need to be clear.
>
> From the text below, it would imply that all IAs on the interface are 
> sent (at least by my interpretation) - even those that might not have 
> been obtained from the server that sent the Reconfigure-Init. I assume 
> this is the desired behavoir but we need to be more explicit about it.
>
>Additional comments below.
>
>- Bernie Volz
>
>-----Original Message-----
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
>Sent: Thursday, May 31, 2001 5:08 PM
>To: DHCPv6 discussion list
>Subject: Spec text for Reconfigure-init
>
>
>Here's some proposed text describing the use of the Reconfigure-init
>message.  I've extracted this text from the draft spec, so watch the
>section numbers to be warned of elided text.
>
>- Ralph
>
>7. DHCP Constants
>
>     This section describes various program and networking constants used
>     by DHCP.
>
>7.5. Configuration Variables
>
>     This section presents a table of client and server configuration
>     variables and the default or initial values for these variables.  The
>     client-specific variables MAY be configured on the server and MAY be
>     delivered to the client through the "DHCP 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_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_
> 
>|ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_
> 
>|SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_
> 
>|REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_
> 
>|QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_
> 
>|REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_
> 
>|RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_
> 
>|REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_
> 
>|REC_THRESHOLD______|100____|_%_of_required_clients____________________|_
> 
>|SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_
>
>9. Message Formats
>
>     Each DHCP message has an identical fixed format header; some messages
>     also allow a variable format area for options.  Not all fields in
>     the header are used in every message.  In this section, every field
>     is described for every message and fields that are not used in a
>     message are marked as "unused".  All unused fields in a message MUST
>     be transmitted as zeroes and ignored by the receiver of the message.
>
>     The DHCP message header:
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    msg-type   |  preference   |         transaction-ID        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                   client-link-local-address                   |
>       |                          (16 octets)                          |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                                                               |
>       |                         server-address                        |
>       |                          (16 octets)                          |
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       .                                                               .
>       .                            options                            .
>       |                          (variable)                           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>9.10. DHCP Reconfigure-init Message Format
>
>        msg-type                    RECONF-INIT
>
>        preference                  (unused) MUST be 0
>
>        transaction-ID              An unsigned integer generated
>                                    by the server to identify this
>                                    Reconfigure-init message
>
>        client-link-local-address   (unused) MUST be 0
>
>        server-address              The IP address of the DHCP server
>                                    issuing the Reconfigure-init message.
>                                    MUST be of sufficient scope to be
>                                    reachable by all clients.
>
>        options                     See section 17.
>
>14. DHCP Server-Initiated Configuration Exchange
>
>     A server initiates a configuration exchange to force DHCP clients
>     to obtain new addresses and other configuration information.  For
>     example, an administrator may use a server-initiated configuration
>     exchange when links in the DHCP domain are to be renumbered.  Other
>     examples include changes in the location of directory servers,
>     addition of new services such as printing, and availability of new
>     software (system or application).
>
>14.1. Reconfigure-init Message Validation
>
>     Agents MUST silently discard any received Reconfigure-init messages.
>BV> Say "Servers and Agents MUST silently ..."
>
>     Clients MUST discard any Reconfigure-init messages that do
>     not contain an authentication option or that fail the client's
>     authentication check.
>
>14.2. Server Behavior
>
>     A server sends a Reconfigure-init message to cause a client to
>     initiate immediately a Request/Reply message exchange with the
>     server.
>
>14.2.1. Creation and sending of Reconfigure-init messages
>
>     The server sets the "msg-type" field to RECONFIG-INIT. The server
>     generates a transaction-ID and inserts it in the "transaction-ID"
>     field.  The server places its address (of appropriate scope) in the
>     "server-address" field.
>
>     The server MAY include an ORO option to inform the client of what
>     information has been changed or new information that has been added.
>
>     The server MUST include an authentication option with the appropriate
>     settings and add that option as the last option in the "options"
>     field of the Reconfigure-init message.
>
>     The server MUST NOT include any other options in the Reconfigure-init
>     except as specifically allowed in the definition of individual
>     options.
>
>     The server unicasts the Reconfigure-init message to one client.  The
>     server may unicast Reconfigure-init messages to more than one client
>     concurrently; for example, to reliably reconfigure all known clients,
>     the server will unicast a Reconfigure-init message to each client.
>
>     After the server sends the Reconfigure-init message, it waits for a
>     Request message from those clients confirming that each client has
>     received the Reconfigure-init and are thus initiating a Request/Reply
>     transaction with the server.
>
>14.2.2. Time out and retransmission of Reconfigure-init messages
>
>     If the server does not receive a Request message from the client
>     in RECREP_MSG_TIMEOUT milliseconds, the server retransmits
>     the Reconfigure-init message, doubles the RECREP_MSG_TIMEOUT
>     value and waits again.  The server continues this process until
>     REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which point
>     the server SHOULD abort the reconfigure process.
>
>     Default and initial values for RECREP_MSG_TIMEOUT and
>     REC_MSG_ATTEMPTS are documented in section 7.5.
>
>14.2.3. Receipt of Request messages
>
>     The server generates and sends Reply message(s) to the client as
>     described in section 13.4.6, including in the "option" field new
>     values for configuration parameters.
>
>14.3. Client Behavior
>
>     A client MUST always monitor UDP port 546 for Reconfigure-init
>     messages on interfaces upon which it has acquired DHCP parameters.
>     Since the results of a reconfiguration event may affect application
>     layer programs, the client SHOULD log these events, and MAY notify
>     these programs of the change through an implementation-specific
>     interface.
>
>14.3.1. Receipt of Reconfigure-init messages
>
>     Upon receipt of a valid Reconfigure-init message, the client
>     initiates a Request/Reply transaction with the server.  While
>     the Request/Reply transaction is in progress, the client silently
>     discards any Reconfigure-init messages it receives.
>BV> "the client MUST silently discard any Reconfigure-init messages it 
>receives
>BV> on that interface [from that server]." The "from that server" is likely
>BV> important? What if a client has obtained several addresses from one 
>server
>BV> and later tried to obtain more but was unable to from that server so it
>BV> sent a SOLICIT and started working with another server? We probably 
>need to
>BV> be clear about what a Reconfigure-Init message means. Does it mean
>BV> reconfigure ALL addresses on that interface or does it mean to 
>reconfigure
>BV> all addresses allocated by that server? Depending on how that is 
>answered,
>BV> the "silently discard" needs to be conditionalized accordingly. And, what
>BV> happens if another server initiates a Reconfigure-Init (should it not too
>BV> be sent Request/Reply with all addresses). Perhaps it is OK to defer
>BV> processing of this new request until the first has been handled to 
>simplify
>BV> client bookkeeping and operation?
>BV>
>BV> Also, I assume that a client MUST always send a Request, even if it 
>has no
>BV> addresses or obtained configuration information from that server? Should
>BV> this be explicitly stated (it is assumed by the logic).
>
>     DISCUSSION:
>
>        The Reconfigure-init message acts as a trigger that signals
>        the client to complete a successful Request/Reply message
>        exchange.  Once the client has received a Recongfigure-init,
>        the client proceeds with the Request/Reply message
>        exchange (retransmitting the Request if necessary); the
>        client ignores any additional Reconfigure-init messages
>        (regardless of the transaction ID in the Reconfigure-init
>        message) until the Request/Reply exchange is complete.
>        Subsequent Reconfigure-init messages (again independent
>        of the transaction ID) cause the client to initiate a new
>        Request/Reply exchange.
>
>        How does this mechanism work in the face of duplicated
>        or retransmitted Reconfigure-init messages?  Duplicate
>        messages will be ignored because the client will begin
>        the Request/Reply exchange after the receipt of the
>        first Reconfigure-init.  Retransmitted messages will
>        either trigger the Request/Reply exchange (if the first
>        Reconfigure-init was not received by the client) or will
>        be ignored.  The server can discontinue retransmission of
>        Reconfigure-init messages to the client once the server
>        receives the client's Request.
>
>        It might be possible for a duplicate or retransmitted
>        Reconfigure-init to be sufficiently delayed (and
>        delivered out of order) to arrive at the client after
>        the Request/Reply exchange (initiated by the original
>        Reconfigure-init) has been completed.  In this case, the
>        client would initiate a redundant Request/Reply exchange.
>        The likelihood of delayed and out of order delivery is small
>        enough to be ignored.  The consequence of the redundant
>        exchange is inefficiency rather than incorrect operation.
>
>14.3.2. Creation and sending of Request messages
>
>     When responding to a Reconfigure-init, the client creates and
>     sends the Request message in exactly the same manner as outlined in
>     section 13.3.1 with the following difference:
>
>        IAs   The client includes IA options containing the addresses the
>              client currently has assigned to those IAs for the interface
>              through which the Reconfigure-init message was received.
>
>14.3.3. Time out and retransmission of Request messages
>
>     The client uses the same variables and retransmission algorithm as it
>     does with Request messages generated as part of a client-initiated
>     configuration exchange.  See section 13.3.1 for details.
>
>14.3.4. Receipt of Reply messages
>
>     Upon the receipt of a valid Reply message, the client extracts the
>     contents of the "options" field, and sets (or resets) configuration
>     parameters appropriately.  The client records and updates the
>     lifetimes for any addresses specified in IAs in the Reply message.
>     If the configuration parameters changed were requested by the
>     application layer, the client notifies the application layer of the
>     changes using an implementation-specific interface.
>
>17. DHCP options
>
>     Options are used to carry additional information and parameters
>     in DHCP messages.  Every option shares a common base format, as
>     described in section 17.1.
>
>     This document describes the DHCP options defined as part of the base
>     DHCP specification.  Other options may be defined in the future in a
>     separate document.
>
>17.1. Format of DHCP options
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |          option-code          |           option-len          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                          option-data                          |
>       |                      (option-len octets)                      |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>        option-code An unsigned integer identifying the specific option
>                  type carried in this option.
>
>        option-len An unsigned integer giving the length of the data in
>                  this option in octets.
>
>        option-data The data for the option; the format of this data
>                  depends on the definition of the option.
>
>17.3. Option request option
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           OPTION_ORO          |           option-len          |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    requested-option-code-1    |    requested-option-code-2    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                              ...                              |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>        option-code OPTION_ORO (2)
>
>        option-len Variable; equal to twice the number of option codes
>                  carried in this option.
>
>        option-data A list of the option codes for the options requested
>                  in this option.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 10 Jun 2001 22:25:18 -0500

>circa 1990 IPv4 stacks).  I don't think the DHCPv6 message size is an issue.

While I don't forsee any client having such a huge number of addresses, but just
in case, it would be good to know what the maximum message size a server (and
hence client) needs to support? After all it is a lot more work to have to support
an arbitrary message size (ones needs to first determine the size of the message
before reading it with UDP). So, I think we should specify a maximum message size.
I would think that 8192 or 16384 should likely be more the sufficient for most
cases?

Regarding lack of feedback from others ... please don't let that stop you from
publishing other parts. I'm most interested in the client identifier (DHCP Unique
Identifier or whatever) and IA details.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Saturday, June 09, 2001 10:01 AM
To: DHCPv6 discussion list
Subject: RE: Spec text for Reconfigure-init

- Ralph