idnits 2.17.1 draft-zzhang-tsvwg-generic-transport-functions-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 165: '...is reserved. It MUST be 0 on transmit...' RFC 2119 keyword, line 178: '...The outer header MUST identify that a ...' RFC 2119 keyword, line 179: '... follows and MAY carry source-identi...' RFC 2119 keyword, line 186: '...the "S" flag bit MAY be clear if the t...' RFC 2119 keyword, line 217: '... label value. The Node Address MAY be...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2020) is 1271 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tsvwg Z. Zhang 3 Internet-Draft R. Bonica 4 Intended status: Standards Track K. Kompella 5 Expires: May 5, 2021 Juniper Networks 6 November 01, 2020 8 Generic Transport Functions 9 draft-zzhang-tsvwg-generic-transport-functions-00 11 Abstract 13 Some functionalities (e.g. fragmentation/reassembly and Encapsulating 14 Security Payload) provided by IPv6 can be viewed as independent of 15 IPv6 or even IP entirely. This document proposes to provide those 16 functionalities at different layers (e.g., MPLS, BIER or even 17 Ethernet) independent of IP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 5, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Generic Fragmentation Header . . . . . . . . . . . . . . 4 56 2.2. MPLS Signaling . . . . . . . . . . . . . . . . . . . . . 5 57 2.2.1. BGP Signaling . . . . . . . . . . . . . . . . . . . . 5 58 2.2.2. IGP Signaling . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Generic ESP/Authentication Header . . . . . . . . . . . . 6 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 6.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Consider an operator providing Ethernet services such as pseudowires, 71 VPLS or EVPN. The Ethernet frames that a Provider Edge (PE) device 72 receives from a Customer Edge (CE) device may have a larger size than 73 the PE-PE path MTU (pMTU) in the provider network. This could be 74 because 76 1. the provider network is built upon virtual connections (e.g. 77 pseudowires) provided by another infrastructure provider, or 79 2. the customer network uses jumbo frames while the provider network 80 does not, or 82 3. the provider-side overhead for transporting customers packets 83 across the network pushes past the pMTU. 85 In any case, the provider simply cannot require its customers to 86 change their MTU. 88 To get those large frames across the provider network, currently the 89 only workaround is to encapsulate the frames in IP (with or without 90 GRE) and then fragment the IP packets. Even if MPLS is used for 91 service delimiting, IP is used for transporation (MPLS over IP/GRE). 92 This may not be desirable in certain deployment scenarios, where MPLS 93 is the preferred transport or IP encapsulation overhead is deemed 94 excessive. 96 IPv6 fragmentation and reassembly are based on the IPv6 Fragmentation 97 header below [RFC8200]: 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Next Header | Reserved | Fragment Offset |Res|M| 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | Identification | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 Figure 1: IPv6 Fragmentation Header 107 This document proposes reusing this header in non-IP contexts, since 108 the fragmentation/reassembly function is actually independent of IPv6 109 except the following aspects: 111 o The fragment header is identified as such by the "previous" 112 header. 114 o The "Next Header" value is from the "Internet Protocol Numbers" 115 registry. 117 o The "Identification" value is unique in the (source, destination) 118 context provided by the IPv6 header 120 The "Identification" field, in conjunction with the IPv6 source and 121 destination identifies fragments of the original packet, for the 122 purpose of reassembly. 124 Therefore, the fragmentation/reassembly function can be applied at 125 other layers as long as a) the fragment header is identified as such; 126 and b) the context for packet identification is provided. Examples 127 of such layers include MPLS, BIER, and Ethernet (if IEEE determines 128 it is so desired). 130 For the layers where the IETF is concerned, the "Next Header" value 131 will still be from the "Internet Protocol Numbers" registry when the 132 function is applied at non-IP layers. 134 For the same consideration, the IP Encapsulating Security Payload 135 (ESP) [RFC4303] could also be applied at other layers if ESP is 136 desired there. For example, if for whatever reason the Ethernet 137 service provider wants to provide ESP between its PEs, it could do so 138 without requiring IP encapsulation if ESP is applied at non-IP 139 layers. 141 The possibility of applying some other IP functions (e.g. 142 Authentication Header [RFC4302]) is for further study. 144 2. Specifications 146 2.1. Generic Fragmentation Header 148 For generic fragmentation/reassembly functionality independent of IP, 149 the following Generic Fragmentation Header (GFH) is defined: 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Next Header | Header Length | Fragment Offset |R|S|M| 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Identification | 155 | (variable) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 2: Generic Fragmentation Header 160 The "Next Header", "Fragment Offset" and "M" flag bit fields are as 161 in the IPv6 Fragmentation Header. 163 Header Length: the number of octets of the entire header. 165 R: The "R" flag bit is reserved. It MUST be 0 on transmitting and 166 ignored on receiving. 168 Identification: at least 4-octet long. 170 S: If the "S" flag bit is clear, the context for the Identification 171 field is provided by the outer header, and only the source- 172 identifying information in the outer header is used. If the "S" 173 flag bit is set, the variable Identification field encodes both 174 source-identifying information (e.g. the IP address of the node 175 adding the GFH) and an identification number unique within that 176 source. 178 The outer header MUST identify that a Generic Fragmentation Header 179 follows and MAY carry source-identifying information. 181 If the outer header is BIER, a TBD value for the "proto" field in the 182 BIER header identifies that a GFH follows. If the "S" flag bit is 183 clear, the "BFIR-id" field in the BIER header provides the context 184 for the "Identification" field. 186 If the outer header is MPLS, the "S" flag bit MAY be clear if the the 187 label preceeding the GFH identifies the sending BFR in addition to 188 indicating that a GFH follows (see Section 2.2). 190 2.2. MPLS Signaling 192 When GFH is used with MPLS, the preceeding label needs to indicate 193 that a GFH follows, and optionally identify the node that does the 194 fragmentation. The label can be signaled via BGP or IGP as sepcified 195 below. 197 2.2.1. BGP Signaling 199 This document defines a new transitive BGP "GFH Labels" attribute, 200 very similar to the "PE Distinguisher Labels" attribute defined in 201 [RFC6514] (and the text below is adapted from Section 8 of 202 [RFC6514]): 204 +---------------------------------+ 205 | Node Address | 206 +---------------------------------+ 207 | Label (3 octets) | 208 +---------------------------------+ 209 ....... 210 +---------------------------------+ 211 | Node Address | 212 +---------------------------------+ 213 | Label (3 octets) | 214 +---------------------------------+ 216 The Label field contains an MPLS label encoded as 3 octets, where the 217 high-order 20 bits contain the label value. The Node Address MAY be 218 0, meaning that the following label only indicates a GFH follows when 219 the label is used in the label stack of a data packet. 221 The Node Address MAY also be a unicast address, indicating that the 222 following label when used in the label stack of a data packet will 223 both indicate that a GFH follows and identify the sending node. 225 If a node supports GFH with MPLS, it attaches the attribute in the 226 BGP routes for its local addresses. A border router SHOULD remove 227 the attribute if no node beyond the border will use GFH with MPLS to 228 send traffic to the corresponding addresses. 230 A router that supports the attribute considers this attribute to be 231 malformed if the Node Address field does not contain a unicast 232 address or 0. The attribute is also considered to be malformed if: 233 (a) the Node Address field is expected to be an IPv4 address, and the 234 length of the attribute is not a multiple of 7 or (b) the Node 235 Address field is expected to be an IPv6 address, and the length of 236 the attribute is not a multiple of 19. The Address Family Indicator 237 (AFI) of the BGP route that the attribute is attached to provides the 238 information on whether the Node Address field contains an IPv4 or 239 IPv6 address. Each of the Node Addresses in the attribute MUST be of 240 the same address family as the route that is carrying the attribute. 242 2.2.2. IGP Signaling 244 This document defines an OSPFv2 "GFH Labels" sub-TLV of OSPFv2 245 Extended Prefix TLV [RFC7684], with the value part being the same as 246 BGP "GFH Labels" attribute above. If an OSPFv2 router surports GFH 247 with MPLS, it includes the GFH Labels sub-TLV in the Extended Prefix 248 TLV that is attached to its local addresses advertised in its OSPFv2 249 Extended Prefix Opaque LSA. 251 Similary, This document defines an OSPFv3 "GFH Labels" sub-TLV of 252 OSPFv3 Intra/Inter-Area-Prefix TLVs [RFC8362], with the value part 253 being the same as BGP "GFH Labels" attribute above. If an OSPFv3 254 router surports GFH with MPLS, it includes the GFH Labels sub-TLV in 255 the Intra-Area-Prefix TLV for its local addresses. 257 This document also defines an ISIS "GFH Labels" sub-TLV of ISIS 258 prefix-reachability TLV [RFC5120] [RFC5305] [RFC5308], with the value 259 part being the same as BGP "GFH Labels" attribute above. If an ISIS 260 router surports GFH with MPLS, it includes the sub-TLV to the prefix- 261 reachability TLV for its local addresses. 263 For both OSPF and ISIS, when advertising a prefix from one area/level 264 to another, if there is a "GFH Labels TLV" attached in the source 265 area/level, the TLV SHOULD be attached in the target area/level and 266 the prefix SHOULD NOT be summarized. 268 2.3. Generic ESP/Authentication Header 270 To be specified in future revisions. 272 3. Security Considerations 274 To be provided. 276 4. IANA Considerations 278 This document makes the following IANA requests: 280 o A new BGP Attribute type for "GFH Labels" from the BGP Path 281 Attributes registry 283 o A new OSPFv2 sub-TLV type for "GFH Labels" from the OSPFv2 284 Extended Prefix TLV Sub-TLVs registry 286 o A new OSPFv3 sub-TLV type for "GFH Labels" from the OSPFv3 287 Extended-LSA sub-TLV registry 289 o A new BIER Next Protocol Identifier value for GFH from BIER Next 290 Protocol Identifiers registry 292 5. Acknowledgements 294 6. References 296 6.1. Normative References 298 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 299 RFC 4303, DOI 10.17487/RFC4303, December 2005, 300 . 302 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 303 Topology (MT) Routing in Intermediate System to 304 Intermediate Systems (IS-ISs)", RFC 5120, 305 DOI 10.17487/RFC5120, February 2008, 306 . 308 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 309 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 310 2008, . 312 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 313 DOI 10.17487/RFC5308, October 2008, 314 . 316 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 317 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 318 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 319 2015, . 321 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 322 (IPv6) Specification", STD 86, RFC 8200, 323 DOI 10.17487/RFC8200, July 2017, 324 . 326 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 327 F. Baker, "OSPFv3 Link State Advertisement (LSA) 328 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 329 2018, . 331 6.2. Informative References 333 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 334 DOI 10.17487/RFC4302, December 2005, 335 . 337 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 338 Encodings and Procedures for Multicast in MPLS/BGP IP 339 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 340 . 342 Authors' Addresses 344 Zhaohui Zhang 345 Juniper Networks 346 1133 Innovation Way 347 Sunnyvale 94089 348 USA 350 Phone: +1 408 745 2000 351 Email: zzhang@juniper.net 353 Ron Bonica 354 Juniper Networks 355 1133 Innovation Way 356 Sunnyvale 94089 357 USA 359 Phone: +1 408 745 2000 360 Email: rbonica@juniper.net 362 Kireeti Kompella 363 Juniper Networks 364 1133 Innovation Way 365 Sunnyvale 94089 366 USA 368 Phone: +1 408 745 2000 369 Email: kireeti@juniper.net