[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 4620

IPng Working Group                                         Matt Crawford
Internet Draft                                                  Fermilab
                                                           June 26, 2003

                       IPv6 Node Information Queries
                <draft-ietf-ipngwg-icmp-name-lookups-10.txt>



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 list Internet-Draft Shadow Directories, see
    http://www.ietf.org/shadow.html.


Abstract

    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.


1.  Introduction

    This document specifies a mechanism for discovering information
    about names and addresses. The applicability of these mechanics is
    currently limited to diagnostic and debugging tools. In the global
    internet, the Domain Name System [1034, 1035] 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.




Expires December 31, 2003       Crawford                        [Page 1]


Internet Draft             ICMP Name Lookups               June 26, 2003


    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 site-local addresses
    [3513] 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 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.


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) 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 word "name" in this document refers to a hostname with or
    without the domain.  Where necessary, the cases of fully-qalified
    and single-label names will be distinguished.




Expires December 31, 2003       Crawford                        [Page 2]


Internet Draft             ICMP Name Lookups               June 26, 2003


    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.


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

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

    Fields:

    Type        139 - NI Query.
                140 - NI Reply.

    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.




Expires December 31, 2003       Crawford                        [Page 3]


Internet Draft             ICMP Name Lookups               June 26, 2003


                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.

    Checksum    The ICMPv6 checksum.

    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.

    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.

    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.

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



Expires December 31, 2003       Crawford                        [Page 4]


Internet Draft             ICMP Name Lookups               June 26, 2003


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

    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 [2535], 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 [1321] 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.  The resulting multicast
    address will be termed the "NI Group Address" for the name.

    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
    used.  Providing the infrastructure to authenticate NI Queries and
    Replies may be quote difficult outside of a well-defined community.

    Upon receiving a 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 a NI Group Address for a name belonging
    to the Responder or a NI Group Address for a name for which the
    Responder is providing proxy service.  A node MAY be configurable to
    discard NI Queries to multicast addresses other than its NI Group
    Address(es) but if so, the default configuration MUST be not to
    discard them.



Expires December 31, 2003       Crawford                        [Page 5]


Internet Draft             ICMP Name Lookups               June 26, 2003


    A Responder must also silently discard a Query whose Subject Address
    or Name (in the Data field) does not belong to that node, unless it
    is providing proxy service for that Subject.  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
    [2535].

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

    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, the Responder may send
    a NI Reply with ICMPv6 Code = 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 or a multicast address.
    If the Queried Address was anycast or multicast, the source address
    for the Reply SHOULD be one belonging to the interface on which the
    Query was received.

    If the Query was sent to an anycast or 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 [2461].


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.


    0   NOOP.

    1   (unused)

    2   Node Name.



Expires December 31, 2003       Crawford                        [Page 6]


Internet Draft             ICMP Name Lookups               June 26, 2003


    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 a NI NOOP Query tells the Querier that a node with the
    Queried Address is up and reachable, implements the Node Information
    protocol, and incidentally happens to reveal whether the Queried
    Address was an anycast address.  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 ...                       |
     +                                                               +
     /                                                               /
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    TTL         MUST be zero.  Any non-zero value received MUST be
                treated as zero.

    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 [1035].  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 [1035]
                SHOULD be used, and the offsets are counted from the



Expires December 31, 2003       Crawford                        [Page 7]


Internet Draft             ICMP Name Lookups               June 26, 2003


                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 separate a 32-bit TTL
    value, with Preferred addresses listed before Deprecated addresses
    [2461], 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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    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.

    C   If set to 1, IPv4-compatible and IPv4-mapped addresses [3513]
        are requested.

    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.

    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



Expires December 31, 2003       Crawford                        [Page 8]


Internet Draft             ICMP Name Lookups               June 26, 2003


    Reply.

    The TTL associated with each address MUST be zero.

    IPv4-mapped addresses can only be returned by a Node Information
    proxy, since they represent addresses of IPv4-only nodes, which
    perforce do not implement this protocol.


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|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

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






Expires December 31, 2003       Crawford                        [Page 9]


Internet Draft             ICMP Name Lookups               June 26, 2003


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, are to be defined by IETF
    Consensus.

    Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used
    in section 5 as a destination for IPv6 Node Information Queries is
    requested.


8.  Security Considerations

    This protocol shares the security issues of ICMPv6 that are
    documented in the "Security Considerations" section of [2463].

    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 [3513] 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
    information.


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.  Bob Hinden kindly edited this document to make it
    more palatable to the IESG.




Expires December 31, 2003       Crawford                       [Page 10]


Internet Draft             ICMP Name Lookups               June 26, 2003


    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.


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.

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

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

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

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

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

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

    [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", RFC 2461, 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.

    [3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
        Architecture", RFC 3513, April 2003.



Expires December 31, 2003       Crawford                       [Page 11]


Internet Draft             ICMP Name Lookups               June 26, 2003


    [KAME] KAME Project, http://www.kame.net/.

11.  Author's Address

    Matt Crawford
    Fermilab MS 369
    PO Box 500
    Batavia, IL 60510
    USA

    Phone: +1 630 840 3461

    Email: crawdad@fnal.gov






































Expires December 31, 2003       Crawford                       [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/