draft-ietf-ipngwg-icmp-name-lookups-05.txt   draft-ietf-ipngwg-icmp-name-lookups-06.txt 
IPng Working Group Matt Crawford IPng Working Group Matt Crawford
Internet Draft Fermilab Internet Draft Fermilab
October 22, 1999 July 14, 2000
IPv6 Node Information Queries IPv6 Node Information Queries
<draft-ietf-ipngwg-icmp-name-lookups-05.txt> <draft-ietf-ipngwg-icmp-name-lookups-06.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 working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see 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.
1. Abstract 1. Abstract
This document describes an experimental protocol for asking an IPv6 This document describes an experimental protocol for asking an IPv6
node to supply certain network information, such as its fully- node to supply certain network information, such as its fully-
qualified domain name. IPv6 implementation experience has shown qualified domain name. IPv6 implementation experience has shown
that direct queries for a DNS name are useful, and a direct query that direct queries for a DNS name are useful, and a direct query
mechanism for other information has been requested. mechanism for other information has been requested.
skipping to change at page 2, line 43 skipping to change at page 2, line 43
Type 139 - NI Query. Type 139 - NI Query.
140 - NI Reply. 140 - NI Reply.
Code For NI Query: Code For NI Query:
0 Indicates that the Data field contains an IPv6 0 Indicates that the Data field contains an IPv6
address which is the Subject of this Query. address which is the Subject of this Query.
1 Indicates that the Data field contains a domain name 1 Indicates that the Data field contains a domain name
which is the Subject of this Query which is the Subject of this Query, or is empty, as
in the case of a NOOP or Supported Qtypes query.
2 Indicates that the Data field contains an IPv4 2 Indicates that the Data field contains an IPv4
address which is the Subject of this Query. address which is the Subject of this Query.
For NI Reply: For NI Reply:
0 Indicates a successful reply. The Reply Data field 0 Indicates a successful reply. The Reply Data field
may or may not be empty. may or may not be empty.
1 Indicates that the Responder refuses to supply the 1 Indicates that the Responder refuses to supply the
answer. The Reply Data field will be absent. 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 Responder. The Reply Data field will be absent. the Responder. The Reply Data field will be empty.
Checksum The ICMPv6 checksum. Checksum The ICMPv6 checksum.
Qtype A 16-bit field which designates the type if information Qtype A 16-bit field which designates the type if 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 is always copied from the corresponding Query in a Reply is always copied from the corresponding Query
by the Responder. Five values of Qtype are specified in by the Responder. Five values of Qtype are specified in
this document. this document.
Flags Qtype-specific flags which may be defined for certain Flags Qtype-specific flags which may be defined for certain
skipping to change at page 3, line 48 skipping to change at page 3, line 50
lengths of the ICMPv6 header and intervening extension lengths of the ICMPv6 header and 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 inferred from the ICMP Code, while the type of information, Query is inferred from the ICMP Code, while the type of information,
if any, in the Data field of a Reply is inferred from the Qtype. if any, in the Data field of a Reply is inferred from 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. label followed by two zero-length labels. Since a Query contains at
most one DNS name, DNS compression will not be used.
4. Message Processing 4. 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
scope [2373].
When the Subject is a domain name, either fully-qualified or When the Subject is a domain name, either fully-qualified or
single-component, and the Querier does not have a unicast address single-component, and the Querier does not have a unicast address
for the target node, the query MUST be sent to a link-scope for the target node, the query MUST be sent to a link-scope
multicast address formed in the following way. The Subject Name is multicast address formed in the following way. The Subject Name is
converted to canonical form, as defined by DNS Security [2065], converted to canonical form, as defined by DNS Security [2065],
which is uncompressed with all alphabetic characters in lower case. which is uncompressed with all alphabetic characters in lower case.
(If additional DNS label types for host names are defined, the rules (If additional DNS label types for host names are defined, the rules
for canonicalizing those labels will be found in the defining for canonicalizing those labels will be found in the defining
specification.) Compute the MD5 hash [1321] of the first label of specification.) Compute the MD5 hash [1321] of the first label of
skipping to change at page 4, line 39 skipping to change at page 4, line 41
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.
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, a unless it is one of the Responder's unicast or anycast addresses, or
NI Group Address for a name belonging to the Responder, or a NI a link-local scope multicast address which the Responder has joined.
Group Address for a name for which the Responder is providing proxy Typically the latter will be a NI Group Address for a name belonging
service. A Responder must also silently discard a Query whose to the Responder or a NI Group Address for a name for which the
Subject Address or Name (in the Data field) does not belong to that Responder is providing proxy service. A node MAY be configurable to
node, unless it is providing proxy service for that Subject. A discard NI Queries to multicast addresses other than its NI Group
single-component Subject Name matches any fully-qualified name whose Address(es) but if so, the default configuration MUST be not to
first label matches the Subject. All name matching is done in a discard them.
case-independent manner.
A Responder must also silently discard a Query whose Subject Address
or Name (in the Data field) does not belong to that node, unless it
is providing proxy service for that Subject. A single-component
Subject Name matches any fully-qualified name whose first label
matches the Subject. All name matching is done in a case-
independent manner consistent with DNSSEC name canonicalization
[2065].
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 with ICMPv6 Type = 2 and no Reply Data. The Responder should Reply with ICMPv6 Type = 2 and no Reply Data. The Responder should
rate-limit such replies as it would ICMPv6 error replies [2463, rate-limit such replies as it would ICMPv6 error replies [2463,
2.4(f)]. 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 not addressed in this document. If an answer is on local policy not addressed in this document. If an answer is
refused, the Responder may send a NI Reply with ICMPv6 Type = 1 and refused, the Responder may send a NI Reply with ICMPv6 Type = 1 and
no Reply Data. Again, the Responder should rate-limit such replies no Reply Data. Again, the Responder should rate-limit such replies
skipping to change at page 5, line 47 skipping to change at page 6, line 11
3 Node Addresses. 3 Node Addresses.
4 IPv4 Addresses. 4 IPv4 Addresses.
5.1. NOOP 5.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. Address was an anycast address. On transmission, the ICMPv6 Code in
a NOOP Query must be set to 1 and the Code in a NOOP Reply must be
0. On reception of a NOOP Query or Reply, the Code must be ignored.
5.2. Supported Qtypes 5.2. Supported Qtypes
This Query contains no Data field. The Reply Data is a bit-vector This Query contains no Data field. The Reply Data is a bit-vector
showing which Qtypes are supported by the Responder. The Reply Data showing which Qtypes are supported by the Responder. The Reply Data
has two variant forms: uncompressed and compressed. The has two variant forms: uncompressed and compressed. The
uncompressed Data format is one or more complete 32-bit words, each 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 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 the lowest numbered Qtype in a group of 32. The first word
describes the Responder's support for Qtypes 0 to 31, the second describes the Responder's support for Qtypes 0 to 31, the second
skipping to change at page 7, line 48 skipping to change at page 8, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TTL The number of seconds that the name may be cached. For TTL The number of seconds that the name may be cached. For
compatibility with DNS [1035], this is a 32-bit signed, compatibility with DNS [1035], this is a 32-bit signed,
2's-complement number, which must not be negative. 2's-complement number, which must not be negative.
DNS Names The fully-qualified or single-component name or names of DNS 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 a single DNS label followed by two zero- suffix, and otherwise be a single DNS label followed by
length labels otherwise. two zero-length labels.
When multiple DNS names are returned, DNS name
compression [1035] 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 a The Responder must fill in the TTL field of the Reply with a
meaningful value if possible. That value should be one of the meaningful value if possible. That value should be one of the
following. following.
The remaining lifetime of a DHCP lease on the Subject Address; The remaining lifetime of a DHCP lease on the Subject Address;
The remaining Valid Lifetime of a prefix from which the Subject The remaining Valid Lifetime of a prefix from which the Subject
Address was derived through Stateless Autoconfiguration [2461, Address was derived through Stateless Autoconfiguration [2461,
2462]; 2462];
skipping to change at page 12, line 28 skipping to change at page 13, line 10
address-to-name translations will be no easier than the maintenance address-to-name translations will be no easier than the maintenance
of the NS, SOA and PTR records themselves, which already appears to of the NS, SOA and PTR records themselves, which already appears to
be difficult in many cases. The author expects, therefore, that be difficult in many cases. The author expects, therefore, that
address-to-name mappings, either through the original DNS mechanism address-to-name mappings, either through the original DNS mechanism
or through this new mechanism, will generally be used as only a hint or through this new mechanism, will generally be used as only a hint
to find more trustworthy information using the returned name as an to find more trustworthy information using the returned name as an
index. index.
8. Acknowledgments 8. Acknowledgments
Alain Durand contributed to this specification. This document is Alain Durand contributed to this specification and valuable feedback
not the first proposal of a direct query mechanism for address-to- and implementation experience was provided by Jun-Ichiro Hagino and
name translation. The idea had been discussed briefly in the IPng Tatuya Jinmei. This document is not the first proposal of a direct
working group and an experimental RFC [1788] describes such a query mechanism for address-to-name translation. The idea had been
mechanism for IPv4. discussed briefly in the IPng working group and an experimental RFC
[1788] describes such a mechanism for IPv4.
9. References 9. References
[1035] P. Mockapetris, "Domain Names - Implementation and [1035] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 1035, STD 13, November 1987. Specification", RFC 1035, STD 13, November 1987.
[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
 End of changes. 

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