Subject: RE: Addresses and other parameters in Advertise and Solicit

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 26 Jul 2001 17:16:53 -0500

See comments below, prefixed by BV>.

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Thursday, July 26, 2001 4:43 PM
To: DHCPv6 discussion list
Subject: Addresses and other parameters in Advertise and Solicit

Bernie Volz wrote:

>1. In Section 14.3.1 (Creation and sending of Request messages), there
>    is no mention of using any of the "information" supplied by a
>    server in the Advertise message (in response to a Solicit). In
>    DHCPv4, the client sent information received in the Offer. We
>    probably should be explicit about this and perhaps even suggest
>    that the information received by a client in an Advertise is
>    basically for information purposes only to help it determine
>    whether this server will offer it what it needs.

So, are you suggesting that the DHCPv6 client Request exactly the addresses 
and options from the Solicit, or no addresses or options, or ???

BV> I'm trying to figure out exactly what you, Jim, and others were expecting.
BV> Since there isn't anything in the text about exactly how this is expected
BV> to work, I would like some clarification.
BV>
BV> I do feel that servers will have less work to do if they don't have
BV> to return full addresses that clients can use. The reason for this is
BV> that the server doesn't have to assign the address until it receives
BV> the request. And when multiple servers are running, this is a potential
BV> big win as the Request will only go to one of those servers.

>    Perhaps the
>    addresses assigned in the Advertise should even just be prefixes
>    (interface portion all 0's)?

I don't have a strong feeling one way or the other.

BV> See above as to why I feel it best that they are just the prefixes.

>    If instead we want the server to assign "real" addresses, should
>    something be said about how long those should be valid and whether the
>    server should attempt to assign those same addresses to the client in
>    a subsequent Request/Reply exchange for the IA? Perhaps we could punt
>    and say this is a server implementation issue (whether it assigns real
>    addresses and whether those are held for some (short) time for the
>    client)?

I take "valid" in this context to mean "reserved for this client".  Has 
this scenario been a problem in DHCPv4?  Do we need to specify any more 
mechanism than we have in the DHCPv4 spec?

BV> Yes, valid means "reserved" for that client binding (DUID/IAID).
BV> Well, I think the message timeouts and retransmission might dictate
BV> the total time a server should put on these lifetimes.

>    NOTE: If real addresses are returned, perhaps a client might even
>    initiate DAD during the Request/Reply in which case it can do these
>    two items in parallel (though this would be somewhat tricky since it
>    would not want to Decline the addresses before receiving the Reply).

Hm.  I guess I had anticipated that the client would do DAD and either 
Request or Decline the addresses in the Advertise.  It is the case that the 
spec does not constrain the times at which a Decline can be sent.  I'm not 
sure it makes much sense for the client to Request a set of addresses and 
then Decline them later.

BV> Hm back. Doesn't this make for a bizarre client implementation?
BV> Recall that a client doesn't go through the Solicit/Advertise phase
BV> for all of the addresses. It can issue additional Requests at any
BV> time. Also, Renews can result in additional addresses being granted.
BV> Under those cases the client must DAD them as well. Just seems so
BV> much easier to be consistent and have the client get some addresses
BV> and before using them run DAD. If the addresses are bad, then it
BV> Declines them.

BV> Also, if the DHCP server is doing its job, DAD really should be an
BV> extremely infrequent event - more likely caused when switching from
BV> stateless to managed or if you have broken clients.

BV> If you want to allow DAD after Advertise (and a Decline before a
BV> Request), then we do need to make that very clear in the draft since
BV> that has never been my understanding. Did I miss something in the
BV> draft?

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 27 Jul 2001 12:42:10 -0400 (EDT)

what my understanding of this is as follows.

1.  we removed the design center/model that clients request specific
number of addresses.  that I think has consensus and I hope we don't
revisit that again.

2. we would like an optimization in dhcpv6 that a client be able to get
addresses to use from solicit.  we knew we needed more words here and
ralph and I assumed draft 20 for this per discussion which we are having
so that is great.

thats how we got there and where we are for continuity.

what were we thinking question?

first keep it simple (ergo cheap to implement and for the network
traffic esp mobile nodes).

client can use ORO with solicit say for IA and addresses?

but can a server know the IA from solicit with just ORO? No.

should we fix the above ?  if we can avoid anythink but ORO thats a good
thing for the protocol design is my thought so I think not is my input.

so the server when giving address back to client on advertise means the
server must be able to maintain it did this (thats why its only an option
not mainstream).  I think this is doable but we should not specify in
detail now.  leave it to implementaiton defined after we are in PS and get
some practical running code experience we can re discuss this aspect.

the client would be able to send addresses back in the advertise (ignoring
the prefix stateless debate for now).

the client should do DAD on the addresses.

if tehy fail a decline should be sent and the server will know how to
determine which client declined (implementaiton defined above).

if success at the client then a request is generated and the server kills
the temp cache (or whatever) from the advertise and builds complete
database set for those client addresses.

would this work for everyone to go to last call?

if so ralph and I can go built the wordage for next spec version for last
call?

[note - whether to permit prefixes only to clients emulating stateless
should be transparent to this answer]

thanks 

/jim