Network Working Group D. Farinacci
`Request for Comments: 2784 T. Li
`Category: Standards Track Procket Networks
` S. Hanks
` Enron Communications
` D. Meyer
` Cisco Systems
` P. Traina
` Juniper Networks
` March 2000
`
` Generic Routing Encapsulation (GRE)
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
`Abstract
`
` This document specifies a protocol for encapsulation of an arbitrary
` network layer protocol over another arbitrary network layer protocol.
`
`1. Introduction
`
` A number of different proposals [RFC1234, RFC1226] currently exist
` for the encapsulation of one protocol over another protocol. Other
` types of encapsulations [RFC1241, RFC1479] have been proposed for
` transporting IP over IP for policy purposes. This memo describes a
` protocol which is very similar to, but is more general than, the
` above proposals. In attempting to be more general, many protocol
` specific nuances have been ignored. The result is that this proposal
` may be less suitable for a situation where a specific "X over Y"
` encapsulation has been described. It is the attempt of this protocol
` to provide a simple, general purpose mechanism which reduces the
` problem of encapsulation from its current O(n^2) size to a more
` manageable size. This memo purposely does not address the issue of
` when a packet should be encapsulated. This memo acknowledges, but
` does not address problems such as mutual encapsulation [RFC1326].
`
`Farinacci, et al. Standards Track [Page 1]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 1
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
` In the most general case, a system has a packet that needs to be
` encapsulated and delivered to some destination. We will call this
` the payload packet. The payload is first encapsulated in a GRE
` packet. The resulting GRE packet can then be encapsulated in some
` other protocol and then forwarded. We will call this outer protocol
` the delivery protocol. The algorithms for processing this packet are
` discussed later.
`
` Finally this specification describes the intersection of GRE
` currently deployed by multiple vendors.
`
` The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
` SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
` in RFC 2119 [RFC2119].
`
`2. Structure of a GRE Encapsulated Packet
`
` A GRE encapsulated packet has the form:
`
` ---------------------------------
` | |
` | Delivery Header |
` | |
` ---------------------------------
` | |
` | GRE Header |
` | |
` ---------------------------------
` | |
` | Payload packet |
` | |
` ---------------------------------
`
` This specification is generally concerned with the structure of the
` GRE header, although special consideration is given to some of the
` issues surrounding IPv4 payloads.
`
`2.1. GRE Header
`
` The GRE packet header has the form:
`
` 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` |C| Reserved0 | Ver | Protocol Type |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Checksum (optional) | Reserved1 (Optional) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
`
`Farinacci, et al. Standards Track [Page 2]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 2
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`2.2. Checksum Present (bit 0)
`
` If the Checksum Present bit is set to one, then the Checksum and the
` Reserved1 fields are present and the Checksum field contains valid
` information. Note that a compliant implementation MUST accept and
` process this field.
`
`2.3. Reserved0 (bits 1-12)
`
` A receiver MUST discard a packet where any of bits 1-5 are non-zero,
` unless that receiver implements RFC 1701. Bits 6-12 are reserved for
` future use. These bits MUST be sent as zero and MUST be ignored on
` receipt.
`
`2.3.1. Version Number (bits 13-15)
`
` The Version Number field MUST contain the value zero.
`
`2.4. Protocol Type (2 octets)
`
` The Protocol Type field contains the protocol type of the payload
` packet. These Protocol Types are defined in [RFC1700] as "ETHER
` TYPES" and in [ETYPES]. An implementation receiving a packet
` containing a Protocol Type which is not listed in [RFC1700] or
` [ETYPES] SHOULD discard the packet.
`
`2.5. Checksum (2 octets)
`
` The Checksum field contains the IP (one's complement) checksum sum of
` the all the 16 bit words in the GRE header and the payload packet.
` For purposes of computing the checksum, the value of the checksum
` field is zero. This field is present only if the Checksum Present bit
` is set to one.
`
`2.6. Reserved1 (2 octets)
`
` The Reserved1 field is reserved for future use, and if present, MUST
` be transmitted as zero. The Reserved1 field is present only when the
` Checksum field is present (that is, Checksum Present bit is set to
` one).
`
`3. IPv4 as a Payload
`
` When IPv4 is being carried as the GRE payload, the Protocol Type
` field MUST be set to 0x800.
`
`Farinacci, et al. Standards Track [Page 3]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 3
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`3.1. Forwarding Decapsulated IPv4 Payload Packets
`
` When a tunnel endpoint decapsulates a GRE packet which has an IPv4
` packet as the payload, the destination address in the IPv4 payload
` packet header MUST be used to forward the packet and the TTL of the
` payload packet MUST be decremented. Care should be taken when
` forwarding such a packet, since if the destination address of the
` payload packet is the encapsulator of the packet (i.e., the other end
` of the tunnel), looping can occur. In this case, the packet MUST be
` discarded.
`
`4. IPv4 as a Delivery Protocol
`
` The IPv4 protocol 47 [RFC1700] is used when GRE packets are
` enapsulated in IPv4. See [RFC1122] for requirements relating to the
` delivery of packets over IPv4 networks.
`
`5. Interoperation with RFC 1701 Compliant Implementations
`
` In RFC 1701, the field described here as Reserved0 contained a number
` of flag bits which this specification deprecates. In particular, the
` Routing Present, Key Present, Sequence Number Present, and Strict
` Source Route bits have been deprecated, along with the Recursion
` Control field. As a result, the GRE header will never contain the
` Key, Sequence Number or Routing fields specified in RFC 1701.
`
` There are, however, existing implementations of RFC 1701. The
` following sections describe correct interoperation with such
` implementations.
`
`5.1. RFC 1701 Compliant Receiver
`
` An implementation complying to this specification will transmit the
` Reserved0 field set to zero. An RFC 1701 compliant receiver will
` interpret this as having the Routing Present, Key Present, Sequence
` Number Present, and Strict Source Route bits set to zero, and will
` not expect the RFC 1701 Key, Sequence Number or Routing fields to be
` present.
`
`5.2. RFC 1701 Compliant Transmitter
`
` An RFC 1701 transmitter may set any of the Routing Present, Key
` Present, Sequence Number Present, and Strict Source Route bits set to
` one, and thus may transmit the RFC 1701 Key, Sequence Number or
` Routing fields in the GRE header. As stated in Section 5.3, a packet
` with non-zero bits in any of bits 1-5 MUST be discarded unless the
` receiver implements RFC 1701.
`
`Farinacci, et al. Standards Track [Page 4]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 4
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`6. Security Considerations
`
` Security in a network using GRE should be relatively similar to
` security in a normal IPv4 network, as routing using GRE follows the
` same routing that IPv4 uses natively. Route filtering will remain
` unchanged. However packet filtering requires either that a firewall
` look inside the GRE packet or that the filtering is done on the GRE
` tunnel endpoints. In those environments in which this is considered
` to be a security issue it may be desirable to terminate the tunnel at
` the firewall.
`
`7. IANA Considerations
`
` This section considers the assignment of additional GRE Version
` Numbers and Protocol Types.
`
`7.1. GRE Version Numbers
`
` This document specifies GRE version number 0. GRE version number 1 is
` used by PPTP [RFC2637]. Additional GRE version numbers are assigned
` by IETF Consensus as defined in RFC 2434 [RFC2434].
`
`7.2. Protocol Types
`
` GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are
` assigned by Xerox Systems Institute [RFC1700].
`
`8. Acknowledgments
`
` This document is derived from the original ideas of the authors of
` RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,
` Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler,
` Tim Gleeson and others provided many constructive and insightful
` comments.
`
`Farinacci, et al. Standards Track [Page 5]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 5
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`9. Appendix -- Known Issues
`
` This document specifies the behavior of currently deployed GRE
` implementations. As such, it does not attempt to address the
` following known issues:
`
` o Interaction Path MTU Discovery (PMTU) [RFC1191]
`
` Existing implementations of GRE, when using IPv4 as the Delivery
` Header, do not implement Path MTU discovery and do not set the
` Don't Fragment bit in the Delivery Header. This can cause large
` packets to become fragmented within the tunnel and reassembled at
` the tunnel exit (independent of whether the payload packet is using
` PMTU). If a tunnel entry point were to use Path MTU discovery,
` however, that tunnel entry point would also need to relay ICMP
` unreachable error messages (in particular the "fragmentation needed
` and DF set" code) back to the originator of the packet, which is
` not a requirement in this specification. Failure to properly relay
` Path MTU information to an originator can result in the following
` behavior: the originator sets the don't fragment bit, the packet
` gets dropped within the tunnel, but since the originator doesn't
` receive proper feedback, it retransmits with the same PMTU, causing
` subsequently transmitted packets to be dropped.
`
` o IPv6 as Delivery and/or Payload Protocol
`
` This specification describes the intersection of GRE currently
` deployed by multiple vendors. IPv6 as delivery and/or payload
` protocol is not included in the currently deployed versions of GRE.
`
` o Interaction with ICMP
`
` o Interaction with the Differentiated Services Architecture
`
` o Multiple and Looping Encapsulations
`
`10. REFERENCES
`
` [ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-
` numbers
`
` [RFC1122] Braden, R., "Requirements for Internet hosts -
` communication layers", STD 3, RFC 1122, October 1989.
`
` [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
` November 1990.
`
`Farinacci, et al. Standards Track [Page 6]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 6
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
` [RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
` Frames", RFC 1226, May 1991.
`
` [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
` RFC 1234, June 1991.
`
` [RFC1241] Woodburn, R. and D. Mills, "Scheme for an Internet
` Encapsulation Protocol: Version 1", RFC 1241, July 1991.
`
` [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",
` RFC 1326, May 1992.
`
` [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol
` Specification: Version 1", RFC 1479, July 1993.
`
` [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
` 1700, October 1994.
`
` [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
` Routing Encapsulation", RFC 1701, October 1994.
`
` [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
` Routing Encapsulation over IPv4 networks", RFC 1702,
` October 1994.
`
` [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
` Requirement Levels", BCP 14, RFC 2119, March, 1997.
`
` [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
` "Internet Security Association and Key Management Protocol
` (ISAKMP)", RFC 2408, November 1998.
`
` [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
` IANA Considerations Section in RFCs", BCP 26, RFC 2434,
` October, 1998.
`
` [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol
` (PPTP)", RFC 2637, July, 1999.
`
`Farinacci, et al. Standards Track [Page 7]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 7
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`11. Authors' Addresses
`
` Dino Farinacci
` Procket Networks
` 3850 No. First St., Ste. C
` San Jose, CA 95134
`
` EMail: dino@procket.com
`
` Tony Li
` Procket Networks
` 3850 No. First St., Ste. C
` San Jose, CA 95134
`
` Phone: +1 408 954 7903
` Fax: +1 408 987 6166
` EMail: tony1@home.net
`
` Stan Hanks
` Enron Communications
`
` EMail: stan_hanks@enron.net
`
` David Meyer
` Cisco Systems, Inc.
` 170 Tasman Drive
` San Jose, CA, 95134
`
` EMail: dmm@cisco.com
`
` Paul Traina
` Juniper Networks
` EMail: pst@juniper.net
`
`Farinacci, et al. Standards Track [Page 8]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 8
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`
`RFC 2784 Generic Routing Encapsulation March 2000
`
`12. Full Copyright Statement
`
` Copyright (C) The Internet Society (2000). All Rights Reserved.
`
` This document and translations of it may be copied and furnished to
` others, and derivative works that comment on or otherwise explain it
` or assist in its implementation may be prepared, copied, published
` and distributed, in whole or in part, without restriction of any
` kind, provided that the above copyright notice and this paragraph are
` included on all such copies and derivative works. However, this
` document itself may not be modified in any way, such as by removing
` the copyright notice or references to the Internet Society or other
` Internet organizations, except as needed for the purpose of
` developing Internet standards in which case the procedures for
` copyrights defined in the Internet Standards process must be
` followed, or as required to translate it into languages other than
` English.
`
` The limited permissions granted above are perpetual and will not be
` revoked by the Internet Society or its successors or assigns.
`
` This document and the information contained herein is provided on an
` "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
` TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
` BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
` HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
` MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
`
`Acknowledgement
`
` Funding for the RFC Editor function is currently provided by the
` Internet Society.
`
`Farinacci, et al. Standards Track [Page 9]
`
`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 9
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`

`

`MPH Technologies Oy, Exhibit 2005
`Page 2005 - 10
`IPR2019-00822, Apple Inc. v. MPH Technologies Oy
`
`