INTERNET-DRAFT                                             D.IPng Working Group                                        Dan Harrington
Internet Draft                                    Digital Equipment Corp                                       Lucent Technologies
                                                            January 1997

           Link Local Addressing and Name Resolution in IPv6

                  <draft-ietf-ipngwg-linkname-00.txt>

                   draft-ietf-ipngwg-linkname-01.txt

Abstract

   This draft proposes an experimental mechanism by which IPv6
   link-local addresses and associated system names may be distributed
   among interconnected hosts, for use by users and applications.  It
   provides an overview of the problem, a proposed solution (including
   suggested protocol details), and lists various related issues. This
   work is introduced to the IPng Working Group initially, although it
   might also have implications or concerns relevant to individuals
   working on directory services and other areas.

Status of this This Memo

   This document is a submission to the IPng Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be
   submitted to the ipng@sunroof.eng.sun.com mailing list.

   This document is not
   at this time a product of the IPng Working Group, but a proposal to
   become a product of the IPng Working Group.

   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 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 learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

Table of Contents: Of Contents

       1. Introduction.................................................3 Introduction                                                 3
       2. Terminology and Definitions..................................3 Definitions                                  3
       3. Design Goals.................................................4 Goals                                                 4
       4. Proposed Protocol............................................4
      4.1 Protocol                                            4
          4.1. Server Processing and Advertisements.....................4
      4.2 Advertisements                    4
          4.2. Client Processing and Requests...........................5 Requests                          5
       5. Interaction with DNS and resolver routines...................7 routines                   7
       6. Alternative uses.............................................7
   7. Multilink issues.............................................7 issues                                             8
       7. Duplicate Names/Addresses                                    8
       8. Alternative uses                                             9
       9. Security Issues..............................................8
      Acknowledgements.............................................9
      References...................................................9 Issues                                              9
       10. Acknowledgements                                            9
       11. References                                                  9
       12. Author's Address.............................................9 Address                                           10

1. Introduction

   One aspect of IP Version 6 which is somewhat novel is the "plug-
      and-play"
   "plug-and-play" capability, in which a system may be interconnected
   with other IPv6 systems without the need for formal configuration.
   In particular, the use of autonomically created link-local
   addresses, which are limited in scope to the physical link to which
   the system is connected, is meant to support this goal.  This is
   sometimes referred to informally as the "dentist's office" scenario.  In fact, early
   Early experience at the interoperability
      bakeoff at the University of New Hampshire this past February
      (1996) showed interoperability
   bakeoffs has shown that to a large degree this goal is achieved;
      systems
   hosts from multiple vendors were interconnected to an Ethernet, and
   in the absence of any routers were able to communicate with
   neighboring systems.

   One capability which is lacking in this case, however, is a simple
   name to address (and inverse) lookup function.  While it is a simple
   matter to add support to existing resolver routines to support the
   lookup of IPv6 addresses from a local ASCII file (e.g. /etc/hosts),
   it is extremely inconvenient to determine the link-
      local link-local addresses
   and names of all adjacent systems, and enter this information into
   said file.  Also, using a manual mechanism such as this is error prone to
   data input errors, and the data itself may quickly become stale.
   Clearly, an automated means of distributing this information is
   called for.

   This draft proposes that an IPv6 systems, system, when utilizing an interface
   which supports the link-local model, advertise its name and
   associated link-local IPv6 address to a multicast group of
   link-local scope, using a simple protocol over UDP.  It also allows
   a system to send a query for a particular name or address to the
   group, which may be responded to by the system matching the given
   item.  In this model, there is no central server; each system
   provides information about its own configuration. The effects of
   multilink hosts, interactions with name resolving services, and
   security concerns are discussed.

2. Terminology and Definitions

   link       -            a communication facility or medium over which nodes
                   can communicate at the link layer, i.e., the layer
                   immediately below IPv6.  Examples are Ethernets
                   (simple or bridged); PPP links; X.25, Frame Relay,
                   or ATM networks; and internet (or higher) layer
                   "tunnels", such as tunnels over IPv4 or IPv6 itself.

   neighbors  -       nodes attached to the same link.

   interface  -       a node's attachment to a link.

   link-local - address
                   An address formed during interface initialization,
          address
                   composed of the well known prefix FE80:: and a media
                   specific token.  This address is limited in scope to
                   the link and may not be forwarded by a router.

   resolver   -        A program which retrieves information from name
                   servers in response to client requests.  It is
                   typically available as a system or library call to a
                   program.

         Multilink  -

   multilink       A system which has multiple link interfaces and
                   multiple IPv6 addresses.  Note that the different
                   interfaces may or may not be connected to the same
                   physical media, or even the same media type.

   FQDN            Fully Qualified Domain Name

3. Design Goals

   The goal of this proposal is to provide a way to advertise and use
   names and link local addresses among IPv6 hosts.  It is also a goal
   to keep this addressing information OUT of the DNS/BIND server's
   data file, as it is almost impossible for such a server to know if
   providing such an address is appropriate, without the server having
   to keep much too much ascertain an inappropriate amount of information about the
   relative location of both the client system and the requested
   hostname.

   The proposed protocol is deliberately simple and limited.  It has
   some elements in common with the Service Location protocol, and it
   may be worth investigating the relationship between the two,
   especially as Service Location adds support for IPv6.  Finally, the
   implementation of this mechanism will also serve to exercise other
   elements of IPv6 systems, in particular multicast support and the
   BSD API interface. For these reasons it is requested that this
   protocol be considered Experimental. Experimental at this point.

4. Proposed Protocol

   There are two aspects to implementing a simple name to address
   function: providing local name and address information (server), and
   requesting and storing remote name or address information (client).
   An IPv6 system SHOULD provide the server functionality, in order to
   distribute its own information to others.  A system MAY wish to be a
   client, in order to learn and use the information of neighbors.

   In order to participate in this service, a system must join the IPv6
   multicast group FF02::<TBD>, FF02::1:1, which has link-local scope. The UDP port <TBD>
   1903 is reserved for use of this protocol.

   4.1

4.1. Server Processing and Advertisements

   A system SHOULD advertise its system name (non-fully qualified,
      i.e. no domains, just a simple hostname) and the associated link
   local address over each of its interfaces, along with an indication
   of how long the information should be considered valid.

        3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
        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

   A system may transmit these packets solely at discrete intervals, or
   only in response to specific requests.  However, a mixture of these
   two models (i.e. periodic advertisements, with direct response to
   queries) would probably be the most reasonable solution.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |     A D V     |R e s e r v e d|  L E N G T H  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | S e q u e n c e   N u m b e r |           T T L               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Link Local Address                                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Simple hostname...                                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Figure 1

   Fields:

       Version - Sent as 1

       ADV (1.) - Advertise name/address information

       TTL - value from 0000 to FFFF (see description below)

       Sequence Number - A value to be used by clients in matching
             requests to responses.  For a periodic
             (i.e. unsolicited) advertisement, should be 0.  For
             responses to explicit requests the value from the
             request should be copied.

   A TTL value of 0 indicates that the name/address pair is no longer
   to be considered valid, and should be flushed from any long-term or
   temporary storage on remote systems.  A TTL value of 0xFFFF
   indicates an infinite value, and clients are permitted to treat the
   name/address pair as permanent, obviating the need to time out the
   entry.

   The Length field indicates the total length of the packet in
      octets. octets,
   and may be used to determine the length of the enclosed hostname.

4.2. Client Processing and Requests

   A system may transmit these packets solely at discrete intervals,
      or only operate in response to specific requests.  However, a mixture of
      these two models (i.e. periodic advertisements, with direct
      response to queries) would probably be the most reasonable
      solution.

   4.2 Client Processing and Requests

      A system may operate in a purely reactionary mode to user
      requests, with no caching purely reactionary mode to user requests,
   with no caching of learned information, but it may well choose to
   record any advertised name/address bindings received. If information
   is stored, then the values of the TTL field in responses must be
   respected, and the associated information dealt with accordingly.
   The following table shows possible TTL values, and how they affect
   recording client systems.

           TTL Value                 Action
           1<n<FFFE         Keep track of time
           FFFF             Permanent (no need to keep track of time)
           0                Stale, flush existing entry.

   The following items should be considered when verifying a received
   advertisement.

         - minimum packet length = 20. octets
         - maximum packet length = maximum UDP limit on specific link
         - Version value must be 1.
         - non link-local address (wrong prefix or token length)
           discarded
         - zero length names discarded.
         - Unrecognized packet types ignored/discarded

   A system may also request a name or address value, via the following
   request packet:

        3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
        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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |    R Q S T    |    T Y P E    |  L E N G T H  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | S e q u e n c e   N u m b e r |        R e s e r v e d        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Link Local Address                                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Simple hostname...                                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                Figure 2

       Version - Send as 1.

       RQST - Request Information (2.)

       TYPE
           Name (1.)      Request a name for the given address.
           Address (2.)   Request an address for the given name.

   If a Name is requested, then the address field must be set to a
   valid link-local address for the given media type, and the hostname
   field must be empty (i.e. of length zero). If an address is
   requested, then the address field must be set to all zeroes, and the
   hostname field must contain a non-null entry. The Length field
   indicates the total length of the packet in octets.

5. Interaction with DNS and resolver routines

   To be useful and available to applications and users, the names and
   addresses made available using this protocol must be integrated to
   some extent with the host's name resolving software.  While it might
   be envisioned that this could be done in a simplistic fashion, by
   adding and mainting entries in the local storage (e.g. the
   "/etc/hosts" file), it would be more appropriate to utilize dynamic
   storage for link local addresses.  In fact, it

   It may well be useful to define a special category to this type of
   address, given its restricted capabilities.  A special pseudo-
      domain,
   pseudo-domain, such as ".link", would be a very useful mechanism,
   both for the unambiguous representation of these names, and as a
   system configuration mechanism (e.g. the resolving software could be
   configured to return address in the order BIND/LOCAL/LINK).

6. Alternative uses

      Using  It
   should be noted that while this protocol service returns naming information
   via the resolver software, the names are not BIND names, although
   they can be expressed in a similar style using the same restrictions
   and conventions.

   Question for other purposes, IANA: would it be possible to get such as a means pseudo-TLD
   assigned?

   The general rule of making thumb for requesting and supplying naming
   information should be to make requests as general as possible, and
   provide answers that are as specific as possible.  For example,
   consider two systems which are connected to a host's neighbors visible common link, neither
   configured to the host's users, use DNS, named portia and jessica.  Their unicast link
   local addresses are represented as <hostname-LL>.  Their exchange
   would take the following form:

   Example 1: Simple Request/Response, no DNS

   	portia tx ==> FF02::1:1
   		RQST, Type = 2
   		ADDR = 0::0
   		NAME = jessica

   	jessica tx ==> <portia-LL>
   		ADV
   		ADDR = <jessica-LL>
   		NAME = jessica.link

   Should these same two systems be configured to use DNS in the
   eng.acme.com domain, the exchange could take the following form:

   Example 2: Request/Response, DNS configured

   	portia.eng.acme.com tx ==> FF02::1:1
   		RQST, Type = 2
   		ADDR = 0::0
   		NAME = jessica

   	jessica.eng.acme.com tx ==> <portia-LL>
   		ADV
   		ADDR = <jessica-LL>
   		NAME = jessica.eng.acme.com.link

   Question for discussion: is including the full DNS name a simplistic
      network management tool, case of
   providing too much information?  In the example above, it might be
   better to return only "jessica.eng.link", which indicates a
   subdomain of the system's FQDN, but it is unclear that a system
   would be able to properly distinguish amongst the available levels.
   It might be possible extension of to use the "ndots" resolver configuration
   mechanism, or to create an analogous device for this
      application.  Such uses purpose.  On
   the other hand, the FQDN information, while perhaps overkill, is
   definitive.

   Another issue involves making sure that inappropriate requests are
   not defined made, which would needlessly query local systems in this specification.

      It is also unclear if link-local order to
   attempt resolution of a name servers should be permitted,
      in which one system provides answers on behalf of another.  This is not locally available.  In
   general, it would require some sort of "proxy bit" in make sense to use the Advertisement
      message.

7. resolver's configured
   default domain and search path into consideration when attempting
   lookups.

6. Multilink issues

   There are two sets of issues to consider, those of the multilink
   server, and those of the client in a multilink environment.

   For the multilink system server to accurately provide name and addressing
   information, it is merely necessary to restrict the advertisement of addressing information for
   a particular address to the interface to which the that address is
   assigned.

   Any client may have a multilink neighbor, and thus SHOULD be
   prepared to deal with a single name being resolved to multiple
   addresses. In practice, this could be handled in the same way as any
   fully qualified hostname returning multiple addresses, although
   returning the address with the largest TTL, or the first received
   address, may be considered.

   A client which is itself multilink may need to store the received
   interface along with the name/address pair.  Not enough is known of
   multilink behaviour to state this with certainty, however.

7. Duplicate Names/Addresses

   As mentioned above, a system with multiple interfaces connected to a
   single link may respond to requests for a single name with different
   addresses at different times.  Alternatively, a system may respond
   to requests for a given address with different names over time,
   should it be configured with multiple aliases.  Neither situation
   should be considered pathological.  The detection of duplicate
   addresses (which would cause general interoperability problems) is a
   function of Duplicate Address Detection, as specified in RFC 1971
   [ADDRCONF].

8. Alternative uses

   Using this protocol for other purposes, such as a means of making a
   host's neighbors visible to the host's users, as a simplistic
   network management tool, is a possible extension of this
   application.  Such uses are not defined in this specification.

   It is also unclear if link-local name servers should be permitted,
   in which one system provides answers on behalf of another.  This
   would require some sort of "proxy bit" in the Advertisement message.

9. Security Issues

   This proposal provides no additional mechanism for security, above
   and beyond the ability to disable this particular function. It might
   be extreme naivete on the part of the author, but he cannot fathom
   any potential security risk in providing a simple name associated
   with an easily obtainable address of limited scope.

10. Acknowledgements

   Thanks to the members of the Digital UNIX IPv6 team, Paul Vixie, and
   the reviewers.  Also, it has been brought to my attention that  RFC 1788 [DOMAIN-MESSAGES], by William Simpson, uses
   similar techniques at a different level (ICMP) to solve a problem of
   greater scope; although it was not used in the initial design of
   this mechanism, it was very useful during initial review of this
   draft.  In particular, the Sequence Number field was borrowed.

   Thanks also to Jef Poskanzer for his permission to reference the
   acme.com domain as an example.

11. References

   [ADDR-ARCH]     R. Hinden and S. Deering, "Internet Protocol Version
                   (IPv6) Addressing Architecture", RFC1884.

   [ADDRCONF]      S. Thompson and T. Narten, "IPv6 Stateless Address
                   Autoconfiguration", work in progress, December 1995,
                    draft-ietf-addrconf-ipv6-auto-07.txt RFC1971.

   [DNS-CONCEPTS]  P. Mockapetris, "Domain names - concepts and
                   facilities", STD-13.

   [MULTILINK]     M. Shand and M. Thomas, "Multihoming Support in
                   IPv6", work in progress, February 1996,
                   draft-shand-ipv6-multi-homing-00.txt
   [DOMAIN-MESSAGES]
                   W. Simpson, "ICMP Domain Name Messages", RFC 1788.

12. Author's Address

       Dan Harrington
    Digital Equipment Corporation
    550 King Street, LKG2-2/Q5
    Littleton,
       Lucent Technologies
       1300 Massachusetts Ave. Suite 100
       Boxborough, MA 01460 01719
       Phone: (508) 486-7643 263-3600 x513
       Email: dan@lkg.dec.com dth@lucent.com