Browse Prior Art Database

Generic Routing Encapsulation (GRE) (RFC2784)

IP.com Disclosure Number: IPCOM000003383D
Original Publication Date: 2000-Mar-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 9 page(s) / 11K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Farinacci: AUTHOR [+4]

Related Documents

10.17487/RFC2784: DOI

Abstract

This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

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]

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 payloa...

Processing...
Loading...