Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 29 Aug 2001 13:06:32 -0500

See my comments below (prefixed by BV>).

But, let me make a few general comments. I assume that the changes to centralize
the sending of messages and retransmissions discussions have not yet been applied
and hence I will refrain from commenting about those sections of text.

Let me also suggest that the previous suggestion by Ted (which I also was
suggested) to move the "relay-address" into an option is probably not so good.
Consider ... how does the relay know on which interface to send the client the
Reply? The only way it could get this without the option is by getting the
destination address from the IPv6 header of the Relay-Reply. While this is likely
much more possible with the IPv6 socket API, it really isn't that easy if one
considers the more restrictive IPv4 socket API (recvfrom only returns source
info, not destination info). I ran into this issue when I received the end of
Ralph's text (section 16.2). I have no problem if we want to gamble on this feature
being available on all IPv6 stacks (to obtain the IPv6 destination address).
I added this comment after making many of the comments about the changes needed to
make this an option below. So, depending on what we decide, the comments below
regarding making this an option may need to be ignored.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Tuesday, August 28, 2001 4:06 PM
To: [email-masked]
Subject: [dhcwg] Changes to remove "client-link-local-address" from the
DHCPv6 header

I've completed the changes to remove the client-link-local-address
field from the DHCP message header.  Relay agents and servers will now
use the source address from the IP header to reply to client messages.

The changes include:

* Message format and descriptions in section 8 to remove the
  client-link-local-address field  
* Relay agent message format and descriptions in section 9 to
  accommodate the client-return-address field 
* Address selection described in section 12 to allow for unicast
  client messages
* The description of client behavior in sections 13 and 14
  to remove the use of the client-link-local-address field and to
  specify that the client must send the message through the interface
  to be configure, to correctly set the source address in the IP
  header
* The description of server behavior in sections 13 and 14 to remove
  the use of the client-link-local-address and change the format of
  the relay agent messages
* The description of relay behavior in section 15 based on the new
  relay agent message format

Note that the relay agent message has to include information about:

1. The return address to which the server should send the Relay-reply
   message
2. A link identifier/subnet selector that the server uses to select
   configuration information for the client
3. An interface identifier and return address for the client that the
   relay agent uses to forward the message from the server back to the
   client

In DHCPv4, all of these functions are supplied by 'giaddr'.  However,
the source address from the IP header isn't sufficient (which we had
discussed using for DHCPv6), because it may be awkward or impossible
(and, usually suboptimal) to force the message from the relay agent to
be sent to the server through the interface on which the message from
the client was received.  So, I've retained the relay-address field
and added a client-return-address field in the Relay-forward for
2. and 3., and specified that the server use the source address from
the IP header for 1.

The text affected by these changes is included below.  Please review
and follow up with comments.

- Ralph

=====

8. 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   |               transaction-ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                            options                            .
     .                          (variable)                           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.1. DHCP Solicit Message Format

      msg-type         SOLICIT

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Solicit message.

      server-address   (unused) MUST be 0

      options          See section 18.

8.2. DHCP Advertise Message Format

      msg-type         ADVERTISE

      transaction-ID   An unsigned integer used to identify this
                       Advertise message.  Copied from the client's
                       Solicit message.

      server-address   The IP address of the server that generated
                       this message.  If the DHCP domain crosses
                       site boundaries, then this address MUST be
                       globally-scoped.

      options          See section 18.

8.3. DHCP Request Message Format

      msg-type         REQUEST

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Request message.

      server-address   The IP address of the server to which the this
                       message is directed, copied from an Advertise
                       message.

      options          See section 18.

8.4. DHCP Confirm Message Format

      msg-type         CONFIRM

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Confirm message.

      server-address   MUST be zero.

      options          See section 18.

8.5. DHCP Renew Message Format

      msg-type         RENEW

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Renew message.

      server-address   The IP address of the server to which this Renew
                       message is directed, which MUST be the address
                       of the server from which the IAs in this message
                       were originally assigned.

      options          See section 18.

8.6. DHCP Rebind Message Format

      msg-type         REBIND

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Rebind message.

      server-address   MUST be zero.

      options          See section 18.

8.7. DHCP Reply Message Format

      msg-type         REPLY

      transaction-ID   An unsigned integer used to identify this Reply
                       message.  Copied from the client's Request,
                       Confirm, Renew or Rebind message.

      server-address   The IP address of the server.  If the DHCP domain
                       crosses site boundaries, then this address MUST
                       be globally-scoped.

      options          See section 18.

8.8. DHCP Release Message Format

      msg-type         RELEASE

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Release message.

      server-address   The IP address of the server that assigned the
                       IA.

      options          See section 18.

8.9. DHCP Decline Message Format

      msg-type         DECLINE

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Decline message.

      server-address   The IP address of the server that assigned the
                       addresses.

      options          See section 18.

8.10. DHCP Reconfigure-init Message Format

      msg-type         RECONFIG-INIT

      transaction-ID   (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 18.

9. Relay messages

   Relay agents exchange messages with servers to forward messages
   between clients and servers that are not connected to the same link.

9.1. Relay-forward message

      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   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type                    RELAY-FORW

      prefix-length               The length of the prefix in the
                                  address in the "relay-address" field.
BV> Drop prefix-length as not used.

      relay-address               An address assigned to the interface
                                  on which the message from the client
                                  was received.
BV> See previous email from Ted and myself regarding the relay-address;
BV> we should make it an option since it won't always be needed (as the
BV> source IPv6 header address can be used in most cases). ALSO, see
BV> my intro to this message before making this change.)

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options                     MUST include a "Client message
                                  option"; see section 18.7.

9.2. Relay-reply message

      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   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      msg-type        RELAY-REPL

      prefix-length   The length of the prefix in the address in the
                      "relay-address" field.
BV> Drop prefix-length as not used.

      relay-address   An address identifying the interface on the
                      relay agent through which the message from the
                      server should be forwarded; copied from the
                      "relay-forward" message.
BV> See above (make an option). Note that the server MUST send this
BV> option back in the relay sent it in Relay-Forw.

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options         MUST include a "Server message option"; see
                      section 18.8.

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
           and the source address in the IP datagram in which the
           message was received is a link-local address, 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 directly from the client
           and the source address in the IP datagram in which the
           message was received is not link-local address, then the
           client is on the link identified by the source address in the
           IP datagram

        *  If the server receives the message from a forwarding relay
           agent, then the client is on the same link as the one to
           which the interface identified by the relay-address field in
           the message from the relay is attached
BV> This will need to be updated to reflect relay-address option (if no
BV> option, use source address else use relay-address option value).

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

13.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any received Advertise messages in which the
   "Transaction-ID" field value does not match the value the client used
   in its 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. 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.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 transaction-ID field from the client's Solicit to the
BV> Drop "the values of"
   Advertise message.

   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 directly by the server, the
   server unicasts the Advertise message directly to the client using
   the address in the source address field from the IP datagram in
   which the Solicit message was received.  The Advertise message MUST
   be unicast through the interface on which the Solicit message was
   received.

   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 directly to the relay agent using
   the address in the source address field from the IP datagram in which
   the Relay-forward message was received.

14. DHCP Client-Initiated Configuration Exchange

   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  The client
   may initiate the configuration exchange as part of the operating
   system configuration process or when requested to do so by the
   application layer.

   The client uses the following messages to initiate a configuration
   event:

      Request   Obtain initial configuration information (from a server
                identified in a previously received Advertise message)
                when the client has no assigned addresses
BV> Request may also be used at any time, not just "initial" configuration
BV> information ... when the client has no assigned addresses.

      Confirm   Confirm the validity of assigned addresses and other
                configuration changes through the server from which the
BV> "configuration changes"? how about "configuration information".
                configuration information was obtained when the client's
                assigned addresses may not be valid; for example, when
                the client reboots or loses its connection to a link
BV> also, this isn't just from the server from the info was obtained?

      Renew     Extend the lease on an IA through the server that
                originally assigned the IA

      Rebind    Extend the lease on an IA through any server willing to
                extend the lease

      Release   Release the lease on an IA and release all of the
                addresses contained in the IA,
BV> I think we still have open whether all or some address can be released.

      Decline   Decline the assignment of one or more addresses in an
                IA.

   A client uses the Release/Reply message exchange to indicate to the
   DHCP server that the client will no longer be using the addresses in
   the released IA.
BV> Why have this? Isn't this already covered by the above entry for Release?

   A client uses the Decline/Reply message exchange to indicate to the
   DHCP server that the client has detected that one or more addresses
   assigned by the server is already in use on the client's link.
BV> Why have this? Same as release.

14.1. Client Message Validation

   Clients MUST silently discard any received client messages (Request,
   Confirm, Renew, Rebind, Release or Decline messages).

   Servers MUST discard any received client messages in which the
   "options" field contains an authentication option, and the server
   cannot successfully authenticate the client.

   Servers MUST discard any received Request, Renew, Release or Decline
   message in which the "server-address" field value does not match any
   of the server's addresses.

14.2. Server Message Validation

   Servers MUST silently discard any received server messages
   (Advertise, Reply or Reconfigure-init messages).

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

     o The "transaction-ID" field value in the server message does
       not match the value the client used in its Request or Release
       message.
BV> This should apply to all client messages, not just Request/Release.

     o The server message contains an authentication option, and the
       client's attempt to authenticate the message fails.

   Relays MUST discard any Relay-reply message in which the
   "client-link-local-address" field in the Relay-reply message does not
   contain a valid link-local address.
BV> This is now the "client-return-address" and does it really need to
BV> only be a link-local address? I don't think so (though it likely will
BV> mostly be link-local).

14.3. Client Behavior

   A client will use Request, Confirm, Renew and Rebind messages to
   acquire and confirm the validity of configuration information.  A
   client may initiate such an exchange automatically in order to
   acquire the necessary network parameters to communicate with nodes
   off-link.  The client uses the server address information from
   previous Advertise message(s) for use in constructing Request and
   Renew message(s).  Note that a client may request configuration
   information from one or more servers at any time.

   A client uses the Release message in the management of IAs when
   the client has been instructed to release the IA prior to the IA
   expiration time since it is no longer needed.

   A client uses the Decline message when the client has determined
   through DAD or some other method that one or more of the addresses
   assigned by the server in the IA is already in use by a different
   client.

14.3.1. Creation and sending of Request messages

   If a client has no valid IPv6 addresses of sufficient scope to
   communicate with a DHCP server, it may send a Request message to
BV> Why "communicate with a DHCP server"? And the client could well
BV> have many addresses of sufficient scope - that's not the point
BV> of the request. We really should just say that "If the client
BV> is using stateful address configuration and either needs an
BV> initial set of address or additional addresses, it MUST send a
BV> Request message to obtain new addresses." (or something like that)
   obtain new addresses.  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.
BV> How about "The client copies the "server-address" field as received in
BV> the selected Advertise message to the "server-address" field of the
BV> Request."

   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
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't
BV> it that people wanted the addresses received in the Advertise to be
BV> used here?
   any addresses, the client omits the IA option.

   The client sends the Request message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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 server will respond to the Request message with a Reply
   message.  If no Reply message is received within REP_MSG_TIMEOUT
   milliseconds, the client retransmits the Request with the same
   transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
   again.  The client continues this process until a Reply is received
   or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
   which time the client MUST abort the configuration attempt.  The
   client SHOULD report the abort status to the application layer.

   Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
   are documented in section 7.5.

14.3.2. Creation and sending of Confirm messages

   Whenever a client may have moved to a new link, its IPv6 addresses
   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 sends the Confirm message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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.

   Servers will respond to the Confirm message with a Reply message.  If
   no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Confirm with the same transaction-ID,
   and doubles the REP_MSG_TIMEOUT value, and waits again.  The client
   continues this process until a Reply is received or QRY_MSG_ATTEMPTS
   unsuccessful attempts have been made, at which time the client MUST
   abort the configuration attempt.  The client SHOULD report the abort
   status to the application layer.

   Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
   are documented in section 7.5.

   If the client receives no response to its Confirm message, it MAY
   restart the configuration process by locating a DHCP server with an
   Advertise message and sending a Request to that server, as described
   in section 14.3.1.

14.3.3. Creation and sending 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 Request 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 remove addresses from the IA by
BV> 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.
BV> The above will be reworked in new material Mark, Ted, and I should be
BV> providing.

   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.

   The client sends the Renew message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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 server will respond to the Renew message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Renew with the same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client
   continues this process until a Reply is received or until time T2 is
   reached (see section 14.3.4).

   Default and initial values for REP_MSG_TIMEOUT are documented in
   section 7.5.

14.3.4. Creation and sending 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 sends the Rebind message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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 server will respond to the Rebind message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Rebind with the same transaction-ID, and
   doubles the REP_MSG_TIMEOUT value, and waits again.  The client
   continues this process until a Reply is received.

   Default and initial values for REP_MSG_TIMEOUT are documented in
   section 7.5.

   The client has several alternatives to choose from if it receives no
   response to its Rebind message.

    -  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

14.3.5 (omitted)

14.3.6. Creation and sending 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.

   If the client is configured to use authentication, the client
   generates the appropriate authentication option, and adds this option
   to the "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  18.11 for more
   details about the authentication option.

   The client sends the Release message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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.

14.3.7. (Omitted)

14.3.8. (Omitted)

14.3.9. Creation and sending 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.

   If the client is configured to use authentication, the client
   generates the appropriate authentication option, and adds this option
   to the "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  18.11 for more
   details about the authentication option.

   The client sends the Decline message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, 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.

14.3.10. (Omitted)

   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
   value, and waits again.  The client continues this process until a
   Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
   been made, at which time the client SHOULD abort the attempt to
   decline the address.  The client SHOULD return the abort status to
   the application, if an application initiated the release.

   Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
   are documented in section 7.5.

14.3.11. 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.
BV> This section should replace Release with Decline (Section 14.3.8
BV> covers the Release case). No need for application layer to be told
BV> about Declines?

14.4. Server Behavior

   For this discussion, the Server is assumed to have been configured in
   an implementation specific manner with configuration of interest to
   clients.

14.4.1. Receipt of Request messages

   Upon the receipt of a valid Request message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Request message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Request and IA option is included the
   client is requesting the configuration of a new IA by the server.
BV> We need to clarify this behavoir and what "new" means (may be cases
BV> where client thinks it is new, but server already knows about it).
   The server MUST take the clients IA and associate a binding for that
   client in an implementation-specific manner within the server's
   configuration parameter database for DHCP clients.

   If the server cannot provide addresses to the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server can provide addresses to the client it MUST send back
   the IA to the client with all fields entered and a status of Success,
   and add the IA as a new client binding.

   The server adds options to the Reply message for any other
   configuration information to be assigned to the client.

14.4.2. Receipt of Confirm messages

   Upon the receipt of a valid Confirm message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Confirm and an IA option is included the
   client is requesting confirmation that the addresses in the IA are
   valid.  The server SHOULD locate the clients binding and verify the
   information in the IA from the client matches the information stored
   for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the information for the client does not
   match what is in the server's records for that client the server
   should send back an empty IA with status set to Conf_NoMatch.

   If the server finds a match to the Confirm then the server should
   send back the IA to the client with status set to success.

14.4.3. Receipt of Renew messages

   Upon the receipt of a valid Renew message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Renew and IA option from a client it
   SHOULD locate the clients binding and verify the information in the
   IA from the client matches the information stored for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the addresses in the IA for the client do
   not match the clients binding the server should return an empty IA
   with status set to Renw_NoMatch.

   If the server cannot Renew addresses for the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server finds the addresses in the IA for the client then the
   server SHOULD send back the IA to the client with new lease times
   and T1/T2 times if the default is not being used, and set status to
   Success.

14.4.4. Receipt of Rebind messages

   Upon the receipt of a valid Rebind message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Rebind and IA option from a client it
   SHOULD locate the clients binding and verify the information in the
   IA from the client matches the information stored for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the addresses in the IA for the client do
   not match the clients binding the server should return an empty IA
   with status set to Rebd_NoMatch.

   If the server cannot Rebind addresses for the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server finds the addresses in the IA for the client then the
   server SHOULD send back the IA to the client with new lease times
   and T1/T2 times if the default is not being used, and set status to
   Success.

   There is a significant difference between Renew and Rebind messages:
   Because the Rebind message is processed by a single server, the
   responding server can actually change the addresses in the IA.
   However, because multiple servers may respond to a Rebind, all they
   can safely do is update T1, T2 (for the IA) and lifetimes (for
   individual addresses).

14.4.5. Receipt of Release messages

   Upon the receipt of a valid Release message, the server examines the
   IAs and the addresses in the IAs for validity.  If the IAs in the
   message are in a binding for the client and the addresses in the IAs
   have been assigned by the server to those IA, the server deletes
   the addresses from the IAs and makes the addresses available for
   assignment to other clients.

   The server then generates a Reply message.  If all of the IAs were
   valid and the addresses successfully released,, the server sets the
   "status" field to "Success".  If any of the IAs were invalid or if
   any of the addresses were not successfully released, the server
   releases none of the addresses in the message and sets the "status"
   field to "NoBinding"(section 7.4).

   If the client successfully releases some but not all of the addresses
   in an IA, the IA continues to exist and holds the remaining,
   unreleased addresses.

   A client can send an option containing an IA with no listed addresses
   to release implicitly all of the addresses in the IA.

   A server is not required to (but may choose to as an implementation
   strategy) retain any record of an IA from which all of the addresses
   have been released.

14.4.6. Sending of Reply messages

   If the Request, Confirm, Renew, Rebind or Release message from
BV> What about Decline messages (add to list).
   the client was originally received was originally received in a
BV> typo - duplicated "was originally received".
   Relay-forward message from a relay, the server places the Reply
   message in the options field of a Relay-response message and copies
   the relay-address and client-link-local-address fields from the
BV> client-return-address
   Relay-forward message into the Relay-response message.

   The server then unicasts the Reply or Relay-reply to the source
   address from the IP datagram in which the original message was
   received.

16. Relay Behavior

   For this discussion, the Relay may be configured to use a list of
   server destination addresses, which may include unicast addresses,
   the All DHCP Servers multicast address, or other multicast addresses
   selected by the network administrator.  If the Relay has not been
   explicitly configured, it MUST use the All DHCP Servers multicast
   address as the default.

16.1. Relaying of client messages

   When a Relay receives a valid client message, it constructs
   a Relay-forward message.  The relay places an address from
   the interface on which the client message was received in the
   "relay-address" field.  This address will be used by the server to
   identify the link to which the client is connected and will be used
   by the relay to forward the Advertise message from the server back to
   the client.

   The relay copies the source address from the IP datagram
   in which the message was received from the client into the
   client-link-local-address field in the Relay-forward message.
BV> client-return-address

   The relay constructs a "client-message" option 18.7 that contains
   the entire message from the client in the data field of the
   option.  The relay places the "relay-message" option along with any
   "relay-specific" options in the options field of the Relay-forward
   message.  The Relay then sends the Relay-forward message to the list
   of server destination addresses that it has been configured with.

16.2. Relaying of server messages

   When the relay receives a Relay-reply message, it extracts the server
   message from the "server-message" option and forwards the message to
   the address in the client-link-local-address field in the Relay-reply
BV> client-returnn-address
   message.  The relay forwards the server message through the interface
   identified in the "relay-address" field in the Relay-reply message.

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 29 Aug 2001 16:30:17 -0400

Bernie, I agree with your conclusion, but differ with your reasoning. 
Comments inline:

> "Bernie Volz (EUD)" wrote:
> 
> destination address from the IPv6 header of the Relay-Reply.

I believe if the relay is using the simple API and it must specify the right
source address, then the relay will need to send through a socket which is
bound to the desired local address.  I believe it will also receive its
response through that bound socket, so learning the responses packet's
destination address is accomplished by noticing the socket through which it
arrived.  So, its doable with the simple API, though I think its a bit more
complexity than you'd want relays to have to implement.

As you note below, if using the advanced API, then specifying the source
address on sending and learning the destination address on receiving is
easier, and is almost as easy as writing a the relay's local address into a
fixed place in the packet, but not quite.

I think the explicit specification of a relay-address is needed in cases
where either the relay has no global address on the proper interface (and
thus needs to indicate a prefix-only address, which should work just fine),
or where specifying the source address may complicate the packet's route out
of the relay (this is speculation).  If a relay must detect one of these
conditions, then it complicates the relay, or encourages relay authors to
opt for the safer solution and always use the option (in which case it isn't
optional in a practical sense).

I think those are the technical considerations.  I think I'd have the
relay-address always present (not move it to an option) for relay agent
implementation simplicity.

> While this is
> likely

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Aug 2001 10:36:14 -0400

> fixed place in the packet, but not quite.

This is kind of a strange thing.  If you need the functionality of the
advanced API, why not use the advanced API?

> optional in a practical sense).

I think the DHCP server should be using the prefix that the relay
reports when doing address assignments, not the IP address that the
relay reports.   Maybe I'm missing something here - are we back to
overloading these two functions?

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 Aug 2001 10:58:18 -0400

>overloading these two functions?

Suppose the field name and definition are changed as in the figure below,
and:

* The server chooses an address for the client
  based on the link-prefix (details TBD; could
  use 0s to indicate prefix length or include
  explicit prefix length or ???)
* The server sends the Relay-reply message to 
  the source address in the IP header of the
  Relay-forward message
* The relay forwards the Reply message to the
  client on the link identified by the
  link-prefix

This proposal still overloads the identification of the link
on which the relay forward the Reply to the client with the
selection of an address for the client by the server.  We
could either add a separate field for specifying a prefix
for address selection or define an option (like the DHCPv4
subnet selection option).  I would be inclined to define
an option that might be used by either a client or a
relay (or both?). 

- Ralph

=====

      0                   1                   2                   3
     |                          link-prefix                          |

      msg-type                    RELAY-FORW

      link-prefix                 A prefix assigned to the link from
                                  which the client message was received.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Aug 2001 11:16:06 -0400

> an option that might be used by either a client or a

Sounds reasonable.

			       _MelloN_