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