Subject: RE: Reasons for dynamic IPv6 address allocation for DHCPv6

From: Bernie Volz <[email-masked]>
Date: Wed, 30 Aug 2000 18:48:26 -0400

Charlie:

(I apologize in advance if this message violates the discussion rules.)

I believe we need to support both address allocation capabilities and I
don't believe the only time this information is needed is a boot time. And,
I agree that the lack of an API standard shouldn't preclude these
capabilities. The API will surely follow (perhaps requiring some time to
become standardized).

We do need to add these to our list of "Things I want to see in DHCPv6".

While allocation choice 1 sounds nice, it can be extremely wasteful (in
terms of allocatable resources). What if a client isn't receiving (or
properly processing server responses) and keeps re-requesting addresses.
Does that mean you want to allocate a new address for each request? Having
the server remember transaction ids to detect duplicates doesn't solve the
problem completely because the client could be crashing on receipt of the
server's responses and that would mean different ids will be used.

The questions really comes down to how does the server know what the
intentions of the client are? I haven't yet figured out how the current
DHCPv6 design communicates this (feel free to explain).

I do think that current DHCPv4 model is rather restrictive (generally one
address per "client"). I don't think this is appropriate longer term and for
IPv6.

One technique that could work, though it isn't optimum by any means, is to
use the bulking technique we're proposing for the Failover protocol. An
extension, such as the ip-address extension, is used as a boundary to mark
the data associated with each address. So, extensions that follow apply to
that address UNTIL another ip-address extension is encountered, in which
case the extensions that follow it apply to that new address.

Therefore, if a client wants to request three addresses is sends:
	... header ...
	ere extension (global)
	ip-address extension 1
	ere extension for address 1
	ip-address extension 2
	ere extension for address 2
	ip-address extension 3
	ere extension for address 3

When the server receives this request, is knows the client is requesting 3
addresses and either allocates all three or those that it can and returns
the results.

Now, the tricky part is what happens if the client wants a 4th address.

One solution (though not optimum as mentioned) is for the client to send 4
ip-address extensions with the first 3 containing essentially renewals for
those that it already has. The server then clearly understands that a 4th
address is desired and can return it.

Another option is to have a flag bit or different extension (or even message
type) that says "new address" instead of a duplicate allocation. You could
have a simple "REQUEST" message which gets the "base" resources. And you
could have a "REQUEST-MORE" message that says 'get me something new'. This
is a bit tricky because of lost messages and retransmissions so I'm not sure
it is as good as the early suggestion to use multiple instances of the
ip-address extension.

NOTE: The above multiple-address requests really only apply (for IPv6) when
an address on the same prefix is being requested. When different prefixes
are used (and if only one address per prefix is desired), multiple simple
requests work fine.

- Bernie Volz
  IPWorks, Inc

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, August 30, 2000 5:44 PM
To: DHCPv6 discussion list
Cc: [email-masked]; Jim Bound; Mike Carney
Subject: Reasons for dynamic IPv6 address allocation for DHCPv6

Hello folks,

Some people on the new DHCPv6 design team seem to be taking the
viewpoint that managed IPv6 computers are going to be like desktops.
>From that perspective, it's O.K. to revise the server's centralized
IP address allocation policy and reboot the IPv6 computer whenever
one needs a new IP address for some reason.  Perhaps an exception
will be made to allow network prefix renumbering to occur without
rebooting.

However, it seems quite likely that the future Internet will
have a lot of highly configurable and mobile devices, for which
the current static address configuration schemes being suggested
will be inadequate.

Some of the problem seems to stem from current preference of
configuring all necessary client parameters at reboot time.
What happens when the DHCPv6 client wants to run a synchronized
application, and the server didn't give out the timeserver extension
when the client rebooted?

Why do we have to frame all application requirements in terms of
what happens when the client reboots?

This was a design goal for DHCPv6 -- to avoid tying all application
needs to boot-time configuration.  I am afraid that we're going back to
boot-time constraints.  It's a dark place, not healthy for mobile nodes.

Regarding address allocation, the choices (as I understand them),
are as follows:

1) Each computer will get an IPv6 address whenever it asks for
   it.  If it asks twice, it will get two addresses.

2) Each computer will get the same list of IPv6 addresses no
   matter how often it asks.

I _think_ that the proponents of (2) will require editing the
server database before a DHCPv6 client could get another (new) 
address.  This is being suggested as a matter of "simplicity".

As a strong proponent of (1), and by the way as a strong proponent
of highly reconfigurable embedded devices, I find this is a big 
step backwards from the existing DHCPv6 specification.

Please note that any installation which favors (2) can trivially
implement the appropriate policy even in the existing DHCPv6
specification.  The discussion is not whether (2) is a useful
model for network administration.  No one disputes that (2)
should be enabled by DHCPv6.  No, instead, the discussion is
whether (1) should even be allowed at all.  The proponents of
the supposed (in my opinion quite illusory) gain in simplicity
wish to control address allocation policy to the extent that  
that DHCPv6 clients can never deviate from the pre-ordained
list of addresses.  Perhaps it will be "allowed" for clients
to spoof new identities by representing themselves using new
client identifiers. 

I offer a possible look at future address allocation policy. 
This is, of course, speculative, given that we have not
evolved into the world of plentiful IPv6 addresses yet.

First, I point out that anonymous addresses should (typically)
be acquired and used once, by a single application, and not 
necessarily used again.  Any policy by which a host computer
is allocated a list of "anonymous addresses" by a DHCPv6 server,
and gets the same list over and over again, is slightly cracked,
again in my opinion.  Designing a whole new DHCPv6 address allocation
protocol for anonymous addresses certainly argues against any
supposed gain in "simplicity".  I think it is very likely that
anonymous addresses on administered links have to be requested by
the application at the time of execution, and not preallocated.
Furthermore, any such address should be returned once it has  
been used (thus it is a "releasable resource"), or else requested
with a short lifetime.

DHCPv6 will likely be used to provide IPv6 care-of addresses on
administered links.  A mobile node may need to get a care-of
address for each of its IPv6 home addresses, but we do not know
enough to suppose that it always has to get a care-of address
for each of its home addresses.  It may use the same care-of 
address for more than one home address, or it may not.  Sometimes
it will want to get a care-of address for only one of its addresses,
or two, or four, even if it might have 10 home addresses.  For
such a node to be constrained _by DHCPv6 protocol_ to always  
getting all of its care-of addresses from the server is highly
suspect, and (worse) may imply some sort of preconfiguration
of each mobile device at the DHCPv6 server.

These are examples that are known today.  In the future, there
will be more.  I almost hate to go into description, because 
after all the strife in DHCPv6 it could be I will be attacked as
a dreamer who just does not understand existing practice.  But 
damn the torpedoes and here I go.  We do not _know_ all the ways
that IPv6 addresses will be used.

During this discussion, please keep in mind that future applications
should be able to be dynamically loaded onto a host computer at any
time.  While many computers may not support such features, many
other computers will.  We should not have to design _two_ protocols
for the different kinds of computers that use IPv6 addresses.

I believe that IPv6 addresses will continue to embody a certain  
amount of context and identity (on behalf of the user).  Thus,
if an application wishes to create a separate context and avoid
association with another application running on the same network
node, the most natural thing will be for that application to  
configure a new IPv6 address.  If the link is a managed link, then
DHCPv6 has to provide for that.

Each new (or sporadically used) identity may have special features:
- security profile
- QoS 
- special routing requirements (e.g. routing header)
- remote profile management 
- separate billing

It's not the job of the network layer feature configuration
architect to limit these future choices.

Thus, I claim that the direction, which has been very strongly
encouraged by several DHCPv4 experts, towards eliminating IPv6
address configuration flexibility, is wrong.  I hope that this
note to the IPng working group will serve to raise the level of
discussion so that the impending disaster can be averted.

Lastly, I will mention that we can't tell the applications exactly
how they ought to call DHCPv6 in order to get new addresses,
because no one has yet designed the API.  However, it would
take a lot longer to get the API right, judging from the history
of other APIs in the IPng group.  That should not be a precondition
for getting the protocol ready for initial deployment.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 Aug 2000 16:16:01 -0700

Hello Bernie,

Thanks for your note.  Since I won't be there tomorrow, I will
have to assume that technical discussion is a legitimate use for
IETF mailing lists :-)

> server's responses and that would mean different ids will be used.

The server should keep track of all resources allocated per client,
and it's able to identify its clients by (relay_address + lower client bits).
If a client is crashing a lot, it should set the 'C' bit for each crash :-)
If it doesn't do that, the server should probably enforce an upper limit
on how many addresses to allocate.  If the client fakes new interface
identifiers each time, then I don't know what to do except track it
down and administer many lashes with a wet noodle.  Or you might
use a user class identifier and require an authentication extension.

> DHCPv6 design communicates this (feel free to explain).

I'll try, but please forgive me if I miss the point.
- If a client asks for a new address, it should get one (within the
  limitations observed above)
- If a client asks for an existing address, it should get a
  renewal.

> addresses and either allocates all three or those that it can and returns

But it _could_ know that even if there were just 3 IP address extensions.

> Now, the tricky part is what happens if the client wants a 4th address.

It could just send another IP address extension.  I don't think it
has to include the previous IP addresses.  Why would it?

Somehow, I am thinking I didn't get the whole point of
your question.  Can you expand a little bit more?

Regards,
Charlie P.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Aug 2000 17:22:01 -0700

> Now, the tricky part is what happens if the client wants a 4th address.

This isn't tricky.   All you need is to identify each address.   So
have the client send a client identifier, and an different address
index for each address request.   If it gets three addresses and later
wants a fourth, it uses a new address index to get that one.   I would
suggest that if you want to clump addresses, you should define a clump
option that encapsulates an entire packet, or something like that,
rather than doing a special case on the ip address option.   This
avoids the artificial imposition of an ordering on how the options
need to be laid out.

			       _MelloN_