From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <200911132137.WAA13539@TR-Sys.de>
Subject: Re: [dnsext] Re: Building structured extensibility into EDNS0(bis)
To: Bob.Halley@nominum.com
Date: Fri, 13 Nov 2009 22:37:01 +0100 (MEZ)
Cc: namedroppers@ops.ietf.org
In-Reply-To: <3970352C-C35F-4886-BBF5-D5ECB84D53B3@nominum.com> from Bob
 Halley at Nov "13, " 2009 "12:35:30" pm
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 8bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk

>
> 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.  ...

If that can be consolidated/quantified, that rather good news!

>                           ...  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

#2 is a good design principle anyway, and I would expect it to be used
universally for future mandatory-to-understand (M=1) options.

The benefits of the M bit should be twofold:
-  allow to more clearly signal what's wrong, from the responder side.
-  allow much more graceful treatment of cases with multiple options,
   in particular with mixed M=1 and M=0 options, where I see no
   means to achieve sensical server behavior otherwise, and probing
   indeed might become necessary otherwise if the querier wants to
   insist on at least some of the options as a fallback mechanism.

The important detail I already pointed out, and which is relevant for
the judgement of #3, is that the currently ramping up deployment phase
for IPv6 and DNSSEC will push DNS software updates out, and fast
action _now_ to enable flexibility for the future wrt ENDS will have
a good chance to see rapid deployment -- independent on the specific
details.


BTW:
I'd be particularly interested in the opinions of those who have
drafts with an EDNS option in the pipeline (independent of the
particular state).


  Alfred.