This document defines five values of Qtype, numbers 0 through 4.
Following the policies outlined in [16], new values, and their
associated Flags and Reply Data, are to be defined by IETF Consensus.
The IANA has assigned the IPv6 multicast prefix
FF02:0:0:0:0:2:FF00::/104 for use in Node Information Queries as
defined in Section 5. It should be noted that this assignment does
conform with the requirements defined in [17].
8. Security Considerations
This protocol shares the security issues of ICMPv6 that are
documented in the "Security Considerations" section of [5].
This protocol has the potential of revealing information useful to a
would-be attacker. An implementation of this protocol MUST have a
default configuration that refuses to answer queries from global-
scope [3] addresses.
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
who can eavesdrop the Query or the Reply.
The information learned via this protocol SHOULD NOT be trusted for
making security-relevant decisions unless some other mechanisms
beyond the scope of this document are used to authenticate this
information.
An implementation of this protocol SHOULD provide the ability to
control the dissemination of information related to IPv6 Privacy
Addresses [18]. The default action of this policy SHOULD NOT provide
a response to a Query that contains a node’s Privacy Addresses.
A node MUST NOT include Privacy Addresses in any Node Addresses
response that includes a public address, or for which the source
address of the response, the destination address of the request, or
the Subject Address of the request is a public address. Similarly, a
node MUST NOT include any address other than the (single) Privacy
Address in any Node Addresses response that includes the Privacy
Address, or for which the source address of the response, the
destination address of the request, or the Subject Address of the
request is the Privacy Address.
9. Acknowledgements
Alain Durand contributed to this specification, and valuable feedback
and implementation experience were provided by Jun-Ichiro Hagino and
Tatuya Jinmei. Other useful comments were received from Robert Elz,
Keith Moore, Elwyn Davies, Pekka Savola, and Dave Thaler. Bob Hinden
and Brian Haberman have acted as document editors during the IETF
advancement process.
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 [19] describes such a
mechanism for IPv4.
10. References
10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034,
March 2005.
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[11] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast
Address Format", RFC 3587, August 2003.
[13] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006.
10.2. Informative References
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[15] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[17] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[18] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[19] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
Authors’ Addresses
Matt Crawford
Fermilab
PO Box 500
Batavia, IL 60510
US
Phone: +1 630 840 3461
EMail: crawdad@fnal.gov
Brian Haberman (editor)
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).