DHCPv6-4.1.mumble

David W. Hankins David_Hankins at isc.org
Thu Jun 12 15:16:52 UTC 2008


On Thu, Jun 12, 2008 at 12:31:15AM +0000, bmanning at vacation.karoshi.com wrote:
> On Wed, Jun 11, 2008 at 03:06:04PM -0700, David W. Hankins wrote:
> > then you're S.O.L, the ietf has never defined a v4 option that
> > can carry ipv6 addresses for nameservers (or any other config
> > option in dhcpv4).
> 
> 	figured that out a -long- time ago.

then you are asking for something you knew you couldn't psosibly have?

> 	necs'ity is the mother of invention.
> 	i've had to do worse in my time (still backporting
> 	crap ISC took out of BIND and removing crap they
> 	stuffed in - regardless of the IETF standards track... :)

so far i haven't seen a cogent argument that mandates a departure
from ietf standards on this issue.  carrying the v4 nameservers
in dhcpv4, and the v6 nameservers via dhcpv6 is clean from single
stack and fate-sharing perspectives, and adding additional options in
either side just complicates things.

that our client presently does not recombine configuration state
from multiple different administrative domains - something it has
never done (not even with multiple interfaces in dhcpv4!) - does
not seem to me to be sufficient evidence for a need for a third
nameservers option.

> > if you're doing stateless autoconf, and want to configure nameservers,
> > consider if you haven't already "the O flag", stateless dhcpv6, and
> > the previously quoted config snippet.
> 
> 	that does look like the easiest option, run both v4 and v6
> 	dameons and hope like heck the end nodes don't fall all over
> 	themselves when presented w/ two, possibly conflicting sets
> 	of data.

that's precisely what stock isc dhclient in 4.x will do.  i'm not
aware of other client behaviours.

> 	I want -both- and ISC's DHCPv6 does not appear to be able to
> 	give it to me.  S.O.L. indeed.

we accept patches to dhcp-suggest at isc.org.

beyond that, our plans are varied.  the center of my ideas on how to
move forward with dhclient is to reduce the amount of work dhclient
does; just the protocol, and maybe converting wireformats to some
other markup for applications.  this places the chore of configuring
a system (or application on the desktop) in the hands of some system
daemon, which collects input from system-config, dhcp-config, and
maybe other sources, and reliably sorts them into an image to present
to the OS and applications.

the most expedient thing, to me, seems to be to put this in the hands
of the NetworkManager daemon, expanding its role basically.  the main
advantage is in keeping one GUI location to look to in order to
configure network-related things.  for non-GUI/servers, you'd want a
small CLI shim.

this also closes the loop and removes configuring itself from the list
of dhclient's chores; it may be configured instead by the same
channel either as system default or from user right-clicks.

the variations on this path are in backwards compatibility (compile
time options) and the "environment" the client is intended to run in
(the above is overkill for embedded systems, and so is the script).

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins


More information about the dhcp-users mailing list