RE: [dhcwg] dhcpv6-24: Elapsed Time option

["Bernie Volz (EUD)" <[e-mail]>]

Oh, I should add that in -24 we have:

---

22.9. 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 (8)

      option-len    2.

      elapsed-time  The amount of time since the client began its
                    current DHCP transaction.  This time is expressed in
                    hundredths of a second (10^-2 seconds).

   A client SHOULD include an Elapsed Time option in messages to
   indicate how long the client has been trying to complete a DHCP
   transaction.  Servers and Relay Agents use the data value in this
                         ^^^^^^^^^^^^^^^^
   option as input to policy controlling how a server responds to a
   client message.  For example, the elapsed time option allows a
   secondary DHCP server to respond to a request when a primary server
   hasn't answered in a reasonable time.


---

I would say to keep things simple, we explicitly DISALLOW relays from using this field??

- Bernie

-----Original Message-----
From: Bernie Volz (EUD) 
Sent: Thursday, May 09, 2002 1:32 PM
To: 'Ted Lemon'
Cc: 'Thomas Narten'; [e-mail]
Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option 


Ted:

Exactly correct. And in fact from my reading of the DHCPv4 specification, this is required by it. Here's the text from RFC 2131:

     To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.

I did forget to mention that we might just need to do that - have the server return the elapsed time option to the client!

I don't have any issue in changing things from DHCPv4 ... I was just assuming we MIGHT want to use that model since it has been tried and proven?

I also agree that having the relay base the forwarding on the elapsed time is likely bad - but again, that was assumed to happen with DHCPv4!!

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[e-mail]]
Sent: Thursday, May 09, 2002 12:55 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; [e-mail]
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option 


> If the server should fail to get a Reply to the Request and restarts the 
> Solicit, time should not be reset.
>
> - Time is 0 when first Renew/Rebind is sent. Increases with each 
> retransmission until timeout or Reply.
>
> - Time is 0 when first Decline/Release is sent. Increases with each 
> retransmission until timeout or Reply.
>
> - Time is 0 when first Information-Request is sent. Increases with each 
> retransmission until timeout or Reply.
>

I think if you let the relay agent make relaying decisions based on the 
time sent by the client, you're in big trouble.   Picture this:

client sends solicit A, t=0
relay sends solicit to server A
client sends solicit B, t=100
relay sends solicit to server B
server A responds to solicit A with advertise A
client sends Request A, t=100
relay sends Request A to server B
server B drops Request A on the floor

repeat until bored

The only reliable way to fix this is to have the server send the time it 
received from the client in the solicit back to the client in the advertise,
  and for the client to use that time in every subsequent Request, 
regardless of how long it has to retry.   This is complicated to specify, 
and complicated to implement.   Do we really want this?