Subject: DC meeting: Discussion question #2, multiple IP addresses

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

Some background for this question:

In response to input by the WG, RECONFIGURE has been
clarified by adding additional messages:

Server:
=======
RECONFIGURE
RECONFIGURE_INIT

Client:
RECONFIGURE_REPLY

RECONFIGURE is used to send extensions to client(s) from the server,
to which a client would reply with a RECONFIGURE_REPLY message.

RECONFIGURE_INIT is used to notify clients that they are to perform
the REQUEST/REPLY exchange with the server.

2) Stateful autoconfiguration and multiple IP addresses. When would a
client need to request additional IP addresses over and above what the
administrator has configured through site policy?

EXPLANATION: This question can be rephrased as: "Can a client request IP
addresses over and above what has been configured by the server?"
Examples brought up at DC were somewhat far-fetched. However, in DHCPv4,
multiple IP addresses have been assigned to an interface simply by
specifying a different clientID. To the DHCPv4 server, it looks like
there are two distinct clients, when in fact there is a single client
managing the IP addresses for the interface. This is used to host a
service on different IP addresses (X.X.X.X.25)...

The IPng WG is working to clarify multihoming, which seems to point to
more interest in multiple addresses per interface.

Unless I've got this totally wrong (and I'm sure I'll be corrected if I
have it wrong), the questions regarding multiple IP addresses and
releasable resources are really parts of an overriding question: "Can
a client request parts of a configuration, or does a DHCP server reserve
and return a "configuration" for a client which contains IP address(es)
as well as other parameters, and that "configuration" is treated as a
black box by the client and the server?

Scenario A: Black box.

Server is configured with groupings of parameters which include IP
address(es) through server policy mechanisms. The combination of these
items is treated as one item by DHCP.

Scenario A ramifications:

Clients are really simple, since they simply request a "configuration" for
their link-local + prefix. There is no 'C' bit required for Solicit or
Request. Release refers to the client's "configuration" as defined by
the network administrator. A client might request an additional
"configuration" for an interface by specifying a different link-local
address w/ the same prefix (a'la DHCPv4). Reconfiguration refers to the
entire "configuration", not a subset of it. Thus, the concept of a
Reconfigure which contains all of the data in a "configuration" would
never be multicast, since it refers to data for specific link local
address(es) + prefix(es). Thus, one could argue that Reconfigures
containing data would never occur, and thus Reconfigure becomes
Reconfigure_init (which instructs the client to perform a Request/Reply
exchange with the server).

Note that if any of the data contained within a "black box" is changed,
then the server would need to generate Reconfigure message(s) to cause
the clients to resynchronize with the server.

Scenario B: Individual extensions

This scenario reflects the protocol as currently defined. Clients can
request individual extensions (how? no parameter request list extension)
which could include one or more IP address extensions. Assume for this
discussion that the protocol has been changed to include the following
change which I proposed as part of "List of DHCPv6 Issues with
responses, part 2 of 2": Advertise messages include IP address
extensions with Prefix (S bit set) specifications advertising which
prefixes are available and have IP addresses for assignment. The client
forms a Request which requests one or more IP addresses (which contain
Prefix specifications from the Advertisements) of the scope necessary.
Also included by the server are extensions configured (site policy)
which are informational in nature. Those extensions which identify
releasable resources (by a bit in the extension) are so marked. A
client can release all releasable resources if it develops amnesia by
generating Solicit/Requests with the C bit set. A client can release
certain releasable resources by including their extension(s) in
a Release. If a client wants to release all resources, it may generate a
Release with no extensions. A server can Reconfigure a client by generating a
RECONFIGURE message which will contain any combination of releasable or
informational extensions, to which a client would respond with a
RECONFIGURE_REPLY. For example, if a site changed the IP address of the
DNS server, the DHCP server could multicast out a RECONFIGURE with just
the extension for the DNS server with the new value to the clients.
Releasable resources would need to be Reconfigured by unicast
RECONFIGUREs or by Multicast RECONFIGURE_INITs, which would cause the
clients to perform the Request/Reply transaction with the server.

Scenario B ramifications:

Deciding whether or not to generate RECONFIGURE* messages in this
scenario is more difficult than Scenario A.

DISCUSSION:

The question to the WG is whether the additional complication of
the protocol described in Scenario B is worth the additional features
over and above what is possible with Scenario A.

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

---

From: Thomas Narten <[email-masked]>
Date: Wed, 17 Nov 1999 12:38:53 -0500 (EST)

> service on different IP addresses (X.X.X.X.25)...

This approach would certainly also be available for DHCPv6. I.e., use
different link-local addresses when additional addresses are
needed. This has the advantage that it doesn't require the basic
DHCPv6 protocol to deal with the multiple sets of addresses problem,
yet doesn't rule out doing this sometime later if applications find it
useful.

> more interest in multiple addresses per interface.

The ongoing multihoming work should have no impact on DHCP that I can
see at present. The existing v6 model is that a multihomed site has
multiple prefixes. This is supported by the existing stateless
addrconf (i.e., no protocol changes are needed) and is also supported
by the "basic" DHCP model (called scenario A below) where the server
tells a client all of its prefixes.

I don't believe the ongoing multihoming work has any implications for
DHCP at present.

> black box by the client and the server?

I'm not sure the above captures the question completely. Regarding
whether a client requests part of a configuration: if a client is
allowed to ask for additional resources, that in effect means that the
configuration is dynamic and changes depending to what the client has
asked for. I.e., each time the client asks for more resources, the
configuration assigned to the client has changed.  Thus, another way
to characterize the difference is that in one model the server has a
configuration for the client (addresses and parameters) that is in
effect static (e.g., doesn't change unless the set of prefixes in the
site changes). In the other model the configuration is dynamic, with
the exact configuration changing over time depending on what the
client has requested.

> the clients to resynchronize with the server.

Another simplification of this model is that the binding cache (which
deals with retransmitted client requests) is no longer needed, as all
requests are idempotent. In model B (below) the server (and client in
the case of reconfigures) needs to distinguish a first request from
subsequent retransmissions and respond appropriately.

Thomas

---

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

Hello Mike,

> Mike Carney - SNT Internet Engineering wrote:
>
>         .........  the questions regarding multiple IP addresses and

Phrased this way, I think it is clear that some configuration
details should not be controlled so tightly by the server as to
preclude additional client interaction later in time.  The main
reason is that I think that some of the configuration needs for
a computer are controlled by the applications that are to be run
on that computer.  It may be impossible for the server to decide
which applications are likely to be run on a particular computer.
More to the point, I think it would be a terrible mistake to legislate
that servers always have to be configured by an administrator to
take care of all possible application configurations on all the
existing computing platforms in any sizable enterprise computing
environment.

Briefly, I believe that DHCP should let applications initiate
transactions as needed.

This should occur without requiring that applications be known
beforehand
and tightly bound to particular platforms.

Especially because there isn't any compelling reason for this overeager
form of rigid configuration.  The protocol has already been designed
to offer the appropriate amount of flexibility for creating applications
that can get configuration information as they need it.

The specific considerations for IP addresses, in this context, are
merely special cases of the same idea, but I will try to lay them
out separately in another note.

> request individual extensions (how? no parameter request list extension)

- A client should be able to request particular extensions by including
  those extensions in the DHCP request.
- No one ever asked for a "parameter request list" extension in all the
  years of discussion on the mailing list.  However, if there is general
  agreement that such an extension is needed, I don't see any technical
  barrier to putting it into the extensions draft.

> prefixes are available and have IP addresses for assignment.

I thought it would be a good idea for Router Advertisements to have
prefix information (even for managed links) and then DHCP clients would
know what prefixes they need IP addresses for.

After re-reading part of RFC 2462, I see that this is possible but not
mandatory.  Perhaps we should make it mandatory.

Regards,
Charlie P.

---

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

Thomas,

Only going to address your statements below as the issue you bring up
needs to be clarified.  I will address any issues from this mail in
other space in another mail thread.  

>subsequent retransmissions and respond appropriately.

The binding cache in DHCPv6 is there regardless of the model because as
DHCPv4, DHCPv6 needs to handle retransmission of requests.

To verify the request is a retransmit so we keep a cache as an
optimization to avoid a complete client database lookup.  We do not need
this because of the model.  

/jim

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 17 Nov 1999 20:15:49 -0500 (EST)

[Mike Carney]

> > black box by the client and the server?
[Charlie Perkins]

> that can get configuration information as they need it.
[Barr Hibbs]

Consider a RAS server.  It may not be started at the time a client requests
configuration data from a server, so if it is later started, the only means
for it to obtain the IP addresses it needs is to request them.  Requesting
multiple addresses in a single request message would be highly desirable.

As to the packaged configuration suggested by Mike as one interpretation of
the protocol behavior, let me observe that the v4 model works quite well,
permitting a client to request any option it wishes (or not), while a server
will deliver (without being asked to do so) the options specified by host
requirements, DHCP protocol, and/or local administrative site policy.  Since
it works well, why change the mechanism?

[Mike Carney]

> > request individual extensions (how? no parameter request list extension)
[Charlie Perkins]

>   barrier to putting it into the extensions draft.
[Barr Hibbs]

There are really two issues here:

(1) should a client be able to request multiple IP addresses (perhaps in
multiple requests)?

(2) should clients be able to request specific extensions at all?

A "yes" answer to either presupposes a mechanism to specify what is
requested, so a parameter request list is needed.

--Barr

---

From: Francis Dupont <[email-masked]>
Date: Wed, 17 Nov 1999 23:10:23 -0500 (EST)

In your previous mail you wrote:

=> I believe stateless prefixes (in router advertisements) will be a
subset of stateful prefixes (managed by DHCP) and in some case a
proper subset then DHCP clients could not rely on router advertisements
in order to know the list of prefixes.

=> to keep a stateless service will give a fallback in case of a
temporary failure of the stateful service then I agree we should
make the announce of at least one prefix with the largest scope
(ie. a global prefix in common cases) by router advertisements
mandatory.

Regards

[email-masked]

---

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

> in order to know the list of prefixes.

The proper subset relationship may be true, but can still be handled by
allowing clients to request IP addresses based on what is advertised.
If a request arrives from a network using an advertised prefix,
the server could just as well supply additional IP addresses from
prefixes that were not advertised in the same DHCP Reply message.

Regards,
Charlie P.

---

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

Thomas,

Just to make sure.  You don't have an issue with clients requesting
things it needs even after it has its addresses.  It does not all have
to happen with one transaction.  DHCPv4 supports this today too and all
client server apps I am aware of do too.  So maybe I missing your point
on this particular issue?

thanks
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 1999 03:54:26 -0500 (EST)

> it works well, why change the mechanism?

I've heard of interoperability problems in DHCPv4 since it isn't clear
what options the client need to explicitly ask for and what the server will
automatically provide. Thus a client might not need to ask for an option
for some server implementations but other server implementations might insist
on being asked to provide the option.

Isn't this something we should try to avoid in DHCPv6?

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Fri, 19 Nov 1999 08:02:39 -0500 (EST)

> on this particular issue?

I don't have an issue with this. I.e., it is fine for a client to
later ask for (say) an option requesting a list of its web proxies.

But that is a different question than the one about requesting
additional addresses.

Thomas

---

From: Charles Perkins <[email-masked]>
Date: Fri, 19 Nov 1999 17:08:09 -0500 (EST)

> Isn't this something we should try to avoid in DHCPv6?

This is a tricky problem!  On the one hand, we might specify a
list of extensions that servers MUST provide when first they create
a client binding.  Alternatively, we might specify that clients
have to include specific requests if they expect specific extensions
to come back in a DHCP Reply message.  The problem with the former
approach is that it is possible we don't know what extensions are
always needed.  Surely the NTP server isn't one of them.  I'd
guess that even DNS isn't always needed.  The problem with the latter
approach is that it makes the DHCP Request message more bulky,
especially
unwlcome when dealing with slow media.

What if we don't pick either method, but we also require that
clients MUST NOT depend upon server behavior in this matter?
Since IPv6 nodes using stateless address autoconfiguration are
still allowed to use DHCPv6 (say, to find DNS), I don't think we
can legislate server behavior, and therefore we have to leave it
to be a matter of local policy.  This tends towards making clients
be specific with their needs, unless local administration is careful
in establishing configuration information for its DHCP clients.
But, wireless speeds are going up, and the extra bulk is only present
in relatively rare control messages, so I guess it's better to lean
towards solutions that put more burden on the clients, unfortunately.

Regards,
Charlie P.

---

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

> clients MUST NOT depend upon server behavior in this matter?

We could do that but in practise this means picking "the client
must explicitly request all extensions it needs" since otherwise
some server might not automatically return something the client
has come to expect from some other server implementation/configuration.

The point is we will end up having to pick in any case. So why not
make the choice explicit and documented instead of something each
implementor has to figure out the hard way when there are interoperability
problems?

   Erik

---

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

Hello Erik,

> has come to expect from some other server implementation/configuration.

Not necessarily.  The downside of mandating that the client make
all requirements explicit, is a corresponding heavier load on
the DHCP Request, which might be sent over slow links.

Here is an alternative sequence:

- At bootup, client finds server address(es).
- Client sends DHCP Request.
- Server sends back all the extensions that are configured in the
  server database for that (class of) client
- Client wants some more extensions, so it asks for the ones
  it didn't get.

How does the client know which extensions it needs?  That depends
on the extension.  For instance, if the client needs DNS, it should
check during a later part of the bootup sequence whether DNS was
configured or not.  If the client needs a timeserver, the same answer
applies.  For many clients, these two items of information would
come automatically because the local administration has configured
their DHCP server that way.  Clients that perform no checking take
a certain amount of risk.  By way of analogy, I have seen programs
that do not check for errors after system calls.  The risk is that
these programs do not work in every circumstance.  We would like to
make it obvious how DHCP clients can work perfectly in every
circumstance.
Some clients might cut corners.  The risk is that those clients would
only work under certain conditions, and not in every circumstance.

Bottom line: we can make the protocol automatically fit every
circumstance by making it bulkier, or we can leave it slimmer by
requiring some design decisions to be made by the systems engineers
who build programs to use the protocol.

I am in favor of the latter in this case, since we can clearly
point out scenarios where the all-purpose cure is not needed and
adds substantially to the bandwidth burden for using the protocol.

> The point is we will end up having to pick in any case.

I hope that I have shown that this statement is not necessarily
true.

Regards,
Charlie P.

---

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

> The downside of mandating that the client make

How much heavier of a load can this create?  I think this is a
non-problem.  Furthermore, if you have the server send all the options
it has, that's almost certainly going to create a larger load than
having the client request all the options it needs.

> - Client wants some more extensions, so it asks for the ones

This seems like a reasonable solution to the problem of getting
information to applications.

> I hope that I have shown that this statement is not necessarily

In fact, in the case of DHCPv4, failing to specify exactly what the
server and client should do in this very situation _has_ resulted in
differing and mutually incompatible implementations.  We now have
deeply-entrenched (i.e., in boot PROM) implementations from some
vendors that don't behave the way other vendors assumed they would,
and we have interoperability problems as a result.  Specifying exactly
what should be done here is a really good idea, IMHO.

OTOH, I think it's fine to say "the client should either request
all the extensions it needs, in which case the server should send only
those extensions, or it should not request any extensions, and the
server will send those extensions it has been configured to send."

			       _MelloN_

---

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

Hello again Ted,

>> == me
>  == Ted

> having the client request all the options it needs.

The server should be configured to do the right thing.  I don't
think it should automatically send all of the options that it
possibly could send.  But it might well be configured to automatically
send a few obvious ones like DNS, and default router.

The question about how much additional load on DHCP requests
is an interesting problem, and I lean heavily towards minimizing
it.  I expect DHCP to be used for getting care-of addresses for
Mobile IP, for instance, on heavily bandwidth-constrained
cellular radio links, and I'd rather see such requests be
allowed to be as lean as possible.  Other applications for
embedded computers (with minimal PROMs, as you suggest elsewhere)
also indicate the need for caution when laying down new mandatory
features.

> what should be done here is a really good idea, IMHO.

I'm very much in agreement.  We should try to explicitly prohibit
any behavior that has led to problems in DHCPv4 implementations.
I'd rather do this by proscribing bad behavior than by mandating
new behaviors.

> server will send those extensions it has been configured to send."

Can't we have it so that the client can request a particular IP address,
and the server send down the DNS server name without being asked?

Regards,
Charlie P.

---

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

> possibly could send.

But how can you guarantee that a server with a heterogenous client
base can send the right options to all the clients?   This is a hard
problem, and the only way to really get it right is to use vendor
classing and require the person setting up the server (or the server
vendor!) to track what clients want what, and have different defaults
for each.   OTOH, the client vendor _knows_ what options the client
wants and/or can use.   From the perspective of efficient distribution
of labor, putting the onus on the client to say what it wants seems
much better than putting it on the server.

What the ISC server currently does for DHCPv4 is to specify a very
small list of options that will be returned to any client, regardless
of what the client asks for - for example, the message type, the lease
time, the server identifier, the offered IP address and subnet mask,
the default route, and the DNS server list.  If the client sends a
parameter request list, the server sends those options in addition to
the "standard" options.   If the client sends no parameter request list,
the server sends first the options that I mentioned above, and then
all other options it has available, up to the available space in the
packet.

I can see having a configuration parameter that enumerates the set of
options the server will always send, but in practice I think requiring
the server administrator to configure this correctly is just going to
create problems.   Many DHCP server administrators are not
particularly knowledgable, and while deploying solutions that require
them to be configure stuff like this is just going to create a lot of
support work for DHCP server vendors (i.e., I'm going to have to
answer a lot of "stupid" questions on the dhcp-server mailing list).

> I expect DHCP to be used for getting care-of addresses for
> allowed to be as lean as possible.

Yes, but this argues for having the client say what parameters it
wants, because the client's request list is going to be way shorter
than even one option the server sends that's not useful to the
client.   How does the server know what clients are mobile and what
aren't, and further, how does it know what options any particular
mobile client will find useful?

> Other applications for embedded computers (with minimal PROMs, as
> you suggest elsewhere) also indicate the need for caution when
> laying down new mandatory features.

The days of 16k eproms are pretty much behind us at this point.  I
think the extra 16 or so bytes this would add to the PROM isn't likely
to be an issue for any new device.  Seriously, the latest Nokia phone
has enough extra space in the ROM to put in Tetris!  I don't think you
can legitimately use this as a reason for making a decision about how
to specify what the client should send.

> I'd rather do this by proscribing bad behavior than by mandating

The problem is that the behaviour is unspecified, not that any
particular vendor is doing the wrong thing.  So people had to use
common sense to figure out what to do.  Unfortunately, different
people who I know personally and who are very sensible came up with
very different answers for what was common sense in this case.  I
would agree that we should not unreasonably limit flexibility, but we
must mandate specific behaviour to some degree, or the result will be
the same sorts of problems we've had with DHCPv4.

> and the server send down the DNS server name without being asked?

Sure, but what if the client doesn't want the DNS name?  A mobile
client doesn't need to know the DNS name of its temporary IP address,
does it?  Maybe it doesn't care!  Was the parameter request list
longer or shorter than the DNS name the server sent?

What about specifically enumerating some small set of options that
must always be sent from the server to the client (e.g., IP address,
lease duration, message type, and so on) and then allowing the client
to either send a parameter request list, in which case it will get
only those additional parameters (possibly none!) that it specified,
or to send no parameter request list, in which case it will get
whatever the server is configured to send by default?

			       _MelloN_

---

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

> - Client wants some more extensions, so it asks for the ones

I stand corrected - the above would work although it is a bit more complex than
the other two mechanisms.

Is this scheme something that everybody can live with?
If so we should document this issue and the above 
recommended solution in the draft.

   Erik