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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 9 May 2002 12:31:49 -0500

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:[email-masked]]
Sent: Thursday, May 09, 2002 12:55 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; [email-masked]
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?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 May 2002 12:43:32 -0500

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

I think it's useful to have the relay be able to do this, but I'm not 
convinced that it's actually going to get used.   There are relays that 
allow you to configure a delayed relay parameter, but do we know of any 
that are actually used this way?   I don't personally know of anybody who'
s doing this.   I suspect that this is something that's a good idea in 
theory, but not in practice, and because of that, I think it might be a 
better choice to simply leave it out of the spec.

The only reason to even *consider* putting it in the spec is that if it 
doesn't go in now, it will never be possible to do it - if clients and 
servers don't do the right thing from the outset, there's no way to 
retrofit this capability later.   I'm just really skeptical that we're ever 
going to need this, and furthermore I'm skeptical that something like this 
is going to get implemented correctly, when nothing will break immediately 
if either the server implementation or the client implementation is 
incorrect.

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