On Tue, Mar 25, 2008 at 02:31:51AM +0800, Santosh Chandwani wrote:
> However, I don't follow
> your argument of why a new option number wouldn't work. There is no
> duality in case where the order of precedence is clearly defined.
As it stands today with the client id option contents and the chaddr
header fields, we have different and incompatible implementations of
client identification. Precedence is unimportant if even in the
presence of clear precedence (as we have today), and universal
implementation of same (as we have today), what you then _do_ with the
field after varies wildly and can be never defined better than "magic
happens."
The problem is with undefined corner cases that historically we are
not very good at capturing. What do you do when the fields are all
the same (modulo formatting, such as a DUID-LL in the new option,
client-id, and chaddr all identical)? What do you do when the client
sends these identical contents unreliably (sometimes not sending an
identity option, sometimes including it later)?
We have this problem today with just two fields; and servers have
different answers, which causes some interoperability headaches at
the worst of times.
Adding a third field for client identification is not a strict
requirement since there are migration strategies without it, also it
would not be compatible with existing deployed servers. So it would
serve only to make the above situation substantially worse in
triplication...especially if it uncovers new corner cases we weren't
aware of. Just by making the situation more complicated than it
already is, it is undesirable.
So although I'm not sure I would agree with Ted that a third
identifier field is a technical impossibility (I suspect this
implication is just a mistake of his writing style), I do agree in
spirit that there are effective barriers from making it a plausible
reality, and hopefully I have explained at least my thinking why.
> DHCID-RR doesn't well for both dual-stacked and multi-homed scenarios.
> Even in single-stack cases (IPv4 alone), RFC 4701 implementations don't
> work in common scenarios such as laptops with both wired as well as
> wireless interfaces if clients don't implement RFC 4361.
This is basically true, but I don't see how a third identifier would
help matters any.
I mentioned at IETF 71 in the hallways to someone that I perceive that
the integration and migration problems set before ddns updates are
going to cause a number of differing "update policies" (as 4703 calls
them) to emerge, and that I think it would be more or less good to
have some formal way to name the different policies and describe their
intentions (calling 4703 "default" perhaps), even with vague
handwaving definitions ("do this, but omit this step").
We saw this at the DHCPv6 bake-off in Philadelphia, when two systems
did interoperate with DHCID RR's, but not until after their owners had
realized they were using different update policies.
I have something of a backlog of drafts to attend to myself, but I do
not wish to hold a monopoly on the above idea...if anyone is willing
to explore it, I think it would be beneficial.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
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
Attachment:
pgpQoIhVWfGGa.pgp
Description: PGP signature
_______________________________________________ dhcwg mailing list dhcwg at ietf.org https://www.ietf.org/mailman/listinfo/dhcwg