home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ipngwg-icmp-namelookups-01.txt
< prev
next >
Wrap
Text File
|
1997-07-29
|
13KB
|
391 lines
IPng Working Group Matt Crawford
Internet Draft Fermilab
July 24, 1997
IPv6 Name Lookups Through ICMP
<draft-ietf-ipngwg-icmp-name-lookups-01.txt>
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 many
cases. In a larger internet with more frequent site renumbering,
the maintenance of such zones will be even more difficult.
This document describes a 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.
Expires January 24, 1998 Crawford [Page 1]
=0C
Internet Draft Who Are You July 24, 1997
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
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].
3. FQDN Messages
There are two ICMPv6 [1885] 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 (more pronounceably, Who-Are-You).
TBA2 - FQDN Reply.
Code For FQDN Query, always 0.
For FQDN Reply:
0 Indicates that the Time-To-Live field is meaningful
Expires January 24, 1998 Crawford [Page 2]
=0C
Internet Draft Who Are You July 24, 1997
1 Indicates that the Responder cannot provide a
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
components.
The last three fields (Time-To-Live, NameLen and FQDN) are not
present in the FQDN Query.
4. Usage Note
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. (Or, the independence from DNS-style delegation can be
exploited to simplify that interface.)
5. Message Processing
The Querier constructs an FQDN Query and sends it to the 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.
Expires January 24, 1998 Crawford [Page 3]
=0C
Internet Draft Who Are You July 24, 1997
The Responder must set the TTL field of the Reply to 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 the prefix from which the
Queried Address was derived through Stateless Autoconfiguration
[1970, 1971].
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 ICMP FQDN Query must not be sent to a multicast address.
Any extension headers included in an FQDN Query should not be such
as to cause the Responder to include more than 260 octets of
extension headers in the Reply. This will ensure that the Reply
does not exceed the minimum IPv6 MTU (576 octets [1883]).
Expires January 24, 1998 Crawford [Page 4]
=0C
Internet Draft Who Are You July 24, 1997
6. Discussion
Because a node can only answer an FQDN Query when it is up and
reachable, it may be useful to be able to create a proxy Responder
for a group of nodes, for example a subnet or a site. Such a
mechanism is not addressed here.
The interface to DNS should be more fully described. A simpler
interface than the reversed-nibbles scheme of the IP6.INT zone could
be provided to the client by having the DNS server translate PTR
queries in a new pseudo-domain for names such as
"5F01250083E100000009080020812B32.IPV6.INT" into FQDN Queries. Or,
the same effect could be achieved by a "virtual wildcard" record
that refers all subdomains of IP6.INT, other than "0" - "9" and "A"
- "F", to the FQDN Query backend.
Other open DNS-related issues:
What if the RD flag in the DNS query was not set and the server
does not already have an FQDN Reply cached?
Is an FQDN reply authoritative? What goes in the Authorities
section of a constructed DNS reply?
Maybe the right solution is not to try to hide the FQDN backend from
the DNS client after all.
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.
The FQDN could be transmitted in DNS series-of-labels form, but why?
With just a single name allowed as an aswer, we're not after name
compression.
What does the Querier do when there's no meaningful TTL in the
Reply?
7. IANA Considerations
The TBA1 and TBA2 ICMPv6 Type values in the range 128 to 255 to
indicate that these are informational messages. After assignment of
Type values, this section of this document may be deleted.
Expires January 24, 1998 Crawford [Page 5]
=0C
Internet Draft Who Are You July 24, 1997
8. 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.
9. 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.
10. References
[1035] P. Mockapetris, "Domain Names - Implementation and
Specification", RFC 1035, STD 13.
[1788] W. Simpson, "ICMP Domain Name Messages", RFC 1788.
[1883] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883.
[1885] A. Conta, S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC
1885.
[1970] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 1970.
[1971] S. Thomson, T. Narten, "IPv6 Stateless Address
Expires January 24, 1998 Crawford [Page 6]
=0C
Internet Draft Who Are You July 24, 1997
Autoconfiguration", RFC 1971.
[2065] D. Eastlake, C. Kaufman, "Domain Name System Security
Extensions", RFC 2065.
[2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
11. 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 January 24, 1998 Crawford [Page 7]