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