idnits 2.17.1 draft-ietf-intarea-gre-ipv6-14.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 (September 1, 2015) is 3158 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-27) exists of draft-ietf-opsec-v6-06 -- Obsolete informational reference (is this intentional?): RFC 7042 (Obsoleted by RFC 9542) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intarea Working Group C. Pignataro 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R. Bonica 5 Expires: March 4, 2016 Juniper Networks 6 S. Krishnan 7 Ericsson 8 September 1, 2015 10 IPv6 Support for Generic Routing Encapsulation (GRE) 11 draft-ietf-intarea-gre-ipv6-14 13 Abstract 15 Generic Routing Encapsulation (GRE) can be used to carry any network- 16 layer payload protocol over any network-layer delivery protocol. 17 Currently, GRE procedures are specified for IPv4, used as either the 18 payload or delivery protocol. However, GRE procedures are not 19 specified for IPv6. 21 This document specifies GRE procedures for IPv6, used as either the 22 payload or delivery protocol. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 4, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3 67 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3 68 3. IPv6 as GRE Payload . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4 70 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4 71 3.3. Fragmentation Considerations . . . . . . . . . . . . . . 5 72 4. IPv6 as GRE Delivery Protocol . . . . . . . . . . . . . . . . 6 73 4.1. Next Header Considerations . . . . . . . . . . . . . . . 6 74 4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 6 75 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 81 8.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used 87 to carry any network-layer payload protocol over any network-layer 88 delivery protocol. Currently, GRE procedures are specified for IPv4 89 [RFC0791], used as either the payload or delivery protocol. However, 90 GRE procedures are not specified for IPv6 [RFC2460]. 92 This document specifies GRE procedures for IPv6, used as either the 93 payload or delivery protocol. Like RFC 2784, this document describes 94 how GRE has been implemented by several vendors. 96 1.1. Terminology 98 The following terms are used in this document: 100 o GRE delivery header - an IPv4 or IPv6 header whose source address 101 represents the GRE ingress node and whose destination address 102 represents the GRE egress node. The GRE delivery header 103 encapsulates a GRE header. 105 o GRE header - the GRE protocol header. The GRE header is 106 encapsulated in the GRE delivery header and encapsulates GRE 107 payload. 109 o GRE payload - a network layer packet that is encapsulated by the 110 GRE header. 112 o GRE overhead - the combined size of the GRE delivery header and 113 the GRE header, measured in bytes. 115 o path MTU (PMTU) - the minimum MTU of all the links in a path 116 between a source node and a destination node. If the source and 117 destination node are connected through equal cost multipath 118 (ECMP), the PMTU is equal to the minimum link MTU of all links 119 contributing to the multipath. 121 o Path MTU Discovery (PMTUD) - A procedure for dynamically 122 discovering the PMTU between two nodes on the Internet. PMTUD 123 procedures for IPv6 are defined in [RFC1981]. 125 o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum 126 packet size in bytes, that can be conveyed over a GRE tunnel 127 without fragmentation of any kind. The GMTU is equal to the PMTU 128 associated with the path between the GRE ingress and the GRE 129 egress, minus the GRE overhead. 131 2. GRE Header Fields 133 This document does not change the GRE header format or any behaviors 134 specified by RFC 2784 or RFC 2890. 136 2.1. Checksum Present 138 The GRE ingress node SHOULD set the Checksum Present field in the GRE 139 header to zero. However, implementations MAY support a configuration 140 option that causes the GRE ingress node to set the Checksum Present 141 field to one. 143 As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum 144 Present field to calculate the length of the GRE header. If the 145 Checksum Present field is set to one, the GRE egress node MUST use 146 the GRE Checksum to verify the integrity of the GRE header and 147 payload. 149 Setting the Checksum Present field to zero reduces the computational 150 cost of GRE encapsulation and decapsulation. In many cases, the GRE 151 Checksum is partially redundant with other checksums. For example: 153 o if the payload protocol is IPv4, the IPv4 header is protected by 154 both the GRE Checksum and the IPv4 Checksum 156 o if the payload carries TCP [RFC0793], the TCP pseudo header, TCP 157 header, and TCP payload are protected by both the GRE Checksum and 158 TCP Checksum 160 o if the payload carries UDP [RFC0768], the UDP pseudo header, UDP 161 header, and UDP payload are protected by both the GRE Checksum and 162 UDP Checksum 164 However, if the GRE Checksum Present field is set to zero, the GRE 165 header is not protected by any checksum. Furthermore, depending on 166 which of the above-mentioned conditions are true, selected portions 167 of the GRE payload will not be protected by any checksum. 169 Network operators should evaluate risk factors in their networks and 170 configure GRE ingress nodes appropriately. 172 3. IPv6 as GRE Payload 174 The following considerations apply to GRE tunnels that carry an IPv6 175 payload. 177 3.1. GRE Protocol Type Considerations 179 The Protocol Type field in the GRE header MUST be set to Ether Type 180 [RFC7042] 0x86DD (IPv6). 182 3.2. MTU Considerations 184 A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from 185 ingress to egress, without fragmenting the payload packet. All GRE 186 tunnels with a GMTU of 1280 bytes or greater satisfy this 187 requirement. GRE tunnels that can fragment and reassemble delivery 188 packets also satisfy this requirement, regardless of their GMTU. 189 However, the ability to fragment and reassemble delivery packets is 190 not a requirement of this specification. This specification requires 191 only that GRE ingress nodes refrain from activating GRE tunnels that 192 do not satisfy the above-mentioned requirement. 194 Before activating a GRE tunnel and periodically thereafter, the GRE 195 ingress node MUST verify the tunnel's ability to carry a 1280-byte 196 IPv6 payload packet from ingress to egress, without fragmenting the 197 payload. Having executed those procedures, the GRE ingress node MUST 198 activate or deactivate the tunnel accordingly. 200 Implementation details regarding the above-mentioned verification 201 procedures are beyond the scope of this document. However, a GRE 202 ingress node can verify tunnel capabilities by sending a 1280-byte 203 IPv6 packet addressed to itself through the tunnel under test. 205 Many existing implementations [RFC7588] do not support the above- 206 mentioned verification procedures. Unless deployed in environments 207 where the GMTU is guaranteed to be greater than 1280, these 208 implementations MUST be configured so that the GRE endpoints can 209 fragment and reassemble the GRE delivery packet. 211 3.3. Fragmentation Considerations 213 When the GRE ingress receives an IPv6 payload packet whose length is 214 less than or equal to the GMTU, it can encapsulate and forward the 215 packet without fragmentation of any kind. In this case, the GRE 216 ingress router MUST NOT fragment the payload or delivery packets. 218 When the GRE ingress receives an IPv6 payload packet whose length is 219 greater than the GMTU, and the GMTU is greater than or equal to 1280 220 bytes, the GRE ingress router MUST: 222 o discard the IPv6 payload packet 224 o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 225 payload packet source. The MTU field in the ICMPv6 PTB message is 226 set to the GMTU. 228 When the GRE ingress receives an IPv6 payload packet whose length is 229 greater than the GMTU, and the GMTU is less than 1280 bytes, the GRE 230 ingress router MUST: 232 o encapsulate the entire IPv6 packet in a single GRE header and IP 233 delivery header 235 o fragment the delivery header, so that it can be reassembled by the 236 GRE egress 238 4. IPv6 as GRE Delivery Protocol 240 The following considerations apply when the delivery protocol is 241 IPv6. 243 4.1. Next Header Considerations 245 When the GRE delivery protocol is IPv6, the GRE header MAY 246 immediately follow the GRE delivery header. Alternatively, IPv6 247 extension headers MAY be inserted between the GRE delivery header and 248 the GRE header. 250 If the GRE header immediately follows the GRE delivery header, the 251 Next Header field in the IPv6 header of the GRE delivery packet MUST 252 be set to 47. If extension headers are inserted between the GRE 253 delivery header and the GRE header, the Next Header field in the last 254 IPv6 extension header MUST be set to 47. 256 4.2. Checksum Considerations 258 As stated in [RFC2784], the GRE header can contain a checksum. If 259 present, the GRE header checksum can be used to detect corruption of 260 the GRE header and GRE payload. 262 The GRE header checksum cannot be used to detect corruption of the 263 IPv6 delivery header. Furthermore, the IPv6 delivery header does not 264 contain a checksum of its own. Therefore, no available checksum can 265 be used to detect corruption of the IPv6 delivery header. 267 In one failure scenario, the destination address in the IPv6 delivery 268 header is corrupted. As a result, the IPv6 delivery packet is 269 delivered to a node other than the intended GRE egress node. 270 Depending upon the state and configuration of that node, it will 271 either: 273 a. Drop the packet 275 b. De-encapsulate the payload and forward it to its intended 276 destination 278 c. De-encapsulate the payload and forward it to a node other than 279 its intended destination. 281 Behaviors a) and b) are acceptable. Behavior c) is not acceptable. 283 Behavior c) is possible only when the following conditions are true: 285 1. The intended GRE egress node is a Virtual Private Network (VPN) 286 Provider Edge (PE) router. 288 2. The node to which the GRE delivery packet is mistakenly delivered 289 is also a VPN PE router. 291 3. VPNs are attached to both of the above-mentioned nodes. At least 292 two of these VPN's number hosts from non-unique (e.g., [RFC1918]) 293 address space. 295 4. The intended GRE egress node maintains state that causes it to 296 decapsulate the packet and forward the payload to its intended 297 destination 299 5. The node to which the GRE delivery packet is mistakenly delivered 300 maintains state that causes it to decapsulate the packet and 301 forward the payload to an identically numbered host in another 302 VPN. 304 While the failure scenario described above is extremely unlikely, a 305 single misdelivered packet can adversely impact applications running 306 on the node to which the packet is misdelivered. Furthermore, 307 leaking packets across VPN boundaries also constitutes a security 308 breach. The risk associated with behavior c) could be mitigated with 309 end-to-end authentication of the payload. 311 Before deploying GRE over IPv6, network operators should consider the 312 likelihood of behavior c) in their network. GRE over IPv6 MUST NOT 313 be deployed other than where the network operator deems the risk 314 associated with behavior c) to be acceptable. 316 4.3. MTU Considerations 318 By default, the GRE ingress node cannot fragment the IPv6 delivery 319 header. However, implementations MAY support an optional 320 configuration in which the GRE ingress node can fragment the IPv6 321 delivery header. 323 Also by default, the GRE egress node cannot reassemble the IPv6 324 delivery header. However, implementations MAY support an optional 325 configuration in which the GRE egress node can reassemble the IPv6 326 delivery header. 328 5. IANA Considerations 330 This document makes no request of IANA. 332 6. Security Considerations 334 The Security Considerations section of [RFC4023] identifies threats 335 encountered when MPLS is delivered over GRE. These threats apply to 336 any GRE payload. As stated in RFC 4023, the various threats can be 337 mitigated through options such as authenticating and/or encrypting 338 the delivery packet using IPSec [RFC4301]. Alternatively when the 339 payload is IPv6, these threats can also be mitigated by 340 authenticating and/or encrypting the payload using IPsec, instead of 341 the delivery packet. Otherwise, the current specification introduces 342 no security considerations beyond those mentioned in RFC 2784. 344 More generally, security considerations for IPv6 are discussed in 345 [RFC4942]. Operational security for IPv6 is discussed in 346 [I-D.ietf-opsec-v6], and security concerns for tunnels in general are 347 discussed in [RFC6169]. 349 7. Acknowledgements 351 The authors would like to thank Fred Baker, Stewart Bryant, Benoit 352 Claise, Ben Campbell, Carlos Jesus Bernardos Cano, Spencer Dawkins, 353 Dino Farinacci, David Farmer, Brian Haberman, Tom Herbert, Kathleen 354 Moriarty, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Yong 355 for their thorough review and useful comments. 357 8. References 359 8.1. Normative References 361 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 362 DOI 10.17487/RFC0768, August 1980, 363 . 365 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 366 DOI 10.17487/RFC0791, September 1981, 367 . 369 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 370 RFC 793, DOI 10.17487/RFC0793, September 1981, 371 . 373 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 374 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 375 1996, . 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, 379 DOI 10.17487/RFC2119, March 1997, 380 . 382 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 383 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 384 December 1998, . 386 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 387 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 388 DOI 10.17487/RFC2784, March 2000, 389 . 391 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 392 RFC 2890, DOI 10.17487/RFC2890, September 2000, 393 . 395 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 396 "Encapsulating MPLS in IP or Generic Routing Encapsulation 397 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 398 . 400 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 401 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 402 December 2005, . 404 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 405 Control Message Protocol (ICMPv6) for the Internet 406 Protocol Version 6 (IPv6) Specification", RFC 4443, 407 DOI 10.17487/RFC4443, March 2006, 408 . 410 8.2. Informative References 412 [I-D.ietf-opsec-v6] 413 Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational 414 Security Considerations for IPv6 Networks", draft-ietf- 415 opsec-v6-06 (work in progress), March 2015. 417 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 418 and E. Lear, "Address Allocation for Private Internets", 419 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 420 . 422 [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ 423 Co-existence Security Considerations", RFC 4942, 424 DOI 10.17487/RFC4942, September 2007, 425 . 427 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 428 Concerns with IP Tunneling", RFC 6169, 429 DOI 10.17487/RFC6169, April 2011, 430 . 432 [RFC7042] Eastlake 3rd, D. and J. Abley, "IANA Considerations and 433 IETF Protocol and Documentation Usage for IEEE 802 434 Parameters", BCP 141, RFC 7042, DOI 10.17487/RFC7042, 435 October 2013, . 437 [RFC7588] Bonica, R., Pignataro, C., and J. Touch, "A Widely 438 Deployed Solution to the Generic Routing Encapsulation 439 (GRE) Fragmentation Problem", RFC 7588, 440 DOI 10.17487/RFC7588, July 2015, 441 . 443 Authors' Addresses 445 Carlos Pignataro 446 Cisco Systems 447 7200-12 Kit Creek Road 448 Research Triangle Park, North Carolina 27709 449 USA 451 Email: cpignata@cisco.com 453 Ron Bonica 454 Juniper Networks 455 2251 Corporate Park Drive 456 Herndon, Virginia 457 USA 459 Email: rbonica@juniper.net 460 Suresh Krishnan 461 Ericsson 462 8400 Decarie Blvd. 463 Town of Mount Royal, QC 464 Canada 466 Phone: +1 514 345 7900 x42871 467 Email: suresh.krishnan@ericsson.com