Subject: RE: Simplify release and decline of addresses

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Jul 2001 18:42:04 -0400

My memory is that we've come to consensus that the client doesn't get to 
specify what kind of addresses it wants; the client sends an IA to the 
server and the server's response is determined by the server's admin policies.

- Ralph

At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>Regarding a new option to handle Temporary Addresses, I think this has
>merit simply because there has been no way for a client to communicate
>what kind of addresses it wants. Having this option provides that mechanism.
>Alternatives, such as allowing 'num-addrs' and thus some address information
>(T bit) to be specified by the client in a Request were discussed at one
>point but did not make it into the -19 draft and I'm not sure if it would be
>in the -20.
>
>Perhaps Ralph and Jim will care to provide some indication of how this 
>will be
>resolved in the -20 draft - to give the client some ability to communicate to
>the server what it needs. OR, perhaps the answer is simply "no, we're not
>going to support it - it is up to the server to figure it out."

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 24 Jul 2001 19:12:26 -0400

Ralph, I'm surprised by this.  I don't want to respond to the list, because I
haven't been following this.  I was trying to find notes back to the 3/14 teleconf
here, which is the last time I was involved in a discussion about this, but
haven't been able to do so.

I thought the client who wanted both temporary and non-temporary addresses would
use two IAs, asking for temps with one and not the other.  How are you proposing a
client get both kinds of addresses (the most common case, I believe)?  Can this be
done with one IA?  I thought all the addrs for an IA were either temp or perm.

--
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-244-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Josh Littlefield <[email-masked]>
Date: Tue, 24 Jul 2001 19:15:35 -0400

Well, so much for not replying to the list...  (Damn mail clients).

Just hold your tomatoes and be kind in replying if I'm way off-base here.
 -josh

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2001 17:09:50 -0700

> I thought the client who wanted both temporary and non-temporary
> addresses would use two IAs, asking for temps with one and not the
> other.  How are you proposing a client get both kinds of addresses
> (the most common case, I believe)?  Can this be done with one IA?  I
> thought all the addrs for an IA were either temp or perm.

That is my recollection as well.   I remember that we went around on
whether to have a special "temporary" IA as well.

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Tue, 24 Jul 2001 23:55:14 -0400 (EDT)

I support Ralphs recollection too.

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 24 Jul 2001 23:57:38 -0400 (EDT)

Josh,

A client can have 10 addresses for one IA.  3 of them could be temporary.

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 24 Jul 2001 23:59:39 -0400 (EDT)

Not mine.

an IA is for an interface.  an interface has x addresses. x(1) and x(4)
could be temporary where all others are permanent. 

we agreed to this to keep it simple for first work on private addresses.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 25 Jul 2001 00:02:51 -0400 (EDT)

also the consensus was when we agreed to provide the T bit for an address
within an IA set of addresses.  But default.  Rather than explicitly. We
had the T bit above all addresses at one point which would have required
an IA for T bit address set.  But people barfed on that at the Minneapolis
meeting.   

Also I would argue this is not a problem either.  And in accordance with
the spirit of using private addresses.  Also having servers keep extra IAs
for yet another derivation has to be justified and no one did that either.

/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 25 Jul 2001 00:17:32 -0400 (EDT)

Folks,

This is just a personal comment and concern.

I think it fine that we use IPv6 multicast for our msgs in DHCPv6. I think
it wonderful we use the relay-forward and relay-reply too.  I also think
it wise we made sure that the client can use unicast for request messages
(confirm is in question now for sure).

But I caution the working group to not overload the relay with state or
server type functions as a MANDATORY REQUIREMENT, but as MAY REQUIREMENT.  

Also in todays maket typically organizations run dhcp servers for multiple
sites.  This will be true for the traditional wireline communications with
dhcpv6 too.

But at access points to the Internet for wireless and broadband for IPv6
and for IP Telephony the dhcpv6 server in most cases will be on the same
link (good news for all you server and dhcp software vendors I predict
more boxes will get sold becaue of this with dhcpv6).  The reason is
locality of reference to obtain an address for these type devices. The
operators for this infrastructure will maintain tight control for
performance reasons and avoid excessive network traffic routing where ever
possible. Ergo dhcp relays.

So its imperative that our abstraction work very well for implementors
where a relay may never be used OR a sys admin wants the clients to
unicast directly when possible to the server.

I will look carefully at this as Ralph and I absorb this last round of
input into the last call draft after London meeting.  I will do my best to
do that before London of course.

/jim