idnits 2.17.1 draft-templin-intarea-grefrag-01.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 130: '...E tunnnel egress MUST therefore config...' RFC 2119 keyword, line 131: '... of 2KB, and MAY configure a larger ...' == 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 (August 5, 2015) is 3186 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 149, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-herbert-gue-fragmentation-00 == Outdated reference: A later version (-82) exists of draft-templin-aerolink-61 Summary: 2 errors (**), 0 flaws (~~), 5 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: RFC2784, RFC2890 (if approved) August 5, 2015 5 Intended status: Informational 6 Expires: February 6, 2016 8 GRE Tunnel Fragmentation 9 draft-templin-intarea-grefrag-01.txt 11 Abstract 13 GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet 14 when the delivery packet exceeds the tunnel MTU, or when otherwise 15 necessary. This can cause problems when unmitigated IPv4 16 fragemntation ensues, or when middleboxes drop IPv6 fragments 17 unconditionally. This document proposes GRE tunnel fragmentation 18 which avoids these pitfalls.. 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 February 6, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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. GRE Fragmentation Header . . . . . . . . . . . . . . . . . . 2 56 3. GRE Tunnel Fragmentation Procedures . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 7.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 GRE is specified in [RFC2784] and [RFC2890]. In its current 68 manifestation, GRE allows for fragmentation of the payload packet 69 only if it is an IPv4 packet with the Don't Fragment (DF) bit set to 70 0. GRE also allows for fragmentation of the delivery packet, but 71 this can cause problems in some applications. A third option 72 (introduced here) is for the GRE tunnel to perform tunnel 73 fragmentation and reassembly on the payload packet. 75 In this way, the ingress can fragment the payload packet (while 76 treating the payload packet's headers as ordinary data) and 77 encapsulate each fragment in a separate delivery header. The GRE 78 header requires a new fragment header field to support this. 80 This tunnel fragmentation method was first suggested in Section 3.1.7 81 of [RFC2764], and also appears in more recent works 82 [I-D.templin-aerolink] [I-D.herbert-gue-fragmentation]. 84 2. GRE Fragmentation Header 86 Figure 1 shows the GRE header as specified in [RFC2784][RFC2890] but 87 with a new optional "Fragment Header" and a new control bit "F": 89 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 90 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 |C| |K|S|F| Reserved0 | Ver | Protocol Type | 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 | Checksum (optional) | Reserved1 (Optional) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | Key (optional) | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | Sequence Number (Optional) | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Fragment Header (Optional) | 100 | | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 Figure 1: GRE Header with Fragment Header 105 In this format, when the "F" bit is set to 1 the GRE header includes 106 a Fragment header formatted as specified in Section 4.5 of [RFC2460]. 108 3. GRE Tunnel Fragmentation Procedures 110 GRE tunnel fragmentation treats the entire GRE payload packet 111 (including the payload headers) as opaque data. The GRE tunnel 112 ingress breaks the payload packet into N fragments and encapsulates 113 each fragment in a separate GRE header and GRE delivery header. The 114 first fragment therefore includes the GRE payload headers and first 115 portion of the GRE payload data, while subsequent fragments include 116 the remaining portions of the GRE payload data. The GRE tunnel 117 ingress then sends each fragment to the GRE tunnel egress. Apart 118 from the appearance of the Fragment Header within the GRE header, the 119 fragmentation procedure is the same as for IPv6 fragmentation. 121 When the GRE tunnel egress receives the fragments, it reassembles the 122 GRE payload packet by concatenating the data portions of each 123 fragment according to their offsets. Apart from the appearance of 124 the Fragment Header within the GRE header, the reassembly procedure 125 is the same as for IPv6 reassembly. 127 In order to support this fragmentation and reassembly procedure, the 128 GRE tunnel ingress must know the maximum sized packet the GRE tunnel 129 egress is capable of reassembling, i.e., the Maximum Reassembly Unit 130 (MRU). The GRE tunnnel egress MUST therefore configure a minimum MRU 131 of 2KB, and MAY configure a larger MRU. 133 4. IANA Considerations 135 This document introduces no IANA considerations. 137 5. Security Considerations 139 TBD. 141 6. Acknowledgements 143 TBD 145 7. References 147 7.1. Normative References 149 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 150 DOI 10.17487/RFC0791, September 1981, 151 . 153 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 154 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 155 December 1998, . 157 [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. 158 Malis, "A Framework for IP Based Virtual Private 159 Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000, 160 . 162 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 163 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 164 DOI 10.17487/RFC2784, March 2000, 165 . 167 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 168 RFC 2890, DOI 10.17487/RFC2890, September 2000, 169 . 171 7.2. Informative References 173 [I-D.herbert-gue-fragmentation] 174 Herbert, T. and F. Templin, "Fragmentation option for 175 Generic UDP Encapsulation", draft-herbert-gue- 176 fragmentation-00 (work in progress), March 2015. 178 [I-D.templin-aerolink] 179 Templin, F., "Asymmetric Extended Route Optimization 180 (AERO)", draft-templin-aerolink-61 (work in progress), 181 August 2015. 183 Author's Address 185 Fred L. Templin (editor) 186 Boeing Research & Technology 187 P.O. Box 3707 188 Seattle, WA 98124 189 USA 191 Email: fltemplin@acm.org