idnits 2.17.1 draft-irtf-rrg-ilnp-dns-00.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 (9 January 2012) is 4490 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'ILNP-Intro' is mentioned on line 352, but not defined == Missing Reference: 'X' is mentioned on line 591, but not defined == Unused Reference: 'ILNP-ARCH' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'ILNP-ENG' is defined on line 522, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 1 error (**), 0 flaws (~~), 5 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-00.txt Consultant 4 Expires: 09 JUL 2012 S Bhatti 5 Category: Experimental U. St Andrews 6 Scott Rose 7 US NIST 8 9 January 2012 10 DNS Resource Records for ILNP 11 draft-irtf-rrg-ilnp-dns-00.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 102 to explore a possible evolutionary direction for the Internet 103 Architecture. An introduction to ILNP is available in a 104 separate document. [ILNP-Intro] 106 The Domain Name System (DNS) is the standard way that Internet 107 nodes locate information about addresses, mail exchangers, and 108 other data relating to remote Internet nodes. [RFC 1034] [RFC 109 1035] More recently, the IETF have defined standards-track 110 security extensions to the DNS. [RFC 4033] These security 111 extensions can be used to authenticate signed DNS data records 112 and can also be used to store signed public keys in the DNS. 113 Further, the IETF have defined a standards-track approach to 114 enable secure dynamic update of DNS records over the 115 network. [RFC 3007] 117 This document defines several new optional data Resource 118 Records. This note specifies the syntax and other items 119 required for independent implementations of these DNS resource 120 records. The reader is assumed to be familiar with the basics 121 of DNS, including familiarity with [RFC 1034] [RFC 1035]. 123 The concept of using DNS to support mobile nodes or mobile 124 networks was proposed earlier by others. [PHG2002] This 125 author was not aware of that work when initially 126 developing the DNS extensions defined here. 128 1.1 Terminology 130 In this document, the term "ILNP-enabled" applied to a DNS 131 component (either authoritative server or cache) is used to 132 indicate that the component attempts to include other ILNP 133 RRTypes to the Additional section of a DNS response to 134 increase performance and reduce the number of follow-up 135 queries for other ILNP RRTypes. These other RRsets are added 136 to the Additional section if space permits and only when the 137 QTYPE equals ID, L64, L32, or LP. There is no method for a 138 server to signal that it is ILNP-enabled. 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 141 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described 143 in RFC 2119. [RFC 2119] 145 2. NEW RESOURCE RECORDS 147 This document specifies several new and closely related DNS data 148 Resource Records (RRs). These new RR types have the mnemonics 149 "ID", "L32", "L64", and "LP". These resource record types are 150 associated with a Fully-Qualified Domain Name (FQDN), that is 151 hereafter called the "owner name". These are part of work on the 152 Identifier-Locator Network Protocol (ILNP). [ILNP-Intro] 154 2.1 "ID" Resource Record 156 An ID record has the following logical components: 157 IN ID 159 In the above is the owner name string, 160 is an unsigned 16-bit value, while is an unsigned 64-bit 161 value. 163 The field indicates the owner name's relative 164 preference for this ID record among other ID records 165 associated with this owner name. Lower preference values 166 are preferred over higher preference values. 168 The field complies with the syntactic rules of IPv6 169 Interface Identifiers. Unlike IPv6 Interface Identifiers 170 (which are bound to a specific interface of a specific node), 171 values are bound to a specific node -- and may be used 172 with any interface of that node. 174 An "ID" record has the DNS TYPE of ID and a numeric value of . An ID record is a member of the Internet 176 ("IN") CLASS in the DNS. Each ID record is associated with a 177 owner name entry in the DNS. 179 ID records are present only for owner name values that are 180 ILNP-capable nodes. This restriction is important; ILNP-capable 181 nodes use the presence of ID records in the DNS to learn that a 182 correspondent node is also ILNP-capable. While erroneous ID 183 records in the DNS for an owner name that is not ILNP-capable 184 would not prevent communication, such erroneous DNS records could 185 increase the delay at the start of an IP communications session. 187 Of course, a particular node's owner name might have an ID record 188 in the DNS and yet that node might be temporarily disconnected 189 from the Internet. 191 A given owner name may have zero or more ID records at a given 192 time. In normal operation, nodes that support the 193 Identifier-Locator Network Protocol (ILNP) will have at least one 194 valid ID record. 196 The ID DNS record has the following RDATA format: 198 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 199 | Preference | 200 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 201 | | 202 | ID | 203 | | 204 | | 205 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 207 where: 209 Preference A 16-bit unsigned integer which specifies the 210 preference given to this RR among others at 211 the same owner. Lower Preference values are 212 preferred over higher Preference values. 214 ID A 64-bit unsigned integer. 216 ILNP-enabled DNS servers and DNS caches SHOULD attempt 217 to return all L32, L64, and LP records associated with 218 the owner name of the ID RRset in the Additional section 219 of the response if space permits. 221 2.2 "L32" Resource Record 223 An "L32" record has the DNS TYPE of "L32" and a numeric value of 224 . An L32 record is a member of the 225 Internet ("IN") CLASS in the DNS. Each L32 record is associated 226 with an owner name entry in the DNS. The Preference field 227 indicates the owner name's relative preference for this 228 particular L32 record among other L32 records for the same 229 owner name. 231 An L32 record has the following logical components: 233 IN L32 235 In the above, is the owner name, is an 236 unsigned 16-bit value, while is an unsigned 32-bit value that 237 names a subnetwork where the owner is directly attached. 239 The Preference field indicates the owner name's relative 240 preference for this L32 record among other L32, L64, and LP 241 records associated with this owner name. Lower values are 242 preferred over higher values. 244 A given owner name might have zero or more L32 values at a given 245 time. An ILNP-capable IPv4 host SHOULD have at least 1 Locator 246 (i.e., L32 or LP) DNS resource record while it is connected to 247 the Internet. An ILNP-capable multi-homed IPv4 host normally 248 will have multiple Locator values while multi-homed. An IPv4 249 host that is NOT ILNP-capable MUST NOT have an L32 or LP record 250 in its DNS entries. A node that is not currently connected to 251 the Internet might not have any L32 values in the DNS associated 252 with its . 254 A DNS owner name that is naming a subnetwork, rather than naming 255 a host, MAY have an L32 record as a wild-card entry, thereby 256 applying to entries under that DNS owner name. This deployment 257 scenario probably is most common if the named subnetwork is, was, 258 or might become, mobile. 260 The L32 DNS record has the following RDATA format: 262 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 263 | Preference | 264 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 265 | | 266 | L32 | 267 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 269 where: 271 Preference A 16-bit unsigned integer which specifies the 272 preference given to this RR among others at 273 the same owner. Lower Preference values are 274 preferred over higher Preference values. 276 L32 A 32-bit unsigned integer that names a 277 subnetwork. 279 ILNP-enabled DNS servers and DNS caches SHOULD attempt to return 280 all ID, L64, and LP records for the same owner name of the L32 281 RRset in the Additional section of the response if space permits. 283 2.3 "L64" Resource Record 285 An "L64" record has the DNS TYPE of "L64" and a numeric value 286 of . An L64 record is a member of the 287 Internet ("IN") CLASS in the DNS. Each L64 record is associated 288 with an owner name entry in the DNS. 290 An L64 record has the following logical components: 291 IN L64 293 In the above, is the owner name, is an 294 unsigned 16-bit value, while is an unsigned 64-bit value that 295 names a subnetwork where is directly attached. 297 The Preference field indicates the owner name's relative 298 preference for this L64 record among other L32, L64, and LP 299 records associated with this owner name. Lower Preference values 300 are preferred over higher Preference values. 302 A given owner name may have zero or more L64 values at a given 303 time. An ILNP-capable multi-homed host connected to the Internet 304 will normally have multiple Locator (i.e., L64 or LP) values 305 while multi-homed. 307 A DNS owner name that is naming a subnetwork, rather than naming 308 a host, MAY have an L64 record as a wild-card entry, thereby 309 applying to all entries under that DNS owner name. This 310 deployment scenario is most common if the named subnetwork is, 311 was, or might become, mobile. 313 A DNS owner name that names a single node that is NOT 314 ILNP-capable MUST NOT have an L64 record in the DNS. A node that 315 is not currently connected to the Internet commonly might not 316 have any L64 or LP values in the DNS associated with its owner 317 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-Intro], 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. 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 366 Fully-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 377 DNS 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 381 an LP record with the same value in both the and 382 values. A given owner name will have zero or 383 more 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) 420 to discover the set of ID records, the set of L32 records, 421 the set of L64 records, and the set of LP records that are 422 associated 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 426 for a node that does not support ILNP. This lookup process 427 is considered to be in the "forward" direction. 429 The Preference fields associated with the ID, L32, L64, 430 and LP records are used to indicate the owner name's preference 431 for others to use one particular ID, L32, L64, or LP record, 432 rather than use another ID, L32, L64, or LP record also 433 associated with that owner name. Lower Preference field 434 values are preferred 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 438 single response. Credible anecdotal reports indicate at least 439 one DNS recursive cache implementation actively drops all 440 Additional Data records that were not expected by that DNS 441 recursive cache. So even if the authoritative DNS server 442 includes all the relevant records in the Additional Data 443 section of the DNS response, the querying client might not 444 receive all of those Additional Data records. DNS caches 445 also might purge some ILNP RRsets before others, for example 446 if ID RRsets have a longer DNS TTL value than Locator-related 447 (e.g. LP, L32, L64) RRsets. So a client sending queries to 448 a DNS cache cannot be certain if they have obtained all 449 available RRtypes for a given owner name. Therefore, the DNS 450 client SHOULD send follow-up DNS queries for RRTYPE values 451 that were missing and are desired, to ensure that the client 452 receives all the necessary information. 454 Note that for nodes likely either to be mobile or to be 455 multi-homed, the DNS TTL values for L32 and L64 records 456 normally will be very low, as those values might change 457 frequently. However, the DNS TTL values for ID and LP records 458 normally will be quite long, as those values are not normally 459 impacted by node location changes. Previous trace-driven 460 DNS simulations from MIT [SBK2002] and more recent experimental 461 DNS validation from U. of St Andrews [Bhatti10] both indicate 462 use of very short DNS TTL values is not problematic. 464 Any ID value associated with a DNS owner name can be used 465 with any or all Locator values associated with that 466 same DNS owner name. 468 4. SECURITY CONSIDERATIONS 470 These new DNS resource record types do not create any new 471 vulnerabilities in the Domain Name System. 473 Existing mechanisms for DNS security can be used unchanged with 474 these record types. [RFC 4033] [RFC 3007] As of this writing, 475 those mechanisms are believed to be widely implemented in 476 currently available DNS servers. 478 In situations where authentication of DNS data is a concern, 479 the DNS Security extensions SHOULD be used. [RFC 4033] 481 If these DNS records are updated dynamically over the network, 482 then the Secure Dynamic DNS Update [RFC 3007] mechanism 483 SHOULD be used to secure such transactions. 485 5. IANA CONSIDERATIONS 487 IANA is requested to allocate each of these DNS Resource Records 488 (enumerated above in Section 2) a Data RRTYPE value according to 489 the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of 490 RFC 5395. [RFC 5395] 492 6. REFERENCES 494 6.1 Normative References 496 [RFC 1034] P. Mockapetris, "Domain names - Concepts and 497 Facilities", RFC-1034, 1 November 1987 499 [RFC 1035] P. Mockapetris, "Domain names - Implementation and 500 Specification", RFC-1035, 1 November 1987. 502 [RFC 2119] Bradner, S., "Key words for use in RFCs to 503 Indicate Requirement Levels", BCP 14, RFC 2119, 504 March 1997. 506 [RFC 3007] B. Wellington, "Secure Domain Name System Dynamic 507 Update", RFC 3007, RFC Editor, November 2000. 509 [RFC 3597] A. Gustafsson, "Handling of Unknown DNS Resource 510 Record (RR) Types", RFC 3597, September 2003. 512 [RFC 4033] R. Arends, R. Austein, M. Larson, D. Massey, & 513 S. Rose, "DNS Security Introduction & Requirements", 514 RFC 4033, RFC Editor, March 2005. 516 [RFC 5395] D. Eastlake 3rd, "Domain Name System IANA 517 Considerations", RFC 5395, November 2008. 519 [ILNP-ARCH] R. Atkinson & S. Bhatti, "ILNP Architecture", 520 draft-irtf-rrg-ilnp-arch, January 2012. 522 [ILNP-ENG] R. Atkinson & S. Bhatti, "ILNP Engineering and 523 Implementation Considerations", 524 draft-irtf-rrg-ilnp-eng, January 2012. 526 6.2 INFORMATIVE REFERENCES 528 [Bhatti10] S. Bhatti, "Reducing DNS Caching (or 'How low 529 can we go ?')", Presentation to 38th JANET 530 Networkshop, 31st March 2010, UK Joint 531 Academic Network (JANET), University of Manchester, 532 Manchester, England, UK. 534 [PHG2002] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, 535 "Mobile Host Location Tracking through DNS", 536 IEEE London Communications Symposium, 537 London, England, UK, September 2002. 538 540 [SBK2002] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 541 Kaashoek, "Reconsidering Internet Mobility", 542 Proceedings of 8th Workshop on Hot Topics in 543 Operating Systems, 2002. 545 7. ACKNOWLEDGEMENTS 547 Mohamed Boucadair, Noel Chiappa, Steve Blake, Steve Hailes, Joel 548 Halpern, Mark Handley, Volker Hilt, Tony Li, and Yakov Rehkter 549 (in alphabetical order) provided review and feedback on earlier 550 versions of the ILNP documents. Steve Blake provided an 551 especially thorough review of the entire ILNP document set. 553 Authors' Addresses: 555 RJ Atkinson 556 Consultant 557 San Jose, CA 558 95125 USA 560 Email: rja.lists@gmail.com 562 S Bhatti 563 School of Computer Science 564 University of St Andrews 565 North Haugh, St Andrews 566 Fife, Scotland, UK 567 KY16 9SX 569 Scott Rose 570 US National Institute for Standards & Technology 571 100 Bureau Drive 572 Gaithersburg, MD 573 20899 USA 575 Email: scottr.nist@gmail.com 577 [NOTE: Appendix A is to be removed by the 578 RFC Editor prior to publication.] 580 Appendix A: 582 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 584 When ready for formal consideration, this template is 585 to be submitted to IANA for processing by emailing the 586 template to dns-rrtype-applications@ietf.org. 588 A. Submission Date: To be determined. 590 B. Submission Type: 591 [X] New RRTYPE 593 C. Contact Information for submitter: 594 Name: R. Atkinson 595 Email Address: rja.lists@gmail.com 596 International telephone number: unlisted 597 Other contact handles: 599 D. Motivation for the new RRTYPE application? 601 Support for an experimental set of IP extensions 602 that replace the concept of an "IP Address" with 603 distinct "Locator" and "Identifier" values. 605 E. Description of the proposed RR type. 607 Please see draft-rja-ilnp-dns-07.txt for a full 608 description. 610 F. What existing RRTYPE or RRTYPEs come closest to filling that 611 need and why are they unsatisfactory? 613 The AAAA record combines both Locator and Identifier, 614 so has significantly different semantics than having 615 separate L64 and ID record values. The AAAA record also 616 lacks scalability and flexibility in the context of the 617 experimental protocol extensions that will use the ID 618 and L64 records, as any valid ID record value for a node 619 can be used on the wire with any valid L64 record value 620 for the same node. 622 The CNAME record is closest conceptually to an "LP" 623 record, but a CNAME is a node name referral scheme, 624 while the LP record is indicating that the given node 625 has the same routing prefix as some other domain name, 626 but does not necessarily have any other values that are 627 the same. 629 Lastly, the AAA and CNAME RR Types lack a preference 630 field to rank responses. Such preference information 631 is useful with ILNP. 633 G. What mnemonic is requested for the new RRTYPE (optional)? 635 As described in this draft, "ID", "L32", "L64", and "LP". 637 H. Does the requested RRTYPE make use of any existing IANA 638 Registry or require the creation of a new IANA 639 sub-registry in DNS Parameters? 641 Existing registry of DNS Resource Record (RR) data TYPE 642 values should be used. 644 I. Does the proposal require/expect any changes in DNS 645 servers/resolvers that prevent the new type from being 646 processed as an unknown RRTYPE (see [RFC 3597])? 648 No. 650 J. Comments: 651 This document defines "ILNP-enabled" DNS servers 652 or DNS caches as a DNS server (authoritative or recursive) 653 that include other ILNP RRTypes in the Additional 654 section of a DNS response that match a QNAME (if 655 size permits). This is to reduce the number of 656 client follow-up DNS queries and only applies when the 657 QTYPE is either ID, L32, L64, or LP. There is no 658 signalling mechanism for this Additional section 659 processing, and this is believed to be compatible 660 with existing non-ILNP-enabled DNS servers and clients. 662 No changes are required for existing deployed 663 DNS servers or DNS caches. 665 Expires: 09 JUL 2012