<?xml version="1.0"?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc toc="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-andrews-edns1-00.txt">
  <front>
    <title abbrev="EDNS(1)">EDNS Version 1</title>
    <author initials="M." surname="Andrews" fullname="M. Andrews">
      <organization abbrev="ISC">Internet Systems Consortium</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <region>CA</region>
          <code>94063</code>
          <country>US</country>
        </postal>
        <email>marka@isc.org</email>
      </address>
    </author>
    <date month="April" year="2014"/>
    <abstract>
      <t>
	It is impracticable to deploy new EDNS options, with EDNS
	version 0, on a global scale due to inconsistent server
	behaviour in deployed servers when a EDNS option is present
	in the query.  Most existing EDNS option deployment has been
	small scale between essentially consenting implementations.
      </t>
      <t>
	When EDNS options were added to every outgoing recursive
	query made it became clear that trial and error to discover
	the level of EDNS version 0 support was not practicable.
      </t>
      <t>
	This document request that EDNS version 1 be assigned so that
	consistent well defined behaviour can be seen when a EDNS option
	is present.
      </t>
    </abstract>
  </front>
  <middle>
    <section toc="yes" anchor="intro" title="Introduction">
      <t>
	Extended DNS (EDNS) supports adding EDNS options to the
	request.  Unfortunately it was not clear in the original
	specification <xref target="RFC 2671" /> that unknown EDNS
	options should be ignored.  The updated EDNS specification
	<xref target="RFC 6891" /> makes ignoring unknown EDNS
	options a explicit requirement but failed to bump the EDNS
	version number.
      </t>
      <t>
	Currently there are EDNS version 0 servers that ignore
	unknown EDNS options.  Those that return FORMERR when unknown
	EDNS options are present.  Those that return BADVERS when
	unknown EDNS options are present.  Those that return REFUSED
	when unknown EDNS options are present and presumably those
	that return NOTIMP (though the author has not seen one).
      </t>
      <t>
	FORMERR, REFUSED and NOTIMP are all returned from servers that
	do not support EDNS.  It is impracticable for clients to have
	yet more overloading of these error codes and more trial and
	error to workout what is and is not supported when there is a
	clear method available to resolve the differences.
      </t>
      <t>
	This document requests EDNS version 1 be assigned and that
	the EDNS behaviour be that of <xref target="RFC 6891" />
	with the exception of the version being 1 rather than 0.
	EDNS version 1 clients then will have well defined behaviour
	when sending unknown EDNS options (they should be ignored)
	to EDNS version 1 servers.  BADVERS to EDNS version 0 servers
	and FORMERR, REFUSED, NOTIMP to servers that do not support
	EDNS and return a error code.
      </t>
      <t>
	This is effectively a protocol reset for EDNS.
      </t>
    </section>
    <section toc="yes" anchor="Version1" title="EDNS Version 1">
      <t>
	EDNS version one behaviour is identical to that described
	in <xref target="RFC 6891" /> with the exception to that
	the EDNS version is assigned to 1.
      </t>
    </section>
    <section toc="yes" anchor="iana" title="IANA Considerations">
      <t>
	This document be the reference document for EDNS version 1.
      </t>
    </section>
    <section toc="yes" anchor="security" title="Security Considerations">
      <t>
	The document does not introduce any security issues that are
	not addressed in <xref target="RFC 6891" />.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC 6891">
        <front>
          <title>Extension Mechanisms for DNS (EDNS(0))</title>
          <author initials="J." surname="Damas" fullname="J. Damas" />
          <author initials="M." surname="Graff" fullname="M. Graff" />
          <author initials="P." surname="Vixie" fullname="P. Vixie" />
          <date month="April" year="2013" />
        </front>
        <seriesInfo name="STD" value="75" />
        <seriesInfo name="RFC" value="6891" />
      </reference>
    </references>
    <references title="Informative References">
     <reference anchor="RFC 2671">
        <front>
          <title>Extension Mechanisms for DNS (EDNS0)</title>
          <author initials="P." surname="Vixie" fullname="P. Vixie" />
          <date month="August" year="1999" />
        </front>
        <seriesInfo name="RFC" value="1999" />
      </reference>
    </references>
  </back>
</rfc>
