idnits 2.17.1 draft-templin-intarea-grefrag-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 : ---------------------------------------------------------------------------- ** 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 135: '...E tunnnel egress MUST therefore config...' RFC 2119 keyword, line 136: '... 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 (April 8, 2015) is 3306 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 154, 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-52 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) April 8, 2015 5 Intended status: Informational 6 Expires: October 10, 2015 8 GRE Tunnel Fragmentation 9 draft-templin-intarea-grefrag-00.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 October 10, 2015. 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 two new control bits ("F" 88 and "D"): 90 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 91 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 92 |C| |K|S|F|D| Reserved0 | Ver | Protocol Type | 93 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 94 | Checksum (optional) | Reserved1 (Optional) | 95 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 96 | Key (optional) | 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Sequence Number (Optional) | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Fragment Header (Optional) | 101 | | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Figure 1: GRE Header with Fragment Header 106 In this format, when the "F" bit is set to 1 the GRE header includes 107 a Fragment header formatted as specified in Section 4.5 of [RFC2460]. 108 When the "D" bit is set to 1, this serves as an indicating to any 109 further GRE encapsulations in the path (i.e., either a nested 110 encapsulation or a re-encapsulation) that the GRE packet must not be 111 fragmented (further). 113 3. GRE Tunnel Fragmentation Procedures 115 GRE tunnel fragmentation treats the entire GRE payload packet 116 (including the payload headers) as opaque data. The GRE tunnel 117 ingress breaks the payload packet into N fragments and encapsulates 118 each fragment in a separate GRE header and GRE delivery header. The 119 first fragment therefore includes the GRE payload headers and first 120 portion of the GRE payload data, while subsequent fragments include 121 the remaining portions of the GRE payload data. The GRE tunnel 122 ingress then sends each fragment to the GRE tunnel egress. Apart 123 from the appearance of the Fragment Header within the GRE header, the 124 fragmentation procedure is the same as for IPv6 fragmentation. 126 When the GRE tunnel egress receives the fragments, it reassembles the 127 GRE payload packet by concatenating the data portions of each 128 fragment according to their offsets. Apart from the appearance of 129 the Fragment Header within the GRE header, the reassembly procedure 130 is the same as for IPv6 reassembly. 132 In order to support this fragmentation and reassembly procedure, the 133 GRE tunnel ingress must know the maximum sized packet the GRE tunnel 134 egress is capable of reassembling, i.e., the Maximum Reassembly Unit 135 (MRU). The GRE tunnnel egress MUST therefore configure a minimum MRU 136 of 2KB, and MAY configure a larger MRU. 138 4. IANA Considerations 140 This document introduces no IANA considerations. 142 5. Security Considerations 144 TBD. 146 6. Acknowledgements 148 TBD 150 7. References 152 7.1. Normative References 154 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 155 1981. 157 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 158 (IPv6) Specification", RFC 2460, December 1998. 160 [RFC2764] Gleeson, B., Heinanen, J., Lin, A., Armitage, G., and A. 161 Malis, "A Framework for IP Based Virtual Private 162 Networks", RFC 2764, February 2000. 164 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 165 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 166 March 2000. 168 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 169 RFC 2890, September 2000. 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., "Transmission of IP Packets over AERO Links", 180 draft-templin-aerolink-52 (work in progress), February 181 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