Subject: Changes to Solicit/Advertise message exchange

From: Ralph Droms <[email-masked]>
Date: Mon, 20 Aug 2001 20:11:04 -0400

Here is the new text describing the Solicit/Advertise message
exchange.  Note that the section numbers have changed.  This
text addresses the following action items from the WG
meeting in London:

* Should addresses in an Advertise message be "real" addresses or
  "informational"; e.g., just prefixes?

  WG consensus: addresses in Advertise are the addresses the server
  will return in a subsequent Reply; client supplies those addresses
  to server in IA in Request message

* Advertise message SHOULD include options for all OROs that were
  included in the Solicit if the server is willing/capable of offering
  a value for that option

  WG consensus: yes

* Server does not respond to Solicit when client wants addresses and
  server has no addresses

  WG consensus: Server should be allowed to respond

* Make the preference field an option

  WG consensus: yes

The changes in this text include:

* Moved some text from "implementor guides" to Solicit/Advertise
  section
* Clarified that the server sends addresses to be assigned in IAs to
  client
* Clarified use of ORO by server to determine options in Advertise
* Added section describing address and option value selection; this
  section to be referenced in later sections.
* Added text for Preference option

Affected text:
--------------

12. Selecting addresses for assignment to an IA

   A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from the following sources:

    -  The link to which the client is attached:

        *  If the server receives the message directly from the client,
           then the client is on the same link to which the interface
           over which the message was received is attached

        *  If the server receives the message from a forwarding relay
           agent, then the client is on the same link as the interface
           to which the relay's address in the message from the relay is
           attached

    -  The DUID supplied by the client

    -  Other information in options supplied by the client

    -  Other information in options supplied by the relay agent

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

13.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.

   Agents MUST silently discard any received Solicit messages if the
   "client-link-local-address" field does not contain a valid link-local
   address.

13.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any Advertise messages that meet any of the
   following criteria:

     o The "Transaction-ID" field value does not match the value the
       client used in its Solicit message.

     o The "client-link-local-address" field value does not match the
       link-local address of the interface upon which the client sent
       the Solicit message.

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

13.3.1. Creation and sending of the Solicit message

   The client sets the "msg-type" field to SOLICIT, and places the
   link-local address of the interface it wishes to configure in the
   "client-link-local-address" field.

   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.

   The client sends the Solicit message to the All DHCP Agents
   multicast address, destination port 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.

13.3.2. Time out and retransmission of Solicit Messages

   The client's first Solicit message on the interface MUST be delayed
   by a random amount of time between the interval of 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 waits ADV_MSG_TIMEOUT, collecting Advertise messages.
   If no Advertise messages are received, the client retransmits
   the Solicit, and doubles the ADV_MSG_TIMEOUT value.  This process
   continues until either one or more Advertise messages are received or
   ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value.  Thereafter, Solicits
   are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been
   made, at which time the client MAY choose to stop trying to DHCP
   configure the interface.  An event external to DHCP is required
   to restart the DHCP configuration process.  A DHCP client MAY,
   alternatively, choose to continue sending Solicit messages at the
   ADV_MSG_MAX interval.

   Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.

13.3.3. Receipt of Advertise messages

   A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
   Solicit message to collect Advertise messages, unless it receives an
   Advertise message with a preference value of 255.  The preference
   value is carried in the Preference option (section  18.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.

13.4. Server Behavior

   A server sends an Advertise message in response to Solicit messages
   it receives to announce the availability of the server to the client.

13.4.1. Receipt of Solicit messages

   The server determines the information about the client and its
   location as described in section 12.  If administrative policy
   permits the server to respond to the client, the server will generate
   and send an Advertise message to the client.

13.4.2. Creation and sending of Advertise messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   values of the following fields from the client's Solicit to the
   Advertise message:

     o transaction-ID

     o client-link-local-address

   The server places one of its IP addresses (determined through
   administrator setting) in the "server-address" field of the Advertise
   message.  The server MAY add a Preference option to carry the
   preference value for the Advertise message.

   The server implementation SHOULD allow the setting of a server
   preference value by the administrator.  The server preference value
   MUST default to zero unless otherwise configured by the server
   administrator.

   The server MUST include options to the Advertise message containing
   any addresses that would be assigned to IAs contained in the Solicit
   message from the client.  If the server will not assign any addresses
   to IAs in a subsequent Request from the client, the server MAY choose
   to send an Advertise message to the client that includes no IA
   options.  The server MAY include other options the server will return
   to the client in a subsequent Reply message.  The information in
   these options will be used by the client in the selection of a server
   if the client receives more than one Advertise message.  The server
   SHOULD include options specifying values for options requested by the
   client in an Option Request Option included in the Solicit message.

   If the Solicit message was received in a Relay-forward message, the
   server constructs a Relay-reply message with the Advertise message in
   the payload of a "server-message" option.  The server unicasts the
   Relay-reply message to the address in the "relay-address" field from
   the Relay-forward message.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the client using
   the "client-link-local-address" field value as the destination
   address.  The Advertise message MUST be unicast through the interface
   on which the Solicit message was received.

18.5. Preference 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_PREFERENCE       |                1              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  pref value   |
     +-+-+-+-+-+-+-+-+

      option-code   OPTION_PREFERENCE (3)

      option-len    MUST be 1

      option-data   The server's preference value for this message.

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 21 Aug 2001 08:38:17 -0500

Ralph:

Thanks for supplying the text. Some comments inline below (prefixed by BV>).

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, August 20, 2001 8:11 PM
To: DHCPv6 discussion list
Subject: Changes to Solicit/Advertise message exchange

  WG consensus: yes

  WG consensus: yes

Affected text:
--------------

BV> If this section applies to *ALL* cases where the server does address
BV> assignment (not just the Solicit/Advertise phase), this is incomplete
BV> as there is the case of the client unicasting to the server - in
BV> which case, the above assumptions do not work.
BV>
BV> I would order the list to match better the processing as follows:
BV>   * ... relay forward message
BV>   * If the server receives the message directly from the client:
BV>        * if the source address is not a link-local address and the
BV>          client is allowed to unicast, then the server must determine
BV>          the location of the client from the non-link-local address.
BV>        * otherwise, the interface on which the message was received.

BV> Are we keeping this "client-link-local-address" field or are we using
BV> the source address of the packet and dropping this field. As we don't
BV> have the complete text, it is difficult to know. If we are using the
BV> IPv6 source address field, then it should specify that field.

BV> What about relays? Shouldn't it be "Agents MUST discard any received
BV> Advertise messages."? A relay will only receive these in relay-reply
BV> messages.

13.3. Client Behavior

   The client sets the "msg-type" field to SOLICIT, and places the
   link-local address of the interface it wishes to configure in the
   "client-link-local-address" field.
BV> See earlier about this "client-link-locak-address" 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
BV> Regarding these "hint" addresses:
BV>  1) They probably won't be in the the IAs (at least not in the IA
BV>     option).
BV>  2) Are these supposed to be complete addresses (not just prefixes)?
BV>     How is the client supposed to determine these? If it already
BV>     had addresses and wants to renew, why is it using Solicit?
   Option in the Solicit message.  The client MUST NOT include any other
   options except those specifically allowed as defined by specific
   options.

   Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.
BV> Wasn't there a single section written earlier that described the
BV> general retransmission algorithm? Can't we just point to that instead
BV> of having to write it out here?

13.4. Server Behavior

     o transaction-ID

     o client-link-local-address
BV> See earlier regarding this field.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the client using
   the "client-link-local-address" field value as the destination
   address.  The Advertise message MUST be unicast through the interface
   on which the Solicit message was received.
BV> The above is broken regarding the sending of responses if we are going
BV> to support server unicast. We really should change this to:
BV>   If Relay-forward received, send Relay-reply OTHERWISE unicast Solicit
BV>   to source IPv6 address of Solicit message. [Perhaps this is overkill
BV>   in the cast of Solicit/Advertise since the client should never be
BV>   unicasting Solicits. But I think it is just simpler and more consistent
BV>   to have *ONE* send policy. Also, we were considering dropping the
BV>   "client-link-local-address" field.

18.5. Preference option

      0                   1                   2                   3

      option-len    MUST be 1

BV> Perhaps add a comment that higher numbers indicate a greater preference
BV> for this server. If no perf value supplied in an Advertise, the default
BV> is 0 (lowest preference).

---

From: Ralph Droms <[email-masked]>
Date: Tue, 21 Aug 2001 09:57:01 -0400

Bernie - I've included a couple of quick comments in line. 
Some of your questions are artifacts, I think, of dealing
with one issue at a time.  For example, I expect to make
the changes concerning the link-local-address field and
client unicast - just haven't done those, yet.

- Ralph

=====
To: DHCPv6 discussion list <[email-masked]>
Subject: RE: Changes to Solicit/Advertise message exchange

Ralph: 

- Bernie Volz 

-----Original Message----- 
From: Ralph Droms [mailto:[email-masked]] 
Sent: Monday, August 20, 2001 8:11 PM 
To: DHCPv6 discussion list 
Subject: Changes to Solicit/Advertise message exchange 

  WG consensus: yes 

  WG consensus: yes 

Affected text: 
-------------- 

RD> To be fixed when I recheck entire doc for client unicast.

RD> OK

RD> link-local-address will be removed...

RD> Right; good catch

13.3. Client Behavior 

   The client sets the "msg-type" field to SOLICIT, and places the 
   link-local address of the interface it wishes to configure in the 
   "client-link-local-address" field. 
BV> See earlier about this "client-link-local-address" field. 

RD> If not the IAs, then where?

RD> This is an issue for WG discussion.

RD> I haven't made that change yet.

13.4. Server Behavior 

     o transaction-ID 

RD> To be fixed soon.

18.5. Preference option 

      0                   1                   2                   3 

      option-len    MUST be 1 

RD> OK.