One document matched: draft-ietf-ipngwg-linkname-01.txt
Differences from draft-ietf-ipngwg-linkname-00.txt
IPng Working Group Dan Harrington
Internet Draft Lucent Technologies
January 1997
Link Local Addressing and Name Resolution in IPv6
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 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 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
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
Expires July 1997 [Page 1]
Internet Draft Link Local Naming January 1997
5. Interaction with DNS and resolver routines 7
6. Multilink issues 8
7. Duplicate Names/Addresses 8
8. Alternative uses 9
9. Security Issues 9
10. Acknowledgements 9
11. References 9
12. Author's Address 10
Expires July 1997 [Page 2]
Internet Draft Link Local Naming January 1997
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.
Early experience at the University of New Hampshire interoperability
bakeoffs has shown that to a large degree this goal is achieved;
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 addresses
and names of all adjacent systems, and enter this information into
said file. Also, using a manual mechanism such as this is 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 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,
composed of the well known prefix FE80:: and a media
specific token. This address is limited in scope to
Expires July 1997 [Page 3]
Internet Draft Link Local Naming January 1997
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 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 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 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::1:1, which has link-local scope. The UDP port
1903 is reserved for use of this protocol.
4.1. Server Processing and Advertisements
A system SHOULD advertise its system name and the associated link
local address over each of its interfaces, along with an indication
of how long the information should be considered valid.
A system may transmit these packets solely at discrete intervals, or
Expires July 1997 [Page 4]
Internet Draft Link Local Naming January 1997
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,
and may be used to determine the length of the enclosed hostname.
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 choose to
Expires July 1997 [Page 5]
Internet Draft Link Local Naming January 1997
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:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Expires July 1997 [Page 6]
Internet Draft Link Local Naming January 1997
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.
It may well be useful to define a special category to this type of
address, given its restricted capabilities. A special
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). It
should be noted that while this 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 IANA: would it be possible to get such a pseudo-TLD
assigned?
The general rule of 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 common link, neither
configured to 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:
Expires July 1997 [Page 7]
Internet Draft Link Local Naming January 1997
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 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 to use the "ndots" resolver configuration
mechanism, or to create an analogous device for this purpose. On
the other hand, the FQDN information, while perhaps overkill, is
definitive.
Another issue involves making sure that inappropriate requests are
not made, which would needlessly query local systems in order to
attempt resolution of a name which is not locally available. In
general, it would make sense to use the 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 server to accurately provide name and addressing
information, it is merely necessary to restrict the advertisement of
a particular address to the interface to which 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
Expires July 1997 [Page 8]
Internet Draft Link Local Naming January 1997
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. 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", 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
Expires July 1997 [Page 9]
Internet Draft Link Local Naming January 1997
[DOMAIN-MESSAGES]
W. Simpson, "ICMP Domain Name Messages", RFC 1788.
12. Author's Address
Dan Harrington
Lucent Technologies
1300 Massachusetts Ave. Suite 100
Boxborough, MA 01719
Phone: (508) 263-3600 x513
Email: dth@lucent.com
Expires July 1997 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 06:13:42 |