Internet DRAFT - draft-deering-ipv6-encap-addr-deletion
draft-deering-ipv6-encap-addr-deletion
Internet Engineering Task Force Steve Deering
INTERNET-DRAFT Cisco
draft-deering-ipv6-encap-addr-deletion-00.txt Brian Zill
November 14, 2001 Microsoft
Expires May 14, 2002
Redundant Address Deletion when Encapsulating IPv6 in IPv6
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 and
may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as ``work in progress.''
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be May 14, 2002.
Abstract
In some potentially common uses of IPv6-in-IPv6 encapsulation
("tunneling"), a node that is performing an encapsulation or
decapsulation will also be the source or destination of the packet
being encapsulated. That can result in the same IPv6 address
appearing in both the outer (encapsulating) and inner (encapsulated)
IPv6 headers. This document specifies a method for deleting such
redundant addresses from an inner header when performing an
encapsulation, and restoring those addresses when decapsulating,
resulting in a 16-octet (128-bit) reduction in header overhead,
per address deleted.
1. Introduction
Encapsulation of IP packets inside other IP packets (usually called
"tunneling") has been used to achieve a number of goals in the IPv4
Internet, and the same mechanism is likely also to be widely used in
Deering Standards Track - Expires May 2002 1
Redundant Address Deletion when Encapsulating IPv6 in IPv6
in the IPv6 Internet. In some of the common uses of IP-in-IP
encapsulation, such as mobile IP tunnels or so-called "virtual private
network" (VPN) tunnels terminating on individual hosts, a node performing
an encapsulation or decapsulation may also be the source or destination
of the packet being encapsulated. In other words, a tunnel entrance/exit
may coincide with one of the endpoints of the traffic being tunneled.
When that is the case, the same IP address may appear in both the outer
(encapsulating) IP header and the inner (encapsulated) IP header. In
the case of IPv6, those addresses are 16 octets (128 bits) long -- a
significant per-packet overhead -- and it would be desirable to avoid
such duplication of information if possible. This document specifies a
method for deleting such addresses from IPv6-in-IPv6 encapsulated
packets.
2. Redundant Address Deletion/Restoration
At the point at which an IPv6 packet is being encapsulated in another
IPv6 packet, the normal behavior is to take a packet of the following
format:
+----+--------+--------+ +------------
| | | | |
|iNAF| iSRC | iDEST | | iPAYLOAD
| | | | |
+----+--------+--------+ +------------
and prepend one or more headers to produce a packet of the following
format:
<-- outer IPv6 header -> <-- inner IPv6 header ->
+----+--------+--------+ + - - -+ +----+--------+--------+ +------------
| | | | : : | | | | |
|oNAF| oSRC | oDEST | : oEXT : |iNAF| iSRC | iDEST | | iPAYLOAD
| | | | : : | | | | |
+----+--------+--------+ + - - -+ +----+--------+--------+ +------------
where:
NAF represents the non-address fields of an IPv6 header
(I.e., the first 8 octets of an IPv6 header)
SRC is an IPv6 source address
DEST is an IPv6 destination address
EXT is zero or more IPv6 extension headers
the prefix "o" means "outer"
the prefix "i" means "inner"
Deering Standards Track - Expires May 2002 2
Redundant Address Deletion when Encapsulating IPv6 in IPv6
The presence of the inner IPv6 header is indicated by the IANA-assigned
value 41 (decimal) in the Next Header field of the last outer header. If
there are no outer extension headers (oEXT) present, this is the Next
Header field in the oNAF part of the outer IPv6 header; otherwise, it is
the Next Header field of the last ("rightmost") outer extension header.
To enable deletion of redundant IPv6 addresses, three new "Next Header"
values are introduced:
IPv6_NO_SRC (value TBD) - indicates an IPv6 header with its
Source Address field removed
IPv6_NO_DEST (value TBD) - indicates an IPv6 header with it
Destination Address field removed
IPv6_NO_ADDRS (value TBD) - indicates an IPv6 header with both
of its address fields removed
When performing the encapsulation, the encapsulating node compares the
addresses in the outer and inner IPv6 headers and produces packets as
follows:
If oSRC == iSRC & oDEST != iDEST, produce a packet of the following
format:
<-- outer IPv6 header -> <- inner hdr ->
+----+--------+--------+ + - - -+ +----+--------+ +------------
| | | | : : | | | |
|oNAF| oSRC | oDEST | : oEXT : |iNAF| iDEST | | iPAYLOAD
| | | | : : | | | |
+----+--------+--------+ + - - -+ +----+--------+ +------------
and set the Next Header field of the last outer header to
IPv6_NO_SRC.
If oSRC != iSRC & oDEST == iDEST, produce a packet of the following
format:
<-- outer IPv6 header -> <- inner hdr ->
+----+--------+--------+ + - - -+ +----+--------+ +------------
| | | | : : | | | |
|oNAF| oSRC | oDEST | : oEXT : |iNAF| iSRC | | iPAYLOAD
| | | | : : | | | |
+----+--------+--------+ + - - -+ +----+--------+ +------------
and set the Next Header field of the last outer header to
IPv6_NO_DEST.
Deering Standards Track - Expires May 2002 3
Redundant Address Deletion when Encapsulating IPv6 in IPv6
If oSRC == iSRC & oDEST == iDEST, produce a packet of the following
format:
<-- outer IPv6 header -> <-in->
+----+--------+--------+ + - - -+ +----+ +------------
| | | | : : | | |
|oNAF| oSRC | oDEST | : oEXT : |iNAF| | iPAYLOAD
| | | | : : | | |
+----+--------+--------+ + - - -+ +----+ +------------
and set the Next Header field of the last outer header to
IPv6_NO_ADDRS.
Otherwise, produce the normal encapsulated format with a full
inner IPv6 header, identified by a Next Header value of 41.
When performing a decapsulation, the decapsulating node uses the
Next Header value of the last outer header to determine which, if
any, of the addresses were deleted from the inner IPv6 header, and
restores them from the coresponding addresses received in the outer
IPv6 header, to produce the original encapsulated packet:
+----+--------+--------+ +------------
| | | | |
|iNAF| iSRC | iDEST | | iPAYLOAD
| | | | |
+----+--------+--------+ +------------
3. Issues
[This part isn't done yet. The following are the authors' notes to
themselves, identifying issues to be discussed in the next version
of this draft]
- Discuss MTU and fragmentation considerations when using this
technique. No particular problems, because the transformations
all increase the available MTU, rather than reduce it, compared
to the normal encapsulation case.
- Note that the technique described herein can and should be applied
recursively, when a node is the entry/exit point of a tunnel within
a tunnel (within a tunnel....).
- Observe that the same technique can be used when the last outer
header is not a standard IPv6 extension header with a Next Header
field, e.g., when doing UDP tunneling or GRE tunneling. In those
cases, three new code points will have to be assigned in whatever
"next header" code space is used by those particular headers (e.g.,
well-known port numbers for UDP, or ethertypes for GRE), to identify
Deering Standards Track - Expires May 2002 4
Redundant Address Deletion when Encapsulating IPv6 in IPv6
the three forms of IPv6 headers with deleted addresses.
- Explain why we don't also propose deleting other possiby redundant
fields in the iNAF part of the inner header. (The reason has to do
with maintaining 64-bit alignment of all headers, for efficient
memory access. In cases where saving every byte or bit matters,
there already exist IPv6 header compression standards that work
across multiple headers, including encapsulations. However, if this
spec is adopted, those other standards should be updated to take
into account the three new variants of the IPv6 header defined here.)
- Discuss backwards-compatibility issues, i.e., ensuring that these
forms of encapsulation are not used by a tunnel entry-point without
assurance that the tunnel exit-point understands and implements them.
- Perhaps add some words suggesting that, when there is a choice of
addresses for the outer header, an effort be made to pick ones that
are the same as ones present in the inner header, whenever possible.
n. Security Considerations
[haven't thought about this yet]
m. IANA Considerations
This specification requires the assignment of three new 8-bit Protocol
Type values to be used in IPv6 Next Header fields. It is suggested that
those new Protocol Types be named as follows:
IPv6_NO_SRC
IPv6_NO_DEST
IPv6_NO_ADDRS
References
[TBD]
Change History
None.
Acknowledgements
[TBD: acknowledge previous examples of this general idea, e.g., RFC 2004]
Deering Standards Track - Expires May 2002 5
Redundant Address Deletion when Encapsulating IPv6 in IPv6
Authors' Addresses
Steve Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 527 8213
Wmail: deering@cisco.com
Brian Zill
Microsoft Research
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 703 3568
Email: bzill@microsoft.com
Deering Standards Track - Expires May 2002 6
