idnits 2.17.1 draft-templin-intarea-grefrag-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '... packet MUST be dropped....' RFC 2119 keyword, line 144: '... packet MUST be dropped....' RFC 2119 keyword, line 163: '...eld. This value MUST be no larger tha...' RFC 2119 keyword, line 176: '... MUST configure a minimum MRU of 150...' RFC 2119 keyword, line 177: '...on overhead, and MAY configure a large...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 29, 2016) is 2821 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 196, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 205, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-03 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-70 Summary: 2 errors (**), 0 flaws (~~), 6 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 Updates: RFC1701, RFC2784, RFC2890 (if July 29, 2016 5 approved) 6 Intended status: Informational 7 Expires: January 30, 2017 9 GRE Tunnel Level Fragmentation 10 draft-templin-intarea-grefrag-03.txt 12 Abstract 14 GRE tunnels use IP fragmentation for delivery packets that exceed the 15 path MTU. However, IP fragmentation has been shown to be susceptible 16 to reassembly errors at high data rates, and IP fragments may be 17 unconditionally dropped by some middleboxes. This document therefore 18 introduces GRE tunnel level fragmentation, which overcomes these 19 issues. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 30, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. GRE Fragmentation Header . . . . . . . . . . . . . . . . . . 2 57 3. GRE Tunnel Level Fragmentation and Reassembly . . . . . . . . 4 58 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 63 7.2. Informative References . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 GRE is specified in the following RFCs: 69 [RFC1701][RFC2784][RFC2890][RFC7676]. GRE fragmentation 70 considerations are further discussed in [RFC7588]. In its current 71 manifestation, GRE allows for fragmentation of the payload packet 72 only if it is an IPv4 packet with the Don't Fragment (DF) bit set to 73 0. GRE also allows for IP fragmentation of the delivery packet, but 74 IP fragmentation has been shown to be susceptible to reassembly 75 errors at high data rates [RFC4963] and IP fragments may be 76 unconditionally dropped by some middleboxes [I-D.taylor-v6ops- 77 fragdrop]. 79 A third option (introduced here) is for the GRE tunnel to perform 80 "tunnel level" fragmentation and reassembly on the payload packet at 81 the GRE layer. In this way, the ingress can fragment the payload 82 packet (while treating the payload packet's headers as ordinary data) 83 and encapsulate each fragment in a separate delivery header. The GRE 84 header requires a new fragment header field to support this. 86 This tunnel level fragmentation method was first suggested in 87 Section 3.1.7 of [RFC2764], and also appears in more recent works 88 [I-D.templin-aerolink] [I-D.herbert-gue-fragmentation]. 89 [I-D.ietf-intarea-tunnels] provides the architectural background for 90 tunnel fragemntation and reassembly. 92 2. GRE Fragmentation Header 94 Figure 1 shows the GRE header as specified in [RFC1701] but with a 95 new optional "Fragment Header" and a new control bit "F": 97 0 1 2 3 98 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 |C|R|K|S|s|Recur|F| Flags | Ver | Protocol Type | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Checksum (optional) | Offset (optional) | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Key (optional) | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Sequence Number (optional) | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Fragment Header (Optional) | 109 | | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | Routing (optional) 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1: GRE Header with Fragment Header 116 In this format, when the "F" bit (i.e., bit 8) is set to 1 the GRE 117 header includes a Fragment header formatted as follows: 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Fragment offset |Res|M| Reserved(2) | | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 124 | Identification | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Figure 2: GRE Fragemnt Header Format 129 The fields of the option are: 131 o Fragment offset: This field indicates where in the datagram this 132 fragment belongs. The fragment offset is measured in units of 8 133 octets (64 bits). The first fragment has offset zero. 135 o Res: Two bit reserved field. Must be set to zero for 136 transmission. If set to non-zero in a received packet then the 137 packet MUST be dropped. 139 o M: More fragments bit. Set to 1 when there are more fragments 140 following in the datagram, set to 0 for the last fragment. 142 o Reserved(2): Eight bit reserved field. Must be set to zero for 143 transmission. If set to non-zero in a received packet then the 144 packet MUST be dropped. 146 o Identification: 40 bits. Identifies fragments of a fragmented 147 packet. 149 Note that these formats are the same as specified in 150 [I-D.herbert-gue-fragmentation] with the exception that the 151 Reserved(2) field replaces the "Original Type" field since the GRE 152 header already includes a Protocl Type. 154 3. GRE Tunnel Level Fragmentation and Reassembly 156 GRE tunnel level fragmentation treats the entire GRE payload packet 157 (including the payload headers) as opaque data. The GRE tunnel 158 ingress breaks the payload packet into N fragments and encapsulates 159 each fragment in a separate GRE header and GRE delivery header. For 160 the first fragment, the ingress writes the IEEE802 protocol number in 161 the Protocol Type field the same as for any GRE packet. For other 162 fragments, the ingress instead writes the length of the fragment in 163 the Protocol Type field. This value MUST be no larger than 1500, 164 which the egress will interpret as a length instead of a protocol 165 type. (This implies that the maximum size for a non-initial fragment 166 is 1500 bytes.) The GRE tunnel ingress then sends each fragment to 167 the GRE tunnel egress. 169 When the GRE tunnel egress receives the fragments, it reassembles the 170 GRE payload packet by concatenating the data portions of each 171 fragment according to their offsets. In order to support this tunnel 172 level fragmentation and reassembly procedure, the GRE tunnel ingress 173 must know the maximum sized packet the GRE tunnel egress is capable 174 of reassembling, i.e., the Maximum Reassembly Unit (MRU). In order 175 to avoid interactions with Path MTU Discovery, the GRE tunnel egress 176 MUST configure a minimum MRU of 1500 bytes plus the GRE delivery 177 encapsulation overhead, and MAY configure a larger MRU. 179 4. IANA Considerations 181 This document introduces no IANA considerations. 183 5. Security Considerations 185 Security considerations for GRE apply also to this document. 187 6. Acknowledgements 189 The following are acknowledged for their helpful comments: Tom 190 Herbert, Carlos Pignataro, Joe Touch. 192 7. References 194 7.1. Normative References 196 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 197 DOI 10.17487/RFC0791, September 1981, 198 . 200 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 201 Routing Encapsulation (GRE)", RFC 1701, 202 DOI 10.17487/RFC1701, October 1994, 203 . 205 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 206 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 207 December 1998, . 209 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 210 Malis, "A Framework for IP Based Virtual Private 211 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 212 . 214 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 215 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 216 DOI 10.17487/RFC2784, March 2000, 217 . 219 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 220 RFC 2890, DOI 10.17487/RFC2890, September 2000, 221 . 223 [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely 224 Deployed Solution to the Generic Routing Encapsulation 225 (GRE) Fragmentation Problem", RFC 7588, 226 DOI 10.17487/RFC7588, July 2015, 227 . 229 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 230 for Generic Routing Encapsulation (GRE)", RFC 7676, 231 DOI 10.17487/RFC7676, October 2015, 232 . 234 7.2. Informative References 236 [I-D.herbert-gue-fragmentation] 237 Herbert, T. and F. Templin, "Fragmentation option for 238 Generic UDP Encapsulation", draft-herbert-gue- 239 fragmentation-02 (work in progress), October 2015. 241 [I-D.ietf-intarea-tunnels] 242 Touch, D. and W. Townsley, "IP Tunnels in the Internet 243 Architecture", draft-ietf-intarea-tunnels-03 (work in 244 progress), July 2016. 246 [I-D.templin-aerolink] 247 Templin, F., "Asymmetric Extended Route Optimization 248 (AERO)", draft-templin-aerolink-70 (work in progress), 249 July 2016. 251 [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly 252 Errors at High Data Rates", RFC 4963, 253 DOI 10.17487/RFC4963, July 2007, 254 . 256 Author's Address 258 Fred L. Templin (editor) 259 Boeing Research & Technology 260 P.O. Box 3707 261 Seattle, WA 98124 262 USA 264 Email: fltemplin@acm.org