Date: Wed, 1 Mar 2006 14:05:48 -0500 From: Charles Swiger <cswiger@mac.com> To: "David W. Hankins" <David_Hankins@isc.org> Cc: freebsd-stable@freebsd.org Subject: Re: dhclient in 6.0 Message-ID: <7FBCD272-D73B-4EDC-9DC0-6845C186CE40@mac.com> In-Reply-To: <20060301001626.GM21419@isc.org> References: <d8a4930a0602030429q50f6aa39o@mail.gmail.com> <54176.24.90.33.115.1138971301.squirrel@mail.el.net> <20060203130241.GJ44469@pegasus.dyndns.info> <c7aff4ef0602030524y3a2632d3w@mail.gmail.com> <60155.24.90.33.115.1138981486.squirrel@mail.el.net> <61418.24.90.33.115.1139004207.squirrel@mail.el.net> <20060204005501.GD7613@isc.org> <43E44BAD.50601@mac.com> <20060206225310.GA16149@isc.org> <43EB80D0.2090303@mac.com> <20060301001626.GM21419@isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 28, 2006, at 7:16 PM, David W. Hankins wrote: > On Thu, Feb 09, 2006 at 12:50:08PM -0500, Chuck Swiger wrote: >> If you haven't read this: >> >> http://files.stuartcheshire.org/draft-cheshire-ipv4-acd.txt >> >> ...it's worth considering the way it standardizes (or proposes to >> standardize) >> how ARP traffic from unconfigured IPs should be done to avoid >> flooding large >> networks, or polluting the ARP caches with traffic from >> unconfigured hosts. > > If we get enough demand for zeroconf, or funding for development, or > contributed patches, we can entertain it. Inarguably, such support > does belong in dhclient since you really only want to entertain > zeroconf when dhcp fails, consistently (and also doesn't supply the > relevant new options in DHCPNAK that tell clients not to entertain > zeroconf). > > Doing address conflict detection just to probe the offered address in > DHCP is worthwhile, learning to do ARP also lets us pick up on Bernard > Aboba's DNAv4 draft, which (did I say this already?) I must admit I > have a fondness for, a desire to implement. If a complete lack of > demand from users (so this remains a far, far future). Perhaps I'll be free to contribute some patches, as I've got code that handles layer-2 ARP traffic per the recommendations in the link above. But I don't own the software in question, it was for a client, so I'll have to see whether I can get permission before I can redistribute anything.... > I think that exhausts your last DHCP related query that might > reasonably > have been a part of this thread. We should probably move the rest of > this off-list, if at all. I didn't start the thread; and you asked for feedback about the usage of ISC DHCP under FreeBSD and for suggestions on what you could improve: "So I also still don't even know what base features would get ISC back in the running for...I don't know...FreeBSD 7?" "If anyone would like to work with me to produce a, I shall term, "working implementation of DHCP" that's well suited to FreeBSD's needs, I would like to hear your thoughts on needs and requirements." If you didn't actually want to be answered, then I apologize for indulging your rhetorical questions. [ ... ] > I suspect you may not realize this, so I'll point it out: You are > arguing with ISC's policy, to which as an employee I must adhere, > not me. I'm not really interested in arguing with either you or ISC's policy, frankly. If the policy results in useful, reliable, and secure code, great...but even two out of three isn't bad. I wish I could count on ISC's policy to also deliver secure software, but this policy hasn't done so in the past [1], and you've convinced me that I'd be wasting my time discussing secure coding practices any further with you. Later, -- -Chuck [1]: http://www.isc.org/index.pl?/sw/bind/bind-security.php By my count, two-thirds of the bugs listed here (more than ten) were buffer-overflow or bounds-checking failures; in particular: Name: "maxdname bug" Versions affected: 4.9.5, 4.9.5 patchlevel 1, 4.9.6, 4.9.7, 4.9.8, 8.1, 8.1.1, 8.1.2, 8.2, 8.2 patchlevel 1, 8.2.1, 8.2.2, 8.2.2 patchlevel 1 Severity: MINOR Exploitable: Remotely Type: Denial of service Description: The use of sprintf() with data from the network can result in a buffer overflow condition which may result in unexpected behavior. Because of the placement of the buffer which might be overflowed, it is unlikely this bug will result in serious consequences, however the possibility of a remotely triggered server crash cannot be ruled out.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7FBCD272-D73B-4EDC-9DC0-6845C186CE40>