Subject: DC meeting: Discussion question #1, releaseable resources

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Tue, 16 Nov 1999 13:50:16 -0500 (EST)

Hi Folks,

	There were a number of discussion questions we covered in
DC. I'm going to send out each question with background for context in
separate email messages. Please feel free to jump in if the topic
interests you.

Here's the first question:

1) Seeking examples of releasable resources. An IP address is one. Others?
When would they be released?

EXPLANATION: What I was seeking here was an understanding of whether
we'd ever have resources other than IP addresses that would be
releasable. If the answer is NO, then Release becomes much easier. If
the answer is YES, then we have to do more work to identify those
resources which are releasable, but are opaque to the client (and
server) implementations.

In DC, we were really reaching for examples of releasable resources over
and above IP addresses.

My opinion: SLP is better at dealing with registering services, etc. We
have always thought that SLP would do more of the heavy lifting than it
did in the DHCPv4 environment. However, SLP still isn't deployed widely.
So, SLP should be used for releasable resources over and above what is
necessary for a host to achieve the ability to talk on the global
internet. Perhaps DHCPv6 can help SLP deployment by remaining true to
minimal stack-only configuration.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Thomas Narten <[email-masked]>
Date: Tue, 16 Nov 1999 18:05:44 -0500 (EST)

> resources which are releasable, but are opaque to the client (and

Right. There are semantics associated with the current definition of
Release that make it more complex for releasable resources. For
example, a client is only allowed to release releasable resources via
the same server that originally allocated them. That means a client
has to keep track of that and can't just release stuff if it switches
DHCP server. It also means that (say) if it gets a Reconfigure from
another server, it can't release that resource to it. I don't fully
understand why things are defined this way, but they are.

> minimal stack-only configuration.

I'm not sure I follow the comparison with SLP. SLP is for locating
servers and services. How you actually access a service is a secondary
issue and not SLP specific. Releasable resources are a specific type
of resource that the current DHCP spec allows a server to hand out to
clients. I.e., it is a way of allowing DHCP servers to assign specific
resources to a client.

My basic question on releasable resources has to do with cost
(complexity) vs. benefits (what will they really be used for).

Thomas

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Tue, 16 Nov 1999 20:04:13 -0500 (EST)

> understand why things are defined this way, but they are.

Any releaseable resource would need to have some lifetime or lease associated
with it in order to automatically reclaim it. That lifetime (and the fact that
a particular extension carried releaseable data) would need to be communicated 
to the client in a non-extension-specific manner (So that clients would not
have to change if new extensions are added which contain releaseable data).
Folks at Minneapolis requested such a mechanism. If we decide that supporting
releaseable/leasable resources is important, we'd need to add supporting text.

But before we drive down into solving the semantics of releaseable resources,
we still have to ask whether the complexity of managing releaseable/leased
resources is worth it given we don't have examples of such resources (other
than IP addresses).

> clients. I.e., it is a way of allowing DHCP servers to assign specific

There was no comparison intended between DHCPv6 and SLP. If we were to decide
that releaseable/leaseable resources other than IP addresses weren't something
we'd deal with in DHCPv6, then we'd need some other method of managing them,
and SLP seems to fit.

> (complexity) vs. benefits (what will they really be used for).

And in order to answer this question we need to determine whether there
are examples of resources we think DHCPv6 should manage which are
releaseable/leaseable.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Tue, 16 Nov 1999 22:07:47 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
-----------------------------------------------------------------------
> resources is worth it given we don't have examples of such resources (other

	No, I believe we have to know what semantics need to be supported
in order to properly evaluate how complex the management solution needs to
be.  Of course the lack of examples of releasable resources makes it even
more difficult for us to try to infer appropriate semantics.

			Carl

---

From: Jim Bound <[email-masked]>
Date: Tue, 16 Nov 1999 22:46:06 -0500 (EST)

>understand why things are defined this way, but they are.

I tend to think the only real releasable resources are the Addresses.
I am beginning to think that a releaseable resource is one which the
server can use elsewhere?  The only ones I can come up with are
addresses?  

But I want to make sure we get to all the issues in this discussion too.

When you say semantics can you be specific?  Is it the resource-server
associations statements?  The "D" bit?  etc...  Just so we don't miss
anything in the syntax either that may imply semantics?

Or is it just a matter of saying that clients only release addresses?
And its that simple?

As far as the multiple server issue that I think is a separate issue?

To release an address for a client (assuming for this discusssion thats
all we are talking about) to a server, when the server gets the release
it will have to do a search on that client and locate the entry for that
client on some non-volatile storage medium I will assume (sure it could
be a cache in a good fail-over server) then do the delete and reuse or
wait for XX time before reusing.

Today we have no mechanism for servers to know about each others
databases and entries.  So we assume that servers can't do this and say
a client can keep the address of a server who gave them their address,
because we know new servers can't "today" know about each others
databases in a "standard" way.  

But..tomorrow it may be there is a standard way for servers to know
about each other and clients can clearly just send the release to any
server if that exists in Theory....if the standard exists.  

Here is a suggestion for discussion:

1.  Lets make the default that the client has no knowledge of servers
    and can release addresses to the next server it hears (e.g. 
    reconfigure, reply, advertise [from reboot]).

2.  But put a MAY in the protocol that permits clients to keep
    the address of servers to later release addresses from where
    it got them.

#2 will permit mobile nodes to release adddresses that roam around
before we get a server-to-server protocol deployed in the market.

thanks
/jim

---

From: Ralph Droms <[email-masked]>
Date: Tue, 16 Nov 1999 23:26:32 -0500 (EST)

>message sent to [email-masked] by [email-masked] follows.

I might ask a slightly different series of questions:

1. Should we take on the exercise of defining the semantics of releasable
resources, given that we don't have examples of such resources?

2. If the answer to (1) is yes, then - after defining the semantics of
releasable resources - is there reason to develop a mechanism for managing
releasable resources DHCPv6?

3. If the answer to (2) is yes, then is the cost of defining and
implementing a mechanism for managing releasable resources (and that cost
may be 0) worth the benefit of being able to manage those resources through
DHCPv6?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Wed, 17 Nov 1999 06:24:44 -0500 (EST)

So, let me answer (1) with "yes", and take a stab at defining "releasable
resources".

Here's a working definition for a "releasble resource": a resource that is
uniquely assigned to a client and that can be reassigned to a different
client at some point in the future.

Discussion: If I remember correctly, the idea of "releasable resources"
first surfaced in the Minneapolis WG meeting.  We generalized the idea from
IP addresses, in a discussion about where a client should send a RELEASE
message.  I don't remember that we had any specific examples of releasable
resources othee than IP addresses.  Our experience with DHCPv4 is that IPv4
addresses are "releasable resources" while everything else managed through
DHCPv4 is a "configuration parameter".

Based on the working definition, here are some preliminary observations
about managing releasable resources:

Servers will:
  - Implement assignment policy determined by DHCP admin
  - Assign resources as part of the configuration requested by clients
  - Track assignment of resources to clients
  - Reassume responsibility for resources released by clients
  - Recover resources (presumably through leasing mechanism)

Clients will:
  - Request configuration from servers
  - Keep track of resources and leases on those resources
  - Release resources

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 17 Nov 1999 08:42:00 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
---------------------------------------------------------------------------

> anything in the syntax either that may imply semantics?

The current draft has pretty specific text about how a client releases
resources:

>    a DHCP Request message with the `C' bit set and no extensions.  If a
>    client wishes to retain some of its network configuration parameters,
>    but determines that others are no longer needed, it SHOULD enable
>    the server to release allocated resources which are no longer in
>    use by sending a DHCP Release message to the server, and including
>    extensions to identify the unneeded items.  The client consults its
>    list of resource-server associations in order to determine which
>    server should receive the desired Release message.  The Release
>    MUST be transmitted to the server that provided the configuration
>    parameters.

Note that I'm assuming that the only resources a client would release
are "releasable resources", i.e., addresses that have explicit
leases. There is no need to release other types of parameters. Right?

So, I guess my previous mail wasn't quite clear. Requiring that
clients rememember which server they got a resource from and then
specifying that it can only release resources by contacting the same
server again (in the MUST sense) seems a bit restrictive. If we
imagine a server-server protocol becoming available, being able to
release a resource to any of the available servers seems desirable. It
might still make sense (as an optimization) to have clients first
attempt to release a resource via the same server it got it from, but
if that fails, wouldn't it make sense to allow it to try releasing
resources via another server? Or more generally, perhaps it makes
sense to say a client always prefers a particular server, the one it
most recently got parameters/resources from. That way, a new server
could (say) send a reconfigure that causes the client to switch to the

new server and then use that new server for subsequent communication,
regardless of where it got resources from previously.

> Or is it just a matter of saying that clients only release addresses?

I think this is in essence the question about whether we should
generalize addresses into releasable resources. Certainly, we'll want
to be able to release addresses. 

> wait for XX time before reusing.

Agreed.

>     the address of servers to later release addresses from where

This seems reasonable to me. I might even go a bit further and say
that a client SHOULD (?) keep track of one server, the one it most
recently got resources/parameters from and use that one first when
releasing resources. If that fails, fall back to finding and trying a
different server. I think this retains the spirit of what is on the
current draft but also provides more flexibility in the event that a
server-server protocol comes along.

Thomas

---

From: Charles Perkins <[email-masked]>
Date: Wed, 17 Nov 1999 14:11:37 -0500 (EST)

>   - Keep track of resources and leases on those resources

I think this is very well stated, and matches my understanding
about what is needed.

It seems to me that one of the sticking points in this discussion
is some difficulty in imagining other releasable resources besides
IP addresses.  I'd like to address that issue in two ways:

1. I can imagine a _lot_ of releasable resources in the future, but
   it would be a mistake to try to specify them before we can have
   DHCPv6 as a Proposed Standard.  After that time, new extensions
   to specify new releasable resources will come up for discussion
   in a natural way, as long as we have a natural mechanism specified
   for handling them.  Some possible examples of releasable resources:
   = disk space
   = network memory
   = I/O devices
   = Licensed software
   = time-metered equipment
   = ports
   = protocol translators

2. However, in a way, imagining cool resources as in (1) even misses
   the point.  I think the point is that DHCP is a way to configure
   computers, and it seems clear to me that computers (especially
   computers on networks) can be considered to be composed of allocated
   resources structured according to parametric values.  DHCPv6 makes
   a nice way to collect such parameters and resources, after some
   years of work.  I vote for keeping it that way.

There is another point regarding the distinction between DHCP and SLP.
SLP is good for applications that need access to services that can be
described by attribute/value pairs.  DHCP is good for configuration
needs that do not need such precise, attribute-driven specification.
The dividing line is perhaps fuzzy between these two areas of need,
but it is not invisible.

>From discussion by Thomas Narten and Jim Bound on this subject:

> > == Jim Bound

>   == Thomas Narten

> >     reconfigure, reply, advertise [from reboot]).

I think it would be better for clients, by default, to release resources
to the server that allocated them.  We've already got this mechanism
specified in the draft now.

> server-server protocol comes along.

To me it seems natural to let clients release things to the server
that allocated them by default, and if that isn't possible then the
client MAY release them to the next server it knows about.

When a server-server protocol is designed, this can be evaluated again,
but in the meantime it would be better to make things work in the
logical way without such server coordination.

> > before we get a server-to-server protocol deployed in the market.

I don't see how this follows at all, especially if the two servers
involved are in different domains.  We haven't even started to figure
out that problem yet.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Nov 1999 15:31:10 -0500 (EST)

> specified in the draft now.

Note: the current draft (my recollection of it anyway) says that
releasable resources can ONLY be released via the original server.
Are you saying this is not the case, or are you suggesting that
relaxing this would be OK?

Also, I'd prefer SHOULD to MAY because if it's a MAY some
implementations won't do it. Either we think all clients should try a
fallback server or we don't. I don't see the value in a MAY
here. Making it a MAY will result in non-uniform behavior, which will
likely cause problems for the sys admins using DHCP (i.e., not have a
uniform predicatable behavior across client implementations).

Thomas

---

From: Charles Perkins <[email-masked]>
Date: Wed, 17 Nov 1999 16:35:19 -0500 (EST)

> relaxing this would be OK?

How about if we say that the client should try to release to the
original server, and if that fails try something else?

> uniform predicatable behavior across client implementations).

I agree with this.

Regards,
Charlie P.

---

From: Jim Bound <[email-masked]>
Date: Wed, 17 Nov 1999 17:56:00 -0500 (EST)

>    MUST be transmitted to the server that provided the configuration

This is with a request.  I was speaking of the Release secton.  But this
is valid we would have to synch up the C bit with Release if we change.

>leases. There is no need to release other types of parameters. Right?

I agree.  None that I know of now.

Agreed.

Agreed.

Agreed.

/jim

---

From: Tim Hartrick <[email-masked]>
Date: Wed, 17 Nov 1999 20:14:41 -0500 (EST)

All,

> specified in the draft now.

If we are going to have releaseable resources and we aren't going to
specify a server-to-server protocol to coordinate resource allocation then
I don't see how the default behavior can be anything but to release the
resources to the server which allocated them.  The alternative of releasing
a resource to any old server could result in servers believing resources
are in use when they are not and resources being released to servers which
aren't managing the resource being released.  This is bad.

This appears at first blush to require more complexity in the client since
the client will need to maintain a fair amount of state in order to make
sure that resources are released to the servers which allocated them.  This
in contrast to a "black-box" of configuration which is passed out to the client
once and only released by server request or lease expiration.

Since we expect many more clients to be multi-homed in the future I believe
that we can also expect that more clients will be interacting with more than
one DHCPv6 server and these multiple DHCPv6 servers could be completely un-
related to each other.  That is, the servers could be managing address space or
other resources from two different providers without any knowledge of the other servers' presence.

If we believe that this is going to be a common configuration then it might
be best to just bite the bullet and deal with the complexity that will allow
clients to handle getting resources from multiple, possibly unrelated, servers.

Does this seem like a reasonable way to view the environment in which DHCPv6
is going to be deployed?  I am not sure, but it seems completely plausible
if we consider mobile IPv6 clients roaming about within various unrelated
adminstrative domains.

> logical way without such server coordination.

As noted above, I think Charlie is right.  It is hard to see what good could
come from releasing resources to a server that didn't allocate them in the
first place.  I can imagine circumstances in which it would work but they
all require thinking about server-to-server protocols which is a rat-hole
that we desperately want to avoid I think.
 
> involved are in different domains.  We haven't even started to figure

Once again I think Charlie has it right.  There are two cases.  The case
where there are multiple servers within one administrative domain handing
out a shared block of resources and the case where there are multiple servers
from possibly seperate administrative domains handing out items from completely
seperate blocks of resources.  The former will probably require a server-to-
server protocol to coordinate things.  The latter doesn't need a server-to-
server protocol since the resources being managed are disjoint.  A mobile node
is likely to find itself dealing with both of these circumstances.  I think we
need to make them both work, or at least make it possible for them to work in
the future, without running down the server-to-server protocol design rat-hole.

Mind you that I haven't completely bought off going with something that is
not the "black-box" approach that has been suggested.  However, if we go down
the path that allows clients to have more freedom then we need to develop
something that works properly in absence of a server-to-server protocol.
The only way I see that happening is if releasible resources are released
to the server from which they were allocated.

In the future we can develop a server-to-server protocol which will allow
clients to release these resources to a number of different servers.  How
the client learns about these other confederate servers is TBD.

Tim Hartrick
Mentat Inc.

---

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Thu, 18 Nov 1999 11:12:55 -0500 (EST)

(From Thomas Narten)
--------------------
Tim,

> aren't managing the resource being released.  This is bad.

Let me clarify. I agree that releasing resources via the server one
got the resources from makes sense.  Having that be the default seems
fine.  However, the current draft goes further and essentially says:
you can't release via another server, period. The middle ground that
has been suggested is to first try releasing via the server one got
the resource from in the first place.  If that fails, however, then
fall back by trying other servers. Having a fall back might make
things work in the case that another server was available. This could
happen via the server-server protocol, but could also happen if a DHCP
server was retired and replaced by another with configuation
information migrated from one server to the other manually.  Thus,
there is no requirement that a server-server protocol be in place, but
we'd be leaving in hooks to make things work better in such an
environment.

I also agree that we shouldn't assume a server-server protocol is
present (since it doesn't quite exist yet), but we should also keep in
mind that changing clients later when/if we do have a server-server
protocol will be very difficult (i.e., we may not have the opporunity
of DHCPv6 clients are already deployed). Thus, anything we can do now
that helps the server-server case should be considered.

> Since we expect many more clients to be multi-homed in the future I
> believe that we can also expect that more clients will be
> interacting with more than one DHCPv6 server and these multiple
> DHCPv6 servers could be completely un- related to each other.  That
> is, the servers could be managing address space or other resources
> from two different providers without any knowledge of the other
> servers' presence.

I don't see right off why multi-homed sites implies multiple DHCP
servers.  Could you further elaborate please?

> If we believe that this is going to be a common configuration then
> it might be best to just bite the bullet and deal with the
> complexity that will allow clients to handle getting resources from
> multiple, possibly unrelated, servers.

If you think that the normal situation would be for a client to need
to talk to multiple DHCP servers to get its configuration, the current
protocol may well be inadequate for that. It has the clear notion that
you locate one DHCP server and then get all your configuration
information from it. There is no notion in the protocol that one

should be conversing with multiple servers simultaneously.  Do you
think this is a requirement?

> Does this seem like a reasonable way to view the environment in
> which DHCPv6 is going to be deployed?  I am not sure, but it seems
> completely plausible if we consider mobile IPv6 clients roaming
> about within various unrelated adminstrative domains.

Roaming about as in the Mobile IP (the protocol) sense? That might be
a somewhat different case. I.e., I can imagine that nodes supporting
Mobile IP might have special requirements to handle the case where
they need to talk to multiple DHCP servers (the one at the site they
are visiting, plus the one back home).  But we need to distinguish
between what is a general requirement for all nodes vs. those that
will be mobile. In addition, does the mobile case require any changes
to the current DHCP protocol? If so, we need to understand those
requirements.

Thomas

---

From: Charles Perkins <[email-masked]>
Date: Thu, 18 Nov 1999 12:24:48 -0500 (EST)

Hello Thomas,

> servers.  Could you further elaborate please?

I don't think that multi-homing _requires_ multiple DHCP servers,
but it certainly suggests the possibility of it.  This would be
particularly true if the multi-homing were for unrelated ISPs.

> protocol may well be inadequate for that.

I hope not!  See below...

>                                          It has the clear notion that
> information from it.

With the exception of the (now likely to be changed) overspecified
behavior for DHCP Release, I don't remember any place where the existing
protocol is inadequate for dealing with multiple DHCP servers.  Thus,
I disagree with your statement.  I hope that you will help identify any
places within the protocol specification that might make such misleading
suggestions, so that we can repair the wording as soon as possible.

>                       There is no notion in the protocol that one

Jim and I have, all along, tried to make sure that the DHCP protocol
does exactly provide for the possibility that a client will have
(perhaps simultaneous) transactions with multiple DHCP servers.
This is enabled by the transaction ID, the minimal linkage between
advertisement and request, the separation of control flow from
data items in the extensions, the modular isolation of state
information from the various control flows, and the avoidance of
requiring state information in the relays.

I think it should be a requirement that the protocol support access
to multiple DHCP servers simultaneously.  The client gets to decide
which servers to query, and the servers get to implement enough policy
information to help them serve the clients according to rational
administration.

> are visiting, plus the one back home).

Please send any thoughts about support requirements for mobile nodes
to the mailing list.  Since the Internet will largely be composed of
mobile nodes by the time IPv6 is dominant, we'd better make sure they
get the support they need from DHCPv6.

>                                     But we need to distinguish
> will be mobile.

I am curious about what kind of distinction you would like to see
put into place.  I'd rather that distinctions not be made, except
in cases which are purely related to requirements from Mobile IP(v6).

>                 In addition, does the mobile case require any changes

I'd like to suggest rethinking the retransmission timeout and
exponential
backoff policy in light of the needs of mobile hosts.  But I won't
suggest
it, for the obvious reasons.

Regards,
Charlie P.

---

From: Tim Hartrick <[email-masked]>
Date: Thu, 18 Nov 1999 15:12:54 -0500 (EST)

Thomas,

> servers.  Could you further elaborate please?

As an example, lets assume that I have a "standard" cable modem in my
house.  This modem and my cable company allow me to choose from any number
of providers or multiple providers.  If I did indeed have multiple
providers then I could be interacting with two different DHCPv6 servers
managed by those two providers.  They don't know anything about each
other and it makes no sense for me to attempt to release an address
that was allocated by provider A to the server administered by provider
B.  This is a unlikely to be common but given appropriate competition in
the market it won't be impossible.

There is also the mobility case.  I have a mobile node which has been
assigned an address from its home network via DHCPv6.  I now pick up this
mobile node and take it to some other administrative domain.  I need an
address from the new network and that address could well be assigned by
a local DHCPv6 server.  Once again I have scenario where the client needs
to interact will multiple DHCPv6 servers but those servers are completely
unrelated.  Attempting to release an address from my home network to
the DHCPv6 server of the local network is not what you want.

I agree that we probably don't want to say that the client MUST release
the resources to the original server.  That precludes the possibility of
designing server-to-server and server redundancy protocols.  All I am
saying is that in order to get things to work correctly in the more common
case we need to say that the client SHOULD release resources to the
original server and if that fails then they MAY release them to some other
known server with the understanding that absent some adminstrative co-
ordination, the description of which is out of scope for the draft, the
release may not work.  That's it.  Nothing more complicated than that.

> think this is a requirement?

I am not sure exactly.  It seems as though it has the potential to be
more common in the IPv6 world.  Is it an absolute requirement that we make
that sort of interaction bullet proof before we go to proposed standard.
I doubt it.
 
> to the current DHCP protocol? If so, we need to understand those

Yes, in the mobile IPv6 sense.  I agree that mobility may well be a
special case that can be handled with mobility specific extensions to
ND, DHCPv6 or mobile IPv6.  However, if we are going down the path of
a relatively complex protocol for managing releasible resources then I
think we should try and do it in a general way.

Tim Hartrick
Mentat Inc.

---

From: Jim Bound <[email-masked]>
Date: Thu, 18 Nov 1999 19:50:59 -0500 (EST)

Charlie,

>involved are in different domains.  We haven't even started to figure

I "think" you misread what I am saying above.  Number #2 is that the
node would take the server that gave the node the resource and be able
to release them.

> >     the address of servers to later release addresses from where

It states that clients may be able to keep the addresses of servers to
release parameters.  Mobile nodes will need this until we do have
server-to-server protocol.

I think we are in violent agreement?  Except about the default behavior
and usage of RFC 2119.

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 1999 02:18:39 -0500 (EST)

Tim Hartrick wrote:

> related to each other.  That is, the servers could be managing address space
> or other resources from two different providers without any knowledge of the
> other servers' presence.

Dealing with multi-homed machines, or to be more specific, multi-interfaced
or multi-linked machines doesn't need anything more than stating that
DHCPv6 operates on a per-interface basis plus some way to resolve
differences for single-valued parameters.
For instance, if the client receives time zone extensions from multiple
servers on different interfaces it must pick one time zone value somehow.
But if the client receives multiple NTP server extensions, it can
either internally have a list of all NTP servers on all interfaces,
or it can have NTP software that runs independently on each interface
(the latter doesn't make much sense for NTP, but it might make sense
for other extensions which contain lists of things).

Is there something more you believe DHCPv6 needs to do to handle
multi-interfaced clients?

To me this seems like a different beast than tracking releaseable 
resources per server on a single interface, especially if only IP
addresses are releaseable since IP addresses are inherently associated
with interfaces.

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 19 Nov 1999 07:27:17 -0500 (EST)

> particularly true if the multi-homing were for unrelated ISPs.

"Possible" doesn't imply likely or desirable. What would be the
benefit of such a configuration? At the least, it would seem to
complicate client implementations (see below).

> suggestions, so that we can repair the wording as soon as possible.

Note: I am assuming that for the purposes of this dicussion, multiple
DHCP servers means one server has one prefix, another server has a
different prefix. I.e., the two servers do not have the same
information about what prefixes (or resources/parameters in general)
to give out and a client must contact both of them to get all of the
addresses/parameters it needs. That is what I understood Tim to be
getting at.

Where in the current spec does it call out for a client to ask for
addresses/parameters from more than one dhcp server?  My read of the
spec is that it says you pick one server and get all your resources
from it.

In a theroretical sense, the protocol doesn't disallow getting
resources from multiple servers in the above case. But because there
is no text calling for clients to actually do this (and the current
text certainly implies that one get all resources from one server), I
believe it is fair to say that DHCP as currently written does not
support getting resources from multiple servers in the case Tim
mentions.

> (perhaps simultaneous) transactions with multiple DHCP servers.

Unless the draft clearly spells out when and under what conditions
simultaneous transactions with multiple servers are to take place,
clients won't implement the feature. 

> information to help them serve the clients according to rational

Please point out specific text in the current draft that makes it
clear under what conditions clients are to expected to be interacting
with multiple servers simultaneously. I don't recall there being much
in the way of specific requirements here.

> in cases which are purely related to requirements from Mobile

I suspect (but am not entirely sure) that nodes implementing mobile IP
may have special requirements with regard to DHCP (e.g., a need to
interact with servers at both the local and home site
simultaneously). In such cases, it would probably make sense to have
mobile nodes (as part of the mobile IP spec) specify those
requirements as part of what implementing mobile IP means. It is not
clear to me that all clients would need to implement this. In any
case, we need to talk specifics here in order to decide whether
somethign is a general requirement or one appropriate for mobile
nodes.

> exponential backoff policy in light of the needs of mobile hosts.
> But I won't suggest it, for the obvious reasons.

The IESG message is clear here. Protocols must be congestion
friendly. The base case against which comparisons are made is TCP
(which has expential backoff, slow start, etc.)  If a protocol wants
to deviate from this, the burden is on the protocol to make the case
for why it's congestion strategy is different and why its deviation
from the norm does is acceptable for the environment into which it
will be deployed.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 19 Nov 1999 07:29:35 -0500 (EST)

Tim,

> managed by those two providers.

My expectation would be that in this case the connectivity provider
would arrange to have your DHCP packets delivered to the DHCP server
of your ISP and NOT to the other DHCP servers. Or, the various DHCP
servers would get the client requests, but only the client's selected
ISP would respond. In both cases, the client would appear to be
interacting with only 1 DHCP server, not multiple ones, and I think
think this should work fine today.

> They don't know anything about each other and it makes no sense for
> me to attempt to release an address that was allocated by provider A
> to the server administered by provider B. This is a unlikely to be
> common but given appropriate competition in the market it won't be
> impossible.

Agreed. But the server can simply return a "no binding" error if a
client attempts to release a resource and the server has no record of
that binding. And in the case where the connectivity provider arranges
to have all DHCP packets delivered only to the client's ISP, this
would not be an issue.

As a data point, I have an ADSL connection to a telco (GTE). GTE also
provides ISP services. However, my ISP is not GTE, it is someone
else. I use DHCP to get addresses and configuration info. It just
works without any special configuration on my part. GTE arranges to
tunnel all of my non-local traffic via bridging to my ISP.

> the DHCPv6 server of the local network is not what you want.

I view this is a special case that applies to mobile IP nodes, and not
to (stationary) clients in general. This case is also different than
the one described above because I believe the node will be aware in
this case that it is operating in two realms (the local one and the
home one) and needs to do special things in some contexts because of
that (e.g., it knows to distinguish interactions with its home site
from those at the local site).

> release may not work.  That's it.  Nothing more complicated than

I think we are in general agreement here.

Thomas

---

From: Charles Perkins <[email-masked]>
Date: Fri, 19 Nov 1999 10:55:03 -0500 (EST)

> complicate client implementations (see below).

DHCP(v6) is at the service of network computers and applications.
DHCP is not the application.  It is constructed to offer benefits
to applications.  If an application needs to get configuration
information from each of two DHCP servers at different ISPs, then
it is the job of DHCP to make that happen.  The benefit of having
DHCP work to serve that possibility is to simplify application
programming.  Insofar as applications care about multi-homing and
multiple ISPs, I think it is quite clear that they will need such
features from DHCP.  If you want to argue that applications should
not ever care about multi-homing and ISPs, then I can't add anything
more to that discussion except my intuition that it would be a
terrible mistake to remove the relevant features from DHCP.

> spec is that it says you pick one server and get all your resources

Then you are reading something into the spec that isn't anywhere in
there.  The job of a specification is to make protocol operations
possible,
not to tell clients when to use the protocol.  The specification also
does not say what kind of routers to use, nor how many bits per second
of bandwidth is required, nor whether mobile computers can use the
messages, nor whether a collision-detection scheme is needed at
layer-2, nor whether the server must store its data using LDAP, nor
any of a thousand other details.  All of these thousand other details
are ABSOLUTELY CRUCIAL for lots of implementations, and yet the
specification does not discuss them.

I claim this is a very good feature.

I claim this very good feature opens up quite a broad system
design space for application developers and network administrators.

The specification does not have to tell clients when to use the
protocol.

> resources from multiple servers in the above case.

Your use of the word theoretical here would indicate that you do
not believe that practice follows theory.  On the other hand,
I believe that it is crucial to have a realistic theory with
clear rules for implementation in any protocol specification.
Let's make the rules clear and give as much latitude as possible
for implementations , and, subsequently, applications using the
implementations.

It is a mistake to follow the road of prescribing every possible
application interaction with a protocol.  Not to mention time-consuming,
tedious, and self-limiting.  Such an authoritarian view of protocol
design is almost always self-defeating, I think.

>                                                    But because there

By now, I hope my reasons for disagreeing totally with this paragraph
are very clear.  It is not fair to say that our specification does
not support Cisco routers just because we don't say how to use them.
It is not fair to say that our spec does not support mobile computers
just because we don't say how to use them.  I think your contention here
is, I wish I could say it more tactfully but I don't know how, totally
wrong.

> clients won't implement the feature.

Again, I think this statement is totally wrong.

As another example, our specification does not say how to a server
should operate Mobile IP at the same time it operates DHCP.

Perhaps this is a danger of thinking in state machines.  If that is
the sticking point, then I want to be sure that our protocol is able
to be understood without reference to state machines, even if a state
machine is helpful for the purposes of implementation.

> in the way of specific requirements here.

The protocol is specifically designed to support interactions with
multiple servers.  We could insert that statement.  Where do you
think it belongs?

> somethign is a general requirement or one appropriate for mobile

Well, I'm ready to talk specifics as soon as anything becomes known.

We implemented Mobile IP with DHCPv4 more than once.  The problem we
had was with the state machine implementation of DHCPv4, and the
drastic inconvenience or impossibility of starting multiple state
machines.
That problem has been avoided in DHCPv6, to the best of my current
understanding.

Cbarlie P.

---

From: Charles Perkins <[email-masked]>
Date: Fri, 19 Nov 1999 11:52:47 -0500 (EST)

> from those at the local site).

This again relates to the discussion about whether clients should
be instructed when to use a protocol.  Since you see here how a Mobile
IP client might use two different servers, it makes sense to you.  Yet,
you do not allow for the operation to make sense _in the abstract_
(or, perhaps, "theoretical") case.  I claim that it is better to get
the protocol right in the abstract, knowing that there will be specific
cases.  I do not wish to get involved with listing the special cases
whereby clients might wish to interact with multiple DHCP servers.

Charlie P.

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Nov 1999 12:46:23 -0500 (EST)

Thomas,

>addresses/parameters it needs. That is what I understood Tim to be

You are viewing this different from us I think and its good this is
exposed to the WG cause we need to hear from those WG members speaking 
now (thank you please stick with us as we discuss this).  Nothing in
DHCPv6 prohibits the use of multiple servers on different links and just
one client process running or multiple client processes running.  It
really is an implementation choice and the vendors will decide in the
open competitive market how the implementation will proceed.  

As far as the protocol I think you should tell us exactly where you
think DHCPv6 breaks the use of multiple servers?  I don't see where it
does off the top of my head.

Nor do I think this spec needs to define that with any text so I
strongly disagree.  But I assume right now you are participating as a
working group member not as an Area Director?  Right.

>spec is that it says you pick one server and get all your resources

Your read of the spec is an interpretation of it what it can do  but not
what it can't do.  There is nothing in the protocol that prohibits
multiple servers. How the client does this is the implementors business.
If folks want an appendix to describe an implementation scenario where:

  1. a new interface comes up on the same link (same sever though)
     this is easy.
  2. a new interface comes up on a link that did not exist and 
     may be a new server after the solicit goes out.

As an implementor if I get a new link but dhcpv6 client is already
running for another link AND I want to use the same dhcpv6 client
process I may just try a REQUEST first with the server address I have on
the other link and if it don't work go back to solicit.

Or I may decide the best way to do this for my customers as a client
implementor is fork a new dhcpv6 client when the M bit gets set on the
new link from addrconf.

Either way the protocol will work.

Whether an implementation starts a new dhcpv6 client process or figures
out the software to use the same process is totally not our business in
the IETF.  

If the protocol will not support either case or one of the cases then I
think that is a bug in the spec.  I don't see one and would like to see
the bug revealed if there is one in the protocol.

As a note this is where Charlie and I consistenly disagree with Thomas
on issues.  But we really need to expose all these issues and hear from
the group.

>text certainly implies that one get all resources from one server), I

I disagree with that.  We talk about a server.  

>support getting resources from multiple servers in the case Tim

I think your premises to you conclusion are invalid hence your
conclusion is invalid.

>clients won't implement the feature. 

I disagree with you premise and conclusions again.  If an implementor is
that unaware to not catch this they and the company deserve the
competitive lashing they will get in the market for missing this as
implementors.  They will fix it in their next release.

Do you think implementors are not capable of dealing with a protocol
that is idempotent to this issue?  I think they are and trust them more
than the IETF to put this stuff in specs.

>in the way of specific requirements here.

We don't and did not have to do that the protocol is written so that
client can communicate with a server or server's its that good that
implementors can expound upon the use of that as an implementation
choice.

I can't find any bugs in the spec that cause such a problem and it
appears you can't either.  If you can we will fix them.

It could be when I implement this completely that we will find bugs and
I think we all will.  What I don't think is possible is try to find
every bug in this spec before it goes to PS and that is impossible IMO.
To find the bugs left (other than Mikes issues he is raising) we need to
go implement.

This is how IPv6 base spec, stateless addrconf, neighbor discovery et al
all have worked with IPv6.  I know cause I implemennted a lot of it and
we changed all those specs a few times after they were proposed
standard.

If we are to attempt to find every bug in these specs without going to
PS we will not be successful be here for another 4 years discussing
cause none of us are implememnting this spec until it goes to PS.

>somethign is a general requirement or one appropriate for mobile

I also would like to say that this is not needed if it is needed to move
this spec to PS.  And I would like to hear from others on this besides
the Area Directors and us authors?

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 19 Nov 1999 13:52:10 -0500 (EST)

>From Charlie Perkins:

>whereby clients might wish to interact with multiple DHCP servers.

Working Group members this above from Charlie I strongly agree with and
is the crux of our many disagreement with Thomas as a WG member inputing
to the spec.  

You need to help us here and respond to this abstract issue as it can
reduce the time to get this spec in shape and fix the real protocol bugs
we are finding from this discussion.

Charlie and I are not going to give into Thomas on this stuff unless we
hear from the WG we should and must go that so please advise.

Right now we have a stalemate here between us almost on the philosophy
of specs and to some degree what is necessary for protocol definition.

Can others please respond to this issue Thomas, Francis, Barr, Stig,
Tim, et al...

Ralph also as chair you view of whats happening here is very important
on the constant disagreement charlie and I have with thomas on this
subtle but important set of points.

Right now no one can say the authors including Mike now are not
listening what we are saying is we don't agree with 1 individual in the
IETF about what we have to do hear to get this spec to PS.  So we are
not the bad guys here.  Now if 5 or more persons on this list tell us
Thomas's philosophy is right and we don't change or give the spec to
someone else which we would not do then we will make the changes.

So help us get out of this stalemate mode.  

Or Thomas you could see the wisdom of what both charlie and I are
relaying to you and give us a break here we are trying to just get to PS
and get folks to implement the spec.  We agree to all the issues Mike
sent can we please just resolve them and not try to add second guessing
what implementations will do until we get some started.

thanks
/jim

---

From: Tim Hartrick <[email-masked]>
Date: Fri, 19 Nov 1999 17:55:05 -0500 (EST)

Erik,

> Dealing with multi-homed machines, or to be more specific, multi-interfaced

I was talking about multi-homing in the provider sense not in the interface
sense.  Clearly, DHCPv6 is a protocol that from the client's perspective
operates on individual interfaces.

I was more concerned about cases where I have multiple providers and as a
result possibly multiple DHCPv6 servers providing me with resources.  The
most likely case that I can imagine for this to occur is for mobile IPv6
but I can also imagine cases where I am using a cable modem or DSL system
to provide me with packet transit but I am actually have multiple providers
which use DHCPv6 to provide me with resources.

Tim Hartrick
Mentat Inc.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Nov 1999 22:11:17 -0500 (EST)

> which use DHCPv6 to provide me with resources.

I understand how multi-interfaced will work; client sends DHCP messages
out all interfaces.

I don't understand how multi-ISPed will work. The client will
send a single DHCP message to a single relay. Will that relay be
configured (or automatically using multicast) to ask two DHCP servers
one in each ISP?
Even if that is the case how will the client be told about the (potentially
conflicting) information from the two ISP's DHCP servers?

   Erik

---

From: Tim Hartrick <[email-masked]>
Date: Mon, 22 Nov 1999 22:49:21 -0500 (EST)

Erik,

> configured (or automatically using multicast) to ask two DHCP servers

Right.

> conflicting) information from the two ISP's DHCP servers?

Nasty problem.  It would depend on the extension as to how one handles
conflicting parameterizations received from multiple servers.  A client
implementation that wanted to do this would need to be pretty smart.

Tim Hartrick
Mentat Inc.

---

From: Charles Perkins <[email-masked]>
Date: Tue, 23 Nov 1999 10:50:43 -0500 (EST)

Hello Erik and Tim,

Erik Nordmark == >>
Tim Hartrick  == >

>> configured (or automatically using multicast) to ask two DHCP servers

I think we should distinguish the operation of the relay(s) from
the operation of the local (default) router(s).  Assume that there
is one router.  The router is likely to be advertising prefixes from
both ISPs.  Each relay is likely to have an address for the ISP that
it cares about.  If there is only one relay, it will have multiple
addresses.

If a client hears router advertisements with two managed-link
prefixes, the client should respond to both such router
advertisements with two distinct DHCP Solicitations and so on.
The protocol should proceed naturally from this point.

> implementation that wanted to do this would need to be pretty smart.

It should not be the responsibility of the client to resolve
conflicting parameterizations.  In fact, a client DHCP host computer
should notify the user that there are conflicts, and then the user
should call the local administration and credit $200/hour to
the user's department away from the administrative budget for making
such mistakes and wasting peoples' time.  Part of the burden of having
two ISPs should be to make sure that the local DHCP servers are
compatible, or else that the ISPs have compatible DHCP service if
the DHCP servers are off-site.

It is probably impossible to make clients robust against all
administrative
errors.  They certainly are not so today.  I can hardly imagine them
being
so anytime in the foreseeable future.  I reckon there is a theorem that
says for any administrative domain, there are administrative errors that
can cause clients to become isolated from the network.

Regards,
Charlie P.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Nov 1999 11:53:15 -0500 (EST)

> the DHCP servers are off-site.

Maybe it's because I haven't been following this protocol very
carefully in the past, and don't know much about IPv6, but what you
are suggesting seems extremely unlikely to me.  What if the two ISPs
have two different sets of default routes, or two different sets of
domain name prefixes?  What if a client is supporting more than one
network interface?  I think the thing that resolves the conflicts
_has_ to be the client, because there's no other entity in a position
to do so.  The client may get different parameters from the _same_
DHCP server on two different interfaces, and this does not indicate a
configuration error on the part of the server administrator.

I also don't think it makes sense to specify in the draft what the
client should do in this case, but I think it's important to keep this
problem in mind when implementing clients, because this problem will
come up, and finger-pointing won't solve it.   It may or may not be
worthwhile to mention this problem in the draft and suggest solutions,
although that in itself is a path that is fraught with danger, as we
have seen in the DHCPv4 specification.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Nov 1999 13:11:47 -0500 (EST)

> What if the two ISPs
> domain name prefixes?

Sorry, I meant "domain name *suffixes*".   :'}

			       _MelloN_

---

From: Charles Perkins <[email-masked]>
Date: Tue, 23 Nov 1999 13:12:29 -0500 (EST)

Hello Ted,

Thanks for your note.

Ted Lemon wrote:

> are suggesting seems extremely unlikely to me.

I think that the protocol details we are discussing are not deeply
tied into anything that is IPv6 specific, except for the behavior
of stateful clients in response to router advertisements.

> have two different sets of default routes, or two different sets of

These are good questions, but they are not questions that can
be answered within the DHCPv6 specification.

>                      What if a client is supporting more than one
> network interface?

I agree with the sentiment that says that each network interface should
be treated somewhat independently as far as the default router from
that interface.  Other considerations about choice of network interface
are not easily solved within DHCPv6.  There is a server preference field
that could be adapted for use for preference of network interface, but
I hope we don't have to solve that problem before going to Proposed
Standard.  These are big policy issues that could take years to decide.

>                  I think the thing that resolves the conflicts
> to do so.

In a way I agree with you.  But I don't agree that the conflict
resolution
mechanism has to be specified in the DHCPv6 protocol document.  It's
just too far afield from where DHCP needs to be.  It's a problem that
affects the entire network programming paradigm in a way that is not
well understood today.  I suggest that we make DHCP work as best we
can and hope that multihoming and multi-network conflict resolution
be investigated more thoroughly as time goes on.

>              The client may get different parameters from the _same_

As noted above, I don't think that different parameters on different
network interfaces _necessarily_ represents any configuration error.
So, yes, I agree that such a thing is possible, and in fact I believe
represents possibly correct behavior.

> have seen in the DHCPv4 specification.

Agreed, and I would support the inclusion of any relevant text to
lessen the dangers.  Perhaps you can offer some paragraphs from
your experience...?

Regards,
Charlie P.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 23 Nov 1999 13:12:40 -0500 (EST)

> lessen the dangers.  Perhaps you can offer some paragraphs from

I'll have to think about this - I can write something from a DHCPv4
perspective, but I don't have any DHCPv6 experience, so it'd be tough
for me to write language that you could just drop in without some
serious cogitation.   I think it's worth it for me to do the
cogitating, but right now I'm cooking the failover protocol in my
brain, so I can't do this immediately, which likely means it'll get
dropped on the floor if it remains my responsibility.

Is there anybody else reading this who agrees that this is a problem,
understands DHCPv6, and would be willing to work with me to come up
with the correct verbiage?   I'd be happy to write something up from a
strictly DHCPv4 perspective and provide hints as to how I think it
might be adapted.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Nov 1999 18:37:06 -0500 (EST)

> > conflicting) information from the two ISP's DHCP servers? > > 
> 

Hmm - does DHCPv6 specify what happens when the client sends one 
request message through the relay but gets 2 or more reply messages
from the relay?
My guess would be that it would ignore all but the 1st reply.

This would mean that it is the DHCP relay which would need to 
both "fork" the request to two different servers and then "merge"
the replies. I guess that could be done by a smart relay.

But I don't see how this would make sense business wise for
ISPs serving a home or a small office.
Wouldn't e.g. the cable TV ISP own the cable modem (or set-top box)
and the DSL ISP own the DSL modem?
Those boxes are likely to be the DHCP relays.
Thus you'd find two relays each willing to serve the hosts - and
handing out addresses from each ISP. So I can't see very the above
postulated "smart" relay would exist in practise.

Thus I think this can only be done if all the hosts in the home are
smart enough to either pick multiple DHCP relays/server and send
requests to all of them and merging the results.
Alternatively, the simply hosts would somehow just pick one relay/server.
Today such a simple host can't tell which ISP (or administration) is
running a server. If we think this is an important case perhaps the
DHCP advertise should contain something naming or identifying the
admin domain.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Nov 1999 18:36:57 -0500 (EST)

> The protocol should proceed naturally from this point.

BTW: The prefix in the router advertisement doesn't have a Managed bit.
The managed bit is part of the router advertisement.
Thus the above suggestion doesn't work as far as I can tell.
Perhaps there is some other way that the client can tell that there
are two different DHCP domains out there?

  Erik

---

From: Jim Bound <[email-masked]>
Date: Fri, 26 Nov 1999 11:13:34 -0500 (EST)

Hi Ted,

>strictly DHCPv4 perspective and provide hints as to how I think it

FYI I agree with you 100%.  Worst case just write it up with dhcpv4
lingo and we can add it to the next draft which has to reviewed anyway
before we do the follow on draft for PS.

thanks
/jim

---

From: Charles Perkins <[email-masked]>
Date: Sat, 27 Nov 1999 14:55:35 -0500 (EST)

> My guess would be that it would ignore all but the 1st reply.

This should never happen.  DHCP Requests are addressed to a specific
DHCP Server.  I don't see now how it is that a relay would duplicate
or fork such a request message (or a Reply).

There has been thought given to the possibility of using multicast
messages for requests, but it has not been specified.

Regards,
Charlie P.

---

From: Charles Perkins <[email-masked]>
Date: Sat, 27 Nov 1999 15:32:55 -0500 (EST)

> are two different DHCP domains out there?

How about if we say that a router advertisement with the 'M' bit
set means that all prefixes advertised in the extensions are for
managed links?

If a router has some managed links and some unmanaged links,
then it needs to send out two different router advertisements,
one for the managed links, and one for the unmanaged links.

Is this reasonable?

I note that such separation of advertisements would similarly
be required whenever the different prefixes required other parameters
to be different (besides just whether the links were managed).
For instance, if a router wanted to be default router for some
but not all of the prefixes, separate advertisements would be
needed.

If more ambitious suggestions were in order, I might suggest
the creation of an 'M' flag from the reserved flags of the Prefix
Information option.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Nov 1999 04:45:50 -0500 (EST)

In your previous mail you wrote:

=> I believe this problem can be solved if ways to use DHCPv6 are described
in a separate document:
 - we keep mechanisms in current I-Ds which should become PS ASAP
 - we explain how to implement/use DHCPv6 in an application document
   which doesn't need to become a PS today
We have this kind of things for routing protocols and I think this is a
good way to split theory and pratice.
Another point, I believe we have to update/improve autoconfig specs
because interactions between stateless (which is described in these specs)
and statefull (aka DHCPv6) autoconfigs were/are not fully understood.
An application document can help us to see what are the problems and
will be easier for implementor feedback.

Is this a good solution for you (Thomas and I-D authors)?

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Mon, 29 Nov 1999 04:48:25 -0500 (EST)

=> the 'M' bit meaning is "this link is a managed link".
Of course it applies to all prefixes of the managed link.

=> I can't see your problem here, router advertisements on different
links are simply router advertisements on different links...

=> to be a default router is at most a link property (usually
it is a node property, ie. there is one default router for the whole node).

=> there is an 'A' bit for per prefix control of autoconfiguration
(its meaning is specified for stateless autoconfiguration and still
unknown for statefull autoconfiguration).

Regards

[email-masked]

PS: please don't discuss about multiple interface links (:-)...

---

From: Richard Draves <[email-masked]>
Date: Mon, 29 Nov 1999 13:53:17 -0500 (EST)

> From: Charles Perkins [mailto:[email-masked]]

I've just joined this discussion so I'm not up to speed... Are you saying,
send different RAs on different links (of course this is OK) or send two
different RAs on the same link (maybe OK, but most implementations today
don't support it I would guess).

> but not all of the prefixes, separate advertisements would be

This is confused - a router either advertises itself as a default router or
not, there's no concept of being "default router for a prefix".

Rich

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:42:45 -0500 (EST)

..boy!  take a few vacation days and see what you miss??!!!??!!!

My apologies in advance to the group for my replies which may seem a bit out
of date after a week.....

--Barr

[Tim Hartrick wrote on 17 November]

> aren't managing the resource being released.  This is bad.
[Barr Hibbs]

--I completely agree:  I see no other way that the clients (and servers)
could operate.

[...stuff deleted...]

> clients to handle getting resources from multiple, possibly unrelated,
[Barr Hibbs]

..while I agree that addressing this now is probably best for the long-term
development of the protocol, I have some reservations about attempting to
completely specify this mode of operation -- we want to complete work on the
protocol sometime soon or it will be irrelevant.

[...stuff deleted...]

> It is hard to see what good could come from releasing resources to a
> server that didn't allocate them in the first place.  I can imagine
> circumstances in which it would work but they all require thinking about
> server-to-server protocols which is a rat-hole that we desperately want to
> avoid I think.
> 
[Barr Hibbs]

Yes.  Especially since "multiple" servers seems to imply more than 2, which
is the only DHCPv4 case currently being considered.  An "n-way" interserver
protocol is probably much more complex than the 2-way failover protocol, so
we should not tie DHCPv6 to the existence of an inter-server protocol.

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:43:42 -0500 (EST)

..boy!  this backlog is quite something....

--Barr

> > particularly true if the multi-homing were for unrelated ISPs.
[Thomas Narten]

[Barr Hibbs]

suppose we have one administrative domain for each network interface, then
multiple interfaces imply multiple servers because the likelihood of
different administrative domains having the same server is, I think,
vanishingly small....

[...stuff deleted...]

[Barr Hibbs]

Okay, but what about the case where there are multiple servers per
administrative domain?

[Thomas Narten]

[Barr Hibbs]

..see Erick's comments about "per-interface" servers...

[...stuff deleted...]

[Barr Hibbs]

..true, identifying these would be very useful, but in their absence,
implementors may do it anyway....

[...stuff deleted...]

[Barr Hibbs]

..roaming (but not mobile-IP) hosts will do this...

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:43:09 -0500 (EST)

> ...again, my apologies to the group for responding after taking several
> vacation days...
> 
> --Barr
> 
> 
> (From Thomas Narten)
> 
> Thomas, I disagree:  if a server is being retired gracefully by an
> administrator, that administrator probably will not really care if every
> last resource is released because the retirement process will most likely
> first entail stopping the soon-to-be-retired server from allocating any
> resources, then simply waiting the anticipated lifetime of all assigned
> resources, leaving any that fall out to simply be handled as exceptions.
> 
> while the DHCPv4 failover protocol is proceeding, I don't see an
> interserver protocol work item for DHCPv6 on our agenda:  that strongly
> suggests that one won't be forthcoming for at least a year, so unless
> Charlie or Jim or Kim or Bernie or someone else takes that as a project,
> spending any great amount of time on DHCPv6 "hooks" or "features" to
> support or that depend on an interserver protocol is, I think, a serious
> tactical error....
> 
> [...stuff deleted...]
> 
> What about "gateway-like" devices with NICs on different network segments?
> 
>

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:43:18 -0500 (EST)

..more catching up on the discussion thread...

--Barr

[Tim Hartrick]

[Barr Hibbs]

while I think I disagree as to the likelihood of this occurring, I
definitely do agree that your point is well-taken....

[...stuff deleted...]

[Barr Hibbs]

How about something like:  "Clients must release resources to the
[administrative] domain which assigned them."

-- obvious problems are how to identify domains, and
-- what is a domain has multiple servers and no interserver protocol?

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:43:30 -0500 (EST)

..still catching up...

--Barr

[Erick Nordmark]

[Barr Hibbs]

Yes.  That seems to simplify several issues.

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 14:43:55 -0500 (EST)

..still catching up...

--Barr

[Barr Hibbs]

is this process for ISP selection specified anywhere?

[...stuff deleted...]

[Barr Hibbs]

..I'm missing something here:  you have one transport provider and a
different ISP.  Why is this at all unusual?

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 15:40:11 -0500 (EST)

..continuing to catch up...

--Barr

[Charlie Perkins]

[Barr Hibbs]

AGREED!!!

> possible, not to tell clients when to use the protocol.  The specification
> also
[Barr Hibbs]

..how about "one server selected per [administrative] domain?"

[...stuff deleted...]

[Barr Hibbs]

yes, Yes, YES!!!

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 15:41:04 -0500 (EST)

..still catching up with the discussion thread...

--Barr

[Jim Bound wrote...]

[Barr Hibbs]

..if I may generalize....

The Europeans and Asians desperately want an entire suite of protocols for
IPv6 -- this discussion is ultimately productive if it results in a more
robust protocol, but if we are simply bogged down in the minutiae of a
theoretical discussion of protocol specifications, then we waste everyone's
time. 

Seems to me that we have the basics already:

1. multiple servers in multiple domains are both possible and likely

2. absent interserver AND interdomain protocols we must address releasable
resources in the DHCPv6 draft

3. while it places a small burden on a client, requiring resources to be
released to the assigning entity is simply the best, most workable starting
point -- we are now including versioning information which permits us the
means to modify the protocol in the future if implementations can't make
this work

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 15:41:19 -0500 (EST)

..almost caught up!

--Barr

[Erik Nordmark]

> I don't understand how multi-ISPed will work. The client will send a
> single DHCP message to a single relay. Will that relay be configured (or
> automatically using multicast) to ask two DHCP servers one in each ISP?
> Even if that is the case how will the client be told about the
> (potentially conflicting) information from the two ISP's DHCP servers?
> 
[Barr Hibbs]

This is NOT impossible!

--either client request contains some discriminator allowing server to
ignore,

--or--

--mechanism for specifying an ISP exists,

--or--

--clients/servers must deal with "stray" requests/responses

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 15:41:31 -0500 (EST)

..still catching up!

--Barr

[Charlie Perkins]

[Barr Hibbs]

Charlie, one router is NOT a good assumption.  In our case we NEVER
provision a network segment with fewer than two routers, and for many busy
or critical segments we often use three or four, each connected to different
paths.

{Charlie Perkins]

[Barr Hibbs]

Good!!

> (potentially
[Barr Hibbs]

..uh... isn't this the client/user's responsibility?

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 29 Nov 1999 15:40:52 -0500 (EST)

> ...still catching up!
> [Jim Bound]
> ...mmmmm....  shouldn't a solicit always be sent in this case?  at least,
> if it is necessary to make the protocol work gracefully....
> 
> 
> [...stuff deleted...]
> 
> ...while I don't agree that well-considered analysis CAN'T find all
> protocol bugs (at least, in theory), in practice test implementations
> really are needed to get to this point...
> 
> 
> [...stuff deleted...]
> 
> Agreed!!
> Jim, I definitely agree with you on this point!
> 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 29 Nov 1999 16:28:50 -0500 (EST)

Hello Barr,

Thanks for reading over all the mail and making comments!

>> is one router.
 
> or critical segments we often use three or four, each connected to different

Sorry for being unclear.  I only made the assumption so that
the discussion would be easier to manage.  Having multiple
routers is fine, and doesn't change anything except for making
the sentence structure of the explanation more complicated.

>> == me

> = Barr Hibbs

I'm not sure what "this" is in your sentence.  My answer here is
when it means the burden of having compatible DHCP servers when
the servers are located at the ISPs' sites.

First, I am assuming the existence of a local network administration
that has negotiated the service agreements with the ISPs.  If there
is not such a local network administration, then it falls on the
shoulders
of the users to do this work.

But if there is such an administration, I should think that it is their
job to make sure that the user population can be served well in this
manner.  Most of the users would have to study for some while before
understanding all of the ways that multiple DHCP servers might be
incompatibly administered.

What about home users...?   Right now, I can't think of the right
answer for making dual-ISP home users able to rely on compatible
DHCP service.  On the other hand, I don't think this is sufficiently
critical that we have to solve the problem just now.  I think that
the solution, in any case, will depend upon answers related to the
general multi-homing problem.  I don't think we know those answers yet.

Regards,
Charlie P.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 20:56:07 -0500 (EST)

>we are finding from this discussion.

Put succinctly, I know of no abstract reason to preclude the concurrent
interoperation of a DHCP client with multiple servers.  In my opinion, the
current spec does not adequately describe the details of concurrent use of
multiple servers to ensure interoperable DHCPv6 clients that will provide
predictable, manageable, useful behavior.

Potentially open issues in the use of multiple servers:

* Text that implies interaction with a single server through use of
singular reference to "server" and through omission of any specific
reference to multiple servers
* Semantics of Solicit message in the presence of multiple DHCP services:
how does a client know when it should interact with multiple servers; how
does a client differentiate between redundant servers (from the same
service) and servers with different resources?
* Text in section 5.3 describing use of server preference field that
implies use of single server with highest preference

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 20:55:36 -0500 (EST)

Based on re-reading this discussion thread, and thinking about two
scenarios in more detail, here are some additional thoughts on how to
manage and release "releasable resources".

The two scenarios are based on whether a client "MUST", "SHOULD" or "MAY"
release releasable resources back to the server from which the the resource
was originally obtained.  If the spec says "MUST", then the client may be
unduly constrained from returning the resource to some other server that
might be able to process the release.  If the spec says "SHOULD" or "MAY",
then there is the risk of releasing the resource to a server that cannot
process the release.  

I think the problem arises because there may be more than one server (but
not all servers) that can process a particular resource.  That is, there
may be some redundant or backup server that can process a particular
resource, but there may be some other servers that cannot process the
resource.  In this situation, choosing a backup server at random may not
work; the client may choose the wrong server.

Rather than associating a resource with a particular *server*, it might be
possible to associate a resource with a DHCP *service* (which may be
provided by more than one server).  If servers and resources were
identified by service, a client could choose among multiple, equivalent
servers within a service.  In this way, a client could take advantage of
redundant *servers* within a *service*, and avoid the risk of returning the
resource to some other server that cannot process the resource.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 20:55:58 -0500 (EST)

>> support getting resources from multiple servers in the case Tim

I disagree with Thomas, here; perhaps we disagree on the meaning of the
word "support".  The protocol, as documented in the current draft, *can* be
used to obtain resources from multiple servers, although much of the text
seems (to my reading) to imply otherwise.  There may be some technical
issues about server selection in section 5.3 (see my previous note); it may
be that we need to clarify that a client needs to send multiple Solicit
messages, one to each potential DHCP service, to find the highest
preference server from each DHCP service.  

>is, I wish I could say it more tactfully but I don't know how, totally

I disagree with Charlie, here.  The examples he cites are irrelevant to
this situation.  The ability to use DHCPv6, as documented in the current
draft, with multiple servers does *not* imply that it will be implemented
in a useful, interoperable and useful way.

Let me take this a step further and say that using the dictum of "let the
market decide" has *not* worked for DHCPv4 *clients*.  There is one
predominant client, which has some well-documented interesting behaviors
that have been fixed in later releases.  The cost of deployment has
precluded the deployment of new releases of that client in many cases.  The
cost of deploying a different vendor's client would be prohibitive and
stand in the way of any market selection mechanisms.

We must be very careful to get the client specification right from the
beginning...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 20:55:47 -0500 (EST)

>specification does not discuss them.

While the spec does not specifically require the use of one server at a
time, much of the language seems to me to imply the use of a single server.
 And, as far as I can recall, this is the first time we've formally
discussed the idea of multiple simultaneous transactions with different
servers.  I think the claim that the spec currently allows the client to
ask for parameters from more than one server is not entirely supported by
the text in draft-ietf-dhc-dhcpv6-14.txt; e.g.:

3.3. Request/Response Processing Model

   The request/response processing for DHCPv6 is transaction based and
   uses a set of best-effort messages to complete the transaction.

   To find a server, a client sends a DHCP Solicit from the interface

   which it wishes to configure.  The client then awaits a DHCP
   Advertise message containing an IP address of a DHCP server.
   Transactions are started by a client with a DHCP Request, which may
   be issued after the client knows the server's address.  The server
   then unicasts a DHCP Reply, possibly via a relay.  At this point in
   the flow all data has been transmitted and is presumed to have been
   received.

4.3. DHCP Request Message Format

   In order to request configuration parameters from a server, a client
   sends a DHCP Request message, and MAY append extensions [15].  If
   the client does not know any server address, it MUST first obtain
   one by multicasting a DHCP Solicit message (see Section 4.1).

5.3. Receiving DHCP Advertise Messages

   After a client has received a DHCP Advertise message, it has the
   address of a server for subsequent DHCP Request messages.

   [...]

   Unless a DHCP Advertisement is received with a preference equal
   to 255 (see Section 4.2), the client MUST wait CLIENT_ADV_WAIT
   seconds after issuing the DHCP Solicit message in order to receive
   the Advertisement with the highest preference.  After waiting for
   that period of time, a client MUST select the highest preference
   server as the target of its DHCP request.  If a client receives an
   advertisement with a preference of 255, it does not have to wait for
   any more advertisements.

   If a client sends a DHCP Request to a highly preferred server but
   fails to receive a DHCP reply from that server after following the
   retransmission algorithm in section 8, the client MUST then try to
   send a DHCP Request to a less preferred server.

(I think this section, at least, needs to be rewritten to allow interaction
with multiple servers.  Under what conditions may a client disregard the
server preference and begin a transaction with a second server with a
[presumably] lower preference?)

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 20:54:55 -0500 (EST)

>That problem has been avoided in DHCPv6, to the best of my current

Charlie, to improve my understanding of DHCPv4 and to be able to tell
students about when state machines may not be an appropriate specficiation
or implementation tool, can you give me an example of how the DHCPv4 state
machine was a problem in your implementation of DHCPv4.  How would the
implementation have been made easier without the state machine, and how can
the behavior of the DHCPv4 client be specified clearly and concisely
without a state machine?

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Mon, 29 Nov 1999 22:41:36 -0500 (EST)

Hi Francis,

>Is this a good solution for you (Thomas and I-D authors)?

This sounds good to me but do want to hear the input on the issues Mike
sent out, or ones like yours.  If it is really broken or NOT CLEAR we
should fix it.

I don't think we should mess with stateless autoconfig because of DHCPv6
until we have seen there is a real problem from implementation and
interoperability testing DHCPv6 in the presence of stateless addrconf.
But I don't think we can get there till DHCPv6 is PS.

/jim
Regards

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 23:20:42 -0500 (EST)

>> resources, leaving any that fall out to simply be handled as exceptions.

Perhaps part of our problem is in not having a clear definition of the
semantics of a releasable resource.  In particular, what happens when a
releasable resource is not correctly released?  In the case of an IPv6
address (the only concrete example we have of a releasable resource), I
believe we can tolerate the failure of a release.  That is, if a release
operation fails for any reason, the lease on the address will eventually
expire and the address will become unassigned.

This model seems to work OK for DHCPv4.  Administrators have the freedom to
choose lease lengths appropriate to the IPv4 address usage patterns, so
that lease expiration 

However, because we're allowing for other (as yet undefined) releasable
resources, it may be the case that these other releasable resources may
require explicit, reliable releases; simply waiting for a lease to expire
isn't sufficient.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 29 Nov 1999 23:20:59 -0500 (EST)

>-- what is a domain has multiple servers and no interserver protocol?

Barr - sounds like we developed similar ideas in parallel.  In a note I
posted earlier today, I suggested associating an address with a "DHCP
service", which I read to be the same idea as your "administrative domain"...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Nov 1999 23:21:23 -0500 (EST)

> We must be very careful to get the client specification right from the

Hear, hear.   The number of broken DHCP clients for which there are
subtle workarounds in the ISC DHCP server is kind of depressing.
Vendors who aren't particularly interested in DHCPv6 can't be expected
to think these issues through to the level of detail that we would
think them through.   That's why they pay us the big bucks, if you
will pardon my saying so.

I _still_ hear RFC1541 referred to as gospel WRT DHCPv4, and encounter
new clients implemented to it, even though it is actually not
interoperable with the current RFC.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 29 Nov 1999 23:21:12 -0500 (EST)

> >drastic inconvenience or impossibility of starting multiple state

I didn't see this go by the first time, but it _is_ a rather
surprising statement to me, because the ISC DHCP client in fact
does implement arbitrary numbers of state machines!

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 00:28:13 -0500 (EST)

hi barr,

>> ...still catching up!

we appreciate that alot...

> if it is necessary to make the protocol work gracefully....

yes my sentence is to terse.  the solicit would learn if this is a new
sever is what I should have said in #2.

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 00:29:50 -0500 (EST)

>means to modify the protocol in the future if implementations can't make

I agree and a good point.  With the version # we are taking a lesson
from DHCPv4 for sure.

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 10:01:58 -0500 (EST)

>reference to multiple servers

This is pretty clear and pretty easy to fix IMO.

>service) and servers with different resources?

Just sent suggestion to fix that which will support getting this done
rather expediently in the spec.  

I am hearing from the working group very loud we need to make choices
that can move this along expediently.

Agreed.

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 10:02:08 -0500 (EST)

Hi Ralph,

>preference server from each DHCP service.  

The solicit is a multicast sendmsg() for a link (subnet) then the client
will hear from multiple servers, which as you pointed out in other mail
we need to clarify for the multiple server case.

Right now I don't think it wise to have different multicast solicit
address types on a link, until we get a lot more knowledge about IPv6
let alone DHCPv6?  I would like to see it work in practice a bit before
going that route.  Also this would presume the client has some knowledge
to differentiate solicit types at boot time and is that a good idea?

thanks
/jim

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 10:01:48 -0500 (EST)

>resource to some other server that cannot process the resource.

Mike has proposed to add an address prefix of topological significance
to the address extension.  The only realeasable resource we have right
now.  For other reasons but close to the same reason.
This could be added to also support knowing if a server is within the
administrative domain as Barr suggested.

The way this would work is on the Advertisement we would add a field for
the server to put its prefix topological significance.  When the client
goes to release a resource to a server the address would be checked
against that stored value for servers and provide the client knowledge
if in fact that server can release the address.

This is more doable than using a service bit mask for now and if we in
the future define other than addresses we can use the server prefix as
part of that releasable resources associations.  

Also if this in the future needs to be expanded we can do so with a new
version of the protocol.

I think this solves the problem in an expedient manner for the spec and
keeps us on track but also addresses Ralph's suggestion I think?

Comments please?

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 30 Nov 1999 10:01:02 -0500 (EST)

Hi Ralph,

>the text in draft-ietf-dhc-dhcpv6-14.txt; e.g.:

I think the issue here is it would make folks more comfortable if we had
some sections that actually mention "multiple servers" in some sense
where it might be appropriate?

But as I read the text below it is idempotent to the multiple server
question, except when we "say pick a server"?

>   the flow all data has been transmitted and is presumed to have been

This is idempotent and I can see no where we break the multiple server
model.  The protocol keeps on ticking whether there is 1...N links and
1...N servers.  

Here is where we might add that this solicit in fact will support
multiple instants of solicit on different links (subnets in IPv4 terms)
or in section 4.1.  

   [...]

Here what we are saying was an addition from the Chicago meeting.

We assume the client on the same link could hear from multiple servers
as we were told by the working group in Chicago.  Per the working group
we added the preference field to the Advertisement message.  The way the
code and implementation could work is as follows:

  boolean head_cheese_server = FALSE;
  int *head_cheese_server_data
  pthread_start_client_solicit;  /* this is not how it looks but */
  time_interrupt_set (CLIENT_ADV_WAIT);
  while (pthread_CLIENT_ADV_WAIT_not_back) {
    get_advertisement_message(server_msg_block);
    If (server_msg_block->preference_value = 255) {
       head_cheese_server = TRUE;
       head_cheese_server_data = server_msg_block;
       break;
    } else 
        store_this_server_for_later_sort (server_msg_block);
  }
  /* not putting in check here for discussion if no advertisements
     came back */
  If (head_cheese_server)
   use_the_head_cheese_server_for_request(server_msg_block);
  else
   sort_and_pick_highest_preference_server(server_msg_block);

But the point is that we listen to multiple servers and select among
them based on the preference field from the server unless a server says
I am the boss or head cheese use me.  The first server to be heard that
does this wins.

The client may store all server advs for later use too.

>[presumably] lower preference?)

So do you believe we should say the client SHOULD store servers that
respond to the solicit and then discuss the case when the client will
use a server of lower preference?

This I believe resolves your concern and is doable?

thanks
/jim

---

From: Thomas Narten <[email-masked]>
Date: Tue, 30 Nov 1999 12:23:37 -0500 (EST)

> preference server from each DHCP service.

I think we are actually in agreement. My use of "does not support"
appears to have been confusing and misleading. The underlying message
formats certainly could support a client having multiple
interactactions with different servers simultaneously.  However, the
spec itself has little text on this and my expectation of what folks
would actually implement (based on my read of what the current text
says should be implemented) is that clients will in practice pick one
server and interact only with it.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Nov 1999 13:38:23 -0500 (EST)

>where it might be appropriate?

Yes, that's right.  At least a few words pointing out that a
client *may* choose to interact with multiple servers simultaneously.
There may be other text required to ensure correct interoperation with
multiple servers, as you 

>model.  The protocol keeps on ticking whether there is 1...N links and

It doesn't break the multiple server model, but (as I interpret the text)
does not explicitly point out that the client may interact with multiple
servers.  This might be a good place to add text about how the spec
allows for concurrent interaction with multiple servers.

>multiple instants of solicit on different links (subnets in IPv4 terms)

OK...

>I am the boss or head cheese use me.  The first server to be heard that

I don't see how this mechanism allows for use of more than one server.
The mechanism explicitly says "pick the one head_cheese or highest
priority server".  What crieria does the client use to decide to use
and choose a second server? 

>This I believe resolves your concern and is doable?

No, this doesn't exactly address my concern.  What I read is a mechanism
for *serial contact* with multiple servers, but *interaction* with only
one server at a time; i.e., the client works down the list, one server at a
time, until it successfully completes a transaction with *one* server.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Nov 1999 15:31:23 -0500 (EST)

Oops...the ", as you" in the following sentence from my previous message
should be replaced with ".":

- Ralph

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 15:31:11 -0500 (EST)

Hello Ralph,

> the behavior of the DHCPv4 client be specified clearly and concisely

I don't think that using state machines automatically leads to
inconvenient implementations.  I only know that the implementations
I had to use some years ago had this problem.

Probably it is better to describe states as pertaining to a
transaction, than to a client.  Maybe it would be enough to
specify that any client has to be able to run several state
independent state machines simultaneously.  Maybe it would
be even better to specify that state variables should not have
global process scope.  Thread variables might have to be indexed
into arrays per thread or something.

On the other hand, I think that many protocols can be specified
in a way that is simple enough to allow correct implementations
that don't rely on state machines.

I was happy to read Ted Lemon's note about ISC's implementation.
I wonder if it was the initial design of the ISC system, or instead
a design that was arrived at from experience with other more
restrictive state-based implementations...

If this is too terse, my apologies, but I'll have to wait until
later to write more if needed.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 15:30:26 -0500 (EST)

Hello Thomas,

>                                        The underlying message

Here, I agree with you.  I think this will be the most
typical case.  Except for the boundary cases where a server
crashes and a client has to go find another server, for
example.

Regards,
Charlie P.

---

From: Ralph Droms <[email-masked]>
Date: Tue, 30 Nov 1999 17:04:51 -0500 (EST)

At 03:31 PM 11/30/99 -0500, Charles E. Perkins wrote:
>> [...] clients will in practice pick one

But I would not consider this case example to be an
example of *concurrent*
interaction with multiple servers.  I would expect
a client to support one-server-at-a-time interaction
with multiple servers; e.g., server selection by
descending preference.  I think the spec needs to be clearer
about allowing transactions with more than one server
at a time.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Nov 1999 17:06:10 -0500 (EST)

> restrictive state-based implementations...

The ISC DHCP client was designed off the protocol spec - neither I nor
Elliot Poger had any experience with other implementations.  The ISC
client does use state machines, BTW - just not a single state machine.
Elliot's original implementation held the state machine global and
forked a new process for each interface, but this seemed unnecessary
to me, so I stuffed the state machine into a per-interface data
structure.  Each network interface then had its own data structure
with timers, parameters to send to the server, and so on.  The whole
thing is event driven - the main program launches the initial event in
each state machine, and then just sits there and handles new events
(timeouts and packet arrivals) as they happen.   Incoming events are
associated with particular state machines based on the transaction
id.

I later (in version 3.0) made a single pervasive change to the client
to support an arbitrary number of state machines per interface.  This
means that if you want to have more than one IP address per interface,
you instantiate a state machine for each address you want, each with
its own unique client identifier (and other parameters, if desired).
Installing IP addresses on the interface gets trickier if you have
more than one per interface, but that is the only real complication.
My motivation in doing this was to implement a DHCP test client, but
since I've done it I've had several people take it and use it to
manage multiple IP addresses per interface.

I would suggest that for DHCPv6, the state machine be associated with
the entity needing an IP address.  That is, if your DHCP client knows
it needs three IP addresses of various kinds, it would set up three
state machines to manage those addresses.  But this is said from a
naive point of view - I have not read the spec closely enough recently
enough to know whether this is the right way of putting it, or that it
makes sense at all.  (And I apologize for that - I'm only
participating right now because I get the feeling I may be of some
service, even if I can't speak authoritatively.)

			       _MelloN_

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 18:49:36 -0500 (EST)

Hello Ted,

>                                               Incoming events are

This makes sense to me.

> the entity needing an IP address.

Would you be willing to support my contention that, instead, the
state machine be associated with the transaction by which the
IP address is expected to be obtained?  This seems to avoid some
of the possible negative interaction between independent requests.

>                             (And I apologize for that - I'm only

It seems to me that you have good ideas to offer.  Thanks for
getting them out there for us to think about.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 19:58:08 -0500 (EST)

Hello Richard,

> don't support it I would guess).

I don't see why it is wrong to send different RAs on the same link.
In fact, I thought that this possibility was explicitly discussed some
years ago on the mailing list.  There was concern about what might
happen if the advertised parameters (e.g., MTU) were incompatible.

> not, there's no concept of being "default router for a prefix".

A router advertises a prefix, and its willingness to be a default
router.  I infer that it wants to be a default router for that
prefix.  I suspect there would be cases where a router would want
to be a default router for some prefix(es) and not for others.
This would be especially true for the multihoming case.  In such
cases, I reckon distinct advertisements would be needed.

Or maybe I am confused.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 20:36:00 -0500 (EST)

Ralph Droms wrote:

>                   It is not fair to say that our specification does
> this situation.

True!  However, the point _was_ to show that irrelevant details do NOT
need to be specified.  I strive to eliminate specification of irrelevant
details.  And, just because a detail is irrelevant to the specification,
does NOT mean it is not important for the implementation.

>              The ability to use DHCPv6, as documented in the current

I think that the current specification promotes interoperability,
so I must disagree with your assessment.  Usefulness is, perhaps, in
the mind of the beholder.  The features in the protocol are, to my mind,
quite likely to be useful now and for many years in the future.
Features that are unlikely to ever be useful should be pointed out
and nominated for removal.

> that have been fixed in later releases.

Hmmm... I thought that many of the problems arose because the
specification was not followed.  Whenever there are ambiguities
in the specification, they should be eliminated.  If implementor A
assumes behavior (X) that is not in the specification, and implementor B
assumes behavior (Y) that is not in the specification, then both
implementors are doing something wrong.  If implementor C assumes
behavior (Z) that contradicts an explicit specification, then
there is really no hope is there?

I think it is almost impossible to anticipate every wrong possibility
for implementation and doctor up the specification to forestall them
all.  It is far better for the specification to just say what is needed,
and not delve into ambiguities and philosophy any more than is necessary
to get the ideas across.  The more text, the more places there are to
get stuff wrong.  Duplicating text across independent parts of the
specification is an open invitation to error, as subsequent revisions
cause changes in one clone of the duplicated text to be mistakenly
omitted from another clone of the duplicated text.

> We must be very careful to get the client specification right from the

I sure do agree with you, Ralph,

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 20:35:33 -0500 (EST)

> resource to some other server that cannot process the resource.

Once a configuration item is designated a "service", with
multiple interchangeable servers, I think it is better suited
as a candidate for identification by way of Service Location
Protocol.  SLP was designed for exactly this kind of operation.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 20:35:44 -0500 (EST)

Ralph Droms wrote:

> servers.

I didn't go over the archives, but I know that I have discussed this
possibility many times in the past.  And, I was pretty sure that it had
come up in conversations at IETF.  Those hardly qualify as formal
discussion, I know.

>            I think the claim that the spec currently allows the client to

This paragraph is worded precisely to allow multiple simultaneous
transactions.  A client sends a DHCP Solicit from the network interface.
It could send another Solicit from another interface.  The same
interface
could be configured with multiple prefixes (somehow).  The client could
send a separate Solicit for each prefix, perhaps at the same time.
I do not see any wording that even prevents the client from sending
multiple Solicits from the same interface at the same time for the
same prefix.  However, in that case, certain timing parameters must
be respected.

>    one by multicasting a DHCP Solicit message (see Section 4.1).

This specifies what a client MUST (at minimum) do to request
configuration
parameters.  It does not prohibit additional actions.

>    address of a server for subsequent DHCP Request messages.

This statement is true regardless of how many advertisements the client
receives.  It can get multiple advertisements from different servers,
with different preferences.  It can get one advertisement only.  It
might
only get one advertisement if it sent out various solicitations, perhaps
due to network congestion.  In fact, it might get zero, in which case
it would resend the Solicitation.

>    advertisement with a preference of 255, it does not have to wait for

This specifies how long a client has to wait before sending its
DHCP Request message.  It does not limit how many interfaces a
client might want to simultaneously configure.

> [presumably] lower preference?)

So far, I didn't see what was wrong.  On the other hand, if you would
like to suggest some clearer wording, I think that would be a good way
to go about resolving any lingering doubts, as well as eliminate them
before they arise for future readers of the specification.

Regards,
Charlie P.

---

From: Richard Draves <[email-masked]>
Date: Tue, 30 Nov 1999 20:36:10 -0500 (EST)

> happen if the advertised parameters (e.g., MTU) were incompatible.

There's nothing wrong with it, what I meant is that I don't know of any IPv6
router implementations that will actually do it today.

> cases, I reckon distinct advertisements would be needed.

To repeat myself, there's no concept of being "default router for a prefix".
When a router advertises a prefix (meaning includes a Prefix Information
option in a Router Advertisement), the prefix can mean several things. If
the A bit is set, then the prefix is used for stateless address
auto-configuration. If the L bit is set, then prefix is put in the host's
on-link prefix list. In either case, there's no connection between the
prefix and the router that advertised it.

When you say "default router for a prefix" it sounds like you mean
"destination addresses matching the prefix should be sent to the router"
which is certainly not correct.

Rich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 21:08:49 -0500 (EST)

> which is certainly not correct.

You are right.  I am having a brain check.  Too many keystrokes,
too many messages to read.  I'll try to figure this out again later
after my eyes stop boiling.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 30 Nov 1999 21:07:57 -0500 (EST)

> predictable, manageable, useful behavior.

I hope you be willing to point out text that is wrong, or suggest
some strategy for us to forestall erroneous interpretations.

> reference to multiple servers

I think we need to say in the introduction that the specification
explicitly allows multiple simultaneous transactions with different
DHCP servers.

> service) and servers with different resources?

I don't think a client needs to make the differentiation.  If it's
truly a service, it should be resolved using SLP.

I also think that DHCP should be invoked because of client needs.
Thus, when the client needs something, it will take action.  I would
interpret your question to be asking how does a client know when it
needs something.  I don't know how to answer that question, and I hope
we don't have to answer it in order to accomplish our near-term
objectives.

> implies use of single server with highest preference

This is in response to a solicitation.  If the client uses the same
link-local address for each of its multiple solicitations, then there
is ambiguity in determining which advertisement belongs to which
solicitation.   The client can solve this problem by picking different
link-local addresses for each distinct solicitation.  This can be
specified, if the working group wants to make the distinction clear.

I think that these cases are very much in the minority.  I agree that
the current specification could be made clearer on this point, but on
the
other hand there are several ways to solve the problem, and it would not
arise for most clients any time soon.  I'll try to suggest a solution
for the problem, or be open for consideration of anyone else's
suggestion.

Note that Solicitation/Advertisement is not a transaction, and should
not require maintenance of state at the server.

Regards,
Charlie P.