RE: Client IAADDR copying between Advertise and Request

Also, doesn't this create a special case for the S/A/R/R
sequence in the
server? That means that the server has to have some way to
detect that
the Request is in response to an Advertise?

This was my point earlier ... How does the server know that
this is a
Request in response to an Advertise as opposed to a Request
for
addresses unrelated to an Advertise (again, my understanding
of RFC 3315
is that a client that has a new binding (IA_*/IAID) and
already has
previous bindings from a server, need NOT go through the
Solicit/Advertise but can just send a Request -- that
Request may or may
not have addresses but certainly would not have any
addresses previously
in an Advertise).


David, I beleive you commented something about the
transaction-id being
the same for the Solicit and Request, but I don't believe
that is the
case at all:

15.1. Use of Transaction IDs

   The "transaction-id" field holds a value used
by clients and servers
   to synchronize server responses to client messages.  A
client SHOULD
   generate a random number that cannot easily be guessed or
predicted
   to use as the transaction ID for each new message it
sends.  Note
   that if a client generates easily predictable
transaction
   identifiers, it may become more vulnerable to certain
kinds of
   attacks from off-path intruders.  A client MUST leave the
transaction
   ID unchanged in retransmissions of a message.

It says "for each new message it sends". I read
that as meaning the a
Solicit and Request would have completely different
transactions IDs --
they are different messages. Only retransmitted messages
have the same
id.

And, I tried this with a publicly available client and it
uses different
transaction-ids in the S/A/R/R sequence for the Solicit and
Request.

- Bernie 

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemonnominum.com] 
Sent: Thursday, March 29, 2007 6:29 PM
To: David W. Hankins
Cc: DHC WG
Subject: Re: [dhcwg] Client IAADDR copying between Advertise
and Request

On Mar 29, 2007, at 3:18 PM, David W. Hankins wrote:
> To clarify, I am making no suggestions for server
behaviour.  I
> am arguing solely about client behaviour.  The first
sentence was
> mis-written (s/should/might/ maybe).  The second
sentence is
> correct.

Okay, now I see why you think this wouldn't break anything. 
 The  
problem is, what if a server implementor reads the required
client  
behavior to mean that it should drop packets from clients
that don't  
send IAADDR?



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

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

On Fri, Mar 30, 2007 at 01:15:52PM -0400, Bernie Volz (volz)
wrote:
> Also, doesn't this create a special case for the
S/A/R/R sequence in the
> server? That means that the server has to have some way
to detect that
> the Request is in response to an Advertise?

I think it doesn't change server behaviour.

You either use the supplied address as a hint, or you don't,
and
that's a separate debate.  You either support a client that
supplied
no addr (as rfc3315 says today), or you don't, and that's
also a
separate debate.

I've observed that all clients supply the IAADDR from the
advertise
in their request - and I think that a client that chooses
not to is
going to find themselves incompatible with servers that are
written
'to the wire'.

What the server does or doesn't do is immaterial.

> David, I beleive you commented something about the
transaction-id being
> the same for the Solicit and Request, but I don't
believe that is the
> case at all:

Nope.  Not sure what this is about.

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