Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 6 Sep 2000 21:14:07 -0400

Ted:

Let's step back a moment. I've been thinking in IPv4 terms when DHCPv6 is
really dealing with IPv6 terms.

Addresses have lifetimes, not lease times. Lifetimes are 32-bit values, in
seconds. They actually have two lifetimes - valid and preferred.

In IPv6 Router Advertisements, each prefix has a lifetime (RFC 2461, 4.6.2.
Prefix Information).

Therefore, why would not each address have a lifetime? And, this lifetime
could easily be different.

Also, a case in point (from the DHCPv6 Extensions draft):
         To perform renumbering, the server will include two IP address
         extensions, one to reduce the preferred and valid lifetimes
         for the old address, and another to give the client its new
         address.

Looking into the IPv6 documents brings up some interesting issues:
- How do the DHCPv6 lifetimes interact with the Router Advertisements
lifetimes? Routers will likely be advertising these prefixes with the 'A'
bit clear. I think the DHCPv6 draft should provide some guidelines for
clients.
- Is a multicast RECONFIGURE request really required? The Router
Advertisements might do the job as they would "deprecate" the address and
force clients to renew (if they must honor Router Advertisements).
[Jim/Mike/Charlie - Sorry if you've already addressed these issues in the
DHCPv6 drafts, but I was unable to find the sections.]

I'd suggest that clients honor Router Advertisements and use the lesser of
Router Advertisement and DHCPv6 lifetimes. But this likely requires some
integration between the DHCPv6 client and the IPv6 stack (client needs to be
passed and parse Router Advertisements or some signalling mechanism). [Sorry
for adding complexity.]

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, September 06, 2000 6:51 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

> I think this is just a difference of how you treat the data. I don't see
why
> allowing individual renewals is such a big deal - the DHCP server can find
> the addresses either by looking for the requested addres. For renewals,
that
> seems most efficient for me.

If you provide a mechanism for allowing the client to renew individual
portions of the set of addresses provided for an identity association,
it complicates both the specification and the implementation.  The
server has to implement the case where it returns all the addresses
for an identity association.  Now you want to have a special case
where it returns some subset of that.  Why?  What does this buy us?
When are you going to have expiry times that vary in this way?

I would expect that the only time you'd give addresses different
expiry times would be when one or more addresses are deprecated -
those might expire early.  But you can't renew them - when they
expire, that's it - you're done with them.  So providing a mechanism
like this doesn't make any sense to me.  Can you come up with a
practical reason why we would want such a mechanism?

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 02:48:58 -0400

Bernie,

>really dealing with IPv6 terms.

This is an important mind set for dhcpv6.

>seconds. They actually have two lifetimes - valid and preferred.

yes we need to not think in the same lease terms as dhcpv4 but as you
state above I said this in earlier thread.

>could easily be different.

This was my input to Ted.  In fact IPv6 does encourage admins to give ou
different times for different prefixes.  They may know that the first
prefix to a client who can have 3 addresses will expire before the other
too and reduce the preferred lifetime.

As I said if an admin does this dhcpv6 should not require the entire
addresses set to be renewed because the earlier address has become
deprecated and about to expire.

>         for the old address, and another to give the client its new

Also what we wanted to do to support the notion of T1 and T2 in dhcpv4
was state that when your address is 80% till it becomes deprecated (the
preferred timer goes off) renew the address or ask for a new one.

In the model Ted is proposing all the client can do is renew the address
or request a new set.

But in IPv6 it is permissable to have addresses expire at different
times.

>bit clear. I think the DHCPv6 draft should provide some guidelines for

They must coexist.  We have to do duplicate address detection for dhcpv6
addresses just like we do for stateless addresses.  This will prevent
collisions.

Implementor Note - What I would do is put the dhcpv6 addresses on the
same if6_net list that the stateless are on and mark them as dhcpv6
begotten.

>DHCPv6 drafts, but I was unable to find the sections.]

Assume the customer is not running stateless or only to tell the clients
go use dhcpv6.  The admin does not want stateless sending out any
prefixes?  

Stateless does not need reconfigure archtype  Router is on the link and
advertisements rule.

>passed and parse Router Advertisements or some signalling mechanism). [Sorry

Yes stateless rules for a prefix.  If a network permits this they should
have good reason.  One good reason would be use dhcpv6 to give out
addresses using prefixes as stateless does but use stateless router
advertisements to force renumbering by reducing valid and preferred
lifetimes for all addresses.  Thats why I will mark the ipv6 addresses
on the if6_net as stateful or stateless.  If Rtr adv reduces lifetimes I
will know this and be able to either release the address or renew it.
Another reason to permit individual renewals because one prefix may get
renumbered and the others are fine.

The bottom line is once you permit a client to have mulitple addresses
for an identifier though finite and fixed they must be individually
renewable and updated per IPv6 architecture and stateless addrconf.

The good news is that stateless or stateful are NOT permitted to send a
zero valid lifetime to kill and address it must be not less than 2
minutes.  This was added to stateless rfc2462.txt to prevent DOS attacks
from shooting IPv6 nodes in the head with rtr advs. 

regards,
/jim