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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 26 Aug 2001 18:43:45 -0500

More general statement is fine with regard to the relay.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, August 24, 2001 6:24 AM
To: DHCPv6 discussion list
Subject: RE: Change to 'seconds' field in DHCP message header

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: Sun, 26 Aug 2001 22:41:47 -0400

> contents of a relay agent option based on the Elapsed Time

Right, AFAIK there's no reason to be so specific about how this will
be used.

			       _MelloN_