As per Relevance of the word extensions, we have this rfc below:
Network Working Group G.
Request for Comments: 2890 Cisco
Category: Standards Track September 2000
Key and Sequence Number Extensions to
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
GRE (Generic Routing Encapsulation) specifies a protocol
encapsulation of an arbitrary protocol over another arbitrary
layer protocol. This document describes extensions by which
fields, Key and Sequence Number, can be optionally carried in the
Header [1].
1.
The current specification of Generic Routing Encapsulation [1]
specifies a protocol for encapsulation of an arbitrary protocol
another arbitrary network layer protocol. This document
enhancements by which two fields, Key and Sequence Number, can
optionally carried in the GRE Header [1]. The Key field is
to be used for identifying an individual traffic flow within
tunnel. The Sequence Number field is used to maintain sequence
packets within the GRE Tunnel
1.1. Specification
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [3].
In addition, the following words are used to signify the
of the specification
Dommety Standards Track [Page 1]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Silently
The implementation discards the datagram without
processing, and without indicating an error to
sender. The implementation SHOULD provide
capability of logging the error, including the
of the discarded datagram, and SHOULD record the
in a statistics counter
2. Extensions to GRE
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
Key field is present in the GRE header. Otherwise, the
field is not present in the GRE header
Sequence Number Present (bit 3)
If the Sequence Number Present bit is set to 1, then
indicates that the Sequence Number field is present
Otherwise, the Sequence Number field is not present in the
header
The Key and the Sequence Present bits are chosen to
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
encapsulator. The actual method by which this Key is obtained
beyond the scope of the document. The Key field is intended to
used for identifying an individual traffic flow within a tunnel.
example, packets may need to be routed based on context
not present in the encapsulated data. The Key field provides
context and defines a logical traffic flow between encapsulator
decapsulator. Packets belonging to a traffic flow are
using the same Key value and the decapsulating tunnel
identifies packets belonging to a traffic flow based on the Key
value
2.2. Sequence Number (4 octets
The Sequence Number field is a four byte field and is inserted by
encapsulator when Sequence Number Present Bit is set. The
Number MUST be used by the receiver to establish the order in
packets have been transmitted from the encapsulator to the receiver
The intended use of the Sequence Field is to provide unreliable
in-order delivery. If the Key present bit (bit 2) is set,
sequence number is specific to the traffic flow identified by the
field. Note that packets without the sequence bit set can
interleaved with packets with the sequence bit set
The sequence number value ranges from 0 to (2**32)-1. The
datagram is sent with a sequence number of 0. The sequence number
thus a free running counter represented modulo 2**32. The
maintains the sequence number value of the last
decapsulated packet. Upon establishment of the GRE tunnel, this
should be set to (2**32)-1.
When the decapsulator receives an out-of sequence packet it SHOULD
silently discarded. A packet is considered an out-of-sequence
if the sequence number of the received packet is less than or
to the sequence number of last successfully decapsulated packet.
sequence number of a received message is considered less than
equal to the last successfully received sequence number if its
lies in the range of the last received sequence number and
preceding 2**31-1 values, inclusive
If the received packet is an in-sequence packet, it is
decapsulated. An in-sequence packet is one with a sequence
exactly 1 greater than (modulo 2**32) the last
decapsulated packet, or one in which the sequence number field is
present (S bit not set).
Dommety Standards Track [Page 3]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
If the received packet is neither an in-sequence nor an out-of
sequence packet it indicates a sequence number gap. The receiver
perform a small amount of buffering in an attempt to recover
original sequence of transmitted packets. In this case, the
may be placed in a buffer sorted by sequence number. If an in
sequence packet is received and successfully decapsulated,
receiver should consult the head of this buffer to see if the
in-sequence packet has already been received. If so, the
should decapsulate it as well as the following in-sequence
that may be present in the buffer. The "last
decapsulated sequence number" should then be set to the last
that was decapsulated from the buffer
Under no circumstances should a packet wait more
OUTOFORDER_TIMER milliseconds in the buffer. If a packet has
waiting that long, the receiver MUST immediately traverse the
in sorted order, decapsulating packets (and ignoring any
number gaps) until there are no more packets in the buffer that
been waiting longer than OUTOFORDER_TIMER milliseconds. The "
successfully decapsulated sequence number" should then be set to
last packet so decapsulated
The receiver may place a limit on the number of packets in any per
flow buffer (Packets with the same Key Field value belong to a flow).
If a packet arrives that would cause the receiver to place more
MAX_PERFLOW_BUFFER packets into a given buffer, then the packet
the head of the buffer is immediately decapsulated regardless of
sequence number and the "last successfully decapsulated
number" is set to its sequence number. The newly arrived packet
then be placed in the buffer
Note that the sequence number is used to detect lost packets and/
restore the original sequence of packets (with buffering) that
have been reordered during transport. Use of the sequence
option should be used appropriately; in particular, it is a good
a avoid using when tunneling protocols that have higher layer in
order delivery mechanisms or are tolerant to out-of-order delivery
If only at certain instances the protocol being carried in the
tunnel requires in-sequence delivery, only the corresponding
encapsulated in a GRE header can be sent with the sequence bit set
Reordering of out-of sequence packets MAY be performed by
decapsulator for improved performance and tolerance to reordering
the network. A small amount of reordering
(MAX_PERFLOW_BUFFER) may help in improving performance when
higher layer employs stateful compression or encryption. Since
state of the stateful compression or encryption is reset by
loss, it might help the performance to tolerate some small amount
Dommety Standards Track [Page 4]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
packet reordering in the network by buffering
3. Security
This document describes extensions by which two fields, Key
Sequence Number, can be optionally carried in the GRE (
Routing Encapsulation) Header [1]. When using the Sequence
field, it is possible to inject packets with an arbitrary
number and launch a Denial of Service attack. In order to
against such attacks, IP security protocols [4] MUST be used
protect the GRE header and the tunneled payload. Either
(Encapsulating Security Payload) [5] or AH (Authentication Header)[6]
MUST be used to protect the GRE header. If ESP is used it
the IP payload which includes the GRE header. If AH is used
entire packet other than the mutable fields are authenticated.
that Key field is not involved in any sort or security (despite
name).
4. IANA
This document does not require any allocations by the IANA
therefore does not have any new IANA considerations
5.
This document is derived from the original ideas of the authors
RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer
Yingchun Xu, Ajoy Singh and many others provided useful discussion
The author would like to thank all the above people
Dommety Standards Track [Page 5]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
6.
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic
Encapsulation", RFC 1701, October 1994.
[3] Bradner S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[4] Kent, S. and R. Atkinson, "Security Architecture for the
Protocol", RFC 2401, November 1998.
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security
(ESP)", RFC 2406, November 1998.
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402,
November 1998.
Author's
Gopal
Cisco Systems, Inc
170 West Tasman
San Jose, CA 95134
EMail: gdommety@cisco.
Dommety Standards Track [Page 6]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Dommety Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
