Subject: [dhcwg] Desynchronization in DHCPv6

From: Christian Vogt <[email-masked]>
Date: Tue, 05 Dec 2006 18:29:37 +0100

DHCP folks,

I might be missing something, but I am wondering how DHCPv6 realizes
desynchronization between the Advertise messages of multiple servers:

When a DHCPv6 client initiates a 4-way handshake, it sends a Solicit
message and waits for responding Advertise messages for a period of 1.0
to 1.1 s.

At first glance, it seems that the purpose of this delay is to allow
multiple on-link DHCPv6 servers to randomly delay their Advertise
messages a bit in an effort to avoid collisions with the Advertise
messages of neighboring servers.

OTOH, according to RFC 3315, a DHCPv6 server sends its Advertise message
promptly upon receiving a Solicit message.  Hence my questions:

(1)  Why does a client have to wait for between 1.0 and 1.1 s after
sending the Solicit message?

(2)  And if not through randomly delaying Advertise messages, how does
DHCPv6 guarantee desynchronization between the Advertise messages of
multiple servers?

Thanks a lot in advance!

- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

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

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 5 Dec 2006 10:06:45 -0800

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 9:30 AM
> To: [email-masked]
> Subject: [dhcwg] Desynchronization in DHCPv6
> 
> DHCP folks,
> 
> I might be missing something, but I am wondering how DHCPv6 
> realizes desynchronization between the Advertise messages of 
> multiple servers:
> 
> When a DHCPv6 client initiates a 4-way handshake, it sends a 
> Solicit message and waits for responding Advertise messages 
> for a period of 1.0 to 1.1 s.
> 
> At first glance, it seems that the purpose of this delay is 
> to allow multiple on-link DHCPv6 servers to randomly delay 
> their Advertise messages a bit in an effort to avoid 
> collisions with the Advertise messages of neighboring servers.

Uh, I thought the delay was to allow the client to potentially receive
Advertises from multiple servers, possibly of different Preference
values, or potentially some other criteria that the client wishes to use
to select between different servers.

---

From: Christian Vogt <[email-masked]>
Date: Tue, 05 Dec 2006 19:36:46 +0100

Hello Andre,

clients certainly need to collect Advertise messages from multiple 
servers, and this requires them to wait for a little while after 
sending the Solicit message.  But given that servers transmit their 
Advertise messages immediately upon receiving the Solicit message, why 
does the wait period have to as long as 1 s?

Kind regards,
- Christian

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 5 Dec 2006 10:45:06 -0800

> Sent: Tuesday, December 05, 2006 10:37 AM
> To: Andre Kostur
> Cc: [email-masked]
> Subject: Re: [dhcwg] Desynchronization in DHCPv6
> 
> Hello Andre,
> 
> clients certainly need to collect Advertise messages from 
> multiple servers, and this requires them to wait for a little 
> while after sending the Solicit message.  But given that 
> servers transmit their Advertise messages immediately upon 
> receiving the Solicit message, why does the wait period have 
> to as long as 1 s?

To allow for propogation times from the clients to the servers, which
may cross one or more Relays, which may also be on slow links.  (Think
sattelite links: There's 1/2 second or more return trip time....)

---

From: Christian Vogt <[email-masked]>
Date: Tue, 05 Dec 2006 20:11:58 +0100

This makes perfect sense, Andre, thanks.

I assume that DHCPv6 relies on link layer mechanisms to cope with the 
potential for collisions when multiple servers on the same link send 
Advertise messages simultaneously.

Regards,
- Christian

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 5 Dec 2006 11:17:56 -0800

> Sent: Tuesday, December 05, 2006 11:12 AM
> To: Andre Kostur
> Cc: [email-masked]
> I assume that DHCPv6 relies on link layer mechanisms to cope 
> with the potential for collisions when multiple servers on 
> the same link send Advertise messages simultaneously.

I'm a little confused about which "collisions" you're talking about.  It
seems that you're talking about low-level packet collisions.  DHCP (both
v4 and v6) operates up at the UDP layer of networking.  Packet collision
on the wire is below where DHCP cares about.  That's the problem for
Ethernet/Token Ring/ATM/IEE 1394/etc. to take care of.

---

From: Christian Vogt <[email-masked]>
Date: Tue, 05 Dec 2006 20:31:25 +0100

The reason I was mentioning it is that some IETF protocols do 
introduce desynchronization delays above the link layer.  E.g., IPv6 
Neighbor Discovery operates at the IP layer, and it calls for access 
routers to delay a multicast Router Advertisement message for up to 
500 ms after receiving a Router Solicitation message.

Independent of this, I see your point that collision handling should 
be a responsibility of the link layer.

Ciao,
- Christian