RE: Client IAADDR copying between Advertise and Request

Well, one point was that a Request with new bindings is
prefectly valid
at any time (once a client has gone through the SARR
sequence and
learned a server identifier, there's no requirement that it
go back to
Solicit if it wants to request leases for another binding).
Also, in
this case, the client COULD request a specific lease, but
the server may
or may not include it in the Reply.

The only time a "contract" between the server and
client is created is
for a Reply; thus I see no requirement that the Advertise
contain the
same as the Reply -- and hence there should be no assumption
that what
you Request is what you get.

I just don't see the need to require this and a server is
certainly much
more robust if it doesn't require this.

I certainly have no issue to indicate a client should send
what it got
in the Advertise, but again, the client MUST only consider
what is in
the Reply as to the leases it ends up using.

- Bernie

-----Original Message-----
From: Bud Millwood [mailto:budmweird-solutions.com] 
Sent: Wednesday, March 28, 2007 2:03 PM
To: dhcwgietf.org
Subject: Re: [dhcwg] Client IAADDR copying between Advertise
and Request

On Wednesday 28 March 2007 19:38, David W. Hankins wrote:

<snip>

My gut feeling is that you're right. Maybe because that's
how DHCPv4 did
it, 
also because SOLICIT/ADVERTISE/REQUEST/REPLY seems like one
transaction,
and 
changing the address mid-way through seems to violate the
whole idea of
a 
transaction.

Initially I agreed wholeheartedly with you, but Bernie had
some
interesting 
points that made me consider the issue carefully -
unfortunately I can't

recall his points now. I hope he'll grace us with those
again and let
the 
wider audience get involved in this issue.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solut
ions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bernie Volz (volz) wrote:
> 
> The only time a "contract" between the server
and client is created is
> for a Reply; thus I see no requirement that the
Advertise contain the
> same as the Reply -- and hence there should be no
assumption that what
> you Request is what you get.
> 
> I just don't see the need to require this and a server
is certainly much
> more robust if it doesn't require this.
> 
> I certainly have no issue to indicate a client should
send what it got
> in the Advertise, but again, the client MUST only
consider what is in
> the Reply as to the leases it ends up using.

Okay, my take on it, based on each part of the message
exchange:

- - Clients have no requirement to put IAADDR in Solicit
messages. They may do so
to offer hints to the server. (We identified a special case
where the client
uses "::" for this when it wants to offer hints to
the server and has no other
way to do this. Well, when I say "we", it was the
Dibbler author, Tomasz
Mrugalski, who explained it to me.)

- - Servers have no requirement to put IAADDR in Advertise
messages. They may do
so to offer hints to the clients, who can use it in server
selection (for example).

- - Clients have no requirement to put IAADDR in Request
messages.

These are uncontentious, I think. This is contentious:

- - If a client *does* put IAADDR in a Request message, and
the server does not
want to lease those IAADDR to that client, the server should
return a Reply with
a failure code of some kind. (Bernie thinks the server
should be able to provide
a different set of IAADDR.)

My reasoning here is that if the client wants a specific
address, it should
request it, and the server should either provide that
address or not. I think
this is actually a part of a bigger disagreement.

Bernie's position, AIUI, is that the server can lease any
addresses to clients
at any time, and the client must be able to do something
with them. So, any
Reply is a new lease.

I think this places quite a burden on the client. For me,
when a client issues a
Renew (for instance), it is expecting exactly what RFC 3315
says:

                                             To request an
extension of
   the lifetimes assigned to an address, the client sends a
Renew
   message to the server.  The server sends a Reply message
to the
   client with the new lifetimes, allowing the client to
continue to use
   the address without interruption.

A client is *not* expecting to get a new address, and I
think in fact should not
have to. I think if the address the client wants under a
given circumstance
(Request, Renew, or Rebind) is not available, the server
should return an error,
and the client can decide what to do at that point (for
example, pick another
server, try stateless configuration, and so on).

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGC4zQMsfZxBO4kbQRAmzRAKDta4MeoyXl87tLr3n2DozCJV3ISwCg
7P54
2f7fKuQHeEGiifDXN9pGb48=
=Ra2I
-----END PGP SIGNATURE-----

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

On Mar 29, 2007, at 2:54 AM, Shane Kerr wrote:
> - - If a client *does* put IAADDR in a Request message,
and the  
> server does not
> want to lease those IAADDR to that client, the server
should return  
> a Reply with
> a failure code of some kind. (Bernie thinks the server
should be  
> able to provide
> a different set of IAADDR.)

This isn't an accident of the specification - it's a
deliberate  
choice.   IPv6 isn't like IPv4.   Addresses are expected to
change;  
renumbering is expected to happen.   You are never
guaranteed to be  
able to keep an address after its valid lifetime expires.

Suppose the server responds with an error, rather than
giving the  
client an address.   Now what does the client do?   Stop
using the  
old address?   That's not what's supposed to happen.  
What's  
supposed to happen is that the old address is supposed to be
 
deprecated, and the new one preferred.   Connections that
use the old  
address can continue for the valid lifetime of that address,
and new  
connections will use the new address.   So it's not an error
when the  
server doesn't want to renew the address, and responding as
if it is  
is not appropriate.



_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

On Thu, Mar 29, 2007 at 11:54:25AM +0200, Shane Kerr wrote:
> I think this places quite a burden on the client. For
me, when a client issues a

I just want to pipe up with one of those annoying real life
datapoints,
since I'm doing a client implementation.  I missed the 'Tao
of rfc3315'
the first read through, so I implemented expecting an error
when the
addresses I request/renew/rebind weren't
available/extendable.  New
addresses might show up, but old ones must always be there
(if with
zero lifetimes) or else an error status code from the
server.  All
else would have been dropped and logged as an error (if I
had finished
that function).

Bernie set me straight at the bake-off, and since other
server
implementations are already written this way I guess, I
wanted to
bring the client around to this point of view.  It's useful
at least
for more interoperability testing, if not permanently.

~/proj/isc:2$ cvs rdiff -r rt16759_base -r rt16759 DHCP | wc
-l
761

I'm about halfway done I think (but there aren't as many LOC
left to
write).  This is all new code - it's not removing the client
code we
saw at Amsterdam, except for the odd one or two lines, it's
adding
new complexities on top of that.

Whereas before, I could use one state object with one
reference point
in time and many "deltas" as provided by the DHCP
server under that
(t1/t2, pref/valid), now I have to provide a reference point
for each
IA, and then for each IAADDR underneath that...so the
schedule keeper
had to be reworked as well...recursive relative time math is
not a
lot of fun to start with, and it gets a lot less fun every
time you
add a reference point that can be potentially inconsistent
with the
others.


Anyway, figure ~1000 lines of diff to sync up with the
opposing view.
This is either a very large number or a very small number
depending on
who you are, but it's a number.

I was a lot happier when I believed I could just log an
error and drop
the packet.

-- 
David W. Hankins	"If you don't do it right the first
time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg