my input is dhcpv6 implementation and deployment state is quite flexible for this topic and code affect and config/admin affect. If we move to unicast instead of multicast for dhc answer would be different ok. /jim
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Ted Lemon > Sent: Friday, May 27, 2005 2:40 PM > To: Bernie Volz (volz) > Cc: [email protected]; Ralph Droms (rdroms); Erik Nordmark; > [email protected]; Iljitsch van Beijnum > Subject: Re: [dhcwg] RE: purpose of m/o bit > > On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote: > > If people are really concerned about this, we can always > add a DHCPv6 > > option to the Solicit that tells the server "I'm a new client and am > > able to receive other configuration parameters even if you're not > > going > > to give me any addresses." Thus, the old servers would ignore this > > option and new servers would know that it is OK to do this. > > DHCPv6 is not a full standard. I don't think it's widely deployed > at this point. I would rather take the risk, as you suggest, than > add an extra protocol to negotiate whether we can do this - it's > extra logic in the server that will be needed for zero clients two > years from now - just another piece of unused code that could be > buggy, because it's never used, and thus could be an avenue > of attack > for some enterprising young script kiddie. > > The time to get conservative about breaking clients by sending them > unexpected responses will come, but it hasn't come yet, IMHO. I > haven't heard anything to contradict this - has anyone else? > > > > _______________________________________________ > dhcwg mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
