Subject: RE: Spec text for Reconfigure-init

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 7 Jun 2001 17:09:21 -0500

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]]
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: Jim Bound <[email-masked]>
Date: Fri, 8 Jun 2001 23:34:53 -0400 (EDT)

Bernie,

> 1) This text still does not state that the transaction-id of the
> Reconfigure-Init is meaningless. It should. 

No comment at this point.

> 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. 

This is not necessary with IPv6.  If the UDP packet exceeds the PMTU or
the Link-MTU fragmentation will happen as part of IPv6 at the client and
the server will reassemble.  Unless your concerned about something else?

> obtained from that server. 

Reconfigur-Init just tells the client to react based on the ORO.  It is
telling the client to act on an interface the server does not have be
known by the client at all thats why authentication is mandatory for this
feature and really all features I guess.

> 
> 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. 
> 
> 
That is correct.  And I agree.