Dear David, Thank you for this clarification.
If we adopt the sub-option scheme with the following values: 1 AFTR IP Addres 2 AFTR Name And if the language is clear to state the client must include both IP address and name sub-options and the Server MUST answer with only one sub-option (IP address or name sub option). Is there any aliasing problem in such case? I went through http://tools.ietf.org/html/draft-ietf-dhc-option-guidelines-06#section-8 and the main reco of that section is "it is not advisable to group options that may not be requested at the same time by the same client under an encapsulated space." Which is not the case of the aftr option. Cheers, Med -----Message d'origine----- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de David W. Hankins Envoyé : mardi 12 octobre 2010 21:16 À : Softwires WG Cc : draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org; Softwire Chairs Objet : Re: [Softwires] DHCPv6 AFTR name option is needed On Fri, Oct 08, 2010 at 05:36:48PM +0200, mohamed.boucad...@orange-ftgroup.com 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/ ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
