On Fri, Oct 08, 2010 at 05:36:48PM +0200, [email protected] wrote: > If there is a real issue with defining two DHCPv6 options (which I don't > see),
The problem of defining two options that convey the same configuration
point is a problem we call "aliasing." Section 6 ("Avoid Aliasing") of
draft-ietf-dhc-option-guidelines [1] is dedicated to discuss it, and
concludes with the advice to choose one natural format for the option.
In summary, it causes implementation confusion when the configuration
value for one knob is present in multiple places in the packet - a
resolution algorithm must therefore be defined. You could say that
one of the IESG criticisms of the AFTR domain name option was that the
normative language to enforce this hierarchy is heavy, and unlikely to
actually be observed by casual implementers. It creates complication,
and our experience is that complication creates problems. Worse, in
this case it requires that the individual operator know the normative
requirements of the configuration they write (you are REQUIRED to
provide an IPv4 address, and PERMITTED to also provide a domain name
to clients that support that option).
The only advantage of defining multiple options for the same
configuration value is that such a heavy-handed set of normative
requirements _can_ be defined to ensure that clients are clearly
informed of what the minimum requirements are.
> an alternative would be to define one option with a sub-code field. This
> field indicates whether the option carries an IP address or a name option.
Which is section 5 of the same draft[1], "Conditional Formatting is
Hard."
DHCP software has to be designed to allow the operator and users to
use new options that weren't defined at the time the software was
released - or for example are defined by vendors. Conditional format
bytes have not entered the mainstream of the mechanisms offered by
today's software, if even one implementation supports such a mechanism
it is unknown to me.
So the use of conditional formatting places adoption of the option on
the 5-year software development cycle, new code must be written to use
the option in both client and server, so it cannot realistically be
touched by mortals until then.
Conditional formatting also removes the question of choice from the
DHCP client software, which often prefers to implement the least that
is required. Since you cannot enumerate the formats you support, and
you cannot expect a DHCP server to translate formats, a client must
support all formats (and all future formats!). This means for example
a B4 client that might need a DNS recursive server configuration for
no other purpose than to locate its AFTR endpoint address must carry
along with it a recursive stub resolver specifically for that purpose.
It is a non-starter, in my opinion.
A third option that has been suggested, through the years, is to define
an encapsulated option space - "sub options." This is a DHCP level
option that contains code-length-values, and so each different format
for the configuration parameter is given a unique code. This has all
the same problems as the Aliasing problem, except that it offers an
opportunity to define a sub-option code that allows a client to
advertise what options it supports (a sub-option-request-sub-option).
I don't think there are any major criticisms of this approach except
that it again requires new code in both client and server.
[1] Hankins, D., "Guidelines for Creating new DHCP Options",
draft-ietf-dhc-option-guidelines-05, February 2009.
--
David W. Hankins BIND 10 needs more DHCP voices.
Software Engineer There just aren't enough in our heads.
Internet Systems Consortium, Inc. http://bind10.isc.org/
pgpl3Q6Wa2jwH.pgp
Description: PGP signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
