On Nov 9, 2009, at 6:27 PM, Carsten Bormann wrote:
On Nov 10, 2009, at 11:13, Jonathan Hui wrote:
On Nov 9, 2009, at 6:04 PM, Carsten Bormann wrote:
A node that just received an address via DHCP has to do DAD next,
no?
(Well, it is a SHOULD in RFC 3315, but it is there for a reason.)
That's what the 3315 says. But let's be realistic. They're both
centralized mechanisms with very similar properties
Actually, 6lowpan-ND goes the extra mile (section 8.8).
Thinking about this more, is that extra mile necessary? Why not just
accept that the node will use a different address? Reboots are fairly
rare events in most operational environments.
and when assigning addresses the goal is to avoid duplicates. I
could continue the argument and say: after receiving an address
from the whiteboard, why not also verify uniqueness with at least
its 1/2-hop neighbors - just to be extra sure? At some point you
have to just stop and say that the ROI doesn't make sense.
That would not make sense, indeed.
However, the failure mode where two DHCP servers oblivious to each
other hand out overlapping addresses is rather well-known, which is
why every real DHCP client does DAD.
I don't see how whiteboards solves this particular problem. What if I
have two whiteboards that are (improperly) configured in a way that
does not effectively combine their whiteboards?
(I have no idea how a DHCP server would help with a duplicate
EUI-64, either.)
How does a DHCP server deal with duplicate DUIDs? The DHCP server
doesn't have to hand out an address if it doesn't want to.
What kind of DUID would a 6lowpan node use if it implemented DHCP?
Probably DUID-LL, which is just another form of the EUI-64.
I'm not aware of a mechanism a DHCP server can use to differentiate
a rebooted node from another node with the same address.
See above.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
