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?

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg