idnits 2.17.1 draft-ietf-intarea-gre-ipv6-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2784, updated by this document, for RFC5378 checks: 1999-11-22) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2015) is 3371 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETYPES' ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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 Updates: 2784 (if approved) R. Bonica 5 Intended status: Standards Track Juniper Networks 6 Expires: July 31, 2015 S. Krishnan 7 Ericsson 8 January 27, 2015 10 IPv6 Support for Generic Routing Encapsulation (GRE) 11 draft-ietf-intarea-gre-ipv6-00 13 Abstract 15 Generic Routing Encapsulation (GRE) can be used to carry any network 16 layer protocol over any network layer protocol. GRE procedures are 17 specified for IPv4, used as either the payload or delivery protocol. 18 However, GRE procedures are not specified for IPv6, used as either 19 the payload or delivery protocol. 21 This document specifies GRE procedures for IPv6, used as either the 22 payload or delivery protocol, and updates RFC 2784, the original GRE 23 specification. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 31, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. GRE Header Fields . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Checksum Present . . . . . . . . . . . . . . . . . . . . 3 69 2.2. Protocol Type . . . . . . . . . . . . . . . . . . . . . . 3 70 3. IPv6 as a GRE Payload . . . . . . . . . . . . . . . . . . . . 4 71 4. IPv6 as a GRE Delivery Protocol . . . . . . . . . . . . . . . 4 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 75 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 78 1. Introduction 80 Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used 81 to encapsulate and carry any network layer protocol (payload) over 82 any network layer protocol (delivery). GRE procedures are specified 83 for IPv4 [RFC0791], used as either the payload or delivery protocol. 84 However, GRE procedures are not specified for IPv6 [RFC2460], used as 85 either the payload or delivery protocol. 87 This document specifies GRE procedures for IPv6, used as either the 88 payload or delivery protocol, and updates RFC 2784 [RFC2784]. 90 1.1. Terminology 92 The following terms are specific to GRE and are modeled from 93 [RFC2784]: 95 o GRE delivery header - an IPv4 or IPv6 header whose source address 96 represents the GRE ingress node and whose destination address 97 represents the GRE egress node. The GRE delivery header 98 encapsulates a GRE header. 100 o GRE header - the GRE protocol header. The GRE header is 101 encapsulated by the GRE delivery header and encapsulates GRE 102 payload. 104 o GRE payload packet - a network layer packet that needs to be 105 encapsulated and delivered to some destination, and is 106 encapsulated by the GRE header. 108 The following terms are specific MTU discovery: 110 o path MTU (PMTU) - the minimum MTU of all the links in a path 111 between a source node and a destination node. If the source and 112 destination node are connected through equal cost multipath 113 (ECMP), the PMTU is equal to the minimum link MTU of all links 114 contributing to the multipath. 116 o Path MTU Discovery (PMTUD) - A procedure for dynamically 117 discovering the PMTU between two nodes on the Internet. PMTUD 118 procedures for IPv6 are defined in [RFC1981]. 120 2. GRE Header Fields 122 This document does not change any other fields or behaviors of the 123 GRE specification [RFC2784] [RFC2890]. 125 2.1. Checksum Present 127 The Checksum Present field SHOULD be set to zero by senders if IPv6 128 is used as a delivery protocol. Receivers MUST also accept a value 129 of one in this field and use it to calculate the GRE header length 130 but they MUST NOT verify the contents of the Checksum field. 132 2.2. Protocol Type 134 The Protocol Type field contains the protocol type of the payload 135 packet. These Protocol Types are defined in [ETYPES]. An 136 implementation receiving a packet containing a Protocol Type which is 137 not listed in [ETYPES] SHOULD discard the packet. 139 3. IPv6 as a GRE Payload 141 When the GRE payload is IPv6, the Protocol Type field in the GRE 142 header MUST be set to 0x86DD. 144 4. IPv6 as a GRE Delivery Protocol 146 When the GRE delivery protocol is IPv6, the GRE header can 147 immediately follow the GRE delivery header. Alternatively, IPv6 148 extension headers MAY be inserted between the GRE delivery header and 149 the GRE header. However, the IPv6 Destination Options Header MUST 150 NOT be inserted between the GRE delivery header and the GRE header. 152 If the GRE header immediately follows the GRE delivery header, the 153 Next Header field in the IPv6 header of the GRE delivery packet MUST 154 be set to the value 47. If extension headers are inserted between 155 the GRE delivery header and the GRE header, the Next Header field in 156 the last IPv6 extension header MUST be set to 47. 158 Following guidance provided in Section 5 of [RFC2460], GRE ingress 159 nodes SHOULD implement PMTUD, in order to discover and take advantage 160 of PMTUs greater than the IPv6 required minimum (1280 octets). 161 However, a GRE ingress node MAY simply restrict itself to sending 162 packets no larger than 1280 octets, and omit implementation of PMTUD. 164 5. IANA Considerations 166 This document makes no request of IANA. 168 6. Security Considerations 170 This document adds no additional security risks to GRE, beyond what 171 is specified in [RFC2784]. It also does not provide any additional 172 security for GRE. 174 7. Acknowledgements 176 The authors would like to thank Fred Baker, Dino Farinacci, and 177 Andrew Yourtchenko for their thorough review and useful comments. 179 8. Normative References 181 [ETYPES] IANA, "ETHER TYPES", 2014, 182 . 185 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 186 1981. 188 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 189 for IP version 6", RFC 1981, August 1996. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 195 (IPv6) Specification", RFC 2460, December 1998. 197 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 198 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 199 March 2000. 201 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 202 RFC 2890, September 2000. 204 Authors' Addresses 206 Carlos Pignataro 207 Cisco Systems 208 7200-12 Kit Creek Road 209 Research Triangle Park, North Carolina 27709 210 USA 212 Email: cpignata@cisco.com 214 Ron Bonica 215 Juniper Networks 216 2251 Corporate Park Drive 217 Herndon, Virginia 218 USA 220 Email: rbonica@juniper.net 222 Suresh Krishnan 223 Ericsson 224 8400 Decarie Blvd. 225 Town of Mount Royal, QC 226 Canada 228 Phone: +1 514 345 7900 x42871 229 Email: suresh.krishnan@ericsson.com