[dnsext] Building structured extensibility into EDNS0(bis)

[Alfred Hönes <[e-mail]>]

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: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+