Key and Sequence Number Extensions to GRE
RFC 2890

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Network Working Group                                          G. Dommety
Request for Comments: 2890                                  Cisco Systems
Category: Standards Track                                  September 2000

               Key and Sequence Number Extensions to 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

   GRE (Generic Routing Encapsulation) specifies a protocol for
   encapsulation of an arbitrary protocol over another arbitrary network
   layer protocol. This document describes extensions by which two
   fields, Key and Sequence Number, can be optionally carried in the GRE
   Header [1].

1. Introduction

   The current specification of Generic Routing Encapsulation [1]
   specifies a protocol for encapsulation of an arbitrary protocol over
   another arbitrary network layer protocol. This document describes
   enhancements by which two fields, Key and Sequence Number, can be
   optionally carried in the GRE Header [1]. The Key field is intended
   to be used for identifying an individual traffic flow within a
   tunnel. The Sequence Number field is used to maintain sequence of
   packets within the GRE Tunnel.

1.1. Specification Language

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [3].

   In addition, the following words are used to signify the requirements
   of the specification.

Dommety                     Standards Track                     [Page 1]
RFC 2890       Key and Sequence Number Extensions to GRE  September 2000

   Silently discard
                The implementation discards the datagram without further
                processing, and without indicating an error to the
                sender.  The implementation SHOULD provide the
                capability of logging the error, including the contents
                of the discarded datagram, and SHOULD record the event
                in a statistics counter.

2. Extensions to GRE Header

   The GRE packet header[1] has the following format:

     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)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The proposed GRE header will have the following format:

    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| |K|S| Reserved0       | Ver |         Protocol Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Checksum (optional)      |       Reserved1 (Optional)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Key (optional)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Sequence Number (Optional)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Key Present (bit 2)

     If the Key Present bit is set to 1, then it indicates that the
     Key field is present in the GRE header.  Otherwise, the Key
     field is not present in the GRE header.

     Sequence Number Present (bit 3)

     If the Sequence Number Present bit is set to 1, then it
     indicates that the Sequence Number field is present.
     Otherwise, the Sequence Number field is not present in the GRE
     header.

     The Key and the Sequence Present bits are chosen to be
     compatible with RFC 1701 [2].

Dommety                     Standards Track                     [Page 2]
RFC 2890       Key and Sequence Number Extensions to GRE  September 2000

2.1. Key Field (4 octets)

   The Key field contains a four octet number which was inserted by the
   encapsulator. The actual method by which this Key is obtained is
   beyond the scope of the document. The Key field is intended to be
   used for identifying an individual traffic flow within a tunnel. For
   example, packets may need to be routed based on context information
   not present in the encapsulated data.  The Key field provides this
   context and defines a logical traffic flow between encapsulator and
   decapsulator.  Packets belonging to a traffic flow are encapsulated