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-linkname-00.txt < prev    next >
Text File  |  1996-06-06  |  20KB  |  594 lines
  1.  
  2. INTERNET-DRAFT                                             D. Harrington
  3. Internet Draft                                    Digital Equipment Corp
  4.  
  5.  
  6.  
  7.            Link Local Addressing and Name Resolution in IPv6
  8.  
  9.                   <draft-ietf-ipngwg-linkname-00.txt>
  10.  
  11.  
  12. Abstract
  13.  
  14.    This draft proposes an experimental mechanism by which IPv6 link-local
  15.    addresses and associated system names may be distributed among
  16.    interconnected hosts, for use by users and applications.  It
  17.    provides an overview of the problem, a proposed solution (including
  18.    suggested protocol details), and lists various related issues.
  19.    This work is introduced to the IPng Working Group initially, 
  20.    although it might also have implications or concerns relevant 
  21.    to individuals working on directory services and other areas.
  22.  
  23. Status of this Memo
  24.  
  25.    This document is a submission to the IPng Working Group of the
  26.    Internet Engineering Task Force (IETF).  Comments should be submitted
  27.    to the ipng@sunroof.eng.sun.com mailing list.  This document is not
  28.    at this time a product of the IPng Working Group, but a proposal to
  29.    become a product of the IPng Working Group.
  30.  
  31.    This document is an Internet-Draft.  Internet-Drafts are working
  32.    documents of the Internet Engineering Task Force (IETF), its areas,
  33.    and its working groups.  Note that other groups may also distribute
  34.    working documents as Internet-Drafts.
  35.  
  36.    Internet-Drafts are draft documents valid for a maximum of six months
  37.    and may be updated, replaced, or obsoleted by other documents at any
  38.    time.  It is inappropriate to use Internet-Drafts as reference
  39.    material or to cite them other than as ``work in progress.''
  40.  
  41.    To learn the current status of any Internet-Draft, please check the
  42.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  43.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  44.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  45.    ftp.isi.edu (US West Coast).
  46.  
  47.    Distribution of this document is unlimited.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Harrington      Expires December 1996                           [Page 1]
  65.  
  66.  
  67. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  68.  
  69.  
  70.    Table of Contents:
  71.  
  72.  
  73.  
  74.  
  75.    1. Introduction.................................................3
  76.    2. Terminology and Definitions..................................3
  77.    3. Design Goals.................................................4
  78.    4. Proposed Protocol............................................4
  79.       4.1 Server Processing and Advertisements.....................4
  80.       4.2 Client Processing and Requests...........................5
  81.    5. Interaction with DNS and resolver routines...................7
  82.    6. Alternative uses.............................................7
  83.    7. Multilink issues.............................................7
  84.    8. Security Issues..............................................8
  85.       Acknowledgements.............................................9
  86.       References...................................................9
  87.       Author's Address.............................................9
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125.  
  126.  
  127.  
  128.  
  129.  
  130. Harrington      Expires December 1996                           [Page 2]
  131.  
  132.  
  133. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  134.  
  135.  
  136. 1. Introduction
  137.  
  138.       One aspect of IP Version 6 which is somewhat novel is the "plug-
  139.       and-play" capability, in which a system may be interconnected with
  140.       other IPv6 systems without the need for formal configuration.  In
  141.       particular, the use of autonomically created link-local addresses,
  142.       which are limited in scope to the physical link to which the
  143.       system is connected, is meant to support this goal.  This is
  144.       sometimes referred to informally as the "dentist's office"
  145.       scenario.  In fact, early experience at the interoperability
  146.       bakeoff at the University of New Hampshire this past February
  147.       (1996) showed that to a large degree this goal is achieved;
  148.       systems from multiple vendors were interconnected to an Ethernet,
  149.       and in the absence of any routers were able to communicate with
  150.       neighboring systems.
  151.  
  152.       One capability which is lacking in this case, however, is a simple
  153.       name to address (and inverse) lookup function.  While it is a
  154.       simple matter to add support to existing resolver routines to
  155.       support the lookup of IPv6 addresses from a local ASCII file (e.g.
  156.       /etc/hosts), it is extremely inconvenient to determine the link-
  157.       local addresses and names of all adjacent systems, and enter this
  158.       information into said file.  Also, using a manual mechanism such
  159.       as this is error prone and may quickly become stale.  Clearly, an
  160.       automated means of distributing this information is called for.
  161.  
  162.       This draft proposes that an IPv6 systems, when utilizing an
  163.       interface which supports the link-local model, advertise its name
  164.       and associated link-local IPv6 address to a multicast group of
  165.       link-local scope, using a simple protocol over UDP.  It also
  166.       allows a system to send a query for a particular name or address
  167.       to the group, which may be responded to by the system matching the
  168.       given item.  The effects of multilink hosts, interactions with
  169.       name resolving services, and security concerns are discussed.
  170.  
  171.  
  172.  
  173.  
  174. 2. Terminology and Definitions
  175.  
  176.          link       - a communication facility or medium over which nodes can
  177.                       communicate at the link layer, i.e., the layer
  178.                       immediately below IPv6.  Examples are Ethernets (simple
  179.                       or bridged); PPP links; X.25, Frame Relay, or ATM
  180.                       networks; and internet (or higher) layer "tunnels",
  181.                       such as tunnels over IPv4 or IPv6 itself.
  182.  
  183.          neighbors  - nodes attached to the same link.
  184.  
  185.          interface  - a node's attachment to a link.
  186.  
  187.          link-local - An address formed during interface initialization,
  188.           address     composed of the well known prefix FE80:: and a media
  189.                       specific token.  This address is limited in scope to
  190.                       the link and may not be forwarded by a router.
  191.  
  192.          resolver   - A program which retrieves information from name servers
  193.                       in response to client requests.  It is typically
  194.  
  195.  
  196. Harrington      Expires December 1996                           [Page 3]
  197.  
  198.  
  199. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  200.  
  201.  
  202.                       available as a system or library call to a program.
  203.  
  204.          Multilink  - A system which has multiple link interfaces and multiple
  205.                       IPv6 addresses.  Note that the different interfaces may
  206.                       or may not be connected to the same physical media, or
  207.                       even the same media type.
  208.  
  209.  
  210.  
  211.  
  212. 3. Design Goals
  213.  
  214.       The goal of this proposal is to provide a way to advertise and use
  215.       names and link local addresses among IPv6 hosts.  It is also a
  216.       goal to keep this addressing information OUT of the DNS/BIND
  217.       server's data file, as it is almost impossible for such a server
  218.       to know if providing such an address is appropriate, without the
  219.       server having to keep much too much information about the relative
  220.       location of both the client system and the requested hostname.
  221.  
  222.       The proposed protocol is deliberately simple and limited.  It has
  223.       some elements in common with the Service Location protocol, and it
  224.       may be worth investigating the relationship between the two,
  225.       especially as Service Location adds support for IPv6.  Finally,
  226.       the implementation of this mechanism will also serve to exercise
  227.       other elements IPv6 systems, in particular multicast support and
  228.       the BSD API interface.  For these reasons it is requested that
  229.       this protocol be considered Experimental.
  230.  
  231.  
  232.  
  233. 4. Proposed Protocol
  234.  
  235.       There are two aspects to implementing a simple name to address
  236.       function: providing local name and address information (server),
  237.       and requesting and storing remote name or address information
  238.       (client).  An IPv6 system SHOULD provide the server functionality,
  239.       in order to distribute its own information to others.  A system
  240.       MAY wish to be a client, in order to learn and use the information
  241.       of neighbors.
  242.  
  243.       In order to participate in this service, a system must join the
  244.       IPv6 multicast group FF02::<TBD>, which has link-local scope.  The
  245.       UDP port <TBD> is reserved for use of this protocol.
  246.  
  247.  
  248.  
  249.    4.1 Server Processing and Advertisements
  250.  
  251.       A system SHOULD advertise its system name (non-fully qualified,
  252.       i.e. no domains, just a simple hostname) and the associated link
  253.       local address over each of its interfaces, along with an
  254.       indication of how long the information should be considered valid.
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262. Harrington      Expires December 1996                           [Page 4]
  263.  
  264.  
  265. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  266.  
  267.  
  268.         3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
  269.         1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  270.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  271.        |    Version    |     A D V     |R e s e r v e d|  L E N G T H  |
  272.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  273.        | S e q u e n c e   N u m b e r |           T T L               |
  274.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  275.        | Link Local Address                                            |
  276.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  277.        |                                                               |
  278.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  279.        |                                                               |
  280.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  281.        |                                                               |
  282.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  283.        | Simple hostname...                                            |
  284.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  285.        |                                                               |
  286.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  287.        |                                                               |
  288.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  289.  
  290.       Fields:
  291.  
  292.  
  293.                   Version - Sent as 1
  294.  
  295.                   TTL - value from 0000 to FFFF (see description below)
  296.  
  297.                   Sequence Number - A value to be used by clients in matching
  298.                         requests to responses.  For a periodic
  299.                         (i.e. unsolicited) advertisement, should be 0.  For
  300.                         responses to explicit requests the value from the
  301.                         request should be copied.
  302.  
  303.  
  304.       A TTL value of 0 indicates that the name/address pair is no longer
  305.       to be considered valid, and should be flushed from any long-term
  306.       storage on remote systems.  A TTL value of 0xFFFF indicates an
  307.       infinite value, and clients are permitted to treat the
  308.       name/address pair as permanent, obviating the need to time out the
  309.       entry.
  310.  
  311.       The Length field indicates the total length of the packet in
  312.       octets.
  313.  
  314.       A system may transmit these packets solely at discrete intervals,
  315.       or only in response to specific requests.  However, a mixture of
  316.       these two models (i.e. periodic advertisements, with direct
  317.       response to queries) would probably be the most reasonable
  318.       solution.
  319.  
  320.  
  321.  
  322.    4.2 Client Processing and Requests
  323.  
  324.       A system may operate in a purely reactionary mode to user
  325.       requests, with no caching of learned information, but it may well
  326.  
  327.  
  328. Harrington      Expires December 1996                           [Page 5]
  329.  
  330.  
  331. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  332.  
  333.  
  334.       choose to record any advertised name/address bindings received.
  335.       If information is stored, then the values of the TTL field in
  336.       responses must be respected, and the associated information dealt
  337.       with accordingly.  The following table shows possible TTL values,
  338.       and how they affect recording client systems.
  339.  
  340.               TTL Value                 Action
  341.               1<n<FFFE         Keep track of time
  342.               FFFF             Permanent (no need to keep track of time)
  343.               0                Stale, flush existing entry.
  344.  
  345.       The following items should be considered when verifying a received
  346.       advertisement.
  347.  
  348.             - minimum packet length = 20. octets
  349.             - maximum packet length = maximum UDP limit on specific link
  350.             - Version value must be 1.
  351.             - non link-local address (wrong prefix or token length)
  352.               discarded
  353.             - zero length names discarded.
  354.             - Unrecognized packet types ignored/discarded
  355.  
  356.       A system may also request a name or address value, via the
  357.       following request packet:
  358.  
  359.         3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
  360.         1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  361.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  362.        |    Version    |    R Q S T    |    T Y P E    |  L E N G T H  |
  363.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  364.        | S e q u e n c e   N u m b e r |        R e s e r v e d        |
  365.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.        | Link Local Address                                            |
  367.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.        |                                                               |
  369.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  370.        |                                                               |
  371.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  372.        |                                                               |
  373.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  374.        | Simple hostname...                                            |
  375.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  376.        |                                                               |
  377.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  378.        |                                                               |
  379.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  380.  
  381.           Version - Send as 1.
  382.  
  383.           RQST - Request Information (2.)
  384.  
  385.           TYPE
  386.               Name (1.)      Request a name for the given address.
  387.               Address (2.)   Request an address for the given name.
  388.  
  389.       If a Name is requested, then the address field must be set to a
  390.       valid link-local address for the given media type, and the
  391.       hostname field must be empty (i.e. of length zero).  If an address
  392.  
  393.  
  394. Harrington      Expires December 1996                           [Page 6]
  395.  
  396.  
  397. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  398.  
  399.  
  400.       is requested, then the address field must be set to all zeroes,
  401.       and the hostname field must contain a non-null entry.  The Length
  402.       field indicates the total length of the packet in octets.
  403.  
  404.  
  405.  
  406.  
  407. 5. Interaction with DNS and resolver routines
  408.  
  409.       To be useful and available to applications and users, the names
  410.       and addresses made available using this protocol must be
  411.       integrated to some extent with the host's name resolving software.
  412.       While it might be envisioned that this could be done in a
  413.       simplistic fashion, by adding and mainting entries in the local
  414.       storage (e.g. the "/etc/hosts" file), it would be more appropriate
  415.       to utilize dynamic storage for link local addresses.  In fact, it
  416.       may well be useful to define a special category to this type of
  417.       address, given its restricted capabilities.  A special pseudo-
  418.       domain, such as ".link", would be a very useful mechanism, both
  419.       for the unambiguous representation of these names, and as a system
  420.       configuration mechanism (e.g. the resolving software could be
  421.       configured to return address in the order BIND/LOCAL/LINK).
  422.  
  423.  
  424.  
  425. 6. Alternative uses
  426.  
  427.       Using this protocol for other purposes, such as a means of making
  428.       a host's neighbors visible to the host's users, as a simplistic
  429.       network management tool, is a possible extension of this
  430.       application.  Such uses are not defined in this specification.
  431.  
  432.       It is also unclear if link-local name servers should be permitted,
  433.       in which one system provides answers on behalf of another.  This
  434.       would require some sort of "proxy bit" in the Advertisement
  435.       message.
  436.  
  437.  
  438.  
  439. 7. Multilink issues
  440.  
  441.       There are two sets of issues to consider, those of the multilink
  442.       server, and those of the client in a multilink environment.
  443.  
  444.       For the multilink system to accurately provide name and addressing
  445.       information, it is merely necessary to restrict the advertisement
  446.       of addressing information for a particular address to the
  447.       interface to which the address is assigned.
  448.  
  449.       Any client may have a multilink neighbor, and thus SHOULD be
  450.       prepared to deal with a single name being resolved to multiple
  451.       addresses.  In practice, this could be handled in the same way as
  452.       any fully qualified hostname returning multiple addresses,
  453.       although returning the address with the largest TTL, or the first
  454.       received address, may be considered.
  455.  
  456.       A client which is itself multilink may need to store the received
  457.       interface along with the name/address pair.  Not enough is known
  458.  
  459.  
  460. Harrington      Expires December 1996                           [Page 7]
  461.  
  462.  
  463. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  464.  
  465.  
  466.       of multilink behaviour to state this with certainty, however.
  467.  
  468.  
  469.  
  470.  
  471. 8. Security Issues
  472.  
  473.       This proposal provides no additional mechanism for security, above
  474.       and beyond the ability to disable this particular function.  It
  475.       might be extreme naivete on the part of the author, but he cannot
  476.       fathom any potential security risk in providing a simple name
  477.       associated with an easily obtainable address of limited scope.
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526. Harrington      Expires December 1996                           [Page 8]
  527.  
  528.  
  529. INTERNET-DRAFT     draft-ietf-ipngwg-linkname-00.txt            June 1996
  530.  
  531.  
  532.    Acknowledgements
  533.  
  534.    Thanks to the members of the Digital UNIX IPv6 team, and the
  535.    reviewers.  Also, it has been brought to my attention that RFC 1788
  536.    [DOMAIN-MESSAGES], by William Simpson, uses similar techniques at a
  537.    different level (ICMP) to solve a problem of greater scope; although
  538.    it was not used in the initial design of this mechanism, it was very
  539.    useful during initial review of this draft.  In particular, the
  540.    Sequence Number field was borrowed.
  541.  
  542.  
  543.  
  544.  
  545. References
  546.  
  547.     [ADDR-ARCH]    R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
  548.                    Addressing Architecture", RFC1884.
  549.  
  550.     [ADDRCONF]      S. Thompson and T. Narten, "IPv6 Stateless Address
  551.                     Autoconfiguration", work in progress, December 1995,
  552.                     draft-ietf-addrconf-ipv6-auto-07.txt
  553.  
  554.     [DNS-CONCEPTS]  P. Mockapetris, "Domain names - concepts and facilities",
  555.                     STD-13.
  556.  
  557.     [MULTILINK]     M. Shand and M. Thomas, "Multihoming Support in IPv6",
  558.                     work in progress, February 1996,
  559.                     draft-shand-ipv6-multi-homing-00.txt
  560.  
  561.     [DOMAIN-MESSAGES]  W. Simpson, "ICMP Domain Name Messages", RFC 1788.
  562.  
  563.  
  564.  
  565. Author's Address
  566.  
  567.     Dan Harrington
  568.     Digital Equipment Corporation
  569.     550 King Street, LKG2-2/Q5
  570.     Littleton, MA 01460
  571.     Phone: (508) 486-7643
  572.     Email: dan@lkg.dec.com
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592. Harrington      Expires December 1996                           [Page 9]
  593.  
  594.