Client IAADDR copying between Advertise and Request

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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Client IAADDR copying between Advertise and Request

Thread: Client IAADDR copying between Advertise and Request