draft-ietf-ipngwg-icmp-name-lookups-12.txt   draft-ietf-ipngwg-icmp-name-lookups-13.txt 
IPv6 WG M. Crawford IPv6 WG M. Crawford
Internet-Draft Fermilab Internet-Draft Fermilab
Expires: January 13, 2006 B. Haberman, Ed. Expires: July 7, 2006 B. Haberman, Ed.
JHU APL JHU APL
July 12, 2005 January 3, 2006
IPv6 Node Information Queries IPv6 Node Information Queries
draft-ietf-ipngwg-icmp-name-lookups-12 draft-ietf-ipngwg-icmp-name-lookups-13
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2006. This Internet-Draft will expire on July 7, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Node Information Messages . . . . . . . . . . . . . . . . . . 4 4. Node Information Messages . . . . . . . . . . . . . . . . . . 4
5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 6 5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 6
6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Node Name . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Node Name . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3 Node Addresses . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Node Addresses . . . . . . . . . . . . . . . . . . . . . . 9
6.4 IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10 6.4. IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10
6.4.1 Discussion . . . . . . . . . . . . . . . . . . . . . . 10 6.4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
10.2 Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies a mechanism for discovering information about This document specifies a mechanism for discovering information about
names and addresses. The applicability of these mechanics is names and addresses. The applicability of these mechanisms is
currently limited to diagnostic and debugging tools and network currently limited to diagnostic and debugging tools and network
management (e.g. node discovery). In the global internet, the Domain management (e.g. node discovery). In the global internet, the Domain
Name System[1][2] is the authoritative source of such information and Name System[1][2] is the authoritative source of such information and
this specification is not intended to supplant or supersede it. And this specification is not intended to supplant or supersede it. And
in fact, in a well-supported network, the names and addresses dealt 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 with by this mechanism will be the same ones, and with the same
relationships, as those listed in the DNS. 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
skipping to change at page 3, line 30 skipping to change at page 3, line 30
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 unique-local addresses [3] debugging, or in regard to link-local and unique-local addresses [3]
which often will not be listed in the DNS. which often will not be listed in the DNS.
2. Applicability Statement 2. Applicability Statement
IPv6 Node Information Queries include the capability to provide IPv6 Node Information Queries include the capability to provide
forward and reverse name lookups independent of the DNS by sending forward and reverse name lookups independent of the DNS by sending
packets directly to IPv6 nodes or groups of nodes. packets directly to IPv6 nodes or groups of nodes.
The applicability of these mechanics is currently limited to The applicability of these mechanisms is currently limited to
diagnostic and debugging tools and network management (e.g. node diagnostic and debugging tools and network management (e.g. node
discovery). These mechanisms can be used to learn the addresses and 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 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 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 debugging problems or when bringing up IPv6 service where there isn't
global routing or DNS name services available. IPv6's large auto- global routing or DNS name services available. IPv6's large auto-
configured addresses make debugging network problems and bringing up configured addresses make debugging network problems and bringing up
IPv6 service difficult without these mechanisms. An example of an IPv6 service difficult without these mechanisms. An example of an
IPv6 debugging tool using IPv6 Node Information Queries is the ping6 IPv6 debugging tool using IPv6 Node Information Queries is the ping6
program in the KAME (<http://www.kame.net>), USAGI, and other IPv6 program in the KAME (<http://www.kame.net>), USAGI, and other IPv6
implementations. implementations.
The mechanisms defined in this document may have wider applicability The mechanisms defined in this document may have wider applicability
in the future (for example, name lookups in zero configuration in the future, but any use beyond debugging and diagnostic tools is
networks, global reverse name lookups, etc.), but any use beyond left for further study and is beyond the scope of this document.
debugging and diagnostic tools is left for further study and is
beyond the scope of this document.
3. Terminology 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 may "Queried Address." The Query concerns a "Subject Address" (which may
differ from the Queried Address and may be an IPv6 or IPv4 address) differ from the Queried Address and may be an IPv6 or IPv4 address)
or a "Subject Name". The Responder sends a "Node Information Reply" or a "Subject Name". The Responder sends a "Node Information Reply"
to the Querier, containing information associated with the node at to the Querier, containing information associated with the node at
the Queried Address. A node receiving an NI Query will be termed a the Queried Address. A node receiving an NI Query will be termed a
Responder even if it does not send a reply. Responder even if it does not send a reply.
The word "name" in this document refers to a hostname with or without The word "name" in this document refers to a hostname with or without
the domain. Where necessary, the cases of fully-qalified and single- the domain. Where necessary, the cases of fully-qualified and
label names will be distinguished. 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 [4]. document are to be interpreted as described in [4].
Packet fields marked "unused" must be zero on transmission and, aside Packet fields marked "unused" must be zero on transmission and, aside
from inclusion in checksums or message integrity checks, ignored on from inclusion in checksums or message integrity checks, ignored on
reception. reception.
4. Node Information Messages 4. Node Information Messages
skipping to change at page 4, line 44 skipping to change at page 4, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Nonce + + Nonce +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Data / / Data /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Node Information Messages
Fields: Fields:
o Type o Type
* 139 - NI Query * 139 - NI Query
* 140 - NI Reply * 140 - NI Reply
o Code o Code
* For NI Query * For NI Query
+ 0 - Indicates that the Data field contains an IPv6 address + 0 - Indicates that the Data field contains an IPv6 address
which is the Subject of this Query. which is the Subject of this Query.
+ 1 - Indicates that the Data field contains a name which is + 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 the Subject of this Query, or is empty, as in the case of a
NOOP or Supported Qtypes query. NOOP.
+ 2 - Indicates that the Data field contains an IPv4 address + 2 - Indicates that the Data field contains an IPv4 address
which is the Subject of this Query. which is the Subject of this Query.
* For NI Reply * For NI Reply
+ 0 - Indicates a successful reply. The Reply Data field may + 0 - Indicates a successful reply. The Reply Data field may
or may not be empty. or may not be empty.
+ 1 - Indicates that the Responder refuses to supply the + 1 - Indicates that the Responder refuses to supply the
skipping to change at page 6, line 34 skipping to change at page 6, line 40
scope [3]. scope [3].
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 address 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 formed in the following way. The Subject Name is converted to the
canonical form defined by DNS Security [6], which is uncompressed canonical form defined by DNS Security [6], which is uncompressed
with all alphabetic characters in lower case. (If additional DNS with all alphabetic characters in lower case. (If additional DNS
label types or character sets for host names are defined, the rules label types or character sets for host names are defined, the rules
for canonicalizing those labels will be found in their defining for canonicalizing those labels will be found in their defining
specification.) Compute the MD5 hash [11] of the first label of the specification.) Compute the MD5 hash [7] of the first label of the
Subject Name -- the portion beginning with the first one-octet length Subject Name -- the portion beginning with the first one-octet length
field and up to, but excluding, any subsequent length field. Append 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: the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0:2:
2::/96. The resulting multicast address will be termed the "NI Group FF::/104. The resulting multicast address will be termed the "NI
Address" for the name. A node will support an "NI Group Address" for Group Address" for the name. A node will support an "NI Group
each associated Subject Name. Address" for each associated Subject Name.
The Nonce should be a random or good pseudo-random value to foil The Nonce MUST be a random or good pseudo-random value to foil
spoofed replies. An implementation which allows multiple independent spoofed replies. An implementation which allows multiple independent
processes to send NI queries MAY use the Nonce value to deliver processes to send NI queries MAY use the Nonce value to deliver
Replies to the correct process. Nonetheless, such processes MUST Replies to the correct process. Nonetheless, such processes MUST
check the received Nonce and ignore extraneous Replies. check the received Nonce and ignore extraneous Replies.
If true communication security is required, IPsec [12] MUST be used. If true communication security is required, IPsec [13] should be
Providing the infrastructure to authenticate NI Queries and Replies used. Providing the infrastructure to authenticate NI Queries and
may be quite difficult outside of a well-defined community. Replies may be quite difficult outside of a well-defined community.
Upon receiving an NI Query, the Responder must check the Query's IPv6 Upon receiving an 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 an NI Group Address for a name belonging 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 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, multicast addresses other than its NI Group Address(es) but if so,
the default configuration MUST be not to discard them. the default configuration 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 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- or Name (in the Data field) does not belong to that node. A single-
component Subject Name matches any fully-qualified name whose first component Subject Name matches any fully-qualified name whose first
label matches the Subject. All name matching is done in a case- label matches the Subject. All name matching is done in a case-
independent manner consistent with DNSSEC name canonicalization [6]. independent manner consistent with DNSSEC name canonicalization [6].
Next, if Qtype is unknown to the Responder, it must return an NI 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 Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should
rate-limit such replies as it would ICMPv6 error replies [5]. rate-limit such replies as it would ICMPv6 error replies [5].
Next, the Responder should decide whether to refuse an answer, based Next, the Responder should decide whether to refuse an answer, based
on local policy. (See "Security Considerations" for recommended on local policy. (See "Security Considerations" for recommended
default behavior.) If an answer is refused, the Responder may send default behavior.) If an answer is refused, depending on local
policy the Responder can elect to silently discard the query or send
an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the an NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the
Responder should rate-limit such replies as it would ICMPv6 error Responder should rate-limit such replies as it would ICMPv6 error
replies [5]. replies [5].
Finally, if the Qtype is known and the response is allowed by local 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 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 Reply in accordance with the definition of the Qtype and transmit the
NI Reply. The source address of the NI Reply SHOULD be selected NI Reply. The source address of the NI Reply SHOULD be selected
using the rules defined in [7]. using the rules defined in [8].
If the Query was sent to a multicast address, transmission of the If the Query was sent to a multicast address, transmission of the
Reply MUST be delayed by a random interval between zero and Reply MUST be delayed by a random interval between zero and
MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [8]. MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor Discovery [9].
6. Defined Qtypes 6. Defined Qtypes
The following Qtypes are defined. Qtypes 0, 2, and 3 MUST be 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. Qtype 4 SHOULD be
supported by any implementation of this protocol 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.
+-------------+----------------+ +-------------+----------------+
| Qtype Value | Qtype Name | | Qtype Value | Qtype Name |
+-------------+----------------+ +-------------+----------------+
| 0 | NOOP | | 0 | NOOP |
| 1 | unused | | 1 | unused |
| 2 | Node Name | | 2 | Node Name |
| 3 | Node Addresses | | 3 | Node Addresses |
| 4 | IPv4 Addresses | | 4 | IPv4 Addresses |
+-------------+----------------+ +-------------+----------------+
6.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 an NI NOOP Query tells the Querier that a node with the Reply to an 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 and implements the Node
protocol, and incidentally happens to reveal whether the Queried Information protocol. On transmission, the ICMPv6 Code in a NOOP
Address was an anycast address. On transmission, the ICMPv6 Code in Query must be set to 1 and the Code in a NOOP Reply must be 0. On
a NOOP Query must be set to 1 and the Code in a NOOP Reply must be 0. reception of a NOOP Query or Reply, the Code must be ignored.
On reception of a NOOP Query or Reply, the Code must be ignored.
6.2 Node Name 6.2. 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 ... |
+ + + +
/ / / /
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Node Information Reply Message
o TTL - MUST be zero. Any non-zero value received MUST be treated 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 as zero. This field is no longer used but is present to preserve
backwards compatibility with older implementations. backwards compatibility with older implementations.
o Node Names - The fully-qualified or single-component name or names o Node Names - The fully-qualified or single-component name or names
of the Responder which correspond(s) to the Subject Address or of the Responder which correspond(s) to the Subject Address or
Name, in DNS wire format [2]. Each name MUST be fully-qualified Name, in DNS wire format, Section 3.1 of [2]. Each name MUST be
if the responder knows the domain suffix, and otherwise be a fully-qualified if the responder knows the domain suffix, and
single DNS label followed by two zero-length labels. When otherwise be a single DNS label followed by two zero-length
multiple node names are returned and more than one of them is labels. When multiple node names are returned and more than one
fully-qualified, DNS name compression [2] SHOULD be used, and the of them is fully-qualified, DNS name compression, Section 4.1.4 of
offsets are counted from the first octet of the Data field. An [2], SHOULD be used, and the offsets are counted from the first
offset of 4, for example, will point to the beginning of the first octet of the Data field. An offset of 4, for example, will point
name. to the beginning of the first name.
The Responder must fill in the TTL field of the Reply with zero. The Responder must fill in the TTL field of the Reply with zero.
Only one TTL is included in the reply. Only one TTL is included in the reply.
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.
6.3 Node Addresses 6.3. Node Addresses
The NI Node Addresses Query requests some set of the Responder's IPv6 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 a separate 32-bit TTL value, with addresses, each address preceded by a separate 32-bit TTL value, with
Preferred addresses listed before Deprecated addresses [8], but Preferred addresses listed before Deprecated addresses [9], but
otherwise in no special order. Five flag bits are defined in the otherwise in no special order. Five flag bits are defined in the
Query, and six in the Reply. 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o G - If set to 1, Global-scope addresses [9] are requested. Figure 3: Node Information Address Query
o S - If set to 1, Site-local addresses [9] are requested. However, o G - If set to 1, Global-scope addresses [10] are requested.
Site-local addresses are now deprecated [13] and this flag is for
backwards compatibility.
o L - If set to 1, Link-local addresses [9] are requested. o S - If set to 1, Site-local addresses [10] are requested.
However, Site-local addresses are now deprecated [14] and this
flag is for backwards compatibility.
o L - If set to 1, Link-local addresses [10] are requested.
o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are
requested. As the IPv4-compatible addresses are now deprecated, requested. As the IPv4-compatible addresses are now deprecated,
this flag is for backwards compatibility with older this flag is for backwards compatibility with older
implementations, implementations,
o A - If set to 1, all the Responder's unicast addresses (of the 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 specified scope(s)) are requested. If 0, only those addresses are
requested which belong to the interface (or any one interface) requested which belong to the interface (or any one interface)
which has the Subject Address, or which are associated with the which has the Subject Address, or which are associated with the
Subject Name. Subject Name.
o T Defined in a Reply only, indicates that the set of addresses is o 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 MUST be zero. The TTL associated with each address MUST be zero.
6.4 IPv4 Addresses 6.4. IPv4 Addresses
The NI IPv4 Addresses Query requests some set of the Responder's IPv4 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 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 addresses, each address preceded by a 32-bit TTL value. One flag bit
is defined in the Query, and two in the Reply. 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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Node Information IPv4 Address Query
o A - If set to 1, all the Responder's unicast addresses are o A - If set to 1, all the Responder's unicast addresses are
requested. If 0, only those addresses are requested which belong requested. If 0, only those addresses are requested which belong
to the interface (or any one interface) which has the Subject to the interface (or any one interface) which has the Subject
Address. Address.
o T Defined in a Reply only, indicates that the set of addresses is o 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 MUST be zero. The TTL associated with each address MUST be zero.
6.4.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 same interfaces as distinct, even though they are associated with the same
hardware. When such a node is responding to an NI Query having a 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 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 has the A flag set to 0, it SHOULD consider IP interfaces, other than
tunnels, associated with the same hardware as being the same tunnels, associated with the same hardware as being the same
interface. interface.
7. IANA Considerations 7. IANA Considerations
ICMPv6 type values 139 and 140 were previously assigned by IANA for ICMPv6 type values 139 and 140 were previously assigned by IANA for
this protocol. This document defines three values of the ICMPv6 Code this 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 [14]. may be defined 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. This document defines five values of Qtype, numbers 0 through 4.
Following the policies outlined in [14], new values, and their Following the policies outlined in [15], new values, and their
associated Flags and Reply Data, are to be defined by IETF Consensus. 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: The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0:
0:2::/96 for use in Node Information Queries as defined in Section 5. 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 8. Security Considerations
This protocol shares the security issues of ICMPv6 that are This protocol shares the security issues of ICMPv6 that are
documented in the "Security Considerations" section of [5]. documented in the "Security Considerations" section of [5].
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 MUST have a
default configuration which refuses to answer queries from global- default configuration which refuses to answer queries from global-
scope [3] addresses. scope [3] 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.
The information learned via this protocol SHOULD not be trusted for The information learned via this protocol SHOULD not be trusted for
making security relevant decisions unless some other mechanisms making security relevant decisions unless some other mechanisms
beyond the scope of this document is used to authenticate this beyond the scope of this document is used to authenticate this
information. information.
An implementation of this protocol SHOULD provide the ability to An implementation of this protocol SHOULD provide the ability to
control the dissemination of information related to IPv6 Privacy control the dissemination of information related to IPv6 Privacy
Addresses [15]. The default action of this policy SHOULD NOT provide Addresses [17]. The default action of this policy SHOULD NOT provide
a reponse to a Query that contains a node's Privacy Addresses. a reponse to a Query that contains a node's Privacy Addresses.
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. Bob Hinden and Brian Haberman have acted as Keith Moore, Elwyn Davies, and Pekka Savola. Bob Hinden and Brian
document editors during the IETF advancement process. Haberman have acted as document editors during the IETF advancement
process.
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 briefly for address-to-name translation. The idea had been discussed briefly
in the IPng working group and RFC 1788 [16] describes such a in the IPng working group and RFC 1788 [18] describes such a
mechanism for IPv4. mechanism for IPv4.
10. References 10. References
10.1 Normative References 10.1. Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", [1] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in Architecture", draft-ietf-ipv6-addr-arch-v4-04 (work in
progress), May 2005. progress), May 2005.
skipping to change at page 12, line 30 skipping to change at page 13, line 6
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[5] Conta, A. and S. Deering, "Internet Control Message Protocol [5] 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.
[6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"Resource Records for the DNS Security Extensions", RFC 4034, "Resource Records for the DNS Security Extensions", RFC 4034,
March 2005. March 2005.
[7] Draves, R., "Default Address Selection for Internet Protocol [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. version 6 (IPv6)", RFC 3484, February 2003.
[8] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery [9] 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.
[9] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast [10] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast
Address Format", RFC 2374, July 1998. Address Format", RFC 2374, July 1998.
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [11] Conta, A., "Internet Control Message Protocol (ICMPv6) for the
Specification", RFC 2460, December 1998. Internet Protocol Version 6 (IPv6) Specification",
draft-ietf-ipngwg-icmp-v3-07 (work in progress), July 2005.
10.2 Informative References [12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[11] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 10.2. Informative References
April 1992.
[12] Kent, S. and R. Atkinson, "Security Architecture for the [13] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[13] Huitema, C. and B. Carpenter, "Deprecating Site Local [14] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004. Addresses", RFC 3879, September 2004.
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[15] Narten, T. and R. Draves, "Privacy Extensions for Stateless [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. Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[16] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. [18] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995.
Authors' Addresses Authors' Addresses
Matt Crawford Matt Crawford
Fermilab Fermilab
PO Box 500 PO Box 500
Batavia, IL 60510 Batavia, IL 60510
US US
Phone: +1 630 840 3461 Phone: +1 630 840 3461
skipping to change at page 14, line 41 skipping to change at page 15, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 56 change blocks. 
89 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/