< draft-andrews-edns1-00.txt		draft-andrews-edns1-01.txt >
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Expires: October 17, 2014 April 15, 2014		Expires: October 18, 2014 April 16, 2014
	EDNS Version 1		EDNS Version 1 (EDNS(1))
	draft-andrews-edns1-00.txt		draft-andrews-edns1-01.txt
	Abstract		Abstract
	It is impracticable to deploy new EDNS options, with EDNS version 0,		It is impracticable to deploy new EDNS options, with EDNS version 0,
	on a global scale due to inconsistent server behaviour in deployed		on a global scale due to inconsistent server behaviour in deployed
	servers when a EDNS option is present in the query. Most existing		servers when a EDNS option is present in the query. Most existing
	EDNS option deployment has been small scale between essentially		EDNS option deployment has been small scale between essentially
	consenting implementations.		consenting implementations.
	When EDNS options were added to every outgoing recursive query made		When EDNS options were added to every outgoing recursive query made
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 17, 2014.		This Internet-Draft will expire on October 18, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. EDNS Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Removing Ambiguity . . . . . . . . . . . . . . . . . . . . . . 3
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3		3. EDNS Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 3		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	5.1. Normative References . . . . . . . . . . . . . . . . . . . 4		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.2. Informative References . . . . . . . . . . . . . . . . . . 4		6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4		6.2. Informative References . . . . . . . . . . . . . . . . . . 4
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Introduction		1. Introduction
	Extended DNS (EDNS) supports adding EDNS options to the request.		Extended DNS (EDNS) supports adding EDNS options to the request.
	Unfortunately it was not clear in the original specification [RFC		Unfortunately it was not clear in the original specification [RFC
	2671] that unknown EDNS options should be ignored. The updated EDNS		2671] that unknown EDNS options should be ignored. The updated EDNS
	specification [RFC 6891] makes ignoring unknown EDNS options a		specification [RFC 6891] makes ignoring unknown EDNS options a
	explicit requirement but failed to bump the EDNS version number.		explicit requirement but failed to bump the EDNS version number.
	Currently there are EDNS version 0 servers that ignore unknown EDNS		Currently there are EDNS version 0 servers that ignore unknown EDNS
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	present. Those that return REFUSED 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		present and presumably those that return NOTIMP (though the author
	has not seen one).		has not seen one).
	FORMERR, REFUSED and NOTIMP are all returned from servers that do not		FORMERR, REFUSED and NOTIMP are all returned from servers that do not
	support EDNS. It is impracticable for clients to have yet more		support EDNS. It is impracticable for clients to have yet more
	overloading of these error codes and more trial and error to workout		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		what is and is not supported when there is a clear method available
	to resolve the differences.		to resolve the differences.
			There has also been observed ambiguity when responding query types
			that are not supported by a server resulting NOTIMP, FORMERR,
			SERVFAIL and REFUSED answers from servers rather than the expected
			result codes SUCCESS (no data exist) or NAME ERROR responses
			depending apon whether the names exists or not which is implictly
			implied by [RFC 1034], Section 4.3.2 and further by [RFC 3597].
			EDNS version 1 makes returning SUCCESS (no data exist) or NAME ERROR
			when a type is not supported by the server a explict requirement
			rather than NOTIMP, FORMERR, SERVFAIL REFUSED or any other error
			code.
	This document requests EDNS version 1 be assigned and that the EDNS		This document requests EDNS version 1 be assigned and that the EDNS
	behaviour be that of [RFC 6891] with the exception of the version		behaviour be that of [RFC 6891] with the exception of the version
	being 1 rather than 0. EDNS version 1 clients then will have well		being 1 rather than 0. EDNS version 1 clients then will have well
	defined behaviour when sending unknown EDNS options (they should be		defined behaviour when sending unknown EDNS options (they should be
	ignored) to EDNS version 1 servers. BADVERS to EDNS version 0		ignored) to EDNS version 1 servers. BADVERS to EDNS version 0
	servers and FORMERR, REFUSED, NOTIMP to servers that do not support		servers and FORMERR, REFUSED, NOTIMP to servers that do not support
	EDNS and return a error code.		EDNS and return a error code.
	This is effectively a protocol reset for EDNS.		This is effectively a protocol reset for DNS and EDNS.
	2. EDNS Version 1		2. Removing Ambiguity
			Removing ambiguity in responses in important as it allows a client to
			cleanly decide based on error codes what to do, rather than doing
			trial and error to discover the server's behaviour.
			EDNS version 1 addresses two observed sources of ambiguity, EDNS
			version 0 with unknown options and unknown query type response
			handling.
			3. EDNS Version 1
	EDNS version one behaviour is identical to that described in [RFC		EDNS version one behaviour is identical to that described in [RFC
	6891] with the exception to that the EDNS version is assigned to 1.		6891] with the exception to that the EDNS version is assigned to 1.
	3. IANA Considerations		4. IANA Considerations
	This document be the reference document for EDNS version 1.		This document be the reference document for EDNS version 1.
	4. Security Considerations		5. Security Considerations
	The document does not introduce any security issues that are not		The document does not introduce any security issues that are not
	addressed in [RFC 6891].		addressed in [RFC 6891].
	5. References		6. References
	5.1. Normative References		6.1. Normative References
			[RFC 1034]
			Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
			STD 13, RFC 1034, November 1987.
			[RFC 3597]
			Gustafsson, A., "Handling of Unknown DNS Resource Record
			(RR) Types", RFC 3597, September 2003.
	[RFC 6891]		[RFC 6891]
	Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms		Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.		for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
	5.2. Informative References		6.2. Informative References
	[RFC 2671]		[RFC 2671]
	Vixie, P., "Extension Mechanisms for DNS (EDNS0)",		Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
	RFC 1999, August 1999.		RFC 1999, August 1999.
	Author's Address		Author's Address
	M. Andrews		M. Andrews
	Internet Systems Consortium		Internet Systems Consortium
	950 Charter Street		950 Charter Street
End of changes. 12 change blocks.
	18 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/