Source Address
A valid unicast IPv6 address of the outgoing
interface.
Destination Address
Copied from the Source Address field of the Original
IPv6 header.
ICMP Fields:
For any of the following tunnel ICMP error messages:
"hop limit exceeded"
"unreachable node"
"parameter problem" - pointing to a valid Tunnel Encapsulation
Limit destination header with the Tun Encap Lim field set to a
value zero:
Type 1 - unreachable node
Code 3 - address unreachable
For tunnel ICMP error message "packet too big":
Type 2 - packet too big
Code 0
MTU The MTU field from the tunnel ICMP message minus
the length of the tunnel headers.
According to the general rules described in 7.1, an ICMP "packet too
big" message is sent to the source of the original packet only if the
original packet size is larger than the minimum link MTU size
required for IPv6 [IPv6-Spec].
8.3 ICMP Messages for IPv4 Original Packets
The tunnel entry-point node builds the ICMP and IPv4 header of the
ICMP message that is sent to the source of the original packet as
follows:
IPv4 Fields:
Source Address
A valid unicast IPv4 address of the outgoing
interface.
Destination Address
Copied from the Source Address field of the Original
IPv4 header.
ICMP Fields:
For any of the following tunnel ICMP error messages:
"hop limit exceeded"
"unreachable node"
"parameter problem" - pointing to a valid Tunnel Enacpsulation
Limit destination header with the Tun Encap Lim field set to a
value zero:
Type 3 - destination unreachable
Code 1 - host unreachable
For a tunnel ICMP error message "packet too big":
Type 3 - destination unreachable
Code 4 - packet too big
MTU The MTU field from the tunnel ICMP message minus
the length of the tunnel headers.
According to the general rules described in section 7.2, an ICMP
"packet too big" message is sent to the original IPv4 packet source
node if the the original IPv4 header has the DF - don't fragment -
bit flag SET.
8.4 ICMP Messages for Nested Tunnel Packets
In case of an error uncovered with a nested tunnel packet, the inner
tunnel entry-point, which receives the ICMP error message from the
inner tunnel reporting node, relays the ICMP message to the outer
tunnel entry-point following the mechanisms described in sections
8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays
the ICMP message to the source of the original packet, following the
same mechanisms.
9. Security Considerations
An IPv6 tunnel can be secured by securing the IPv6 path between the
tunnel entry-point and exit-point node. The security architecture,
mechanisms, and services are described in [RFC2401], [RFC2402], and
[RFC2406]. A secure IPv6 tunnel may act as a gateway-to-gateway
secure path as described in [RFC2401].
For a secure IPv6 tunnel, in addition to the mechanisms described
earlier in this document, the entry-point node of the tunnel performs
security algorithms on the packet and prepends as part of the tunnel
headers one or more security headers in conformance with [IPv6-Spec],
[RFC2401], and [RFC2402], or [RFC2406].
The exit-point node of a secure IPv6 tunnel performs security
algorithms and processes the tunnel security header[s] as part of the
tunnel headers processing described earlier, and in conformance with
[RFC2401], and [RFC2402], or [RFC2406]. The exit-point node discards
the tunnel security header[s] with the rest of the tunnel headers
after tunnel headers processing completion.
The degree of integrity, authentication, and confidentiality and the
security processing performed on a tunnel packet at the entry-point
and exit-point node of a secure IPv6 tunnel depend on the type of
security header - authentication (AH) or encryption (ESP) - and
parameters configured in the Security Association for the tunnel.
There is no dependency or interaction between the security level and
mechanisms applied to the tunnel packets and the security applied to
the original packets which are the payloads of the tunnel packets.
In case of nested tunnels, each inner tunnel may have its own set of
security services, independently from those of the outer tunnels, or
of those between the source and destination of the original packet.
10. Acknowledgments
This document is partially derived from several discussions about
IPv6 tunneling on the IPng Working Group Mailing List and from
feedback from the IPng Working Group to an IPv6 presentation that
focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July
1995.
Additionally, the following documents that focused on tunneling or
encapsulation were helpful references: RFC1933 (R. Gilligan, E.
Nordmark), RFC1241 (R. Woodburn, D. Mills), RFC1326 (P. Tsuchiya),
RFC1701, RFC1702 (S. Hanks, D. Farinacci, P. Traina), RFC1853 (W.
Simpson), as well as RFC2003 (C. Perkins).
Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik
Nordmark (in alphabetical order) gave valuable reviewing comments and
suggestions for the improvement of this document. Scott Bradner, Ross
Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical
order) shared their view or experience on matters of concern in this
document. Judith Grossman provided a sample of her many years of
editorial and writing experience as well as a good amount of probing
technical questions.
11. References
[IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol
Version 6 (IPv6) Specification", RFC2460, December 1998.
[ICMP-Spec] Conta, A. and S. Deering "Internet Control Message
Protocol for the Internet Protocol Version 6 (IPv6)", RFC
2463, December 1998.
[ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor
Discovery for IP Version 6 (IPv6)", RFC2461, December
1998.
[PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP Version 6 (IPv6)", RFC1981, August 1996.
[RFC2401] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC2401, November 1998.
[RFC2402] Atkinson, R., "IP Authentication Header", RFC2402,
November 1998.
[RFC2406] Atkinson, R., "IP Encapsulation Security Payload (ESP)",
RFC2406, November 1998.
[RFC-1853] Simpson, W., "IP in IP Tunneling", RFC1853, October
1995.
[Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC1700, October 1994. See also:
http://www.iana.org/numbers.html
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
Authors' Addresses
Alex Conta
Lucent Technologies Inc.
300 Baker Ave
Concord, MA 01742-2168
+1-978-287-2842
EMail: aconta@lucent.com
Stephen Deering
Cisco Systems
170 West Tasman Dr
San Jose, CA 95132-1706
Phone: +1-408-527-8213
EMail: deering@cisco.com
Appendix A
A.1 Risk Factors in Nested Encapsulation
Nested encapsulations of a packet become a recursive encapsulation if
the packet reenters an outer tunnel before exiting it. The cases
which present a high risk of recursive encapsulation are those in
which a tunnel entry-point node cannot determine whether a packet
that undergoes encapsulation reenters the tunnel before exiting it.
Routing loops that cause tunnel packets to reenter a tunnel before
exiting it are certainly the major cause of the problem. But since
routing loops exist, and happen, it is important to understand and
describe, the cases in which the risk for recursive encapsulation is
higher.
There are two significant elements that determine the risk factor of
routing loop recursive encapsulation:
(a) the type of tunnel,
(b) the type of route to the tunnel exit-point, which
determines the packet forwarding through the tunnel, that
is, over the tunnel virtual-link.
A.1.1 Risk Factor in Nested Encapsulation - type of tunnel.
The type of tunnels which were identified as a high risk factor for
recursive encapsulation in routing loops are:
"inner tunnels with identical exit-points".
Since the source and destination of an original packet is the main
information used to decide whether to forward a packet through a
tunnel or not, a recursive encapsulation can be avoided in case of a
single tunnel (non-inner), by checking that the packet to be
encapsulated is not originated on the entry-point node. This
mechanism is suggested in [RFC-1853].
However, this type of protection does not seem to work well in case
of inner tunnels with different entry-points, and identical exit-
points.
Inner tunnels with different entry-points and identical exit-points
introduce ambiguity in deciding whether to encapsulate a packet, when
a packet encapsulated in an inner tunnel reaches the entry-point node
of an outer tunnel by means of a routing loop. Because the source of
the tunnel packet is the inner tunnel entry-point node which is
different than the entry-point node of the outer tunnel, the source
address checking (mentioned above) fails to detect an invalid
encapsulation, and as a consequence the tunnel packet gets
encapsulated at the outer tunnel each time it reaches it through the
routing loop.
A.1.2 Risk Factor in Nested Encapsulation - type of route.
The type of route to a tunnel exit-point node has been also
identified as a high risk factor of recursive encapsulation in
routing loops.
One type of route to a tunnel exit-point node is a route to a
specified destination node, that is, the destination is a valid
specified IPv6 address (route to node). Such a route can be selected
based on the longest match of an original packet destination address
with the destination address stored in the tunnel entry-point node
routing table entry for that route. The packet forwarded on such a
route is first encapsulated and then forwarded towards the tunnel
exit-point node.
Another type of route to a tunnel exit-point node is a route to a
specified prefix-net, that is, the destination is a valid specified
IPv6 prefix (route to net). Such a route can be selected based on the
longest path match of an original packet destination address with the
prefix destination stored in the tunnel entry-point node routing
table entry for that route. The packet forwarded on such a route is
first encapsulated and then forwarded towards the tunnel exit-point
node.
And finally another type of route to a tunnel exit-point is a default
route, or a route to an unspecified destination. This route is
selected when no-other match for the destination of the original
packet has been found in the routing table. A tunnel that is the
first hop of a default route is a "default tunnel".
If the route to a tunnel exit-point is a route to node, the risk
factor for recursive encapsulation is minimum.
If the route to a tunnel exit-point is a route to net, the risk
factor for recursive encapsulation is medium. There is a range of
destination addresses that will match the prefix the route is
associated with. If one or more inner tunnels with different tunnel
entry-points have exit-point node addresses that match the route to
net of an outer tunnel exit-point, then a recursive encapsulation may
occur if a tunnel packet gets diverted from inside such an inner
tunnel to the entry-point of the outer tunnel that has a route to its
exit-point that matches the exit-point of an inner tunnel.
If the route to a tunnel exit-point is a default route, the risk
factor for recursive encapsulation is maximum. Packets are forwarded
through a default tunnel for lack of a better route. In many
situations, forwarding through a default tunnel can happen for a wide
range of destination addresses which at the maximum extent is the
entire Internet minus the node's link. As consequence, it is likely
that in a routing loop case, if a tunnel packet gets diverted from an
inner tunnel to an outer tunnel entry-point in which the tunnel is a
default tunnel, the packet will be once more encapsulated, because
the default routing mechanism will not be able to discern
differently, based on the destination.
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.