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]