< draft-ietf-dnsind-edns0-01.txt		draft-ietf-dnsind-edns0-02.txt >
	DNSIND Working Group Paul Vixie		DNSIND Working Group Paul Vixie
	INTERNET-DRAFT ISC		INTERNET-DRAFT ISC
	<draft-dnsind-edns0-01.txt> January, 1999		<draft-ietf-dnsind-edns0-02.txt> June, 1999
	Extension mechanisms for DNS (EDNS0)		Extension mechanisms for DNS (EDNS0)
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft. Internet-Drafts are working		This document is an Internet-Draft and is in full conformance with
	documents of the Internet Engineering Task Force (IETF), its areas,		all provisions of Section 10 of RFC2026.
	and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF), its areas, and its working groups. Note that
			other groups may also distribute working documents as Internet-
			Drafts.
	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."
	To view the entire list of current Internet-Drafts, please check the		The list of current Internet-Drafts can be accessed at
	"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow		http://www.ietf.org/ietf/1id-abstracts.txt
	Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
	Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific		The list of Internet-Draft Shadow Directories can be accessed at
	Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	The Domain Name System's wire protocol includes a number of fixed		The Domain Name System's wire protocol includes a number of fixed
	fields whose range has been or soon will be exhausted and does not		fields whose range has been or soon will be exhausted and does not
	allow clients to advertise their capabilities to servers. This		allow clients to advertise their capabilities to servers. This
	document describes backward compatible mechanisms for allowing the		document describes backward compatible mechanisms for allowing the
	protocol to grow.		protocol to grow.
	1 - Rationale and Scope		1 - Rationale and Scope
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	3.1. The ``0 1'' label type will now indicate an extended label type,		3.1. The ``0 1'' label type will now indicate an extended label type,
	whose value is encoded in the lower six bits of the first octet of a		whose value is encoded in the lower six bits of the first octet of a
	label. All subsequently developed label types should be encoded using		label. All subsequently developed label types should be encoded using
	an extended label type.		an extended label type.
	3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future		3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future
	expansion of the extended label type code space.		expansion of the extended label type code space.
	4 - OPT pseudo-RR		4 - OPT pseudo-RR
	4.1. The OPT pseudo-RR can be added to the additional data section of		4.1. One OPT pseudo-RR can be added to the additional data section of
	either a request or a response. An OPT is called a pseudo-RR because it		either a request or a response. An OPT is called a pseudo-RR because it
	pertains to a particular transport level message and not to any actual		pertains to a particular transport level message and not to any actual
	DNS data. OPT RRs shall never be cached, forwarded, or stored in or		DNS data. OPT RRs shall never be cached, forwarded, or stored in or
	loaded from master files.		loaded from master files. The quantity of OPT pseudo-RRs per message
			shall be either zero or one, but not greater.
	4.2. An OPT RR has a fixed part and a variable set of options expressed		4.2. An OPT RR has a fixed part and a variable set of options expressed
	as {attribute, value} pairs. The fixed part holds some DNS meta data		as {attribute, value} pairs. The fixed part holds some DNS meta data
	and also a small collection of new protocol elements which we expect to		and also a small collection of new protocol elements which we expect to
	be so popular that it would be a waste of wire space to encode them as		be so popular that it would be a waste of wire space to encode them as
	{attribute, value} pairs.		{attribute, value} pairs.
	4.3. The fixed part of an OPT RR is structured as follows:		4.3. The fixed part of an OPT RR is structured as follows:
	Field Name Field Type Description		Field Name Field Type Description
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 43 ¶
	/ OPTION-DATA /		/ OPTION-DATA /
	/ /		/ /
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	OPTION-CODE (Assigned by IANA.)		OPTION-CODE (Assigned by IANA.)
	OPTION-LENGTH Size (in octets) of OPTION-DATA.		OPTION-LENGTH Size (in octets) of OPTION-DATA.
	OPTION-DATA Varies per OPTION-CODE.		OPTION-DATA Varies per OPTION-CODE.
	4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS		4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
	field) is the number of octets of the largest UDP payload that can be		field) is the number of octets of the largest UDP payload that can be
	reassembled and delivered in the sender's network stack. Note that path		reassembled and delivered in the sender's network stack. Note that path
	MTU, with or without fragmentation, may be smaller than this.		MTU, with or without fragmentation, may be smaller than this.
	4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP		4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
	reassembly buffer. Choosing 1280 on an Ethernet connected requestor		reassembly buffer. Choosing 1280 on an Ethernet connected requestor
	would be reasonable. The consequence of choosing too large a value may		would be reasonable. The consequence of choosing too large a value may
	be an ICMP message from an intermediate gateway, or even a silent drop		be an ICMP message from an intermediate gateway, or even a silent drop
	of the response message. Requestors are advised to retry in such cases.		of the response message.
	4.5.2. Both requestors and responders are advised to take account of the		4.5.2. Both requestors and responders are advised to take account of the
	path's already discovered MTU (if known) when considering message sizes.		path's discovered MTU (if already known) when considering message sizes.
			4.5.3. The requestor's maximum payload size can change over time, and
			should therefore not be cached for use beyond the transaction in which
			it is advertised.
			4.5.4. The responder's maximum payload size can change over time, but
			can be reasonably expected to remain constant between two sequential
			transactions; for example, a meaningless QUERY to discover a responder's
			maximum UDP payload size, followed immediately by an UPDATE which takes
			advantage of this size. (This is considered preferrable to the outright
			use of TCP for oversized requests, if there is any reason to suspect
			that the responder implements EDNS, and if a request will not fit in the
			default 512 payload size limit.)
			4.5.5. Due to transaction overhead, it is unwise to advertise an
			architectural limit as a maximum UDP payload size. Just because your
			stack can reassemble 64KB datagrams, don't assume that you want to spend
			more than about 4KB of state memory per ongoing transaction.
	4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)		4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
	are structured as follows:		are structured as follows:
	+0 (MSB) +1 (LSB)		+0 (MSB) +1 (LSB)
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	0: | EXTENDED-RCODE | VERSION |		0: | EXTENDED-RCODE | VERSION |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	2: | Z |		2: | Z |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that		EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that
	EXTENDED-RCODE value "0" indicates that an unextended		EXTENDED-RCODE value "0" indicates that an unextended
	RCODE is in use (values "0" through "15").		RCODE is in use (values "0" through "15").
	VERSION Indicates the implementation level of whoever sets it.		VERSION Indicates the implementation level of whoever sets it.
	Full conformance with this specification is indicated by		Full conformance with this specification is indicated by
	version ``0.'' Note that both requestors and responders		version ``0.'' Requestors are encouraged to set this to
	should set this to the highest level they implement,		the lowest implemented level capable of expressing a
	that responders should send back RCODE=BADVERS and that		transaction, to minimize the responder and network load
	requestors should be prepared to probe using lower		of discovering the greatest common implementation level
	version numbers if they receive an RCODE=BADVERS.		between requestor and responder. A requestor's version
			numbering strategy should ideally be a run time
			configuration option.
			If a responder does not implement the VERSION level of
			the request, then it answers with RCODE=BADVERS. All
			responses will be limited in format to the VERSION level
			of the request, but the VERSION of each response will be
			the highest implementation level of the responder. In
			this way a requestor will learn the implementation level
			of a responder as a side effect of every response,
			including error responses, including RCODE=BADVERS.
	Z Set to zero by senders and ignored by receivers, unless		Z Set to zero by senders and ignored by receivers, unless
	modified in a subsequent specification.		modified in a subsequent specification.
	5 - Transport Considerations		5 - Transport Considerations
	5.1. The presence of an OPT pseudo-RR in a request should be taken as an		5.1. The presence of an OPT pseudo-RR in a request should be taken as an
	indication that the requestor fully implements the given version of		indication that the requestor fully implements the given version of
	EDNS, and can correctly understand any response that conforms to that		EDNS, and can correctly understand any response that conforms to that
	feature's specification.		feature's specification.
	skipping to change at page 6, line 25 ¶		skipping to change at page 7, line 18 ¶
	Specification,'' RFC 1035, USC/Information Sciences		Specification,'' RFC 1035, USC/Information Sciences
	Institute, November 1987.		Institute, November 1987.
	10 - Author's Address		10 - Author's Address
	Paul Vixie		Paul Vixie
	Internet Software Consortium		Internet Software Consortium
	950 Charter Street		950 Charter Street
	Redwood City, CA 94063		Redwood City, CA 94063
	+1 650 779 7001		+1 650 779 7001
	<paul@vix.com>		<vixie@isc.org>
End of changes. 12 change blocks.
	22 lines changed or deleted		54 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/