Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Sun, 24 Sep 2000 07:59:44 -0400

>So, that synchronization could be accomplished by
>requiring that the client send its version of the
>IA to the server, and the server could send back the
>changes - changing the lifetimes on some addresses,
>explicitly invalidating some addresses and adding new
>addresses.  That seems more complicated to me than the
>server simply sending the client the current, correct,
>complete IA.

I believe, though perhaps more complicated, that this will be required. Now,
it is a matter of discussion whether an "invalid" address in the client's
renewal is explicitly or implicitly invalidated - the server could send back
lifetimes of 0 or it could simply not return that address (the client then
would either invalidate the missing address or would keep using it until the
previously received lifetime expires). I think that we should allow the two
different behavoirs:
1. Server explicitly responds with 0 lifetimes to force the client to
invalidate the address immediately.
2. Server doesn't respond with the address (perhaps because it is no longer
or never was authoritative for that address) and the client is allowed to
continue using that address until the lifetime expires (since that's what
the original 'lease' give it in terms of 'rights'). Note that in this case,
the client MUST continue to send this address in any future renewals UNTIL
it has stopped using the address (lifetime expires).

I actually believe that #2 will have some value in mobility or similar
environments.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Friday, September 22, 2000 3:58 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

At 08:16 AM 9/22/00 -0400, Thomas Narten wrote:

>I think that the only way to force a client to "invalidate" or "stop
>using" an address is to explicitely tell it that it now has a zero
>valid lifetime. 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.

Can't we define explicitly define those semantics within DHCP?  That
is, can't we define a model in which the client and server agree that
the server will send exactly the current state of the IA - the
current list of addresses associated with the IA.  With such a model,
the server would resend every address that continues to be in the IA
and drops those that are no longer in the IA.

>>My comparison point is stateless addrconf. One doesn't
>>conclude an address is no longer valid because routers
>>stop advertising it, one stops using an address when
>>its lifetime expires.

I can understand the desire to be compatible with stateless
autoconf.  But DHCP allows for host-specific configuration
information, rather than information multicast to
many hosts.  So the problem space is a little different,
I think.  I don't see where omitting some of the addresses
sent from a host to a client simplifies anything - that
list of addresses is just the current state for the
client - while explicitly invalidating some addresses
complicates the server logic by requiring that the server
keep track of the client's previous state.

In fact, specifically invalidating addresses complicates
the protocol logic because, as Kim Kinnear pointed out
to me earlier today, DHCP really manages a database of
configuration information that's distributed among the server
and the clients.

If the server must explicitly invalidate
client addresses, it must know what those addresses are.
Easy enough, if the client and server are in sync.  But,
to guarantee correctness in the case that the client
and server are out of sync, the server must know reliably
what addresses the client has in the IA (the server can't
assume that it's version of the IA is the same as the
client's).

So, that synchronization could be accomplished by
requiring that the client send its version of the
IA to the server, and the server could send back the
changes - changing the lifetimes on some addresses,
explicitly invalidating some addresses and adding new
addresses.  That seems more complicated to me than the
server simply sending the client the current, correct,
complete IA.

>Note also, that a DHCP server probably *does* want to include all
>addresses, including those that will become invalid *very* soon,
>because other nodes may be trying to send traffic to those
>addresses.

Agreed...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Sep 2000 11:24:18 -0700

> >So, that synchronization could be accomplished by requiring that
> >the client send its version of the IA to the server, and the server
> >could send back the changes

> I believe, though perhaps more complicated, that this will be required.

Why do you believe this?   I don't think this is required at all, and
it does create a great deal of complexity, as well as making client
packets a lot fatter.   Can you explain why you believe that this is
necessary?

			       _MelloN_