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

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

Jim:

Sorry to appear to be shooting the messenger. Just trying to get this worked
out.

>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?

The reason it is weird is that in other cases you're basically using DAD
once you have a "provisional" address. Yet, in this case, you don't yet
have this address "assigned" - it was just advertised.

Are you intending to allow the client to use the address once DAD is done?
Or, MUST the client wait until it receives a Reply from the server? While
under normal cases this would be relatively quick, there can be times when
it is not - such as if several hops are required to reach a server and you
have a short term link failure somewhere in that path.

And, what happens if the server went down and you're unable to Request the
addresses. If you've installed them at the client already, you'd be in
trouble with connections that might have used them.

So, basically you have this interval between when DAD was complete and until
you receive the Reply that the address can not be used, but you must still
respond to DAD messages (since otherwise if two clients were Advertised
the same address - hopefully by different servers - then the client must
respond).

This seems to imply that you require a new "state" for an address - post
DAD but before it's OK to use.

If you wait until after the Request/Reply, you don't have this issue. You
can just do what you do for stateless ... install the address as "provisional"
and once DAD is done, you're good to go. The address can be used.

And, let me again point out that what you must do anyway should the server
assign more addresses or you get addresses from additional Requests. So,
once again if you do Advertised addresses differently, the client must
remember "oh, I've already run DAD on this so I don't need to do it again".

I am trying to keep the implementation simple. That's exactly why I suggest
we defer DAD until after Reply.

- Bernie

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

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.

On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote:

> 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).

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.
 
> 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.
> 
 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. 

> 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.

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?

> - 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 ...

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.

> - 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.

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).

> 
> 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.

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

---

From: Jim Bound <[email-masked]>
Date: Sat, 28 Jul 2001 00:05:07 -0400 (EDT)

Bernie,

> Sorry to appear to be shooting the messenger. Just trying to get this worked

OK.  Just checking we are all pioneers with dhcpv6 and lots of those folks
got shot...:----)

> have this address "assigned" - it was just advertised.

Yes that is true.  But I view it as optimization for a request I thought
had some consensus.  But I have been wrong on that before.
 
> Are you intending to allow the client to use the address once DAD is done?

Just a nit. "I" the id of Jim intends nothing, but I a co-author am
working with Ralph and our other co-authors to try to move this spec to
consensus, so unless this feature has that I would assume it will get put
on hold.

I do suggest for discussion that the client should not use this address
until a request reply has taken place except on the local link or within
the nodes IPv6 site for that interface.

There could be damage for the site but it would be minimal if incorrect
and if we do this the gain from it for those wanting to do it would be
worth the risk to permit it.  I am assuming is the logic????

> have a short term link failure somewhere in that path.

To use the address beyond the site this should be the case.

> trouble with connections that might have used them.

If that happens the client should delete the address and enter solicit
phase again after all the uses of that address within the site or
local-link have ended.
 
> the same address - hopefully by different servers - then the client must

Yes once the client has the address no one else can use it.  But the
client can use it as I said for link and site communications is my belief.

> DAD but before it's OK to use.

I would not implement it this way or spec it this way.  DAD has happened
thats over.  The client needs to recall the state of the address as the
server has not completed the transaction yet though.  But DAD was done and
completed or failed.
 
> and once DAD is done, you're good to go. The address can be used.

If we do it this way yes it will work.  But why bother with the
optimization then?  Whats was the reason?  I don't see one?
Thats why I suggest it may be useful for link/site prior to the
request/reply phase.  

Either way I see no reason to implement a "state" DAD is done.  Your not
going to have to do DAD again after the Reply.  But you can use it for
greater-than site communications if it has such scope.
 
> remember "oh, I've already run DAD on this so I don't need to do it again".

Thats not the way it will work.  We require the client verify all
addresses are not duplicated on a link.  Thats all we say. We don't say
how you must do that.  IPv6 stateless is the reference for that.  That is
DAD.  After the client gets the prefix from the reply it does not have to
process the same prefix with DAD.  If its a new prefix then DAD will have
to run.  The client does have to keep track of which/when for the
addresses now to support this optimization.
 
> we defer DAD until after Reply.

I see that.  But if we do this what does the optimization buy the end
user?  I don't see it?

thanks
/jim