IPng Working Group A. Conta (Lucent)
INTERNET-DRAFT
July 1997
IPv6 Neighbor Discovery Extensions for Inverse Discovery
Specification
draft-conta-ipv6-nd_ext_ind-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working doc-
uments of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "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 memo is unlimited.
Abstract
This memo describes a mechanism that can be seen as an extension to
the IPv6 Neighbor Discovery. It allows a node to solicit and be
advertized an IPv6 address corresponding to a given link-layer
address. Because the known parameter is the link layer address, the
mechanism is called Inverse Neighbor Discovery. It specifically
applies to Frame Relay nodes that may have a Data Link Connection
Identifier (DLCI), the Frame Relay equivalent of a link-layer
address, associated with an established Permanent Virtual Circuit
(PVC), but do not know the IPv6 address of the node at the other end
of the circuit. It may also apply to other networks with similar
behavior.
Conta Expires in six months [Page 1]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
1. Introduction
This document defines an extension mechanism to the IPv6 Neighbor
Discovery that will allow a node to solicit and be advertised an IPv6
address corresponding to a given link-layer address. Because the
input parameter is the link layer address, the mechanism is called
Inverse Neighbor Discovery.
The Inverse Neighbor Discovery (IND) specifically applies to Frame
Relay nodes. Frame Relay permanent virtual circuits (PVCs) and
switched virtual circuits (SVCs) are identified by each node in a
Frame Relay network through a Data Link Connection Identifier (DLCI).
Each DLCI defines for a Frame Relay node a single virtual connection
through the wide area network (WAN) and is the Frame Relay equivalent
to a link-layer address.
Through specific signaling messages, a Frame Relay network may
announce to a node a new virtual circuit with its corresponding DLCI.
However, the announcement being made at link-layer level and com-
pletely independent of the IPv6 protocol does not include IPv6
addressing information. The node receiving such an announcement
learns about the new connection, and it is able to address the other
end of the virtual circuit at link layer level, but, a configuration
or mechanism for discovering an IPv6 address of the other end of the
virtual circuit is necessary.
The IPv6 Inverse Neighbor Discovery (IND) will allow a Frame Relay
node to discover dynamically an IPv6 address of a node associated
with a virtual circuit. These extensions can be used with other
links that similar to Frame Relay provide destination data link-layer
addresses without indicating corresponding IPv6 addresses.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in RFC 2119.
There is a good number of similarities but also differences between
the mechanisms described here and those defined for InARP for IPv4 in
RFC 1293, and the updating "draft-ietf-ion-inarp-update-01.txt".
2. Inverse Neighbor Discovery Messages
The following messages are defined:
Conta Expires in six months [Page 2]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
2.1. Inverse Neighbor Discovery Solicitation Message
Nodes send Inverse Neighbor Discovery Solicitations to request an
IPv6 address corresponding to a link-layer address of the target node
while also providing their own link-layer address to the target.
Inverse Neighbor Discovery Solicitations are link-layer unicast mes-
sages, but IPv6 multicasts, since the destination IPv6 address is not
known.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An IPv6 address assigned to the interface from
which this message is sent.
Destination Address
The solicited-node multicast address. It contains
the 24 bit normalised value of the DLCI.
Hop Limit 255
Priority 15
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the destina-
tion link-layer address, then the sender SHOULD
include this header.
ICMP Fields:
Type 135 or [TBD] if considered as new message
Code 0
Conta Expires in six months [Page 3]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Required options:
Source link-layer address
The link-layer address of the sender.
For Frame Relay, the sender link-layer address is
filled in by the receiver of this message.
Destination link-layer address
The link-layer address of the receiver.
For Frame Relay, both the above addresses are in
Q.922 format (DLCI), which can have 10 (default),
17, or 24 significant addressing bits. The option
length (link-layer address) is expressed in 8 octet
units, therefore, the DLCI will have to be
extracted from the 8 bytes based on the EA field
(bit 0) of the second, third, or forth octet (EA =
1). The C/R, FECN, BECN, DE fields do not have any
significance for IND [IPv6FR].
MTU The MTU configured for this link (circuit).
Future versions of this protocol may add other option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
2.2 Inverse Neighbor Discovery Advertisement Message Format
A node sends Inverse Neighbor Discovery Advertisements in response to
Inverse Neighbor Discovery Solicitations and sends unsolicited Neigh-
bor Advertisements in order to (unreliably) propagate new information
quickly.
Conta Expires in six months [Page 4]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Target Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
An address assigned to the interface from which the
advertisement is sent.
Destination Address
For solicited advertisements, the Source Address of an
invoking Neighbor Solicitation.
For unsolicited advertisements typically the all-nodes
multicast address.
Hop Limit 255
Priority 15
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the destination
address, then the sender SHOULD include this header.
ICMP Fields:
Type 136
Code 0
Conta Expires in six months [Page 5]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
Checksum The ICMP checksum. See [ICMPv6].
R Router flag. When set, the R-bit indicates that the
sender is a router. The R-bit is used by Neighbor
Unreachability Detection to detect a router that
changes to a host.
S Solicited flag. When set, the S-bit indicates that
the advertisement was sent in response to a Neighbor
Solicitation from the Destination address. The S-bit
is used as a reachability confirmation for Neighbor
Unreachability Detection. It MUST NOT be set in
multicast advertisements or in unsolicited unicast
advertisements.
Note that a Frame Relay link is a virtual circuit, which if brakes,
all participants to the circuit receive appropriate link layer sig-
naling, which can be propagated to the upper layers, including IPv6.
Consequently, Neighbor Unreachability Detection is a mechanism that
doubles this function of the Frame Relay link, and as such it is less
useful than in datagram oriented links.
O Override flag. When set, the O-bit indicates that
the advertisement should override an existing cache
entry and update the cached link-layer to IPv6
address mapping. When it is not set the advertise-
ment will not update a cached link-layer address to
IPv6 address mapping though it will update an
existing Neighbor Cache entry for which no IPv6
address is known. It SHOULD NOT be set in
solicited advertisements for anycast addresses and
in solicited proxy advertisements. It SHOULD be
set in other solicited advertisements and in unso-
licited advertisements.
Reserved 29-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Target Address
For solicited advertisements, the IPv6 address
corresponding to the Target Link-Layer Address in
the Inverse Neighbor Discover Solicitation message
that prompted this advertisement. For an unso-
licited advertisement, the IPv6 address whose link-
layer address to IPv6 address mapping has changed.
The Target Address MUST NOT be a multicast address.
Conta Expires in six months [Page 6]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
Required options:
Target link-layer address
The link-layer address of the target, i.e., the
sender of the advertisement [IPV6FR].
Source link-layer address
The link-layer address of the source, i.e., the
receiver of the advertisement [IPv6FR].
MTU The MTU configured for this link (circuit).
Future versions of this protocol may add other option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
3. Inverse Neighbor Discovery Conceptual Algorithm
IND operates essentially the same as IPv6 ND with the exception that
IND uses the link-layer address of the destination node which is
already known, instead of a link-layer multicast. A soliciting node
formats an IND solicitation message as defined above, encapsulates
the packet for the specific link-layer and sends it directly to the
target node.
Upon receiving an IND solicitation, a Frame Relay node fills in the
source link-layer address field with the DLCI from the frame link-
layer header. This is necessary for the correct functioning of the
Frame Relay mechanism. Further the receiver node may put the
sender's IPv6 address/link-layer address mapping into its ND cache as
it would for a ND solicitation. However, unlike in the case of ND,
all IND solicitations are destined and sent to the receiving node.
For every IND solicitation, the receiving node may format in response
a proper advertisment using the link-layer source and target address
pair as well as the IPv6 source address from the solicitation. If a
node is unable or unwilling to advertise, it ignores the solicita-
tion.
Because IPv6 nodes may have multiple IPv6 addresses per interface, a
node responding to an IND solicitation MAY select the IPv6 address
which has the same prefix as the solicitor's node IPv6 address.
When the soliciting node receives the IND advertisment, it resolves
the link-layer address to IPv6 address mapping in the ND cache.
Conta Expires in six months [Page 7]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
Note:
Although IND applies to circuit oriented links, like Frame Relay, for
which a broken physical connectivity is detected in a timely fashion
by the link layer, and consequently the change of state is passed to
upper layer protocols such as IPv6, under certain circumstances,
information learned via IND may be aged or invalidated, and the IPv6
Neighbor Unreachability Detection may be used as an additional mecha-
nism to refresh the link-layer to IPv6 address mapping.
4. Acknowledgments
Thanks to Thomas Narten and Eric Nordmark who spent time discussing
the idea of Inverse Neighbor Discovery. Also thanks to Dan Harring-
ton, Milan Merhar, and Martin Mueller for a thorough reviewing.
5. Security Considerations
Security issues are not addressed in this memo at this time.
6. References
[RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci-
fication"
[RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for
IP Version 6 (IPv6)"
[RFC-1825] R. Atkinson, "Security Architecture for the Internet Pro-
tocol"
[RFC-1826] R. Atkinson, "IP Authentication Header"
[RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers"
[RFC-1293] T. Bradley, C. Brown, "Inverse Address Resolution Proto-
col", 1/1992
Conta Expires in six months [Page 8]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery 29 July 1997
8. Authors' Addresses
Alex Conta
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
+1-508-287-2842
email: aconta@lucent.com
Conta Expires in six months [Page 9]