Intarea Working Group C. Pignataro Internet-Draft Cisco Systems Updates: 2784 (if approved) R. Bonica Intended status: Standards Track Juniper Networks Expires: October 13, 2015 S. Krishnan Ericsson April 11, 2015 IPv6 Support for Generic Routing Encapsulation (GRE) draft-ietf-intarea-gre-ipv6-06 Abstract Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. It updates the GRE specification, RFC 2784. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 13, 2015. Pignataro, et al. Expires October 13, 2015 [Page 1] Internet-Draft GRE IPv6 April 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3 3. IPv6 As GRE Payload . . . . . . . . . . . . . . . . . . . . . 4 3.1. GRE Protocol Type Considerations . . . . . . . . . . . . 4 3.2. MTU Considerations . . . . . . . . . . . . . . . . . . . 4 3.3. Fragmentation Considerations . . . . . . . . . . . . . . 4 4. IPv6 As GRE Delivery Protocol . . . . . . . . . . . . . . . . 5 4.1. Next Header Considerations . . . . . . . . . . . . . . . 5 4.2. Checksum Considerations . . . . . . . . . . . . . . . . . 5 4.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used to carry any network-layer payload protocol over any network-layer delivery protocol. GRE procedures are specified for IPv4 [RFC0791], used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6 [RFC2460]. This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. Like RFC 2784, this document describes Pignataro, et al. Expires October 13, 2015 [Page 2] Internet-Draft GRE IPv6 April 2015 GRE how has been implemented by several vendors. It updates RFC 2784 . 1.1. Terminology The following terms are used in this document: o GRE delivery header - an IPv4 or IPv6 header whose source address represents the GRE ingress node and whose destination address represents the GRE egress node. The GRE delivery header encapsulates a GRE header. o GRE header - the GRE protocol header. The GRE header is encapsulated in the GRE delivery header and encapsulates GRE payload. o GRE payload - a network layer packet that is encapsulated by the GRE header. o GRE overhead - the combined size of the GRE delivery header and the GRE header, measured in bytes o path MTU (PMTU) - the minimum MTU of all the links in a path between a source node and a destination node. If the source and destination node are connected through equal cost multipath (ECMP), the PMTU is equal to the minimum link MTU of all links contributing to the multipath. o Path MTU Discovery (PMTUD) - A procedure for dynamically discovering the PMTU between two nodes on the Internet. PMTUD procedures for IPv6 are defined in [RFC1981]. o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum packet size in bytes, that can be conveyed over a GRE tunnel without fragmentation of any kind. The GMTU is equal to the PMTU associated with the path between the GRE ingress and the GRE egress, minus the GRE overhead 2. GRE Header Fields This document does not change the GRE header format or any behaviors specified by RFC 2784 or RFC 2890. 2.1. Checksum Present When the delivery protocol is IPv6, the GRE ingress node SHOULD set the Checksum Present field to zero. GRE egress nodes MUST accept either a value of zero or one in this field. If the GRE egress node Pignataro, et al. Expires October 13, 2015 [Page 3] Internet-Draft GRE IPv6 April 2015 receives a value of one, it MUST use that information to calculate the GRE header length. It MUST also use the checksum to verify packet integrity. 3. IPv6 As GRE Payload The following considerations apply to GRE tunnels that carry IPv6 payload. 3.1. GRE Protocol Type Considerations The Protocol Type field in the GRE header MUST be set to Ether Type [ETYPES] 0x86DD. 3.2. MTU Considerations A GRE tunnel MUST be able to carry a 1280-byte IPv6 packet from ingress to egress, without fragmenting the payload packet. All GRE tunnels with a GMTU of 1280 bytes or greater satisfy this requirement. GRE tunnels that can fragment and reassemble delivery packets also satisfy this requirement, regardless of their GMTU. However, the ability to fragment and reassemble delivery packets is not a requirement of this specification. This specification requires only that GRE ingress nodes refrain from activating GRE tunnels that do not satisfy the above-mentioned requirement. Before activating a GRE tunnel and periodically thereafter, the GRE ingress node MUST execute procedures that verify the tunnel's ability to carry a 1280-byte IPv6 payload packet from ingress to egress, without fragmenting the payload. Having executed those procedures, the GRE ingress node MUST activate or deactivate the tunnel accordingly. Implementation details regarding the above-mentioned verification procedures are beyond the scope of this document. However, a GRE ingress node can verify tunnel capabilities by sending a 1280-byte IPv6 packet addressed to itself through the tunnel under test. 3.3. Fragmentation Considerations When the GRE ingress receives an IPv6 payload packet whose length is less than or equal to the GMTU, it can encapsulate and forward the packet without fragmentation of any kind. In this case, the GRE ingress router MUST NOT fragment the payload or delivery packets. When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is greater than or equal to 1280 bytes, the GRE ingress router MUST: Pignataro, et al. Expires October 13, 2015 [Page 4] Internet-Draft GRE IPv6 April 2015 o discard the IPv6 payload packet o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 payload packet source. The MTU field in the ICMPv6 PTB message is set to the GMTU. When the GRE ingress receives an IPv6 payload packet whose length is greater than the GMTU, and the GMTU is less than 1280 bytes, the GRE ingress router MUST: o encapsulate the entire IPv6 packet in a single GRE header and IP delivery header o fragment the delivery header, so that it can be reassembled by the GRE egress 4. IPv6 As GRE Delivery Protocol The following considerations apply when the delivery protocol is IPv6. 4.1. Next Header Considerations When the GRE delivery protocol is IPv6, the GRE header MAY immediately follow the GRE delivery header. Alternatively, IPv6 extension headers MAY be inserted between the GRE delivery header and the GRE header. If the GRE header immediately follows the GRE delivery header, the Next Header field in the IPv6 header of the GRE delivery packet MUST be set to 47. If extension headers are inserted between the GRE delivery header and the GRE header, the Next Header field in the last IPv6 extension header MUST be set to 47. 4.2. Checksum Considerations As stated in [RFC2784], the GRE header can contain a checksum. If present, the GRE header checksum can be used to detect corruption of the GRE header and GRE payload. The GRE header checksum cannot be used to detect corruption of the IPv6 delivery header. Furthermore, the IPv6 delivery header does not contain a checksum of its own. Therefore, no available checksum can be used to detect corruption of the IPv6 delivery header. In one failure scenario, the destination address in the IPv6 delivery header is corrupted. As a result, the IPv6 delivery packet is delivered to a node other than the intended GRE egress node. Pignataro, et al. Expires October 13, 2015 [Page 5] Internet-Draft GRE IPv6 April 2015 Depending upon the state and configuration of that node, it will either: a. Drop the packet b. De-encapsulate the payload and forward it to its intended destination c. De-encapsulate the payload and forward it to a node other than its intended destination. For example, the payload might be intended for a node on one VPN, but delivered to an identically numbered node in another VPN. Behaviors a) and b) are acceptable. Behavior c) is not acceptable. Before deploying GRE over IPv6, network operators should consider the likelihood of behavior c) in their network. GRE over IPv6 is deployable only in environments where the network operator deems the risk associated with behavior c) to be acceptable. The risk associated with behavior c) could be mitigated with end-to- end authentication of the payload. 4.3. MTU Considerations By default, the GRE ingress node cannot fragment the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE ingress node can fragment the IPv6 delivery header. Also by default, the GRE egress node cannot reassemble the IPv6 delivery header. However, implementations MAY support an optional configuration in which the GRE egress node can reassemble the IPv6 delivery header. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations The Security Considerations section of [RFC4023] identifies threats encountered when MPLS is deliver over GRE. These threats apply to any GRE payload. As stated in RFC 4023, these threats can be mitigated by authenticating and/or encrypting the delivery packet using IPSec [RFC4301]. Alternatively when the payload is IPv6, these threats can also be mitigated by authenticating and/or encrypting the payload using IPSec, instead of the delivery packet. Otherwise, the Pignataro, et al. Expires October 13, 2015 [Page 6] Internet-Draft GRE IPv6 April 2015 current specification introduces no security considerations beyond those mentioned in RFC 2784. More generically, security considerations for IPv6 are discussed in [RFC4942]. operational security for IPv6 is discussed in [I-D.ietf-opsec-v6], and security concerns for tunnels in general are discussed in [RFC6169]. 7. Acknowledgements The authors would like to thank Fred Baker, Stewart Bryant, Dino Farinacci, David Farmer, Tom Herbert, Fred Templin, Joe Touch, Andrew Yourtchenko and Lucy Yong for their thorough review and useful comments. 8. References 8.1. Normative References [ETYPES] IANA, "ETHER TYPES", 2014, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Pignataro, et al. Expires October 13, 2015 [Page 7] Internet-Draft GRE IPv6 April 2015 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. 8.2. Informative References [I-D.ietf-opsec-v6] Chittimaneni, K., Kaeo, M., and E. Vyncke, "Operational Security Considerations for IPv6 Networks", draft-ietf- opsec-v6-06 (work in progress), March 2015. [RFC4942] Davies, E., Krishnan, S., and P. Savola, "IPv6 Transition/ Co-existence Security Considerations", RFC 4942, September 2007. [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011. Authors' Addresses Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, North Carolina 27709 USA Email: cpignata@cisco.com Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia USA Email: rbonica@juniper.net Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Pignataro, et al. Expires October 13, 2015 [Page 8]