One document matched: draft-conta-ipv6-inv-nd-tun-00.txt
IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels
Specification
draft-conta-ipv6-inv-nd-tun-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 an extension mechanism to the IPv6 Neighbor Dis-
covery and IPv6 Inverse Neighbor Discovery [IND] that applies to IPv6
and IPv4 tunnels. The mechanism can be used to advertise the parame-
ters of a tunnel to its exit point node, and to create a reverse tun-
nel path between the exit point and entry point nodes of a unidirec-
tional tunnel. If such a bidirectional tunnel already exists, the
mechanism can be used to learn the IPv6 address of the tunnel pseudo-
interface of the exit-point node, as well as the reverse tunnel path
parameters.
Conta Expires in six months [Page 1]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
1. Introduction
This document defines an extension mechanism to the IPv6 Neighbor
Discovery and IPv6 Inverse Neighbor Discovery to advertise the param-
eters of an IPv6 or IPv4 tunnel to the exit point node. The mechanism
can be used at the time of configuring a tunnel, to create a reverse
tunnel path, from the exit-point node to the entry-point node, i.e. a
bidirectional tunnel. If the reverse tunnel path already exists, the
mechanism can be used to learn the IPv6 address of the tunnel pseudo-
interface of the exit-point node, as well as the reverse tunnel path
parameters.
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as
defined in RFC 2119.
2. Inverse Neighbor Discovery Messages
The Inverse Neighbor Discovery Messages defined by [IND], with the
TLEN, an additional option defined later in this document, are
employed with IPv6 tunnels as follows:
2.1. Inverse Neighbor Discovery Solicitation Message Format
A tunnel entry-point node sends an Inverse Neighbor Discovery Solici-
tation to the exit-point node to request the IPv6 address correspond-
ing to the virtual link-layer address represented by the IPv6 address
configured as exit-point node address.
The sender node provides its own virtual link-layer address to the
target, as well as additional parameters such as MTU and Tunnel
Nested Encapsulation Limit (IPv6). A tunnel Inverse Neighbor Discov-
ery Solicitation is a virtual link-layer unicast message. The message
is sent as a tunnel packet, i.e. encapsulated in an IPv6 or IPv4 tun-
nel header that has as source and destination the tunnel entry-point
and exit-point node addresses.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-
Conta Expires in six months [Page 2]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
IP Fields:
Source Address
An IPv6 address assigned to the tunnel pseudo-
interface from which this message is sent.
Destination Address
The solicited-node multicast address of the exit-
point node - built based on the exit-point node IP
address. Alternatively, the all-node multicast
address could be used.
Hop Limit 255
Priority 15
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the destina-
tion address (entry and exit point node addresses),
then the sender SHOULD include this header.
ICMP Fields:
Type 135 or [TBD] if considered a new message
Code 0
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 IPv6 or IPv4 address configured as tunnel
entry-point node address, which plays the role of
the sender's virtual link-layer address.
Target link-layer address
The IPv6 or IPv4 address configured as tunnel exit-
point node address, which plays the role of the
receiver's virtual link-layer address.
Possible options:
Conta Expires in six months [Page 3]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
MTU The MTU of this link (tunnel MTU).
TNEL The configured value of the Tunnel Nested
Encapsulation Limit (IPv6 only).
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 tunnel exit-point node sends Inverse Neighbor Discovery Advertise-
ments in response to Inverse Neighbor Discovery Solicitations if it ?
created a reverse tunnel, i.e. a bidirectional tunnel, or if a
reverse tunnel path exists.
The message is send as a tunnel packet, i.e. encapsulated in a tunnel
header that has as source and destination the reverse tunnel entry-
point and exit-point node addresses.
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 IPv6 address assigned to the tunnel pseudo-interface
from which the advertisement is sent.
Conta Expires in six months [Page 4]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
Destination Address
The IPv6 Source Address of the invoking 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.
ICMP Fields:
Type 136
Code 0
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.
O Override flag. When set, the O-bit indicates that
the advertisement should override an existing cache
entry and update the cached virtual link-layer to
IPv6 address mapping. When it is not set the
advertisement will not update a cached virtual
link-layer address to IPv6 address mapping though
it will update an existing Neighbor Cache entry for
which no IPv6 address is known.
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 5]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
Target Address
The IPv6 or IPv4 address of the tunnel exit-point node
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 or IPv4 address
whose virtual link-layer address to IPv6 address
mapping has changed.
Mandatory options:
Target link-layer address
The virtual link-layer address of the target, i.e., the
IPv6 or IPv4 address of the tunnel exit-point node,
sender of the advertisement.
Source link-layer address
The virtual link-layer address of the source, i.e., the
IPv6 or IPv4 address of the tunnel entry-point node,
receiver of the advertisement.
Possible options:
MTU The MTU of this link (tunnel virtual link).
TNEL The configured value for the Tunnel Nested
Encapsulation Limit. For IPv6 only.
This is the value for the reverse tunnel.
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.3. Tunnel Nested Encapsulation Limit.
This is an option to be sued with IPv6 tunnels only [TUNNEL].
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TNEL | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Conta Expires in six months [Page 6]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
Fields:
Type 5
Length 1
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
TNEL The configured value for the Tunnel Nested
Encapsulation Limit.
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
3. Conceptual Model
An IPv6 or an IPv4 for IPv6 transition tunnel is configured at the
tunnel entry-point node as a virtual link to the tunnel exit-point
node. This leaves a tunnel exit-point unaware of the existence of a
tunnel terminating at that node. Although tunnel entry-point and
exit-point addresses pin-point the virtual link end points, the
reverse path from the exit-point node to the entry point node may be
completely different than the direct path, unless both are specified
as direct strict source route and respectively its reversed strict
source route. This implies that a tunnel is unidirectional.
The end-point nodes addresses are used to fill the source and desti-
nation fields in the tunnel header prepended to a packet sent
through the tunnel, similarly to a link-layer encapsulation. The tun-
nel virtual link is virtually terminated in tunnel pseudo-interfaces
at both ends. These pseudo-interfaces have their own IPv6 addresses.
A tunnel entry-point pseudo-interface IPv6 address may appear as
original packet source address if a packet originated at the tunnel
entry-point node is forwarded through the tunnel towards its destina-
tion. Knowing and using as destination the IPv6 address of the tun-
nel pseudo-interface of the exit-point node may result in packets
sent through the tunnel only if the forwarding path to that destina-
tion is configured so.
The entry-point node can advertise to the exit-point node the config-
uring of a tunnel by way of Inverse Neighbor Discovery Solicitation
messages. As a result, the exit-point node learning about the tunnel
may optionally create a reverse path tunnel, hence creating the
effect of a bidirectional tunnel, with potentially different direct
and reverse paths. Additionally, by responding with Inverse Neighbor
Discovery Advertising messages, the exit-point node notifies the
Conta Expires in six months [Page 7]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
bidirectional tunnel effect to the entry-point node.
4. Security Considerations
The creation of a reverse tunnel path raises security issues which
need be discussed. At this early stage this memo does not address
those security issues.
5. Acknowledgments
This draft is a result of a discussion with Steve Deering about the
applicability and benefits of Neighbor Discovery for IPv6 tunnels.
After more thinking and in combination with IPv6 Inverse Neighbor
Discovery things seemed to fall into place.
The IPv4 part was quickly added after Dan Harrington suggested that
it would be a good idea to have it.
Thanks to Thomas Narten and Erik Nordmakr for discussing the idea =
of
this memo.
6. References
[RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci-
fication"
[RFC-1885] A. Conta, and S. Deering "Internet Control Message Proto-
col for the Internet Protocol Version 6 (IPv6)"
[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"
Conta Expires in six months [Page 8]
INTERNET-DRAFT IPv6 Inverse ND for Tunnels 29 July 1997
[IND] A. Conta "IPv6 Inverse Neighbor Discovery.
7. Authors' Addresses
Alex Conta
Lucent Technologies Inc.
300 Baker Ave, Suite 100
Concord, MA 01742
+1-508-287-2800/ext 2842
email: aconta@lucent.com
Conta Expires in six months [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 01:58:40 |