idnits 2.17.1 draft-templin-aeromin-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 76 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 10, 2014) is 3448 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-82) exists of draft-templin-aerolink-46 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Templin, Ed. 3 Internet-Draft Boeing Research & Technology 4 Intended status: Informational November 10, 2014 5 Expires: May 14, 2015 7 AERO Minimal Encapsulation 8 draft-templin-aeromin-00.txt 10 Abstract 12 Asymmetric Extended Route Optimization (AERO) specifies both a 13 control messaging facility and an encapsulation format for managing 14 tunnels over an enterprise network or other Internetwork. Although 15 AERO can operate with any tunnel encapsulation format, the base 16 document considers IP-in-UDP-in-IP encapsulation as the default. 17 This document presents a minimal encapsulation format for AERO for 18 use when a UDP header is not needed. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 14, 2015. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Minimal Encapsulation Format . . . . . . . . . . . . . . . . 3 56 3. When to Insert the IPv6 Fragment Header . . . . . . . . . . . 3 57 4. Considerations for Using Minimal Encapsulation . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 63 8.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 Asymmetric Extended Route Optimization (AERO) [I-D.templin-aerolink] 69 specifies both a control messaging facility and an encapsulation 70 format for forwarding Internet Protocol (IP) packets [RFC0791] 71 [RFC2460] over an enterprise network or other Internetwork through a 72 process known as tunneling. Although AERO can operate with any 73 tunnel encapsulation format, the base document specifies the 74 insertion of a User Datagram Protocol (UDP) header [RFC0768] with 75 port 8060 between the inner and outer IP headers, i.e., as IP-in-UDP- 76 in-IP. This document presents a minimal encapsulation format for 77 AERO for use when a UDP header is not needed. 79 In its minimal form, AERO can use direct IP-in-IP encapsulation 80 [RFC2003][RFC2473][RFC4213] with no intermediate layer between the 81 inner and outer IP headers for interior routing and addressing 82 services. The encapsulation is therefore only differentiated from 83 other IP-in-IP tunnel types through the application of AERO control 84 messaging facilities. 86 However, the tunnel fragmentation required by AERO to support a 87 guaranteed minimum 1500 bytes cannot be accomplished by inserting an 88 IPv6 Fragment Header immediately following the UDP header, since the 89 UDP header is not included for minimal encapsulation. Instead, the 90 IPv6 fragment header is inserted directly between the inner and outer 91 IP headers when needed, i.e., even if the outer header is IPv4. The 92 IPv6 Fragment Header is identified to the outer IP layer by its IP 93 protocol number, and the Next Header field in the IPv6 Fragment 94 Header identifies the inner IP header version. 96 2. Minimal Encapsulation Format 98 Figure 1 shows the AERO minimal encapsulation format before any 99 fragmentation is applied: 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Outer IPv4 Header | | Outer IPv6 Header | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 |IPv6 Fragment Header (optional)| |IPv6 Fragment Header (optional)| 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Inner IP Header | | Inner IP Header | | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | | | 109 ~ ~ ~ ~ 110 ~ Inner Packet Body ~ ~ Inner Packet Body ~ 111 ~ ~ ~ ~ 112 | | | | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 Minimal Encapsulation in IPv4 Minimal Encapsulation in IPv6 117 Figure 1: Minimal Encapsulation Format 119 3. When to Insert the IPv6 Fragment Header 121 The IPv6 Fragment Header is inserted whenever the AERO tunnel ingress 122 needs to apply fragmentation to accommodate packets no larger than 123 1500 bytes. Fragmentation is performed on the inner packet while 124 encapsulating each inner packet fragment in identical outer IP and 125 IPv6 Fragment Headers. Fragmentation therefore follows the same 126 procedure as for the case when a UDP header is included, which 127 follows the same procedure as for standard IPv6 fragmentation. 129 The IPv6 Fragment Header can also be inserted in order to include a 130 coherent Identification value with each packet, e.g., to aid in 131 Duplicate Packet Detection (DPD). In this way, networking devices 132 can cache the Identification values of recently-seen packets and use 133 the cached values to determine whether a newly-arrived packet is in 134 fact a duplicate. 136 Finally, the Identification value within each packet could provide a 137 rough indicator of packet reordering, e.g., in cases when the tunnel 138 egress wishes to discard packets that are grossly out of order. 140 4. Considerations for Using Minimal Encapsulation 142 Minimal encapsulation is preferred in environments where UDP 143 encapsulation would add unnecessary overhead. For example, certain 144 low-bandwidth wireless data links may benefit from an 8-byte-per- 145 packet overhead reduction. This is not likely to be a prime 146 consideration for many modern wireless data links nor for most modern 147 wired-line data links. 149 UDP encapsulation can traverse network paths that are inaccessible to 150 minimal encapsulation, e.g., for crossing Network Address Translators 151 (NATs). More and more, network middleboxes are also being configured 152 to discard packets that include anything other than a well-known IP 153 protocol such as UDP and TCP. It may therefore be necessary to 154 consider the potential for middlebox filtering before enabling 155 minimal encapsulation in a given environment. 157 Evidence seems to suggest that IPv6 fragmentation does not work along 158 all paths, since well-meaning network middleboxes may consider it as 159 an attack. 161 5. IANA Considerations 163 This document introduces no IANA considerations. 165 6. Security Considerations 167 Security considerations are discussed in the base AERO specification 168 [I-D.templin-aerolink]. 170 7. Acknowledgements 172 TBD 174 8. References 176 8.1. Normative References 178 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 179 August 1980. 181 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 182 1981. 184 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 185 October 1996. 187 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 188 (IPv6) Specification", RFC 2460, December 1998. 190 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 191 IPv6 Specification", RFC 2473, December 1998. 193 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 194 for IPv6 Hosts and Routers", RFC 4213, October 2005. 196 8.2. Informative References 198 [I-D.templin-aerolink] 199 Templin, F., "Transmission of IP Packets over AERO Links", 200 draft-templin-aerolink-46 (work in progress), October 201 2014. 203 Author's Address 205 Fred L. Templin (editor) 206 Boeing Research & Technology 207 P.O. Box 3707 208 Seattle, WA 98124 209 USA 211 Email: fltemplin@acm.org