DHCPv6-4.1.mumble

[bmanning at vacation.karoshi.com]

On Thu, Jun 12, 2008 at 08:16:52AM -0700, David W. Hankins wrote:
> 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?

	no... that if I have to depend on the IETF, I am pretty much
	S.O.L.

	what I want is for the domain nameservrer option to do what
	is advertized... to pass a list of IP addresses to the client.

	it doesn't in the ISC code.  It selectively presumes to know 
	better than the person writing the config file what valid
	IP addresses for domain name servers are.


> > 	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.

	chapter and verse from the IETF standards please.
	we have clear direction from the DNS side of the house
	that it is perfectly fine to push A and AAAA records out
	over IPv4 and to push A and AAAA records out over IPv6.

	The Dynamic HOST Configuration Protocol deviated along time
	ago from simple passing out of IP addresses to client nodes.
	If your going to pass out -other- configuration data -that is
	not specific to the transport itself- (like DNS nameserver IP
	addresses) then you can not presume that DHCP is the only vehicle
	for doing host configuration.  DHCP is now a complicated 
	beast and this "simplification" for clean separation on the
	transport side is fine.  for other options that are -NOT-
	transport specific, this rigour is counter productive.


> 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.

	cool... one more thing to play with.

> > 	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.

	thanks - when I get it working, I'll let you know.

> 
> 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.

	sounds nifty.

> 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.

	GUI?  there is no GUI here.. :)

> 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