Re: [dnsext] Re: Building structured extensibility into EDNS0(bis)

[Bob Halley <Bob.Halley@nominum.com>]

On 13 Nov 2009, at 20:05, Alfred HÎnes wrote:

> On 13 Nov 2009 08:58:44 +0100, W.C.A. Wijngaards wrote:
>> 
>> On 11/13/2009 05:21 AM, Stephane Bortzmeyer wrote:
>>> Alfred HÎnes <ah@TR-Sys.de> wrote
>>>> d)  As a result of c), I suggest to assign two functional bits from
>>>>    the most significant nibble of the EDNS OPTION-CODE for
>>>>    "must understand" (M) and "echo" (E); two bits remain reserved
>>>>    (res) for future sepcification and are set to zero currently.
>>> It seems a very good plan to me.
>> 
>> I wonder how a resolver would detect that the other end supports M and E
>> bits.
>> 
>> Best regards,
>>   Wouter
> 
> Admittedly, that's a dilemma.

It's a real problem.  If the M bit is to to be useful, you have to know that an implementation supports it.  Many implementations today will simply ignore unknown options.  So you're going to have to do one of:

	1) probe for M support somehow (maybe using an option that the server has to echo back if it understands)

	2) require that any "M" option always causes an option to be added to the response in an aware implementation

	3) increment the EDNS version number

IMO, #1 adds yet more latency and complexity and is best avoided.  #2 is equivalent to what the -bis draft recommends ("signaled acknowledgement"), but adds noise M and E bits to the option type.  #3 could work, but I'd rather we didn't try EDNS1 until EDNS0 was nearly universally understood.

I favor the approach taken in the -bis draft over the idea of M & E bits.

/Bob