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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 27 Jul 2001 13:10:13 -0500

Jim:

I do feel differently about this.

>From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be
used to find servers (based on Advertise) and no addresses or parameters
would be provided, I don't see why we have this major shift. The *PROBLEM*
that we had with not sending back anything about addresses in the Advertise
was how does a client know when there are multiple servers which might be
able to give it addresses (this was basically how to pick a "good" server
rather than just simply the highest preference).

So, I think you are changing the rules significantly and I for one don't think
it is a good idea to do DAD on information (addresses) in the Advertise.

There are also issues with this:
- DAD isn't done consistently (as I pointed out below). It's done before
Request in some cases but not in all. Seems kind of weird to me.
- During the Solicit/Advertise, DAD, Request/Reply phase, does the client
have to honor the lifetimes in the addresses? Thus, if a server sends back
short lifetimes and the client doesn't complete the process (get a Reply),
does it have to abort? Or, does it now send a Renew even before it has
requested the addresses? Now, this hopefully won't happen because servers
will return reasonable lifetimes, but ...
- What if a client only wants to use an address for a short time. Does it
every have to Request the address? Perhaps the lifetime it gets from the
server in the Advertise is sufficient for its purposes.

Let's use Advertise for what it was intended - to allow a client to find a
reasonable server. Let's use Request/Reply to do the address allocation.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Friday, July 27, 2001 12:42 PM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit

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

On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote:

> 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 14:57:38 -0400 (EDT)

Bernie,

Not my idea I am the messenger here trying to get to PS.  Mark was the
first one to suggest this as optimization on Ralph's very 1st design team
con call over a year ago.  So I am just reiterating my understanding not
my wishes.

More comments below.

Don't shoot the messenger.  Or the co-author trying to achieve consensus.

> rather than just simply the highest preference).

That is addressed in the current draft by statements what the client can
do with multiple advertisements.  Clearly a server will timeout their
advertize cache to see if client sends addresses and no request comes
back.  I for one don't think we need to say this in an IETF spec either so
I disagree with a lot of the wordy input you want for clarification.  An
implementor should see there is no NAK to the server code base and realize
a timeout is needed to end the state to maintain the information.  We
could provide a suggestion for that time and should be configurable by the
sys admin.
 
> it is a good idea to do DAD on information (addresses) in the Advertise.
 DAD is not an issue here at all.  Its the communications btw the client
and the server that we are working on and IPv6 is fine behind that
(meaning DAD works. 

> Request in some cases but not in all. Seems kind of weird to me.

I was suggesting (if we do this) that we make it consistent after an
advertise and when the client has selected the server.

Why is that weird.  You just enter the code thread on your platform where
you build DAD, Usolicited Mcastaddr, and do the DAD thing.  That code all
exists.  If it doesn't then IPv6 won't work on the platform anyway.  Then
just set up the reply from the function you call into your DAD module.
Why is that weird?  thanks  or are you making another point I am missing?

> will return reasonable lifetimes, but ...

WOW. DAD is like nanoseconds.  Lets put it this way when IPv6 comes up on
our platforms it happens during boot phase so fast we could not dump it
during AD of IPv6 to see it.  Had to hack around it.  

So if an admin says an address is on 5 minutes good then thats just stupid
and they should suffer from being incompetent.  But seriously I don't
think this will happen in practice even as exception but if it did the
client should never do a renew without a request.  That is asking for to
much state in the server for this optimization.

> server in the Advertise is sufficient for its purposes.

Yes the client has to do this because in our model the server owns the
addresses, times, and everything about the address.  The client must
request the address after the advertise.  Its the right way to tell the
server I am now keeping this and by the way Mr. server I got pass DAD too
(indirectly of course).

> reasonable server. Let's use Request/Reply to do the address allocation.

Hmmm.  I have no comment on this as co-author for now.  I am merely
explaining a way this can be done.  What you ask is WG consensus
questioins. I was assuming we wanted to do what Mark suggested maybe I am
wrong. 

Comments from others please..............

thanks
/jim