--- 1/draft-ietf-ipngwg-icmp-name-lookups-08.txt 2006-02-04 23:38:52.000000000 +0100 +++ 2/draft-ietf-ipngwg-icmp-name-lookups-09.txt 2006-02-04 23:38:52.000000000 +0100 @@ -1,17 +1,17 @@ IPng Working Group Matt Crawford Internet Draft Fermilab - July 20, 2001 + May 17, 2002 IPv6 Node Information Queries - + Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six @@ -46,26 +46,26 @@ not found in the DNS - for example discovering relationships between addresses without reference to names. And the functions that do overlap with the DNS may be useful in serverless environments, for debugging, or in regard to link-local and site-local addresses [2373] which often will not be listed in the DNS. 2. Terminology A "Node Information (or NI) Query" message is sent by a "Querier" node to a "Responder" node in an ICMPv6 packet addressed to the - "Queried Address." The Query concerns a "Subject Address" which may - differ from the Queried Address, or a "Subject Name". The Responder - sends a "Node Information Reply" to the Querier, containing - information associated with the node at the Queries address. A node - receiving a NI Query will be termed a Responder even if it does not - send a Reply. + "Queried Address." The Query concerns a "Subject Address" (which + may differ from the Queried Address) or a "Subject Name". The + Responder sends a "Node Information Reply" to the Querier, + containing information associated with the node at the Queried + Address. A node receiving a NI Query will be termed a Responder + even if it does not send a reply. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2119]. Packet fields marked "unused" must be zero on transmission and, aside from inclusion in checksums or message integrity checks, ignored on reception. 3. Node Information Messages @@ -526,21 +526,45 @@ 5.5.1. Discussion It is possible that a node may treat IPv4 interfaces and IPv6 interfaces as distinct, even though they are associated with the same hardware. When such a node is responding to a NI Query having a Subject Address of one type requesting the other type, and the Query has the A flag set to 0, it SHOULD consider IP interfaces, other than tunnels, associated with the same hardware as being the same interface. -6. IANA Considerations +6. Applicability Statement + + IPv6 Node Information Queries include the capability to provide + forward and reverse name lookups independent of the DNS by sending + packets directly to IPv6 nodes or groups of nodes. + + The applicability of these mechanics is currently limited to + diagnostic and debugging tools. These mechanisms can be used to + learn the addresses and names for nodes on the other end of a + point-to-point link or nodes on a shared-medium link such as an + Ethernet. This is very useful when debugging problems or when + bringing up IPv6 service where there isn't global routing or DNS + name services available. IPv6's large auto-configured addresses + make debugging network problems and bringing up IPv6 service + difficult without these mechanisms. An example of a IPv6 debugging + tool using IPv6 Node Information Queries is the ping6 program in the + KAME, USAGI, and other IPv6 implementations [KAME]. + + The mechanisms defined in this document may have wider applicability + in the future (for example, name lookups in zero configuration + networks, global reverse name lookups, etc.), but any use beyond + debugging and diagnostic tools is left for further study and is + beyond the scope of this document. + +7. IANA Considerations ICMPv6 type values 139 and 140 have been assigned by IANA for this protocol. This document defines three values of the ICMPv6 Code field for each of these ICMPv6 Type values. Additional Code values may be defined only by IETF Consensus [2434]. This document defines five values of Qtype, numbers 0 through 4. Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [2434], new values, and their associated Flags and Reply Data, may be defined as follows. @@ -554,21 +578,21 @@ Qtypes 4096 through 65535, Private Use. Users of Private Use values should note that values above 8000 to 9000 are likely to lead to fragmentation of "Supported Qtypes" Replies unless the compressed form of the Reply Data is used. Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used in section 4 as a destination for IPv6 Node Information Queries is requested. -7. Security Considerations +8. Security Considerations This protocol has the potential of revealing information useful to a would-be attacker. An implementation of this protocol SHOULD have a default configuration which refuses to answer queries from global- scope [2373] adresses. Implementations SHOULD apply rate-limiting to NI responses to avoid being used in a denial of service attack. The anti-spoofing Nonce does not give any protection from spoofers @@ -577,33 +601,33 @@ In a large Internet with relatively frequent renumbering, the maintenance of of KEY and SIG records [2535] in the zones used for address-to-name translations will be no easier than the maintenance of the NS, SOA and PTR records themselves, which already appears to be difficult in many cases. The author expects, therefore, that address-to-name mappings, either through the original DNS mechanism or through this new mechanism, will generally be used as only a hint to find more trustworthy information using the returned name as an index. -8. Acknowledgments +9. Acknowledgments Alain Durand contributed to this specification and valuable feedback and implementation experience was provided by Jun-Ichiro Hagino and Tatuya Jinmei. Other useful comments were received from Robert Elz and Keith Moore. This document is not the first proposal of a direct query mechanism for address-to-name translation. The idea had been discussed briefly in the IPng working group and RFC 1788 [1788] describes such a mechanism for IPv4. -9. References +10. References [1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 1034, STD 13, November 1987. [1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13, November 1987. [1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. @@ -631,21 +655,23 @@ [2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [2535] D. Eastlake 3rd, "Domain Name System Security Extensions", RFC 2535, March 1999. -10. Author's Address + [KAME] KAME Project, http://www.kame.net/. + +11. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840 3461 Email: crawdad@fnal.gov