Sorry Jim, said "when DHCPv6 may not be secure", i.e. there will be many deployments like now with IPv4 where authentication is not deployed by the local administrator. Bear in mind there is very little use of RFC3118 DHCP authentication today for IPv4.
So key message is DHCPv6 can be deployed securely, and it's great to hear you'll be building and testing this on Moonv6 in a full implementation. Tim On Wed, Apr 28, 2004 at 11:30:07PM -0400, Bound, Jim wrote: > DHCPv6 is secure read the spec. > /jim > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Alain Durand > > Sent: Wednesday, April 28, 2004 2:37 PM > > To: Tim Chown > > Cc: IETF IPv6 Mailing List > > Subject: Re: [rfc2462bis] whether we need the M/O flags > > > > > > 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
