Subject: [dhcwg] Client IAADDR copying between Advertise and Request

From: "David W. Hankins" <[email-masked]>
Date: Wed, 28 Mar 2007 10:38:22 -0700

Presently, RFC3315 indicates that it is optional for a client
to either provide, or neglect to provide, the IAADDR contents
found in the Advertise packet the client has selected, and is
Request'ing.

So, a server has to be prepared to deal with either case.

This is kind of a pet peeve for me, and I thought I'd take a
moment to write down why in the spirit of the DHCPv6 bake-off
"issues list".  It's a fairly long explanation unfortunately,
and I don't really see a way to trim it.

Sorry about that.

For a client, the act of copying a field from one packet to
another is trivial, so making this optional is a "trivial
simplification" from the client's perspective.  It doesn't
really win you a lot.  It doesn't affect software design
or implementation ("architecture") choices.

For some DHCPv6 servers, the act of finding an address to
allocate to a client might be more expensive than to look up an
address (we have no crystal ball to show us future
implementations, or all "implementation environments").

That is: "what address should this client use?" is often more
expensive than "is address 5 available?".  We don't know "how
much" more expensive.

So this is a "irksome complication" from the server's
perspective.  It definitely affects software design and
implementation choices, although mildly.

The first part of my pet peeve is that the protocol has pitted
these two against each other, and has chosen that the server
should be complicated to simplify the client.  It's obviously
my own opinion that the simplification does not justify the
complication, but that's mainly where this peeves me.

The second part of my pet peeve here has to do with a class of
software implementer who are not well represented at IETF
(possibly because we would collectively consume their twitching
carcass in a savage feeding frenzy).

I speak of those individuals who implement to the RFC in part,
but mostly base their implementations off of what they see on the
wire - they seek to inter-operate with one or at most two big-name
brands, and write their software to process packets that come from
them.  This is much more expedient than reading and understanding
a long document.

As examples, we could speak of DHCPv4 client implementations that
rely on specific client-identifier server behaviour.  We could
speak of the recent reports a DHCP server has had with a client
implementation's interpretation of DNAv4.  Or we could also use
as example certain DNS implementations that treat the compression
to byte 0 tag as a "start of answer" magic value, rather than
properly parsing the packet (and so failing - even crashing - when
the answer was not compressed to the question).

These experiences tell us that "protocol correctness" is not what
usually wins out here.

I sense, based upon what we've seen so far in published
DHCPv6 clients (and my experience in writing a DHCPv6 client)
that most, if not all clients, will choose to provide the IAADDR
contents.  It's just too easy not to.

So I believe allowing a client implementor to understand that
providing the IAADDR is optional is bad guidance.  At some
point, I think we can reasonably worry, this may not inter-operate
universally, even if we don't approve of it.

Consistency is better than flexibility.  Having clients
consistently do the same thing is more advantageous than
the flexibility of being allowed to omit the IAADDR.

-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Bud Millwood <[email-masked]>
Date: Wed, 28 Mar 2007 20:02:59 +0200

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-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 28 Mar 2007 16:15:47 -0400

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:[email-masked]] 
Sent: Wednesday, March 28, 2007 2:03 PM
To: [email-masked]
Subject: Re: [dhcwg] Client IAADDR copying between Advertise and Request

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Mar 2007 23:39:19 -0500

To me it seems that if the client sends the IAADDR, the server's job  
is potentially easier, if address allocation is expensive; otherwise,  
it doesn't make much difference.   So it's probably reasonable to  
strongly suggest that clients send IAADDR when they have it.    
However, they won't always have it.   So servers have to deal with  
the case where the client doesn't remember an old value for IAADDR,  
and thus can't send it.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 29 Mar 2007 11:54:25 +0200

> 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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 29 Mar 2007 08:24:30 -0400

Shane:

I respectfully disagree.

First, there is NO status code defined to communicate that an address
can't be granted, and I think it would be a mistake to do so. It also
means that more round trips have to be performed if the client's request
isn't honored rather than just offering the client usuable addresses.

Second, the text in 18.1.8 (Receipt of Reply Messages) is pretty clear
about the processing a client must do when receiving a reply and many
clients have successfully implemented this without any problems.

Third, the statement that "A client is *not* expecting to get a new
address, and I think in fact should not
have to." goes completely against what IPv6 is all about. A renumbering
event may very will introduce a new address at any time (this is no
different than if using stateless autoconfiguration and reconfiguring
the router to send a new prefix advertisement allowing stateless on that
prefix).

Let's not redesign RFC 3315. There are plenty of implementations that
have been developed that interoperate just fine.

- Bernie

-----Original Message-----
From: Shane Kerr [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 5:54 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] Client IAADDR copying between Advertise and Request

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

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

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

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 29 Mar 2007 08:26:14 -0400

Right ... There's plenty of very efficient data structures that can be
used to make the cost of locating information relatively inexpensive.
That's what we server implementaters are paid to do.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 07:07:18 -0700

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 08:40:22 -0700

> used to make the cost of locating information relatively inexpensive.

...and there are implementation environments that make limitations
on what data structures can feasibly be implemented.

I was thinking specificially of embedded systems when I wrote
this first message, but in DHCPv4 we've also seen a number of
implementations (such as udhcpd for example) whose "special sauce"
was specifically not to implement heavyweight data structures.  One
of the reasons I remember udhcpd managed to do this, was because it
could rely on the client to supply the offered address in the
request.

I guess I could rephrase that second part of my complaint to be that
I'm uncomfortable with making design decisions for software that is
not represented by participation at the IETF.

> That's what we server implementaters are paid to do.

The lucky ones are paid.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 08:50:22 -0700

> the case where the client doesn't remember an old value for IAADDR,  

Hm, I was aiming at Advertise->Request specifically, leaving
"trickle downs" to other behaviour (such as sending a Request
with no IAADDRS in response to a Reply with STATUS_NoBinding)
as an excercise for the reader.

But you are right that since Advertises are cached until the
first retransmission, it is an implementation consideration
wether or not to retain the IAADDR until it is time to send a
Request.

So this makes the 'implementation considerations' possibly about
equal for both sides.  Since the client would have to retain the
server-id, I wonder if the server is still the one getting the
short end of this stick.

And this still leaves me queasy over the prospect that this
protocol feature will produce interoperability failures when
our "second class" implementers start their work.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 08:58:03 -0700

> not represented by participation at the IETF.

Speaking as a long-time participant in the DHCP process, I would  
*love* it if implementors of embedded DHCP clients would avail  
themselves of the resources that the IETF provides, not only in terms  
of free expertise and paid expertise, but also interoperability  
events.    But frequently they don't.   So they have to live with  
decisions that are made in their absence, and until they come here  
and advocate something different, I think it's unreasonable to assume  
that the decisions we are making are wrong for them.   We do very  
much take into account the needs of the embedded world when we write  
protocol specifications - we did for DHCPv4, and we do for DHCPv6.

> The lucky ones are paid.

Yes, very lucky.   But not even slightly germane to the discussion.    
If you want to work on a DHCP server for free, good for you, but you  
don't get to complain about the protocol just because you're not  
getting paid.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 09:02:11 -0700

> server-id, I wonder if the server is still the one getting the

Well, sure, but the DUID is an identifier.   If the server wants to  
provisionally allocate an address to the client at advertise time,  
then doing the lookup at request time based on DUID isn't much  
different than doing a lookup based on IP address - they're both  
about the same size, and probably best hashed.   So I don't think  
there's any particular win for the server in the advertise case if  
the client sends the IAADDR - the only thing that's different is  
which key you use.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 10:10:19 -0700

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

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 10:17:39 -0700

> the client sends the IAADDR - the only thing that's different is  

I note with interest that asking the client to retain and provide
the IAADDR in Advertise->Request is not argued as being more than
a "trivial" consideration...at worst being a /second/ field the
client must retain, if it chooses not to keep Advertisements in
their complete form.

I further note with interest that provisional allocations based
on DUID hashes represents an implementation choice made by the
protocol on behalf of the implementor which can not be described
as "trivial".

So, I am not finding a lot here that argues with my core complaints.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 10:26:41 -0700

> don't get to complain about the protocol just because you're not  

Conversely, the fact that some people are paid to write DHCPv6
software does not justify excessive complexity.  One might wonder
if the purpose of such complexity were for the purpose of ensuring
that only economically strong positions were capable of
implementation.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 10:57:04 -0700

> So, I am not finding a lot here that argues with my core complaints.

The point is simply that your core complaints don't seem to me to be  
talking about something that I think you can really call a problem.    
What you are proposing is an optimization, not a bug fix.   My  
previous message talked about why I don't think it's an important  
optimization.   But aside from that, what you're proposing actually  
creates an interoperability risk in order to get this optimization.    
I thought the risk was fairly obvious, so I focused on why it wasn't  
a particularly important optimization, but maybe it's worthwhile to  
explore the risk a bit further - I hadn't really thought it through,  
but just assumed that it would be risky.   More detailed analysis  
confirms that theory:

One way to interpret what you are proposing is to say that the DHCP  
server could be allowed to fail in the face of a missing IAADDR in a  
DHCP Request.   Or it could be allowed to succeed.   So perhaps  
you're proposing that neither behavior is wrong, but that it's  
worthwhile to allow it to succeed.

But in fact, if you make succeeding when no IAADDR is given optional,  
then you create an interoperability problem.   Most client  
implementors simply take a DHCP server and try their client against  
it; when it works, they assume that they have interoperability.   
Getting them to make changes beyond this is hard - in most cases it  
doesn't happen, particularly if they test against a very commonly  
used server.   What happens instead is that DHCP server implementors  
have to account for quirks in the client's behavior.

So consider what happens if the DHCP server they test against  
supports the 3315 behavior, rather than your 3315bis behavior, which  
is optional.   In that case, the client may be implemented assuming  
that it needn't send the IAADDR option.   And since this works  
against the server they're testing with, they assume their client  
follows the standard, and they burn it into ROMs and ship it out.

If succeeding when no IAADDR is given is required, rather than  
optional, then no such interoperability problem occurs.   So I think  
the change you propose, while it sounds nice from an implementation  
perspective, is not really a good idea.

You could also propose requiring the DHCP server *not* to succeed if  
IAADDR is not present.   The problem there is that the cat is already  
out of the bag - there are quite a few server implementations.    
While it's possible that we could put the toothpaste back in the tube  
at this point, I think that if we were to make this a MUST NOT, we'd  
get minimal or at least slow compliance, and so in all likelihood the  
DHCP server that the client implementor would test against would be  
in spec for 3315, but out of spec for 3315bis.   So this doesn't  
solve the interoperability problem your proposed change creates -  
even though 3315bis *requires* the behavior you want, in practice  
that behavior isn't really required, so we can't count on servers  
implementing it.

So what this boils down to is that whether 3315bis contains the  
changes you want or not, I think you're going to have to implement to  
3315 - your server is going to have to work when the client doesn't  
send IAADDR.   So even though your changes are not wrong in the  
abstract, I think they provide no practical benefit to you, and  
significant risk to all of us.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 11:00:02 -0700

> then you create an interoperability problem.   Most client  

Actually, I was arguing that the server should fail if it receives
a request with no IAADDR.  That is, to make it mandatory for
clients to supply an IAADDR in Requests (and this means we have
to drop some other unimportant optimiations).

I'm glad we could come to agreement.

-- 
ISC Training!  http://www.isc.org/training/  [email-masked]
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 11:08:52 -0700

> that only economically strong positions were capable of

Sure, but there's no excessive complexity here.   This is a matter of  
an extra associative array lookup, basically.   Unless you're  
seriously proposing taking out support for deprecating IP addresses  
during renumbering, which I suppose would make the protocol less  
complex, in exchange for a huge loss of functionality.

The point is that if you have an argument to make, there must be a  
technical basis for making it, or a user story that backs up your  
argument.   Talking about the cost of writing code, particularly code  
you've already written, is just off-topic.   Proposing that the  
complexity here was motivated by a desire to shut out open source  
vendors is weird.   The ISC DHCP server implements failover, for  
Heaven's sake.   This is trivial in comparison.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 11:14:17 -0700

> to drop some other unimportant optimiations).

Oh, okay.   So did you read the second half of my message, where I  
explained why this isn't going to do you any good?

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 11:45:24 -0700

On Thu, Mar 29, 2007 at 11:08:52AM -0700, Ted Lemon wrote:
> Sure, but there's no excessive complexity here.

This is complexity with no reasonable justification, which is
therefore excessive in my opinion.

>  This is a matter of  
> an extra associative array lookup, basically.

Perhaps.  It is server's protocol complexity pitted against a
veritable no-op in the client.  We can agree on that I think,
except that you haven't stated an acceptance that this is a
no-op for the client.

>  Unless you're  

There's no reason you can't deal with deprecated IP addresses during
renumbering inbetween Advertise and Request by asking clients to
return to Solicit, rather than adding complexity to the server.

There is no reason to drop address renumbering support through
deprecation means since that all starts after the Request's Reply
is received by the client.

There is an argument on that topic in another thread.

> argument.

I stand by my original complaint as being both a techncial
argument, and a conern of user experiences to come in the
future.  It is my opinion from the comments garnered so far
that there has been no substantive counter to that argument.

I'm sorry you don't agree.

>  Proposing that the  
> vendors is weird.

I don't remember saying 'open source'.  I stand by what I said.

>  The ISC DHCP server implements failover, for  

Actually, I have a salary.

I find it very curious, Ted, that you direct these comments at me,
who merely replied to Bernie's statement that was contrapositive
to mine.

Twice now.

Why isn't Bernie the target of all this?

Why is it okay to say that complexity is fine since we're all paid
to do it, but it's not okay to say that complexity can not be
justified by the fact that implementers have economic interests?

Ted, this is hypocritical.

In my opinion, complexity can only be justified by the feature(s)
it supports.  I personally will accept no other argument.

I'm tired of these Sophist antics.  Don't expect any replies from
me for a few days.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 12:11:04 -0700

> Actually, I have a salary.

Then why are you making claims about what people who are not being  
paid to do DHCP work are experiencing?   If we are creating problems  
for these people, why aren't we hearing from them here?   Were you  
asked by such a person to raise this issue here?   If so, can you  
tell us who it was?   Can't they participate?   Do they not have email?

> Why isn't Bernie the target of all this?

David, you are the one with whom I am disagreeing.   Why would I be  
debating Bernie, with whom I agree?   And why the ad hominem?   If  
this is about technical stuff, why all this verbiage questioning my  
motivation?

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 29 Mar 2007 17:08:30 -0400

David:

I guess the statement about being paid was somewhat out of line. There
are indeed folks implementing servers that may not be paid -- they have
other motivations, whatever they are.

The point I was trying to make is that your argument is that it isn't as
efficient for your server. Well, make it efficient if you care; don't if
you don't. That's your choice as a software engineer. And, often what
distinguishes one product from another is performance. And, that usually
doesn't happen by accident.

I don't think you can ask the community to change the protocol just
because it will work better with your implementation?

I believe I (and Ted) have presented sufficient arguments to keep things
as they are -- certainly a 3315bis could recommend that clients send the
IAADDRs/IAPREFIXs in the Request that they received in the Advertise (in
a Solicit/Advertise/Request/Reply sequence). But that is only a
recommendation, definitely not MUST (and even not a SHOULD; though
should is OK).

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 15:13:36 -0700

> I guess the statement about being paid was somewhat out of line. There

No it wasn't, I think you were joking, and I was poking fun back at
you.

> efficient for your server.

No, that wasn't it at all.  I sensed it was a mistake to send such
a long message to start this thread.  I probably should have waited
until I could figure out how to condense it.

Let's start over again.

This is specifically the Advertise->Request case.  I am aware there
is a whole other subthread going on here, hijacked off my complaint
here, which is vaguely IAADDR related and applies to Request/Renew/
Rebind.  It's also more familiar since we talked it to death in AMS.

/This/ part of the thread is about the Advertise->Request IAADDR
being optional for the client.  It is not about how the server
reacts.  It is not about how the server /should/ react.  It is,
however, about how some servers might react in the future.

The reality I have observed from clients implemented so far, is that
everyone provides the IAADDR from the Advertise in their Request.

So;

1) Making this optional was a bad move.  Picking a no-op client
   optimization no one uses which also affects DHCP server
   implementation was a mistake.

   *) "Keeping this protocol element serves no useful purpose."

2) "Those kinds of people" who implement to what they see on the wire,
   will wind up not allowing clients to forget to include the IAADDR
   anyway.  If we wanted to save ourselves some headache, we might
   want to consider doing something about that today since we're not
   really using this anyway.

   *) "Letting client implementers believe they have a choice is bad
       guidance."

That's as small as I can make it.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 29 Mar 2007 15:18:13 -0700

> to drop some other unimportant optimiations).

Oops.  Typing too fast.

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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2007 15:28:58 -0700

> mis-written (s/should/might/ maybe).  The second sentence is

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?

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 30 Mar 2007 13:15:52 -0400

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

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 30 Mar 2007 16:36:30 -0700

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

> the same for the Solicit and Request, but I don't believe that is the

Nope.  Not sure what this is about.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 30 Mar 2007 20:48:50 -0400

>going to find themselves incompatible with servers that are written

Your quote on your signature is interestingly appropriate for this

>Nope.  Not sure what this is about.

Must have been someone else; sorry.

Cheers.

- Bernie

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 30 Mar 2007 18:54:57 -0700

> >Software Engineer		you'll just have to do it again." 

I think it also applies to RFC writers, especially those who
are producing 'bis' documents.

---

From: Bud Millwood <[email-masked]>
Date: Sat, 31 Mar 2007 11:11:38 +0200

To all in this thread:

Can we please keep this discussion on a more professional level? I'm concerned 
with the defensive posturing. And I would prefer not to read personal 
sleights.

Bud Millwood
Weird Solutions, Inc.