Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

[Robert Elz <[e-mail]>]

    Date:        Mon, 09 Feb 2004 10:48:31 -0800
    From:        Harald Tveit Alvestrand <[e-mail]>
    Message-ID:  <2435506122.1076323711@localhost>

  | Then stop trying to configure SNTP and NIS.

Harald, with all respect, this is plain stupid.

DHCP isn't trying to configure anything.   DHCP is a mechanism via which
network managers can cause systems to obtain information, which they can
then use to configure themselves.

How the systems use that information is entirely up to them - you might
believe that there's one "obvious way" (or obvious use) implied, but that's
no more than something which might be done.

Eg: for my systems at home, my DHCP server, for reasons not worth going into
(well: I can't figure out how to reconfigure it, as all of its config info
and documentation is in Japanese, and I don't read Japanese) sends a
default router value of X - my systems see that X, and when that's what
DHCP says the default router address should be, they set it to Y instead.
Y works as a default router, and X doesn't.   You might think that I could
simply hard configure Y, but that doesn't work at all for mobile systems
(there are a couple of laptops involved here) - when the systems get told
something other than X as the default router, they configure the address
they're told.

If in some particular circumstance the information that DHCP could send
to a node would make no sense, or not be able to be interpreted, by the
node, then the DHCP server should be configured to not send that information.

That doesn't mean that the DHCP protocol should have no means to send that
information, that can be used in the other 99% of cases where sending the
values does make sense - that would mean that the only thing left for DHCP
as we know it to supply would be address, netmask, and (for IPv4) the
broadcast address (maybe MTU I suppose).   Everything else is "host"
configuration (including the router addresses - as the default router
implies a default interface as well as a default address out that interface).

But do note, that in most cases (the odd case of a system with multiple
interfaces connected to multiple admin domains, and using DHCP for all of
them excepted) the fact that different information is received for the
"same" parameter over different interfaces, or via different protocols,
is really immaterial.

Eg: take SNTP as an example.   (I don't actually use DHCPv6 at the minute,
I use autoconfig, but lets pretend I do use DHCPv6 for now - I do use DHCPv4).

If I have a dual stack host with 2 interfaces, then I'm going to be
receiving 4 different DHCP response, one for each protocol on each interface.
On my DHCP (4 & 6) servers, I'm going to arrange to give the address of
an SNTP server that's on the same link as the interface being configured
(so systems can get the time, even if the router is dead).   Obviously
I'm also going to be giving the address of an SNTP server that can be
reached using the same protocol as is being configured, as that's the only
one I know the client will be able to reach.

So, my client is going to end up with IF-1-6addr IF-1-4addr IF-2-6addr
and IF-2-4addr as addresses for its SNTP server.   The client now has to
pick which of those addresses it should use - for SNTP it can probably
just use all 4 of them (multiple servers doesn't net to hurt NTP, in
fact, it is usually good) but let's assume that we're required to pick
just one.

Which one should we pick?   You're certainly correct that the DHCP spec
gives us no guidance at all.   But does it really need to?   What we want
is to get the time after all.   And last time I looked, the time was
the time - and should be the same time, whatever server tells it to me.
That is, if I have 4 plausible addresses, who cares which one I pick, any
one of them is going to give me the time.

On the other hand, I could also decide to get smart.   Knowing something
about SNTP, I know that I can query the servers, determine their
status, who many peers they have, how accurate they believe their clocks
to be, what their natural clock drift looks like, ... and having obtained
all that information (measuring the RTTs to the servers while obtaining it)
I can run some complicated formula and decide which SNTP server is going to
be the best one for me to use.

Which of those is appropriate is entirely up to the end system to decide,
the DHCP server can't decide - it cannot really know how important the
time is to the client in question, in order to know how much effort the
client should take to get a really good idea of the time.   Simply giving
the client the raw data it needs to be able to make its own decision is
as much as can be asked of DHCP, anything more than that would be too much.

I'm not going to attempt to comment on how closely NIS fits into this
kind of analysis (I know that most of the parameters that DHCP can configure,
including default routers, and servers for most services around) fit
fairly closely.   But in my opinion, NIS would be better obliterated from
the universe (DHCP included) than configured at all, so I have never cared
whether it is really going to make any difference which particular NIS
server I happen to pick (I would have hoped that they'd all give the same
answers about a particular NIS domain, but who knows...).   On the other
hand, I also know that my opinion about NIS isn't shared by absolutely
everyone, and that some people may be deluded enough to think they get
some benefit from configuring NIS.   So, I'm not about to object to having
DHCP able to configure it - I just don't have my DHCP servers do that.
My clients never have to worry about getting conflicting NIS information,
as they never get any of it in the first place...

If you have any real examples of cases where it really makes a significant
difference which particular configuration is used, when the config received
is different from different interfaces, and where the client isn't really
the entity best placed to make the decision on which particular config
it should actually use, then please demonstrate the problem - but more than
just "I have to make a decision, and I don't know which one to make" - you
also need to demonstrate that it actually makes a noticeable difference.


Margaret Wasserman <[e-mail]> said:
 | Harald's two "discuss" positions (on the DHCPv6 configuration options for NIS
 | and SNTP) do not mention an API, nor do they concern how an application
 | requests or receives DHCP information within the host.

 | They do question the fact that the DHCPv6 configuration options for NIS and
 | SNTP do not mention IPv4, nor do they explain how a dual-stack node would
 | obtain the IPv4 addresses of NIS or SNTP servers. 

Yes, we know that.   The topic was mentioned, and without dissent, it
was suggested (with some explicit agreement, and no disagreement) that
the solution to this was to explicitly state that DHCPv6 configures only
IPv6 addresses of NIS servers (and others, though the draft in question
is concerned only with NIS as I understand it, it is ...-nisconfig-...
after all).

The particular point of the discuss vote in the IESG will get fixed,
no-one here is objecting to that (some of us see it as a pretty minor
issue, that should have been obvious without explicit mention, but who
cares, a few more words can't hurt much).

Then Harald, in his capacity as a new/occasional member of the WG (I assume,
that's what it sounded like) decide to argue for a different WG response.
That's fine, he's entitled to do that.   The WG is equally entitled to
listen to his point of view, and then tell him that we don't agree, and
that having DHCPv6 configure only v6 is the solution we believe is correct.

>From reading the messages in the past day or two, that seems to me to be
the common view in the responses.

The answer to "or do they explain how a dual-stack node would
obtain the IPv4 addresses of" (anything at all) is that they use
DHCP (SHCPv4) of course.   Does that really need to be explicitly
stated?   The dual stack node isn't going to be a configured
dual stack node at all unless it uses DHCPv4 to get its v4 addresses
for its interfaces, now is it?   DHCPv6 isn't going to be supplying
that information.   DHCPv6 isn't a replacement for DHCPv4, it is a
new protocol that operates alongside DHCPv4, one for v4 information,
the other for v6 information.    If v4 addresses are being manually
configured on a node, because it doesn't want to use DHCPv4, then its
v6 SNTP and v4 NIS addresses can be manually configured at the same time,
it would be laughable to suggest to someone that they should use manual
config to configure v4 addresses, and then go ahead and use DHCPv6 to
get the rest of the v4 configuration information, wouldn't it?

Let's just go back to Ted's original answer when the question was
raised, do (A), agree on that as WG consensus, fix the draft with that
in mind, and send it back to the IESG.

kre


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg