Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Mon, 25 Sep 2000 06:59:51 -0400

Yes, as I understand it that is what was being proposed.

There may be cases where the renewal time could be larger than the preferred
lifetime, for example if the server isn't going to be renewing that address.
Perhaps the preferred is the same as the valid and is 2 hours (similar to
your stateless router advertisement examples where the address is going
away), and hence the renewal time could be longer than 2 hours. 

We do need to be careful to avoid a situation when an address is going away.
Suppose it is going away in 2 hours. If a new client gets a lease, if the
renewal time is set to 2 hours, it will renew in 1 hour. At that 1 hour
time, it will get a preferred of 1 hour. Client will renew in 30 minutes, it
gets renewal time of 30 minutes. Renews in 15 ...

So, we might state the renewal time as "In general, the renewal time of an
IA will be less than the smallest preferred lifetime of the non-depreciated
addresses in the IA." (Or something like that.)

- Bernie Volz

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Sunday, September 24, 2000 11:56 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

So the renewal time will always be less than the preferred lifetime for
a single address?

And the renewal time will always be less than the smallest preferred
lifetime for an address set provided by the server?

regards,
/jim

---

From: Bernie Volz <[email-masked]>
Date: Mon, 25 Sep 2000 07:57:11 -0400

Thomas:

The model I was proposing handles your situations. The DHCP server need NOT
supply the address in a renewal, but that does NOT mean that the client
should stop using that address. The client can continue to use that address
until the lifetime expires.

If the DHCP Server wants to stop the client from using the address 'now', it
can do that by supplying a small (or 0) lifetime in the renewal. (The
lifetime depends on what we'll allow the server to specify for lifetimes and
how secure the client feels about what it receives from the server).

The Server could use the following technique to remove an address:
- Signal client to reconfigure
- When client renews, send the address with a 0 lifetime

If an address (prefix) is otherwise removed from a DHCP server
configuration, the server would simply not include that address in future
replies to the client. However, the client has full rights to use that
address until the lifetime expires.

BTW: It would not surprise me that Router Advertisements will advertise
stateful prefixes (that was the design as there is a bit that specifies
whether a client can autoconfigure from that prefix). That is one reason why
I raised the issue early on that we need to be clear about how a client
should handle this in general. What if a DHCP Server says that preferred
lifetime is 20 hours and valid is 60 hours and Router Advertisements say 2
and 6 hours, respectively? Which should the client use? And depending on how
you chose, consider what happens if the renewal time is 10 hours.

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Monday, September 25, 2000 7:35 AM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

Ted Lemon <[email-masked]> writes:

> > Or, one can be silent (omit an address), but that *does* *not*
> > invalidate the address and cause the client to stop using it per
> > se. Rather, the client stops using an address when the addresses'
> > valid lifetime goes to zero.

> The way we have talked about this, the client remembers all its
> addresses, and the absence of one of these addresses in the response
> for an IA indicates that the client should stop using the address
> immediately.

One reason why the above semantics are perhaps not ideal concerns when
both stateless addrconf *and* DHCPv6 happen to be sending out
information about the same address. Sure, one can argue that this is a
misconfiguration, but it will happen sometimes, and the protocol needs
to define the correct behavior in that case. The addrconf spec says
that in all cases, whenever a node gets "new" information (either from
stateless addrconf or DHCP) that new information becomes definitive
and supercedes any information about that address received in the
past. Thus, a "new" DHCP update always overrides a previous stateless
addrconf advertisement and vice versa.  This choice was made to keep
things simple, as it removes corner cases having to do when deciding
whether to believe stateless over DHCP or vice versa.

For example, if an address is being advertised by both stateless and
DHCP, what happens if the DHCP server *omits* that address the next
time the client renews an IA? Should the client now assume the address
is no longer valid? But does it then also need to remember that it
learned that address via stateless addrconf, and shouldn't invalidate
it?

To me, it seems cleanest to say all addresses have explicit
lifetimes, and the only way to invalidate an address is:

1) have the lifetime go to zero (something the client does should it
   not receive an updated lifetime via DHCP or stateless addrconf)

2) Use DHCP or stateless addrconf to send an update with new lifetimes
   that force step 1) to happen more quickly in those cases where this
   is the desired outcome.

Here is specific scenario where the invalidate implicitely model may
result in incorrect behavior. Consider a misconfiguration where the
same address is being advertised via stateless and DHCP. Suppose the
sys admin determines the misconfiguration and attempts to correct it
by having address/prefix advertised only via statless. The sys admin
then updates the DHCP config file and on the next DHCP update, the
DHCP server omits the address at question. In this case, you do not
want the client to invalidate the address, as it is also being
advertised by stateless. But the client would have already forgotten
that information, unless it remembered the last router advertisement
(something that it is not required to do). If the DHCP semantics were
that an address becomes invalidated only when the lifetime reaches
zero, having DHCP stop advertising the prefix would not cause the
client (in this case) to improperly stop using and address. On the
other hand, if the DHCP semantics resulted in invalidating an address
through omission of the address, the client would invalidate the
address immediately, and it would not become valid again until it
received a new advertisement via stateless (this can take as long as
30 minutes, BTW).

Thomas

---

From: Bernie Volz <[email-masked]>
Date: Tue, 26 Sep 2000 12:55:18 -0400

In fact, with duplicate address detection and the huge address space, a
server maybe could even chose to not store any information about a client.
If the addresses are assigned by incrementing a counter or some such
mechansim, it would not need to really remember (except of course if we
didn't send the addresses in the RENEWAL request in which case it must).

I'm not arguing for server implemnetations to do this or even be allowed to
do it.

And this would really be more of the stateless addrconf instead of stateful
- except of course that a server could have a list of "allowed" clients and
only respond with addresses to those clients that were in that list.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, September 26, 2000 12:32 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

> Given the size of the v6 address space and the standard subnet size,
> I'd say that the probabilities are (or could be engineered to be) on
> the side of non-reuse.

Yup.   Sounds like stateless addrconf.

			       _MelloN_

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Sep 2000 20:54:37 -0700 (PDT)

Ralph,

> My thought was that specifying that the server send a complete list of only 
> the client's currently valid addresses was actually a simplification - the 
> client can simply throw out its old list of addresses and copy down the 
> current list from the server.
> 
> However, there is a second step - the client has to update the 
> configuration of its interfaces with the list of addresses from the 
> server.  So, I imagine simply omitting addresses makes the client's job a 
> little harder - it has to poke around at each of the interfaces and see if 
> any of the addresses on those interfaces were missing from the message and 
> must therefore be un-configured.

Agreed.
This is made a bit tricker by the fact that it should be possible to
use both stateless and DHCPv6 to configure addresses on a host at
the same time (section 4 in RFC 2462).
Thus the client should not touch any IP addresses that were configured 
through the stateful mechanism when doing the above un-configuration.

  Erik

> But, as Ted points out, requiring the server to specifically invalidate 
> addresses may make the server implementation more complex - the server will 
> have to remember each client's previous list of assigned addresses as well 
> as any newly assigned addresses until the client has renewed its IA.
> 
> - Ralph
>