Subject: RE: DHCPv6 address model proposal...

From: Bernie Volz <[email-masked]>
Date: Mon, 25 Sep 2000 16:05:58 -0400

Yeah ... I looked through the spec the other day and couldn't find this
discussed either. I thought perhaps I just wasn't looking the right place.

Perhaps the DHCPv6 model is that the client must go back through the entire
cycle to locate a server? In that case, having the ability to provide a list
("gee, I'd like these addresses - can I have them please!") would be greatly
useful.

Sometimes I've been falling back into the DHCPv4 mode in our discussions ...
and in that case, certainly having the client send the address is absolutely
critical to the proper operation of DHCPv4 (we trust the client in failover
and at other times). And, as DHCPv6 has similar goals and requirements (at
least in my mind), I can't see how this fundamental issue should be changed.

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, September 25, 2000 3:37 PM
To: DHCPv6 discussion list
Subject: Re: DHCPv6 address model proposal...

> These are *ALL* examples of where the server's behavoir (under certain
> circumstances) would be changed based on this information because if it
> wasn't there the renewal might get completely different addresses UNLESS
you
> tell me that the way a server "calculates" an address is a fixed algorithm
> (in which case why have the IA at all as we want to be able to give the
> client multiple addresses).

If the client is renewing, it's unicasting to the server, not
broadcasting, right?   Actually, now that I think about it, I don't
know that this is true - do DHCPrequest messages go to the server's
address or to a multicast address?

Hm, this is interesting.  There does not appear to be a mechanism in
the specification for what happens if the client has a valid IA, tries
to renew it, and gets no response.   There doesn't seem to be anything
in the spec at all about renewal, other than a brief blurb on
releasable resources.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Sep 2000 14:04:56 -0700

> And, as DHCPv6 has similar goals and requirements (at

When the client is contacting a server with which it has an existing
collection of addresses for an identity association, it should not be
necessary for it to resend its current addresses.  And if it is only
using its current addresses as care-of addresses, likewise I think it
doesn't need to send it.  However, if we can get into something like a
REBINDING state, *then* it needs to send its current set of addresses,
so that the other server in a failover pair has the opportunity to
renew them.

I don't think it needs to send its addresses on startup - in the
DHCPsolicit message - because at that time presumably it does not have
any outstanding connections on addresses in the identity association,
so it has nothing to lose if the secondary gives it a different
address.

So I see only one case where this is important: REBIND.   And the
current draft doesn't do REBIND.   I think it should do REBIND, and
when it does, I think the REBIND request should include a list of
addresses.   Would that satisfy your concern?   If we conclude that we
*don't* need REBIND, do you think there is a case where the client
still needs to send its current address list?

			       _MelloN_