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.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
