draft-ietf-dnsext-rfc2671bis-edns0-09.txt   draft-ietf-dnsext-rfc2671bis-edns0-10.txt 
DNSEXT Working Group J. Damas DNSEXT Working Group J. Damas
Internet-Draft M. Graff Internet-Draft Bond Internet Systems
Obsoletes: 2671, 2673 P. Vixie Obsoletes: 2671, 2673 M. Graff
(if approved) Internet Systems Consortium (if approved)
Intended status: Standards Track August 13, 2012 Intended status: Standards Track P. Vixie
Expires: February 14, 2013 Expires: July 4, 2013 Internet Systems Consortium
December 31, 2012
Extension Mechanisms for DNS (EDNS(0)) Extension Mechanisms for DNS (EDNS(0))
draft-ietf-dnsext-rfc2671bis-edns0-09 draft-ietf-dnsext-rfc2671bis-edns0-10
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 requestors to advertise their capabilities to responders. This allow requestors to advertise their capabilities to responders. This
document describes backward compatible mechanisms for allowing the document describes backward compatible mechanisms for allowing the
protocol to grow. protocol to grow.
This document updates the EDNS(0) specification (and obsoletes RFC This document updates the EDNS(0) specification (and obsoletes RFC
2671) based on feedback from deployment experience in several 2671) based on feedback from deployment experience in several
implementations. It also closes the IANA registry for extended implementations. It also obsoletes RFC 2673 ("Binary Labels in the
labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Domain Name System") and adds considerations on the use of extended
Labels in the Domain Name System") which depends on the existence of labels in the DNS.
extended labels.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 14, 2013. This Internet-Draft will expire on July 4, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 6, line 27 skipping to change at page 6, line 27
specifies the label type; the basic DNS specification [RFC1035] specifies the label type; the basic DNS specification [RFC1035]
dedicates the two most significant bits of that octet for this dedicates the two most significant bits of that octet for this
purpose. purpose.
[RFC2671] defined DNS label type 0b01 for use as an indication for [RFC2671] defined DNS label type 0b01 for use as an indication for
Extended Label Types. A specific Extended Label Type was selected by Extended Label Types. A specific Extended Label Type was selected by
the 6 least significant bits of the first octet. Thus, Extended the 6 least significant bits of the first octet. Thus, Extended
Label Types were indicated by the values 64-127 (0b01xxxxxx) in the Label Types were indicated by the values 64-127 (0b01xxxxxx) in the
first octet of the label. first octet of the label.
Extended Label Types are difficult to use due to lack of support in Extended Label Types are extremely difficult to deploy due to lack of
clients and intermediate gateways as described in [RFC3363] which support in clients and intermediate gateways as described in
moved [RFC2673] to experimental status, and [RFC3364], which [RFC3363] which moved [RFC2673] to experimental status, and
describes the pros and cons. [RFC3364], which describes the pros and cons. As such proposals that
contemplate extended labels SHOULD weigh this deployment cost against
Therefore, this document obsoletes [RFC2673] and deprecates the use the possibility of implementing functionality in other ways.
of Extended Label Types.
Implementations MUST NOT generate or pass Extended Labels in their Finally, implementations MUST NOT generate or pass Binary Labels in
communications. Additionally, IANA has been requested to close their communications as they are now deprecated.
registration of further Extended Label Types in the "DNS Label Types"
Registry so that no further registrations will be permitted.
6. The OPT pseudo-RR 6. The OPT pseudo-RR
6.1. OPT Record Definition 6.1. OPT Record Definition
6.1.1. Basic elements 6.1.1. Basic elements
An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
additional data section of a request. additional data section of a request.
skipping to change at page 15, line 38 skipping to change at page 15, line 38
A.2. Changes since -02 A.2. Changes since -02
o Specified the method for allocation of constants. o Specified the method for allocation of constants.
o Cleaned up a lot of wording, along with quite a bit of document o Cleaned up a lot of wording, along with quite a bit of document
structure changes. structure changes.
Authors' Addresses Authors' Addresses
Joao Damas Joao Damas
Internet Systems Consortium Bond Internet Systems
950 Charter Street Av Albufera 14
Redwood City, California 94063 S.S. Reyes, Madrid 28701
US ES
Phone: +1 650.423.1312 Phone: +1 650.423.1312
Email: joao@isc.org Email: joao@bondis.org
Michael Graff
Internet Systems Consortium
950 Charter Street
Redwood City, California 94063
US
Phone: +1 650.423.1304 Michael Graff
Email: mgraff@isc.org
Email: explorer@flame.org
Paul Vixie Paul Vixie
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, California 94063 Redwood City, California 94063
US US
Phone: +1 650.423.1301 Phone: +1 650.423.1301
Email: vixie@isc.org Email: vixie@isc.org
 End of changes. 10 change blocks. 
34 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/