draft-ietf-ipngwg-icmp-name-lookups-09.txt   draft-ietf-ipngwg-icmp-name-lookups-10.txt 
IPng Working Group Matt Crawford IPng Working Group Matt Crawford
Internet Draft Fermilab Internet Draft Fermilab
May 17, 2002 June 26, 2003
IPv6 Node Information Queries IPv6 Node Information Queries
<draft-ietf-ipngwg-icmp-name-lookups-09.txt> <draft-ietf-ipngwg-icmp-name-lookups-10.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 1, line 37 skipping to change at page 1, line 37
This document describes a protocol for asking an IPv6 node to supply This document describes a protocol for asking an IPv6 node to supply
certain network information, such as its hostname or fully-qualified certain network information, such as its hostname or fully-qualified
domain name. IPv6 implementation experience has shown that direct domain name. IPv6 implementation experience has shown that direct
queries for a hostname are useful, and a direct query mechanism for queries for a hostname are useful, and a direct query mechanism for
other information has been found useful in serverless environments other information has been found useful in serverless environments
and for debugging. and for debugging.
1. Introduction 1. Introduction
This docment specifies a mechanism for discovering information about This document specifies a mechanism for discovering information
names and addresses. (The mechanism is extensible to deal with about names and addresses. The applicability of these mechanics is
other information). In the global internet, the Domain Name System currently limited to diagnostic and debugging tools. In the global
[1034, 1035] is the authoritative source of such information and internet, the Domain Name System [1034, 1035] is the authoritative
this specifcation is not intended to supplant or supersede it. And source of such information and this specification is not intended to
in fact, in a well-supported network the names and addresses dealt supplant or supersede it. And in fact, in a well-supported network
with by this mechanism will be the same ones, and with the same the names and addresses dealt with by this mechanism will be the
relationships, as those listed in the DNS. same ones, and with the same relationships, as those listed in the
DNS.
This new Node Information protocol does provide facilities which are This new Node Information protocol does provide facilities which are
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. [3513] which often will not be listed in the DNS.
2. Terminology 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" 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 "Queried Address." The Query concerns a "Subject Address" (which
may differ from the Queried Address) or a "Subject Name". The may differ from the Queried Address) or a "Subject Name". The
Responder sends a "Node Information Reply" to the Querier, Responder sends a "Node Information Reply" to the Querier,
containing information associated with the node at the Queried containing information associated with the node at the Queried
Address. A node receiving a NI Query will be termed a Responder Address. A node receiving a NI Query will be termed a Responder
even if it does not send a reply. 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.
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 4. Node Information Messages
Two types of Node Information messages, the NI Query and the NI Two types of Node Information messages, the NI Query and the NI
Reply, are carried in ICMPv6 [2463] packets. They have the same Reply, are carried in ICMPv6 [2463] packets. They have the same
format. format.
0 1 2 3 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 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 | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 23 skipping to change at page 5, line 6
Note that the type of information present in the Data field of a 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, 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. 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 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 format [1035]. The name may be either a fully-qualified domain
name, including the terminating zero-length label, or a single DNS name, including the terminating zero-length label, or a single DNS
label followed by two zero-length labels. Since a Query contains at label followed by two zero-length labels. Since a Query contains at
most one name, DNS name compression MUST NOT be used. most one name, DNS name compression MUST NOT be used.
4. Message Processing 5. Message Processing
The Querier constructs an ICMP NI Query and sends it to the address 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 from which information is wanted. When the Subject of the Query is
an IPv6 address, that address will normally be used as the IPv6 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 destination address of the Query, but need not be if the Querier has
useful a priori information about the addresses of the target node. 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 An NI Query may also be sent to a multicast address of link-local
scope [2373]. scope [3513].
When the Subject is a name, either fully-qualified or single- When the Subject is a name, either fully-qualified or single-
component, and the Querier does not have a unicast address for the component, and the Querier does not have a unicast address for the
target node, the query MUST be sent to a link-scope multicast target node, the query MUST be sent to a link-scope multicast
address formed in the following way. The Subject Name is converted address formed in the following way. The Subject Name is converted
to the canonical form defined by DNS Security [2535], which is to the canonical form defined by DNS Security [2535], which is
uncompressed with all alphabetic characters in lower case. (If uncompressed with all alphabetic characters in lower case. (If
additional DNS label types for host names are created, the rules for additional DNS label types or character sets for host names are
canonicalizing those labels will be found in their defining defined, the rules for canonicalizing those labels will be found in
specification.) Compute the MD5 hash [1321] of the first label of their defining specification.) Compute the MD5 hash [1321] of the
the Subject Name -- the portion beginning with the first one-octet first label of the Subject Name -- the portion beginning with the
length field and up to, but excluding, any subsequent length field. first one-octet length field and up to, but excluding, any
Append the first 32 bits of that 128-bit hash to the prefix subsequent length field. Append the first 32 bits of that 128-bit
FF02:0:0:0:0:2::/96. The resulting multicast address will be termed hash to the prefix FF02:0:0:0:0:2::/96. The resulting multicast
the "NI Group Address" for the name. address will be termed the "NI Group Address" for the name.
The Nonce should be a random or good pseudo-random value to foil The Nonce should be a random or good pseudo-random value to foil
spoofed replies. An implementation which allows multiple spoofed replies. An implementation which allows multiple
independent processes to send NI queries MAY use the Nonce value to independent processes to send NI queries MAY use the Nonce value to
deliver Replies to the correct process. Nonetheless, such processes deliver Replies to the correct process. Nonetheless, such processes
MUST check the received Nonce and ignore extraneous Replies. MUST check the received Nonce and ignore extraneous Replies.
If true communication security is required, IPsec [2401] must be If true communication security is required, IPsec [2401] must be
used. 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 Upon receiving a NI Query, the Responder must check the Query's IPv6
destination address and discard the Query without further processing destination address and discard the Query without further processing
unless it is one of the Responder's unicast or anycast addresses, or unless it is one of the Responder's unicast or anycast addresses, or
a link-local scope multicast address which the Responder has joined. a link-local scope multicast address which the Responder has joined.
Typically the latter will be a NI Group Address for a name belonging 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 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 Responder is providing proxy service. A node MAY be configurable to
discard NI Queries to multicast addresses other than its NI Group discard NI Queries to multicast addresses other than its NI Group
Address(es) but if so, the default configuration MUST be not to Address(es) but if so, the default configuration MUST be not to
skipping to change at page 6, line 6 skipping to change at page 6, line 39
Address, unless that address was an anycast or a multicast address. Address, unless that address was an anycast or a multicast address.
If the Queried Address was anycast or multicast, the source 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 for the Reply SHOULD be one belonging to the interface on which the
Query was received. Query was received.
If the Query was sent to an anycast or multicast address, If the Query was sent to an anycast or multicast address,
transmission of the Reply MUST be delayed by a random interval transmission of the Reply MUST be delayed by a random interval
between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor
Discovery [2461]. Discovery [2461].
5. Defined Qtypes 6. Defined Qtypes
The following five Qtypes are defined. The first four (number 0 to The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be
3) MUST be supported by any implementation of this protocol. The supported by any implementation of this protocol. Qtype 4 SHOULD be
last one SHOULD be supported by any implementation on an IPv4/IPv6 supported by any implementation of this protocol on an IPv4/IPv6
dual-stack node and MAY be supported on an IPv6-only node. dual-stack node and MAY be supported on an IPv6-only node.
0 NOOP. 0 NOOP.
1 Supported Qtypes. 1 (unused)
2 Node Name. 2 Node Name.
3 Node Addresses. 3 Node Addresses.
4 IPv4 Addresses. 4 IPv4 Addresses.
5.1. NOOP 6.1. NOOP
This NI type has no defined flags and never has a Data field. A 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 Reply to a NI NOOP Query tells the Querier that a node with the
Queried Address is up and reachable, implements the Node Information Queried Address is up and reachable, implements the Node Information
protocol, and incidentally happens to reveal whether the Queried protocol, and incidentally happens to reveal whether the Queried
Address was an anycast address. On transmission, the ICMPv6 Code in 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 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. 0. On reception of a NOOP Query or Reply, the Code must be ignored.
5.2. Supported Qtypes 6.2. Node Name
This Query contains no Data field. The Reply Data 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 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 mandatory Qtypes defined in this
specification. Thus the Data field of a NI Supported Qtypes Reply
from a Responder implementing only the mandatory Qtypes 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 following the included 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=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 compressed form
MAY be used in a Reply only if the Query had the 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 or save significant space in the Reply.
5.3. Node Name
The NI Node Name Query requests the fully-qualified or single- The NI Node Name Query requests the fully-qualified or single-
component name corresponding to the Subject Address or Name. The component name corresponding to the Subject Address or Name. The
Reply Data has the following format. Reply Data has the following format.
0 1 2 3 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 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 | | TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Names ... | | Node Names ... |
+ + + +
/ / / /
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TTL The number of seconds that the name may be cached. For TTL MUST be zero. Any non-zero value received MUST be
compatibility with DNS [1035], this is a 32-bit signed, treated as zero.
2's-complement number, which must not be negative.
Node Names The fully-qualified or single-component name or names of Node Names The fully-qualified or single-component name or names of
the Responder which correspond(s) to the Subject Address the Responder which correspond(s) to the Subject Address
or Name, in DNS wire format [1035]. Each name MUST be or Name, in DNS wire format [1035]. Each name MUST be
fully-qualified if the responder knows the domain fully-qualified if the responder knows the domain
suffix, and otherwise be a single DNS label followed by suffix, and otherwise be a single DNS label followed by
two zero-length labels. two zero-length labels.
When multiple node names are returned and more than one When multiple node names are returned and more than one
of them is fully-qualified, DNS name compression [1035] of them is fully-qualified, DNS name compression [1035]
SHOULD be used, and the offsets are counted from the SHOULD be used, and the offsets are counted from the
first octet of the Data field. An offset of 4, for first octet of the Data field. An offset of 4, for
example, will point to the beginning of the first name. example, will point to the beginning of the first name.
The Responder must fill in the TTL field of the Reply with a The Responder must fill in the TTL field of the Reply with zero.
meaningful value if possible. That value should be one of the
following.
The remaining lifetime of a DHCP lease on the Subject Address;
The remaining Valid Lifetime of a prefix from which the Subject
Address was derived through Stateless Autoconfiguration [2461,
2462];
The TTL of an existing AAAA or A6 record which associates the
Subject Address with the Node Name being returned.
If the Responder returns multiple names but considers one name to be
official or canonical, that name MUST be placed immediately after
the TTL.
Only one TTL is included in the reply. If the Responder considers Only one TTL is included in the reply.
different names to be cacheable for different times, the TTL field
must be set no larger than the minimum of those times. In any case,
the TTL returned MUST be no greater than 2^31-1, even if the
responding node's conception of the lifetime is longer (or
infinite).
If the Responder does not know its name at all it MUST send a 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 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 refusal to answer). The Querier will be able to determine from the
packet length that the Data field contains no names. packet length that the Data field contains no names.
One Flag bit is defined, in the Reply only. 6.3. Node Addresses
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=2 | unused |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A T-flag set to 1 in a NI Node Name Reply indicates that the TTL
field contains a meaningful value. If the T-flag is 0, the TTL
SHOULD be set to zero by the Responder and 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 a NI Node Name 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 Node Name 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 records that match a received NI Node Name
Reply. This might be done to obtain a TTL to make the Reply
cacheable or in anticipation of such a DNS query from the client
that caused the Node Name Query.
5.3.1. Discussion
Because a node can only answer a Node Name 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 Node Name 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 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 unicast addresses. The Reply Data is a sequence of 128-bit
IPv6 addresses, each address preceded by separate a 32-bit TTL IPv6 addresses, each address preceded by separate a 32-bit TTL
value, with Preferred addresses listed before Deprecated addresses value, with Preferred addresses listed before Deprecated addresses
[2461], but otherwise in no special order. Five flag bits are [2461], but otherwise in no special order. Five flag bits are
defined in the Query, and six in the Reply. defined in the Query, and six in the Reply.
0 1 2 3 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 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| | Qtype=3 | unused |G|S|L|C|A|T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
G If set to 1, Global-scope addresses [2374] are requested. G If set to 1, Global-scope addresses [2374] are requested.
S If set to 1, Site-local 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. L If set to 1, Link-local addresses [2374] are requested.
C If set to 1, IPv4-compatible and IPv4-mapped addresses [2373] C If set to 1, IPv4-compatible and IPv4-mapped addresses [3513]
are requested. are requested.
A If set to 1, all the Responder's unicast addresses (of the A If set to 1, all the Responder's unicast addresses (of the
specified scope(s)) are requested. If 0, only those addresses specified scope(s)) are requested. If 0, only those addresses
are requested which belong to the interface (or any one are requested which belong to the interface (or any one
interface) which has the Subject Address, or which are interface) which has the Subject Address, or which are
associated with the Subject Name. associated with the Subject Name.
T Defined in a Reply only, indicates that the set of addresses is T Defined in a Reply only, indicates that the set of addresses is
incomplete for space reasons. incomplete for space reasons.
Flags G, S, L, C and A are copied from a Query to the corresponding Flags G, S, L, C and A are copied from a Query to the corresponding
Reply. Reply.
The TTL associated with each address are to be determined by the The TTL associated with each address MUST be zero.
rules in section 5.3, applied to the returned address rather than
the Subject. If no meaningful caching time can be given for an
address, the corresponding TTL field MUST be zero.
Each address with non-zero TTL in a NI Node Address Reply may be
cached and used for the period indicated by that TTL. If the TTL is
zero, the corresponding address 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.
IPv4-mapped addresses can only be returned by a Node Information IPv4-mapped addresses can only be returned by a Node Information
proxy, since they represent addresses of IPv4-only nodes, which proxy, since they represent addresses of IPv4-only nodes, which
perforce do not implement this protocol. perforce do not implement this protocol.
5.5. IPv4 Addresses 6.4. IPv4 Addresses
The NI IPv4 Addresses Query requests some set of the Responder's 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 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 addresses, each address preceded by a 32-bit TTL value. One flag
bit is defined in the Query, and two in the Reply. bit is defined in the Query, and two in the Reply.
0 1 2 3 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 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| | Qtype=4 | unused |A|T|
skipping to change at page 12, line 7 skipping to change at page 9, line 35
A If set to 1, all the Responder's unicast addresses are A If set to 1, all the Responder's unicast addresses are
requested. If 0, only those addresses are requested which requested. If 0, only those addresses are requested which
belong to the interface (or any one interface) which has the belong to the interface (or any one interface) which has the
Subject Address. Subject Address.
T Defined in a Reply only, indicates that the set of addresses is T Defined in a Reply only, indicates that the set of addresses is
incomplete for space reasons. incomplete for space reasons.
Flag A is copied from a Query to the corresponding Reply. Flag A is copied from a Query to the corresponding Reply.
The TTL associated with each address are to be determined by the The TTL associated with each address MUST be zero.
rules in section 5.3, applied to the returned address rather than
the Subject, excluding the autoconfiguration Valid Lifetime. If no
meaningful caching time can be given for an address, the
corresponding TTL field MUST be zero.
Each address with non-zero TTL in a NI IPv4 Address Reply may be
cached and used for the period indicated by that TTL. If the TTL is
zero, the corresponding address 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.
5.5.1. Discussion 6.4.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. 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 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, are to be defined by IETF
Consensus.
Qtypes 5 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 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 5 as a destination for IPv6 Node Information Queries is
requested. requested.
8. Security Considerations 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 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 [3513] addresses.
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
who can eavesdrop the Query or the Reply. who can eavesdrop the Query or the Reply.
In a large Internet with relatively frequent renumbering, the The information learned via this protocol SHOULD not be trusted for
maintenance of of KEY and SIG records [2535] in the zones used for making security relevant decisions unless some other mechanisms
address-to-name translations will be no easier than the maintenance beyond the scope of this document is used to authenticate this
of the NS, SOA and PTR records themselves, which already appears to information.
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
index.
9. 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. Bob Hinden kindly edited this document to make it
more palatable to the IESG.
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.
10. 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.
skipping to change at page 14, line 41 skipping to change at page 11, line 27
[1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, [1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April
1995. 1995.
[2119] S. Bradner, "Key words for use in RFCs to Indicate [2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997. Requirement Levels," RFC 2119, March 1997.
[2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 Aggregatable
Architecture", RFC 2373, July 1998. Global Unicast Address Format", RFC 2374. July 1998.
[2401] Kent, S. and R. Atkinson, "Security Architecture for the [2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an [2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October 1998. IANA Considerations Section in RFCs", RFC 2434, October 1998.
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. 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 [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.
[3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003.
[KAME] KAME Project, http://www.kame.net/. [KAME] KAME Project, http://www.kame.net/.
11. Author's Address 11. Author's Address
Matt Crawford Matt Crawford
Fermilab MS 368 Fermilab MS 369
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/