idnits 2.17.1 draft-deering-ipv6-encap-addr-deletion-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 14, 2002) is 8017 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'TBD' is defined on line 239, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'TBD' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Steve Deering 3 INTERNET-DRAFT Cisco 4 draft-deering-ipv6-encap-addr-deletion-00.txt Brian Zill 5 November 14, 2001 Microsoft 6 Expires May 14, 2002 8 Redundant Address Deletion when Encapsulating IPv6 in IPv6 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. 21 It is inappropriate to use Internet-Drafts as reference material or to 22 cite them other than as ``work in progress.'' 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 Distribution of this memo is unlimited. 29 The internet-draft will expire in 6 months. The date of expiration will 30 be May 14, 2002. 32 Abstract 34 In some potentially common uses of IPv6-in-IPv6 encapsulation 35 ("tunneling"), a node that is performing an encapsulation or 36 decapsulation will also be the source or destination of the packet 37 being encapsulated. That can result in the same IPv6 address 38 appearing in both the outer (encapsulating) and inner (encapsulated) 39 IPv6 headers. This document specifies a method for deleting such 40 redundant addresses from an inner header when performing an 41 encapsulation, and restoring those addresses when decapsulating, 42 resulting in a 16-octet (128-bit) reduction in header overhead, 43 per address deleted. 45 1. Introduction 47 Encapsulation of IP packets inside other IP packets (usually called 48 "tunneling") has been used to achieve a number of goals in the IPv4 49 Internet, and the same mechanism is likely also to be widely used in 50 Redundant Address Deletion when Encapsulating IPv6 in IPv6 52 in the IPv6 Internet. In some of the common uses of IP-in-IP 53 encapsulation, such as mobile IP tunnels or so-called "virtual private 54 network" (VPN) tunnels terminating on individual hosts, a node performing 55 an encapsulation or decapsulation may also be the source or destination 56 of the packet being encapsulated. In other words, a tunnel entrance/exit 57 may coincide with one of the endpoints of the traffic being tunneled. 58 When that is the case, the same IP address may appear in both the outer 59 (encapsulating) IP header and the inner (encapsulated) IP header. In 60 the case of IPv6, those addresses are 16 octets (128 bits) long -- a 61 significant per-packet overhead -- and it would be desirable to avoid 62 such duplication of information if possible. This document specifies a 63 method for deleting such addresses from IPv6-in-IPv6 encapsulated 64 packets. 66 2. Redundant Address Deletion/Restoration 68 At the point at which an IPv6 packet is being encapsulated in another 69 IPv6 packet, the normal behavior is to take a packet of the following 70 format: 72 +----+--------+--------+ +------------ 73 | | | | | 74 |iNAF| iSRC | iDEST | | iPAYLOAD 75 | | | | | 76 +----+--------+--------+ +------------ 78 and prepend one or more headers to produce a packet of the following 79 format: 81 <-- outer IPv6 header -> <-- inner IPv6 header -> 82 +----+--------+--------+ + - - -+ +----+--------+--------+ +------------ 83 | | | | : : | | | | | 84 |oNAF| oSRC | oDEST | : oEXT : |iNAF| iSRC | iDEST | | iPAYLOAD 85 | | | | : : | | | | | 86 +----+--------+--------+ + - - -+ +----+--------+--------+ +------------ 88 where: 89 NAF represents the non-address fields of an IPv6 header 90 (I.e., the first 8 octets of an IPv6 header) 92 SRC is an IPv6 source address 94 DEST is an IPv6 destination address 96 EXT is zero or more IPv6 extension headers 98 the prefix "o" means "outer" 100 the prefix "i" means "inner" 101 Redundant Address Deletion when Encapsulating IPv6 in IPv6 103 The presence of the inner IPv6 header is indicated by the IANA-assigned 104 value 41 (decimal) in the Next Header field of the last outer header. If 105 there are no outer extension headers (oEXT) present, this is the Next 106 Header field in the oNAF part of the outer IPv6 header; otherwise, it is 107 the Next Header field of the last ("rightmost") outer extension header. 109 To enable deletion of redundant IPv6 addresses, three new "Next Header" 110 values are introduced: 112 IPv6_NO_SRC (value TBD) - indicates an IPv6 header with its 113 Source Address field removed 115 IPv6_NO_DEST (value TBD) - indicates an IPv6 header with it 116 Destination Address field removed 118 IPv6_NO_ADDRS (value TBD) - indicates an IPv6 header with both 119 of its address fields removed 121 When performing the encapsulation, the encapsulating node compares the 122 addresses in the outer and inner IPv6 headers and produces packets as 123 follows: 125 If oSRC == iSRC & oDEST != iDEST, produce a packet of the following 126 format: 128 <-- outer IPv6 header -> <- inner hdr -> 129 +----+--------+--------+ + - - -+ +----+--------+ +------------ 130 | | | | : : | | | | 131 |oNAF| oSRC | oDEST | : oEXT : |iNAF| iDEST | | iPAYLOAD 132 | | | | : : | | | | 133 +----+--------+--------+ + - - -+ +----+--------+ +------------ 135 and set the Next Header field of the last outer header to 136 IPv6_NO_SRC. 138 If oSRC != iSRC & oDEST == iDEST, produce a packet of the following 139 format: 141 <-- outer IPv6 header -> <- inner hdr -> 142 +----+--------+--------+ + - - -+ +----+--------+ +------------ 143 | | | | : : | | | | 144 |oNAF| oSRC | oDEST | : oEXT : |iNAF| iSRC | | iPAYLOAD 145 | | | | : : | | | | 146 +----+--------+--------+ + - - -+ +----+--------+ +------------ 148 and set the Next Header field of the last outer header to 149 IPv6_NO_DEST. 151 Redundant Address Deletion when Encapsulating IPv6 in IPv6 153 If oSRC == iSRC & oDEST == iDEST, produce a packet of the following 154 format: 156 <-- outer IPv6 header -> <-in-> 157 +----+--------+--------+ + - - -+ +----+ +------------ 158 | | | | : : | | | 159 |oNAF| oSRC | oDEST | : oEXT : |iNAF| | iPAYLOAD 160 | | | | : : | | | 161 +----+--------+--------+ + - - -+ +----+ +------------ 163 and set the Next Header field of the last outer header to 164 IPv6_NO_ADDRS. 166 Otherwise, produce the normal encapsulated format with a full 167 inner IPv6 header, identified by a Next Header value of 41. 169 When performing a decapsulation, the decapsulating node uses the 170 Next Header value of the last outer header to determine which, if 171 any, of the addresses were deleted from the inner IPv6 header, and 172 restores them from the coresponding addresses received in the outer 173 IPv6 header, to produce the original encapsulated packet: 175 +----+--------+--------+ +------------ 176 | | | | | 177 |iNAF| iSRC | iDEST | | iPAYLOAD 178 | | | | | 179 +----+--------+--------+ +------------ 181 3. Issues 183 [This part isn't done yet. The following are the authors' notes to 184 themselves, identifying issues to be discussed in the next version 185 of this draft] 187 - Discuss MTU and fragmentation considerations when using this 188 technique. No particular problems, because the transformations 189 all increase the available MTU, rather than reduce it, compared 190 to the normal encapsulation case. 192 - Note that the technique described herein can and should be applied 193 recursively, when a node is the entry/exit point of a tunnel within 194 a tunnel (within a tunnel....). 196 - Observe that the same technique can be used when the last outer 197 header is not a standard IPv6 extension header with a Next Header 198 field, e.g., when doing UDP tunneling or GRE tunneling. In those 199 cases, three new code points will have to be assigned in whatever 200 "next header" code space is used by those particular headers (e.g., 201 well-known port numbers for UDP, or ethertypes for GRE), to identify 202 Redundant Address Deletion when Encapsulating IPv6 in IPv6 204 the three forms of IPv6 headers with deleted addresses. 206 - Explain why we don't also propose deleting other possiby redundant 207 fields in the iNAF part of the inner header. (The reason has to do 208 with maintaining 64-bit alignment of all headers, for efficient 209 memory access. In cases where saving every byte or bit matters, 210 there already exist IPv6 header compression standards that work 211 across multiple headers, including encapsulations. However, if this 212 spec is adopted, those other standards should be updated to take 213 into account the three new variants of the IPv6 header defined here.) 215 - Discuss backwards-compatibility issues, i.e., ensuring that these 216 forms of encapsulation are not used by a tunnel entry-point without 217 assurance that the tunnel exit-point understands and implements them. 219 - Perhaps add some words suggesting that, when there is a choice of 220 addresses for the outer header, an effort be made to pick ones that 221 are the same as ones present in the inner header, whenever possible. 223 n. Security Considerations 225 [haven't thought about this yet] 227 m. IANA Considerations 229 This specification requires the assignment of three new 8-bit Protocol 230 Type values to be used in IPv6 Next Header fields. It is suggested that 231 those new Protocol Types be named as follows: 233 IPv6_NO_SRC 234 IPv6_NO_DEST 235 IPv6_NO_ADDRS 237 References 239 [TBD] 241 Change History 243 None. 245 Acknowledgements 247 [TBD: acknowledge previous examples of this general idea, e.g., RFC 2004] 248 Redundant Address Deletion when Encapsulating IPv6 in IPv6 250 Authors' Addresses 252 Steve Deering 253 Cisco Systems, Inc. 254 170 West Tasman Drive 255 San Jose, CA 95134-1706 256 USA 257 Phone: +1 408 527 8213 258 Wmail: deering@cisco.com 260 Brian Zill 261 Microsoft Research 262 One Microsoft Way 263 Redmond, WA 98052 264 USA 265 Phone: +1 425 703 3568 266 Email: bzill@microsoft.com