Junhyuk Song
INTERNET DRAFT Samsung Electronics
November 2003 Dongkie lee
SK Telecom
Kuntal Chowdhury
Nortel Networks
GRE TLV Extension
draft-song-gre-tlv-extension-00.txt
Status of This Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
GRE (Generic Routing Encapsulation) specifies a protocol for
encapsulation of an arbitrary protocol over another arbitrary network
layer protocol. This document describes GRE TLV Extensions header
that support three fields, Type, Length and value, can be
optionally carried in the GRE Header [1]. This GRE extensions may be
facilitate equipment vendors and organizations to make specific
use of these extensions.
Song, et al. Expires May 2004 [Page 1]
Internet Draft November 2003
1. Introduction
The current specification of Generic Routing Encapsulation [1] and
enhanced GRE extension that specifies Key and Sequence numbers [2]
does not allow for organizations and vendors to expand the usage
of GRE or include organization/vendor-specific information.
With the imminent wide scale deployment of GRE it is desirable to
have TLV extension that support vendor or organization-Specific
Extensions to support this capability.
This document describes GRE TLV Extensions header that support
three fields, Type, Length and Value, can be optionally
carried in the GRE Header [1]. The GRE extensions may be
facilitate equipment vendors and organizations to make specific
use of these extensions.
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.
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.
Song, et al. Expires May 2004 [Page 2]
Internet Draft November 2003
2. Extended 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| Reserved0 |T| | Ver | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (Optional) | Length (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Present (bit 8)
If the T present bit is set to 1, then it indicates that Length
and Attributes fields present in the GRE header. Otherwise,
the Length and attributes are not present in the GRE header.
Version Number (bits 13-15)
The Version Number field MUST contain the value ?.
Length (2 Octets)
The Length field is two octet, and indicates the length of the
packet including the flags, version, Protocol Type, Checksum,
Length and attributes fields. If the GRE packet is received with
an invalid length, the packet MUST be silently discarded.
This field is present if the the Checksum Present or Type Present
bit is set to 1, and contains valid information only if the Type
Present bit is set to 1.
Attributes
The Attribute field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the Type and Length fields of the contained
attributes.
Song, et al. Expires May 2004 [Page 3]
Internet Draft November 2003
3. Attributes
A summary of the Attribute format is shown below. The fields are
transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
The Type field is one octet, and identifies the type of GRE
extension. Values 192-223 are reserved for experimental use,
values 224-240 are reserved for implementation-specific use,
and value 241-255 are reserved for and should not be used.
This specification concerns the following values:
26 Vendor Specific
Length
The Length field is one octet, and indicates the length of this
Attribute including the Type, Length and Value fields.
Value
The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the Type and Length fields.
3.1 Vendor-Specific
Description
This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not
affect the operation of the GRE protocol.
A summary of the Vendor-Specific Attribute format is shown below.
The fields are transmitted from left to right.
Song, et al. Expires May 2004 [Page 4]
Internet Draft November 2003
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
26 for Vendor-Specific.
Length
>= 7
Vendor-Id
The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the "Assigned Numbers" RFC [4].
Value
The Value field is zero or more octets and contains information
specific to the Attribute. The format and length of the Value
field is determined by the Type, Length, and Vendor-ID fields.
4. RFC 1701 and RFC 2784 Compliant Implementations consideration
In RFC 1701 and RFC 2784, the field (bit 8) described here as
'T' bits contained 0 and reserved for future use. As a result,
existing implementations of RFC 1701 and RFC 2784 shall ignore T bit
on receipt, and shall not support new TLV attribute fields.
An RFC 1701 compliant 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. A packet with non-zero bits in any
of bits 1-5 MUST be discarded unless the receiver implements RFC 1701.
Song, et al. Expires May 2004 [Page 5]
Internet Draft November 2003
5. IANA Considerations
This section considers the assignment of additional GRE Version
Numbers and Protocol Types.
7. Acknowledgments
This document is derived from the original ideas of the authors of
RFC 1701, RFC 2784 and RFC 2890
8. References
[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 Routing
Encapsulation", RFC 1701, October 1994.
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
Author's Address
JUNHYUK SONG
SAMSUNG ELECTRONICS.
+82-31-279-3639
junhyuk@telecom.samsung.co.kr
DONNIE DONGKIE LEE
SK TELECOM
+82-11-758-4359
galahad@sktelecom.com
Kuntal ChowdhuryPhone
Nortel Networks
+1(972) 685-7788
chowdhury@nortelnetworks.com
Song, et al. Expires May 2004 [Page 6]
Internet Draft November 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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.
Song, et al. Expires May 2004 [Page 7]