IPng Working Group Matt Crawford Internet Draft Fermilab March 9, 1998 IPv6 Name Lookups Through ICMP Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. 1. Abstract IPv4 addresses are translated to fully-qualified domain names (FQDNs) using the DNS. Experience shows that the IN-ADDR.ARPA zones used for this translation tend to be poorly maintained in some cases. In a larger internet with more frequent site renumbering, the maintenance of such zones will be even more difficult. This document describes an experimental protocol for simply asking an IPv6 node to supply its FQDN when needed. The DNS style of authority delegation is thus eliminated for IPv6 address-to-name translations and the routing infrastructure plays that role. 2. Terminology An "FQDN Query" message is sent by a "Querier" node to a "Responder" node in an ICMPv6 packet addressed to the "Queried Address." The Expires September 14, 1998 Crawford [Page 1] Internet Draft ICMP Name Lookups March 9, 1998 Responder sends an "FQDN Reply" to the Querier, containing the Fully Qualified Domain Name (FQDN) currently associated with the Queried 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 ignored on reception. 3. FQDN Messages There are two ICMPv6 [ICMPV6] FQDN message, the FQDN Query and the FQDN Reply. They have 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time-To-Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NameLen | FQDN ... | +-+-+-+-+-+-+-+-+ + / / + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBA1 - FQDN Query. TBA2 - FQDN Reply. Code For FQDN Query, always 0. For FQDN Reply: 0 Indicates that the Time-To-Live field is meaningful 1 Indicates that the responding node cannot provide a Expires September 14, 1998 Crawford [Page 2] Internet Draft ICMP Name Lookups March 9, 1998 meaningful TTL for its Address-to-FQDN association. Checksum The ICMPv6 checksum. ID A 16-bit field to aid in matching replies and requests. Its value is chosen by the Querier and copied from a Request to a Reply by the Responder. Nonce An opaque 64-bit field to help avoid spoofing. Its value is chosen by the Querier and copied from a Request to a Reply by the Responder. Time-To-Live 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. The last three fields (Time-To-Live, NameLen and FQDN) are not present in the FQDN Query. 4. Message Processing The Querier constructs an ICMP FQDN Query and sends it to the unicast address whose FQDN is wanted. The ID field's value is chosen for the Querier's convenience, and the Nonce should be a random or good pseudo-random value to foil spoofed replies. Upon receiving an FQDN Query, the Responder must check the Query's IPv6 destination address and discard the Query if it is not one of the Responder's unicast addresses. 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. 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 [ND, Expires September 14, 1998 Crawford [Page 3] Internet Draft ICMP Name Lookups March 9, 1998 ACONF]; The TTL of an existing AAAA record which associates the Queried Address with the FQDN being returned. If the Responder has no meaningful TTL value to return, the ICMPv6 Code field of the Reply must be set to 1 and the TTL field should be set to 0. The IPv6 source address of the Reply must be the Queried Address. The Querier must silently discard any Reply whose source address, ID and Nonce do not match an outstanding Query. The information in an FQDN Reply which has an ICMPv6 Code value of 0 may be cached and used for the period indicated by that TTL. If a Reply has no TTL (ICMPv6 Code 1), 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 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 record that matches a received 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. An FQDN Query must not be sent to a multicast address. To avoid congesting the internet with ICMP FQDN messages, they should be sent only by a system capable of caching the replies, preferably on behalf of many other potential queriers. A logical place to do that caching is in DNS servers. Accordingly, these messages should be used as a "back end" to DNS servers, which can then present clients with an unchanged interface to the FQDN-lookup service. 5. 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. Expires September 14, 1998 Crawford [Page 4] Internet Draft ICMP Name Lookups March 9, 1998 IPsec could be applied to FQDN messages to achieve greater trust in the information obtained, but such a need is probably obviated by applying IPsec directly to some other communication which is going on (or contemplated) between the Querier and Responder. 6. 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. 7. 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. 8. References [1035] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 1035, STD 13. [1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788. [2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [ACONF] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", draft-ietf-ipngwg-addrconf-v2-02.txt. [ND] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", draft-ietf-ipngwg-discovery-v2-02.txt. [ICMPV6]A. Conta, S. Deering, "Internet Control Message Protocol Expires September 14, 1998 Crawford [Page 5] Internet Draft ICMP Name Lookups March 9, 1998 (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", Currently draft-ietf-ipngwg-icmp-v2-00.txt. 9. 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 14, 1998 Crawford [Page 6]