INTERNET-DRAFT D. Harrington Internet Draft Digital Equipment Corp Link Local Addressing and Name Resolution in IPv6 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 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. Harrington Expires December 1996 [Page 1] INTERNET-DRAFT draft-ietf-ipngwg-linkname-00.txt June 1996 Table of Contents: 1. Introduction.................................................3 2. Terminology and Definitions..................................3 3. Design Goals.................................................4 4. Proposed Protocol............................................4 4.1 Server Processing and Advertisements.....................4 4.2 Client Processing and Requests...........................5 5. Interaction with DNS and resolver routines...................7 6. Alternative uses.............................................7 7. Multilink issues.............................................7 8. Security Issues..............................................8 Acknowledgements.............................................9 References...................................................9 Author's Address.............................................9 Harrington Expires December 1996 [Page 2] INTERNET-DRAFT draft-ietf-ipngwg-linkname-00.txt June 1996 1. Introduction One aspect of IP Version 6 which is somewhat novel is the "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 experience at the interoperability bakeoff at the University of New Hampshire this past February (1996) showed that to a large degree this goal is achieved; systems 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 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 and may quickly become stale. Clearly, an automated means of distributing this information is called for. This draft proposes that an IPv6 systems, 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. 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 - 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 Harrington Expires December 1996 [Page 3] INTERNET-DRAFT draft-ietf-ipngwg-linkname-00.txt June 1996 available as a system or library call to a program. 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. 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 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 IPv6 systems, in particular multicast support and the BSD API interface. For these reasons it is requested that this protocol be considered Experimental. 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::, which has link-local scope. The UDP port is reserved for use of this protocol. 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. Harrington Expires December 1996 [Page 4] INTERNET-DRAFT draft-ietf-ipngwg-linkname-00.txt June 1996 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 | 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Version - Sent as 1 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 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. 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. 4.2 Client Processing and Requests A system may operate in a purely reactionary mode to user requests, with no caching of learned information, but it may well Harrington Expires December 1996 [Page 5] INTERNET-DRAFT draft-ietf-ipngwg-linkname-00.txt June 1996 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