IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                       February 26,
                                                           June 21, 1999

                       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
    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."

    To view the

    The list of current Internet-Drafts can be accessed at

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

1.  Abstract

    This document describes an experimental protocol for asking an IPv6
    node to supply certain network information, such as its fully-
    qualified domain name.  IPv6 implementation experience has shown
    that direct queries for FQDN are useful, and a direct query
    mechanism for other information has been requested.

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 an 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",
    document are to be interpreted as described in [2119].

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

3.  Node Information Messages

    Two types of Node Information messages, the NI Query and the NI
    Reply, are carried in ICMPv6 [2463] packets.  They have the same
    format, except that the Query lacks the Reply Data section.

      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                             +
     |                                                               |
     |                                                               |
     /                          Reply                             Data                              /
     |                                                               |


    Type        TBA1        139 - NI Query.
                140 - NI Reply.

    Code        For NI Query, always 0. 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 domain name
                    which is the subject of this Query
                For NI Reply:

                0   Indicates a successful reply.

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

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

    Checksum    The ICMPv6 checksum.

    Qtype       A 16-bit field which designates the type if 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.  Four values of Qtype are specified in
                this document.

    Flags       Qtype-specific flags which may be defined for certain
                Query types. 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

    Nonce       An opaque 64-bit field to help avoid spoofing. 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


    Data        In a Query, the subject address or name.  In a Reply,
                Qtype-specific data present only in an NI Reply message
                with when the ICMPv6 Type
                field equal to is zero.  The length of the
                Reply Data may be inferred
                from the IPv6 header's Payload Length field [2460] and
                the length of the fixed portion of the NI Reply packet and the
                lengths of the ICMPv6 header and intervening extension

4.  Message Processing

    The Querier constructs an ICMP NI Query and sends it to the unicast 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.

    When the subject is a domain 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 by appending to the prefix
    FF02:0:0:0:0:2::/96 the CRC-32 checksum [IS3309] of the first
    component of the subject domain name -- the portion up to, but
    excluding, the first period.

    The Nonce should 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 [2401] must be

    Upon receiving an NI Query, the Responder must check the Query's
    IPv6 destination address and discard the Query without further
    processing if it is not one of the Responder's unicast or anycast
    addresses.  A Responder must also silently discard a Query whose
    subject address or name (in the Data field) does belong to that

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

    Next, the Responder should decide whether to refuse an answer, based
    on local policy not addressed in this document.  If an answer is
    refused, the Responder may send an NI Reply with ICMPv6 Type = 1 and
    no Reply Data.  Again, the Responder should rate-limit such replies
    as it would ICMPv6 error replies [2463, 2.4(f)].

    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 with an ICMPv6 source address equal to the Queried
    Address, unless that address was an anycast address.  If the Queried
    Address was anycast, the source adderss address for the Reply should SHOULD be one
    belonging to the interface on which the Query was received.

    The Querier should silently discard any Reply whose Destination
    Address and Nonce do not match

    If the Source Address and Nonce of Query was sent to an
    outstanding Query.

    An NI message anycast or multicast address,
    transmission of either sort must never the Reply MUST be sent to delayed by a multicast
    address. random interval
    between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor
    Discovery [2461].

5.  Defined Qtypes

    The following four Qtypes are defined and must be supported by any
    implementation of this protocol.

    0   NOOP.

    1   Supported Qtypes.

    2   FQDN.


    3   Node Addresses.

5.1.  NOOP

    This Qtype NI type has no defined flags and never has a Reply Data field.  A
    Reply to an NI NOOP Query tells the Querier that a node with the
    Queried Address was is up and reachable, implments implements the Node Information
    protocol, and secondarily reveals incidentally happens to reveal whether the Queried
    Address was an anycast address.

5.2.  Supported Qtypes

    This Query contains no Data field.  The Reply Data in an NI Supported Qtypes Reply is a bit-vector
    showing which Qtypes are supported by the Responder.  The Reply Data
    has two variant forms: uncompressed and compressed.  The
    uncompressed Data format is grouped in one or more complete 32-bit words, each
    word a bitmask with the low-order bit in each word corresponding to
    the lowest numbered Qtype in a group of 32.  The first word
    describes the Responder's support for Qtypes 0 to 31, the second
    word 32 to 63, and so on.

    A 1-valued bit indicates support for the corresponding Qtype.  The
    lowest-order four bits in the first 32-bit word must be set to 1,
    showing support for the four Qtypes defined in this specification.
    Thus the Data field of an NI Supported Qtypes Reply from a Responder
    implementing only the 4 Qtypes defined here will contain 32 bits in
    the following form:

      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
     |0 0 0                    . . .                    0 0 0 1 1 1 1|

    The compressed form of the Reply Data consists of a sequence of
    blocks, each block consisting of two 16-bit unsigned integers, nWord
    and nSkip, followed by nWord 32-bit bitmasks describing the
    Responder's support for 32 consecutive Qtypes.  nSkip is a count of
    32-bit words which would have been all-zero and have been
    suppressed.  The last block MUST have nSkip = 0.  As an example, a
    Responder supporting Qtypes 0, 1, 2, 3, 60, and 4097 could express
    that information with the following Reply Data (nWord and nSkip
    fields are written in decimal for easier reading):

      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
     |               2               |              126              |
     |0 0 0                    . . .                    0 0 0 1 1 1 1|
     |0 0 0 1 0 0 0                    . . .                    0 0 0|
     |               1               |               0               |
     |0 0 0                      . . .                      0 0 0 1 0|

    One flag bit is defined.

      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            Qtype=1            |          unused             |C|

    In a Query, a C-flag set to 1 indicates that the Querier will accept
    the compressed form of the Reply Data.  In a Reply, a C-flag set to
    1 indicates that the Reply Data is compressed.  The compression is not
    yet defined and may only compressed form
    MAY be used in a Reply only if the Query had the C-
    flag C-flag set.
    Implementations of this specification SHOULD support the compressed
    form and if they do, SHOULD set the C-flag in all Supported Qtypes
    Queries and SHOULD use the compressed form in Supported Qtypes
    Replies (when allowed by the C-flag in the query) if doing so would
    avoid fragmentation of the Reply or save significant space in the

5.3.  FQDN

    The NI FQDN Query requests the fully-qualified domain name
    corresponding to the Queried Address. 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                              |
     |    NameLen    |                   FQDN ...                    |
     +-+-+-+-+-+-+-+-+                                               +
     /                                                               /
     +                                                               +
     |                                                               |

    TTL         The number of seconds that the name may be cached.  For
                compatibility with DNS [1035], this is a 32-bit signed,
                2's-complement number, which must not be negative.

    NameLen     The length in octets of the FQDN, as an 8-bit unsigned

    FQDN        The fully-qualified domain name of the Responder which
                corresponds to the Queried Address, Subject Address or Name, as a
                sequence of NameLen US-ASCII octets, with periods
                between the labels, and no period after the last label.

    The Responder must fill in the TTL field of the Reply with a
    meaningful value if possible.  That value should be one of the

        The remaining lifetime of a DHCP lease on the Queried Subject Address;

        The remaining Valid Lifetime of a prefix from which the Queried Subject
        Address was derived through Stateless Autoconfiguration [2461,

        The TTL of an existing AAAA or A6 record which associates the
        Subject Address with the FQDN being returned.

    If the Responder knows its hostname but not its domain, it MUST send
    its one-component name with no periods.  It may still be possible to
    return a meaningful TTL based on a DHCP lease or autoconfigured

    If the Responder does not know its name at all it MUST send a Reply
    with TTL=0, NameLen=0 and no FQDN.

    One Flag bit is defined, in the Reply only.

      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            Qtype=2            |          unused             |T|

    A T-flag set to 1 in an NI FQDN Reply indicates that the TTL field
    contains a meaningful value.  If the T-flag is 0, the TTL should SHOULD be
    set to zero by the Responder and must MUST be ignored by the Querier.

    If a name rather than an address was the Subject of the Query, the
    T-flag MUST be zero and the TTL SHOULD be zero.

    The information in an NI FQDN Reply with T-flag 1 may be cached and
    used for the period indicated by that TTL.  If a Reply has no TTL
    (T-flag 0), the information in that Reply must not be used more than
    once.  If the Query was sent by a DNS server on behalf of a DNS
    client, the result may be returned to that client as a DNS response
    with TTL zero.  However, if the server has the matching AAAA record,
    either in cache or in an authoritative zone, then the TTL of that
    record may be used as the missing TTL of the NI FQDN Reply and the
    information in the reply may be cached and used for that period.

    It would be an implementation choice for a server to perform a DNS
    query for the AAAA or A6 record that matches a received NI FQDN
    Reply.  This might be done to obtain a TTL to make the Reply
    cacheable or in anticipation of such a AAAA query from the client
    that caused the FQDN Query.

5.3.1.  Discussion

    Because a node can only answer a FQDN Request when it is up and
    reachable, it may be useful to create a proxy responder for a group
    of nodes, for example a subnet or a site.  Such a mechanism is not
    addressed here.

    IPsec can be applied to NI FQDN messages to achieve greater trust in
    the information obtained, but such a need may be obviated by
    applying IPsec directly to some other communication which is going
    on (or contemplated) between the Querier and Responder.

5.4.  Node Addresses

    The NI Node Addresses Query requests some set of the Responder's
    unicast addresses.  The Reply Data is a sequence of 128-bit IPv6
    addresses, with Preferred addresses listed before Deprecated
    addresses [2461], but otherwise in no special order.  Four flag bits
    are defined in the Query, and five 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            Qtype=3            |       unused        |T|A|G|S|L|

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

    A   If set to 1, all the Responder's unicast addresses are (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
        Queried Subject Address.

    G   If set to 1, Global-scope addresses [2374] are requested.

    S   If set to 1, Site-local addresses [2374] are requested.

    L   If set to 1, Link-local addresses [2374] are requested.

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

6.  IANA Considerations

    ICMPv6 type values 139 and 140 have been assigned by IANA for this

    This document defines four values of Qtype, numbers 0 through 3.
    Following the policies outlined in [2434], new values, and their
    associated Flags and Reply Data, may be defined as follows.

         Qtypes 4 through 255, by IETF Consensus.

         Qtypes 256 through 1023, Specification Required.

         Qtypes 1024 through 4095, First Come First Served.

         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 for of the Reply Data is used.

    The multicast address formation of section  has not yet been
    discussed in the IPNG working group and is not yet requested or
    assigned for this use.

7.  Security Considerations

    The anti-spoofing Nonce does not give any protection from spoofers
    who can snoop the Query or the Reply.

    In a large Internet with relatively frequent renumbering, the
    maintenance of of KEY and SIG records [2065] 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

8.  Acknowledgments

    Alain Durand contributed to this specification.  This document is
    not the first proposal of a direct query mechanism for address-to-name address-to-
    name translation.  The idea was had been discussed and
    deferred briefly in the IPng
    working group and an experimental RFC [1788] describes such a
    mechanism for IPv4.

9.  References

    [1035] P. Mockapetris, "Domain Names - Implementation and
        Specification", RFC 1035, STD 13.

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

    [2119] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels," RFC 2119.

    [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 2373, July 1998.

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

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

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

    [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.

    [IS3309] International Organization for Standardization, "ISO
        Information Processing Systems - Data Communication High-Level
        Data Link Control Procedure - Frame Structure", IS 3309, October
        1984, 3rd Edition.

10.  Author's Address

    Matt Crawford
    Fermilab MS 368
    PO Box 500
    Batavia, IL 60510

    Phone: +1 630 840 3461

    Email: crawdad@fnal.gov