idnits 2.17.1 draft-irtf-rrg-ilnp-dns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 26, 2012) is 4386 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'X' is defined on line 627, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RJ Atkinson 3 draft-irtf-rrg-ilnp-dns-01.txt Consultant 4 Expires: 26 OCT 2012 SN Bhatti 5 Category: Experimental U. St Andrews 6 Scott Rose 7 US NIST 8 March 26, 2012 10 DNS Resource Records for ILNP 11 draft-irtf-rrg-ilnp-dns-01.txt 13 STATUS OF THIS MEMO 15 Distribution of this memo is unlimited. 17 Copyright (c) 2012 IETF Trust and the persons identified as the 18 document authors. All rights reserved. 20 This document is subject to BCP 78 and the IETF Trust's Legal 21 Provisions Relating to IETF Documents 22 (http://trustee.ietf.org/license-info) in effect on the date of 23 publication of this document. Please review these documents 24 carefully, as they describe your rights and restrictions with 25 respect to this document. Code Components extracted from this 26 document must include Simplified BSD License text as described in 27 Section 4.e of the Trust Legal Provisions and are provided 28 without warranty as described in the Simplified BSD License. 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 This document may contain material from IETF Documents or 34 IETF Contributions published or made publicly available before 35 before November 10, 2008. The person(s) controlling the 36 copyright in some of this material may not have granted the 37 IETF Trust the right to allow modifications of such material 38 outside the IETF Standards Process. Without obtaining an 39 adequate license from the person(s) controlling the copyright 40 in such materials, this document may not be modified outside 41 the IETF Standards Process, and derivative works of it may not 42 be created outside the IETF Standards Process, except to format 43 it for publication as an RFC or to translate it into languages 44 other than English. 46 Internet-Drafts are working documents of the Internet 47 Engineering Task Force (IETF), its areas, and its working 48 groups. Note that other groups may also distribute working 49 documents as Internet-Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six 52 months and may be updated, replaced, or obsoleted by other 53 documents at any time. It is inappropriate to use 54 Internet-Drafts as reference material or to cite them other 55 than as "work in progress." 57 The list of current Internet-Drafts can be accessed at 58 http://www.ietf.org/1id-abstracts.html 60 The list of Internet-Draft Shadow Directories can be accessed at 61 http://www.ietf.org/shadow.html 63 This document is not on the IETF standards-track and does not 64 specify any level of standard. This document merely provides 65 information for the Internet community. 67 This document is part of the ILNP document set, which has had 68 extensive review within the IRTF Routing Research Group. ILNP is 69 one of the recommendations made by the RG Chairs. Separately, 70 various refereed research papers on ILNP have also been published 71 during this decade. So the ideas contained herein have had much 72 broader review than the IRTF Routing RG. The views in this 73 document were considered controversial by the Routing RG, but the 74 RG reached a consensus that the document still should be 75 published. The Routing RG has had remarkably little consensus on 76 anything, so virtually all Routing RG outputs are considered 77 controversial. 79 ABSTRACT 81 This note describes additional optional Resource Records for use 82 with the Domain Name System (DNS). These optional resource 83 records are for use with the Identifier-Locator Network Protocol 84 (ILNP). This document is a product of the IRTF Routing RG. 86 TABLE OF CONTENTS 88 1. Introduction.............................2 89 2. New Resource Records.....................3 90 2.1 ID Resource Record......................3 91 2.2 L32 Resource Record......................5 92 2.3 L64 Resource Record......................6 93 2.4 LP Resource Record.......................7 94 3. Usage Example............................8 95 4. Security Considerations..................9 96 5. IANA Considerations......................9 97 6. References...............................9 99 1. INTRODUCTION 101 The Identifier-Locator Network Protocol (ILNP) was developed to 102 explore a possible evolutionary direction for the Internet 103 Architecture. An description of the ILNP architecture is 104 available in a separate document [ILNP-ARCH]. Implementation and 105 engineering details are largely isolated into a second document 106 [ILNP-ENG]. 108 The Domain Name System (DNS) is the standard way that Internet 109 nodes locate information about addresses, mail exchangers, and 110 other data relating to remote Internet nodes [RFC1034] [RFC1035]. 111 More recently, the IETF have defined standards-track security 112 extensions to the DNS. [RFC4033] These security extensions can 113 be used to authenticate signed DNS data records and can also be 114 used to store signed public keys in the DNS. Further, the IETF 115 have defined a standards-track approach to enable secure dynamic 116 update of DNS records over the network [RFC3007]. 118 This document defines several new optional data Resource 119 Records. This note specifies the syntax and other items 120 required for independent implementations of these DNS resource 121 records. The reader is assumed to be familiar with the basics 122 of DNS, including familiarity with [RFC1034] [RFC1035]. 124 The concept of using DNS to support mobile nodes or mobile 125 networks has been proposed earlier, more than once, 126 independently, by several other researchers; for example, 127 please see [SB00] [SBK01] and [PHG02]. 129 1.1 Terminology 131 In this document, the term "ILNP-enabled" applied to a DNS 132 component (either authoritative server or cache) is used to 133 indicate that the component attempts to include other ILNP 134 RRTypes to the Additional section of a DNS response to 135 increase performance and reduce the number of follow-up 136 queries for other ILNP RRTypes. These other RRsets are added 137 to the Additional section if space permits and only when the 138 QTYPE equals ID, L64, L32, or LP. There is no method for a 139 server to signal that it is ILNP-enabled. 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 142 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described 144 in RFC 2119 [RFC2119]. 146 2. NEW RESOURCE RECORDS 148 This document specifies several new and closely related DNS data 149 Resource Records (RRs). These new RR types have the mnemonics 150 "ID", "L32", "L64", and "LP". These resource record types are 151 associated with a Fully-Qualified Domain Name (FQDN), that is 152 hereafter called the "owner name". These are part of work on the 153 Identifier-Locator Network Protocol (ILNP) [ILNP-ARCH]. 155 2.1 "ID" Resource Record 157 An ID record has the following logical components: 158 IN ID 160 In the above is the owner name string, 161 is an unsigned 16-bit value, while is an unsigned 64-bit 162 value. 164 The field indicates the owner name's relative 165 preference for this ID record among other ID records associated 166 with this owner name. Lower preference values are preferred over 167 higher preference values. 169 The field complies with the syntactic rules of IPv6 Interface 170 Identifiers. Unlike IPv6 Interface Identifiers, which are bound 171 to a specific *interface* of a specific node, values are 172 bound to a specific *node* -- and may be used with *any 173 interface* of that node. 175 An "ID" record has the DNS TYPE of ID and a numeric value of 176 . An ID record is a member of the 177 Internet ("IN") CLASS in the DNS. Each ID record is associated 178 with a owner name entry in the DNS. 180 ID records are present only for owner name values that are 181 ILNP-capable nodes. This restriction is important; ILNP-capable 182 nodes use the presence of ID records in the DNS to learn that a 183 correspondent node is also ILNP-capable. While erroneous ID 184 records in the DNS for an owner name that is not ILNP-capable 185 would not prevent communication, such erroneous DNS records could 186 increase the delay at the start of an IP communications session. 188 Of course, a particular node's owner name might have an ID record 189 in the DNS and yet that node might be temporarily disconnected 190 from the Internet. 192 A given owner name may have zero or more ID records at a given 193 time. In normal operation, nodes that support the Identifier- 194 Locator Network Protocol (ILNP) will have at least one valid ID 195 record. 197 The ID DNS record has the following RDATA format: 199 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 200 | Preference | 201 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 202 | | 203 | ID | 204 | | 205 | | 206 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 208 where: 210 Preference A 16-bit unsigned integer which specifies the 211 preference given to this RR among others at 212 the same owner. Lower Preference values are 213 preferred over higher Preference values. 215 ID A 64-bit unsigned integer. 217 ILNP-enabled DNS servers and DNS caches SHOULD attempt to return 218 all L32, L64, and LP records associated with the owner name of 219 the ID RRset in the Additional section of the response if space 220 permits. 222 2.2 "L32" Resource Record 224 An "L32" record has the DNS TYPE of "L32" and a numeric value of 225 . An L32 record is a member of the 226 Internet ("IN") CLASS in the DNS. Each L32 record is associated 227 with an owner name entry in the DNS. The Preference field 228 indicates the owner name's relative preference for this 229 particular L32 record among other L32 records for the same owner 230 name. 232 An L32 record has the following logical components: 234 IN L32 236 In the above, is the owner name, is an 237 unsigned 16-bit value, while is an unsigned 32-bit value that 238 names a subnetwork where the owner is directly attached. 240 The Preference field indicates the owner name's relative 241 preference for this L32 record among other L32, L64, and LP 242 records associated with this owner name. Lower values are 243 preferred over higher values. 245 A given owner name might have zero or more L32 values at a given 246 time. An ILNP-capable IPv4 host SHOULD have at least 1 Locator 247 (i.e., L32 or LP) DNS resource record while it is connected to 248 the Internet. An ILNP-capable multi-homed IPv4 host normally 249 will have multiple Locator values while multi-homed. An IPv4 250 host that is NOT ILNP-capable MUST NOT have an L32 or LP record 251 in its DNS entries. A node that is not currently connected to 252 the Internet might not have any L32 values in the DNS associated 253 with its . 255 A DNS owner name that is naming a subnetwork, rather than naming 256 a host, MAY have an L32 record as a wild-card entry, thereby 257 applying to entries under that DNS owner name. This deployment 258 scenario probably is most common if the named subnetwork is, was, 259 or might become, mobile. 261 The L32 DNS record has the following RDATA format: 263 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 264 | Preference | 265 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 266 | | 267 | L32 | 268 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 270 where: 272 Preference A 16-bit unsigned integer which specifies the 273 preference given to this RR among others at 274 the same owner. Lower Preference values are 275 preferred over higher Preference values. 277 L32 A 32-bit unsigned integer that names a 278 subnetwork. 280 ILNP-enabled DNS servers and DNS caches SHOULD attempt to return 281 all ID, L64, and LP records for the same owner name of the L32 282 RRset in the Additional section of the response if space permits. 284 2.3 "L64" Resource Record 286 An "L64" record has the DNS TYPE of "L64" and a numeric value of 287 . An L64 record is a member of the 288 Internet ("IN") CLASS in the DNS. Each L64 record is associated 289 with an owner name entry in the DNS. 291 An L64 record has the following logical components: 292 IN L64 294 In the above, is the owner name, is an 295 unsigned 16-bit value, while is an unsigned 64-bit value that 296 names a subnetwork where is directly attached. 298 The Preference field indicates the owner name's relative 299 preference for this L64 record among other L32, L64, and LP 300 records associated with this owner name. Lower Preference values 301 are preferred over higher Preference values. 303 A given owner name may have zero or more L64 values at a given 304 time. An ILNP-capable multi-homed host connected to the Internet 305 will normally have multiple Locator (i.e., L64 or LP) values 306 while multi-homed. 308 A DNS owner name that is naming a subnetwork, rather than naming 309 a host, MAY have an L64 record as a wild-card entry, thereby 310 applying to all entries under that DNS owner name. This 311 deployment scenario is most common if the named subnetwork is, 312 was, or might become, mobile. 314 A DNS owner name that names a single node that is NOT ILNP- 315 capable MUST NOT have an L64 record in the DNS. A node that is 316 not currently connected to the Internet commonly might not have 317 any L64 or LP values in the DNS associated with its owner name. 319 The L64 DNS record has the following RDATA format: 321 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 322 | Preference | 323 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 324 | | 325 | L64 | 326 | | 327 | | 328 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 330 where: 332 Preference A 16-bit unsigned integer which specifies the 333 preference given to this RR among others at 334 the same owner. Lower Preference values are 335 preferred over higher Preference values. 337 L64 A 64-bit unsigned integer that names a 338 subnetwork. 340 The Preference field indicates the owner name's relative 341 preference for this LP record among other L32, L64, and LP 342 records associated with this owner name. Lower values are 343 preferred over higher values. 345 ILNP-enabled DNS servers and DNS caches SHOULD attempt to 346 return all ID, L32, and LP RRsets associated with the owner 347 name of the L64 RRset in the Additional section of the 348 response if space permits. 350 2.4 "LP" Resource Record 352 As described in [ILNP-ARCH], the LP resource record provides 353 one level of indirection within the DNS in naming a Locator 354 value. This is useful in several deployment scenarios, such as 355 for a multi-homed site where the multi-homing is handled entirely 356 by the site's border routers (e.g. via Locator rewriting) 357 or in some mobile network deployment scenarios [ILNP-ADV]. 359 An "LP" record has the following logical components: 360 IN LP 362 An LP record has the DNS TYPE of LP and a numeric value of . An LP record is a member of the Internet 364 ("IN") CLASS in the DNS. Each LP record is associated with an 365 owner name entry in the DNS, and points to a second Fully- 366 Qualified Domain Name (shown above as ). 368 LP records MUST NOT be present for owner name values that are not 369 ILNP-capable nodes. This restriction is important; ILNP-capable 370 nodes use the presence of "LP" records in the DNS to infer that 371 a correspondent node is also ILNP-capable. While erroneous "LP" 372 records in the DNS for an owner name would not prevent 373 communication, presence of such erroneous DNS records could 374 increase the delay at the start of a communications session. 376 Of course, a particular node might have an LP record in the DNS 377 and yet temporarily be disconnected from the Internet. 379 In the above is the owner name, while 380 is any other valid domain name string. It is invalid to have an 381 LP record with the same value in both the and 382 values. A given owner name will have zero or more 383 LP records at a given time. 385 The LP DNS record has the following RDATA format: 387 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 388 | Preference | 389 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 390 | | 391 / FQDN / 392 / / 393 | | 394 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 396 where: 398 Preference A 16-bit unsigned integer which specifies the 399 preference given to this RR among others at 400 the same owner. Lower Preference values are 401 preferred over higher Preference values. 403 FQDN A Fully-Qualified Domain Name that has one 404 or more L64 records in the DNS. This is 405 referred to as the above. 407 The Preference field indicates the owner name's relative 408 preference for this LP record among other L32, L64, and LP 409 records associated with this owner name. Lower values are 410 preferred. 412 ILNP-enabled DNS servers and DNS caches SHOULD attempt to 413 return all ID, L32, and L64 RRsets associated with the owner 414 name of the LP RRset in the Additional section of the response 415 if space permits. 417 3. USAGE EXAMPLE 419 Given a domain name, one can use the Domain Name System (DNS) to 420 discover the set of ID records, the set of L32 records, the set 421 of L64 records, and the set of LP records that are associated 422 with that owner name. 424 As these DNS records are only used with the Identifier-Locator 425 Network Protocol (ILNP), these records MUST NOT be present for a 426 node that does not support ILNP. This lookup process is 427 considered to be in the "forward" direction. 429 The Preference fields associated with the ID, L32, L64, and LP 430 records are used to indicate the owner name's preference for 431 others to use one particular ID, L32, L64, or LP record, rather 432 than use another ID, L32, L64, or LP record also associated with 433 that owner name. Lower Preference field values are preferred 434 over higher Preference field values. 436 It is possible that a client querying for one of these record 437 types will not receive all ID, L32, L64, and LP RR's in a single 438 response. Credible anecdotal reports indicate at least one DNS 439 recursive cache implementation actively drops all Additional Data 440 records that were not expected by that DNS recursive cache. So 441 even if the authoritative DNS server includes all the relevant 442 records in the Additional Data section of the DNS response, the 443 querying client might not receive all of those Additional Data 444 records. DNS caches also might purge some ILNP RRsets before 445 others, for example if ID RRsets have a longer DNS TTL value than 446 Locator-related (e.g. LP, L32, L64) RRsets. So a client sending 447 queries toa DNS cache cannot be certain if they have obtained all 448 available RRtypes for a given owner name. Therefore, the DNS 449 client SHOULD send follow-up DNS queries for RRTYPE values that 450 were missing and are desired, to ensure that the client receives 451 all the necessary information. 453 Note that for nodes likely either to be mobile or to be multi- 454 homed, the DNS TTL values for L32 and L64 records normally will 455 be very low, as those values might change frequently. However, 456 the DNS TTL values for ID and LP records normally will be quite 457 long, as those values are not normally impacted by node location 458 changes. Previous trace-driven DNS simulations from MIT [JSBM02] 459 and more recent experimental DNS validation from U. of St Andrews 460 [BA11] both indicate use of very short DNS TTL values is not 461 problematic. 463 Any ID value associated with a DNS owner name can be used with 464 any or all Locator values associated with that same DNS owner 465 name. 467 4. SECURITY CONSIDERATIONS 469 These new DNS resource record types do not create any new 470 vulnerabilities in the Domain Name System. 472 Existing mechanisms for DNS security can be used unchanged with 473 these record types [RFC4033] [RFC3007]. As of this writing, those 474 mechanisms are believed to be widely implemented in currently 475 available DNS servers. 477 In situations where authentication of DNS data is a concern, the 478 DNS Security extensions SHOULD be used [RFC4033]. 480 If these DNS records are updated dynamically over the network, 481 then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be 482 used to secure such transactions. 484 5. IANA CONSIDERATIONS 486 IANA is requested to allocate each of these DNS Resource Records 487 (enumerated above in Section 2) a Data RRTYPE value according to 488 the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of 489 RFC 6195 [RFC6195]. 491 6. REFERENCES 493 6.1 Normative References 495 [RFC1034] P. Mockapetris, "Domain names - Concepts and 496 Facilities", RFC-1034, 1 November 1987 498 [RFC1035] P. Mockapetris, "Domain names - Implementation and 499 Specification", RFC-1035, 1 November 1987. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to 502 Indicate Requirement Levels", BCP 14, RFC 2119, 503 March 1997. 505 [RFC3007] B. Wellington, "Secure Domain Name System Dynamic 506 Update", RFC 3007, RFC Editor, November 2000. 508 [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource 509 Record (RR) Types", RFC 3597, September 2003. 511 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, & 512 S. Rose, "DNS Security Introduction & Requirements", 513 RFC 4033, RFC Editor, March 2005. 515 [RFC6195] D. Eastlake 3rd, "Domain Name System IANA 516 Considerations", RFC 6195, March 2011. 518 [ILNP-ARCH] R. Atkinson & S. Bhatti, "ILNP Architecture", 519 draft-irtf-rrg-ilnp-arch, January 2012. 521 [ILNP-ADV] R. Atkinson & S. N. Bhatti, 522 "Optional Advanced Deployment Scenarios for ILNP", 523 draft-irtf-rrg-ilnp-adv, March 2012 525 [ILNP-ENG] R. Atkinson & S. Bhatti, "ILNP Engineering and 526 Implementation Considerations", 527 draft-irtf-rrg-ilnp-eng, March 2012. 529 6.2 INFORMATIVE REFERENCES 531 [BA11] S. Bhatti & R. Atkinson, 532 "Reducing DNS Caching", 533 Proc. GI2011 - 14th IEEE Global Internet Symposium, 534 Shanghai, China. 15 Apr 2011. 535 http://dx.doi.org/10.1109/INFCOMW.2011.5928919 537 [JSBM02] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, 538 DNS performance and the effectiveness of caching. 539 IEEE/ACM Trans. Netw. 10, 5 (October 2002), 589-603. 540 http://dx.doi.org/10.1109/TNET.2002.803905 542 [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, 543 "Mobile Host Location Tracking through DNS", 544 IEEE London Communications Symposium, 545 London, England, UK, September 2002. 546 548 [SB00] Alex C. Snoeren and Hari Balakrishnan. 2000. 549 "An End-To-End Approach To Host Mobility", Proc. 550 6th Conference on Mobile Computing And Networking 551 (MobiCom), ACM, Boston, MA, USA, pp. 155-166, 552 August 2000. 554 [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 555 Kaashoek, "Reconsidering Internet Mobility", 556 Proceedings of 8th Workshop on Hot Topics in 557 Operating Systems (HotOS), IEEE Computer Society, 558 Washington, DC, USA, May 2001. 560 ACKNOWLEDGEMENTS 562 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 563 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 564 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 565 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 566 order) provided review and feedback on earlier versions of this 567 document. Steve Blake provided an especially thorough review of 568 an early version of the entire ILNP document set, which was 569 extremely helpful. We also wish to thank the anonymous reviewers 570 of the various ILNP papers for their feedback. 572 RFC EDITOR NOTE 574 This section is to be removed prior to publication. 576 This document is written in English, not American. So English 577 spelling is used throughout, rather than American spelling. 578 This is consistent with existing practice in several other RFCs, 579 for example RFC-5887. 581 This document tries to be very careful with history, in the 582 interest of correctly crediting ideas to their earliest 583 identifiable author(s). So in several places the first published 584 RFC about a topic is cited rather than the most recent published 585 RFC about that topic. 587 Authors' Addresses: 589 RJ Atkinson 590 Consultant 591 San Jose, CA 592 95125 USA 594 Email: rja.lists@gmail.com 596 SN Bhatti 597 School of Computer Science 598 University of St Andrews 599 North Haugh, St Andrews 600 Fife, Scotland, UK 601 KY16 9SX 603 Email: saleem@cs.st-andrews.ac.uk 605 Scott Rose 606 US National Institute for Standards & Technology 607 100 Bureau Drive 608 Gaithersburg, MD 609 20899 USA 611 Email: scottr.nist@gmail.com 613 [NOTE: Appendix A is to be removed by the 614 RFC Editor prior to publication.] 616 Appendix A: 618 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 620 When ready for formal consideration, this template is 621 to be submitted to IANA for processing by emailing the 622 template to dns-rrtype-applications@ietf.org. 624 A. Submission Date: To be determined. 626 B. Submission Type: 627 [X] New RRTYPE 629 C. Contact Information for submitter: 630 Name: R. Atkinson 631 Email Address: rja.lists@gmail.com 632 International telephone number: unlisted 633 Other contact handles: 635 D. Motivation for the new RRTYPE application? 637 Support for an experimental set of IP extensions 638 that replace the concept of an "IP Address" with 639 distinct "Locator" and "Identifier" values. 641 E. Description of the proposed RR type. 643 Please see draft-rja-ilnp-dns-07.txt for a full 644 description. 646 F. What existing RRTYPE or RRTYPEs come closest to filling that 647 need and why are they unsatisfactory? 649 The AAAA record combines both Locator and Identifier, 650 so has significantly different semantics than having 651 separate L64 and ID record values. The AAAA record also 652 lacks scalability and flexibility in the context of the 653 experimental protocol extensions that will use the ID 654 and L64 records, as any valid ID record value for a node 655 can be used on the wire with any valid L64 record value 656 for the same node. 658 The CNAME record is closest conceptually to an "LP" 659 record, but a CNAME is a node name referral scheme, 660 while the LP record is indicating that the given node 661 has the same routing prefix as some other domain name, 662 but does not necessarily have any other values that are 663 the same. 665 Lastly, the AAA and CNAME RR Types lack a preference 666 field to rank responses. Such preference information 667 is useful with ILNP. 669 G. What mnemonic is requested for the new RRTYPE (optional)? 671 As described in this draft, "ID", "L32", "L64", and "LP". 673 H. Does the requested RRTYPE make use of any existing IANA 674 Registry or require the creation of a new IANA 675 sub-registry in DNS Parameters? 677 Existing registry of DNS Resource Record (RR) data TYPE 678 values should be used. 680 I. Does the proposal require/expect any changes in DNS 681 servers/resolvers that prevent the new type from being 682 processed as an unknown RRTYPE (see [RFC3597]) ? 684 No. 686 J. Comments: 687 This document defines "ILNP-enabled" DNS servers 688 or DNS caches as a DNS server (authoritative or recursive) 689 that include other ILNP RRTypes in the Additional 690 section of a DNS response that match a QNAME (if 691 size permits). This is to reduce the number of 692 client follow-up DNS queries and only applies when the 693 QTYPE is either ID, L32, L64, or LP. There is no 694 signalling mechanism for this Additional section 695 processing, and this is believed to be compatible 696 with existing non-ILNP-enabled DNS servers and clients. 698 No changes are required for existing deployed 699 DNS servers or DNS caches. 701 Expires: 26 OCT 2012