Internet DRAFT - draft-conta-ion-ipv6-ind
draft-conta-ion-ipv6-ind
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:21:03 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 21 Nov 1997 18:59:00 GMT
ETag: "2e7f98-5191-3475d9f4"
Accept-Ranges: bytes
Content-Length: 20881
Connection: close
Content-Type: text/plain
ION/IPng Working Groups A. Conta (Lucent)
INTERNET-DRAFT
November 1997
Extensions to IPv6 Neighbor Discovery for Inverse Discovery
Specification
draft-conta-ion-ipv6-ind-00.txt
Status of this Memo
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. 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 extensions to the IPv6 Neighbor Discovery that
allow a node to solicit and be advertised an IPv6 address
corresponding to a given link-layer address. These extensions are
called Inverse Neighbor Discovery. They specifically apply to Frame
Relay networks but they may also apply to other networks with similar
behavior.
1. Introduction
This document defines extensions to the IPv6 Neighbor Discovery (ND)
that allow a node to solicit and be advertised an IPv6 address
Conta Expires in six months [Page 1]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
corresponding to a known link-layer address. The extensions are
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 in a Frame Relay
network by a Data Link Connection Identifier (DLCI). Each DLCI
defines for a Frame Relay node a single virtual connection through
the wide area network (WAN).
By way of specific signaling messages, a Frame Relay network may
announce to a node a new virtual circuit with its corresponding DLCI.
The DLCI identifies to a node a virtual circuit, and can be
considered the equivalent of a remote node link-layer address,
allowing a node to address at link layer level the node at the other
end of the virtual circuit. However, the signaling message does not
contain information about the identifier used by a remote node to
identify the node, which would be the equivalent of the local link-
layer address. Furthermore, the message being transmitted at link-
layer level and completely independent of the IPv6 protocol does not
include any IPv6 addressing information. Therefore it seems to be
useful to define a protocol that allows a Frame Relay node to
discover the equivalent of a local link layer address, that is, the
identifier by way of which remote nodes address the node, and more
importantly discover based on a known remote link layer address an
IPv6 address of a node at the other end of the virtual circuit.
The IPv6 Inverse Neighbor Discovery (IND) protocol defined by this
document allows a Frame Relay node to discover dynamically the DLCI
by way of which a remote node identifies the virtual circuit as well
an IPv6 address of a remote node associated with a virtual circuit.
These mechanisms can be used with other links that similar to Frame
Relay provide to nodes information equivalent to destination (remote)
data link-layer addresses without indicating the 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 number of similarities and differences between the
mechanisms described here and those defined for InARP for IPv4 in RFC
1293, or its replacing documents.
2. Inverse Neighbor Discovery Messages
The following messages are defined:
Conta Expires in six months [Page 2]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
2.1. Inverse Neighbor Discovery Solicitation Message
A node sends an Inverse Neighbor Discovery Solicitation message to
request an IPv6 address corresponding to a link-layer address of the
target node while also providing its own link-layer address to the
target. Since the remote node IPv6 addresses are not known, Inverse
Neighbor Discovery (IND) Solicitations are sent as IPv6 all-node
multicasts. However, at link layer level, an IND Solicitation is sent
directly to the target node, identified by the known link-layer
address.
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 IPv6 all-node 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 link-layer address, then the sender
SHOULD include this header.
ICMP Fields:
Type [TBD]
Code 0
Conta Expires in six months [Page 3]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 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 may have no knowledge
of the information that indicates to the remote
node the equivalent of the link-layer address of
the source of this message. Therefore prior to any
Inverse Neighbor Discovery processing, the receiver
of this message replaces this field, whether filled
in or not by the sender, with information carried
by the Frame Relay header in the DLCI field. The
field is encoded in DLCI format as defined by
[IPv6FR].
Target Link-Layer Address
The link-layer address of the target node.
For Frame Relay, this field is filled with the
value known to the sender as the equivalent of the
target node link-layer address, encoded in DLCI
format [IPv6FR].
Note: For Frame Relay, both the above addresses are in Q.922
format (DLCI), which can have 10 (default), 17, or 23 significant
addressing bits [IPv6FR]. 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 in the Q.922 address have no significance for IND and are
set to 0 [IPv6FR].
Options:
MTU The MTU configured for this link [ND]
For Frame Relay is the MTU for this virtual circuit
[IPv6FR].
Future versions of this protocol may add other option types.
Conta Expires in six months [Page 4]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
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.
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
The Source Address of an invoking Inverse Discovery
Neighbor Solicitation.
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.
Conta Expires in six months [Page 5]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
ICMP Fields:
Type [TBD]
Code 0
Checksum The ICMP checksum. See [ICMPv6].
R Router flag. Defined for compatibility
with Neighbor Discovery advertisement messages. It
is not used. It MUST be clear.
S Solicited flag. Defined for compatibility with
Neighbor Discovery advertisement messages. It is
used mostly with Neighbor Unreachability Detection.
It is not used by IND. It MUST be clear.
Note:
In case of Frame Relay, this message is sent on a virtual circuit,
which acts like a virtual-link. If it brakes, all participants to the
circuit receive appropriate link layer signaling messages, which can
be propagated to the upper layers, including IPv6. Consequently,
Neighbor Unreachability Detection is a mechanism that is superfluous
and therefore less useful than for 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 mapping of the link-
layer address to IPv6 address. When it is not set
the advertisement 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 be set.
Note:
For Frame Relay, the Inverse Neighbor Discovery Advertisement
messages unlike the Neighbor Discovery Advertisement messages
carrying DLCI format link-layer addresses, SHOULD have a "O" bit set
to 1.
Reserved 29-bit unused field. It MUST be initialized to
zero by the sender and MUST be ignored by the
receiver.
Conta Expires in six months [Page 6]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
Target Address
The IPv6 address corresponding to the Target Link-
Layer Address in the Inverse Neighbor Discover
Solicitation message that prompted this
advertisement.
Required options:
Source Link-Layer Address
The link-layer address of the sender of this
message.
For Frame Relay, the sender link-layer address is
filled with the DLCI value of the virtual circuit
known to the sender of this message. The field is
in DLCI format as defined by [IPv6FR].
Target Link-Layer Address
The link-layer address of the sender of this
message.
For Frame Relay, this field is copied from the
Inverse Neighbor Discovery Solicitation Target
link-layer address field. It is encoded in DLCI
format [IPv6FR].
Options
MTU The MTU configured for this link
(virtual circuit) [ND].
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 Protocol
IND operates essentially the same as ND. The solicitor of a target IP
address sends a solicitation message, the target node responds with
an advertisement message containing the information requested.
3.1 Sender Node Processing
A soliciting node formats an IND solicitation message as defined in a
previous section, encapsulates the packet for the specific link-layer
[IPv6FR] and sends it directly to the target node. Although the
Conta Expires in six months [Page 7]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
destination IP address is the all-node multicast address, the message
is sent only to the target node. In the case of Frame Relay, the
target node is the known remote node on the link represented by the
virtual circuit. The significant fields for the IND protocol are the
Source IP address, the Source link-layer address, the Target link-
layer address, and the MTU. The latter can be used to set the optimum
value of the MTU for the link.
3.2 Receiver Node Processing
A Frame Relay node, before further processing, is replacing in the
Source link-layer address the existent DLCI value with the DLCI value
from the Frame Relay header of the frame containing the message. The
DLCI value has to be formated appropriately in the Source link-layer
address field [IPv6FR]. This operation is required to allow a correct
interpretation of the fields in the further processing of the IND
solicitation message.
For every IND solicitation, the receiving node may format in response
a proper IND advertisement using the link-layer source and target
address pair as well as the IPv6 source address from the IND
solicitation message. If a node is unable or unwilling to advertise,
it ignores the solicitation.
Further, the receiver node may put the sender's IPv6 address/link-
layer address mapping - i.e. the source IP address and the Source
link-layer address from the solicitation message - into its ND cache
as it would for a ND solicitation.
For a Frame Relay node, the MTU value from the solicitation message
MAY be used to set the receiver's MTU to a value that is more
optimal, in case that was not already done at the interface
configuration time.
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.
4. Security Considerations
Being employed on point to point virtual circuits Inverse Neighbor
Discovery messages are not sensitive to impersonation attacks from
on-link nodes.
Like Neighbor Discovery, the protocol reduces the exposure to threats
Conta Expires in six months [Page 8]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
from off-link nodes in the absence of authentication by ignoring IND
packets received from off-link senders. The Hop Limit field of all
received packets is verified to contain 255, the maximum legal value.
Because routers decrement the Hop Limit on all packets they forward,
received packets containing a Hop Limit of 255 must have originated
from a neighbor.
Inverse Neighbor Discovery protocol packet exchanges can be
authenticated using the IP Authentication Header [RFC 1826]. A node
SHOULD include an Authentication Header when sending Inverse Neighbor
Discovery packets if a security association for use with the IP
Authentication Header exists for the destination address. The
security associations may have been created through manual
configuration or through the operation of some key management
protocol.
Received Authentication Headers in Neighbor Discovery packets MUST be
verified for correctness and packets with incorrect authentication
MUST be ignored.
It SHOULD be possible for the system administrator to configure a
node to ignore any Inverse Neighbor Discovery messages that are not
authenticated using either the Authentication Header or Encapsulating
Security Payload. Such a switch SHOULD default to allowing
unauthenticated messages.
Confidentiality issues are addressed by the IP Security Architecture
and the IP Encapsulating Security Payload documents [RFC 1825, RFC
1827].
5. Acknowledgments
Thanks to Thomas Narten and Eric Nordmark who spent time discussing
the idea of Inverse Neighbor Discovery. Also thanks to Dan
Harrington, Milan Merhar, and Martin Mueller for a thorough
reviewing.
6. References
[IPv6] S. Deering, R. Hinden, "Internet Protocol Version 6
Specification"
[ND] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for IP
Version 6 (IPv6)"
Conta Expires in six months [Page 9]
INTERNET-DRAFT IPv6 Inverse Neighbor Discovery November 20, 1997
[IPv6FR] A. Conta, A. Malis, M. Mueller, "Transmission of IPv6
Packets over Frame Relay networks" <draft-conta-ion-ipv6-fr-00.txt>
[RFC-1825] R. Atkinson, "Security Architecture for the Internet
Protocol"
[RFC-1826] R. Atkinson, "IP Authentication Header"
[RFC-1827] R. Atkinson. "IP Encapsulating Security Payload (ESP)".
[RFC-2200] J. Reynolds, J. Postel, "Assigned Numbers"
[ENCAPS]C. Brown, A. Malis, "Multiprotocol Interconnect over Frame
Relay", <draft-ietf-ion-fr-update-03.txt>.
[RFC-1293] T. Bradley, C. Brown, "Inverse Address Resolution
Protocol", 1/1992
7. 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 10]
590
