idnits 2.17.00 (12 Aug 2021) /tmp/idnits59781/draft-leymann-banana-data-encap-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2017) is 1636 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: 'RFC2697' is defined on line 194, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2697 -- Possible downref: Normative reference to a draft: ref. 'BANANA-signaling' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BANANA N. Leymann 3 Internet Draft C. Heidemann 4 Intended Category: Proposed Standard Deutsche Telekom AG 5 M. Zhang 6 B. Sarikaya 7 Huawei 8 M. Cullen 9 Painless Security 10 Expires: May 24, 2018 November 20, 2017 12 BANdwidth Aggregation for interNet Access (BANANA) 13 The Data Plane of Bonding Tunnels 14 draft-leymann-banana-data-encap-01.txt 16 Abstract 18 This memo specifies the encapsulation format for data packets of 19 BANdwidth Aggregation for interNet Access (BANANA). 21 Status of this Memo 23 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 2 61 3. Data Encapsulation . . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. The GRE Header . . . . . . . . . . . . . . . . . . . . . . 3 63 4. The Reordering Buffer . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 GRE tunnels are set up over heterogeneous connections between the 75 local BANANA box and the remote BANANA box. These tunnels are bonded 76 together to form a logic single connection for the subscriber. Each 77 tunnel may be used to carry a user's IP packets as payload, which 78 forms a typical IP-over-IP overlay. 80 This document adopts the GRE header with Key and Sequence Number 81 extensions specified by [RFC2890]. The Protocol Type of the GRE 82 header is either 0x0800 (listed as "0x800" in [RFC2784]) or 0x86DD 83 [RFC7676], which indicates that the inner packet is either an IPv4 84 packet or an IPv6 packet, respectively. The GRE Key field is set to 85 a unique value for the bonding GRE tunnels between two peering BANANA 86 boxes. The GRE Sequence Number field is used to maintain the 87 sequence of packets transported in all these GRE tunnels. 89 2. Acronyms and Terminology 91 GRE: Generic Routing Encapsulation [RFC2784] [RFC2890]. 93 RTT: Round-Trip Time. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Data Encapsulation 101 Users' IP (inner) packets are encapsulated in GRE packets that are in 102 turn carried in IP (outer) packets. The general structure of data 103 packets of the GRE Tunnel Bonding Protocol is shown below. 105 +--------------------------------+ 106 | Media Header | 107 +--------------------------------+ 108 | Outer IP Header | 109 +--------------------------------+ 110 | GRE Header | 111 +--------------------------------+ 112 | Inner IP Packet | 113 +--------------------------------+ 115 3.1. The GRE Header 117 The GRE header was first standardized in [RFC2784]. [RFC2890] added 118 the optional Key and Sequence Number fields. 120 The Checksum and the Reserved1 fields are not used in this memo; 121 therefore, the C bit is set to 0. 123 The Key bit is set to 1 so that the Key field is present. The Key 124 field is used as a 32-bit random number. It is generated by the 125 remote BANANA box per bonding connection, and the local BANANA box is 126 notified. 128 The S bit is set to 1, and the Sequence Number field is present and 129 used for in-order delivery (see Section 4 and [RFC2890]). 131 The Protocol Type field in the GRE header MUST be set to 0x0800 for 132 IPv4 or 0x86DD for IPv6. So, the GRE header used by data packets of 133 BANANA has the following format: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |0| |1|1| Reserved0 | Ver | Protocol Type 0x0800/86DD | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Key | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Sequence Number | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 3: The GRE header for BANANA data packets 147 4. The Reordering Buffer 149 The local or remote BANANA box generates sequence numbers to be 150 carried by all incoming packets that need to be distributed into the 151 tunnels. The receiver maintains a small reordering buffer and orders 152 the data packets in this buffer according to the Sequence Number 153 field [RFC2890] of their GRE header. Packets carried in GRE tunnels 154 that are bonded to the same session (see Section 5.2 of [BANANA- 155 signaling]) enter the same reordering buffer. 157 Operators may configure the maximum allowed size (see 158 MAX_PERFLOW_BUFFER in [RFC2890]) of the reordering buffer. They may 159 also configure the maximum time (see OUTOFORDER_TIMER in [RFC2890]) 160 that a packet can stay in the reordering buffer. The 161 OUTOFORDER_TIMER must be configured carefully. Values larger than 162 the difference of the normal Round-Trip Time (RTT) (e.g., 100 ms) of 163 any two connections between the two BANANA boxes are not recommended. 164 Implementation and deployment experiences have demonstrated that 165 there is usually a large margin for the value of MAX_PERFLOW_BUFFER. 166 Values larger than the multiplication of the sum of the line rate of 167 the two connections and the value of OUTOFORDER_TIMER can be used. 169 5. Security Considerations 171 As a security feature, the Key field of the GRE header of the data 172 packets is generated as a 32-bit cleartext password. The local 173 BANANA box and the remote BANANA box validate the Key value and the 174 outer source IP address, and they discard any packets with invalid 175 combinations. 177 See also the Security Considerations section of [BANANA-signaling] 178 and [RFC2890]. 180 6. IANA Considerations 182 IANA need not assign anything for this memo. RFC editor: please 183 remove this section before publication. 185 7. References 187 7.1. Normative References 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, DOI 191 10.17487/RFC2119, March 1997, . 194 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 195 Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, 196 . 198 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 199 "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 200 10.17487/RFC2784, March 2000, . 203 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 204 RFC 2890, DOI 10.17487/RFC2890, September 2000, 205 . 207 [BANANA-signaling] 208 N. Leymann, C. Heidemann, et al, "BANdwidth Aggregation for 209 interNet Access (BANANA) The Control Protocol of Bonding 210 Tunnels", draft-leymann-banana-signaling, work in progress. 212 7.2. Informative References 214 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 215 for Generic Routing Encapsulation (GRE)", RFC 7676, DOI 216 10.17487/RFC7676, October 2015, . 219 Contributors 221 Li Xue 222 Individual 223 Email: xueli_jas@163.com 225 Zhongwen Jiang 226 Huawei Technologies 227 Email: jiangzhongwen@huawei.com 229 Authors' Addresses 231 Nicolai Leymann 232 Deutsche Telekom AG 233 Winterfeldtstrasse 21-27 234 Berlin 10781 235 Germany 236 Phone: +49-170-2275345 237 Email: n.leymann@telekom.de 239 Cornelius Heidemann 240 Deutsche Telekom AG 241 Heinrich-Hertz-Strasse 3-7 242 Darmstadt 64295 243 Germany 244 Phone: +49-6151-5812721 245 Email: heidemannc@telekom.de 247 Mingui Zhang 248 Huawei Technologies 249 No. 156 Beiqing Rd. 250 Haidian District 251 Beijing 100095 252 China 253 Email: zhangmingui@huawei.com 255 Behcet Sarikaya 256 Huawei USA 257 5340 Legacy Dr. Building 3 258 Plano, TX 75024 259 United States of America 260 Email: sarikaya@ieee.org 262 Margaret Cullen 263 Painless Security 264 14 Summer St. Suite 202 265 Malden, MA 02148 266 United States of America 267 Email: margaret@painless-security.com