One document matched: draft-itojun-ipv6-nodeinfo-zeroconflookup-00.txt

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]