Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: December 20, 2002 June 20, 2002 Name resolution in zeroconf environment using ICMPv6 node information query draft-itojun-ipv6-nodeinfo-zeroconflookup-00.txt 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. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be December 20, 2002. Abstract The document proposes a way to resolve DNS names in zeroconf environment [Williams, 2002] , by using ICMPv6 node information query/reply [Crawford, 2002] . The proposed protocol works only with IPv6 (not with IPv4). 1. Outline This document discusses a way to provide name-to-address mapping, and reverse mapping, in zeroconf environment [Williams, 2002] . By "zeroconf environment", we mean a single-link network without any DNS servers. The approach uses ICMPv6 node information query/reply [Crawford, 2002] . All IPv6 addresses used in the document would be in link-local scope. There are two parties: querier and responder. For forward mapping, querier knows a DNS name and interested in getting link-local IPv6 address for the DNS name. For reverse mapping, querier knows a link- local IPv6 address and interested in getting DNS name for the IPv6 ITOJUN Expires: December 20, 2002 [Page 1] DRAFT Zeroconf name resolution by ICMPv6 node info query June 2002 address. 2. Forward mapping (name-to-addrress) Querier knows a DNS name which should belong to the responder, and is interested in getting link-local IPv6 address for the DNS name. Querier transmits the following ICMPv6 node information query packet to the NI group corresponds to the DNS name: IPv6 source: one of querier's address (Q) IPv6 destination: NI group address for the DNS name (ff02::2:xxxx:xxxx) Code: 1 (Subject is a DNS name) Qtype: 2 (DNS name) Nonce: pseudo-random (N) Data (Subject): target DNS name In response, the reponder transmits ICMPv6 node information reply with the DNS name. IPv6 source: one of responder's address (R) IPv6 destination: Q Code: 0 (Successful) Qtype: 2 (DNS name) Flag: lowermost bit set (TTL is valid) Nonce: N Data: target DNS name. TTL must be set based on R's address lifetime. IPv6 source address of the reply (R) is the address the querier is looking for. Note: o Nonce field should be used to match replies against a query. o DNS name should be equal between the query and the reply. o Querier should expect to receive multiple replies, as multiple nodes can be configured with the same name. 3. Reverse mapping (address-to-name) Querier knows a link-local IPv6 address of the responder, and is interested in getting DNS name for the responder, Querier transmits the following ICMPv6 node information query packet to the reponder's address: ITOJUN Expires: December 20, 2002 [Page 2] DRAFT Zeroconf name resolution by ICMPv6 node info query June 2002 IPv6 source: one of querier's address (Q) IPv6 destination: responder's address (R) Code: 0 (Subject is an IPv6 address) Qtype: 2 (DNS name) Nonce: pseudo-random (N) Data (Subject): responder's address In response, the reponder transmits ICMPv6 node information reply with fully-qualified DNS name. IPv6 source: one of responder's address IPv6 destination: Q Code: 0 (Successful) Qtype: 2 (DNS name) Flag: lowermost bit set (TTL is valid) Nonce: N Data: fully-qualified DNS name. TTL must be set based on R's address lifetime. Note: o The IPv6 source address of the reply need not be R; Nonce field should be used to match replies against a query. o Fully-qualified DNS name should be sent on replies. 4. Retransmission and timing parameter Querier is allowed to retransmit query 3 times with 1 second interval. Querier should implement cache mechanism, based on the TTL value sent from the responder. If TTL value is not present on replies, querier must not cache values on replies. If there is no response after 3 retransmissions, negative-cache entry with lifetime of 30 second should be installed. Querier must ignore responses with a Nonce value unknown to the querier (it could be a malicious attempt to taint the cache). Responder must rate-limit replies as documented in ICMPv6 node information query document [Crawford, 2002] . 5. Appicability 5.1. Is "DNS name" mentioned here really a DNS name? Responses returned on "DNS name" query can contain arbitrary string independent from deployed DNS infrastructure. For example, any node can respond with DNS name "foo.example.org" without example.org administrator's knowledge. ITOJUN Expires: December 20, 2002 [Page 3] DRAFT Zeroconf name resolution by ICMPv6 node info query June 2002 To avoid contamination of the global DNS namespace, the mechanism should be used only within a zeroconf network isolated from the global Internet. 5.2. How should we distinguish between multiple nodes with the same name? When a querier sees multiple replies on forward lookup, the querier has no way to distinguish between two responses, in ICMPv6 node information query/reply level. In such case, upper-layer protocol mechanisms (like SSH host key) should be used to distinguish between multiple replies. 6. Security consideration 6.1. Are there any possibility for forgery? Yes. Nodes on the link can intercept node information query/reply packet and throw in forged queries/replies. More on security implication in a zeroconf network can be found in [Williams, 2002] . 6.2. Use of reverse DNS mapping for authentication As documented in [Senie, 2001] it is discouraged to use the existence of reverse DNS mapping as authentication. References Williams, 2002. Aidan Williams, "Zeroconf IP Host Requirements" in draft-ietf-zeroconf- reqts-10.txt (February 2002). work in progress material. Crawford, 2002. Matt Crawford, "IPv6 Node Information Queries" in draft-ietf-ipngwg- icmp-name-lookups-09.txt (May 2002). work in progress material. Senie, 2001. Daniel Senie, "Requiring DNS IN-ADDR Mapping" in draft-ietf-dnsop- inaddr-required-02.txt (July 2001). work in progress material. Change history None. Acknowledgements (to be filled) ITOJUN Expires: December 20, 2002 [Page 4] DRAFT Zeroconf name resolution by ICMPv6 node info query June 2002 Author's address Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 Email: itojun@iijlab.net ITOJUN Expires: December 20, 2002 [Page 5]