idnits 2.17.1 draft-irtf-rrg-ilnp-dns-03.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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 May 2012) is 4361 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'X' is defined on line 876, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) Summary: 1 error (**), 0 flaws (~~), 4 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-03.txt Consultant 4 Expires: 17 NOV 2012 SN Bhatti 5 Category: Experimental U. St Andrews 6 Scott Rose 7 US NIST 8 17 May 2012 10 DNS Resource Records for ILNP 11 draft-irtf-rrg-ilnp-dns-03.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 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 NID 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]. 112 More recently, the IETF have defined standards-track security 113 extensions to the DNS [RFC4033]. These security extensions can 114 be used to authenticate signed DNS data records and can also be 115 used to store signed public keys in the DNS. Further, the IETF 116 have defined a standards-track approach to enable secure dynamic 117 update of DNS records over the network [RFC3007]. 119 This document defines several new optional data Resource 120 Records. This note specifies the syntax and other items 121 required for independent implementations of these DNS resource 122 records. The reader is assumed to be familiar with the basics 123 of DNS, including familiarity with [RFC1034] [RFC1035]. 125 The concept of using DNS for rendezvous with mobile nodes or 126 mobile networks has been proposed earlier, more than once, 127 independently, by several other researchers; for example, 128 please see [SB00] [SBK01] and [PHG02]. 130 1.1 Terminology 132 In this document, the term "ILNP-aware" applied to a DNS 133 component (either authoritative server or cache) is used to 134 indicate that the component attempts to include other ILNP 135 RRTypes to the Additional section of a DNS response to 136 increase performance and reduce the number of follow-up 137 queries for other ILNP RRTypes. These other RRsets MAY be added 138 to the Additional section if space permits and only when the 139 QTYPE equals NID, L64, L32, or LP. There is no method for a 140 server to signal that it is ILNP-aware. 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 143 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described 145 in RFC 2119 [RFC2119]. 147 2. NEW RESOURCE RECORDS 149 This document specifies several new and closely related DNS data 150 Resource Records (RRs). These new RR types have the mnemonics 151 "NID", "L32", "L64", and "LP". These resource record types are 152 associated with a Fully-Qualified Domain Name (FQDN), that is 153 hereafter called the "owner name". These are part of work on the 154 Identifier-Locator Network Protocol (ILNP) [ILNP-ARCH]. 156 For clarity, throughout this section of this document, the 157 "RDATA" subsections specify the on-the-wire format for these 158 records, while the "Presentation Format" subsections specify the 159 human-readable format used in a DNS configuration file 160 (i.e. "master file" as defined by RFC-1035, Section 5.1). 162 2.1 The NID Resource Record 164 The NID DNS Resource Record (RR) is used hold values for Node 165 Identifiers that will be used for ILNP-capable nodes. 167 NID records are present only for ILNP-capable nodes. This 168 restriction is important; ILNP-capable nodes use the presence of 169 NID records in the DNS to learn that a correspondent node is also 170 ILNP-capable. While erroneous NID records in the DNS for an node 171 that is not ILNP-capable would not prevent communication, such 172 erroneous DNS records could increase the delay at the start of an 173 IP communications session. 175 A given owner name may have zero or more NID records at a given 176 time. In normal operation, nodes that support the Identifier- 177 Locator Network Protocol (ILNP) will have at least one valid NID 178 record. 180 The type value for the NID RR type is X-NID-X . 182 The NID RR is class independent. 184 The NID RR has no special TTL requirements. 186 2.1.1 NID RDATA wire format 188 The RDATA for an NID RR consists of: 190 - a 16 bit Preference field 191 - a 64 bit NodeID field 192 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Preference | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 197 | NodeID | 198 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 2.1.1.1 The Preference field 204 The field contains a 16-bit unsigned integer in 205 network byte-order that indicates the owner name's relative 206 preference for this NID record among other NID records associated 207 with this owner name. Lower Preference values are preferred over 208 higher Preference values. 210 2.1.1.2 The NodeID field 212 The NodeID field is an unsigned 64-bit value in network 213 byte-order. It complies with the syntactic rules of IPv6 214 Interface Identifiers [RFC-4291, Section 2.5.1], but has slightly 215 different semantics. Unlike IPv6 Interface Identifiers, which are 216 bound to a specific *interface* of a specific node, NodeID values 217 are bound to a specific *node*, and MAY be used with *any 218 interface* of that node. 220 2.1.2 NID RR Presentation Format 222 The presentation of the format of the RDATA portion is as follows: 224 - The Preference field MUST be represented as a 16-bit unsigned 225 decimal integer. 227 - The NodeID field MUST be represented using the same syntax 228 (i.e. groups of 4 hexadecimal digits, with each group 229 separated by a colon) that is already used for DNS AAAA 230 records (and also used for IPv6 Interface IDs). 232 - The NodeID value MUST NOT be in the 'compressed' format 233 (e.g. using "::") that is defined in RFC-4291, Section 2.2 234 (2). This restriction exists to avoid confusion with 128-bit 235 IPv6 addresses, because the NID is a 64-bit field. 237 2.1.3 NID RR Examples 239 An NID record has the following logical components: 240 IN NID 242 In the above, is the owner name string, 243 is an unsigned 16-bit value, and is an unsigned 64-bit 244 value. 246 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 247 host1.example.com. IN NID 20 0015:5fff:ff21:ee65 248 host2.example.com. IN NID 10 0016:6fff:ff22:ee66 250 As NodeID values use the same syntax as IPv6 interface 251 identifiers, when displayed for human readership, the NodeID 252 values are presented in the same hexadecimal format as IPv6 253 interface identifiers. This is shown in the example above. 255 2.1.4 Additional Section Processing 257 To improve performance, ILNP-aware DNS servers and DNS resolvers 258 MAY attempt to return all L32, L64, and LP records for the same 259 owner name of the NID RRset in the Additional section of the 260 response, if space permits. 262 2.2 The L32 Resource Record 264 An L32 DNS Resource Record (RR) is used to hold 32-bit 265 Locator values for ILNPv4-capable nodes. 267 L32 records are present only for ILNPv4-capable nodes. This 268 restriction is important; ILNP-capable nodes use the presence of 269 L32 records in the DNS to learn that a correspondent node is also 270 ILNPv4-capable. While erroneous L32 records in the DNS for a 271 node that is not ILNP-capable would not prevent communication, 272 such erroneous DNS records could increase the delay at the start 273 of an IP communications session. 275 A given owner name might have zero or more L32 values at a given 276 time. An ILNPv4-capable host SHOULD have at least 1 Locator 277 (i.e., L32 or LP) DNS resource record while it is connected to 278 the Internet. An ILNPv4-capable multi-homed host normally 279 will have multiple Locator values while multi-homed. An IP 280 host that is NOT ILNPv4-capable MUST NOT have an L32 or LP record 281 in its DNS entries. A node that is not currently connected to 282 the Internet might not have any L32 values in the DNS associated 283 with its owner name. 285 A DNS owner name that is naming a subnetwork, rather than naming 286 a host, MAY have an L32 record as a wild-card entry, thereby 287 applying to entries under that DNS owner name. This deployment 288 scenario probably is most common if the named subnetwork is, was, 289 or might become, mobile. 291 The type value for the L32 RR type is X-L32-X . 293 The L32 RR is class independent. 295 The L32 RR has no special TTL requirements. 297 2.2.1 L32 RDATA Wire Format 299 The RDATA for an L32 RR consists of: 301 - a 16 bit Preference field 302 - a 32 bit Locator32 field 304 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Preference | Locator32 (16 MSBs) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Locator32 (16 LSBs) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 2.2.1.1 The Preference field 314 The field is an unsigned 16-bit field in network 315 byte-order that indicates the owner name's relative preference 316 for this L32 record among other L32 records associated with this 317 owner name. Lower Preference values are preferred over higher 318 Preference values. 320 2.2.1.2 The Locator32 field 322 The field is an unsigned 32-bit integer in network 323 byte-order that is identical on-the-wire to the ADDRESS field 324 of the existing DNS A record. 326 2.2.2 L32 RR Presentation Format 328 The presentation of the format of the RDATA portion is as follows: 330 - The Preference field MUST be represented as a 16-bit unsigned 331 decimal integer. 333 - The Locator32 field MUST be represented using the same syntax 334 used for existing DNS A records (i.e. 4 decimal numbers 335 separated by periods without any embedded spaces). 337 2.2.3 L32 RR Examples 339 An L32 record has the following logical components: 340 IN L32 342 In the above is the owner name string, 343 is an unsigned 16-bit value, and is an unsigned 32-bit 344 value. 346 host1.example.com. IN L32 10 10.1.02.0 347 host1.example.com. IN L32 20 10.1.04.0 348 host2.example.com. IN L32 10 10.1.08.0 350 As L32 values have the same syntax and semantics as IPv4 routing 351 prefixes, when displayed for human readership, the values are 352 presented in the same dotted-decimal format as IPv4 addresses. 353 An example of this syntax is shown above. 355 In the example above, the owner name is from a FQDN for an 356 individual host. host1.example.com has two L32 values, so 357 host1.example.com is multi-homed. 359 Another example is when the owner name is that learned from an LP 360 record (see below for details of LP records). 362 l32-subnet1.example.com. IN L32 10 10.1.02.0 363 l32-subnet2.example.com. IN L32 20 10.1.04.0 364 l32-subnet3.example.com. IN L32 30 10.1.08.0 366 In this example above, the owner name is for a subnetwork rather 367 than an individual node. 369 2.2.4 Additional Section Processing 371 To improve performance, ILNP-aware DNS servers and DNS resolvers 372 MAY attempt to return all NID, L64, and LP records for the same 373 owner name of the L32 RRset in the Additional section of the 374 response, if space permits. 376 2.3 The L64 Resource Record 378 The L64 resource record (RR) is used to hold unsigned 64-bit 379 Locator Values for ILNPv6-capable nodes. 381 L64 records are present only for ILNPv6-capable nodes. This 382 restriction is important; ILNP-capable nodes use the presence of 383 L64 records in the DNS to learn that a correspondent node is also 384 ILNPv6-capable. While erroneous L64 records in the DNS for a 385 node that is not ILNP-capable would not prevent communication, 386 such erroneous DNS records could increase the delay at the start 387 of an IP communications session. 389 A given owner name might have zero or more L64 values at a given 390 time. An ILNPv6-capable host SHOULD have at least 1 Locator 391 (i.e., L64 or LP) DNS resource record while it is connected to 392 the Internet. An ILNPv6-capable multi-homed host normally 393 will have multiple Locator values while multi-homed. An IP 394 host that is NOT ILNPv6-capable MUST NOT have an L64 or LP record 395 in its DNS entries. A node that is not currently connected to 396 the Internet might not have any L64 values in the DNS associated 397 with its owner name. 399 A DNS owner name that is naming a subnetwork, rather than naming 400 a host, MAY have an L64 record as a wild-card entry, thereby 401 applying to entries under that DNS owner name. This deployment 402 scenario probably is most common if the named subnetwork is, was, 403 or might become, mobile. 405 The type value for the L64 RR type is X-L64-X . 407 The L64 RR is class independent. 409 The L64 RR has no special TTL requirements. 411 2.3.1 The L64 RDATA Wire Format 413 The RDATA for an L64 RR consists of: 415 - a 16 bit Preference field 416 - a 64 bit Locator64 field 418 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 419 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Preference | | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 423 | Locator64 | 424 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 2.3.1.1 The Preference field 430 The field is an unsigned 16-bit integer in network 431 byte-order that indicates the owner name's relative preference 432 for this L64 record among other L64 records associated with this 433 owner name. Lower Preference values are preferred over higher 434 Preference values. 436 2.3.1.2 The Locator64 field 438 The field is an unsigned 64-bit integer in network 439 byte-order that has the same syntax and semantics as a 64-bit 440 IPv6 routing prefix. 442 2.3.2 L64 RR Presentation Format 444 The presentation of the format of the RDATA portion is as follows: 446 - The Preference field MUST be represented as a 16-bit unsigned 447 decimal integer. 449 - The Locator64 field MUST be represented using the same syntax 450 used for AAAA records (i.e. groups of 4 hexadecimal digits 451 separated by colons). However, the 'compressed' display 452 format (e.g. using "::") that is specified in RFC-4291, 453 Section 2.2 (2), MUST NOT be used. This is done to avoid 454 confusion with a 128-bit IPv6 address, since the Locator64 is 455 a 64-bit value, while the IPv6 address is a 128-bit value. 457 2.3.3 L64 RR Examples 459 An L64 record has the following logical components: 460 IN L64 462 In the above, is the owner name string, 463 is an unsigned 16-bit value, while is an unsigned 464 64-bit value. 466 host1.example.com. IN L64 10 2001:0DB8:1140:1000 467 host1.example.com. IN L64 20 2001:0DB8:2140:2000 468 host2.example.com. IN L64 10 2001:0DB8:4140:4000 470 As L64 values have the same syntax and semantics as IPv6 routing 471 prefixes, when displayed for human readership, the values might 472 conveniently be presented in hexadecimal format, as above. 474 In the example above, the owner name is from a FQDN for an 475 individual host. host1.example.com has two L64 values, so it will 476 be multi-homed. 478 Another example is when the owner name is that learned from an LP 479 record (see below for details of LP records). 481 l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000 482 l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000 483 l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000 485 Here, the owner name is for a subnetwork rather than an individual 486 node. 488 2.3.4 Additional Section Processing 490 To improve performance, ILNP-aware DNS servers and DNS resolvers 491 MAY attempt to return all NID, L32, and LP records for the same 492 owner name of the L64 RRset in the Additional section of the 493 response, if space permits. 495 2.4 The LP Resource Record 497 The LP DNS resource record (RR) is used to hold the name of a 498 subnetwork for ILNP. The name is an FQDN which can then be used 499 to look up L32 or L64 records. LP is, effectively, a Locator 500 Pointer to L32 and/or L64 records. 502 As described in [ILNP-ARCH], the LP RR provides one level of 503 indirection within the DNS in naming a Locator value. This is 504 useful in several deployment scenarios, such as for a multi-homed 505 site where the multi-homing is handled entirely by the site's 506 border routers (e.g. via Locator rewriting) or in some mobile 507 network deployment scenarios [ILNP-ADV]. 509 LP records MUST NOT be present for owner name values that are not 510 ILNP-capable nodes. This restriction is important; ILNP-capable 511 nodes use the presence of LP records in the DNS to infer that 512 a correspondent node is also ILNP-capable. While erroneous LP 513 records in the DNS for an owner name would not prevent 514 communication, presence of such erroneous DNS records could 515 increase the delay at the start of a communications session. 517 The type value for the LP RR type is X-LP-X . 519 The LP RR is class independent. 521 The LP RR has no special TTL requirements. 523 2.4.1 LP RDATA Wire Format 525 The RDATA for an LPP RR consists of: 527 - an unsigned 16 bit Preference field 528 - a variable-length FQDN field 530 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 531 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Preference | / 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 535 / / 536 / FQDN / 537 / / 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 2.4.1.1 The Preference field 542 The field contains an unsigned 16-bit integer in 543 network-byte order that indicates the owner name's relative 544 preference for this LP record among other LP records associated 545 with this owner name. Lower Preference values are preferred over 546 higher Preference values. 548 2.4.1.2 The FQDN field 550 The variable-length FQDN field contains the DNS target name that 551 is used to reference L32 and/or L64 records. This field MUST NOT 552 have the same value as the owner name of the LP RR instance. 554 2.4.2 LP RR Presentation Format 556 The presentation of the format of the RDATA portion is as follows: 558 - The Preference field MUST be represented as a 16-bit unsigned 559 decimal integer. 561 - The FQDN field MUST be represented as a wire-encoded domain 562 name, as described in Section 3.3 of RFC 1035 [RFC1035]. The 563 wire-encoded format is self-describing, so the length is 564 implicit. The domain names MUST NOT be compressed. 566 2.4.3 LP RR Examples 568 An LP record has the following logical components: 569 IN LP 571 In the above, is the owner name string, 572 is an unsigned 16-bit value, while is the domain name 573 which should be resolved further. 575 host1.example.com. IN LP 10 l64-subnet1.example.com. 576 host1.example.com. IN LP 10 l64-subnet2.example.com. 577 host1.example.com. IN LP 20 l32-subnet1.example.com. 579 In the example above, host1.example.com is multi-homed on three 580 subnets. Resolving the FQDNs return in the LP records would 581 allow the actual subnet prefixes to be resolved, e.g. as in the 582 examples for the L32 and L64 RR descriptions, above. This level 583 of indirection allows the same L32 and/or L64 records to be used 584 by many hosts in the same subnetwork, easing management of the 585 ILNP network and potentially reducing the number of DNS Update 586 transactions, especially when that network is mobile [RAB09] or 587 multi-homed [ABH09a]. 589 2.4.4 Additional Section Processing 591 To improve performance, ILNP-aware DNS servers and DNS resolvers 592 MAY attempt to return all L32 and L64 records for the same owner 593 name of the LP RRset in the Additional section of the response, 594 if space permits. 596 3. DEPLOYMENT EXAMPLE 598 Given a domain name, one can use the Domain Name System (DNS) to 599 discover the set of NID records, the set of L32 records, the set 600 of L64 records, and the set of LP records that are associated 601 with that DNS owner name. 603 For example: 605 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 606 host1.example.com. IN L64 10 2001:0DB8:1140:1000 608 would be the minimum requirement for an ILNPv6 node that has 609 owner name host1.example.com and is connected to the Internet at 610 the subnetwork having routing prefix 2001:0DB8:1140:1000. 612 If that host were multi-homed on two different IPv6 subnets: 614 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 615 host1.example.com. IN L64 10 2001:0DB8:1140:1000 616 host1.example.com. IN L64 20 2001:0DB8:2140:2000 618 would indicate the Identifier and two subnets that 619 host1.example.com is attached to, along with the relative 620 preference that a client would use in selecting the 621 Locator value for use in initiating communication. 623 If host1.example.com were part of a mobile network, 624 a DNS query might return: 626 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 627 host1.example.com. IN LP 10 mobile-net1.example.com. 629 and then a DNS query to find the current Locator value(s) 630 for the node named by the LP record: 632 mobile-net1.example.com. IN L64 2001:0DB8:8140:8000 634 3.1 Use of ILNP records 636 As these DNS records are only used with the Identifier-Locator 637 Network Protocol (ILNP), these records MUST NOT be present for a 638 node that does not support ILNP. This lookup process is 639 considered to be in the "forward" direction. 641 The Preference fields associated with the NID, L32, L64, and LP 642 records are used to indicate the owner name's preference for 643 others to use one particular NID, L32, L64, or LP record, rather 644 than use another NID, L32, L64, or LP record also associated with 645 that owner name. Lower Preference field values are preferred 646 over higher Preference field values. 648 It is possible that a DNS stub resolver querying for one of these 649 record types will not receive all NID, L32, L64, and LP RR's in a 650 single response. Credible anecdotal reports indicate at least 651 one DNS recursive cache implementation actively drops all 652 Additional Data records that were not expected by that DNS 653 recursive cache. So even if the authoritative DNS server includes 654 all the relevant records in the Additional Data section of the 655 DNS response, the querying DNS stub resolver might not receive 656 all of those Additional Data records. DNS resolvers also might 657 purge some ILNP RRsets before others, for example if NID RRsets 658 have a longer DNS TTL value than Locator-related (e.g. LP, L32, 659 L64) RRsets. So a DNS stub resolver sending queries to a DNS 660 resolver cannot be certain if they have obtained all available 661 RRtypes for a given owner name. Therefore, the DNS stub resolver 662 SHOULD send follow-up DNS queries for RRTYPE values that were 663 missing and are desired, to ensure that the DNS stub resolver 664 receives all the necessary information. 666 Note nodes likely either to be mobile or to be multi-homed 667 normally will have very low DNS TTL values for L32 and L64 668 records, as those values might change frequently. However, the 669 DNS TTL values for NID and LP records normally will be higher, 670 as those values are not normally impacted by node location 671 changes. Previous trace-driven DNS simulations from MIT [JSBM02] 672 and more recent experimental validation of operational DNS from 673 U. of St Andrews [BA11] both indicate deployment and use of very 674 short DNS TTL values within 'stub' or 'leaf' DNS domains is not 675 problematic. 677 An ILNP node MAY use any NID value associated with its DNS owner 678 name with any or all Locator (L32 or L64) values also associated 679 with its DNS owner name. 681 3.2 Additional Section Processing 683 For all the records above, Additional Section Processing MAY be 684 used. This is intended to improve performance for both the DNS 685 client and the DNS server. For example, a node sending DNS query 686 for an NID owner name, such as host1.example.com, would benefit 687 from receiving all ILNP DNS records related to that owner name 688 being returned, as it is quite likely that the client will need 689 that information to initiate an ILNP communication session. 691 However, this is not always the case: a DNS query for L64 for a 692 particular owner name might be made because the DNS TTL for a 693 previously resolved L64 RR has expired, while the NID RR for that 694 same owner name has a DNS TTL that has not expired. 696 4. SECURITY CONSIDERATIONS 698 These new DNS resource record types do not create any new 699 vulnerabilities in the Domain Name System. 701 Existing mechanisms for DNS Security can be used unchanged with 702 these record types [RFC4033] [RFC3007]. As of this writing, the 703 DNS Security mechanisms are believed to be widely implemented 704 in currently available DNS servers and DNS clients. Deployment 705 of DNS Security appears to be growing rapidly. 707 In situations where authentication of DNS data is a concern, 708 the DNS Security extensions SHOULD be used [RFC4033]. 710 If these DNS records are updated dynamically over the network, 711 then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be 712 used to secure such transactions. 714 5. IANA CONSIDERATIONS 716 IANA is requested to allocate each of these DNS Resource Records 718 NID 719 L32 720 L64 721 LP 723 (described above in Section 2) a Data RRTYPE value according to 724 the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of 725 RFC 6195 [RFC6195]. 727 6. REFERENCES 729 6.1 Normative References 731 [RFC1034] P. Mockapetris, "Domain names - Concepts and 732 Facilities", RFC-1034, 1 November 1987 734 [RFC1035] P. Mockapetris, "Domain names - Implementation and 735 Specification", RFC-1035, 1 November 1987. 737 [RFC2119] Bradner, S., "Key words for use in RFCs to 738 Indicate Requirement Levels", BCP 14, RFC 2119, 739 March 1997. 741 [RFC3007] B. Wellington, "Secure Domain Name System Dynamic 742 Update", RFC 3007, RFC Editor, November 2000. 744 [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource 745 Record (RR) Types", RFC 3597, September 2003. 747 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, & 748 S. Rose, "DNS Security Introduction & Requirements", 749 RFC 4033, RFC Editor, March 2005. 751 [RFC6195] D. Eastlake 3rd, "Domain Name System IANA 752 Considerations", RFC 6195, March 2011. 754 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", 755 draft-irtf-rrg-ilnp-arch, May 2012. 757 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 758 "Optional Advanced Deployment Scenarios for ILNP", 759 draft-irtf-rrg-ilnp-adv, May 2012 761 [ILNP-ENG] R. Atkinson & S. Bhatti, "ILNP Engineering and 762 Implementation Considerations", 763 draft-irtf-rrg-ilnp-eng, May 2012. 765 6.2 INFORMATIVE REFERENCES 767 [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, 768 "Site-Controlled Secure Multi-Homing and Traffic 769 Engineering For IP", Proc. MILCOM2009 - 28th IEEE 770 Military Communications Conference, Boston, MA, USA. 771 Oct 2009. 773 [BA11] S. Bhatti & R. Atkinson, 774 "Reducing DNS Caching", 775 Proc. GI2011 - 14th IEEE Global Internet Symposium, 776 Shanghai, China. 15 Apr 2011. 777 779 [JSBM02] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, 780 DNS performance and the effectiveness of caching. 781 IEEE/ACM Trans. Netw. 10(5) (October 2002), 589-603. 782 784 [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, 785 "Mobile Host Location Tracking through DNS", 786 IEEE London Communications Symposium, London, 787 England, UK, September 2002. 788 790 [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, 791 "Enabling Mobile Networks Through Secure Naming", 792 Proc. MILCOM2009 - 28th IEEE Military Communications 793 Conference (MILCOM), Boston, MA, USA, Oct 2009 795 [SB00] Alex C. Snoeren and Hari Balakrishnan. 2000. 796 "An End-To-End Approach To Host Mobility", Proc. 797 6th Conference on Mobile Computing And Networking 798 (MobiCom), ACM, Boston, MA, USA, pp. 155-166, 799 August 2000. 801 [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 802 Kaashoek, "Reconsidering Internet Mobility", 803 Proceedings of 8th Workshop on Hot Topics in 804 Operating Systems (HotOS), IEEE Computer Society, 805 Washington, DC, USA, May 2001. 807 ACKNOWLEDGEMENTS 809 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 810 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 811 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 812 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 813 order) provided review and feedback on earlier versions of this 814 document. Steve Blake provided an especially thorough review of 815 an early version of the entire ILNP document set, which was 816 extremely helpful. We also wish to thank the anonymous reviewers 817 of the various ILNP papers for their feedback. 819 Roy Arends provided expert guidance on technical and procedural 820 aspects of DNS issues, for which the authors are greatly obliged. 822 RFC EDITOR NOTE 824 This section is to be removed prior to publication. 826 This document is written in English, not American. So English 827 spelling is used throughout, rather than American spelling. 828 This is consistent with existing practice in several other RFCs, 829 for example RFC-5887. 831 This document tries to be very careful with history, in the 832 interest of correctly crediting ideas to their earliest 833 identifiable author(s). So in several places the first published 834 RFC about a topic is cited rather than the most recent published 835 RFC about that topic. 837 Authors' Addresses: 839 RJ Atkinson 840 Consultant 841 San Jose, CA 842 95125 USA 844 Email: rja.lists@gmail.com 845 SN Bhatti 846 School of Computer Science 847 University of St Andrews 848 North Haugh, St Andrews 849 Fife, Scotland, UK 850 KY16 9SX 852 Email: saleem@cs.st-andrews.ac.uk 854 Scott Rose 855 US National Institute for Standards & Technology 856 100 Bureau Drive 857 Gaithersburg, MD 858 20899 USA 860 Email: scottr.nist@gmail.com 862 [NOTE: Appendix A is to be removed by the 863 RFC Editor prior to publication.] 865 Appendix A: 867 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 869 When ready for formal consideration, this template is 870 to be submitted to IANA for processing by emailing the 871 template to dns-rrtype-applications@ietf.org. 873 A. Submission Date: To be determined. 875 B. Submission Type: 876 [X] New RRTYPE 878 C. Contact Information for submitter: 879 Name: R. Atkinson 880 Email Address: rja.lists@gmail.com 881 International telephone number: unlisted 882 Other contact handles: 884 D. Motivation for the new RRTYPE application? 886 Support for an experimental set of IP extensions 887 that replace the concept of an "IP Address" with 888 distinct "Locator" and "Identifier" values. 890 E. Description of the proposed RR type. 892 Please see: 894 http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-03.txt 896 for a full description. 898 F. What existing RRTYPE or RRTYPEs come closest to filling 899 that need and why are they unsatisfactory? 901 There is no RRTYPE that fulfils the need due to the 902 new semantics of Locator and Identifier values. 904 The AAAA record combines both Locator and Identifier, 905 so has significantly different semantics than having 906 separate L64 and NID record values. The AAAA record also 907 lacks scalability and flexibility in the context of the 908 experimental protocol extensions that will use the NID 909 and L64 records, as any valid NID record value for a node 910 can be used on the wire with any valid L64 record value 911 for the same node. 913 The CNAME record is closest conceptually to an LP 914 record, but a CNAME is a node name referral scheme, 915 while the LP record is indicating that the given node 916 has the same routing prefix as some other domain name, 917 but does not necessarily have any other values that are 918 the same. 920 Lastly, the AAAA and CNAME RR Types lack a Preference 921 field to rank responses. Such Preference information 922 is required for ILNP in order to support the use of multiple 923 instances of NID, L32, L64 and LP records. 925 G. What mnemonic is requested for the new RRTYPE (optional)? 927 As described in this draft, "NID", "L32", "L64", and "LP". 929 H. Does the requested RRTYPE make use of any existing IANA 930 Registry or require the creation of a new IANA 931 sub-registry in DNS Parameters? 933 Existing registry of DNS Resource Record (RR) data TYPE 934 values should be used. 936 I. Does the proposal require/expect any changes in DNS 937 servers/resolvers that prevent the new type from being 938 processed as an unknown RRTYPE (see [RFC3597]) ? 940 No. 942 J. Comments: 943 This document defines "ILNP-aware" DNS servers 944 or DNS resolver as a DNS server (authoritative or recursive) 945 that MAY include other ILNP RRTypes in the Additional 946 section of a DNS response that match a QNAME (if 947 size permits). This is to reduce the number of 948 DNS stub resolver follow-up DNS queries. and only applies 949 when the QTYPE is either NID, L32, L64, or LP. There is no 950 signalling mechanism for this Additional section 951 processing, and this is believed to be compatible 952 with existing non-ILNP-aware DNS servers and DNS stub 953 resolvers. 955 No changes are required for existing deployed 956 DNS servers or DNS resolvers. 958 Expires: 17 NOV 2012