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

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/