Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Wed, 4 Oct 2000 22:01:25 -0400

By all means. I wasn't trying to provide the exact text, just trying to
improve on what was being proposed. Details will need to be filled in.
Likely, we would also want a prefix to identify how the unique identifier
was created in all cases - that would help to assure each technique of
generating the identifier produces a unique identifier.

I also suspect that there is some 'prior art' on this matter in other places
and that should be used and referenced if at all possible.

- Bernie

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Wednesday, October 04, 2000 9:35 PM
To: DHCPv6 discussion list
Subject: RE: DHCPv6 address model proposal...

Bernie,

 > 2) If a client has unique identifying information (such as a serial
number)
> that it can use as a unique identifier, it MUST use this (after storing it
> in stable storage if possible).

For this to produce unique numbers you need to identify the number space
as part of the I-D. Otherwise two boxes made by two different vendors
might both have serial number 17.

   Erik

---

From: Ted Lemon <[email-masked]>
Date: Wed, 04 Oct 2000 22:32:36 -0700

> Details will need to be filled in.

Someone has to do this, of course.   We're into the rewrite period at
this point - can the authors say how they are doing, and whether or
not they would like some help, or whether they don't feel they have
anything to go on yet?

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Thu, 05 Oct 2000 22:15:45 -0400

Hi Ted,

>not they would like some help, or whether they don't feel they have

Yes we have lots to go on.  Mike and I have been talking to Ralph. Yes
we will want help.  Ralph will be sending note to the design team what
next steps are and then we can get that to the list.

So Yes Yes Yes too all your questions.

thanks
/jim

---

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Oct 2000 13:23:46 -0400

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: Jim Bound <[email-masked]>
Date: Wed, 11 Oct 2000 14:17:42 -0400

Hi Ralph,

>collection of global-, site- and link-local addresses.

The server cannot give out link-local addresses they are determined at
boot time by an IPv6 node.  The reason is that link-local addresses are
automatically generated by IPv6 nodes and verified with Duplicate
Address Detection on the link.  

Also nodes using site-local addresses to connect to a dhcpv6 server
would mean the dhcpv6 server also has a similar site local address.
Clients should only use a site-local address when communicating with the
server if the server is in the same site as the client.  Multi-sited
dhcp servers should be acceed with greater scope than site-local which
today is only global.

regards,
/jim