On Feb 18, 2009, at 11:53 AM, Jack Bates wrote:
Kevin Loch wrote:
Just how DO we get the message to the IETF that we need all the
tools we
have in v4 (DHCP, VRRP, etc) to work with RA turned off?
You don't, because there isn't really a technical reason for turning
off RA. RA is used as a starting point. It can push you to DHCPv6 or
any number of other options (such as SLAAC). The same argument goes
for multicast versus broadcast. The idea is to add an extra level
that allows for better manipulation and versatility.
There is a reason for turning off RA and the IETF (and you) just don't
seem to
get it.
There are real world situations in which not all routers are created
equal and
it is important for the DHCP server to tell the correct host which
router to use
for default.
There are also a number of security issues available in the "Just
trust some
unsolicited broadcast about where to send all your network traffic."
approach
to host bootstrapping that bother some people.
We can argue all you want about how pathological these cases are, but,
the fact remains that trusting some unsolicited broadcast from a device
claiming to be a router as your starting point isn't viable in a
number of
real world installations and an alternative needs to be made available.
Of course, better support and vendor implementation of all the
different options would be nice.
Sure, but, so would DHCP functionality equivalent to what we have in
IPv4.
If you want SLAAC or RA or whatever, more power to you. Some
installations
do not. They want DHCP equivalent functionality with the same
security model.
Most networks have broadcast controls that are mostly vendor
specific hacks. Now they'll have multicast controls, which is good
to have anyways.
This assumes a lot, but, even if it's true, it doesn't change the fact
that some
organizations like the existing DHCP model and there's no reason not to
provide equivalent functionality in IPv6.
Owen
