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 >
Text File  |  1997-07-29  |  13KB  |  391 lines
  1.  
  2. IPng Working Group                                         Matt Crawford
  3. Internet Draft                                                  Fermilab
  4.                                                            July 24, 1997
  5.  
  6.                        IPv6 Name Lookups Through ICMP
  7.                 <draft-ietf-ipngwg-icmp-name-lookups-01.txt>
  8.  
  9.  
  10. Status of this Memo
  11.  
  12.     This document is an Internet Draft.  Internet Drafts are working
  13.     documents of the Internet Engineering Task Force (IETF), its Areas,
  14.     and its Working Groups.  Note that other groups may also distribute
  15.     working documents as Internet Drafts.
  16.  
  17.     Internet Drafts are draft documents valid for a maximum of six
  18.     months.  Internet Drafts may be updated, replaced, or obsoleted by
  19.     other documents at any time.  It is not appropriate to use Internet
  20.     Drafts as reference material or to cite them other than as a
  21.     "working draft" or "work in progress."
  22.  
  23.     To learn the current status of any Internet-Draft, please check the
  24.     "1id-abstracts.txt" listing contained in the Internet Drafts Shadow
  25.     Directories on ds.internic.net (US East Coast), nic.nordu.net
  26.     (Europe), ftp.isi.edu (US  West  Coast), or munnari.oz.au (Pacific
  27.     Rim).
  28.  
  29.     Distribution of this memo is unlimited.
  30.  
  31.  
  32.  
  33. 1.  Abstract
  34.  
  35.     IPv4 addresses are translated to fully-qualified domain names
  36.     (FQDNs) using the DNS.  Experience shows that the IN-ADDR.ARPA zones
  37.     used for this translation tend to be poorly maintained in many
  38.     cases.  In a larger internet with more frequent site renumbering,
  39.     the maintenance of such zones will be even more difficult.
  40.  
  41.     This document describes a protocol for simply asking an IPv6 node to
  42.     supply its FQDN when needed.  The DNS style of authority delegation
  43.     is thus eliminated for IPv6 address-to-name translations and the
  44.     routing infrastructure plays that role.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Expires January 24, 1998        Crawford                        [Page 1]
  54. =0C
  55. Internet Draft                Who Are You                  July 24, 1997
  56.  
  57.  
  58. 2.  Terminology
  59.  
  60.     An FQDN "Query" message is sent by a "Querier" node to a "Responder"
  61.     node in an ICMPv6 packet addressed to the "Queried Address."  The
  62.     Responder sends an FQDN "Reply" to the Querier, containing the Fully
  63.     Qualified Domain Name (FQDN) currently associated with the Queried
  64.     Address.
  65.  
  66.     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  67.     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  68.     document are to be interpreted as described in [2119].
  69.  
  70.  
  71. 3.  FQDN Messages
  72.  
  73.     There are two ICMPv6 [1885] FQDN message, the FQDN Query and the
  74.     FQDN Reply.  They have the following format.
  75.  
  76.       0                   1                   2                   3
  77.       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
  78.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  79.      |     Type      |     Code      |           Checksum            |
  80.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  81.      |              ID               |            unused             |
  82.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  83.      |                                                               |
  84.      +                             Nonce                             +
  85.      |                                                               |
  86.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  87.      |                          Time-To-Live                         |
  88.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  89.      |    NameLen    |                   FQDN ...                    |
  90.      +-+-+-+-+-+-+-+-+                                               +
  91.      /                                                               /
  92.      +                                                               +
  93.      |                                                               |
  94.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  95.  
  96.     Fields:
  97.  
  98.     Type        TBA1 - FQDN Query (more pronounceably, Who-Are-You).
  99.                 TBA2 - FQDN Reply.
  100.  
  101.     Code        For FQDN Query, always 0.
  102.                 For FQDN Reply:
  103.  
  104.                 0   Indicates that the Time-To-Live field is meaningful
  105.  
  106.  
  107.  
  108.  
  109. Expires January 24, 1998        Crawford                        [Page 2]
  110. =0C
  111. Internet Draft                Who Are You                  July 24, 1997
  112.  
  113.  
  114.                 1   Indicates that the Responder cannot provide a
  115.                     meaningful TTL for its Address-to-FQDN association.
  116.  
  117.     Checksum    The ICMPv6 checksum.
  118.  
  119.     ID          A 16-bit field to aid in matching replies and requests.
  120.                 Its value is chosen by the Querier and copied from a
  121.                 Request to a Reply by the Responder.
  122.  
  123.     Nonce       An opaque 64-bit field to help avoid spoofing.  Its
  124.                 value is chosen by the Querier and copied from a Request
  125.                 to a Reply by the Responder.
  126.  
  127.     Time-To-Live
  128.                 The number of seconds that the name may be cached.  For
  129.                 compatibility with DNS [1035], this is a 32-bit signed,
  130.                 2's-complement number, which must not be negative.
  131.  
  132.     NameLen     The length in octets of the FQDN, as an 8-bit unsigned
  133.                 integer.
  134.  
  135.     FQDN        The fully-qualified domain name of the Responder which
  136.                 corresponds to the Queried Address, as a sequence of
  137.                 NameLen US-ASCII octets, with periods between the
  138.                 components.
  139.  
  140.     The last three fields (Time-To-Live, NameLen and FQDN) are not
  141.     present in the FQDN Query.
  142.  
  143.  
  144. 4.  Usage Note
  145.  
  146.     To avoid congesting the internet with ICMP FQDN messages, they
  147.     should be sent only by a system capable of caching the replies,
  148.     preferably on behalf of many other potential Queriers.  A logical
  149.     place to do that caching is in DNS servers.  Accordingly, these
  150.     messages should be used as a "back end" to DNS servers, which can
  151.     then present clients with an unchanged interface to the FQDN-lookup
  152.     service.  (Or, the independence from DNS-style delegation can be
  153.     exploited to simplify that interface.)
  154.  
  155.  
  156. 5.  Message Processing
  157.  
  158.     The Querier constructs an FQDN Query and sends it to the address
  159.     whose FQDN is wanted.  The ID field's value is chosen for the
  160.     Querier's convenience, and the Nonce should be a random or good
  161.     pseudo-random value to foil spoofed replies.
  162.  
  163.  
  164.  
  165. Expires January 24, 1998        Crawford                        [Page 3]
  166. =0C
  167. Internet Draft                Who Are You                  July 24, 1997
  168.  
  169.  
  170.     The Responder must set the TTL field of the Reply to a meaningful
  171.     value if possible.  That value should be one of the following.
  172.  
  173.         The remaining lifetime of a DHCP lease on the Queried Address,
  174.  
  175.         The remaining Valid Lifetime of the prefix from which the
  176.         Queried Address was derived through Stateless Autoconfiguration
  177.         [1970, 1971].
  178.  
  179.         The TTL of an existing AAAA record which associates the Queried
  180.         Address with the FQDN being returned.
  181.  
  182.     If the Responder has no meaningful TTL value to return, the ICMPv6
  183.     Code field of the Reply must be set to 1 and the TTL field should be
  184.     set to 0.
  185.  
  186.     The IPv6 source address of the Reply must be the Queried Address.
  187.  
  188.     The Querier must silently discard any Reply whose source address, ID
  189.     and Nonce do not match an outstanding Query.
  190.  
  191.     The information in an FQDN Reply which has an ICMPv6 Code value of 0
  192.     may be cached and used for the period indicated by that TTL.  If a
  193.     Reply has no TTL (ICMPv6 Code 1), the information in that Reply must
  194.     not be used more than once.  If the Query was sent by a DNS server
  195.     on behalf of a DNS client, the result may be returned to that client
  196.     as a DNS response with TTL zero.  However, if the server has the
  197.     matching AAAA record, either in cache or in an authoritative zone,
  198.     then the TTL of that record may be used as the missing TTL of the
  199.     FQDN Reply and the information in the reply may be cached and used
  200.     for that period.
  201.  
  202.     It would be an implementation choice for a server to perform a DNS
  203.     query for the AAAA record that matches a received FQDN Reply.  This
  204.     might be done to obtain a TTL to make the Reply cacheable or in
  205.     anticipation of such a AAAA query from the client that caused the
  206.     FQDN Query.
  207.  
  208.     An ICMP FQDN Query must not be sent to a multicast address.
  209.  
  210.     Any extension headers included in an FQDN Query should not be such
  211.     as to cause the Responder to include more than 260 octets of
  212.     extension headers in the Reply.  This will ensure that the Reply
  213.     does not exceed the minimum IPv6 MTU (576 octets [1883]).
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Expires January 24, 1998        Crawford                        [Page 4]
  222. =0C
  223. Internet Draft                Who Are You                  July 24, 1997
  224.  
  225.  
  226. 6.  Discussion
  227.  
  228.     Because a node can only answer an FQDN Query when it is up and
  229.     reachable, it may be useful to be able to create a proxy Responder
  230.     for a group of nodes, for example a subnet or a site.  Such a
  231.     mechanism is not addressed here.
  232.  
  233.     The interface to DNS should be more fully described.  A simpler
  234.     interface than the reversed-nibbles scheme of the IP6.INT zone could
  235.     be provided to the client by having the DNS server translate PTR
  236.     queries in a new pseudo-domain for names such as
  237.     "5F01250083E100000009080020812B32.IPV6.INT" into FQDN Queries.  Or,
  238.     the same effect could be achieved by a "virtual wildcard" record
  239.     that refers all subdomains of IP6.INT, other than "0" - "9" and "A"
  240.     - "F", to the FQDN Query backend.
  241.  
  242.     Other open DNS-related issues:
  243.  
  244.         What if the RD flag in the DNS query was not set and the server
  245.         does not already have an FQDN Reply cached?
  246.  
  247.         Is an FQDN reply authoritative?  What goes in the Authorities
  248.         section of a constructed DNS reply?
  249.  
  250.     Maybe the right solution is not to try to hide the FQDN backend from
  251.     the DNS client after all.
  252.  
  253.     IPsec could be applied to FQDN messages to achieve greater trust in
  254.     the information obtained, but such a need is probably obviated by
  255.     applying IPsec directly to some other communication which is going
  256.     on (or contemplated) between the Querier and Responder.
  257.  
  258.     The FQDN could be transmitted in DNS series-of-labels form, but why?
  259.     With just a single name allowed as an aswer, we're not after name
  260.     compression.
  261.  
  262.     What does the Querier do when there's no meaningful TTL in the
  263.     Reply?
  264.  
  265.  
  266. 7.  IANA Considerations
  267.  
  268.     The TBA1 and TBA2 ICMPv6 Type values in the range 128 to 255 to
  269.     indicate that these are informational messages.  After assignment of
  270.     Type values, this section of this document may be deleted.
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277. Expires January 24, 1998        Crawford                        [Page 5]
  278. =0C
  279. Internet Draft                Who Are You                  July 24, 1997
  280.  
  281.  
  282. 8.  Security Considerations
  283.  
  284.     The anti-spoofing Nonce does not give any protection from spoofers
  285.     who can snoop the Query or the Reply.
  286.  
  287.     In a large Internet with relatively frequent renumbering, the
  288.     maintenance of of KEY and SIG records [2065] in the zones used for
  289.     address-to-name translations will be no easier than the maintenance
  290.     of the NS, SOA and PTR records themselves, which already appears to
  291.     be difficult in many cases.  The author expects, therefore, that
  292.     address-to-name mappings, either through the original DNS mechanism
  293.     or through this new mechanism, will generally be used as only a hint
  294.     to find more trustworthy information using the returned name as an
  295.     index.
  296.  
  297.  
  298. 9.  Acknowledgments
  299.  
  300.     This document is not the first proposal of a direct query mechanism
  301.     for address-to-name translation.  The idea was discussed and
  302.     deferred in the IPng working group and an experimental RFC [1788]
  303.     describes such a mechanism for IPv4.
  304.  
  305.  
  306. 10.  References
  307.  
  308.  
  309.     [1035]  P. Mockapetris, "Domain Names - Implementation and
  310.             Specification", RFC 1035, STD 13.
  311.  
  312.  
  313.     [1788]  W. Simpson, "ICMP Domain Name Messages", RFC 1788.
  314.  
  315.  
  316.     [1883]  S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
  317.             Specification", RFC 1883.
  318.  
  319.  
  320.     [1885]  A. Conta, S. Deering, "Internet Control Message Protocol
  321.             (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC
  322.             1885.
  323.  
  324.  
  325.     [1970]  T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for
  326.             IP Version 6 (IPv6)", RFC 1970.
  327.  
  328.  
  329.     [1971]  S. Thomson, T. Narten, "IPv6 Stateless Address
  330.  
  331.  
  332.  
  333. Expires January 24, 1998        Crawford                        [Page 6]
  334. =0C
  335. Internet Draft                Who Are You                  July 24, 1997
  336.  
  337.  
  338.             Autoconfiguration", RFC 1971.
  339.  
  340.  
  341.     [2065]  D. Eastlake, C. Kaufman, "Domain Name System Security
  342.             Extensions", RFC 2065.
  343.  
  344.  
  345.     [2119]  S. Bradner, "Key words for use in RFCs to Indicate
  346.             Requirement Levels," RFC 2119.
  347.  
  348.  
  349. 11.  Author's Address
  350.  
  351.     Matt Crawford
  352.     Fermilab MS 368
  353.     PO Box 500
  354.     Batavia, IL 60510
  355.     USA
  356.  
  357.     Phone: +1 630 840 3461
  358.  
  359.     Email: crawdad@fnal.gov
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389. Expires January 24, 1998        Crawford                        [Page 7]
  390.  
  391.