idnits 2.17.1 draft-ietf-dnsext-ends-unknown-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Servers MAY include SUPPORTED options in replies to messages, listing option codes which they understand. This message SHOULD contain all option codes the server understands. This facility MAY NOT be used in place of the UNSUPPORTED option to identify unsupported options in replies. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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? 'RFC1034' on line 41 looks like a reference -- Missing reference section? 'RFC1035' on line 41 looks like a reference -- Missing reference section? 'RFC2671' on line 223 looks like a reference -- Missing reference section? 'RFC2119' on line 220 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Sawyer 3 A. Gustafsson 4 M. Graff 5 Nominum 6 February 23 2000 8 Handling of unknown EDNS0 attributes 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This draft expires on August 23, 2001. 33 Abstract 35 This document provides a clarification of the EDNS0 protocol, 36 specifying the behavior of servers when they receive unknown EDNS 37 options. 39 1.1 - Introduction 41 Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms 42 [RFC2671] is helpful. 44 EDNS0 [RFC2671] specifies a general framework for extending the 45 packet format used by the Domain Name System protocol. The framework 46 provides for a series of additional options, identified by a 16 bit 47 attribute ID and arbitrary sized payload. Any number of these 48 additional options can be specified in the DNS packet. As specified, 49 the current scheme has drawbacks: 51 - It provides no way for implementers to deploy test systems with 52 experimental features prior to approval of the feature and assignment 53 of an attribute ID. 55 - It provides no specification on what an application should do when 56 receiving unrecognized options. 58 This draft proposes to clarify the original EDNS0 draft [RFC2671], 59 addressing these drawbacks. 61 1.2 - Requirements 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2 - Protocol changes: 69 This document updates [RFC2671]. Conformance to this specification 70 is claimed by specifying EDNS version 1. 72 2.1 - Advisory and Required Options: 74 Some potential uses of EDNS options are advisory in nature, For 75 example, a hypothetical option indicating that "I understand frobozz 76 compression in responses" can be safely ignored by the recipient, 77 which will then simply not use frobozz compression. Others uses of 78 options, such as a hypothetical "send only cryptographically verified 79 data in responses" option, cannot be safely ignored, and should cause 80 the request to fail if not understood by the receiver. 82 This suggests that we need two types of options, "advisory" options 83 (that can be ignored) and "required" options (that can not). Because 84 a server needs to classify options as advisory or required even if 85 they were not yet defined when the server was implemented, the type 86 of an option must be evident without knowing its internal structure. 87 This is achieved by splitting the option type codes into two ranges: 88 options with type code 0x0000-0x7FFF are considered "advisory", and 89 options with type code 0x8000-0xFFFF are considered "required". 91 2.2 - Handling of Unknown and Unsupported EDNS Option Types 93 When a server receives an unknown or unsupported advisory option in a 94 request or response message, it MUST ignore the unknown option and 95 process the message as if the option was not present. In the reply, 96 it SHOULD include an advisory UNSUPPORTED option (TBD). 98 When a server receives an unknown or unsupported required option in a 99 request message, it MUST NOT act on the request, and it MUST return 100 an error response with the extended result code BADOPT (TBD). In the 101 reply, it SHOULD include an advisory UNSUPPORTED option. 103 When a server receives an unknown or unsupported required option in a 104 response message, it MUST ignore the response. The server SHOULD 105 continue to parse options after the unknown option, including a list 106 of all unsupported options in the UNSUPPORTED option in the reply, if 107 such an option is present. 109 Servers MAY include SUPPORTED options in replies to messages, listing 110 option codes which they understand. This message SHOULD contain all 111 option codes the server understands. This facility MAY NOT be used 112 in place of the UNSUPPORTED option to identify unsupported options in 113 replies. 115 Clients MAY include SUPPORTED or UNSUPPORTED options in queries. If 116 a client includes a SUPPORTED option, it SHOULD contain all required 117 options the client is willing to accept in reply to its query, and 118 MAY contain some or all of the advisory options. Servers SHOULD NOT 119 use any required options in replies which were not listed in a 120 SUPPORTED option, if present, but MAY use advisory options not 121 listed. 123 If a client includes an UNSUPPORTED option, it SHOULD NOT contain a 124 full list of all options not supported, but rather only options it 125 has received from the server which it did not understand or support. 126 Servers SHOULD NOT include any options listed in an UNSUPPORTED 127 option in the query when generating replies. 129 2.3 - Use of Reserved Options for Development 131 Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF 132 are considered "reserved" and shall not be assigned to new protocols. 133 Software vendors SHOULD use these options for testing of protocols 134 under development, provided the following conditions are met: 136 - Vendors MUST NOT ship any versions of the software which use option 137 codes in this range. They MUST delay shipping software with the new 138 options until IANA has assigned permanent option codes. 140 - Vendors MUST NOT place development servers on the live internet 141 which send options in this range to remote servers or which 142 understand options in this range as having any meaning. 144 Option codes in the range 0x7000 through 0x7FEF and 0xF000 through 145 0xFFEF are considered "experimental." Their use must be assigned by 146 IANA or some other agreed-upon board, and are valid for one (1) year 147 from the date of assignment. Software vendors SHOULD use these 148 options for testing of new protocols under development when such 149 testing requires deployment on the live internet, provided the 150 following conditions are met: 152 - Vendors MUST NOT ship any release candidate or release versions of 153 the software which use option codes in this range. They MUST delay 154 shipping software using the new options until IANA has assigned 155 permanent option codes. 157 - Vendors MAY ship development (so-called "alpha" and "beta") 158 releases of software using these codes, provided it is clearly 159 documented that such software will not be interoperable with release 160 versions of the software in so far as these options are concerned. 162 3.1 - SUPPORTED and UNSUPPORTED options 164 The SUPPORTED and UNSUPPORTED options contain a list of option codes 165 which the server or client does or doesn't support. The list 166 contains, in network byte order, the supported or unsupported 16 bit 167 option codes: 169 1 1 1 1 1 1 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 171 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 172 | SUPPORTED or UNSUPPORTED (TBD) | 173 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 174 | LENGTH (number of options * 2) | 175 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 176 / OPTION CODE(s) / 177 / / 178 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 180 Sending a SUPPORTED option with a zero-length payload indicates that 181 the server or client supports no EDNS options, so none should be 182 used. UNSUPPORTED options with zero-length payloads SHOULD NOT be 183 sent, as such a message is meaningless. 185 Multiple SUPPORTED or UNSUPPORTED options SHOULD NOT be sent, but 186 SHOULD be accepted. If multiple options are received, their contents 187 should be merged together, as if they were all sent in a single 188 option. This produces a limit of at most approx. 32000 options being 189 listed as supported or unsupported. This should not be a problem in 190 any practical application. 192 4 - IANA considerations 193 When allocating EDNS Option Codes, the IANA shall henceforth require 194 the RFC defining the new option to specify whether the option is an 195 "advisory" or a "required" option. The option code for an advisory 196 option shall be allocated from the range 0x0000-0x7FEF, and the code 197 for a required option shall be allocated from the range 198 0x8000-0xFFEF. 200 Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF 201 are considered "reserved." 203 The IANA is hereby requested to assign EDNS Version Number 1 to this 204 specification, to assign a new extended RCODE value for BADOPT, and 205 to assign advisory option codes for UNSUPPORTED and SUPPORTED. 207 5 - Security considerations 209 This draft poses no additional security risks. 211 6 - Acknowledgments 213 The authors would like to thank Olafur Gudmundsson and Brian 214 Wellington for his input on this draft. R. Austin and H. Alvestrand 215 provided initiative for this draft in their draft, "A Proposed 216 Enhancement to the EDNS0 Version Mechanism." 218 7 - References 220 [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate 221 Requirement Levels,'' RFC 2119, ISI, November 1997. 223 [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC 224 2671, ISI, August, 1999 226 Author's Address 228 Michael Sawyer 229 Nominum, Inc. 230 950 Charter St. 231 Redwood City, CA 94063 232 Phone: +1-650-779-6021 233 michael.sawyer@nominum.com 235 Andreas Gustafsson 236 Nominum, Inc. 237 950 Charter St. 238 Redwood City, CA 94063 239 Phone: +1-650-779-6004 240 andreas.gustafsson@nominum.com 242 Michael Graff 243 Nominum, Inc. 244 950 Charter St. 245 Redwood City, CA 94063 246 Phone: +1-650-779-6034 247 michael.graff@nominum.com