draft-ietf-ipngwg-linkname-00.txt   draft-ietf-ipngwg-linkname-01.txt 
IPng Working Group Dan Harrington
INTERNET-DRAFT D. Harrington Internet Draft Lucent Technologies
Internet Draft Digital Equipment Corp January 1997
Link Local Addressing and Name Resolution in IPv6 Link Local Addressing and Name Resolution in IPv6
<draft-ietf-ipngwg-linkname-00.txt> draft-ietf-ipngwg-linkname-01.txt
Abstract Abstract
This draft proposes an experimental mechanism by which IPv6 link-local This draft proposes an experimental mechanism by which IPv6
addresses and associated system names may be distributed among link-local addresses and associated system names may be distributed
interconnected hosts, for use by users and applications. It among interconnected hosts, for use by users and applications. It
provides an overview of the problem, a proposed solution (including provides an overview of the problem, a proposed solution (including
suggested protocol details), and lists various related issues. suggested protocol details), and lists various related issues. This
This work is introduced to the IPng Working Group initially, work is introduced to the IPng Working Group initially, although it
although it might also have implications or concerns relevant might also have implications or concerns relevant to individuals
to individuals working on directory services and other areas. working on directory services and other areas.
Status of this Memo Status of This Memo
This document is a submission to the IPng Working Group of the This document is a submission to the IPng Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be
to the ipng@sunroof.eng.sun.com mailing list. This document is not submitted to the ipng@sunroof.eng.sun.com mailing list.
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 This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as ``work in progress.'' reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Distribution of this document is unlimited.
Table of Contents: Table Of Contents
1. Introduction.................................................3 1. Introduction 3
2. Terminology and Definitions..................................3 2. Terminology and Definitions 3
3. Design Goals.................................................4 3. Design Goals 4
4. Proposed Protocol............................................4 4. Proposed Protocol 4
4.1 Server Processing and Advertisements.....................4 4.1. Server Processing and Advertisements 4
4.2 Client Processing and Requests...........................5 4.2. Client Processing and Requests 5
5. Interaction with DNS and resolver routines...................7 5. Interaction with DNS and resolver routines 7
6. Alternative uses.............................................7 6. Multilink issues 8
7. Multilink issues.............................................7 7. Duplicate Names/Addresses 8
8. Security Issues..............................................8 8. Alternative uses 9
Acknowledgements.............................................9 9. Security Issues 9
References...................................................9 10. Acknowledgements 9
Author's Address.............................................9 11. References 9
12. Author's Address 10
1. Introduction 1. Introduction
One aspect of IP Version 6 which is somewhat novel is the "plug- One aspect of IP Version 6 which is somewhat novel is the
and-play" capability, in which a system may be interconnected with "plug-and-play" capability, in which a system may be interconnected
other IPv6 systems without the need for formal configuration. In with other IPv6 systems without the need for formal configuration.
particular, the use of autonomically created link-local addresses, In particular, the use of autonomically created link-local
which are limited in scope to the physical link to which the addresses, which are limited in scope to the physical link to which
system is connected, is meant to support this goal. This is the system is connected, is meant to support this goal. This is
sometimes referred to informally as the "dentist's office" sometimes referred to informally as the "dentist's office" scenario.
scenario. In fact, early experience at the interoperability Early experience at the University of New Hampshire interoperability
bakeoff at the University of New Hampshire this past February bakeoffs has shown that to a large degree this goal is achieved;
(1996) showed that to a large degree this goal is achieved; hosts from multiple vendors were interconnected to an Ethernet, and
systems from multiple vendors were interconnected to an Ethernet, in the absence of any routers were able to communicate with
and in the absence of any routers were able to communicate with
neighboring systems. neighboring systems.
One capability which is lacking in this case, however, is a simple One capability which is lacking in this case, however, is a simple
name to address (and inverse) lookup function. While it is a name to address (and inverse) lookup function. While it is a simple
simple matter to add support to existing resolver routines to matter to add support to existing resolver routines to support the
support the lookup of IPv6 addresses from a local ASCII file (e.g. lookup of IPv6 addresses from a local ASCII file (e.g. /etc/hosts),
/etc/hosts), it is extremely inconvenient to determine the link- it is extremely inconvenient to determine the link-local addresses
local addresses and names of all adjacent systems, and enter this and names of all adjacent systems, and enter this information into
information into said file. Also, using a manual mechanism such said file. Also, using a manual mechanism such as this is prone to
as this is error prone and may quickly become stale. Clearly, an data input errors, and the data itself may quickly become stale.
automated means of distributing this information is called for. Clearly, an automated means of distributing this information is
called for.
This draft proposes that an IPv6 systems, when utilizing an This draft proposes that an IPv6 system, when utilizing an interface
interface which supports the link-local model, advertise its name which supports the link-local model, advertise its name and
and associated link-local IPv6 address to a multicast group of associated link-local IPv6 address to a multicast group of
link-local scope, using a simple protocol over UDP. It also link-local scope, using a simple protocol over UDP. It also allows
allows a system to send a query for a particular name or address a system to send a query for a particular name or address to the
to the group, which may be responded to by the system matching the group, which may be responded to by the system matching the given
given item. The effects of multilink hosts, interactions with item. In this model, there is no central server; each system
name resolving services, and security concerns are discussed. 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 2. Terminology and Definitions
link - a communication facility or medium over which nodes can link a communication facility or medium over which nodes
communicate at the link layer, i.e., the layer can communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets (simple immediately below IPv6. Examples are Ethernets
or bridged); PPP links; X.25, Frame Relay, or ATM (simple or bridged); PPP links; X.25, Frame Relay,
networks; and internet (or higher) layer "tunnels", or ATM networks; and internet (or higher) layer
such as tunnels over IPv4 or IPv6 itself. "tunnels", such as tunnels over IPv4 or IPv6 itself.
neighbors - nodes attached to the same link. neighbors nodes attached to the same link.
interface - a node's attachment to a link. interface a node's attachment to a link.
link-local - An address formed during interface initialization, link-local address
address composed of the well known prefix FE80:: and a media 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 specific token. This address is limited in scope to
the link and may not be forwarded by a router. the link and may not be forwarded by a router.
resolver - A program which retrieves information from name servers resolver A program which retrieves information from name
in response to client requests. It is typically servers in response to client requests. It is
available as a system or library call to a program. typically available as a system or library call to a
program.
Multilink - A system which has multiple link interfaces and multiple multilink A system which has multiple link interfaces and
IPv6 addresses. Note that the different interfaces may multiple IPv6 addresses. Note that the different
or may not be connected to the same physical media, or interfaces may or may not be connected to the same
even the same media type. physical media, or even the same media type.
FQDN Fully Qualified Domain Name
3. Design Goals 3. Design Goals
The goal of this proposal is to provide a way to advertise and use 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 names and link local addresses among IPv6 hosts. It is also a goal
goal to keep this addressing information OUT of the DNS/BIND to keep this addressing information OUT of the DNS/BIND server's
server's data file, as it is almost impossible for such a server data file, as it is almost impossible for such a server to know if
to know if providing such an address is appropriate, without the providing such an address is appropriate, without the server having
server having to keep much too much information about the relative to ascertain an inappropriate amount of information about the
location of both the client system and the requested hostname. relative location of both the client system and the requested
hostname.
The proposed protocol is deliberately simple and limited. It has The proposed protocol is deliberately simple and limited. It has
some elements in common with the Service Location protocol, and it some elements in common with the Service Location protocol, and it
may be worth investigating the relationship between the two, may be worth investigating the relationship between the two,
especially as Service Location adds support for IPv6. Finally, especially as Service Location adds support for IPv6. Finally, the
the implementation of this mechanism will also serve to exercise implementation of this mechanism will also serve to exercise other
other elements IPv6 systems, in particular multicast support and elements of IPv6 systems, in particular multicast support and the
the BSD API interface. For these reasons it is requested that BSD API interface. For these reasons it is requested that this
this protocol be considered Experimental. protocol be considered Experimental at this point.
4. Proposed Protocol 4. Proposed Protocol
There are two aspects to implementing a simple name to address There are two aspects to implementing a simple name to address
function: providing local name and address information (server), function: providing local name and address information (server), and
and requesting and storing remote name or address information requesting and storing remote name or address information (client).
(client). An IPv6 system SHOULD provide the server functionality, An IPv6 system SHOULD provide the server functionality, in order to
in order to distribute its own information to others. A system distribute its own information to others. A system MAY wish to be a
MAY wish to be a client, in order to learn and use the information client, in order to learn and use the information of neighbors.
of neighbors.
In order to participate in this service, a system must join the In order to participate in this service, a system must join the IPv6
IPv6 multicast group FF02::<TBD>, which has link-local scope. The multicast group FF02::1:1, which has link-local scope. The UDP port
UDP port <TBD> is reserved for use of this protocol. 1903 is reserved for use of this protocol.
4.1 Server Processing and Advertisements 4.1. Server Processing and Advertisements
A system SHOULD advertise its system name (non-fully qualified, A system SHOULD advertise its system name and the associated link
i.e. no domains, just a simple hostname) and the associated link local address over each of its interfaces, along with an indication
local address over each of its interfaces, along with an of how long the information should be considered valid.
indication of how long the information should be considered valid.
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.
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 | | 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 | | S e q u e n c e N u m b e r | T T L |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Address | | Link Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Simple hostname... | | Simple hostname... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Fields: Fields:
Version - Sent as 1 Version - Sent as 1
ADV (1.) - Advertise name/address information
TTL - value from 0000 to FFFF (see description below) TTL - value from 0000 to FFFF (see description below)
Sequence Number - A value to be used by clients in matching Sequence Number - A value to be used by clients in matching
requests to responses. For a periodic requests to responses. For a periodic
(i.e. unsolicited) advertisement, should be 0. For (i.e. unsolicited) advertisement, should be 0. For
responses to explicit requests the value from the responses to explicit requests the value from the
request should be copied. request should be copied.
A TTL value of 0 indicates that the name/address pair is no longer 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 to be considered valid, and should be flushed from any long-term or
storage on remote systems. A TTL value of 0xFFFF indicates an temporary storage on remote systems. A TTL value of 0xFFFF
infinite value, and clients are permitted to treat the indicates an infinite value, and clients are permitted to treat the
name/address pair as permanent, obviating the need to time out the name/address pair as permanent, obviating the need to time out the
entry. entry.
The Length field indicates the total length of the packet in 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.
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 4.2. Client Processing and Requests
A system may operate in a purely reactionary mode to user A system may operate in a purely reactionary mode to user requests,
requests, with no caching of learned information, but it may well with no caching of learned information, but it may well choose to
choose to record any advertised name/address bindings received. record any advertised name/address bindings received. If information
If information is stored, then the values of the TTL field in is stored, then the values of the TTL field in responses must be
responses must be respected, and the associated information dealt respected, and the associated information dealt with accordingly.
with accordingly. The following table shows possible TTL values, The following table shows possible TTL values, and how they affect
and how they affect recording client systems. recording client systems.
TTL Value Action TTL Value Action
1<n<FFFE Keep track of time 1<n<FFFE Keep track of time
FFFF Permanent (no need to keep track of time) FFFF Permanent (no need to keep track of time)
0 Stale, flush existing entry. 0 Stale, flush existing entry.
The following items should be considered when verifying a received The following items should be considered when verifying a received
advertisement. advertisement.
- minimum packet length = 20. octets - minimum packet length = 20. octets
- maximum packet length = maximum UDP limit on specific link - maximum packet length = maximum UDP limit on specific link
- Version value must be 1. - Version value must be 1.
- non link-local address (wrong prefix or token length) - non link-local address (wrong prefix or token length)
discarded discarded
- zero length names discarded. - zero length names discarded.
- Unrecognized packet types ignored/discarded - Unrecognized packet types ignored/discarded
A system may also request a name or address value, via the A system may also request a name or address value, via the following
following request packet: 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 | | 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 | | 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 | | Link Local Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Simple hostname... | | Simple hostname... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Version - Send as 1. Version - Send as 1.
RQST - Request Information (2.) RQST - Request Information (2.)
TYPE TYPE
Name (1.) Request a name for the given address. Name (1.) Request a name for the given address.
Address (2.) Request an address for the given name. Address (2.) Request an address for the given name.
If a Name is requested, then the address field must be set to a 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 valid link-local address for the given media type, and the hostname
hostname field must be empty (i.e. of length zero). If an address field must be empty (i.e. of length zero). If an address is
is requested, then the address field must be set to all zeroes, requested, then the address field must be set to all zeroes, and the
and the hostname field must contain a non-null entry. The Length hostname field must contain a non-null entry. The Length field
field indicates the total length of the packet in octets. indicates the total length of the packet in octets.
5. Interaction with DNS and resolver routines 5. Interaction with DNS and resolver routines
To be useful and available to applications and users, the names To be useful and available to applications and users, the names and
and addresses made available using this protocol must be addresses made available using this protocol must be integrated to
integrated to some extent with the host's name resolving software. some extent with the host's name resolving software. While it might
While it might be envisioned that this could be done in a be envisioned that this could be done in a simplistic fashion, by
simplistic fashion, by adding and mainting entries in the local adding and mainting entries in the local storage (e.g. the
storage (e.g. the "/etc/hosts" file), it would be more appropriate "/etc/hosts" file), it would be more appropriate to utilize dynamic
to utilize dynamic storage for link local addresses. In fact, it storage for link local addresses.
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).
6. Alternative uses 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.
Using this protocol for other purposes, such as a means of making Question for IANA: would it be possible to get such a pseudo-TLD
a host's neighbors visible to the host's users, as a simplistic assigned?
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, The general rule of thumb for requesting and supplying naming
in which one system provides answers on behalf of another. This information should be to make requests as general as possible, and
would require some sort of "proxy bit" in the Advertisement provide answers that are as specific as possible. For example,
message. 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:
7. Multilink issues 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 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 There are two sets of issues to consider, those of the multilink
server, and those of the client in a multilink environment. server, and those of the client in a multilink environment.
For the multilink system to accurately provide name and addressing For the multilink server to accurately provide name and addressing
information, it is merely necessary to restrict the advertisement information, it is merely necessary to restrict the advertisement of
of addressing information for a particular address to the a particular address to the interface to which that address is
interface to which the address is assigned. assigned.
Any client may have a multilink neighbor, and thus SHOULD be Any client may have a multilink neighbor, and thus SHOULD be
prepared to deal with a single name being resolved to multiple prepared to deal with a single name being resolved to multiple
addresses. In practice, this could be handled in the same way as addresses. In practice, this could be handled in the same way as any
any fully qualified hostname returning multiple addresses, fully qualified hostname returning multiple addresses, although
although returning the address with the largest TTL, or the first returning the address with the largest TTL, or the first received
received address, may be considered. address, may be considered.
A client which is itself multilink may need to store the received A client which is itself multilink may need to store the received
interface along with the name/address pair. Not enough is known interface along with the name/address pair. Not enough is known of
of multilink behaviour to state this with certainty, however. multilink behaviour to state this with certainty, however.
8. Security Issues 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 This proposal provides no additional mechanism for security, above
and beyond the ability to disable this particular function. It and beyond the ability to disable this particular function. It might
might be extreme naivete on the part of the author, but he cannot be extreme naivete on the part of the author, but he cannot fathom
fathom any potential security risk in providing a simple name any potential security risk in providing a simple name associated
associated with an easily obtainable address of limited scope. with an easily obtainable address of limited scope.
Acknowledgements 10. Acknowledgements
Thanks to the members of the Digital UNIX IPv6 team, and the Thanks to the members of the Digital UNIX IPv6 team, Paul Vixie, and
reviewers. Also, it has been brought to my attention that RFC 1788 the reviewers. RFC 1788 [DOMAIN-MESSAGES], by William Simpson, uses
[DOMAIN-MESSAGES], by William Simpson, uses similar techniques at a similar techniques at a different level (ICMP) to solve a problem of
different level (ICMP) to solve a problem of greater scope; although greater scope; although it was not used in the initial design of
it was not used in the initial design of this mechanism, it was very this mechanism, it was very useful during initial review of this
useful during initial review of this draft. In particular, the draft. In particular, the Sequence Number field was borrowed.
Sequence Number field was borrowed.
References Thanks also to Jef Poskanzer for his permission to reference the
acme.com domain as an example.
[ADDR-ARCH] R. Hinden and S. Deering, "Internet Protocol Version (IPv6) 11. References
Addressing Architecture", RFC1884.
[ADDR-ARCH] R. Hinden and S. Deering, "Internet Protocol Version
(IPv6) Addressing Architecture", RFC1884.
[ADDRCONF] S. Thompson and T. Narten, "IPv6 Stateless Address [ADDRCONF] S. Thompson and T. Narten, "IPv6 Stateless Address
Autoconfiguration", work in progress, December 1995, Autoconfiguration", RFC1971.
draft-ietf-addrconf-ipv6-auto-07.txt
[DNS-CONCEPTS] P. Mockapetris, "Domain names - concepts and facilities", [DNS-CONCEPTS] P. Mockapetris, "Domain names - concepts and
STD-13. facilities", STD-13.
[MULTILINK] M. Shand and M. Thomas, "Multihoming Support in IPv6", [MULTILINK] M. Shand and M. Thomas, "Multihoming Support in
work in progress, February 1996, IPv6", work in progress, February 1996,
draft-shand-ipv6-multi-homing-00.txt draft-shand-ipv6-multi-homing-00.txt
[DOMAIN-MESSAGES]
W. Simpson, "ICMP Domain Name Messages", RFC 1788.
[DOMAIN-MESSAGES] W. Simpson, "ICMP Domain Name Messages", RFC 1788. 12. Author's Address
Author's Address
Dan Harrington Dan Harrington
Digital Equipment Corporation Lucent Technologies
550 King Street, LKG2-2/Q5 1300 Massachusetts Ave. Suite 100
Littleton, MA 01460 Boxborough, MA 01719
Phone: (508) 486-7643 Phone: (508) 263-3600 x513
Email: dan@lkg.dec.com Email: dth@lucent.com
 End of changes. 56 change blocks. 
194 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/