Subject: DHCPv6 address allocation model

From: Thomas Narten <[email-masked]>
Date: Mon, 23 Aug 1999 11:40:49 -0400 (EDT)

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 applications.

   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