IPv6 WG                                                      M. Crawford
Internet-Draft                                                  Fermilab
Expires: January 13, July 7, 2006                                   B. Haberman, Ed.
                                                                 JHU APL
                                                           July 12, 2005
                                                         January 3, 2006

                     IPv6 Node Information Queries

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 13, July 7, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).


   This document describes a protocol for asking an IPv6 node to supply
   certain network information, such as its hostname or fully-qualified
   domain name.  IPv6 implementation experience has shown that direct
   queries for a hostname are useful, and a direct query mechanism for
   other information has been found useful in serverless environments
   and for debugging.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  3
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Node Information Messages  . . . . . . . . . . . . . . . . . .  4
   5.  Message Processing . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1  8
     6.1.  NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  Node Name  . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.3.  Node Addresses . . . . . . . . . . . . . . . . . . . . . .  9
     6.4.  IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10
       6.4.1.  Discussion . . . . . . . . . . . . . . . . . . . . . . 10 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 12 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 . . 14
   Intellectual Property and Copyright Statements . . . . . . . . 14 . . 15

1.  Introduction

   This document specifies a mechanism for discovering information about
   names and addresses.  The applicability of these mechanics mechanisms is
   currently limited to diagnostic and debugging tools and network
   management (e.g. node discovery).  In the global internet, the Domain
   Name System[1][2] is the authoritative source of such information and
   this specification is not intended to supplant or supersede it.  And
   in fact, in a well-supported network, the names and addresses dealt
   with by this mechanism will be the same ones, and with the same
   relationships, as those listed in the DNS.

   This new Node Information protocol does provide facilities which are
   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 unique-local addresses [3]
   which often will not be listed in the DNS.

2.  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 mechanisms is currently limited to
   diagnostic and debugging tools and network management (e.g. node
   discovery).  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 an
   IPv6 debugging tool using IPv6 Node Information Queries is the ping6
   program in the KAME (<http://www.kame.net>), USAGI, and other IPv6

   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.), future, but any use beyond debugging and diagnostic tools is
   left for further study and is beyond the scope of this document.

3.  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 and may be an IPv6 or IPv4 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 an NI Query will be termed a
   Responder even if it does not send a reply.

   The word "name" in this document refers to a hostname with or without
   the domain.  Where necessary, the cases of fully-qalified fully-qualified and single-
   single-label names will be distinguished.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [4].

   Packet fields marked "unused" must be zero on transmission and, aside
   from inclusion in checksums or message integrity checks, ignored on

4.  Node Information Messages

   Two types of Node Information messages, the NI Query and the NI
   Reply, are carried in ICMPv6 [5] packets.  They have the same format.

    0                   1                   2                   3
    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
   |     Type      |     Code      |           Checksum            |
   |             Qtype             |             Flags             |
   |                                                               |
   +                             Nonce                             +
   |                                                               |
   |                                                               |
   /                             Data                              /
   |                                                               |

   Figure 1: Node Information Messages


   o  Type
      *  139 - NI Query

      *  140 - NI Reply

   o  Code

      *  For NI Query

         +  0 - Indicates that the Data field contains an IPv6 address
            which is the Subject of this Query.

         +  1 - Indicates that the Data field contains a name which is
            the Subject of this Query, or is empty, as in the case of a
            NOOP or Supported Qtypes query.

         +  2 - Indicates that the Data field contains an IPv4 address
            which is the Subject of this Query.

      *  For NI Reply

         +  0 - Indicates a successful reply.  The Reply Data field may
            or may not be empty.

         +  1 - Indicates that the Responder refuses to supply the
            answer.  The Reply Data field will be empty.

         +  2 - Indicates that the Qtype of the Query is unknown to the
            Responder.  The Reply Data field will be empty.

   o  Checksum - The ICMPv6 checksum.

   o  Qtype - A 16-bit field which designates the type of information
      requested in a Query or supplied in a Reply.  Its value in a Reply
      is always copied from the corresponding Query by the Responder.
      Five values of Qtype are specified in this document.

   o  Flags - Qtype-specific flags which may be defined for certain
      Query types and their Replies.  Flags not defined for a given
      Qtype must be zero on transmission and ignored on reception, and
      must not be copied from a Query to a Reply unless so specified in
      the definition of the Qtype.

   o  Nonce - An opaque 64-bit field to help avoid spoofing and/or to
      aid in matching Replies with Queries.  Its value in a Query is
      chosen by the Querier.  Its value in a Reply is always copied from
      the corresponding Request by the Responder.

   o  Data - In a Query, the Subject Address or Name.  In a Reply,
      Qtype-specific data present only when the ICMPv6 Code field is
      zero.  The length of the Data may be inferred from the IPv6
      header's Payload Length field [2460], the length of the fixed
      portion of the NI packet and the lengths of the ICMPv6 header and
      intervening extension headers.

   Note that the type of information present in the Data field of a
   Query is declared by the ICMP Code, while the type of information, if
   any, in the Data field of a Reply is determined by the Qtype.

   When the Subject of a Query is a name, the name MUST be in DNS wire
   format [2].  The name may be either a fully-qualified domain name,
   including the terminating zero-length label, or a single DNS label
   followed by two zero-length labels.  Since a Query contains at most
   one name, DNS name compression MUST NOT be used.

5.  Message Processing

   The Querier constructs an ICMP NI Query and sends it to the address
   from which information is wanted.  When the Subject of the Query is
   an IPv6 address, that address will normally be used as the IPv6
   destination address of the Query, but need not be if the Querier has
   useful a priori information about the addresses of the target node.
   An NI Query may also be sent to a multicast address of link-local
   scope [3].

   When the Subject is a name, either fully-qualified or single-
   component, and the Querier does not have a unicast address for the
   target node, the query MUST be sent to a link-scope multicast address
   formed in the following way.  The Subject Name is converted to the
   canonical form defined by DNS Security [6], which is uncompressed
   with all alphabetic characters in lower case.  (If additional DNS
   label types or character sets for host names are defined, the rules
   for canonicalizing those labels will be found in their defining
   specification.)  Compute the MD5 hash [11] [7] of the first label of the
   Subject Name -- the portion beginning with the first one-octet length
   field and up to, but excluding, any subsequent length field.  Append
   the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:
   2::/96. FF02:0:0:0:0:2:
   FF::/104.  The resulting multicast address will be termed the "NI
   Group Address" for the name.  A node will support an "NI Group
   Address" for each associated Subject Name.

   The Nonce should MUST be a random or good pseudo-random value to foil
   spoofed replies.  An implementation which allows multiple independent
   processes to send NI queries MAY use the Nonce value to deliver
   Replies to the correct process.  Nonetheless, such processes MUST
   check the received Nonce and ignore extraneous Replies.

   If true communication security is required, IPsec [12] MUST [13] should be
   used.  Providing the infrastructure to authenticate NI Queries and
   Replies may be quite difficult outside of a well-defined community.

   Upon receiving an NI Query, the Responder must check the Query's IPv6
   destination address and discard the Query without further processing
   unless it is one of the Responder's unicast or anycast addresses, or
   a link-local scope multicast address which the Responder has joined.
   Typically the latter will be an NI Group Address for a name belonging
   to the Responder.  A node MAY be configured to discard NI Queries to
   multicast addresses other than its NI Group Address(es) but if so,
   the default configuration MUST SHOULD be not to discard them.  An
   exception is made in the previous rule in the case of the All-Routers
   (FF02::2) and All-Nodes (FF02::1) multicast addresses.  The default
   configuration for responding to NI Queries to these multicast
   addresses MUST be to discard them.

   A Responder must also silently discard a Query whose Subject Address
   or Name (in the Data field) does not belong to that node.  A single-
   component Subject Name matches any fully-qualified name whose first
   label matches the Subject.  All name matching is done in a case-
   independent manner consistent with DNSSEC name canonicalization [6].

   Next, if Qtype is unknown to the Responder, it must return an NI
   Reply with ICMPv6 Code = 2 and no Reply Data.  The Responder should
   rate-limit such replies as it would ICMPv6 error replies [5].

   Next, the Responder should decide whether to refuse an answer, based
   on local policy.  (See "Security Considerations" for recommended
   default behavior.)  If an answer is refused, depending on local
   policy the Responder may can elect to silently discard the query or send
   an NI Reply with ICMPv6 Code = 1 and no Reply Data.  Again, the
   Responder should rate-limit such replies as it would ICMPv6 error
   replies [5].

   Finally, if the Qtype is known and the response is allowed by local
   policy, the Responder MUST fill in the Flags and Reply Data of the NI
   Reply in accordance with the definition of the Qtype and transmit the
   NI Reply.  The source address of the NI Reply SHOULD be selected
   using the rules defined in [7]. [8].

   If the Query was sent to a multicast address, transmission of the
   Reply MUST be delayed by a random interval between zero and
   MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [8]. [9].

6.  Defined Qtypes

   The following Qtypes are defined.  Qtypes 0, 2, and 3 MUST be
   supported by any implementation of this protocol.  Qtype 4 SHOULD be
   supported by any implementation of this protocol on an IPv4/IPv6
   dual-stack node and MAY be supported on an IPv6-only node.

                     | Qtype Value |   Qtype Name   |
                     |      0      |      NOOP      |
                     |      1      |     unused     |
                     |      2      |    Node Name   |
                     |      3      | Node Addresses |
                     |      4      | IPv4 Addresses |


6.1.  NOOP

   This NI type has no defined flags and never has a Data field.  A
   Reply to an NI NOOP Query tells the Querier that a node with the
   Queried Address is up and reachable, reachable and implements the Node
   protocol, and incidentally happens to reveal whether the Queried
   Address was an anycast address. protocol.  On transmission, the ICMPv6 Code in a NOOP
   Query must be set to 1 and the Code in a NOOP Reply must be 0.  On
   reception of a NOOP Query or Reply, the Code must be ignored.


6.2.  Node Name

   The NI Node Name Query requests the fully-qualified or single-
   component name corresponding to the Subject Address or Name.  The
   Reply Data has the following format.

    0                   1                   2                   3
    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
   |                              TTL                              |
   |                          Node Names ...                       |
   +                                                               +
   /                                                               /
   +                                                               +
   |                                                               |

   Figure 2: Node Information Reply Message
   o  TTL - MUST be zero.  Any non-zero value received MUST be treated
      as zero.  This field is no longer used but is present to preserve
      backwards compatibility with older implementations.

   o  Node Names - The fully-qualified or single-component name or names
      of the Responder which correspond(s) to the Subject Address or
      Name, in DNS wire format format, Section 3.1 of [2].  Each name MUST be
      fully-qualified if the responder knows the domain suffix, and
      otherwise be a single DNS label followed by two zero-length
      labels.  When multiple node names are returned and more than one
      of them is fully-qualified, DNS name compression [2] compression, Section 4.1.4 of
      [2], SHOULD be used, and the offsets are counted from the first
      octet of the Data field.  An offset of 4, for example, will point
      to the beginning of the first name.

   The Responder must fill in the TTL field of the Reply with zero.

   Only one TTL is included in the reply.

   If the Responder does not know its name at all it MUST send a Reply
   with TTL=0 and no Node Names (or a Reply with Code=1 indicating
   refusal to answer).  The Querier will be able to determine from the
   packet length that the Data field contains no names.


6.3.  Node Addresses

   The NI Node Addresses Query requests some set of the Responder's IPv6
   unicast addresses.  The Reply Data is a sequence of 128-bit IPv6
   addresses, each address preceded by a separate 32-bit TTL value, with
   Preferred addresses listed before Deprecated addresses [8], [9], but
   otherwise in no special order.  Five flag bits are defined in the
   Query, and six in the Reply.

    0                   1                   2                   3
    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
   |            Qtype=3            |       unused      |G|S|L|C|A|T|

   Figure 3: Node Information Address Query

   o  G - If set to 1, Global-scope addresses [9] [10] are requested.

   o  S - If set to 1, Site-local addresses [9] [10] are requested.
      However, Site-local addresses are now deprecated [13] [14] and this
      flag is for backwards compatibility.

   o  L - If set to 1, Link-local addresses [9] [10] are requested.

   o  C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are
      requested.  As the IPv4-compatible addresses are now deprecated,
      this flag is for backwards compatibility with older

   o  A - If set to 1, all the Responder's unicast addresses (of the
      specified scope(s)) are requested.  If 0, only those addresses are
      requested which belong to the interface (or any one interface)
      which has the Subject Address, or which are associated with the
      Subject Name.

   o  T Defined in a Reply only, indicates that the set of addresses is
      incomplete for space reasons.

   Flags G, S, L, C and A are copied from a Query to the corresponding

   The TTL associated with each address MUST be zero.


6.4.  IPv4 Addresses

   The NI IPv4 Addresses Query requests some set of the Responder's IPv4
   unicast addresses.  The Reply Data is a sequence of 32-bit IPv4
   addresses, each address preceded by a 32-bit TTL value.  One flag bit
   is defined in the Query, and two in the Reply.

    0                   1                   2                   3
    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
   |            Qtype=4            |       unused              |A|T|

   Figure 4: Node Information IPv4 Address Query

   o  A - If set to 1, all the Responder's unicast addresses are
      requested.  If 0, only those addresses are requested which belong
      to the interface (or any one interface) which has the Subject

   o  T Defined in a Reply only, indicates that the set of addresses is
      incomplete for space reasons.

   Flag A is copied from a Query to the corresponding Reply.

   The TTL associated with each address MUST be zero.


6.4.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 an 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

7.  IANA Considerations

   ICMPv6 type values 139 and 140 were previously 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 [14]. using the "Specification Required" criteria from [15].
   IANA is requested to establish and maintain a registry for the Code
   fields associated with the Node Information Query ICMPv6 Types as a
   part of its ICMPv6 Registry updated in [11].

   This document defines five values of Qtype, numbers 0 through 4.
   Following the policies outlined in [14], [15], new values, and their
   associated Flags and Reply Data, are to be defined by IETF Consensus.

   The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0:
   0:2:FF::/104 for use in Node Information Queries as defined in
   Section 5.  It should be noted that this request does conform with
   the requirements defined in [16].

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 SHOULD MUST have a
   default configuration which 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 is used to authenticate this

   An implementation of this protocol SHOULD provide the ability to
   control the dissemination of information related to IPv6 Privacy
   Addresses [15]. [17].  The default action of this policy SHOULD NOT provide
   a reponse to a Query that contains a node's Privacy Addresses.

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 Elz,
   Keith Moore. Moore, Elwyn Davies, and Pekka Savola.  Bob Hinden and Brian
   Haberman have acted as document editors during the IETF advancement

   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 [16] [18] 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", draft-ietf-ipv6-addr-arch-v4-04 (work in
         progress), May 2005.

   [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]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "Resource Records for the DNS Security Extensions", RFC 4034,
         March 2005.

   [7]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
         April 1992.

   [8]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.


   [9]   Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.


   [10]  Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast
         Address Format", RFC 2374, July 1998.


   [11]  Conta, A., "Internet Control Message Protocol (ICMPv6) for the
         Internet Protocol Version  6 (IPv6) Specification",
         draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005.

   [12]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.


10.2.  Informative References

   [11]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
         April 1992.


   [13]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.


   [14]  Huitema, C. and B. Carpenter, "Deprecating Site Local
         Addresses", RFC 3879, September 2004.


   [15]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434,
         October 1998.


   [16]  Haberman, B., "Allocation Guidelines for IPv6 Multicast
         Addresses", RFC 3307, August 2002.

   [17]  Narten, T. and R. Draves, "Privacy Extensions for Stateless
         Address Autoconfiguration in IPv6", RFC 3041, January 2001.


   [18]  Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.

Authors' Addresses

   Matt Crawford
   PO Box 500
   Batavia, IL  60510

   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

   Phone: +1 443 778 1319
   Email: brian@innovationslab.net

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005). (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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.