draft-ietf-ipngwg-icmp-name-lookups-10.txt | draft-ietf-ipngwg-icmp-name-lookups-11.txt | |||
---|---|---|---|---|
IPng Working Group Matt Crawford | IPv6 WG M. Crawford | |||
Internet Draft Fermilab | Internet-Draft Fermilab | |||
June 26, 2003 | Expires: November 6, 2005 B. Haberman, Ed. | |||
JHU APL | ||||
May 5, 2005 | ||||
IPv6 Node Information Queries | IPv6 Node Information Queries | |||
<draft-ietf-ipngwg-icmp-name-lookups-10.txt> | draft-ietf-ipngwg-icmp-name-lookups-11 | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | By submitting this Internet-Draft, each author represents that any | |||
all provisions of Section 10 of RFC2026. Internet-Drafts are | applicable patent or other IPR claims of which he or she is aware | |||
working documents of the Internet Engineering Task Force (IETF), its | have been or will be disclosed, and any of which he or she becomes | |||
areas, and its working groups. Note that other groups may also | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
distribute working documents as Internet-Drafts. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are working documents of the Internet Engineering | |||
months and may be updated, replaced, or obsoleted by other documents | Task Force (IETF), its areas, and its working groups. Note that | |||
at any time. It is inappropriate to use Internet- Drafts as | other groups may also distribute working documents as Internet- | |||
reference material or to cite them other than as "work in progress." | Drafts. | |||
To view the list Internet-Draft Shadow Directories, see | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | ||||
time. It is inappropriate to use Internet-Drafts as reference | ||||
material or to cite them other than as "work in progress." | ||||
The list of current Internet-Drafts can be accessed at | ||||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
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 November 6, 2005. | ||||
Copyright Notice | ||||
Copyright (C) The Internet Society (2005). | ||||
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 | ||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 | ||||
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | ||||
4. Node Information Messages . . . . . . . . . . . . . . . . . . 4 | ||||
5. Message Processing . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
6. Defined Qtypes . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
6.1 NOOP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
6.2 Node Name . . . . . . . . . . . . . . . . . . . . . . . . 8 | ||||
6.3 Node Addresses . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
6.4 IPv4 Addresses . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
6.4.1 Discussion . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | ||||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
10.1 Normative References . . . . . . . . . . . . . . . . . . . 12 | ||||
10.2 Informative References . . . . . . . . . . . . . . . . . . 12 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
Intellectual Property and Copyright Statements . . . . . . . . 14 | ||||
1. Introduction | 1. Introduction | |||
This document specifies a mechanism for discovering information | This document specifies a mechanism for discovering information about | |||
about names and addresses. The applicability of these mechanics is | names and addresses. The applicability of these mechanics is | |||
currently limited to diagnostic and debugging tools. In the global | currently limited to diagnostic and debugging tools. In the global | |||
internet, the Domain Name System [1034, 1035] is the authoritative | internet, the Domain Name System[1][2] is the authoritative source of | |||
source of such information and this specification is not intended to | such information and this specification is not intended to supplant | |||
supplant or supersede it. And in fact, in a well-supported network | or supersede it. And in fact, in a well-supported network the names | |||
the names and addresses dealt with by this mechanism will be the | and addresses dealt with by this mechanism will be the same ones, and | |||
same ones, and with the same relationships, as those listed in the | with the same relationships, as those listed in the DNS. | |||
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 unique-local addresses [3] | |||
[3513] 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 mechanics is currently limited to | |||
diagnostic and debugging tools. These mechanisms can be used to | diagnostic and debugging tools. These mechanisms can be used to | |||
learn the addresses and names for nodes on the other end of a | learn the addresses and names for nodes on the other end of a point- | |||
point-to-point link or nodes on a shared-medium link such as an | to-point link or nodes on a shared-medium link such as an Ethernet. | |||
Ethernet. This is very useful when debugging problems or when | This is very useful when debugging problems or when bringing up IPv6 | |||
bringing up IPv6 service where there isn't global routing or DNS | service where there isn't global routing or DNS name services | |||
name services available. IPv6's large auto-configured addresses | available. IPv6's large auto-configured addresses make debugging | |||
make debugging network problems and bringing up IPv6 service | network problems and bringing up IPv6 service difficult without these | |||
difficult without these mechanisms. An example of a IPv6 debugging | mechanisms. An example of a IPv6 debugging tool using IPv6 Node | |||
tool using IPv6 Node Information Queries is the ping6 program in the | Information Queries is the ping6 program in the KAME, USAGI, and | |||
KAME, USAGI, and other IPv6 implementations [KAME]. | other IPv6 implementations <http://www.kame.net>. | |||
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 (for example, name lookups in zero configuration | |||
networks, global reverse name lookups, etc.), but any use beyond | networks, global reverse name lookups, etc.), but any use beyond | |||
debugging and diagnostic tools is left for further study and is | debugging and diagnostic tools is left for further study and is | |||
beyond the scope of this document. | 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 | "Queried Address." The Query concerns a "Subject Address" (which may | |||
may differ from the Queried Address) or a "Subject Name". The | differ from the Queried Address) or a "Subject Name". The Responder | |||
Responder sends a "Node Information Reply" to the Querier, | sends a "Node Information Reply" to the Querier, containing | |||
containing information associated with the node at the Queried | information associated with the node at the Queried Address. A node | |||
Address. A node receiving a NI Query will be termed a Responder | receiving a NI Query will be termed a Responder even if it does not | |||
even if it does not send a reply. | send a reply. | |||
The word "name" in this document refers to a hostname with or | The word "name" in this document refers to a hostname with or without | |||
without the domain. Where necessary, the cases of fully-qalified | the domain. Where necessary, the cases of fully-qalified and single- | |||
and single-label names will be distinguished. | 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 [4]. | |||
Packet fields marked "unused" must be zero on transmission and, | Packet fields marked "unused" must be zero on transmission and, aside | |||
aside from inclusion in checksums or message integrity checks, | from inclusion in checksums or message integrity checks, ignored on | |||
ignored on reception. | reception. | |||
4. 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 [5] 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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Qtype | Flags | | | Qtype | Flags | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+ Nonce + | + Nonce + | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
/ Data / | / Data / | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Fields: | Fields: | |||
Type 139 - NI Query. | o Type | |||
140 - NI Reply. | ||||
Code For NI Query: | * 139 - NI Query | |||
0 Indicates that the Data field contains an IPv6 | * 140 - NI Reply | |||
address which is the Subject of this Query. | o Code | |||
1 Indicates that the Data field contains a name which | * For NI Query | |||
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 | + 0 - Indicates that the Data field contains an IPv6 address | |||
address which is the Subject of this Query. | which is the Subject of this Query. | |||
For NI Reply: | + 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. | ||||
0 Indicates a successful reply. The Reply Data field | + 2 - Indicates that the Data field contains an IPv4 address | |||
may or may not be empty. | which is the Subject of this Query. | |||
1 Indicates that the Responder refuses to supply the | * 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. | answer. The Reply Data field will be empty. | |||
2 Indicates that the Qtype of the Query is unknown to | + 2 - Indicates that the Qtype of the Query is unknown to the | |||
the Responder. The Reply Data field will be empty. | Responder. The Reply Data field will be empty. | |||
Checksum The ICMPv6 checksum. | o Checksum - The ICMPv6 checksum. | |||
Qtype A 16-bit field which designates the type of information | o Qtype - A 16-bit field which designates the type of information | |||
requested in a Query or supplied in a Reply. Its value | requested in a Query or supplied in a Reply. Its value in a Reply | |||
in a Reply is always copied from the corresponding Query | is always copied from the corresponding Query by the Responder. | |||
by the Responder. Five values of Qtype are specified in | Five values of Qtype are specified in this document. | |||
this document. | ||||
Flags Qtype-specific flags which may be defined for certain | o Flags - Qtype-specific flags which may be defined for certain | |||
Query types and their Replies. Flags not defined for a | Query types and their Replies. Flags not defined for a given | |||
given Qtype must be zero on transmission and ignored on | Qtype must be zero on transmission and ignored on reception, and | |||
reception, and must not be copied from a Query to a | must not be copied from a Query to a Reply unless so specified in | |||
Reply unless so specified in the definition of the | the definition of the Qtype. | |||
Qtype. | ||||
Nonce An opaque 64-bit field to help avoid spoofing and/or to | o Nonce - An opaque 64-bit field to help avoid spoofing and/or to | |||
aid in matching Replies with Queries. Its value in a | aid in matching Replies with Queries. Its value in a Query is | |||
Query is chosen by the Querier. Its value in a Reply is | chosen by the Querier. Its value in a Reply is always copied from | |||
always copied from the corresponding Request by the | the corresponding Request by the Responder. | |||
Responder. | ||||
Data In a Query, the Subject Address or Name. In a Reply, | o Data - In a Query, the Subject Address or Name. In a Reply, | |||
Qtype-specific data present only when the ICMPv6 Code | Qtype-specific data present only when the ICMPv6 Code field is | |||
field is zero. The length of the Data may be inferred | zero. The length of the Data may be inferred from the IPv6 | |||
from the IPv6 header's Payload Length field [2460], the | header's Payload Length field [2460], the length of the fixed | |||
length of the fixed portion of the NI packet and the | portion of the NI packet and the lengths of the ICMPv6 header and | |||
lengths of the ICMPv6 header and intervening extension | intervening extension headers. | |||
headers. | ||||
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 | |||
if any, in the Data field of a Reply is determined by the Qtype. | 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 [2]. The name may be either a fully-qualified domain name, | |||
name, including the terminating zero-length label, or a single DNS | including the terminating zero-length label, or a single DNS label | |||
label followed by two zero-length labels. Since a Query contains at | followed by two zero-length labels. Since a Query contains at most | |||
most one name, DNS name compression MUST NOT be used. | one name, DNS name compression MUST NOT be used. | |||
5. 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 [3513]. | 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 | target node, the query MUST be sent to a link-scope multicast address | |||
address formed in the following way. The Subject Name is converted | formed in the following way. The Subject Name is converted to the | |||
to the canonical form defined by DNS Security [2535], which is | canonical form defined by DNS Security [6], which is uncompressed | |||
uncompressed with all alphabetic characters in lower case. (If | with all alphabetic characters in lower case. (If additional DNS | |||
additional DNS label types or character sets for host names are | label types or character sets for host names are defined, the rules | |||
defined, the rules for canonicalizing those labels will be found in | for canonicalizing those labels will be found in their defining | |||
their defining specification.) Compute the MD5 hash [1321] of the | specification.) Compute the MD5 hash [10] of the first label of the | |||
first label of the Subject Name -- the portion beginning with the | Subject Name -- the portion beginning with the first one-octet length | |||
first one-octet length field and up to, but excluding, any | field and up to, but excluding, any subsequent length field. Append | |||
subsequent length field. Append the first 32 bits of that 128-bit | the first 32 bits of that 128-bit hash to the prefix FF02:0:0:0:0: | |||
hash to the prefix FF02:0:0:0:0:2::/96. The resulting multicast | 2::/96. The resulting multicast address will be termed the "NI Group | |||
address will be termed the "NI Group Address" for the name. | Address" for the name. A node will support an "NI Group Address" for | |||
each associated Subject 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 | |||
independent processes to send NI queries MAY use the Nonce value to | processes to send NI queries MAY use the Nonce value to deliver | |||
deliver Replies to the correct process. Nonetheless, such processes | Replies to the correct process. Nonetheless, such processes MUST | |||
MUST check the received Nonce and ignore extraneous Replies. | 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 [11] must be used. | |||
used. Providing the infrastructure to authenticate NI Queries and | Providing the infrastructure to authenticate NI Queries and Replies | |||
Replies may be quote difficult outside of a well-defined community. | 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 | |||
discard them. | 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, unless it | or Name (in the Data field) does not belong to that node, unless it | |||
is providing proxy service for that Subject. A single-component | is providing proxy service for that Subject. A single-component | |||
Subject Name matches any fully-qualified name whose first label | Subject Name matches any fully-qualified name whose first label | |||
matches the Subject. All name matching is done in a case- | matches the Subject. All name matching is done in a case- | |||
independent manner consistent with DNSSEC name canonicalization | independent manner consistent with DNSSEC name canonicalization [6]. | |||
[2535]. | ||||
Next, if Qtype is unknown to the Responder, it must return a NI | Next, if Qtype is unknown to the Responder, it must return a NI Reply | |||
Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should | with ICMPv6 Code = 2 and no Reply Data. The Responder should rate- | |||
rate-limit such replies as it would ICMPv6 error replies [2463, | limit such replies as it would ICMPv6 error replies [5]. | |||
2.4(f)]. | ||||
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, the Responder may send a | |||
a NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the | 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 [2463, 2.4(f)]. | 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 | policy, the Responder must fill in the Flags and Reply Data of the NI | |||
NI Reply in accordance with the definition of the Qtype and transmit | Reply in accordance with the definition of the Qtype and transmit the | |||
the NI Reply with an ICMPv6 source address equal to the Queried | NI Reply with an ICMPv6 source address equal to the Queried Address, | |||
Address, unless that address was an anycast or a multicast address. | unless that address was an anycast or a multicast address. If the | |||
If the Queried Address was anycast or multicast, the source address | Queried Address was anycast or multicast, the source address for the | |||
for the Reply SHOULD be one belonging to the interface on which the | Reply SHOULD be one belonging to the interface on which the Query was | |||
Query was received. | 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 [7]. | |||
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. | |||
0 NOOP. | +-------------+----------------+ | |||
| Qtype Value | Qtype Name | | ||||
1 (unused) | +-------------+----------------+ | |||
| 0 | NOOP | | ||||
2 Node Name. | | 1 | unused | | |||
| 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 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. | |||
0. On 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 ... | | |||
+ + | + + | |||
/ / | / / | |||
+ + | + + | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
TTL MUST be zero. Any non-zero value received MUST be | o TTL - MUST be zero. Any non-zero value received MUST be treated | |||
treated as zero. | 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 | o Node Names - The fully-qualified or single-component name or names | |||
of them is fully-qualified, DNS name compression [1035] | of the Responder which correspond(s) to the Subject Address or | |||
SHOULD be used, and the offsets are counted from the | Name, in DNS wire format [2]. Each name MUST be fully-qualified | |||
first octet of the Data field. An offset of 4, for | if the responder knows the domain suffix, and otherwise be a | |||
example, will point to the beginning of the first name. | single DNS label followed by two zero-length labels. When | |||
multiple node names are returned and more than one of them is | ||||
fully-qualified, DNS name compression [2] SHOULD be used, and the | ||||
offsets are counted from the first octet of the Data field. An | ||||
offset of 4, for example, will point to the beginning of the first | ||||
name. | ||||
The Responder must fill in the TTL field of the Reply with zero. | 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 | The NI Node Addresses Query requests some set of the Responder's IPv6 | |||
IPv6 unicast addresses. The Reply Data is a sequence of 128-bit | unicast addresses. The Reply Data is a sequence of 128-bit IPv6 | |||
IPv6 addresses, each address preceded by separate a 32-bit TTL | addresses, each address preceded by separate a 32-bit TTL value, with | |||
value, with Preferred addresses listed before Deprecated addresses | Preferred addresses listed before Deprecated addresses [7], but | |||
[2461], but otherwise in no special order. Five flag bits are | otherwise in no special order. Five flag bits are defined in the | |||
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| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
G If set to 1, Global-scope addresses [2374] are requested. | o G - If set to 1, Global-scope addresses [8] are requested. | |||
S If set to 1, Site-local addresses [2374] are requested. | o S - If set to 1, Site-local addresses [8] are requested. | |||
L If set to 1, Link-local addresses [2374] are requested. | o L - If set to 1, Link-local addresses [8] are requested. | |||
C If set to 1, IPv4-compatible and IPv4-mapped addresses [3513] | o C - If set to 1, IPv4-compatible and IPv4-mapped addresses [3] are | |||
are requested. | requested. | |||
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 | specified scope(s)) are requested. If 0, only those addresses are | |||
are requested which belong to the interface (or any one | requested which belong to the interface (or any one interface) | |||
interface) which has the Subject Address, or which are | which has the Subject Address, or which are associated with the | |||
associated with the Subject Name. | Subject Name. | |||
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 | |||
incomplete for space reasons. | is 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. | |||
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. | |||
6.4. 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 | |||
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 | addresses, each address preceded by a 32-bit TTL value. One flag bit | |||
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| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
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 | requested. If 0, only those addresses are requested which belong | |||
belong to the interface (or any one interface) which has the | to the interface (or any one interface) which has the Subject | |||
Subject Address. | Address. | |||
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 | |||
incomplete for space reasons. | is 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 | interfaces as distinct, even though they are associated with the same | |||
same hardware. When such a node is responding to a NI Query having | hardware. When such a node is responding to a NI Query having a | |||
a Subject Address of one type requesting the other type, and the | Subject Address of one type requesting the other type, and the Query | |||
Query has the A flag set to 0, it SHOULD consider IP interfaces, | has the A flag set to 0, it SHOULD consider IP interfaces, other than | |||
other than tunnels, associated with the same hardware as being the | tunnels, associated with the same hardware as being the same | |||
same interface. | interface. | |||
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 were previously assigned by IANA for | |||
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 [2434]. | may be defined only by IETF Consensus [12]. | |||
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 [12], new values, and their | |||
Considerations Section in RFCs" [2434], 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. | ||||
Assignment of the multicast address prefix FF02:0:0:0:0:2::/96 used | The IANA is requested to assign the IPv6 multicast prefix FF02:0:0:0: | |||
in section 5 as a destination for IPv6 Node Information Queries is | 0:2::/96 for use in Node Information Queries as defined in section | |||
requested. | Section 5. | |||
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 [2463]. | 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 SHOULD have a | |||
default configuration which refuses to answer queries from global- | default configuration which refuses to answer queries from global- | |||
scope [3513] 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 | ||||
control the dissemination of information related to IPv6 Privacy | ||||
Addresses [13]. The default action of this policy SHOULD NOT provide | ||||
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 kindly edited this document to make it | and Keith Moore. Bob Hinden and Brian Haberman have acted as | |||
more palatable to the IESG. | 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 | for address-to-name translation. The idea had been discussed briefly | |||
briefly in the IPng working group and RFC 1788 [1788] describes such | in the IPng working group and RFC 1788 [14] describes such a | |||
a mechanism for IPv4. | mechanism for IPv4. | |||
10. References | 10. References | |||
[1034] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC | 10.1 Normative References | |||
1034, STD 13, November 1987. | ||||
[1035] P. Mockapetris, "Domain Names - Implementation and | [1] Mockapetris, P., "Domain names - concepts and facilities", | |||
Specification", RFC 1035, STD 13, November 1987. | STD 13, RFC 1034, November 1987. | |||
[1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, | [2] Mockapetris, P., "Domain names - implementation and | |||
April 1992. | specification", STD 13, RFC 1035, November 1987. | |||
[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788, April | [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) | |||
1995. | Addressing Architecture", RFC 3513, April 2003. | |||
[2119] S. Bradner, "Key words for use in RFCs to Indicate | [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement | |||
Requirement Levels," RFC 2119, March 1997. | Levels", BCP 14, RFC 2119, March 1997. | |||
[2374] Hinden, R., O'Dell, M., and S. Deering, "An IPv6 Aggregatable | [5] Conta, A. and S. Deering, "Internet Control Message Protocol | |||
Global Unicast Address Format", RFC 2374. July 1998. | (ICMPv6) for the Internet Protocol Version 6 (IPv6) | |||
Specification", RFC 2463, December 1998. | ||||
[2401] Kent, S. and R. Atkinson, "Security Architecture for the | [6] Eastlake, D., "Domain Name System Security Extensions", | |||
Internet Protocol", RFC 2401, November 1998. | RFC 2535, March 1999. | |||
[2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an | [7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery | |||
IANA Considerations Section in RFCs", RFC 2434, October 1998. | for IP Version 6 (IPv6)", RFC 2461, December 1998. | |||
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 | [8] Hinden, R. and S. Deering, "An IPv6 Aggregatable Global Unicast | |||
(IPv6) Specification", RFC 2460, December 1998. | Address Format", RFC 2374, July 1998. | |||
[2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery | [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) | |||
for IP Version 6 (IPv6)", RFC 2461, December 1998. | Specification", RFC 2460, December 1998. | |||
[2463] Conta, A. and S. Deering, "Internet Control Message Protocol | 10.2 Informative References | |||
(ICMPv6) for the Internet Protocol Version 6 (IPv6) | ||||
Specification", RFC 2463, December 1998. | ||||
[2535] D. Eastlake 3rd, "Domain Name System Security Extensions", | [10] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |||
RFC 2535, March 1999. | April 1992. | |||
[3513] Hinden, R. and S. Deering, "IP Version 6 Addressing | [11] Kent, S. and R. Atkinson, "Security Architecture for the | |||
Architecture", RFC 3513, April 2003. | Internet Protocol", RFC 2401, November 1998. | |||
[KAME] KAME Project, http://www.kame.net/. | [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA | |||
Considerations Section in RFCs", BCP 26, RFC 2434, | ||||
October 1998. | ||||
11. Author's Address | [13] Narten, T. and R. Draves, "Privacy Extensions for Stateless | |||
Address Autoconfiguration in IPv6", RFC 3041, January 2001. | ||||
[14] Simpson, W., "ICMP Domain Name Messages", RFC 1788, April 1995. | ||||
Authors' Addresses | ||||
Matt Crawford | Matt Crawford | |||
Fermilab MS 369 | Fermilab | |||
PO Box 500 | PO Box 500 | |||
Batavia, IL 60510 | Batavia, IL 60510 | |||
USA | US | |||
Phone: +1 630 840 3461 | Phone: +1 630 840 3461 | |||
Email: crawdad@fnal.gov | Email: crawdad@fnal.gov | |||
Brian Haberman (editor) | ||||
Johns Hopkins University Applied Physics Lab | ||||
11100 Johns Hopkins Road | ||||
Laurel, MD 20723-6099 | ||||
US | ||||
Phone: +1 443 778 1319 | ||||
Email: brian@innovationslab.net | ||||
Intellectual Property Statement | ||||
The IETF takes no position regarding the validity or scope of any | ||||
Intellectual Property Rights or other rights that might be claimed to | ||||
pertain to the implementation or use of the technology described in | ||||
this document or the extent to which any license under such rights | ||||
might or might not be available; nor does it represent that it has | ||||
made any independent effort to identify any such rights. Information | ||||
on the procedures with respect to rights in RFC documents can be | ||||
found in BCP 78 and BCP 79. | ||||
Copies of IPR disclosures made to the IETF Secretariat and any | ||||
assurances of licenses to be made available, or the result of an | ||||
attempt made to obtain a general license or permission for the use of | ||||
such proprietary rights by implementers or users of this | ||||
specification can be obtained from the IETF on-line IPR repository at | ||||
http://www.ietf.org/ipr. | ||||
The IETF invites any interested party to bring to its attention any | ||||
copyrights, patents or patent applications, or other proprietary | ||||
rights that may cover technology that may be required to implement | ||||
this standard. Please address the information to the IETF at | ||||
ietf-ipr@ietf.org. | ||||
Disclaimer of Validity | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2005). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |