On Apr 27, 2004, at 2:21 AM, Tim Chown wrote:
On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:Let me try to explain why I, as an implementor, do not like the M/O bits very much. ...
Alain,
Could you explain how the functionality of the O/M bits will be replaced
within the ND/etc protocols? Or should they not be replaced?
I'm not convinced they are needed in the first place.
Until now, most people have not worried about DNS resolver discovery because
they run dual-stack networks (and thus use IPv4 transport DNS), but hosts
autoconfiguring in an IPv6-only environment need a method to get DNS and
other configuration info. I agree they can just try DHCPv6, rather than
being told to do so. So is your argument that the client should decide which
protocols to try, as per IPv4, rather than be "forced" to use DHCPv6 when
DHCPv6 may not be secure?
It has nothing to do with DHCPv6 being secure or not.
I think it is up to the client to decide what to do. I have nothing against
hints provided by the network that DHCPv6 may be here, but I'm not
comfortable in having host being told to use it despite other configuration
they may have.
But whether the client decides to use DHCP, or an RA tells it to do so, there
is no way to know whether the DHCP response is from a real or malicious server
(who uses authenticated DHCP? :). And if you're not using DHCP you trust
the RA for the network settings anyway.
not necessarily. You can use manual config. Or still use stateless autoconf
and have an external verification.
So isn't SEND the answer to this,
rather than deprecating flags? You either run in an authenticated/trusted
environment, or you don't...
I agree with you for the M bit. Not for the O bit, as you can trivially mount attacks
that were more difficult to do before. Overriding the configuration of the DNS server
would be much more difficult to detect than overriding the default router.
- Alain.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
