IPng Working Group Matt Crawford Internet Draft Fermilab February 26, 1999 IPv6 Node Information Queries Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. 1. Abstract This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. 2. Terminology A "Node Information (or NI) Query" message is sent by a "Querier" node to a "Responder" node in an ICMPv6 packet addressed to the "Queried Address." The Responder sends a "Node Information Reply" to the Querier, containing information associated with the node at the Queries address. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2119]. Packet fields marked "unused" must be zero on transmassion and Expires September 3, 1999 Crawford [Page 1] Internet Draft ICMP Name Lookups February 26, 1999 ignored on reception. 3. Node Information Messages Two types of Node Information messages, the NI Query and the NI Reply, are carried in ICMPv6 [2463] packets. They have the same format, except that the Query lacks the Reply Data section. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Reply Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA1 - NI Query. TBA2 - NI Reply. Code For NI Query, always 0. For NI Reply: 0 Indicates a successful reply. 1 Indicates that the Responder refuses to supply the answer. The Reply Data field will be absent. 2 Indicates that the Qtype of the Query is unknown to the Responder. The Reply Data field will be absent. Checksum The ICMPv6 checksum. Qtype A 16-bit field which designates the type if information requested in a Query or supplied in a Reply. Its value in a Reply is always copied from the corresponding Query by the Responder. Four values of Qtype are specified in this document. Expires September 3, 1999 Crawford [Page 2] Internet Draft ICMP Name Lookups February 26, 1999 Flags Qtype-specific flags which may be defined for certain Query types. Flags not defined for a given Qtype must be zero on transmission and ignored on reception, and must not be copied from a Query to a Reply unless so specified in the definition of the Qtype. Nonce An opaque 64-bit field to help avoid spoofing. Its value in a Query is chosen by the Querier. Its value in a Reply is always copied from the corresponding Request by the Responder. Reply Data Qtype-specific data present only in an NI Reply message with ICMPv6 Type field equal to zero. The length of the Reply Data may be inferred from the IPv6 header's Payload Length field [2460] and the length of the fixed portion of the NI Reply and the lengths of the ICMPv6 header and intervening extension headers. 4. Message Processing The Querier constructs an ICMP NI Query and sends it to the unicast address from which information is wanted. The Nonce should be a random or good pseudo-random value to foil spoofed replies. If true communication security is required, IPsec [2401] must be used. Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing if it is not one of the Responder's unicast or anycast addresses. 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 rate-limit such replies as it would ICMPv6 error replies [2463, 2.4(f)]. Next, the Responder should decide whether to refuse an answer, based 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 no Reply Data. Again, the Responder should rate-limit such replies as it would ICMPv6 error replies [2463, 2.4(f)]. Finally, if the Qtype is known and the response is allowed by local policy, the Responder must fill in the Flags and Reply Data of the NI Reply in accordance with the definition of the Qtype and transmit the NI Reply with an ICMPv6 source address equal to the Queried Address, unless that address was an anycast address. If the Queried Expires September 3, 1999 Crawford [Page 3] Internet Draft ICMP Name Lookups February 26, 1999 Address was anycast, the source adderss for the Reply should be one belonging to the interface on which the Query was received. The Querier should silently discard any Reply whose Destination Address and Nonce do not match the Source Address and Nonce of an outstanding Query. An NI message of either sort must never be sent to a multicast address. 5. Defined Qtypes The following four Qtypes are defined and must be supported by any implementation of this protocol. 0 NOOP. 1 Supported Qtypes. 2 FQDN. 2 Node Addresses. 5.1. NOOP This Qtype has no defined flags and never has a Reply Data field. A Reply to an NI NOOP Query tells the Querier that a node with the Queried Address was up and reachable, implments the Node Information protocol, and secondarily reveals whether the Queried Address was an anycast address. 5.2. Supported Qtypes The Reply Data in an NI Supported Qtypes Reply is a bit-vector 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 word corresponding to the lowest numbered Qtype in a group of 32. A 1-valued bit indicates support for the corresponding Qtype. The lowest-order four bits in the first 32-bit word must be set to 1, showing support for the four Qtypes defined in this specification. One flag bit is defined. Expires September 3, 1999 Crawford [Page 4] Internet Draft ICMP Name Lookups February 26, 1999 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype | unused |C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 indicates that the Reply Data is compressed. The compression is not yet defined and may only be used in a Reply if the Query had the C- flag set. 5.3. FQDN The NI FQDN Query requests the fully-qualified domain name corresponding to the Queried Address. The Reply Data has the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NameLen | FQDN ... | +-+-+-+-+-+-+-+-+ + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TTL The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. NameLen The length in octets of the FQDN, as an 8-bit unsigned integer. FQDN The fully-qualified domain name of the Responder which corresponds to the Queried Address, as a sequence of NameLen US-ASCII octets, with periods between the labels, and no period after the last label. The Responder must fill in the TTL field of the Reply with a meaningful value if possible. That value should be one of the following. Expires September 3, 1999 Crawford [Page 5] Internet Draft ICMP Name Lookups February 26, 1999 The remaining lifetime of a DHCP lease on the Queried Address; The remaining Valid Lifetime of a prefix from which the Queried Address was derived through Stateless Autoconfiguration [2461, 2462]; The TTL of an existing AAAA or A6 record which associates the Queried Address with the FQDN being returned. One Flag bit is defined, in the Reply only. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype | unused |T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 set to zero by the Responder and must be ignored by the Querier. 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 (T-flag 0), the information in that Reply must not be used more than once. If the Query was sent by a DNS server on behalf of a DNS client, the result may be returned to that client as a DNS response with TTL zero. However, if the server has the matching AAAA record, either in cache or in an authoritative zone, then the TTL of that record may be used as the missing TTL of the NI FQDN Reply and the information in the reply may be cached and used for that period. It would be an implementation choice for a server to perform a DNS query for the AAAA or A6 record that matches a received NI FQDN Reply. This might be done to obtain a TTL to make the Reply cacheable or in anticipation of such a AAAA query from the client that caused the FQDN Query. 5.3.1. Discussion 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 of nodes, for example a subnet or a site. Such a mechanism is not addressed here. IPsec can be applied to NI FQDN messages to achieve greater trust in the information obtained, but such a need may be obviated by applying IPsec directly to some other communication which is going Expires September 3, 1999 Crawford [Page 6] Internet Draft ICMP Name Lookups February 26, 1999 on (or contemplated) between the Querier and Responder. 5.3.1.1. Node Addresses The NI Node Addresses Query requests some set of the Responder's unicast addresses. The Reply Data is a sequence of 128-bit IPv6 addresses, with Preferred addresses listed before Deprecated addresses [2461], but otherwise in no special order. Four flag bits are defined in the Query, and five in the Reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Qtype | unused |T|A|G|S|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ T Defined in a Reply only, indicates that the set of addresses is inclomplete for space reasons. A If set to 1, all the Responder's unicast addresses are requested. If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Queried Address. G If set to 1, Global-scope 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. Flags A, G, S and L are copied from a Query to the corresponding Reply. 6. IANA Considerations This document defines four values of Qtype, numbers 0 through 3. Following the policies outlined in [2434], new values, and their associated Flags and Reply Data, may be defined as follows. Qtypes 4 through 255, by IETF Consensus. Qtypes 256 through 1023, Specification Required. Qtypes 1024 through 4095, First Come First Served. Expires September 3, 1999 Crawford [Page 7] Internet Draft ICMP Name Lookups February 26, 1999 Qtypes 4096 through 65535, Private Use. User of Private Use values should note that values above 8000 to 9000 are likely to lead to fragmentation of "Supported Qtypes" Replies. 7. Security Considerations The anti-spoofing Nonce does not give any protection from spoofers who can snoop the Query or the Reply. In a large Internet with relatively frequent renumbering, the maintenance of of KEY and SIG records [2065] in the zones used for address-to-name translations will be no easier than the maintenance of the NS, SOA and PTR records themselves, which already appears to be difficult in many cases. The author expects, therefore, that address-to-name mappings, either through the original DNS mechanism or through this new mechanism, will generally be used as only a hint to find more trustworthy information using the returned name as an index. 8. Acknowledgments This document is not the first proposal of a direct query mechanism for address-to-name translation. The idea was discussed and deferred in the IPng working group and an experimental RFC [1788] describes such a mechanism for IPv4. 9. References [1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13. [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788. [2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401. Expires September 3, 1999 Crawford [Page 8] Internet Draft ICMP Name Lookups February 26, 1999 [2434] Narten, T. and H. T. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 10. Author's Address Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA Phone: +1 630 840 3461 Email: crawdad@fnal.gov Expires September 3, 1999 Crawford [Page 9]