Internet Engineering Task Force                 Jun-ichiro itojun Hagino
INTERNET-DRAFT                                   IIJ Research Laboratory
Expires: December 20, 2002                                 June 20, 2002


      Use of ICMPv6 node information query for reverse DNS lookup
              draft-itojun-ipv6-nodeinfo-revlookup-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 an alternative way to perform reverse DNS lookup,
by using ICMPv6 node information query/reply [Crawford, 2002] .  The
proposed protocol works only with IPv6 (not with IPv4).

1.  Motivation

As documented in [Senie, 2001] , even though many applications assume
reverse address mapping to exist, DNS reverse address mapping table may
not be present.  With IPv4, automatically-generated reverse mapping
table, like following, has been used.

     123.123.123.123.in-addr.arpa. IN PTR 123-123-123-123.reverse.example.org.

However, it is difficult to provide such mapping for IPv6, due to the
number of reverse mapping records needed.  Therefore, with IPv6, it is
more likely to see IPv6 addresses without reverse DNS mapping.  While it
may be possible to register reverse DNS records via dynamic DNS updates,
it is still not widely practiced due to difficulties with authentication


ITOJUN                 Expires: December 20, 2002               [Page 1]


DRAFT         ICMPv6 node info query for reverse DNS lookup    June 2002

(distribution of TSIG authentication keys).  Also, reverse DNS lookup
based on PTR record can cause more delay to applications than IPv4 case,
as an IPv6 reverse DNS mapping requires much more of NS indirections (34
levels rather than 6 levels).

Another problem is that DNS PTR records do not support scoped IPv6
addresses well, as DNS infrastructure is global in nature and there is
no way to differentiate between scope zones.

For this reason, this document discusses an alternative way to provide
reverse DNS lookups.  The approach uses ICMPv6 node information
query/reply [Crawford, 2002] .

2.  Protocol

There are two parties: querier and responder.  The querier knows an IPv6
address of the responder, and is interested in getting fully-qualified
DNS name for the responder,

Querier transmits the following ICMPv6 node information query packet to
the reponder's address:

     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 must be sent on replies.  If DNS name on the
  reply is a single-component name, the querier should ignore the
  response.

o Administrators are advised to provide consistent reverse mapping with
  forward DNS record, where possible.


ITOJUN                 Expires: December 20, 2002               [Page 2]


DRAFT         ICMPv6 node info query for reverse DNS lookup    June 2002

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] .

3.  Appicability

3.1.  Is "DNS name" on the reply 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.  This is also true for reverse DNS mapping
based on PTR records.

3.2.  Consistency with forward DNS records?

We cannot assume consistency with forward DNS records.  It is the same
as DNS PTR records.

With scoped IPv6 address, it is not possible to keep consistency between
forward and reverse mapping (both with DNS PTR records and ICMPv6 node
information queries), as it is discouraged to put scoped IPv6 address
into global DNS database, and there is no DNS PTR delegation for scoped
IPv6 addresses.

3.3.  Number of configured elements?

With DNS PTR records, the reverse address mapping needs to be configured
on DNS server.  With ICMPv6 node information query, all nodes need to be
configured with fully-qualified DNS name.

3.4.  Interaction with scoped IPv6 addresses

DNS PTR records do not support scoped IPv6 addresses well, due to the
following reasons:

o DNS database is a global database in nature, and does not fit well
  with scoped IPv6 address.

o ip6.arpa (or ip6.int) delegation structure does not deal with scoped
  delegation.



ITOJUN                 Expires: December 20, 2002               [Page 3]


DRAFT         ICMPv6 node info query for reverse DNS lookup    June 2002

o The view of scope zones differs from nodes to nodes.  Therefore, if
  the querier node of DNS PTR record is different from the node holding
  DNS PTR database, they have different idea about/access to scope
  zones.

o There is no way to differentiate between scope zones, specifically
  from remote.

ICMPv6 node information query/reply handles scoped IPv6 address well, as
the querier directly tries to obtain reverse name mapping (hence there
is no difference in the view of scope zones).

Even with ICMPv6 node information query/reply, it is not possible to
provide a consistent mapping between forward and reverse lookup for
scoped IPv6 addresses, as DNS wire packet format (AAAA) does not have a
way to identify scope zones.

4.  Security consideration

4.1.  Are there any possibility for forgery?

Yes.  Intermediate nodes can intercept node information query/reply
packet and throw in forged queries/replies.  It is true for DNS
query/reply too.

There are ongoing efforts in DNS arena for data integrity protection -
DNSSEC.  It is a bit hard to do similar thing for node information
query.  DNSSEC is possible because there is NS delegation tree in DNS.
There is no obvious "structure" in node information query.

4.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

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.





ITOJUN                 Expires: December 20, 2002               [Page 4]


DRAFT         ICMPv6 node info query for reverse DNS lookup    June 2002

Acknowledgements

(to be filled)


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]