[dnsext] Building structured extensibility into EDNS0(bis)
Alfred Hönes <ah@TR-Sys.de> Thu, 12 November 2009 20:40 UTC
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009003A679C; Thu, 12 Nov 2009 12:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.555
X-Spam-Level: ***
X-Spam-Status: No, score=3.555 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKbn3TtjLDsf; Thu, 12 Nov 2009 12:40:48 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 333453A67A7; Thu, 12 Nov 2009 12:40:48 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1N8gN9-000EtN-6z for namedroppers-data0@psg.com; Thu, 12 Nov 2009 20:34:27 +0000
Received: from [213.178.172.147] (helo=TR-Sys.de) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <A.Hoenes@TR-Sys.de>) id 1N8gN2-000EsR-DA for namedroppers@ops.ietf.org; Thu, 12 Nov 2009 20:34:22 +0000
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA124908000; Thu, 12 Nov 2009 21:33:20 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id VAA10313; Thu, 12 Nov 2009 21:33:14 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200911122033.VAA10313@TR-Sys.de>
Subject: [dnsext] Building structured extensibility into EDNS0(bis)
To: draft-ietf-dnsext-rfc2671bis-edns0@cabernet.tools.IETF.ORG, namedroppers@ops.ietf.org
Date: Thu, 12 Nov 2009 21:33:14 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>
The recent discussion on my "RR Group Query" proposal (*) has lead me back to another proposal I had made last year during the FR debate, but which had not attracted much response since. I have been called for submitting it in enough detail for discussion and subsequent inclusion in the rfc2671bis draft. (*) work on draft has been started; please be patient, more input in unicast welcome!) As the name says, EDNS0 is an Extension mechanism for DNS, and its hook for extensibility is with the {attribute,value} pairs (aka EDNS0 Options) grouped in the RDATA portion of the OPT RR placed in the Additional section of both Queries and Responses. Good protocol extension design (cf. draft-iab-extension-recs) ensures provisions for mechanisms allowing seemless gradual deployment of protocol extensions making use of the fundamental extension mechanisms built into a base protocol. Many successful protocols have built-in clever hooks to signal intended behavior wrt subordinate protocol elements in case the recipient of a message does not "understand" (or "support" or "has enabled the use of") a particular protocol object. This gives the designer of the extension object the choice of some default processing implemented by all speakers of the protocol, independent of their support for a specific extension object, and thus allows to achieve clever deployment strategies. Examples include Class-Types in RSVP, LSA types in OSPF (in particular in OSPFv3) and similar constructs in various routing protocols, "Mandatory/Optional" discriminators in PKIX structures, etc. The identifier for EDNS0 options is the 16-bit OPTION-CODE, so far an unstructured value subject to IANA assignment. In the 10 years since the publication of the EDNS0 specification, RFC 2671, only a handful OPTION-CODE values have been assigned by IANA (or "came into use") : IANA: Value Name Status Reference ------- ----------- -------- ----------- 0 reserved [RFC2671] 1 LLQ On-hold [draft-sekar-dns-llq] 2 UL On-hold [draft-sekar-dns-ul] 3 NSID Standard [RFC5001] 4 reserved [draft-cheshire-edns0-owner-option] 5-65535 -unassigned- [RFC2671] "known to the list": 5 "used" [draft-hubert-ulevitch-edns-ping] Note: I could not find record of RFC 2671 having reserved value 0; ++++ instead, RFC 2671 has reserved value 65535 for future extensions, as does the current rfc2671bis-edns0 draft. I suggest that rfc2671bis-edns0 also registers value 0 as -reserved- . RFC 2671 is silent about server behavior in face of unknown options. Currently, Section 6.2 of draft-ietf-dnsext-rfc2671bis-edns0-02 says: | Any OPTION-CODE values not understood by a responder or requestor | MUST be ignored. Specifications of such options might wish to | include some kind of signalled acknowledgement. For example, an | option specification might say that if a responder sees option XYZ, | it SHOULD include option XYZ in its response. This is still unsatisfactory, since it unnecessarily restricts the design choices for new EDNS0 options. To further the design of EDNS0 options, I suggest to reclaim the four most significant bits of the EDNS0 OPTION-CODE as functional bits directing the recipient of the option what to do with it in case it does not "support" the option. This seems to be a still conservative and responsible action, with regard to the low demand for EDNS0 Option-Code assignments so far. The following tasks have to be performed to properly design the details: a) propose and achieve consensus on the needed groups of behavioral patterns to be encoded b) assessment of existing use c) based on b): do we need a "legacy" group ? d) fix encoding of groups e) perhaps subdivide groups into assigned by IANA / experimental / private use and decide on IANA policy for the former To give a starting point, here are my provisional contributions (NB: That does not mean I insists on the analysis results and proposals; I simply want to give a reasonable starting point for collecting more input and rapid consensus-building.) a) Classification of default behavior of recipient of query. Observation #1: EDNS0, i.e. the OPT RR, essentially is a hop-by-hop protocol. (RFC 5001 says "not transitive".) Hence no functionality related to "forwarding" needs to be considered. Remaining categories: o "ignore" -- do not send same option in response o "echo" -- copy option unchanged into response o "must understand" -- refuse entire query (extended RCODE: t.b.d.) o "unspecified" -- implementation specific (to be used for legacy code points) [[ DISCUSS: Other valid options? ]] The single change in protocol behavior needed by the introduction of this proposal would be for DNS responders (servers, resolvers) to honor the "must understand" and "echo" semantics if they do not understand the particular option received in these groups, thus making the introduction and gradual deployment of new options much more easier subsequently. b) (Provisional) Analysis by code point for existing definitions/use: 0/65535 : since this code point is reserved as an anchor point for future extensibility, arguably it could be placed in any of the groups given above; maybe: exceptional processing needed anyway, should code point become used some day, so decision does not matter. 1 : The DNS-LLQ service model has been found incompatible with the standard DNS service model and has not been standardized; however, reportedly it is used in specific environments, and notably with mDNS. DNS-LLQ Challenge is underspecified for the case of lack of server support. A non-EDNS0 aware server might respond with RCODE FormErr(1) or NotImp(4), which the draft takes as "non-LLQ capable", but it is silent of the possible case of an EDNS0-aware, yet "non-LLQ capable" server. Assuming the behavior specified in rfc2671bis-edns0-02 would mean "ignore" was a server behavior allowing graceful fallback to standard DNS operation with minimal extra traffic; arguably classification as "must understand" or "unspecified" could also be regarded as appropriate. 2 : DNS-UL also has not been adopted by the IETF, but reportedly it is used in specific environments. Again, the defining draft underspecifies expected server and client behavior in the case of a "non-UL capable" server, but again "ignore" server behavior would allow graceful fallback to standard DNS operation with minimal extra traffic; arguably classification as "must understand" or "unspecified" could also be regarded as appropriate. 3 : RFC 5001 specifies the NSID option as a diagnostics tool. "ignore" seems to be the best default strategy as well. 4 : The EDNS Owner Option is used in specific environments. The specification is silent on deployment/interoperability considerations, but that seems rather irrelevant due to the specific context where the option is used and consenting universal support is assumed. The seems to be tolerant to the "ignore" default behavior, but the mDNS folks might be able to teach us otherwise. 5 : "echo" would be most useful default behavior, but "ignore" is acceptable, and upon potential approvement of the draft a different code point could be assigned. c) (Provisional) Evaluation It looks like there is no need for a "legacy" / "unspecified" group; all existing use cases seem to be compatible with "ignore" behavior as currently specified in rfc2671bis-edns0-02 for *all* EDNS0 options. Thus, it should make sense to include option# 1..5 in the "ignore" group. 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. For instance: +0 (MSB) +1 (LSB) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | OPTION-CODE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ is subdivided as: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 0: | M : E : res : Code | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ In generalization of the reservations mentioned above, I suggest that all OPTION-CODEs with Code 0x000 or 0xFFF be RESERVED for future updates to the EDNS0 RFC, i.e. all OPTION-CODE values of the form 0xy000 and 0xyFFF for y=0..F . Under this regime, - registrations must specify the setting of M and E, and IANA assigns the Code in a manner that a unique, flat 16-bit OPTION-CODE namespace is maintained; - existing registrations and use cases would be interpreted as having M=0 and E=0; - as long as no updating Standards track RFC has been issues, IANA will only assign OPTION-CODE values in the ranges (i) 1- 4094 ... for M=0 and E=0 (ii) 16385-20478 ... for M=0 and E=1 (ii) 32769-36862 ... for M=1 and E=0 (iii) 49153-53246 ... for M=1 and E=1 [ does that make sense? ] - The RESERVED OPTION-CODE 65535 = 0xFFFF remains exempt from the interpretation of M and E for backwards compatibility. e) Currently, the IANA Registry for EDNS Option Codes follows the RFC 5226 "Specification Required" policy, based on RFC 2671, and draft-ietf-dnsext-rfc2671bis-edns0-02 does not alter that. To allow room for protocol experiments, I propose to subdivide the 16 ranges in a uniform manner, reserving one subrange for Experimental use, in the spirit of BCP 82 (RFC 3692), and to allow other SDOs (for instance) make use of specific EDNS0 options, a Private Use range might also make sense. For instance, including the RESERVED code points mentioned above: CODE 0 (0x000 ) ... -RESERVED- Code 1-3839 (0x000-0xEFF) ... Spec. Required Code 3849-4063 (0xF00-0xFDF) ... Private Use Code 4064-4094 (0xFE0-0xFFE) ... Experimental CODE 4095 ( 0xFFF) ... -RESERVED- Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+
- [dnsext] Building structured extensibility into E… Alfred Hönes
- [dnsext] Re: Building structured extensibility in… Stephane Bortzmeyer
- Re: [dnsext] Re: Building structured extensibilit… W.C.A. Wijngaards
- Re: [dnsext] Re: Building structured extensibilit… Alfred Hönes
- Re: [dnsext] Re: Building structured extensibilit… Mark Andrews
- Re: [dnsext] Re: Building structured extensibilit… Bob Halley
- Re: [dnsext] Re: Building structured extensibilit… Andrew Sullivan
- Re: [dnsext] Re: Building structured extensibilit… Alfred Hönes
- Re: [dnsext] Re: Building structured extensibilit… Mark Andrews
- Re: [dnsext] Re: Building structured extensibilit… Mark Andrews
- Re: [dnsext] Re: Building structured extensibilit… Andrew Sullivan
- Re: [dnsext] Re: Building structured extensibilit… Mark Andrews