Iljitsch van Beijnum writes: > On 20-aug-2007, at 15:02, James Carlson wrote: > > To me, that sounds like high cost with essentially no benefit. What > > am I missing? > > What it does and saves is very much dependent on the circumstances. > > Saving one or two packets here or there in and of itself is probably > not compelling (but a good secondary goal because those multicasts > can clog up wireless networks). The main benefit is that it > simplifies the host behavior: rather than either holding off on DHCP
Actually, it doesn't do that either. It doesn't do that because we _already_ have deployed implementations of all of the existing protocols. There are systems out there that already have separate router discovery and DHCP, already work, and that are unlikely to be "upgraded" at any point in the near future -- if ever at all. Because of that, any robust implementation of the scheme you're suggesting would need to support _both_ types of operation. That includes most sane vendors: they'll be forced to implement, test, and support both modes of operation in all of their products. The alternative leads to an interoperability problem. A new-style client introduced into an old-style network won't get the all-inclusive RAs with DHCP data that it wants, and will then be forced to drop back to the previous (now existing) mode of operation with DHCP Solicit. Thus, adding new features like you're suggesting is always more complex. It's only by _removing_ features that we can make things simpler. > > Avoiding DAD doesn't sound like a good goal to me. It means that the > > system _assumes_ that the rest of the world is perfect and never has > > any problems. > > Let me rephrase: making DAD more efficient. If there's a DHCP server > present that knows about all addresses anyway, then obviously the > DHCP server is capable of determining whether two nodes are trying to > use the same address, which is probably more efficient than hosts > doing DAD for each address. This means that the DHCP server is perfect in its operation and omniscient about all hosts that may be attached to the network, even the statically-configured ones. I've yet to meet one that is this good. > Personally, I'm comfortable with foregoing DAD on EUI-64 derived > addresses, because if the EUI-64 uniqueness fails things aren't going > to work anyway. There is always the possibility of someone > configuring a duplicate EUI-64 address manually, though, so there is > still _some_ potential for trouble. So I guess no DAD for EUI-64 or > DAD for everything is something that network administrators should be > able to control. I have no problem with implementations including a tunable to disable DAD for the people who like to work without a net (both figuratively and literally), but the default still ought to be to use DAD, and nothing DHCPv6 does ought to discourage that. To use a phrase from another era: "trust, but verify." -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
