idnits 2.17.1 draft-anderson-reverse-dns-status-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 24, 2007) is 6210 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-1035' is mentioned on line 411, but not defined ** Obsolete normative reference: RFC 883 (Obsoleted by RFC 1034, RFC 1035) ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1788 (Obsoleted by RFC 6918) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Downref: Normative reference to an Informational RFC: RFC 3833 ** Downref: Normative reference to an Experimental RFC: RFC 4620 -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Anderson 3 Internet-Draft AV8 4 Intended status: Best Current April 24, 2007 5 Practice 6 Expires: October 26, 2007 8 Reverse DNS Status Report 9 draft-anderson-reverse-dns-status-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 26, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Translation of IP addresses to domain names is an optional feature of 43 DNS. Many sites implement it in someway, many others do not 44 implement it at all. Over time, some myths have developed regarding 45 reverse DNS mapping. The goal of this document is to to identify 46 best practices, illuminate false assumptions and to report on the 47 status of reverse DNS facilities so that DNS Administrators and 48 operators can make informed decisions about the options for DNS 49 reverse mapping. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Analysis of Issues . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Registry Issues . . . . . . . . . . . . . . . . . . . . . 6 61 3.2. Reverse Mapping Alternatives . . . . . . . . . . . . . . . 7 62 3.3. Use of Reverse Mapping for Security and Abuse Detection . 8 63 3.4. Logging Issues . . . . . . . . . . . . . . . . . . . . . . 9 64 3.5. Domain Population Issues . . . . . . . . . . . . . . . . . 10 65 3.6. Delegation Issues . . . . . . . . . . . . . . . . . . . . 11 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 5. Normative References . . . . . . . . . . . . . . . . . . . . . 13 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . . . 15 71 1. Introduction 73 1.1. Overview 75 The Domain Name System has a facility for providing mapping of IP 76 addresses to host names. A number of different practices have 77 evolved for using reverse DNS mapping. This facility has long been 78 documented, but without detailed canons for those who wish to utilize 79 such mappings. DNS Administrators are free to use or not use the PTR 80 facility in any way that is useful to their site. This document does 81 not seek to define or endorse a canonical reverse mapping scheme, but 82 rather to identify facts, illuminate myths, recommend best practices, 83 and to report on the status of reverse mapping facilities. 85 1.2. Terminology 87 In the following, the general term "reverse mapping" is used to refer 88 to the capability of mapping IP addresses to host names, and "reverse 89 tree" the portions of the DNS that provide the functionality. The 90 term "IN-ADDR" is used to specifically refer to the feature only as 91 it applies to IPv4 use. The domain IN-ADDR.ARPA is used to 92 denominate the portion of the DNS that provides such IPv4-specific 93 functionality. "IP6" refers to the feature only as it applies to 94 IPv6 use. The domain "IP6.ARPA" denominates the portion of the DNS 95 that provides the IPv6-specific functionality. In what follows, 96 except where the text explicitly refers specifically to IPv4 or IPv6 97 features, the document can and should be applied to both address 98 spaces. 100 1.3. Key Words 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 1.4. Motivation 108 In recent years, some sites have increased utilization of reverse 109 mapping even as other sites have stopped maintaining reverse mappings 110 for their addresses. This has created friction and controversy about 111 the use of reverse mapping. Several factors drive these diverging 112 behaviors. 114 The widespread practice of "virtual hosting" -- using one machine and 115 IP address to host many different domains -- increases the number of 116 machines that have multiple IP addresses and/or multiple domain 117 names. Some sites only enter reverse mappings for certain kinds of 118 systems such as routers. Some sites generate reverse mapping entries 119 automatically using a script or program. There are a variety of 120 schemes for reverse mapping. Since forward names and reverse 121 mappings are frequently administered by different agencies or 122 organizations, consistency is difficult to maintain and the structure 123 is not amenable to cooperative secure update. The large IPv6 address 124 space exacerbates the difficulty of administering reverse mapping. 125 For example, the reverse lookup domain name corresponding to the 126 address 128 4321:0:1:2:3:4:567:89ab 130 would be 132 b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. 133 ARPA. 135 As this example from [RFC3596] makes clear, the IPv6 reverse DNS tree 136 is much more tedious to administer and expensive to maintain than the 137 IPv4 tree. The greatly increased depth is expected to make queries 138 slower, and more burdensome on servers. 140 Many DNS Administrators regard the data in the reverse tree as an 141 unnecessary expense and a potential information leak, and so object 142 to populating reverse mappings. 144 DNS Administrators have also attempted to use reverse mappings as a 145 part of a security-prevention or abuse-prevention policy. 146 Administrators have asserted that a certain style of reverse mapping 147 must be maintained. Facts have been obscured by advocacy and false 148 assumptions. Consequently, myths have developed regarding the notion 149 of proper use of reverse DNS records, and what reverse mapping 150 information reasonably means outside of the organization providing 151 the data. 153 Information about the status of reverse mapping facilities seems to 154 be fragmented, missing, or not well understood in the operations 155 community. Many people may be unaware of the status of reverse 156 mapping facilities and options available for consideration. 158 In light of the above issues, a discussion of facts, false 159 assumptions, and current status of reverse mapping facilities will be 160 helpful so that DNS users, system administrators, and stakeholders 161 can make informed and rational decisions. 163 2. Background 165 In the early days of the Domain Name System [RFC0883] a special 166 domain was set aside for finding gateways and mapping IP addresses to 167 domain names. From the very beginning, cautions were stated: 169 "Since the IN-ADDR special domain and the normal domain for a 170 particular host or gateway will be in different zones, the 171 possibility exists that that the data may be inconsistent. 173 "Gateways will often have two names in separate domains, only one of 174 which can be primary." 176 These cautions were repeated in [RFC1035]. The guidelines on the use 177 of the special domain IN-ADDR.ARPA are discussed in [RFC1034]. The 178 introduction of Classless Interdomain Routing (CIDR) by [RFC1519] in 179 1993 effectively obsoleted the use of IN-ADDR.ARPA to find gateways. 180 CIDR also made delegation of reverse mapping zones more difficult. 181 Very early in the development, problems were noted with the IN- 182 ADDR.ARPA special domain method of reverse mapping. Alternatives 183 began to be explored in [RFC1788] in 1995. In 1998, a scheme for 184 classless delegation of IN-ADDR.ARPA was invented in [RFC2317]. For 185 the IPv6 address space, IP6.ARPA was added and is described by 186 [RFC3596]. Experimentation is proceeding in IPv6 on the Node 187 Information (NI) ICMP query specified in [RFC4620]. It should be 188 noted that serious discussions were held about obsoleting the special 189 domain method of reverse mapping in IPv6, however, the IP6.ARPA 190 special domain has been kept, at least for now. 192 An exploration of the role of the U.S. Department of Commerce in the 193 privatization of the management of the Internet and the role of ICANN 194 in managing the Domain Name System is helpful, if not critical to 195 understanding the status of the reverse mapping system. This 196 document will not explore these roles in detail, but will make 197 references as necessary. 199 Finally, the DNSSEC system has also changed the landscape regarding 200 the authenticity of DNS queries. However, DNSSEC is not yet widely 201 deployed, and this document will only make reference to the 202 improvements in authenticity. 204 3. Analysis of Issues 206 3.1. Registry Issues 208 The mission of a Regional Internet Registry (RIR) is, generally, to 209 manage the assignment and registration of IP Address resources, and 210 to keep the records and documents which are necessary to perform that 211 function. A function assigned to the RIRs includes joint operation 212 of the special reverse mapping domains. 214 As the Internet was privatized, the assignment of blocks of IP 215 Address space was delegated to (originally three) Regional Internet 216 Registries. The guidelines in [RFC2050] state that registries must 217 maintain reverse mapping parent records for the blocks assigned to 218 ISPs and for CIDR blocks smaller than /16, and for blocks that are 219 not assigned to specific organizations. Each RIR has its own policy 220 for reverse-mapping maintenance; these policies may change from time 221 to time, but typically follow RFC2050. 223 Myth: "Registries require IP users to populate reverse mapping." 225 Explanation: Some persons, in order to promote population of reverse 226 mapping, have asserted that the Regional Registries require 227 population of reverse mapping entries. This myth is a play on words 228 in RFC2050 and on the Registry policies that restate the RFC2050 229 guideline. Registries require only that certain specified users 230 perform their own reverse mapping. But the registries don't require 231 that users must populate reverse mapping entries, only that the 232 Registry will not perform delegations for them. 234 Fact: Registries generally encourage, but do not require, customers 235 to use reverse mapping. 237 Fact: Registries may remove reverse mapping delegations on their own 238 initiative if the delegated nameservers are lame. 240 The U.S. Department of Commerce MOU with ICANN [1] and amendments do 241 not explicitly require ICANN to perform reverse mapping service, nor 242 does the MOU explicitly require any delegated Regional Internet 243 Registries to perform reverse mapping service. The MOU and 244 amendments don't mention reverse mapping at all. One or more 245 registries have previously expressed interest in removing support for 246 reverse mappings records. The operations of the IN-ADDR.ARPA and 247 IP6.ARPA special domains impose a growing technical, engineering- 248 oriented, network-operational burden on what are otherwise entirely 249 documentary, legal-oriented organizations. 251 The technical problems faced by Regional Registries have been known 252 for some time as [RFC1788] states in its introduction in 1995: 254 "As application servers have appeared which require the Domain Name 255 for user interaction and security logging, the IN-ADDR servers have 256 been inundated with queries. This produces long user visible pauses 257 at the initiation of sessions." 259 This load presents a performance problem for the Regional Registries 260 that continues to grow in proportion to the size of the Internet. 261 Delegated special domain servers also have a burden that depends on 262 the number of users and presents a performance bottleneck. 264 3.2. Reverse Mapping Alternatives 266 Experimentation with alternatives for IPv4 began in 1995 with 267 [RFC1788]. This RFC documents ICMP types 37 and 38, Domain Name 268 Query and Domain Name Reply, respectively. IPv6 experimentation 269 continues with [RFC4620], which defines similar functions for Node 270 Information queries using ICMPv6 types 139 and 140 for NI Query and 271 NI Reply, respectively. 273 These reverse mapping alternatives are attractive because they neatly 274 solve the problem that many people use reverse mapping to perform: 275 They identify the host computer using the IP address. These 276 alternatives are more scalable because each host handles its own 277 responses to reverse mapping, rather than a few servers that must 278 handle all the reverse mapping queries for a particular IP address 279 block. Putting this information on the host solves long-cited 280 administration and consistency problems, present since RFC0883 first 281 noted them. 283 It is often a mistaken assumption that a host has one and only one IP 284 address. A single host computer may have many IP addresses, and 285 there may even be complicated internal topology to those IP 286 Addresses. IP hosts are perfectly capable of a complicated internal 287 topology similar to Netware or similar to internal network paths of 288 NSC Hyperchannel routers. 290 For example, one may have a single loopback address that is canonical 291 for a host, with each network interface having a unique address. 292 This structure, pioneered by Netware, enables Applications to connect 293 to a single address, via routing information distributed by the 294 physical network interfaces. Virtual hosting systems may also have 295 many IP addresses on internal loopback interfaces so that each 296 virtual host site has only a single address, but the physical host 297 can be multihomed. 299 For another example, a scheme preferred for BGP setups, gives a 300 router a loopback address for BGP peers. A variant gives each BGP 301 peer a unique address. This structure improves management of BGP 302 peers and also makes it harder for attackers to guess the BGP IP 303 address because a traceroute would only identify the physical 304 interfaces. The accumulation of many IP Addresses on a single host 305 or router means that identification via special reverse mapping 306 mapping is difficult at best. As noted since RFC0883, a router may 307 have IP addresses from different organizations and zones. A better 308 solution is to have a means of querying the node for its name. 310 There is also an architectural attraction to having this 311 identification performed at the same level as other host control 312 messages such as PING. The questions "Are you up?" and "What is your 313 name?" are naturually on the same level. 315 Recommendation: Become familiar with the alternatives in RFC1788 and 316 RFC4620. 318 3.3. Use of Reverse Mapping for Security and Abuse Detection 320 Threats against DNS have been documented in [RFC3833]. The threats 321 described are sobering, and reveal that DNS is not suitable for trust 322 purposes. 324 Myth: Hosts with matching forward and reverse mappings are more 325 trustworthy. 327 Explanation: This idea has been promoted by certain anti-spam 328 elements for many years. 330 Fact: There is no justification for this conclusion. When pressed 331 for a reason, advocates say that one is entitled to make decisions 332 without justification because they have "incomplete information". 333 There is nothing about imcomplete information that justifies 334 irrational or capricous decision making. Every scientific experiment 335 and every court case involves conclusions and decisions based on 336 incomplete information. There are legitimate methods of making 337 decisions with incomplete information. No scientific or judicial 338 method involves an entitlement to act irrationally or capriciously. 339 Legitimate methods do not depend on false assumptions, particularly 340 those with security and trust implications. We note the following 341 facts: 343 The lack of reverse mapping has no security implications at all. 344 Not having reverse mapping does not imply one is untrustworthy. 346 A non-matching reverse mapping carries no security or spam 347 implications. There is no requirement that forward and reverse 348 mappings must match in order to be useful to the site creating the 349 mappings. 351 A matching forward/reverse entry may be forged by a number of 352 methods. 354 The user of an IP Address often has no connection to the reverse 355 mapping entry for the IP Address other than being a customer of an 356 ISP. The fact of being a customer does not make the user 357 trustworthy nor untruthworthy. There is no relationship between 358 whether the user is trustworthy, and whether the IP Address has 359 reverse mapping. 361 In the case that the IP user also has been delegated control of 362 the reverse mapping, the user only has to forge the forward 363 lookup, because they control the reverse lookup. 365 There have been instances, sometimes well publicized, where trust 366 decisions have been based on reverse mapping. For example, ISPs have 367 blocked email based on lack of reverse mapping; Banks have blocked 368 customer access; etc. Advocates of a certain type of population 369 scheme when persuding others to use reverse mapping as a trust 370 mechanism often cite such cases in order to bolster the notion that 371 other people utilize reverse mappings for trust and security 372 purposes. What is omitted from their descriptions is the fact that 373 such examples were often short-lived and ended ignomiously, and 374 frequently caused disruption and embarrassment to the organizations 375 that implemented them. 377 There have also been more serious threats involved in the 378 inappropriate use of DNS for trust decisions. The Unix rsh and rexec 379 commands look for names in a .rhosts file. If the DNS mapping is 380 forged, the programs will allow access. These programs have long 381 since been deprecated in favor of programs that use cryptographic 382 authentication. 384 Best Practice: Do not use DNS for trust or security decisions. 386 3.4. Logging Issues 388 Logging requires special attention. Logging systems exist that only 389 log reverse mapping entry to identify the remote connection. Because 390 an attacker may have control over their reverse mapping entry and 391 their forward mapping entry, These DNS entries cannot be trusted to 392 identify an attacker. An IP Address should always be logged and used 393 as the primary means of identification. The reverse mapping and the 394 forward mapping may be of interest, but one should be prepared for 395 the case where these will be entirely useless. Another consideration 396 is that the reverse mapping entry may be up to 255 bytes long. Care 397 should be taken that a DOS attack cannot be executed on the logging 398 system by use of long domain names. 400 Fact: Packets are exchanged depending on the source and destination 401 IP Addresses. 403 Best Practice: Logging systems should have the configurable 404 capability to omit reverse mapping entries from the logs. 406 3.5. Domain Population Issues 408 The success of the IN-ADDR domain in its intended role has long been 409 questioned. As [RFC1788] notes: 411 "The IN-ADDR domain of the DNS is specified [RFC-1035] to perform 412 address to domain name resolution, and to facilitate queries to 413 locate all gateways (routers) on a particular network in the 414 Internet. 416 "Neither function has been remarkably successful. The IN-ADDR domain 417 is not reliably populated." 419 Not much has changed since this was written in 1995. The IN-ADDR 420 domain is still not used by many sites. There are a variety of 421 reasons cited as to why this is, and still more varieties of proposed 422 solutions to this problem. There are yet more myths about what could 423 be done if the entire planet were to populate the reverse mapping 424 trees. Most such claims involve security or trust decisions that 425 would be unjustified and untrustworthy even if the entire planet 426 fully populated the reverse mapping in just the way demanded. 428 However, It is apparent that many trivial mappings are possible: For 429 example, one might translate any IP address into a name generated 430 from the IP address itself. For example, 192.0.2.1 might become x1- 431 2-0-192.example.com where example.com is the domain of the ISP to 432 which the IP Address was originally delegated. 434 This yields no information that wasn't already available to the 435 remote site that issued the reverse mapping query. Indeed, some 436 persons object to such automated mappings because they don't reveal 437 anything about the IP address. Others object to revealing 438 information to outsiders. 440 Suggestion: Use names that become something like characters rather 441 than names that reflect the purpose. So instead of naming a host 442 system 'accounting', name it something that becomes meaningful to the 443 people the use the system, yet meaningless to outsiders. In the 444 event of problems, the system can be discussed by name without 445 revealing unnecessary information about the purpose of the system 447 One could completely automate both forward and reverse domains so 448 that a query for an A record for x1-2-0-192.example.com would produce 449 the address 192.0.2.1 while a PTR query produces the name. No 450 information at all is exchanged in such a transaction, and so it 451 could be done locally, without DNS servers at all, if one were so 452 inclined. Or it could be done by a set of servers on the internet. 453 Certainly, trust decisions should not be affected by such a zero 454 information system. 456 3.6. Delegation Issues 458 A method of delegating CIDR blocks has been described in [RFC2317]. 459 Organizations have performed such RFC2317 delegations omitting the 460 first and last IP addresses in the block, asserting that these IP 461 addresses are unusable. This assumption is only true if the block is 462 used on a broadcast network, such as an ethernet. However, there are 463 many types of non-broadcast network media. Examples include ATM and 464 Frame Relay, and of course the host may have internal non-broadcast 465 network topology, suitable for virtual hosting. The delegated block 466 might also be further subnetted and routed as /32 by the recipient. 468 Best Practice: Delegate all addresses in block. Do not assume that 469 everyone uses ethernet. 471 4. Security Considerations 473 DNS PTR records are entirely optional, and MUST NOT be assumed to 474 exist. Software MUST NOT fail or incur delay as a result of the non- 475 existance of PTR records. 477 Unauthenticated DNS MUST NOT be relied on for security or trust 478 decisions. Even when DNSSEC is used to verify the authenticity of 479 DNS records, matching reverse and forward records do not imply either 480 improved security or trustworthiness over sites that either do not 481 have reverse DNS or that do not have matching foward/reverse DNS. 483 DNS records MUST NOT be used in logs instead of IP addresses. 484 Logging only the PTR resource records instead of the IP address is 485 vulnerable to attack, since attackers may control the name, and may 486 also use long names that will either become truncated by the logging 487 system, or require upto 255 bytes to store. Logging both IP address 488 and DNS PTR records may be helpful but one must also consider that 489 the 255 byte per record space requirement does not become a DOS 490 attack on the logging system. 492 5. Normative References 494 [RFC0883] Mockapetris, P., "Domain names: Implementation 495 specification", RFC 883, November 1983. 497 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 498 STD 13, RFC 1034, November 1987. 500 [RFC1035] Mockapetris, P., "Domain names - implementation and 501 specification", STD 13, RFC 1035, November 1987. 503 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 504 Inter-Domain Routing (CIDR): an Address Assignment and 505 Aggregation Strategy", RFC 1519, September 1993. 507 [RFC1788] Simpson, W., "ICMP Domain Name Messages", RFC 1788, 508 April 1995. 510 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 511 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 512 BCP 12, RFC 2050, November 1996. 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 517 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 518 ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. 520 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 521 "DNS Extensions to Support IP Version 6", RFC 3596, 522 October 2003. 524 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 525 Name System (DNS)", RFC 3833, August 2004. 527 [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information 528 Queries", RFC 4620, August 2006. 530 [1] 532 Author's Address 534 Dean Anderson 535 Av8 Internet, Inc 536 P.O. Box 7286 537 Nashua, NH 03060 538 USA 540 Phone: +1 617 256 5494 541 Email: dean@av8.net 543 Full Copyright Statement 545 Copyright (C) The IETF Trust (2007). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Acknowledgment 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).