idnits 2.17.1 draft-graff-dnsext-edns0bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC2671, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2009) is 5398 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group P. Vixie 3 Internet-Draft M. Graff 4 Obsoletes: 2671 (if approved) Internet Systems Consortium 5 Intended status: Standards Track July 13, 2009 6 Expires: January 14, 2010 8 Extension Mechanisms for DNS (EDNS0) 9 draft-graff-dnsext-edns0bis-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The Domain Name System's wire protocol includes a number of fixed 48 fields whose range has been or soon will be exhausted and does not 49 allow clients to advertise their capabilities to servers. This 50 document describes backward compatible mechanisms for allowing the 51 protocol to grow. 53 This document is a starting point to update the EDNS0 RFC after 10 54 years of operational experience. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 60 3. Affected Protocol Elements . . . . . . . . . . . . . . . . . . 3 61 3.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 3 62 3.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 3 64 4. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Extended Label Type . . . . . . . . . . . . . . . . . . . . 4 66 4.2. Reserved Label Type . . . . . . . . . . . . . . . . . . . . 4 67 5. OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5.1. OPT Record Behavior . . . . . . . . . . . . . . . . . . . . 4 69 5.2. OPT Record Format . . . . . . . . . . . . . . . . . . . . . 4 70 5.2.1. Fixed Content . . . . . . . . . . . . . . . . . . . . . 4 71 5.2.2. Variable Content . . . . . . . . . . . . . . . . . . . 5 72 5.3. Sender's Payload Size . . . . . . . . . . . . . . . . . . . 5 73 5.3.1. Reassembly Considerations . . . . . . . . . . . . . . . 6 74 5.3.2. Path MTU . . . . . . . . . . . . . . . . . . . . . . . 6 75 5.3.3. No Caching . . . . . . . . . . . . . . . . . . . . . . 6 76 5.3.4. Oversize Requests . . . . . . . . . . . . . . . . . . . 6 77 5.3.5. Be Reasonable . . . . . . . . . . . . . . . . . . . . . 6 78 5.4. Extended RCODE . . . . . . . . . . . . . . . . . . . . . . 6 79 6. Transport Considerations . . . . . . . . . . . . . . . . . . . 7 80 6.1. Meaning of OPT Presense . . . . . . . . . . . . . . . . . . 7 81 6.2. Meaning of OPT Absence . . . . . . . . . . . . . . . . . . 7 82 6.3. Refusing Message with OPT Records . . . . . . . . . . . . . 8 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 DNS [RFC1035] specifies a Message Format and within such messages 94 there are standard formats for encoding options, errors, and name 95 compression. The maximum allowable size of a DNS Message is fixed. 96 Many of DNS's protocol limits are too small for uses which are or 97 which are desired to become common. There is no way for 98 implementations to advertise their capabilities. 100 Existing clients will not know how to interpret the protocol 101 extensions detailed here. In practice, these clients will be 102 upgraded when they have need of a new feature, and only new features 103 will make use of the extensions. We must however take account of 104 client behaviour in the face of extra fields, and design a fallback 105 scheme for interoperability with these clients. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 3. Affected Protocol Elements 115 3.1. Message Header 117 The DNS Message Header's (see RFC 1035, section 4.1.1 [RFC1035]) 118 second full 16-bit word is divided into a 4-bit OPCODE, a 4-bit 119 RCODE, and a number of 1-bit flags. The original reserved Z bits 120 have been allocated to various purposes, and most of the RCODE values 121 are now in use. More flags and more possible RCODEs are needed. 123 3.2. Label Types 125 The first two bits of a wire format domain label are used to denote 126 the type of the label. RFC 1035, 4.1.4 [RFC1035] allocates two of 127 the four possible types and reserves the other two. Proposals for 128 use of the remaining types far outnumber those available. More label 129 types are needed. 131 3.3. UDP Message Size 133 DNS Messages are limited to 512 octets in size when sent over UDP. 134 While the minimum maximum reassembly buffer size still allows a limit 135 of 512 octets of UDP payload, most of the hosts now connected to the 136 Internet are able to reassemble larger datagrams. Some mechanism 137 must be created to allow requestors to advertise larger buffer sizes 138 to responders. 140 4. Extended Label Types 142 4.1. Extended Label Type 144 The "0 1" label type will now indicate an extended label type, whose 145 value is encoded in the lower six bits of the first octet of a label. 146 All subsequently developed label types should be encoded using an 147 extended label type. 149 4.2. Reserved Label Type 151 The "1 1 1 1 1 1" extended label type will be reserved for future 152 expansion of the extended label type code space. 154 5. OPT pseudo-RR 156 5.1. OPT Record Behavior 158 One OPT pseudo-RR can be added to the additional data section of 159 either a request or a response. An OPT is called a pseudo-RR because 160 it pertains to a particular transport level message and not to any 161 actual DNS data. OPT RRs shall never be cached, forwarded, or stored 162 in or loaded from master files. The quantity of OPT pseudo-RRs per 163 message shall be either zero or one, but not greater. 165 5.2. OPT Record Format 167 An OPT RR has a fixed part and a variable set of options expressed as 168 {attribute, value} pairs. The fixed part holds some DNS meta data 169 and also a small collection of new protocol elements which we expect 170 to be so popular that it would be a waste of wire space to encode 171 them as {attribute, value} pairs. 173 5.2.1. Fixed Content 175 The fixed part of an OPT RR is structured as follows: 177 +------------+--------------+---------------------------+ 178 | Field Name | Field Type | Description | 179 +------------+--------------+---------------------------+ 180 | NAME | domain name | empty (root domain) | 181 | TYPE | u_int16_t | OPT | 182 | CLASS | u_int16_t | sender's UDP payload size | 183 | TTL | u_int32_t | extended RCODE and flags | 184 | RDLEN | u_int16_t | describes RDATA | 185 | RDATA | octet stream | {attribute,value} pairs | 186 +------------+--------------+---------------------------+ 188 OPT RR Format 190 5.2.2. Variable Content 192 The variable part of an OPT RR is encoded in its RDATA and is 193 structured as zero or more of the following: 195 +0 (MSB) +1 (LSB) 196 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 0: | OPTION-CODE | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 2: | OPTION-LENGTH | 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 201 4: | | 202 / OPTION-DATA / 203 / / 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 206 OPTION-CODE 207 Assigned by IANA. 209 OPTION-LENGTH 210 Size (in octets) of OPTION-DATA. 212 OPTION-DATA 213 Varies per OPTION-CODE. 215 5.3. Sender's Payload Size 217 The sender's UDP payload size (which OPT stores in the RR CLASS 218 field) is the number of octets of the largest UDP payload that can be 219 reassembled and delivered in the sender's network stack. Note that 220 path MTU, with or without fragmentation, may be smaller than this. 222 5.3.1. Reassembly Considerations 224 4.5.1 Note that a 512-octet UDP payload requires a 576-octet IP 225 reassembly buffer. Choosing 1280 on an Ethernet connected requestor 226 would be reasonable. The consequence of choosing too large a value 227 may be an ICMP message from an intermediate gateway, or even a silent 228 drop of the response message. 230 5.3.2. Path MTU 232 Both requestors and responders are advised to take account of the 233 path's discovered MTU (if already known) when considering message 234 sizes. 236 5.3.3. No Caching 238 4.5.3. The requestor's maximum payload size can change over time, 239 and should therefore not be cached for use beyond the transaction in 240 which it is advertised. 242 5.3.4. Oversize Requests 244 4.5.4. The responder's maximum payload size can change over time, 245 but can be reasonably expected to remain constant between two 246 sequential transactions; for example, a meaningless QUERY to discover 247 a responder's maximum UDP payload size, followed immediately by an 248 UPDATE which takes advantage of this size. (This is considered 249 preferrable to the outright use of TCP for oversized requests, if 250 there is any reason to suspect that the responder implements EDNS, 251 and if a request will not fit in the default 512 payload size limit.) 253 5.3.5. Be Reasonable 255 4.5.5. Due to transaction overhead, it is unwise to advertise an 256 architectural limit as a maximum UDP payload size. Just because your 257 stack can reassemble 64KB datagrams, don't assume that you want to 258 spend more than about 4KB of state memory per ongoing transaction. 260 5.4. Extended RCODE 262 4.6. The extended RCODE and flags (which OPT stores in the RR TTL 263 field) are structured as follows: 265 +0 (MSB) +1 (LSB) 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 0: | EXTENDED-RCODE | VERSION | 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 2: | Z | 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 272 EXTENDED-RCODE 273 Forms upper 8 bits of extended 12-bit RCODE. Note that 274 EXTENDED-RCODE value "0" indicates that an unextended RCODE is 275 in use (values "0" through "15"). 277 VERSION 278 Indicates the implementation level of whoever sets it. Full 279 conformance with this specification is indicated by version 280 ``0.'' Requestors are encouraged to set this to the lowest 281 implemented level capable of expressing a transaction, to 282 minimize the responder and network load of discovering the 283 greatest common implementation level between requestor and 284 responder. A requestor's version numbering strategy should 285 ideally be a run time configuration option. 286 If a responder does not implement the VERSION level of the 287 request, then it answers with RCODE=BADVERS. All responses 288 will be limited in format to the VERSION level of the request, 289 but the VERSION of each response will be the highest 290 implementation level of the responder. In this way a requestor 291 will learn the implementation level of a responder as a side 292 effect of every response, including error responses, including 293 RCODE=BADVERS. 295 Z 296 Set to zero by senders and ignored by receivers, unless 297 modified in a subsequent specification. 299 6. Transport Considerations 301 6.1. Meaning of OPT Presense 303 The presence of an OPT pseudo-RR in a request should be taken as an 304 indication that the requestor fully implements the given version of 305 EDNS, and can correctly understand any response that conforms to that 306 feature's specification. 308 6.2. Meaning of OPT Absence 310 Lack of use of these features in a request must be taken as an 311 indication that the requestor does not implement any part of this 312 specification and that the responder may make no use of any protocol 313 extension described here in its response. 315 6.3. Refusing Message with OPT Records 317 Responders who do not understand these protocol extensions are 318 expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. 319 Therefore use of extensions should be ``probed'' such that a 320 responder who isn't known to support them be allowed a retry with no 321 extensions if it responds with such an RCODE. If a responder's 322 capability level is cached by a requestor, a new probe should be sent 323 periodically to test for changes to responder capability. 325 7. Security Considerations 327 Requestor-side specification of the maximum buffer size may open a 328 new DNS denial of service attack if responders can be made to send 329 messages which are too large for intermediate gateways to forward, 330 thus leading to potential ICMP storms between gateways and 331 responders. 333 8. IANA Considerations 335 The IANA has assigned RR type code 41 for OPT. 337 It is the recommendation of this document and its working group that 338 IANA create a registry for EDNS Extended Label Types, for EDNS Option 339 Codes, and for EDNS Version Numbers. 341 This document assigns label type 0b01xxxxxx as "EDNS Extended Label 342 Type." We request that IANA record this assignment. 344 This document assigns extended label type 0bxx111111 as "Reserved for 345 future extended label types." We request that IANA record this 346 assignment. 348 This document assigns option code 65535 to "Reserved for future 349 expansion." 351 This document expands the RCODE space from 4 bits to 12 bits. This 352 will allow IANA to assign more than the 16 distinct RCODE values 353 allowed in RFC 1035 [RFC1035]. 355 This document assigns EDNS Extended RCODE "16" to "BADVERS". 357 IESG approval should be required to create new entries in the EDNS 358 Extended Label Type or EDNS Version Number registries, while any 359 published RFC (including Informational, Experimental, or BCP) should 360 be grounds for allocation of an EDNS Option Code. 362 9. Acknowledgements 364 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 365 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas 366 Narten were each instrumental in creating and refining this 367 specification. 369 10. References 371 10.1. Normative References 373 [RFC1035] Mockapetris, P., "Domain names - implementation and 374 specification", STD 13, RFC 1035, November 1987. 376 10.2. Informative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 Authors' Addresses 383 Paul Vixie 384 Internet Systems Consortium 385 950 Charter Street 386 Redwood City, California 94063 387 US 389 Phone: +1 650.423.1301 390 Email: vixie@isc.org 392 Michael Graff 393 Internet Systems Consortium 394 950 Charter Street 395 Redwood City, California 94063 396 US 398 Phone: +1 650.423.1304 399 Email: mgraff@isc.org