idnits 2.17.00 (12 Aug 2021) /tmp/idnits21685/draft-irtf-rrg-ilnp-dns-06.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 (10 July 2012) is 3595 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC4984' is mentioned on line 104, but not defined == Unused Reference: 'X' is defined on line 965, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6195 (Obsoleted by RFC 6895) == Outdated reference: draft-irtf-rrg-ilnp-arch has been published as RFC 6740 == Outdated reference: draft-irtf-rrg-ilnp-eng has been published as RFC 6741 == Outdated reference: draft-irtf-rrg-ilnp-adv has been published as RFC 6748 == Outdated reference: draft-irtf-rrg-ilnp-arp has been published as RFC 6747 == Outdated reference: draft-irtf-rrg-ilnp-icmpv4 has been published as RFC 6745 == Outdated reference: draft-irtf-rrg-ilnp-icmpv6 has been published as RFC 6743 == Outdated reference: draft-irtf-rrg-ilnp-noncev6 has been published as RFC 6744 == Outdated reference: draft-irtf-rrg-ilnp-v4opts has been published as RFC 6746 Summary: 1 error (**), 0 flaws (~~), 13 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-06.txt Consultant 4 Expires: 10 JAN 2013 SN Bhatti 5 Category: Experimental U. St Andrews 6 Scott Rose 7 US NIST 8 10 July 2012 10 DNS Resource Records for ILNP 11 draft-irtf-rrg-ilnp-dns-06.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 At present, the Internet research and development community are 102 exploring various approaches to evolving the Internet 103 Architecture to solve a variety of issues including, but not 104 limited to, scalability of inter-domain routing [RFC4984]. A wide 105 range of other issues (e.g. site multi-homing, node multi-homing, 106 site/subnet mobility, node mobility) are also active concerns at 107 present. Several different classes of evolution are being 108 considered by the Internet research & development community. One 109 class is often called "Map and Encapsulate", where traffic would 110 be mapped and then tunnelled through the inter-domain core of the 111 Internet. Another class being considered is sometimes known as 112 "Identifier/Locator Split". This document relates to a proposal 113 that is in the latter class of evolutionary approaches. 115 The Identifier-Locator Network Protocol (ILNP) was developed to 116 explore a possible evolutionary direction for the Internet 117 Architecture. An description of the ILNP architecture is 118 available in a separate document [ILNP-ARCH]. Implementation and 119 engineering details are largely isolated into a second document 120 [ILNP-ENG]. 122 The Domain Name System (DNS) is the standard way that Internet 123 nodes locate information about addresses, mail exchangers, and 124 other data relating to remote Internet nodes [RFC1034] [RFC1035]. 126 More recently, the IETF have defined standards-track security 127 extensions to the DNS [RFC4033]. These security extensions can 128 be used to authenticate signed DNS data records and can also be 129 used to store signed public keys in the DNS. Further, the IETF 130 have defined a standards-track approach to enable secure dynamic 131 update of DNS records over the network [RFC3007]. 133 This document defines several new optional data Resource 134 Records. This note specifies the syntax and other items 135 required for independent implementations of these DNS resource 136 records. The reader is assumed to be familiar with the basics 137 of DNS, including familiarity with [RFC1034] [RFC1035]. 139 The concept of using DNS for rendezvous with mobile nodes or 140 mobile networks has been proposed earlier, more than once, 141 independently, by several other researchers; for example, 142 please see [SB00] [SBK01] and [PHG02]. 144 1.1 Document roadmap 146 This document describes defines additional DNS resource records 147 that support ILNP. 149 The ILNP architecture can have more than one engineering 150 instantiation. For example, one can imagine a "clean-slate" 151 engineering design based on the ILNP architecture. In separate 152 documents, we describe two specific engineering instances of 153 ILNP. The term ILNPv6 refers precisely to an instance of ILNP that 154 is based upon, and backwards compatible with, IPv6. The term ILNPv4 155 refers precisely to an instance of ILNP that is based upon, and 156 backwards compatible with, IPv4. 158 Many engineering aspects common to both ILNPv4 and ILNPv6 are 159 described in [ILNP-ENG]. A full engineering specification for 160 either ILNPv6 or ILNPv4 is beyond the scope of this document. 162 Readers are referred to other related ILNP documents for details 163 not described here: 165 a) [ILNP-ARCH] is the main architectural description of ILNP, 166 including the concept of operations. 168 b) [ILNP-ENG] describes engineering and implementation 169 considerations that are common to both ILNPv4 and ILNPv6. 171 c) [ILNP-ICMPv6] defines a new ICMPv6 Locator Update message 172 used by an ILNP node to inform its correspondent nodes 173 of any changes to its set of valid Locators. 175 d) [ILNP-NONCEv6] defines a new IPv6 Nonce Destination Option 176 used by ILNPv6 nodes (1) to indicate to ILNP correspondent 177 nodes (by inclusion within the initial packets of an ILNP 178 session) that the node is operating in the ILNP mode and 179 (2) to prevent off-path attacks against ILNP ICMP messages. 180 This Nonce is used, for example, with all ILNP ICMPv6 181 Locator Update messages that are exchanged among ILNP 182 correspondent nodes. 184 e) [ILNP-ICMPv4] defines a new ICMPv4 Locator Update message 185 used by an ILNP node to inform its correspondent nodes 186 of any changes to its set of valid Locators. 188 f) [ILNP-v4OPTS] defines a new IPv4 Nonce Option used by ILNPv4 189 nodes to carry a security nonce to prevent off-path attacks 190 against ILNP ICMP messages and also defines a new IPv4 191 Identifier Option used by ILNPv4 nodes. 193 g) [ILNP-ARP] describes extensions to ARP for use with ILNPv4. 195 h) [ILNP-ADV] describes optional engineering and deployment 196 functions for ILNP. These are not required for the operation 197 or use of ILNP and are provided as additional options. 199 1.2 Terminology 201 In this document, the term "ILNP-aware" applied to a DNS 202 component (either authoritative server or cache) is used to 203 indicate that the component attempts to include other ILNP 204 RRTypes to the Additional section of a DNS response to 205 increase performance and reduce the number of follow-up 206 queries for other ILNP RRTypes. These other RRsets MAY be added 207 to the Additional section if space permits and only when the 208 QTYPE equals NID, L64, L32, or LP. There is no method for a 209 server to signal that it is ILNP-aware. 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 212 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 213 "OPTIONAL" in this document are to be interpreted as described 214 in RFC 2119 [RFC2119]. 216 2. NEW RESOURCE RECORDS 218 This document specifies several new and closely related DNS data 219 Resource Records (RRs). These new RR types have the mnemonics 220 "NID", "L32", "L64", and "LP". These resource record types are 221 associated with a Fully-Qualified Domain Name (FQDN), that is 222 hereafter called the "owner name". These are part of work on the 223 Identifier-Locator Network Protocol (ILNP) [ILNP-ARCH]. 225 For clarity, throughout this section of this document, the 226 "RDATA" subsections specify the on-the-wire format for these 227 records, while the "Presentation Format" subsections specify the 228 human-readable format used in a DNS configuration file 229 (i.e. "master file" as defined by RFC-1035, Section 5.1). 231 2.1 The NID Resource Record 233 The NID DNS Resource Record (RR) is used hold values for Node 234 Identifiers that will be used for ILNP-capable nodes. 236 NID records are present only for ILNP-capable nodes. This 237 restriction is important; ILNP-capable nodes use the presence of 238 NID records in the DNS to learn that a correspondent node is also 239 ILNP-capable. While erroneous NID records in the DNS for an node 240 that is not ILNP-capable would not prevent communication, such 241 erroneous DNS records could increase the delay at the start of an 242 IP session. 244 A given owner name may have zero or more NID records at a given 245 time. In normal operation, nodes that support the Identifier- 246 Locator Network Protocol (ILNP) will have at least one valid NID 247 record. 249 The type value for the NID RR type is X-NID-X . 251 The NID RR is class independent. 253 The NID RR has no special TTL requirements. 255 2.1.1 NID RDATA wire format 257 The RDATA for an NID RR consists of: 259 - a 16 bit Preference field 260 - a 64 bit NodeID field 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Preference | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 267 | NodeID | 268 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 2.1.1.1 The Preference field 274 The field contains a 16-bit unsigned integer in 275 network byte-order that indicates the owner name's relative 276 preference for this NID record among other NID records associated 277 with this owner name. Lower Preference values are preferred over 278 higher Preference values. 280 2.1.1.2 The NodeID field 282 The NodeID field is an unsigned 64-bit value in network 283 byte-order. It complies with the syntactic rules of IPv6 284 Interface Identifiers [RFC-4291, Section 2.5.1], but has slightly 285 different semantics. Unlike IPv6 Interface Identifiers, which are 286 bound to a specific *interface* of a specific node, NodeID values 287 are bound to a specific *node*, and MAY be used with *any 288 interface* of that node. 290 2.1.2 NID RR Presentation Format 292 The presentation of the format of the RDATA portion is as follows: 294 - The Preference field MUST be represented as a 16-bit unsigned 295 decimal integer. 297 - The NodeID field MUST be represented using the same syntax 298 (i.e. groups of 4 hexadecimal digits, with each group 299 separated by a colon) that is already used for DNS AAAA 300 records (and also used for IPv6 Interface IDs). 302 - The NodeID value MUST NOT be in the 'compressed' format 303 (e.g. using "::") that is defined in RFC-4291, Section 2.2 304 (2). This restriction exists to avoid confusion with 128-bit 305 IPv6 addresses, because the NID is a 64-bit field. 307 2.1.3 NID RR Examples 309 An NID record has the following logical components: 310 IN NID 312 In the above, is the owner name string, 313 is an unsigned 16-bit value, and is an unsigned 64-bit 314 value. 316 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 317 host1.example.com. IN NID 20 0015:5fff:ff21:ee65 318 host2.example.com. IN NID 10 0016:6fff:ff22:ee66 320 As NodeID values use the same syntax as IPv6 interface 321 identifiers, when displayed for human readership, the NodeID 322 values are presented in the same hexadecimal format as IPv6 323 interface identifiers. This is shown in the example above. 325 2.1.4 Additional Section Processing 327 To improve performance, ILNP-aware DNS servers and DNS resolvers 328 MAY attempt to return all L32, L64, and LP records for the same 329 owner name of the NID RRset in the Additional section of the 330 response, if space permits. 332 2.2 The L32 Resource Record 334 An L32 DNS Resource Record (RR) is used to hold 32-bit 335 Locator values for ILNPv4-capable nodes. 337 L32 records are present only for ILNPv4-capable nodes. This 338 restriction is important; ILNP-capable nodes use the presence of 339 L32 records in the DNS to learn that a correspondent node is also 340 ILNPv4-capable. While erroneous L32 records in the DNS for a 341 node that is not ILNP-capable would not prevent communication, 342 such erroneous DNS records could increase the delay at the start 343 of an IP session. 345 A given owner name might have zero or more L32 values at a given 346 time. An ILNPv4-capable host SHOULD have at least 1 Locator 347 (i.e., L32 or LP) DNS resource record while it is connected to 348 the Internet. An ILNPv4-capable multi-homed host normally 349 will have multiple Locator values while multi-homed. An IP 350 host that is NOT ILNPv4-capable MUST NOT have an L32 or LP record 351 in its DNS entries. A node that is not currently connected to 352 the Internet might not have any L32 values in the DNS associated 353 with its owner name. 355 A DNS owner name that is naming a subnetwork, rather than naming 356 a host, MAY have an L32 record as a wild-card entry, thereby 357 applying to entries under that DNS owner name. This deployment 358 scenario probably is most common if the named subnetwork is, was, 359 or might become, mobile. 361 The type value for the L32 RR type is X-L32-X . 363 The L32 RR is class independent. 365 The L32 RR has no special TTL requirements. 367 2.2.1 L32 RDATA Wire Format 369 The RDATA for an L32 RR consists of: 371 - a 16 bit Preference field 372 - a 32 bit Locator32 field 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Preference | Locator32 (16 MSBs) | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Locator32 (16 LSBs) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 2.2.1.1 The Preference field 384 The field is an unsigned 16-bit field in network 385 byte-order that indicates the owner name's relative preference 386 for this L32 record among other L32 records associated with this 387 owner name. Lower Preference values are preferred over higher 388 Preference values. 390 2.2.1.2 The Locator32 field 392 The field is an unsigned 32-bit integer in network 393 byte-order that is identical on-the-wire to the ADDRESS field 394 of the existing DNS A record. 396 2.2.2 L32 RR Presentation Format 398 The presentation of the format of the RDATA portion is as follows: 400 - The Preference field MUST be represented as a 16-bit unsigned 401 decimal integer. 403 - The Locator32 field MUST be represented using the same syntax 404 used for existing DNS A records (i.e. 4 decimal numbers 405 separated by periods without any embedded spaces). 407 2.2.3 L32 RR Examples 409 An L32 record has the following logical components: 410 IN L32 412 In the above is the owner name string, 413 is an unsigned 16-bit value, and is an unsigned 32-bit 414 value. 416 host1.example.com. IN L32 10 10.1.02.0 417 host1.example.com. IN L32 20 10.1.04.0 418 host2.example.com. IN L32 10 10.1.08.0 420 As L32 values have the same syntax and semantics as IPv4 routing 421 prefixes, when displayed for human readership, the values are 422 presented in the same dotted-decimal format as IPv4 addresses. 423 An example of this syntax is shown above. 425 In the example above, the owner name is from a FQDN for an 426 individual host. host1.example.com has two L32 values, so 427 host1.example.com is multi-homed. 429 Another example is when the owner name is that learned from an LP 430 record (see below for details of LP records). 432 l32-subnet1.example.com. IN L32 10 10.1.02.0 433 l32-subnet2.example.com. IN L32 20 10.1.04.0 434 l32-subnet3.example.com. IN L32 30 10.1.08.0 436 In this example above, the owner name is for a subnetwork rather 437 than an individual node. 439 2.2.4 Additional Section Processing 441 To improve performance, ILNP-aware DNS servers and DNS resolvers 442 MAY attempt to return all NID, L64, and LP records for the same 443 owner name of the L32 RRset in the Additional section of the 444 response, if space permits. 446 2.3 The L64 Resource Record 448 The L64 resource record (RR) is used to hold unsigned 64-bit 449 Locator Values for ILNPv6-capable nodes. 451 L64 records are present only for ILNPv6-capable nodes. This 452 restriction is important; ILNP-capable nodes use the presence of 453 L64 records in the DNS to learn that a correspondent node is also 454 ILNPv6-capable. While erroneous L64 records in the DNS for a 455 node that is not ILNP-capable would not prevent communication, 456 such erroneous DNS records could increase the delay at the start 457 of an IP session. 459 A given owner name might have zero or more L64 values at a given 460 time. An ILNPv6-capable host SHOULD have at least 1 Locator 461 (i.e., L64 or LP) DNS resource record while it is connected to 462 the Internet. An ILNPv6-capable multi-homed host normally 463 will have multiple Locator values while multi-homed. An IP 464 host that is NOT ILNPv6-capable MUST NOT have an L64 or LP record 465 in its DNS entries. A node that is not currently connected to 466 the Internet might not have any L64 values in the DNS associated 467 with its owner name. 469 A DNS owner name that is naming a subnetwork, rather than naming 470 a host, MAY have an L64 record as a wild-card entry, thereby 471 applying to entries under that DNS owner name. This deployment 472 scenario probably is most common if the named subnetwork is, was, 473 or might become, mobile. 475 The type value for the L64 RR type is X-L64-X . 477 The L64 RR is class independent. 479 The L64 RR has no special TTL requirements. 481 2.3.1 The L64 RDATA Wire Format 483 The RDATA for an L64 RR consists of: 485 - a 16 bit Preference field 486 - a 64 bit Locator64 field 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Preference | | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 493 | Locator64 | 494 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 2.3.1.1 The Preference field 500 The field is an unsigned 16-bit integer in network 501 byte-order that indicates the owner name's relative preference 502 for this L64 record among other L64 records associated with this 503 owner name. Lower Preference values are preferred over higher 504 Preference values. 506 2.3.1.2 The Locator64 field 508 The field is an unsigned 64-bit integer in network 509 byte-order that has the same syntax and semantics as a 64-bit 510 IPv6 routing prefix. 512 2.3.2 L64 RR Presentation Format 514 The presentation of the format of the RDATA portion is as follows: 516 - The Preference field MUST be represented as a 16-bit unsigned 517 decimal integer. 519 - The Locator64 field MUST be represented using the same syntax 520 used for AAAA records (i.e. groups of 4 hexadecimal digits 521 separated by colons). However, the 'compressed' display 522 format (e.g. using "::") that is specified in RFC-4291, 523 Section 2.2 (2), MUST NOT be used. This is done to avoid 524 confusion with a 128-bit IPv6 address, since the Locator64 is 525 a 64-bit value, while the IPv6 address is a 128-bit value. 527 2.3.3 L64 RR Examples 529 An L64 record has the following logical components: 530 IN L64 532 In the above, is the owner name string, 533 is an unsigned 16-bit value, while is an unsigned 534 64-bit value. 536 host1.example.com. IN L64 10 2001:0DB8:1140:1000 537 host1.example.com. IN L64 20 2001:0DB8:2140:2000 538 host2.example.com. IN L64 10 2001:0DB8:4140:4000 540 As L64 values have the same syntax and semantics as IPv6 routing 541 prefixes, when displayed for human readership, the values might 542 conveniently be presented in hexadecimal format, as above. 544 In the example above, the owner name is from a FQDN for an 545 individual host. host1.example.com has two L64 values, so it will 546 be multi-homed. 548 Another example is when the owner name is that learned from an LP 549 record (see below for details of LP records). 551 l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000 552 l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000 553 l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000 555 Here, the owner name is for a subnetwork rather than an individual 556 node. 558 2.3.4 Additional Section Processing 560 To improve performance, ILNP-aware DNS servers and DNS resolvers 561 MAY attempt to return all NID, L32, and LP records for the same 562 owner name of the L64 RRset in the Additional section of the 563 response, if space permits. 565 2.4 The LP Resource Record 567 The LP DNS resource record (RR) is used to hold the name of a 568 subnetwork for ILNP. The name is an FQDN which can then be used 569 to look up L32 or L64 records. LP is, effectively, a Locator 570 Pointer to L32 and/or L64 records. 572 As described in [ILNP-ARCH], the LP RR provides one level of 573 indirection within the DNS in naming a Locator value. This is 574 useful in several deployment scenarios, such as for a multi-homed 575 site where the multi-homing is handled entirely by the site's 576 border routers (e.g. via Locator rewriting) or in some mobile 577 network deployment scenarios [ILNP-ADV]. 579 LP records MUST NOT be present for owner name values that are not 580 ILNP-capable nodes. This restriction is important; ILNP-capable 581 nodes use the presence of LP records in the DNS to infer that 582 a correspondent node is also ILNP-capable. While erroneous LP 583 records in the DNS for an owner name would not prevent 584 communication, presence of such erroneous DNS records could 585 increase the delay at the start of a IP session. 587 The type value for the LP RR type is X-LP-X . 589 The LP RR is class independent. 591 The LP RR has no special TTL requirements. 593 2.4.1 LP RDATA Wire Format 595 The RDATA for an LPP RR consists of: 597 - an unsigned 16 bit Preference field 598 - a variable-length FQDN field 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Preference | / 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / 605 / / 606 / FQDN / 607 / / 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 2.4.1.1 The Preference field 612 The field contains an unsigned 16-bit integer in 613 network-byte order that indicates the owner name's relative 614 preference for this LP record among other LP records associated 615 with this owner name. Lower Preference values are preferred over 616 higher Preference values. 618 2.4.1.2 The FQDN field 620 The variable-length FQDN field contains the DNS target name that 621 is used to reference L32 and/or L64 records. This field MUST NOT 622 have the same value as the owner name of the LP RR instance. 624 2.4.2 LP RR Presentation Format 626 The presentation of the format of the RDATA portion is as follows: 628 - The Preference field MUST be represented as a 16-bit unsigned 629 decimal integer. 631 - The FQDN field MUST be represented as a domain name. 632 The domain name MUST NOT be compressed. 634 2.4.3 LP RR Examples 636 An LP record has the following logical components: 637 IN LP 639 In the above, is the owner name string, 640 is an unsigned 16-bit value, while is the domain name 641 which should be resolved further. 643 host1.example.com. IN LP 10 l64-subnet1.example.com. 644 host1.example.com. IN LP 10 l64-subnet2.example.com. 645 host1.example.com. IN LP 20 l32-subnet1.example.com. 647 In the example above, host1.example.com is multi-homed on three 648 subnets. Resolving the FQDNs return in the LP records would 649 allow the actual subnet prefixes to be resolved, e.g. as in the 650 examples for the L32 and L64 RR descriptions, above. This level 651 of indirection allows the same L32 and/or L64 records to be used 652 by many hosts in the same subnetwork, easing management of the 653 ILNP network and potentially reducing the number of DNS Update 654 transactions, especially when that network is mobile [RAB09] or 655 multi-homed [ABH09a]. 657 2.4.4 Additional Section Processing 659 To improve performance, ILNP-aware DNS servers and DNS resolvers 660 MAY attempt to return all L32 and L64 records for the same owner 661 name of the LP RRset in the Additional section of the response, 662 if space permits. 664 3. DEPLOYMENT EXAMPLE 666 Given a domain name, one can use the Domain Name System (DNS) to 667 discover the set of NID records, the set of L32 records, the set 668 of L64 records, and the set of LP records that are associated 669 with that DNS owner name. 671 For example: 673 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 674 host1.example.com. IN L64 10 2001:0DB8:1140:1000 676 would be the minimum requirement for an ILNPv6 node that has 677 owner name host1.example.com and is connected to the Internet at 678 the subnetwork having routing prefix 2001:0DB8:1140:1000. 680 If that host were multi-homed on two different IPv6 subnets: 682 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 683 host1.example.com. IN L64 10 2001:0DB8:1140:1000 684 host1.example.com. IN L64 20 2001:0DB8:2140:2000 686 would indicate the Identifier and two subnets that 687 host1.example.com is attached to, along with the relative 688 preference that a client would use in selecting the 689 Locator value for use in initiating communication. 691 If host1.example.com were part of a mobile network, 692 a DNS query might return: 694 host1.example.com. IN NID 10 0014:4fff:ff20:ee64 695 host1.example.com. IN LP 10 mobile-net1.example.com. 697 and then a DNS query to find the current Locator value(s) 698 for the node named by the LP record: 700 mobile-net1.example.com. IN L64 2001:0DB8:8140:8000 702 3.1 Use of ILNP records 704 As these DNS records are only used with the Identifier-Locator 705 Network Protocol (ILNP), these records MUST NOT be present for a 706 node that does not support ILNP. This lookup process is 707 considered to be in the "forward" direction. 709 The Preference fields associated with the NID, L32, L64, and LP 710 records are used to indicate the owner name's preference for 711 others to use one particular NID, L32, L64, or LP record, rather 712 than use another NID, L32, L64, or LP record also associated with 713 that owner name. Lower Preference field values are preferred 714 over higher Preference field values. 716 It is possible that a DNS stub resolver querying for one of these 717 record types will not receive all NID, L32, L64, and LP RR's in a 718 single response. Credible anecdotal reports indicate at least 719 one DNS recursive cache implementation actively drops all 720 Additional Data records that were not expected by that DNS 721 recursive cache. So even if the authoritative DNS server includes 722 all the relevant records in the Additional Data section of the 723 DNS response, the querying DNS stub resolver might not receive 724 all of those Additional Data records. DNS resolvers also might 725 purge some ILNP RRsets before others, for example if NID RRsets 726 have a longer DNS TTL value than Locator-related (e.g. LP, L32, 727 L64) RRsets. So a DNS stub resolver sending queries to a DNS 728 resolver cannot be certain if they have obtained all available 729 RRtypes for a given owner name. Therefore, the DNS stub resolver 730 SHOULD send follow-up DNS queries for RRTYPE values that were 731 missing and are desired, to ensure that the DNS stub resolver 732 receives all the necessary information. 734 Note nodes likely either to be mobile or to be multi-homed 735 normally will have very low DNS TTL values for L32 and L64 736 records, as those values might change frequently. However, the 737 DNS TTL values for NID and LP records normally will be higher, 738 as those values are not normally impacted by node location 739 changes. Previous trace-driven DNS simulations from MIT [JSBM02] 740 and more recent experimental validation of operational DNS from 741 U. of St Andrews [BA11] both indicate deployment and use of very 742 short DNS TTL values within 'stub' or 'leaf' DNS domains is not 743 problematic. 745 An ILNP node MAY use any NID value associated with its DNS owner 746 name with any or all Locator (L32 or L64) values also associated 747 with its DNS owner name. 749 3.2 Additional Section Processing 751 For all the records above, Additional Section Processing MAY be 752 used. This is intended to improve performance for both the DNS 753 client and the DNS server. For example, a node sending DNS query 754 for an NID owner name, such as host1.example.com, would benefit 755 from receiving all ILNP DNS records related to that owner name 756 being returned, as it is quite likely that the client will need 757 that information to initiate an ILNP session. 759 However, this is not always the case: a DNS query for L64 for a 760 particular owner name might be made because the DNS TTL for a 761 previously resolved L64 RR has expired, while the NID RR for that 762 same owner name has a DNS TTL that has not expired. 764 4. SECURITY CONSIDERATIONS 766 These new DNS resource record types do not create any new 767 vulnerabilities in the Domain Name System. 769 Existing mechanisms for DNS Security can be used unchanged with 770 these record types [RFC4033] [RFC3007]. As of this writing, the 771 DNS Security mechanisms are believed to be widely implemented 772 in currently available DNS servers and DNS clients. Deployment 773 of DNS Security appears to be growing rapidly. 775 In situations where authentication of DNS data is a concern, 776 the DNS Security extensions SHOULD be used [RFC4033]. 778 If these DNS records are updated dynamically over the network, 779 then the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be 780 used to secure such transactions. 782 5. IANA CONSIDERATIONS 784 IANA is requested to allocate each of these DNS Resource Records 786 NID 787 L32 788 L64 789 LP 791 (described above in Section 2) a Data RRTYPE value according to 792 the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of 793 RFC 6195 [RFC6195]. 795 6. REFERENCES 797 6.1 Normative References 799 [RFC1034] P. Mockapetris, "Domain names - Concepts and 800 Facilities", RFC-1034, 1 November 1987 802 [RFC1035] P. Mockapetris, "Domain names - Implementation and 803 Specification", RFC-1035, 1 November 1987. 805 [RFC2119] Bradner, S., "Key words for use in RFCs to 806 Indicate Requirement Levels", BCP 14, RFC 2119, 807 March 1997. 809 [RFC3007] B. Wellington, "Secure Domain Name System Dynamic 810 Update", RFC 3007, RFC Editor, November 2000. 812 [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource 813 Record (RR) Types", RFC 3597, September 2003. 815 [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, & 816 S. Rose, "DNS Security Introduction & Requirements", 817 RFC 4033, RFC Editor, March 2005. 819 [RFC6195] D. Eastlake 3rd, "Domain Name System IANA 820 Considerations", RFC 6195, March 2011. 822 [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, 823 "ILNP Architectural Description", 824 draft-irtf-rrg-ilnp-arch, 10 July 2012. 826 [ILNP-ENG] R.J. Atkinson & S.N. Bhatti, 827 "ILNP Engineering and Implementation Considerations", 828 draft-irtf-rrg-ilnp-eng, 10 July 2012. 830 6.2 INFORMATIVE REFERENCES 832 [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, 833 "Site-Controlled Secure Multi-Homing and Traffic 834 Engineering For IP", Procedings of IEEE Military 835 Communications Conference, IEEE, Boston, MA, USA. 836 Oct 2009. 838 [BA11] S. Bhatti & R. Atkinson, "Reducing DNS Caching", 839 Procedings of IEEE Global Internet Symposium (GI2011), 840 Shanghai, P.R. China. 15 Apr 2011. 841 843 [JSBM02] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, 844 DNS performance and the effectiveness of caching. 845 IEEE/ACM Trans. Netw. 10(5) (October 2002), 589-603. 846 848 [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, 849 "Mobile Host Location Tracking through DNS", 850 IEEE London Communications Symposium, London, 851 England, UK, September 2002. 853 855 [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, 856 "Enabling Mobile Networks Through Secure Naming", 857 Proceedings of IEEE Military Communications 858 Conference (MILCOM), IEEE, Boston, MA, USA, 859 Oct 2009. 861 [SB00] Alex C. Snoeren and Hari Balakrishnan. 2000. 862 "An End-To-End Approach To Host Mobility", 863 Proceedings of 6th Conference on Mobile Computing And 864 Networking (MobiCom), ACM, Boston, MA, USA, 865 August 2000. 867 [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans 868 Kaashoek, "Reconsidering Internet Mobility", 869 Proceedings of 8th Workshop on Hot Topics in 870 Operating Systems (HotOS), IEEE Computer Society, 871 Elmau, Germany, May 2001. 873 [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, 874 "Optional Advanced Deployment Scenarios for ILNP", 875 draft-irtf-rrg-ilnp-adv, 10 July 2012. 877 [ILNP-ARP] R.J. Atkinson & S.N. Bhatti, "ARP Extension for 878 ILNPv4", draft-irtf-rrg-ilnp-arp, 10 July 2012. 880 [ILNP-ICMPv4] R.J. Atkinson & S.N. Bhatti, "ICMPv4 Locator 881 Update message", draft-irtf-rrg-ilnp-icmpv4, 882 10 July 2012. 884 [ILNP-ICMPv6] R.J. Atkinson & S.N. Bhatti, "ICMPv6 Locator 885 Update message", draft-irtf-rrg-ilnp-icmpv6, 886 10 July 2012. 888 [ILNP-NONCEv6] R.J. Atkinson & S.N. Bhatti, "IPv6 Nonce 889 Destination Option for ILNPv6", 890 draft-irtf-rrg-ilnp-noncev6, 10 July 2012. 892 [ILNP-v4OPTS] R.J. Atkinson & S.N. Bhatti, "IPv4 Options for 893 ILNP", draft-irtf-rrg-ilnp-v4opts, 10 July 2012. 895 ACKNOWLEDGEMENTS 897 Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel 898 Chiappa, Wes George, Steve Hailes, Joel Halpern, Mark Handley, 899 Volker Hilt, Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, 900 Bruce Simpson, Robin Whittle and John Wroclawski (in alphabetical 901 order) provided review and feedback on earlier versions of this 902 document. Steve Blake provided an especially thorough review of 903 an early version of the entire ILNP document set, which was 904 extremely helpful. We also wish to thank the anonymous reviewers 905 of the various ILNP papers for their feedback. 907 Roy Arends provided expert guidance on technical and procedural 908 aspects of DNS issues, for which the authors are greatly obliged. 910 RFC EDITOR NOTE 912 This section is to be removed prior to publication. 914 Please note that this document is written in British English, so 915 British English spelling is used throughout. This is consistent 916 with existing practice in several other RFCs, for example 917 RFC-5887. 919 This document tries to be very careful with history, in the 920 interest of correctly crediting ideas to their earliest 921 identifiable author(s). So in several places the first published 922 RFC about a topic is cited rather than the most recent published 923 RFC about that topic. 925 Authors' Addresses: 927 RJ Atkinson 928 Consultant 929 San Jose, CA 930 95125 USA 932 Email: rja.lists@gmail.com 934 SN Bhatti 935 School of Computer Science 936 University of St Andrews 937 North Haugh, St Andrews 938 Fife, Scotland, UK 939 KY16 9SX 941 Email: saleem@cs.st-andrews.ac.uk 943 Scott Rose 944 US National Institute for Standards & Technology 945 100 Bureau Drive 946 Gaithersburg, MD 947 20899 USA 949 Email: scottr.nist@gmail.com 951 [NOTE: Appendix A is to be removed by the 952 RFC Editor prior to publication.] 954 Appendix A: 956 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 958 When ready for formal consideration, this template is 959 to be submitted to IANA for processing by emailing the 960 template to dns-rrtype-applications@ietf.org. 962 A. Submission Date: To be determined. 964 B. Submission Type: 965 [X] New RRTYPE 967 C. Contact Information for submitter: 968 Name: R. Atkinson 969 Email Address: rja.lists@gmail.com 970 International telephone number: unlisted 971 Other contact handles: 973 D. Motivation for the new RRTYPE application? 975 Support for an experimental set of IP extensions 976 that replace the concept of an "IP Address" with 977 distinct "Locator" and "Identifier" values. 979 E. Description of the proposed RR type. 981 Please see: 983 http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-03.txt 985 for a full description. 987 F. What existing RRTYPE or RRTYPEs come closest to filling 988 that need and why are they unsatisfactory? 990 There is no RRTYPE that fulfils the need due to the 991 new semantics of Locator and Identifier values. 993 The AAAA record combines both Locator and Identifier, 994 so has significantly different semantics than having 995 separate L64 and NID record values. The AAAA record also 996 lacks scalability and flexibility in the context of the 997 experimental protocol extensions that will use the NID 998 and L64 records, as any valid NID record value for a node 999 can be used on the wire with any valid L64 record value 1000 for the same node. 1002 The CNAME record is closest conceptually to an LP 1003 record, but a CNAME is a node name referral scheme, 1004 while the LP record is indicating that the given node 1005 has the same routing prefix as some other domain name, 1006 but does not necessarily have any other values that are 1007 the same. 1009 Lastly, the AAAA and CNAME RR Types lack a Preference 1010 field to rank responses. Such Preference information 1011 is required for ILNP in order to support the use of multiple 1012 instances of NID, L32, L64 and LP records. 1014 G. What mnemonic is requested for the new RRTYPE (optional)? 1016 As described in this draft, "NID", "L32", "L64", and "LP". 1018 H. Does the requested RRTYPE make use of any existing IANA 1019 Registry or require the creation of a new IANA 1020 sub-registry in DNS Parameters? 1022 Existing registry of DNS Resource Record (RR) data TYPE 1023 values should be used. 1025 I. Does the proposal require/expect any changes in DNS 1026 servers/resolvers that prevent the new type from being 1027 processed as an unknown RRTYPE (see [RFC3597]) ? 1029 No. 1031 J. Comments: 1032 This document defines "ILNP-aware" DNS servers 1033 or DNS resolver as a DNS server (authoritative or recursive) 1034 that MAY include other ILNP RRTypes in the Additional 1035 section of a DNS response that match a QNAME (if 1036 size permits). This is to reduce the number of 1037 DNS stub resolver follow-up DNS queries. and only applies 1038 when the QTYPE is either NID, L32, L64, or LP. There is no 1039 signalling mechanism for this Additional section 1040 processing, and this is believed to be compatible 1041 with existing non-ILNP-aware DNS servers and DNS stub 1042 resolvers. 1044 No changes are required for existing deployed 1045 DNS servers or DNS resolvers. 1047 Expires: 10 JAN 2013