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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 31 Jul 2001 10:44:48 -0500

Jim:

Agreed, DAD itself has little to do with this.

However, when DAD is done does - because that determines when the client begins
to claim some ownership of that address (whether it uses it is another issue)
and it impacts when a Decline might be done.

If the conclusion is that Advertise is just an advertisement of service (which
is what I'm arguing for and which was the original purpose of Advertise) and not
a "contract" of the actual addresses (which is the opposing view), DAD can't be
done until later (after Reply received) and so is not an issue. However, as you
specified it earlier, DAD was done on the Advertised addresses and that has
implications on what Advertise means.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Tuesday, July 31, 2001 11:23 AM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit 

Bernie,

DAD has nothing to do with this at all.  Its transparent.  I will leave it
to my colleagues on the list to respond to other comments.

thanks

/jim

On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote:

> Ted:
> 
> I don't understand your argument. A broken server is just that, broken. What it will
> and will not allow a client to do is not an issue - fix the server.
> 
> In fact, I believe having the actual assignment of addresses deferred until the Reply
> is received is far more likely to result in non-broken servers. A server, in the
> Advertise, just needs to tell the client that it is willing to assign address.
> 
> The questions are:
> - Is Advertise a contract to give the client those addresses?
> - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before
> doing the Request. And, when can a client start using an address? After Advertise?
> After Reply?
> 
> Please also note that there are some other properties of DHCPv4's offer behavoir that
> are not currently specified in DHCPv6. Such as:
> - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that
> their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose,
> do we need this?
> - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence
> and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence.
> - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If
> we're going to follow that convention, we need the client to send the IA option it
> received from the server in the REQUEST?
> - In DHCPv4, the server always has the ability to DHCPNACK the address received
> in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need
> to have a mechanism for the server to tell the client, gee sorry, that address isn't
> available now. Perhaps the mechanism is simply for the server not to include that
> address in the IA in the Reply. But again, this behavoir would not be needed if the
> addresses in the Advertise are just informational (I will assign you addresses similar
> to these).
> 
> - Bernie
> 
> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, July 30, 2001 3:46 PM
> To: DHCPv6 discussion list
> Subject: Re: Addresses and other parameters in Advertise and Solicit 
> 
> 
> 
> > thanks for the input I knew that this was your view.  But Mark said
> > nothing about DAD.  He said and also at the San Diego meeting it would be
> > good if we could optimize the protocol to support this jaundra.  So your
> > recollection is not mine.  thanks
> 
> Blech.   If Solicit/Advertise doesn't say what the merchandise is,
> it's easy to imagine a server that's broken in a way that would
> prevent a client from ever getting an address.   We have been over
> this ground before.   Jim is right.   Please let's leave it that
> advertise says "I'll try to give you these addresses if you choose
> me."   I.e., pretty much like DHCPOFFER in DHCPv4.
> 
> 			       _MelloN_
>

---

From: Jim Bound <[email-masked]>
Date: Tue, 31 Jul 2001 15:34:30 -0400 (EDT)

Bernie,

Yes we are in synch.  I will support either decision as my individual WG
input.  So I am amoral on this one.

thx

/jim