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

[Harald Tveit Alvestrand <[e-mail]>]

Ted,

thinking about this some more....  I know that you have worked on this far 
longer than I have, and that the role I'm playing here of saying "the 
current solution is not reasonable" is not a very pleasant one.....

I think you have to do some basic decision-making first - first off, is 
this the Dynamic HOST Configuration Protocol or the Dynamic INTERFACE 
Configuration Protocol?
For a lot of parameters (such as address and netmask), it seems to be 
interface (or stack). But for many (such as NIS server and SNTP server), it 
is definitely host. And those are the ones for which we have the problem.

If I think of the problem of host configuration from the viewpoint of a 
network admin, what I want is to get a set of parameters from my 
configuration files into the running config of a host, without having to 
ask the user to do anything but connect. Having the possibility multiple 
overlapping and interacting configurations doesn't help my job, it 
complicates it.

So - viewing this as a HOST configuration problem, I think the problem 
reduces to getting multiple sets of configurations, via multiple 
interfaces/protocols, deciding on one and only one set to use for HOST 
configuration, and ignoring the rest.
This means that ONE set has to be able to contain ALL the parameters a 
sysadmin wants to set that has HOST scope.

Back to the v4/v6 case:
DHCPv4 is useful for IPv4-only hosts, of which we will still have a lot for 
a few (?) years.
For dual-stack hosts, of which we will hopefully have many soon, a single 
configuration mechanism that is able to set HOST parameters for both IPv4 
and IPv6-related data is required.
For IPv6-only hosts, of which we will hopefully have more than a few in the 
future, it should be easy to use the same mechanism by not setting the 
IPv4-related values.

So - what I'd think was a sensible thing to do:

- Mark each and every DHCPv6 configuration parameter with "Interface 
specific" or "Host specific".
- For "Host specific", make it easy for a host to figure out which set of 
parameters it uses, and let it stick to that set only. No mixing!
- Make sure that all "Host specific" parameters are able to specify values 
that make sense for both IPv4 and IPv6
- In all the instances I've seen so far, declare that if you need an IPv4 
address, put it in as an IPv4-mapped IPv6 address (::12.34.56.78) - no 
other changes needed.

and most difficult:

- declare WG consensus for all this while KRE still disagrees :-)

(I recognize that KRE has a logically coherent argument. I just happen to 
think that he's wrong. That's life!)

I may now have repeated a proposal that was suggested and rejected 3.5 
years ago - that's life too. But you asked......

                        Harald



--On 5. februar 2004 18:22 -0600 Ted Lemon <[e-mail]> wrote:

> You are totally right.   This sucks.   The problem is that the
> alternative is even worse.   This isn't even strictly an IPv4/IPv6 issue
> - consider what happens when you have two network interfaces that are
> configured by two different servers in two different administrative
> domains!
>
> Unfortunately, we haven't been able to think of a way to specify how DHCP
> devices should deal with this problem.  It's easy to specify a scenario,
> and then say what should be done in that scenario, but it's hard to
> specify a set of rules that will work in all scenarios.
>
> Anyway, you have to support both protocols, because you might be on an
> IPv4-only or IPv6-only network, so even if we specified a way to
> configure your IPv4 stack with DHCPv6, you'd still have to implement a
> DHCPv4 client.   :'(
>
> It's possible that when we have some real-world experience with this, we
> might have enough information to make a stab at specifying a general
> solution to this problem, but I don't think we do right now, and if we
> tried, we'd wind up in ten-years-later land.
>
> If you have an idea for a general solution, we'd all like to hear it, by
> the way.   But please remember that we're not complete dummies, and try
> to think about six chess moves ahead rather than just stating an obvious,
> but wrong, idea, because we've probably already considered and discarded
> that idea.
>