On 20-aug-2007, at 15:02, James Carlson wrote:
The first step is to add an option to the router solicitation message
that makes it possible to use this message as the start of a DHCP
exchange. This way, a host doesn't have to know whether it will
receive configuration through RAs or DHCP or both, and there is no
delay if there are no RAs. I'm not sure whether the option should
I don't see what that fixes. It appears to reduce the traffic from
three packets {RS, RA, DHCP Solicit} down to two {RS, RA "Enhanced"},
but I'm not sure why that's an important consideration. Is getting
rid of one packet per link start-up a useful thing to do when it also
means that DHCPv6 servers and routers will be architecturally joined
at the hip, limiting deployment options, and when it means that
Proposed Standard documents need to be roto-tilled?
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
depending on value of the M and O bits, which costs extra time, or
ignoring the M and O bits and adding a fairly significant number of
discovery packets, a host can always do the same thing and reach the
optimum result as fast as possible, regardless of whether the network
runs with RAs only, stateless autoconfig + DHCP for other
configuration, stateless autoconfig + stateful config combined, RAs
but no stateless autoconfig with DHCP, or even no RAs at all and just
DHCP. The way things are now, host behavior will be suboptimal for at
least some of these situations.
A new DHCP capability is address registration. This means that the
host selects one or more addresses autonomously, and then tells the
DHCP server about those addresses, for the following purposes:
You can already do that if you want. See RFC 3315 section 18.1.1 --
you can include IAs for the addresses you want or already have in your
DHCP Request message.
Excellent.
- to avoid DAD
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.
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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
