draft-ietf-ipngwg-icmp-name-lookups-03.txt   draft-ietf-ipngwg-icmp-name-lookups-04.txt 
IPng Working Group Matt Crawford IPng Working Group Matt Crawford
Internet Draft Fermilab Internet Draft Fermilab
February 26, 1999 June 21, 1999
IPv6 Node Information Queries IPv6 Node Information Queries
<draft-ietf-ipngwg-icmp-name-lookups-03.txt> <draft-ietf-ipngwg-icmp-name-lookups-04.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 FQDN are useful, and a direct query that direct queries for FQDN are useful, and a direct query
mechanism for other information has been requested. mechanism for other information has been requested.
2. Terminology 2. 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 Responder sends a "Node Information Reply" "Queried Address." The Query concerns a "Subject Address" which may
to the Querier, containing information associated with the node at differ from the Queried Address, or a "Subject Name". The Responder
the Queries address. sends a "Node Information Reply" to the Querier, containing
information associated with the node at the Queries address. A node
receiving an NI Query will be termed a Responder even if it does not
send a Reply.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2119]. document are to be interpreted as described in [2119].
Packet fields marked "unused" must be zero on transmassion and Packet fields marked "unused" must be zero on transmission and,
aside from inclusion in checksums or message integrity checks,
ignored on reception. ignored on reception.
3. Node Information Messages 3. Node Information Messages
Two types of Node Information messages, the NI Query and the NI Two types of Node Information messages, the NI Query and the NI
Reply, are carried in ICMPv6 [2463] packets. They have the same Reply, are carried in ICMPv6 [2463] packets. They have the same
format, except that the Query lacks the Reply Data section. 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 +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Reply Data / / Data /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type TBA1 - NI Query. Type 139 - NI Query.
TBA2 - NI Reply. 140 - NI Reply.
Code For NI Query, always 0. Code For NI Query:
0 Indicates that the Data field contains an IPv6
address which is the subject of this Query.
1 Indicates that the Data field contains a domain name
which is the subject of this Query
For NI Reply: For NI Reply:
0 Indicates a successful reply. 0 Indicates a successful reply.
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 absent.
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 absent.
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. Four values of Qtype are specified in by the Responder. Four 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
Query types. Flags not defined for a given Qtype must Query types and their Replies. Flags not defined for a
be zero on transmission and ignored on reception, and given Qtype must be zero on transmission and ignored on
must not be copied from a Query to a Reply unless so reception, and must not be copied from a Query to a
specified in the definition of the Qtype. Reply unless so specified in the definition of the
Qtype.
Nonce An opaque 64-bit field to help avoid spoofing. Its Nonce An opaque 64-bit field to help avoid spoofing and/or to
value in a Query is chosen by the Querier. Its value in aid in matching Replies with Queries. Its value in a
a Reply is always copied from the corresponding Request Query is chosen by the Querier. Its value in a Reply is
by the Responder. always copied from the corresponding Request by the
Responder.
Reply Data Qtype-specific data present only in an NI Reply message Data In a Query, the subject address or name. In a Reply,
with ICMPv6 Type field equal to zero. The length of the Qtype-specific data present only when the ICMPv6 Type
Reply Data may be inferred from the IPv6 header's field is zero. The length of the Data may be inferred
Payload Length field [2460] and the length of the fixed from the IPv6 header's Payload Length field [2460] and
portion of the NI Reply and the lengths of the ICMPv6 the length of the fixed portion of the NI packet and the
header and intervening extension headers. lengths of the ICMPv6 header and intervening extension
headers.
4. Message Processing 4. Message Processing
The Querier constructs an ICMP NI Query and sends it to the unicast The Querier constructs an ICMP NI Query and sends it to the address
address from which information is wanted. The Nonce should be a from which information is wanted. When the subject of the Query is
random or good pseudo-random value to foil spoofed replies. If true an IPv6 address, that address will normally be used as the IPv6
communication security is required, IPsec [2401] must be used. destination address of the Query, but need not be if the Querier has
useful a priori information about the addresses of the target node.
When the subject is a domain name, either fully-qualified or
single-component, and the Querier does not have a unicast address
for the target node, the query MUST be sent to a link-scope
multicast address formed by appending to the prefix
FF02:0:0:0:0:2::/96 the CRC-32 checksum [IS3309] of the first
component of the subject domain name -- the portion up to, but
excluding, the first period.
The Nonce should be a random or good pseudo-random value to foil
spoofed replies. An implementation which allows multiple
independent processes to send NI queries MAY use the Nonce value to
deliver Replies to the correct process. Nonetheless, such processes
MUST check the received Nonce and ignore extraneous Replies.
If true communication security is required, IPsec [2401] must be
used.
Upon receiving an NI Query, the Responder must check the Query's Upon receiving an NI Query, the Responder must check the Query's
IPv6 destination address and discard the Query without further IPv6 destination address and discard the Query without further
processing if it is not one of the Responder's unicast or anycast processing if it is not one of the Responder's unicast or anycast
addresses. addresses. A Responder must also silently discard a Query whose
subject address or name (in the Data field) does belong to that
node.
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 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 an NI Reply with ICMPv6 Type = 1 and refused, the Responder may send an 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
as it would ICMPv6 error replies [2463, 2.4(f)]. as it would ICMPv6 error replies [2463, 2.4(f)].
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 Reply in accordance with the definition of the Qtype and transmit NI Reply in accordance with the definition of the Qtype and transmit
the NI Reply with an ICMPv6 source address equal to the Queried the NI Reply with an ICMPv6 source address equal to the Queried
Address, unless that address was an anycast address. If the Queried Address, unless that address was an anycast address. If the Queried
Address was anycast, the source adderss for the Reply should be one Address was anycast, the source address for the Reply SHOULD be one
belonging to the interface on which the Query was received. belonging to the interface on which the Query was received.
The Querier should silently discard any Reply whose Destination If the Query was sent to an anycast or multicast address,
Address and Nonce do not match the Source Address and Nonce of an transmission of the Reply MUST be delayed by a random interval
outstanding Query. between zero and MAX_ANYCAST_DELAY_TIME, as defined by IPv6 Neighbor
Discovery [2461].
An NI message of either sort must never be sent to a multicast
address.
5. Defined Qtypes 5. Defined Qtypes
The following four Qtypes are defined and must be supported by any The following four Qtypes are defined and must be supported by any
implementation of this protocol. implementation of this protocol.
0 NOOP. 0 NOOP.
1 Supported Qtypes. 1 Supported Qtypes.
2 FQDN. 2 FQDN.
2 Node Addresses. 3 Node Addresses.
5.1. NOOP 5.1. NOOP
This Qtype has no defined flags and never has a Reply 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 was up and reachable, implments the Node Information Queried Address is up and reachable, implements the Node Information
protocol, and secondarily reveals whether the Queried Address was an protocol, and incidentally happens to reveal whether the Queried
anycast address. Address was an anycast address.
5.2. Supported Qtypes 5.2. Supported Qtypes
The Reply Data in an NI Supported Qtypes Reply 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
is grouped in complete 32-bit words, with the low-order bit in each has two variant forms: uncompressed and compressed. The
word corresponding to the lowest numbered Qtype in a group of 32. A uncompressed Data format is one or more complete 32-bit words, each
1-valued bit indicates support for the corresponding Qtype. The word a bitmask with the low-order bit in each word corresponding to
the lowest numbered Qtype in a group of 32. The first word
describes the Responder's support for Qtypes 0 to 31, the second
word 32 to 63, and so on.
A 1-valued bit indicates support for the corresponding Qtype. The
lowest-order four bits in the first 32-bit word must be set to 1, lowest-order four bits in the first 32-bit word must be set to 1,
showing support for the four Qtypes defined in this specification. showing support for the four Qtypes defined in this specification.
Thus the Data field of an NI Supported Qtypes Reply from a Responder
implementing only the 4 Qtypes defined here will contain 32 bits in
the following form:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 . . . 0 0 0 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The compressed form of the Reply Data consists of a sequence of
blocks, each block consisting of two 16-bit unsigned integers, nWord
and nSkip, followed by nWord 32-bit bitmasks describing the
Responder's support for 32 consecutive Qtypes. nSkip is a count of
32-bit words which would have been all-zero and have been
suppressed. The last block MUST have nSkip = 0. As an example, a
Responder supporting Qtypes 0, 1, 2, 3, 60, and 4097 could express
that information with the following Reply Data (nWord and nSkip
fields are written in decimal for easier reading):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | 126 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 . . . 0 0 0 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 0 . . . 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 . . . 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One flag bit is defined. One flag bit is defined.
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 | unused |C| | Qtype=1 | unused |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In a Query, a C-flag set to 1 indicates that the Querier will accept In a Query, a C-flag set to 1 indicates that the Querier will accept
a compressed form of the Reply Data. In a Reply, a C-flag set to 1 the compressed form of the Reply Data. In a Reply, a C-flag set to
indicates that the Reply Data is compressed. The compression is not 1 indicates that the Reply Data is compressed. The compressed form
yet defined and may only be used in a Reply if the Query had the C- MAY be used in a Reply only if the Query had the C-flag set.
flag set. Implementations of this specification SHOULD support the compressed
form and if they do, SHOULD set the C-flag in all Supported Qtypes
Queries and SHOULD use the compressed form in Supported Qtypes
Replies (when allowed by the C-flag in the query) if doing so would
avoid fragmentation of the Reply or save significant space in the
Reply.
5.3. FQDN 5.3. FQDN
The NI FQDN Query requests the fully-qualified domain name The NI FQDN Query requests the fully-qualified domain name
corresponding to the Queried Address. The Reply Data has the corresponding to the subject Address or Name. The Reply Data has
following format. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NameLen | FQDN ... | | NameLen | FQDN ... |
+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+ +
/ / / /
+ + + +
skipping to change at page 5, line 43 skipping to change at page 7, 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.
NameLen The length in octets of the FQDN, as an 8-bit unsigned NameLen The length in octets of the FQDN, as an 8-bit unsigned
integer. integer.
FQDN The fully-qualified domain name of the Responder which FQDN The fully-qualified domain name of the Responder which
corresponds to the Queried Address, as a sequence of corresponds to the Subject Address or Name, as a
NameLen US-ASCII octets, with periods between the sequence of NameLen US-ASCII octets, with periods
labels, and no period after the last label. between the labels, and no period after the last label.
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 Queried Address; The remaining lifetime of a DHCP lease on the Subject Address;
The remaining Valid Lifetime of a prefix from which the Queried 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];
The TTL of an existing AAAA or A6 record which associates the The TTL of an existing AAAA or A6 record which associates the
Queried Address with the FQDN being returned. Subject Address with the FQDN being returned.
If the Responder knows its hostname but not its domain, it MUST send
its one-component name with no periods. It may still be possible to
return a meaningful TTL based on a DHCP lease or autoconfigured
prefix.
If the Responder does not know its name at all it MUST send a Reply
with TTL=0, NameLen=0 and no FQDN.
One Flag bit is defined, in the Reply only. One Flag bit is defined, in the Reply only.
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 | unused |T| | Qtype=2 | unused |T|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A T-flag set to 1 in an NI FQDN Reply indicates that the TTL field A T-flag set to 1 in an NI FQDN Reply indicates that the TTL field
contains a meaningful value. If the T-flag is 0, the TTL should be contains a meaningful value. If the T-flag is 0, the TTL SHOULD be
set to zero by the Responder and must be ignored by the Querier. set to zero by the Responder and MUST be ignored by the Querier.
If a name rather than an address was the Subject of the Query, the
T-flag MUST be zero and the TTL SHOULD be zero.
The information in an NI FQDN Reply with T-flag 1 may be cached and The information in an NI FQDN Reply with T-flag 1 may be cached and
used for the period indicated by that TTL. If a Reply has no TTL used for the period indicated by that TTL. If a Reply has no TTL
(T-flag 0), the information in that Reply must not be used more than (T-flag 0), the information in that Reply must not be used more than
once. If the Query was sent by a DNS server on behalf of a DNS once. If the Query was sent by a DNS server on behalf of a DNS
client, the result may be returned to that client as a DNS response client, the result may be returned to that client as a DNS response
with TTL zero. However, if the server has the matching AAAA record, with TTL zero. However, if the server has the matching AAAA record,
either in cache or in an authoritative zone, then the TTL of that either in cache or in an authoritative zone, then the TTL of that
record may be used as the missing TTL of the NI FQDN Reply and the record may be used as the missing TTL of the NI FQDN Reply and the
information in the reply may be cached and used for that period. information in the reply may be cached and used for that period.
skipping to change at page 7, line 6 skipping to change at page 8, line 46
Because a node can only answer a FQDN Request when it is up and Because a node can only answer a FQDN Request when it is up and
reachable, it may be useful to create a proxy responder for a group reachable, it may be useful to create a proxy responder for a group
of nodes, for example a subnet or a site. Such a mechanism is not of nodes, for example a subnet or a site. Such a mechanism is not
addressed here. addressed here.
IPsec can be applied to NI FQDN messages to achieve greater trust in IPsec can be applied to NI FQDN messages to achieve greater trust in
the information obtained, but such a need may be obviated by the information obtained, but such a need may be obviated by
applying IPsec directly to some other communication which is going applying IPsec directly to some other communication which is going
on (or contemplated) between the Querier and Responder. on (or contemplated) between the Querier and Responder.
5.3.1.1. Node Addresses 5.4. Node Addresses
The NI Node Addresses Query requests some set of the Responder's The NI Node Addresses Query requests some set of the Responder's
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, with Preferred addresses listed before Deprecated addresses, with Preferred addresses listed before Deprecated
addresses [2461], but otherwise in no special order. Four flag bits addresses [2461], but otherwise in no special order. Four flag bits
are defined in the Query, and five in the Reply. are defined in the Query, and five 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 | unused |T|A|G|S|L| | Qtype=3 | unused |T|A|G|S|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T Defined in a Reply only, indicates that the set of addresses is T Defined in a Reply only, indicates that the set of addresses is
inclomplete for space reasons. incomplete for space reasons.
A If set to 1, all the Responder's unicast addresses are A If set to 1, all the Responder's unicast addresses (of the
requested. If 0, only those addresses are requested which specified scope(s))are requested. If 0, only those addresses
belong to the interface (or any one interface) which has the are requested which belong to the interface (or any one
Queried Address. interface) which has the Subject Address.
G If set to 1, Global-scope addresses [2374] are requested. G If set to 1, Global-scope addresses [2374] are requested.
S If set to 1, Site-local addresses [2374] are requested. S If set to 1, Site-local addresses [2374] are requested.
L If set to 1, Link-local addresses [2374] are requested. L If set to 1, Link-local addresses [2374] are requested.
Flags A, G, S and L are copied from a Query to the corresponding Flags A, G, S and L are copied from a Query to the corresponding
Reply. Reply.
6. IANA Considerations 6. IANA Considerations
ICMPv6 type values 139 and 140 have been assigned by IANA for this
protocol.
This document defines four values of Qtype, numbers 0 through 3. This document defines four values of Qtype, numbers 0 through 3.
Following the policies outlined in [2434], new values, and their Following the policies outlined in [2434], new values, and their
associated Flags and Reply Data, may be defined as follows. associated Flags and Reply Data, may be defined as follows.
Qtypes 4 through 255, by IETF Consensus. Qtypes 4 through 255, by IETF Consensus.
Qtypes 256 through 1023, Specification Required. Qtypes 256 through 1023, Specification Required.
Qtypes 1024 through 4095, First Come First Served. Qtypes 1024 through 4095, First Come First Served.
Qtypes 4096 through 65535, Private Use. Qtypes 4096 through 65535, Private Use.
User of Private Use values should note that values above 8000 to Users of Private Use values should note that values above 8000 to
9000 are likely to lead to fragmentation of "Supported Qtypes" 9000 are likely to lead to fragmentation of "Supported Qtypes"
Replies. Replies unless the compressed for of the Reply Data is used.
The multicast address formation of section has not yet been
discussed in the IPNG working group and is not yet requested or
assigned for this use.
7. Security Considerations 7. Security Considerations
The anti-spoofing Nonce does not give any protection from spoofers The anti-spoofing Nonce does not give any protection from spoofers
who can snoop the Query or the Reply. who can snoop the Query or the Reply.
In a large Internet with relatively frequent renumbering, the In a large Internet with relatively frequent renumbering, the
maintenance of of KEY and SIG records [2065] in the zones used for maintenance of of KEY and SIG records [2065] in the zones used for
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
This document is not the first proposal of a direct query mechanism Alain Durand contributed to this specification. This document is
for address-to-name translation. The idea was discussed and not the first proposal of a direct query mechanism for address-to-
deferred in the IPng working group and an experimental RFC [1788] name translation. The idea had been discussed briefly in the IPng
describes such a mechanism for IPv4. 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. Specification", RFC 1035, STD 13.
[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788. [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788.
[2119] [2119] Bradner, S., "Key words for use in RFCs to Indicate
Bradner, S., "Key words for use in RFCs to Indicate Requirement Requirement Levels," RFC 2119.
Levels," RFC 2119.
[2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[2401] Kent, S. and R. Atkinson, "Security Architecture for the [2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401. Internet Protocol", RFC 2401.
[2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an [2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434. IANA Considerations Section in RFCs", RFC 2434.
[2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[2463] Conta, A. and S. Deering, "Internet Control Message Protocol [2463] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
[IS3309] International Organization for Standardization, "ISO
Information Processing Systems - Data Communication High-Level
Data Link Control Procedure - Frame Structure", IS 3309, October
1984, 3rd Edition.
10. Author's Address 10. Author's Address
Matt Crawford Matt Crawford
Fermilab MS 368 Fermilab MS 368
PO Box 500 PO Box 500
Batavia, IL 60510 Batavia, IL 60510
USA USA
Phone: +1 630 840 3461 Phone: +1 630 840 3461
 End of changes. 

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