idnits 2.17.1 draft-ietf-dnsind-edns0-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-dnsind-edns0-01', but the file name used is 'draft-ietf-dnsind-edns0-01' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 63 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 99 has weird spacing: '...in name emp...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1035' on line 230 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie 3 INTERNET-DRAFT ISC 4 January, 1999 6 Extension mechanisms for DNS (EDNS0) 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 23 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 24 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Abstract 28 The Domain Name System's wire protocol includes a number of fixed 29 fields whose range has been or soon will be exhausted and does not 30 allow clients to advertise their capabilities to servers. This 31 document describes backward compatible mechanisms for allowing the 32 protocol to grow. 34 1 - Rationale and Scope 36 1.1. DNS (see [RFC1035]) specifies a Message Format and within such 37 messages there are standard formats for encoding options, errors, and 38 name compression. The maximum allowable size of a DNS Message is fixed. 39 Many of DNS's protocol limits are too small for uses which are or which 40 are desired to become common. There is no way for implementations to 41 advertise their capabilities. 43 1.2. Existing clients will not know how to interpret the protocol 44 extensions detailed here. In practice, these clients will be upgraded 45 when they have need of a new feature, and only new features will make 46 use of the extensions. We must however take account of client behaviour 47 in the face of extra fields, and design a fallback scheme for 48 interoperability with these clients. 50 2 - Affected Protocol Elements 52 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit 53 word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 54 1-bit flags. The original reserved Z bits have been allocated to 55 various purposes, and most of the RCODE values are now in use. More 56 flags and more possible RCODEs are needed. 58 2.2. The first two bits of a wire format domain label are used to denote 59 the type of the label. [RFC1035 4.1.4] allocates two of the four 60 possible types and reserves the other two. Proposals for use of the 61 remaining types far outnumber those available. More label types are 62 needed. 64 2.3. DNS Messages are limited to 512 octets in size when sent over UDP. 65 While the minimum maximum reassembly buffer size still allows a limit of 66 512 octets of UDP payload, most of the hosts now connected to the 67 Internet are able to reassemble larger datagrams. Some mechanism must 68 be created to allow requestors to advertise larger buffer sizes to 69 responders. 71 3 - Extended Label Types 73 3.1. The ``0 1'' label type will now indicate an extended label type, 74 whose value is encoded in the lower six bits of the first octet of a 75 label. All subsequently developed label types should be encoded using 76 an extended label type. 78 3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future 79 expansion of the extended label type code space. 81 4 - OPT pseudo-RR 83 4.1. The OPT pseudo-RR can be added to the additional data section of 84 either a request or a response. An OPT is called a pseudo-RR because it 85 pertains to a particular transport level message and not to any actual 86 DNS data. OPT RRs shall never be cached, forwarded, or stored in or 87 loaded from master files. 89 4.2. An OPT RR has a fixed part and a variable set of options expressed 90 as {attribute, value} pairs. The fixed part holds some DNS meta data 91 and also a small collection of new protocol elements which we expect to 92 be so popular that it would be a waste of wire space to encode them as 93 {attribute, value} pairs. 95 4.3. The fixed part of an OPT RR is structured as follows: 97 Field Name Field Type Description 98 ------------------------------------------------------ 99 NAME domain name empty (root domain) 100 TYPE u_int16_t OPT 101 CLASS u_int16_t sender's UDP payload size 102 TTL u_int32_t extended RCODE and flags 103 RDLEN u_int16_t describes RDATA 104 RDATA octet stream {attribute,value} pairs 106 4.4. The variable part of an OPT RR is encoded in its RDATA and is 107 structured as zero or more of the following: 109 +0 (MSB) +1 (LSB) 110 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 111 0: | OPTION-CODE | 112 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 113 2: | OPTION-LENGTH | 114 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 115 4: | | 116 / OPTION-DATA / 117 / / 118 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 120 OPTION-CODE (Assigned by IANA.) 122 OPTION-LENGTH Size (in octets) of OPTION-DATA. 124 OPTION-DATA Varies per OPTION-CODE. 126 4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS 127 field) is the number of octets of the largest UDP payload that can be 128 reassembled and delivered in the sender's network stack. Note that path 129 MTU, with or without fragmentation, may be smaller than this. 131 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP 132 reassembly buffer. Choosing 1280 on an Ethernet connected requestor 133 would be reasonable. The consequence of choosing too large a value may 134 be an ICMP message from an intermediate gateway, or even a silent drop 135 of the response message. Requestors are advised to retry in such cases. 137 4.5.2. Both requestors and responders are advised to take account of the 138 path's already discovered MTU (if known) when considering message sizes. 140 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) 141 are structured as follows: 143 +0 (MSB) +1 (LSB) 144 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 145 0: | EXTENDED-RCODE | VERSION | 146 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 147 2: | Z | 148 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 150 EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that 151 EXTENDED-RCODE value "0" indicates that an unextended 152 RCODE is in use (values "0" through "15"). 154 VERSION Indicates the implementation level of whoever sets it. 155 Full conformance with this specification is indicated by 156 version ``0.'' Note that both requestors and responders 157 should set this to the highest level they implement, 158 that responders should send back RCODE=BADVERS and that 159 requestors should be prepared to probe using lower 160 version numbers if they receive an RCODE=BADVERS. 162 Z Set to zero by senders and ignored by receivers, unless 163 modified in a subsequent specification. 165 5 - Transport Considerations 167 5.1. The presence of an OPT pseudo-RR in a request should be taken as an 168 indication that the requestor fully implements the given version of 169 EDNS, and can correctly understand any response that conforms to that 170 feature's specification. 172 5.2. Lack of use of these features in a request must be taken as an 173 indication that the requestor does not implement any part of this 174 specification and that the responder may make no use of any protocol 175 extension described here in its response. 177 5.3. Responders who do not understand these protocol extensions are 178 expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. 179 Therefore use of extensions should be ``probed'' such that a responder 180 who isn't known to support them be allowed a retry with no extensions if 181 it responds with such an RCODE. If a responder's capability level is 182 cached by a requestor, a new probe should be sent periodically to test 183 for changes to responder capability. 185 6 - Security Considerations 187 Requestor-side specification of the maximum buffer size may open a new 188 DNS denial of service attack if responders can be made to send messages 189 which are too large for intermediate gateways to forward, thus leading 190 to potential ICMP storms between gateways and responders. 192 7 - IANA Considerations 194 IANA is hereby requested to assign an RR type code for OPT. 196 It is the recommendation of this document and its working group that 197 IANA create a registry for EDNS Extended Label Types, for EDNS Option 198 Codes, and for EDNS Version Numbers. 200 This document assigns label type 0b01xxxxxx as "EDNS Extended Label 201 Type." We request that IANA record this assignment. 203 This document assigns extended label type 0bxx111111 as "Reserved for 204 future extended label types." We request that IANA record this 205 assignment. 207 This document assigns option code 65535 to "Reserved for future 208 expansion." 210 This document expands the RCODE space from 4 bits to 12 bits. This will 211 allow IANA to assign more than the 16 distinct RCODE values allowed in 212 [RFC1035]. 214 This document assigns EDNS Extended RCODE "16" to "BADVERS". 216 IESG approval should be required to create new entries in the EDNS 217 Extended Label Type or EDNS Version Number registries, while any 218 published RFC (including Informational, Experimental, or BCP) should be 219 grounds for allocation of an EDNS Option Code. 221 8 - Acknowledgements 223 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 224 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas 225 Narten were each instrumental in creating and refining this 226 specification. 228 9 - References 230 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 231 Specification,'' RFC 1035, USC/Information Sciences 232 Institute, November 1987. 234 10 - Author's Address 236 Paul Vixie 237 Internet Software Consortium 238 950 Charter Street 239 Redwood City, CA 94063 240 +1 650 779 7001 241