Subject: Reasons for dynamic IPv6 address allocation for DHCPv6

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

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: Jim Bound <[email-masked]>
Date: Wed, 30 Aug 2000 18:34:59 -0400

Charlie,

Reference Point:
--------------------------------
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.
---------------------------------

As you already know and for the record I fully agree with all your
"technical analysis" and also am a proponent of #1.   You have also clearly
articulated the reasoning why a different direction was selected in this
instance than DHCPv4.

Also what is very important architecturally as you stated, nothing in
dhcpv6 prevents #2 at all.

That being said it is also imperative we ship a spec by San Diego
meeting that many implementors feel comfortable writing code to and
showing up at our bake-offs at with running code in 2001.  Hats
off also to Francis Dupont and his team who have implemented this code
and that should be a positive light and message to this community as
Francis is one of our lead implementors for IPv6 for many years.

Also as editor, implementor, and WG member for the IPv6 base API we all know
APIs don't get done fast when you try to cover the future (e.g. Scoping,
Anycast Effect) and to hold up any protocol for an API is just plain bad
engineering trade-off judgement.  We need to build the protocol and the
API will come.  Or look at the IPv6 Advanced API that is taking some
time too.  Not only that but wearing my product engineer hat it is very
bad when you keep changing the API in an emerging market which we have done
in IPv6 and we have mail from ISVs now that told us either stop or we
give up on IPv6.  So premature APIs are very dangerous in the market
too.  

I think your mail should be part of the input to tomorrow's design interim
meeting which I have the highest hopes for thorough and par excellence
technical and architectural discussion will take place.  Ralph Droms has
done a good job putting together the agenda and is still collecting
input and also the DHCPv4 implementors are reading the drafts.  This is
all goodness for IPv6 as I think many are totally convinced now that
Stateless is not the only Plug N Play solution for IPv6 the market will
want and need and my favorite metric "pay for".  That in of itself has been 
a long hard battle in addition to building the protocol.  

I think it a good technical challenge to DHCPv6 for the folks who have 
lived with DHCPv4 implementations on the street, built them, or taught and
configured them to ask the basic question of dhcpv6, why does the
protocol leave any of the models inherent to DHCPv4.

Also this protocol cannot be driven only by client/sever computing as
was DHCPv4.  I will not restate what you said so well but IPv6 and the
Internet are about a lot more than client desktops, servers, and routers
but about the Internet networking fabric that has evolved beyond any of the
Pioneers expectations.  DHCPv6 technically has to be extensibile and
support the future needs of Mobile and Wireless devices where ever they
may roam :-----).

Talk to you at the meeting tomorrow.

regards,
/jim