Subject: Re: DHCPv6 and multiple servers

From: Tim Hartrick <[email-masked]>
Date: Mon, 27 Dec 1999 12:03:30 -0800 (PST)

Thomas,

> 
> There was another case discussed, where a client has one interface,
> but may want to interact with multiple servers *simultaneously*.  By
> interact, I mean actually get some parameters from one server, other
> parameters from another. Is your position that this second case should
> not be pursued?  (I personally think that not handling this case is
> reasonable, but haven't quite gotten a sense of what the WG thinks
> here.) If this case is to be pursued, however, I believe explicit text
> needs to go into the document explaining when this is desirable, how a 
> client decides it needs to interact with multiple servers, etc.
>

It depends on what you mean by "not handling this case".  If you mean
that we should make it impossible for a sufficiently intelligent client
to handle this case, and put text in the document which says you MUST NOT
implement such a client, I disagree.  If you mean that we don't need
to specify the details of such an interaction now, other than making sure
that the specification does not prohibit the possibility, then I agree.

My only point in bringing this up previously was that it seemed obvious
to me that mobile nodes may well need to be able to "interact" with multiple
DHCPv6 servers in the home network and the remote network.  If we
put something into DHCPv6 that prevents such clients from ever existing
we are making a mistake.  Currently, I don't see any thing that would pre-
vent such a client from existing.  I just want to make sure that nothing
gets added that would prevent such a client from existing.

> 
> > 7) Multiple Interfaces, multiple choices for application layer extensions.
> 
> > Erik raised a concern about how a client would present a coherent view
> > of the data returned from multiple interfaces when such data might
> > conflict. I suggested we use the method the Solaris DHCPv4 client uses
> > to resolve the conflict - the user picks a "primary" interface, and the
> > data associated with that interface is authoritative. I've heard no
> > comment for or against this proposal. Your input is welcomed.
> 
 
It seems that that we could do a similar thing for handling multiple
servers per interface for the mobility case.  One could have the notion of
a home DHCPv6 server and a remote DHCPv6 server and designate which
parameters are authoritative from which server.

This does not need to specified now to the Nth detail now.  We just need to
make sure that it is not prohibited in the base specification by engineering
or politics.

tim

---

From: Thomas Narten <[email-masked]>
Date: Wed, 29 Dec 1999 13:04:13 -0500

Tim,

> that the specification does not prohibit the possibility, then I

I did not intend to imply that there should be MUST NOT language. I
certainly don't believe that.

What I would like to be clear on (and maybe this is already clear to
everyone else) is whether it is requirement that clients are expected
to make use of multiple servers, in the simultaneous sense. Although
the spec doesn't disallow it, it also doesn't suggest that clients do
this. If there is an expectation that clients do need to handle this
case, more text in the document is needed. If clients do not need to
do this today, than the current document is fine in this regard.

> gets added that would prevent such a client from existing.

I totally agree.

> parameters are authoritative from which server.

I'm not sure this is so clear. I can imagine that there are cases
where the DHCP-learned parameter one uses (i.e., DNS server) depends
on whether the node is pretending to be mobile (i.e., using its home
address) or whether it is acting directly attached (i.e., using its
temporary address directly). So this case may need more thought.

> make sure that it is not prohibited in the base specification by engineering

Agreed.

Thomas