Subject: RE: Change to 'seconds' field in DHCP message header

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Aug 2001 06:24:05 -0400

Thanks for the feedback; comments in line.

- Ralph

At 12:59 PM 8/23/2001 -0500, Bernie Volz (EUD) wrote:

>Perhaps also worth saying that if the elapsed time is >655.35 seconds, 
>655.35 seconds should be used? It probably will never be the case that 
>a client waits that long, but just in case (since it would be bad to 
>have it wrap around and start at low values again). 

OK.

>I agree with Ted's comment to add Relays. But, perhaps it should be a 
>new sentence, such as "Relays MAY use the data value in this option as 
>input to policy controlling to which server(s) the relay forwards the 
>client's message." 

I think I prefer a more general statement; is there a chance that,
in the future, a relay agent may make a decision about the
contents of a relay agent option based on the Elapsed Time
option value?

>- Bernie 
>
>-----Original Message----- 
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]] 
>Sent: Thursday, August 23, 2001 9:55 AM 
>To: DHCPv6 discussion list 
>Subject: Change to 'seconds' field in DHCP message header 
>
>This change eliminates the 'seconds' field from the message header and 
>replaces it with the "Elapsed Time" option.  The transaction-ID is now 
>24 bits. 
>
>The "Elapsed Time" option carries a 16 bit integer, giving the number 
>of seconds elapsed since the client began its current transaction. 
>The number of seconds is expressed in hundredths of a second (10^-2 
>seconds). The "Elapsed Time" option can indicate times in the range of 
>0 to 655 seconds, in increments of 10^-2 seconds. 
>
>This change address the following issue from the London WG meeting: 
>
>* Add 'secs' field to fixed header 
>
>  WG consensus: if client retransmits, MUST send option called 
>  "milliseconds" 
>
>Affected text: 
>-------------- 
>
>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                  | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |                                                               | 
>     |                   client-link-local-address                   | 
>     |                          (16 octets)                          | 
>     |                                                               | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |                                                               | 
>     |                         server-address                        | 
>     |                          (16 octets)                          | 
>     |                                                               | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     .                                                               . 
>     .                            options                            . 
>     |                          (variable)                           | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>
>
>18.6. Elapsed Time 
>
>      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_ELAPSED_TIME      |           option_len          | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>     |          elapsed time         | 
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>
>      option-code   OPTION_ELAPSED_TIME (4) 
>
>      option-len    MUST be 2 
>
>      option-data   The amount of time since the client began its 
>                    current DHCP transaction.  This time is expressed in 
>                    hundredths of a second (10-2seconds): 
>
>   If a client retransmits a DHCP message, it MUST include an Elapsed 
>   Time option in the message to indicate how long the client has been 
>   trying to complete a DHCP transaction.  Servers MAY use the data value 
>   in this option as input to policy controlling how a server responds 
>   to a client message.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2001 11:57:16 -0400

> >have it wrap around and start at low values again). 

Ga-zikes, is the field only 16 bits?   I think 655 seconds is not very
long for some possible applications.   Is there any reason not to make
this a 32-bit field?

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Fri, 24 Aug 2001 12:31:53 -0400

Yup - as a first pass, I took the initiative to define the field to be 16 bits.

I'm happy to make it 32 bits, 64 bits - measured in milliseconds, microseconds or the time between the light turning green and the guy behind me honking his horn here in Boston.

Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Aug 2001 13:48:41 -0400

> Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me...

Yeah, I saw that.   I tend to agree, except that 10 minutes is
actually within two orders of magnitude of a reasonable timeout, so
I'd like a little more breathing room, since there may be some cases
where long timeouts might be wanted.   I can't see a use for this
offhand, but it doesn't seem like it's worth saving two bytes here,
since milliseconds will only be sent in exceptional cases anyway, and
only in the client payload, which is generally small.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 09:11:35 -0400

(Please note that this message has been sent to the new dhc WG mailing list, [email-masked].  The current mailing lists, [email-masked] and [email-masked], will be taken off line tomorrow, Aug 28, around 4PM.  I will arrange for e-mail to the old lists to be forwarded to [email-masked] for a couple of months.  I will also save the archives from the old lists and make them available on line as soon as possible. - RD)

Another alternative for greater range would be to define the units of the data value to be tenths of a second.  My intuition is that tenths of a second should be sufficiently precise...

Can anyone give us the benefit of experience with the 'secs' field in DHCPv4?  There hasn't been any interest in defining a new option with greater range or precision than the current 0-255 seconds measured in seconds.  Has the range or precision in DHCPv4 been inadequate in any specific instance?

- Ralph

At 10:44 PM 8/26/2001 -0400, you wrote:

>> I think 16-bits is enough (with the counter maxing out). If an attempt goes
>> on that long, no server is probably available and the relays (or servers)
>> will likely long have taken alternative actions (which probably failed as
>> well). So, I see little need to make this more than 16-bits.
>
>That's a pretty set of suppositions, but you may well be wrong.   Why
>not make sure that it works if you are?
>
>                               _MelloN_

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 10:35:23 -0400

> Can anyone give us the benefit of experience with the 'secs' field
> in DHCPv4?  There hasn't been any interest in defining a new option
> with greater range or precision than the current 0-255 seconds
> measured in seconds.  Has the range or precision in DHCPv4 been
> inadequate in any specific instance?

A millisecond is a thousandth of a second.  So the range with 16 bits
is 65.536 seconds, not 655.36 seconds as Bernie said.  I think this is
too short to represent a reasonable set of cases.  There may be
devices, e.g. low power scientific devices that might want to probe
the network from time to time, but can't afford the power cost of
probing it frequently, where the desirable retry interval may be much
longer than that.  I do not know of any such devices that are in use
right now, but it seems plausible to me that someone might want to
deploy one, and I would like to account for that possibility.

> Another alternative for greater range would be to define the units
> of the data value to be tenths of a second.  My intuition is that
> tenths of a second should be sufficiently precise...

I think it's good to have better granularity than that.   We specify
the retry timeout in milliseconds, so the retry interval should also
be computed in milliseconds.

This is an option that will only be present in exceptional cases, and
we are discussing a difference in space consumption of 33%.  I am all
in favor of saving space in frequently-transmitted packets, but this
is not much space, and will not be in the most frequently-transmitted
packets.

I may be wrong that we need this extra breathing room, but the cost is
low, and I'd really appreciate it if we could stop arguing about this
and just take the risk that we might be being a little bit generous in
our allocation of bits.

			       _MelloN_

dhcwg mailing list
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 21:03:24 -0400

Comments in line; anyone have specific examples of the use of the
'secs' field in DHCPv4?  If it hasn't been used at all in DHCPv4
perhaps we don't need to define it at this point in DHCPv6.

- Ralph

At 10:35 AM 8/27/2001 -0400, Ted Lemon wrote:

>A millisecond is a thousandth of a second. 

The original definition I sent out defined the value in the
option field to be expressed in hundredths of a second
(10^-2 seconds), giving the range of 0-655.36 seconds,

>be computed in milliseconds.

Are there specific examples of when millisecond granularity is needed?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 22:17:36 -0400

> Are there specific examples of when millisecond granularity is needed?

I have definitely found that 1s granularity is too coarse for DHCPv4,
at least in the ISC DHCP server, and I have been meaning to make it
more fine-grained, but have not yet done so.

I think it violates the principle of least surprise to call an option
milliseconds when it's not - if it's centiseconds, call it that.   WRT
granularity, if we are specifying millisecond granularity, people are
likely to do their math in millisecond granularity, and I think it's
confusing to specify a variety of different granularities.

I will not respond to any further questions about this.  I think I've
made my reasoning clear.  I can't prove that we need 32 bits.  I think
we do.  I am not without experience in these matters, so I think that
my gut feeling on this is worth something, but I can't prove it, and
it's pointless for you to ask me to try.  Do what you will.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 22:18:54 -0400

> perhaps we don't need to define it at this point in DHCPv6.

The ISC DHCP server uses it to bypass load balancing at a
user-specified threshhold.   The Microsoft DHCP relay can be
configured to relay based on a user-specified threshhold.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 22:29:05 -0400

Ted - I specifically titled this new option "Elapsed Time" 
(see the original text I sent out) to be more descriptive
(rather than 'secs' or 'milliseconds') and to allow for
other units in the expression of the data value.

I'm not asking for proof of the requirement for milliseconds
or 32 bits.  We have a difference of opinion, and I'd like to
find out if there's any operational experience that would give
us something more than opinion to base a decision on.
If nobody speaks up to say that the 'secs' field in DHCPv4
has actually been used in practice,
perhaps we don't need to define an "Elapsed Time" option
at all.

More comments in line...

- Ralph

>more fine-grained, but have not yet done so.

Are you referring to the granularity of the 'secs' field?  How
would you make it more fine-grained if the units for the fields
are defined as "seconds" in the spec?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 27 Aug 2001 22:30:24 -0400

My last message crossed with yours in flight; please
ignore my previous request for specific examples.
Thanks...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 27 Aug 2001 22:54:48 -0400

> >I will not respond to any further questions about this.

Promises, promises.   :'}   I'm sorry for all the mistakes in the
previous couple of messages - I'm working from what I remember seeing
a while back, when we had decided to call the message milliseconds and
represent it in milliseconds, so I apparently didn't read your writeup
very carefully.   :'(

> are defined as "seconds" in the spec?

I'm referring to timeout computations.   And if timeout computations
are more fine-grained, then it would make sense for the secs field to
be more fine-grained as well.   Otherwise the implementor has to
answer the question "if the difference between the last transmission
time and the current transmission time is less than one half the
granularity, do I specify an interval of zero or one?"   I would
rather not force the implementor to make this decision, because s/he
will get it wrong, probably even if it is carefully specified in the
draft.   I don't know many junior geeks who have taken courses in
numerical methods.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Tue, 28 Aug 2001 16:05:34 -0400

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

   The DHCP message header:
      0                   1                   2                   3
     .                          (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.

      relay-address               An address assigned to the interface
                                  on which the message from the client
                                  was received.

      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.

      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.

      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

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

      Confirm   Confirm the validity of assigned addresses and other
                configuration changes through the server from which the
                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

      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,

      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.

   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.

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.

     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.

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

   The client adds a DUID option to identify itself to the server.  The
   client adds any other appropriate options, including one or more IA
   options (if the client is requesting that the server assign it some
   network addresses).  The list of addresses in each included IA MUST
   be empty.  If the client is not requesting that the server assign it
   any addresses, the client omits the IA option.

   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
   setting the preferred and valid lifetimes of those addresses to zero.

   The server controls the time at which the client contacts the server
   to extend the lifetimes on assigned addresses through the T1 and
   T2 parameters assigned to an IA. If the server does not assign an
   explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
   shortest preferred lifetime of any address assigned to the IA and
   T2 defaults to 0.875 times the shortest preferred lifetime of any
   address assigned to the IA.

   At time T1 for an IA, the client initiates a Request/Reply message
   exchange to extend the lifetimes on any addresses in the IA. The
   client includes an IA option with all addresses currently assigned to
   the IA in its Request message.

   The client sets the "msg-type" field to RENEW. The client generates a
   transaction ID and inserts this value in the "transaction-ID" field.

   The client places the address of the destination server in the
   "server-address" field.

   The client adds a DUID option to identify itself to the server.  The
   client adds any appropriate options, including one or more IA options
   (if the client is requesting that the server extend the lease on some
   IAs; note that the client may check the status of other configuration
   parameters without asking for lease extensions).  If the client does
   include any IA options, it MUST include the list of addresses the
   client currently has associated with that IA.

   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.

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.
   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
   the client was originally received was originally received in a
   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
   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.

   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
   message.  The relay forwards the server message through the interface
   identified in the "relay-address" field in the Relay-reply message.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Aug 2001 11:49:05 -0400

How about making relay-address an option?   I don't think it will be
useful in most cases, so it seems like a drag to have it part of the
fixed header.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Wed, 29 Aug 2001 13:22:40 -0400

Before I make the change, let me make sure I understand your proposal.  If the relay agent does not include the relay-address, the relay agent has to cause the forwarded message to have a source address - an address with the widest scope possible; e.g., a link-local address isn't useful - that is assigned to the interface on which the message was received by the agent from the client.

- Ralph