Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 11 Oct 2000 13:56:56 -0400

Ralph:

1) It might be useful to explicitly state the behavior of the server not
returning one or more addresses on a renewal (the implication is that the
client continue to use the missing address(es) until the lifetimes
previously communicated expire).

2) Ted was arguing NOT to include the list of addresses in client renewals
(but to include them in REBINDINGS, which need to be explicitly addressed in
the DHCPv6 specification). I personally would like to see them included
always, but we've debated that issue before.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, October 11, 2000 1:24 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

Issue: DHCPv6 address model.  Here's my summary of the discussion:

DHCP clients and servers will use Identity Associations (IAs) to
manage IPv6 addresses.  Each IA will have:

* a unique identifier
* a set of IPv6 addresses
* a renewal time

Clients and servers use the unique identifier to identify the IAs in
protocol messages.

Each IPv6 address has an associated preferred and valid lifetime.  The
lifetimes are determined by the server and handed to the client.
There are no restrictions on the scopes or number of IPv6 addresses in
an IA; an IA might contain just one IPv6 address or it might contain a
collection of global-, site- and link-local addresses.

The renewal time defines the time at which the client must contact the
server to get the current state of the IA (call this "renewing" the
IA).  The renewal time is independent of the address lifetimes of any
of the lifetimes of the IPv6 addresses in the IA.  It makes most sense
for the renewal time to be less than the preferred lifetimes of all of the
IPv6 addresses in the IA, and the renewal time must be less than the
valid lifetimes or the client will lose the use of some expired
addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  In any event, the server is
authoritative about the set of addresses and lifetimes in the IA.

The client must send all of the addresses associated with an IA when
renewing the IA.  The server examines this list of addresses and may
extend the lifetime or set the lifetime to zero of any addresses in
the IA.  The server may also add new addresses to the IA.  The server
returns the new IA to the client.

In all other transactions, the client sends the IA identifier and the
server returns IA identifier along with the list of addresses in the
IA.  The server is authoritative and the client simply records the IA
and configures the associated addresses.

TBD: During the address model discussion, we noted that the current
spec leaves the details of the renewal process to the DHCPv6 client
implementor.  I heard consensus that we should define the renewal
process and include it in the spec.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Oct 2000 14:17:24 -0400

>previously communicated expire).

Good point; I'll make that change.

>always, but we've debated that issue before.

Well, this issue is a little tough to resolve with precision until we 
settle on a mechanism for IA extension.  The current spec doesn't 
differentiate between the DHCPv4 RENEW and REBIND actions.
Within the current spec, I could clarify by specifying that the addresses 
in an IA must be included in any multicast renewal message (I think that 
captures the circumstance in which the addresses must be communicated to a 
different server) - which would anticipate that we define a unicast RENEW 
and a multicast REBIND.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Oct 2000 08:17:08 -0400

I just finished writing this note, and see that it is *way* longer than one 
page.  So here's an executive summary:

The requirements of the failover protocol and explicit expiration of 
addresses in server-client messages combine to require that the client send 
its version of the IA - identifier and addresses - with every message to 
the server...

- Ralph

>always, but we've debated that issue before.

I think there is need for some additional clarity in this debate.  I see 
two issues influencing the inclusion of addresses with IAs in 
client->server communication:

1) The address expiration model: does the server expire addresses 
(effectively make the valid lifetime 0) by explicitly setting the address 
lifetime to 0 or implicitly by omitting the address from the IA?

2) Failover protocol: a client using multicast to extend the assignment 
time of an IA must include the addresses with the IA in case the extension 
request is received by the backup server, which has not received the 
information about the IA from the primary server.  In the case where the 
backup server does not know about the IA, it assumes the IA from the client 
is valid, extracts the information about the IA from the client message and 
commits the IA to its binding database.  Note: I used the terms 
"mutlticast", "extend", "extension" and "assignment time" here to describe 
the situation in the abstract without conflicting with terms like "renew", 
"RENEWING", "REBINDING" and "lease" from DHCPv4.

I'll work backwards: (2) requires that the addresses be included in any 
messages that might be received by the backup in a primary-backup failover 
pair before the backup has received the IA binding from the server.  This 
is the case when the client uses multicast to extend the assignment time of 
an IA, corresponding to a DHCPREQUEST message from a client in REBINDING 
state in DHCPv4.  I've heard WG consensus to require that IA addresses be 
included in these messages from the client.

(1) comes into play in any message in which the client thinks it knows the 
addresses in the IA; the corresponding states in DHCPv4 would be 
INIT-REBOOT and RENEWING.  In both of those cases, the server must know the 
addresses in the IA before it can expire any addresses that are no longer 
usable by the client.  In theory, because the server is authoritative, the 
server knows what addresses are in the IA and need not get the current 
state of the IA from the client.  In practice, if the client and server are 
out of sync, the server may not know all of the addresses in use by the 
client and therefore will not know to expire those addresses.  I think the 
requirement for explicit expiration and recognizing that clients and 
servers may be out of sync requires, as a belt-and-suspenders measure, that 
the client send the addresses with the IA any time it has addresses it 
thinks it can use.

So, it appears to me that the client should always send the entire IA to 
the server.  If the client thinks the IA is "empty" (i.e., a new IA for 
which the client is requesting address assignment), the client sends no 
addresses with the IA; otherwise, the client sends what it thinks is the 
current list of addresses in the IA.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Oct 2000 11:13:40 -0400

At 10:48 AM 10/12/00 -0400, you wrote:

>I assume that both techniques are valid. Omitting the address from the IA
>means that whatever lifetimes that client previously had apply and it is
>free to use the address until the lifetimes end.

Right - however, I was trying to enumerate ways in which the server could 
terminate the client's use of an address immediately with extreme prejudice 
rather than allowing it to die a natural death.  So, I was describing the 
case in which the client would set the lifetime of any addresses not in the 
IA to 0.  My (1) should read:

1) The address expiration model: does the server expire addresses
(effectively make the valid lifetime 0) by explicitly setting the
address lifetime to 0 or implicitly by omitting the address
from the IA (in which case the client would set the lifetime
of any addresses not in the IA to 0).

>  Explicitly setting the
>address lifetime to 0 means that the server requests the client stop using
>that address immediately.

We agree here -

- Ralph

---

From: Bernie Volz <[email-masked]>
Date: Sun, 22 Oct 2000 08:57:48 -0400

>* We have not yet reached consensus on when the client sends the
>   addresses in an IA - with every messages or only when trying to
>   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
>   the wording for sending the addresses SHOULD or MUST?

While it may be premature as there's been no (or relatively little)
discussion regarding the possibility of giving clients a multicast address
as the server's address, I think it best for sending the addresses in an IA
to be a MUST.

For things like redundancy, whether a 'revised' DHCPv4 Failover protocol or
something else, the idea of having a client send DHCPv6 requests (whether
initial, renewal, or rebinding) to a multicast address instead of a unicast
address is attractive. Thus, having the client provide the address list to
the server is critical (since the redundancy model may rely on lazy updates
or perhaps even no updates).

I guess an alterative is to add the requirement that only if the destination
address for a message is a multicast address, it is a MUST (instead of
always a MUST).

Other benefits for always requiring the sending is that it makes debugging
and tracing easier (since a rebinding or renewal may come days after the
initial request and being able to compare the Request against the Reply
without having to know what the client and server knew is attractive).

The COST of having this be a MUST is the increase in packet size and
processing time at the receiver - a relatively small price to pay. If that
price is to high in certain applications (wireless?), perhaps a solution is
for an option (extension) to be defined that tells the client that it is OK
not to send the addresses for specific cases. The cost of that option is 4
or 5 bytes (5 with a flag byte for on/off). Though there are likely some
issues with this option - such as scoping (when does it apply/not apply).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 1:16 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

Here's my latest summary of the DHCPv6 address model.  I've included a 
summary of changes from the previous model and  a list of 3 TBD issues at 
the end of the summary.

Please review this summary and post any comments.  If we have any 
unresolved issues I'll add them to the draft for discussion at our next 
design team phone call.

- Ralph

=====

* a unique identifier

collection of global- and  site-local addresses.

When the client renews an IA, the server tells the client about the
current set of IPv6 addresses in the IA.  The server may change the
set of addresses or the lifetimes of existing addresses during this
renewal.  For example, setting a longer lifetime on an address already
in the IA is the equivalent of extending the lease on a DHCPv4-managed
address.  Setting the valid lifetime to zero marks an address
immediately as no longer valid for the client.  Adding a new address
to the IA can be used for renumbering.  If the client has an address
assocaited with an IA that is not explicitly mentioned in a message
from the server, the client leaves the address in the IA and may
continue to use the address until the lifetime for the address
expires. In any event, the server is authoritative about the set of
addresses and lifetimes in the IA.

Changes from previous summary:

* (3rd para) DHCP server does not hand out link-local addresses (input
   from Jim Bound)

* (5th para) If the server does not include an address in the IA, the
   client is allowed to continue using the address until its valid
   lifetime expires (input from Bernie Volz)

TBD:

* During the address model discussion, we noted that the current
   spec leaves the details of the renewal process to the DHCPv6 client
   implementor.  I heard consensus that we should define the renewal
   process and include it in the spec.

* We have not yet reached consensus on when the client sends the
   addresses in an IA - with every messages or only when trying to
   locate a new DHCP server (as in DHCPv4 REBINDING state)?  And, is
   the wording for sending the addresses SHOULD or MUST?

* There is still a minority position that the contents of the IA from
   the server should be authoritative, and any addresses not explicitly
   included in the IA from the server should be discarded immediately
   by the client.