idnits 2.17.1 draft-rja-ilnp-dns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 295. -- Found old boilerplate from RFC 3978, Section 5.3 on line 297. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (10 December 2008) is 5615 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2929 (ref. 'EBM00') (Obsoleted by RFC 5395) -- Obsolete informational reference (is this intentional?): RFC 1036 (ref. 'Mock87b') (Obsoleted by RFC 5536, RFC 5537) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Atkinson 3 draft-rja-ilnp-dns-01.txt Extreme Networks 4 Category: Experimental 5 Expires: 10 JUN 2009 10 December 2008 7 Additional DNS Resource Records 8 draft-rja-ilnp-dns-01.txt 10 STATUS OF THIS MEMO 12 Distribution of this memo is unlimited. 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is a contribution to the IRTF Routing Research 35 Group. It is NOT a contribution to the IETF or to any IETF 36 Working Group or to any IETF Area. 38 ABSTRACT 40 This note describes two additional optional Resource Records for use 41 with the Domain Name System (DNS). At present these optional resource 42 records are subject of experimentation in certain IPv6 networks. 44 Limited deployment is anticipated in the near future. 46 1. INTRODUCTION 48 The Domain Name System (DNS) is the standard way that Internet 49 nodes locate information about addresses, mail exchangers, and other 50 data relating to remote Internet nodes. [Mock87a, Mock87b] More 51 recently, the IETF have defined standards-track security extensions 52 to the DNS. [AALMR05] These security extensions can be used to 53 authenticate signed DNS data records and can also be used to store 54 signed public keys in the DNS. Further, the IETF have defined a 55 standards-track approach to enable secure dynamic update of DNS 56 records over the network. [Well00] 58 This document defines two new optional Resource Records. 59 This note specifies the syntax and other items required for 60 independent implementations of these two DNS resource records. 61 The reader is assumed to be familiar with the basics of DNS, 62 including familiarity with [Mock87a] [Mock87b]. 64 This document is not on the IETF standards-track 65 and does not specify any level of standard. This document 66 merely provides information for the Internet community. 68 2. NEW RESOURCE RECORDS 70 This document specifies two new and closely related 71 DNS Resource Records (RRs). The two new RR types have the 72 mnemonics "L" and "I". The L and I records are associated 73 with a fully-qualified domain name. 75 These resource records are not on the IETF standards 76 track and are not standards of any sort. Instead, these 77 records are defined for use in limited deployment and 78 experimental work within certain existing IP-based networks. 80 2.1 "L" Resource Record 82 An "L" record has the DNS TYPE of "L" and a numeric value 83 of . An "L" record is a member of 84 the Internet ("IN") CLASS in the DNS. Each L record is 85 associated with a entry in the DNS. The 86 Preference field indicates the domain-name's relative 87 preference for this particular L record among other L 88 records for the same domain-name. 90 An L record has the following logical components: 91 IN L 92 In the above, is any valid domain name 93 string, is an unsigned 16-bit value, while 94 is an unsigned 64-bit value that names a subnetwork where 95 is directly attached. 97 A given may have zero or more L values 98 at a given time. A multi-homed host will, by definition, 99 have multiple L values while multi-homed. A domain-name 100 that is not a host may have an "L" record as a wild-card 101 entry, in this case the domain-name must be naming a 102 subnetwork. This last usage is most common operationally 103 when the named subnetwork is, was, or might become, mobile. 105 The Preference field indicates the domain-name's 106 relative preference for this L record among other L records 107 associated with this domain-name. Lower values are 108 preferred. 110 The L DNS record has the following RDATA format: 112 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 113 | Preference | 114 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 115 | | 116 | L | 117 | | 118 | | 119 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 where: 123 Preference A 16-bit unsigned integer which specifies the 124 preference given to this RR among others at 125 the same owner. Lower values are preferred. 127 L A 64-bit unsigned integer that names a 128 subnetwork. 130 L records cause additional section processing to lookup all 131 I records for the same domain-name target. All I records 132 located are returned by the DNS server as additional data 133 present in the L record reply. 135 2.2 "I" Resource Record 137 An I record has the following logical components: 138 IN I 139 An "I" record has the DNS TYPE of "I" and a numeric 140 value of . An "I" record is a 141 member of the Internet ("IN") CLASS in the DNS. Each I 142 record is associated with a entry in the DNS. 143 Only a that is associated with an Internet 144 node may have an "I" record. Any that is not 145 a node on the Internet must not have an "I" record. 147 The Preference field indicates the domain-name's 148 relative preference for this I record among other I records 149 associated with this domain-name. Lower values are 150 preferred. 152 In the above is any valid domain name 153 string, while is an unsigned 64-bit value. A given 154 may have zero or more I records at a given 155 time. In normal operation, nodes that support the 156 Identifier-Locator Network Protocol (ILNP) will have at 157 least one valid I record. 159 The I DNS record has the following RDATA format: 161 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 162 | Preference | 163 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 164 | | 165 | I | 166 | | 167 | | 168 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 170 where: 172 Preference A 16-bit unsigned integer which specifies the 173 preference given to this RR among others at 174 the same owner. Lower values are preferred. 176 I A 64-bit unsigned integer. 178 I records cause additional section processing which looks up all L 179 records for the same domain-name target. All L records located are 180 returned by the DNS server as additional data present in the L record 181 reply. 183 3. Usage Example 185 Given a domain-name, one can use the Domain Name System (DNS) 186 to discover the set of I records and the set of L records associated 187 with that domain-name. A given domain-name might have zero or more 188 I records at a time and might have zero or more L records at a time. 189 This lookup process is considered to be in the "forward" direction. 191 The preference fields associated with the I and L records 192 are used to indicate the domain-name's preference for others to use 193 one particular I or L record, rather than use another I or L record 194 also associated with that domain-name. 196 When a DNS server that implements this specification receives 197 an AAAA record query, the server perform additional section processing 198 to locate all I and L records associated with the target domain-name. 199 If found, these I and L records will be returned as additional data 200 in the AAAA record reply. 202 4. SECURITY CONSIDERATIONS 204 These new DNS resource record types do not create any new 205 vulnerabilities. Existing mechanisms for DNS security can be used 206 unchanged with these record types. 208 In situations where authentication of DNS data is a concern, 209 the DNS Security extensions should be used.[AALMR05] 211 If these DNS records are updated dynamically over the network, 212 then the Secure Dynamic DNS Update [Well00] mechanism should be used 213 to secure such transactions. 215 5. IANA CONSIDERATIONS 217 IANA is requested to allocate each of these two DNS 218 Resource Records a value from the "Specification Required" 219 block (32768 - 65279) according to the procedures of Section 220 3.1 on page 7 of RFC-2929 for "Specification Required". 221 [EBM00] 223 5. INFORMATIVE REFERENCES 225 [EBM00] D. Eastlake 3rd, E. Brunner-Williams, & B. Manning, 226 "Domain Name System IANA Considerations", RFC-2929, 227 RFC-Editor, September 2000. 229 [AALMR05] R. Arends, R. Austein, M. Larson, D. Massey, & 230 S. Rose, "DNS Security Introduction & Requirements", 231 RFC-4033, RFC Editor, March 2005. 233 [Well00] B. Wellington, "Secure Domain Name System Dynamic 234 Update", RFC-3007, RFC Editor, November 2000. 236 [Mock87a] P. Mockapetris, "Domain names - Implementation and 237 Specification", RFC-1035, 1 November 1987. 239 [Mock87b] P. Mockapetris, "Domain names - Concepts and 240 Facilities", RFC-1036, 1 November 1987 242 AUTHOR'S ADDRESS: 244 R. Atkinson 245 Extreme Networks 246 3585 Monroe Street 247 Santa Clara, CA 248 95051 USA 250 Email: rja@extremenetworks.com 251 Telephone: +1 (408)579-2800 253 Full Copyright Statement 255 Copyright (C) The IETF Trust (2008). 257 This document is subject to the rights, licenses and restrictions 258 contained in BCP 78, and except as set forth therein, the authors 259 retain all their rights. 261 This document and the information contained herein are provided 262 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 263 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 264 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 265 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 266 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 267 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 268 OR FITNESS FOR A PARTICULAR PURPOSE. 270 Intellectual Property 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed 274 to pertain to the implementation or use of the technology 275 described in this document or the extent to which any license 276 under such rights might or might not be available; nor does it 277 represent that it has made any independent effort to identify any 278 such rights. Information on the procedures with respect to 279 rights in RFC documents can be found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use 284 of such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository 286 at http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention 289 any copyrights, patents or patent applications, or other 290 proprietary rights that may cover technology that may be required 291 to implement this standard. Please address the information to the 292 IETF at ietf-ipr@ietf.org. 294 This document may not be modified, and derivative works of it 295 may not be created. 297 This document may only be posted in an Internet-Draft. 299 Expires: 10 June 2009