Re: [dhcwg] What sorts of services does DHCP configure?

You do have a point in bringing the user into this.

I suggest to focus on looking at services and servers in three groups:
- location agnostic, DNS is an example.
- location specific, router is an example
- user dependent, IMAP is an example

I think only those that are not user specific should be provided by DHCP.

Next question is of course whether hosts actually request and use these.

On 15/10/13 12:15, Robert Elz wrote:
> Since you're asking a largely philosophical question, you'll get a mostly
> philosophical answer from me - which will start from looking at what
> we can tell of the protocol now - partly from usage (but that doesn't
> help a lot for this purpose, as, as you say, it has all kinds of crud jammed 
> in) but also from the more simple aspect of its name...
>
> The Dynamic Host Configuration Protocol ... a protocol for configuring
> hosts (dynamically, as in not necessarily with static configuration, but
> that part isn't relevant to your question I don't think.)
>
> What is, is "host" - as in "node that is not a router" (though I don't see
> any particular reason DHCP couldn't be used to configure routers as well).
>
> Just based upon this, attempting to redefine DHCP as a network configuration
> protocol, leaving the node configuration for some unspecified something else
> looks like it would be backwards.
>
> Next comment is your concentration on "services" being configured.  I think
> I know why that is - because if you allowed other node specific information
> to get bundled in with the ones that are a problem for you, then this would
> be obvious nonsense - other node specific information that gets configured 
> include its address (and OK, that's also network specific) and the hostname
> (which isn't, or shouldn't be).   Attempt to tell people that DHCP shouldn't
> be configuring hostnames (ever) and I doubt you'd get many supporters.
>
> What DHCP offers is information - it doesn't configure services, it just
> provides raw data that something else can use to configure the service.
> Sometimes that distinction is important.   As an example, DHCP (on unix
> systems) doesn't configure resolv.conf - what it does is get s alist of
> DNS back end resolvers and make that data available.  Something else
> (true, usually run triggered by the DHCP client's actions) takes that
> data and (sometimes) puts it in resolv.conf (on other systems it goes into
> a "forwarder" config in named.boot or something included from that).
>
> That said, the examples you picked were both particularly poor choices - SMTP
> isn't, as for me at least, I prefer that configured just the way you explain
> configuring the DNS resolver, as a local network specific service - I just want
> the nearest MTA that will be willing to take my mail and deliver it.
> The nearer the better, as it increases the chances that I'll be able to
> contact it to hand off the e-mail even in the presence of severe network
> disruptions.   Of course, I know that others treat SMTP as kind of an inverse
> IMAP, where there needs to be an existing relationship (and security config)
> between client and server ...
>
> IMAP on the other hand (or POP if anyone is still using that) is not a good
> example of what you're asking for an entirely different reason .. of course,
> it may be that this causes you to rephrase your question/opinion in a
> different way.
>
> IMAP isn't a node specific service at all, it is a user specific service.
> You only view it as a node specific service if you have the impression of
> a very tight (almost unbreakable) bond between node and user, that is fairly
> common these days.   But consider the case of a shared office notebook,
> that anyone picks up (one from the pile) and takes away to use for a few
> days, returning it when they're done?   Should the IMAP configuration be
> node specific, or user specific?
>
> Since when DHCP normally runs (at least initially) the identity of the
> user won't always be known, DHCP at first glance doesn't look to be a good
> fit for configuring services that are user specific, and need the user's
> credentials to be able to determine the proper response - as distinct from
> true node configuration (independent of the user).
>
> But, I know that you're not proposing that all of this stuff go unconfigured,
> or that we revert to the bad old days, of users attempting to follow the
> configuration manual in conjunction with some configuration information
> provideed (via a phone call, on a web page, in e-mail, or even printed)
> from whatever network info center the user is supposed to get that particular
> information from.  That means that we need some kind of a config protocol.
> What's more it needs to be a protocol that works starting with a 100%
> unconfigured node - and some information for that node (and/or the node's
> user) somewhere in the network.
>
> What is the protocol that allows the node to discover where that information
> is to be found going to look like, and is it (really) going to be anything
> significantly different from DHCP ?
>
> For (some) shared info, we can adopt the IPv6 model (in fact, we should
> probably only really be considering IPv6 - doing much more work on IPv4
> is really just painful palliative care for an obviously doomed protocol)
> and broadcast (that is, of course, multicast) the config.  That works quite
> well when the same info is appropriate for all nodes that will receive the
> broadcast (like the DNS resolver and router locations).   What that leaves
> for DHCP, or some DHCP like protocol, is the information that is meant to be
> unique for each node (hostnames, even IMAP servers ...)
>
> Consider a node that has obtained the user identity information from its
> user (which may be simply known at boot time for a node that is tightly
> bound to a specific user, or later, after the user has been identified and
> authenticated in other cases) then sending those credentials to the DHCP
> server in a DHCP request option, and for the DHCP server to then reply with
> node and user specific information - which it may have obtained by
> consulting with a radius (or other AAA) server and hence supply this
> particular user's correct IMAP (and other similar) configuration?
>
> Whether that's the right solution or not I don't know, but I do believe that
> whatever solution is eventually adopted, it needs to start with making
> node & user specific information available to a 100% unconfigured node,
> without any user assistance (some nodes may not even have a mechanism for
> to user to assist, even if they were able) and I'm having trouble seeing
> how any solution is going to be so dramatically different from DHCP that
> simply using DHCP as (at least a part of) the resulting protocol wouldn't
> be a sane result.
>
> Consequently, I don't think it is a good idea now to start on the divorce
> proceedings between these kinds of config info and DHCP, simply writing it
> off as a problem for someone else to solve - and while the way that DHCP
> is currently defined (and more importantly in many cases perhaps, configured)
> to provide this info may be sub-optimal, we may want to see if we can
> find an amicable reconciliation.
>
> kre
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 