Subject: DHCPv6 issues status

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Thu, 16 Dec 1999 11:19:39 -0500 (EST)

Hi folks,

The DHCPv6 ID authors (Jim Bound, Charlie Perkins, and myself) meet on
a weekly basis to discuss open issues and the great input we've been
getting from the WG. Thanks much for taking the time to contribute. We
really appreciate it. The following information is based in a large part
on your participation.

Status Update:
==============

1) General Releasable resources

Based upon input from the WG, we've decided to defer the support of
general releasable resources until a later time. We believe we've
uncovered the many if not all of the issues related to general support,
and feel we have a good handle on how the protocol could support such
resources. Later, when the IETF community identifies more releasable
resources, we will revisit this issue. Meanwhile, we would like to
reserve the last 8k options (57344-65535) for assignment of extensions
for dealing with releasable resources.

2) Multiple Addresses, Multiple servers

We feel we've solved the issues of support for multiple addresses (of
different prefixes) and multiple servers. Please read the following
and let us know if you agree.

Acronyms:
=========

ERE	-	Extension Request Extension

General:
========

We started the discussion by talking about scenarios where multiple IP
addresses are consumed, and how the protocol would work in such
environments.

Can we handle many global and/or site prefixes assigned to a link?
==================================================================

Yes. We need a method by which a client can discover what prefixes are
available on the link. This is done as follows:

	- Sophisticated clients MAY include a ERE in their Solicit which
	  requests that servers advertise their prefixes [a].  Servers
	  receiving an ERE with the prefix request will advertise
	  available prefixes on the client's link by including IP
	  address extensions for each prefix, which contains the network
	  address and prefix size (subscriber ID is zero).

	- Since solicits may generate more than one advertisement
	  (multiple servers), a Solicit ID provided in the Solicit (and
	  echoed back in the Advertisement) is used to link
	  advertisements to their solicitations [b].

	- Simple clients do not include the prefix request ERE, and thus
	  only care to get *some* set of one or more IP addresses
	  returned by the server. They make the number of IP addresses
	  known by including empty IP address extensions in their DHCP
	  request.

	- Relay agents forward traffic to remote DHCP servers. DHCP
	  servers have been configured with the mappings from the Relay
	  agent's prefix to available prefixes [c].

	- A client includes the IP address extensions from the
	  advertisement in the Request to signal to the server what
	  flavor IP address(es) it would like.

Requesting additional addresses
===============================

New requests for addresses are differentiated through the use of the XID
cache implemented on the server. A different XID means a new request.
The same means a retransmission. We understand that there is a window
where the XID cache entry may timeout and the server may allocate
additional IP addresses to the client. We manage that problem by
specifying that the XID TIMEOUT be 3 hours by default. We suggest
that somewhat short lifetimes be specified such that IP addresses
allocated which the client does not know about are reclaimed in a
timely fashion. If after this draft goes to PS, and we (WG) find that
this problem proves to be more of a problem than we anticipated, we
will revisit this issue.

3) Router Advertisements

There has been some traffic on the list wondering whether having a
single 'M' bit in the header in router advertisements provided enough
granularity, or whether their should be an 'M' bit in the individual
prefixes. In other words, there may be some problems in environments
where stateless and stateful config are combined. Some folks suggested
that multiple router advertisements would be sent, some for stateless,
others for stateful.

We felt that this issue just wasn't a problem, so long as the stateless
and stateful client implementations operate independently from one
another.

4) Reconfigure/Renumbering

We talked about whether or not we should have a renumbering section in
the appendix. (Yes). We also talked about reconfigure, and whether we
need both schemes or whether we could discard one of them. We've
identified additional semantics of RECONFIGURE, which we'll present in a
separate E-mail message.

5) Authentication

We felt that people calling into question whether or not our
authentication model is adequate given the progress made with DHCPv4
authentication need to raise specific points regarding potential
defects in our specification. Our response is that it is up to those
people to point out the defects to the WG, as we see our model as
having been validated before. "I'm uncomfortable" isn't a helpful
comment - "I'm uncomfortable because of a, b, and c" *is*.

6) API interface for clients

I proposed an informational RFC which would describe an API which could
be used by applications to make requests to and retrieve data from a
DHCPv6 client. The other authors thought this was a good idea. What do
you think?

7) Multiple Interfaces, multiple choices for application layer extensions.

Erik raised a concern about how a client would present a coherent view
of the data returned from multiple interfaces when such data might
conflict. I suggested we use the method the Solaris DHCPv4 client uses
to resolve the conflict - the user picks a "primary" interface, and the
data associated with that interface is authoritative. I've heard no
comment for or against this proposal. Your input is welcomed.

Footnotes, etc
==============

	[a]	ERE needs specification

	[b]	The solicit ID needs specification. Perhaps 8 bits out
		of the reserved field could be used? Is 8 bits enough? A
		solict ID of 0 means that client doesn't match
		advertisements to solicits.

	[c]	This "mapping" seems rather nasty. I'm wondering if we
		should make network administrator's life easier by
		having the relay agent enumerate all of the prefixes
		available on the client's link, rather than force the
		DHCP server administrator to configure this. I think we
		need to do this. Comments?

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 19 Dec 1999 23:37:30 -0800 (PST)

> 	  known by including empty IP address extensions in their DHCP

Do you have a proposal that can carry these different types of semantics:
 - Client want's no addresses at all (got them from stateless already)
 - Client want's all addresses (using the "default" prefixes) that the
   server hands out
 - Client wants N addresses (even if the server by default hands out M which
   could be more or less than N)

   Erik

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Dec 1999 11:14:48 -0500

> and let us know if you agree.

Re: multiple addresses. I posted a note to the dhcpv6 list back in
august (appended below). Does your solution solve all the points
mentioned in it? Indeed, has the solution been explained to the WG
yet?

Thomas

From: Thomas Narten <[email-masked]>
To: [email-masked]
Date: Sat, 21 Aug 1999 08:20:10 -0400
Subject: DHCPv6 address allocation model

One of the questions I've had in the back of my mind for a while is
how does one use DHCPv6 to renumber a site. This may seem like a silly
and obvious question, but I'm actually quite serious. To summarize, I
believe there are a lot of ambiguities and unspecified details
relating to the new DHCPv6 semantics, where a client is allowed to ask
for additional addresses. In the following, I describe a number of
concrete scenarios where I am not sure how the protocol is supposed to
work and what the spec calls for. 

Background:

Using stateless address autoconfiguration, the system administrator
controls the prefixes that routers advertise via RAs. Hosts
autoconfigure addresses from the prefixes in RAs. A host generates
exactly one address for each prefix. To renumber a site, the sys admin
adds a new prefix to the list sent out in RAs (which all the hosts
then generate an address for) and also deprecates the (now old) prefix
that has been advertised in use for some time, but now needs to be
phased out. Because hosts always generate exactly one address for each
advertised prefix, there is never any ambiguity as to which addresses
are actually in use, or how they are used.

DHCPv4 doesn't have the notion of muliple addresses per client.
However, it does have the model that the client asks for its
resources, and the server returns them. If the client asks again, it
gets the same answer again. The v6 counterpart of DHCPv4 that would
retain this model (but incorporate v6's multiple address model) would
simply have the server return ALL the addresses a client is supposed
to have (i.e., addresses from the same set of prefixes the RAs would
be advertising). If a client asked for addresses three different
times, it would always get the same answer.

With DHCPv6 (as currently defined), however, the address assignment
model is quite different. Specifically, a server doesn't simply
respond saying "here are ALL of your addresses." If a client asks for
addresses (and the server returns some), and then later asks for more,
the server will return more (i.e., different ones in addition to those
it has already handed out). The motivation for this model (from what I
understand) is to allow individual applications to have their own
addresses.  This new model leads to a number of details that I don't
think are covered in the current spec. The following gives concrete
examples where there are gaps in the current spec, and where I'm not
sure how things are actually supposed to work.

1) In a request, the client must specifically ask for an address (via
an address extension). When it requests an address, how many does the
server return? The text doesn't seem to say, and in fact says:

> 3.2.2. Receiving a DHCP Request with the IP Address Extension
> 
>    When a server receives a request for an IP address, it consults its
>    allocation tables and determines an IP address appropriate for the
>    requesting client and the link to which the client is attached.

note "determines an IP address", i.e., just one.

2) Now, the above wording could of course be tweaked to say "one or
more ...". Let's assume that the above wording is changed and that a
site has 2 prefixes (for two ISPs), and the DHCP server is allowed to
return two addresses in response to the request for an address. No
problem.

But what if the client actually requests two addresses (by including
two address extensions in the request)? How many addresses does the
server return? Which ones?

It could return 2, but that may be incorrect. If the two requests
(i.e., two address extensions included in the request) were for two
different uses, shouldn't the server return 4? Two addresses from each
ISP prefix?

If the server returns 4, what will the client do with those four
addresses? It asked for 2, but got 4. Does it assume the first two
should be associated with the first requested address, while the
latter two belong to the second request? Or does it assume the first
address goes with the first request, the remaining addresses go with
the last request? What if the server returns the 4 addresses in the
different order than the client expects them to be grouped (i.e., the
first two addresses for ISP 1, the last two for ISP 2)?  The point
here is that there are quite a lot of unspecified details in how this
will work. If the client and server have different assumptions, the
wrong thing might happen and we won't have interoperability.

3) DHCPv4 and IPv6's stateless address autoconfiguration have an
assumption that the sys admin knows how many addresses a host
needs. The model is the client can ask for its addresses, and the
server (DHCPv4 server or router sending RAs) always responds giving it
all of the addresses its supposed to use.

The current DHCPv6 model has the client requesting one or more
addresses. But this begs a fundamental question. How does a client
know how many addresses it should ask for? A client generally doesn't
know how many ISPs it has connections through (and there is no defined
mechanism in IPv6 today for a client to find out) so how can it
sensibly be expected to know how many to ask for?

Indeed, how can it ask indicate *which* type of address it wants?  For
example, how would it indicate that it wants two addresses and that
the two addresses to come from two different ISP prefixes?

Another way of stating the issue is that DHCP is intended for
configuring clients. That is, the client is assumed to need
configuring. But if the client is expected to ask the server for
individual addresses, it needs to know what types of addresses to ask
for (e.g., global scope or site-local?, which ISP prefixes, etc.) But
this type of information is normally managed by the centralized DHCP
server. The client doesn't (and shouldn't) need to know these sorts of
things in order to use DHCP. DHCP's primary benefit comes when clients
are dumb, so to speak. For example, when a new machine plugs into the
network the first time, it should be able to use DHCP and just have
things work, without requiring advance configuration of the client.

4) Suppose a site has two prefixes for ISPA and ISPB. A client has
requested and received addresses for both prefixes (i.e., ADDR-A and
ADDR-B). Suppose now that the client sends in a Request to renew
address ADDR-A (the address for ISPA), but doesn't include ADDR-B in
the request. What does the server return? Just an address for ADDR-A
with a new lifetime?  Should it also return an address corresponding
to ISPB? In case 1) above, the answer was yes. But in this case,
returning an additional address from ISPB's prefix gets
complicated. Should it return the same ADDR-B it returned earlier
(that the client is using, but didn't include in an extension in the
Request message). Should the server return ADDR-BPRIME, an address for
ISPB but different from ADDR-B? I'm not sure there is a "right" answer
here. The right answer depends on how the client intends to use the
returned addresses.

5) Suppose a site has one prefix for ISPA, but decides it wants to add
a new one for a new ISP connection (ISPB). If a client had asked for
one address, this wouldn't be too big of a problem. The server could
send a reconfigure, the client would send a Request, and the Reply
could contain both the old address and the new one.

But suppose further that a client has requested and received 2
separate addresses already (both addresses are on prefix ISPA). The
server can send a reconfigure for both addresses, and the client then
responds with a Request for those two addresses. But now we have the
problem described earlier about how many prefixes get returned, which
ones, and what does a client do with them.

6) Suppose a client asks for 4 addresses (two each from ISP prefixes
ISPA and ISPB) but gets back only 2 because the prefix from ISPA is no
longer valid. What are semantics?

In summary, I think there are a number of technical problems with the
current definition of address allocation. I believe that they all stem
from the extended allocation model that is new to DHCPv6. No doubt,
they can all be fixed in the protocol, but I continue to wonder
whether the effort is worth while. The WG should consider:

1) what are the benefits of the new model, and do the benefits justify
   the complexity they add.

   My understanding is that the main benefit is that it allows
   individual applications to request addresses for their own
   use. I.e., so I can have (say) multiple web server processes, each
   using their own address that is presumably not shared with any
   other rapplications.

   My sense also is that there is no concrete example that calls for
   this problem to be solved via DHCP.

   It also appears that the new allocation model has introduced
   complexity to the protocol (relative to DHCPv4) that stems directly
   from the new model. Specifically:

   - 'C' bit is needed so that the a client has a way to tell the
     server to throw away previous allocations. This is needed because
     the client can forget (i.e., via system restart) what resources
     have been assigned to it, and the server has no way of
     determining whether a client is still using a resource. The 'C'
     bit opens up a denial of service attack not present in DHCPv4.
     
   - the requirement that the  server  cache responses and respond to
     retransmissions from its cache for certain time periods. Unlike
     DHCPv4, DHCPv6 requests are not idempotent.

   - Additional complexity will likely be needed to address  some
     of the issues outlined above.

2) What additional pieces are also needed in order take advantage of
   the new facilities. I believe that there is additional stuff that
   needs to be done. For example, an API would probably be needed that
   allowed applications to interact with DHCP to request addresses,
   and also that would allow DHCP to interact with an application. For
   example, if an application wants to get an address for its own use,
   it needs to ask the local DHCP entity to obtain one. Likewise, if
   the DHCP server sends out a RECONFIGURE, and that reconfigure
   corresponds to a particular address being used by one particular
   application, there would need to be system hooks (e.g., via the
   API) that allowed the client DHCP process to inform the application
   that the address it was using has changed, a new one has been
   assigned, etc. Because RECONFIGUREs can arrive at any time, the API
   would probably need some sort of asynchronous notification
   facility. (I.e, an application would need to poll or DHCP would
   need do upcalls.)

   Is there agreement that such an API required in order to take
   advantage of these facilities? Does anyone have any plans to write
   one or think that they might in the future?

3) In the case where a client needs to do specialized things (like
   host multiple servers), another argument is that that DHCP provides
   only limited benefits. I.e., such environments will require that
   individual clients be hand-configured anyway, in which case
   configuring the address-specific stuff might make sense anyway (and
   wouldn't be a significant burden), and the incremental benefit of
   using DHCP might be quite small.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Dec 1999 11:30:22 -0500

> and let us know if you agree.

I'd like to be sure we understand what is meant by "multiple servers".
The description supplied in your note seems to cover the case where
there are multiple servers, and the client wants to pick the one of
them for interacting with, i.e., to get all of its parameters from
that one. The current draft already handles this, and the rest of your
note is consistent with that I believe.

But there were also some other thoughts expressed on the about what
"multiple servers" means. There are (at least) two cases. In the first
case, the client has two interfaces and thus runs DHCP on both of
them. Your proposed solution addresses this case. In this case, it is
assumed that the client must run two instances of DHCP with (possibly)
different servers. But the assumption here is that the client gets
information from both sources, and accepts the union of the
information. The fact that it is interacting with two DHCP servers is
an artifact of the the fact that it has two interfaces. No changes to
the DHCP protocol/model are needed to handle this.

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

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Dec 1999 11:39:23 -0500

> comment - "I'm uncomfortable because of a, b, and c" *is*.

I'm surprised at this response. The current v4 authentication work is
the result of a lot of effort from folks that really are interested in
making authentication of DHCPv4 work and be deployable in practice.
While I agree that it is desirable for those folks to provide input to
the DHCPv6 effort, this group needs to be proactive in looking at that
work and extracting the relevant parts. Placing the burden on others
to point out what's wrong with the current mechanism is a cop out.

Also, while the current DHCPv6 authentication model may have been
validated in the past, much of the v4 authentication work has taken
place since then. The world has changed, and this effort needs to be
in sync with those changes.

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Dec 1999 08:53:52 -0800

> client decides it needs to interact with multiple servers, etc.

I do not see this.  If a client finds out about a DHCP server,
and sends a DHCP request, and gets a DHCP reply, then that client
has a consistent state with that DHCP server.

If somebody in the future can manage to devise a platform that can
realistically use multiple DHCP servers for a single network interface,
and the existing protocol does not suffer harm, why do we need to make
any specification about whether or not such a future platform does
such a thing?  Why do we need to specify how the client resolves
the answers?  Why do we need to explain the client's motivation?

As an example, if a client today goes out and interacts with multiple
timeservers, it isn't NTP's fault if something goes wrong!

If a client today goes out and dials up two RADIUS servers, it isn't
RADIUS's fault if something goes wrong on the client.

If a client today responds to multiple SNMP masters, it is not SNMP's
fault if something goes wrong.

If a client today gets mail from multiple IMAP servers, it is not IMAP's
fault if the client does the wrong thing.

I could go on and make a similar example out of every other protocol
today, probably...

Furthermore, we can't enforce any restriction on what the client might
do.  We don't have any realistic detection mechanism.  The best remedy
is to have reasonable DHCP server management.  Just as it is the best
remedy in every other server case.

Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Dec 1999 09:09:27 -0800

Thomas Narten wrote:

> I'm surprised at this response.  ...   Placing the burden on others

The current model for DHCPv6 validation has been through the ringer
for years in the context of Mobile IP.  No one has yet suggested that
it has significant flaws, at least not in any forum that I know of.
It may not be perfect, and it doesn't solve key distribution.

Specifying and adapting the use of a known good mechanism is not a
cop out, and I don't think you should portray it that way.  Given that
we have done a good job of specifying and adapting, then for us to ask
for specific comments is not a cop-out either.

Having said that, I do not disagree that studying the DHCPv4
authentication
mechanism would likely be worthwhile.  I just disagree with your cop-out
accusation.  Furthermore, it would be even more worthwhile to do further
research into authentication mechanisms.  It's all a matter of time and
effort.  I thought we had made a pretty good effort, short of trying
to hit a moving target.

Do you have a specific demand in mind from your perspective as AD?
Or, do you have a specific requirement in mind in your role as a
possible implementer of the protocol?

> in sync with those changes.

Can you mention a specific change that we should focus our awareness on?

Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 1999 18:10:23 +0100

I believe if we split client addresses in :
 - primary addresses, one per prefix, typically a primary address
   is the address a client could get when it uses stateless autoconf.
   Primary addresses are allocated by DHCPv6 servers (one set per client),
   common clients need only primary addresses.
 - secondary addresses which are explicitely needed by some special clients,
   they are extra-addresses (ie. the client has already a primary address for
   this prefix).
   My proposal: servers don't allocate secondary addresses, when a client
   wants a secondary address, it builds it and send a request to the server
   with a filled address extension in order to check if this address is
   available. All management actions should be initiated by the client
   (this removes most of problems of the DHCPv6 allocation model).

Happy new year

[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 30 Dec 1999 09:31:10 -0800

Hello Francis,

I understand the desire for simplicity in your proposal.
And, I also believe it is a reasonable policy for use by
typical system administrators.

However, I have generally thought that it was the job of
the protocol specification to create the mechanism, while
not constraining the policy.

Thus, I suggest that your policy be followed in the typical
case, but that the protocol specification allow for other
policies.  For instance, a network administrator may desire
to specify other address allocation strategies for particular
nodes, or for all nodes of a particular class, and so on.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Dec 1999 20:27:33 +0100

In your previous mail you wrote:

   
=> I agree. In a previous message I proposed to put this kind of things
in an application document like we have for routing protocols (by the
way we need a MIB document too). This has many advantages and can
make DHCPv6 specs easier to finish because documents of this kind are
informational only (in the case this will go in a separate document,
I think this is the best solution because current I-Ds are large enough).

Thanks

[email-masked]