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).
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 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.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
