INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-calhoun-mobileip-gre-ext-01.txt Gopal Dommety
Date: September 2001 Cisco Systems
Tom Hiller
Lucent Technologies
Peter J. McCann
Lucent Technologies
Yingchun Xu
3Com Corporation
GRE Extensions
Status of this Memo
This document is an individual contribution for consideration by the
Mobile IP Working Group of the Internet Engineering Task Force.
Comments should be submitted to the mobile-
ip@standards.nortelnetworks.com mailing list.
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.
Copyright (C) The Internet Society 2000. All Rights Reserved.
Calhoun et al. expires February 2002 [Page 1]
INTERNET DRAFT September 2001
Abstract
The GRE specification contains a Key field, which MAY contain a value
that is used to identify a particular GRE "flow". This specification
defines a new Mobile IP extensions that is used to exchange the value
to be used in the GRE Key field.
This specification also introduces a new extension, called the GRE
Type extension, which is used during registration to signal the GRE
type that will be used for the Mobile Node's session. This extension
is deemed important in order to allow the Mobility Agents to setup
the necessary protocol interfaces prior to receiving the mobile's
traffic.
Table of Contents
1.0 Introduction
1.1 Requirements language
1.2 Fast handoffs
2.0 GRE Key extension
3.0 GRE Type extension
4.0 Error Values
5.0 GRE Encapsulation
6.0 IANA Considerations
7.0 Security Considerations
8.0 References
9.0 Acknowledgements
10.0 Authors' Addresses
11.0 Full Copyright Statement
Calhoun et al. expires February 2002 [Page 2]
INTERNET DRAFT September 2001
1.0 Introduction
The GRE specification contains a Key field, which MAY contain a value
that is used to identify a particular GRE "flow". This specification
defines a new Mobile IP extensions that is used to exchange the value
to be used in the GRE Key field.
This specification also introduces a new extension, called the GRE
Type extension, which is used during registration to signal the GRE
type that will be used for the Mobile Node's session. This extension
is deemed important in order to allow the Mobility Agents to setup
the necessary protocol interfaces prior to receiving the mobile's
traffic.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [2].
2.0 GRE Key extension
The GRE Key extension MAY be included in Registration Requests [1],
and Regional Registration Requests [3] whose 'G' bit is enabled. The
GRE Key extension is used to inform the recipient of the Mobile IP
request of the value to be used in GRE's Key field.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (non-skippable) [1]
Length
6
Reserved
This field MUST be set to zero (0).
Calhoun et al. expires February 2002 [Page 3]
INTERNET DRAFT September 2001
Key Identifier
This is a four octet value assigned in the Registration or
Regional Registration Request, and inserted in every GRE frame
(see Section 5).
3.0 GRE Type extension
The GRE Type extension MAY be included in Registration Requests [1],
and Regional Registration Requests [3] whose 'G' bit is enabled. The
GRE Type extension is used to signal to the peer the type of traffic
that will be sent from the Mobile Node encapsulated in GRE. Note that
only one GRE Type extension MAY be present in a request.
If the GRE Type is not supported by the receiver of the Registration
or Regional Registration Request, it MUST return the appropriate
Reply with the Code field set to PROTO_NOT_SUPPORTED (see Section 4).
If the GRE Type extension was present in the Request, all traffic for
the Mobile Node MUST be of the type specified in this extension.
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 | GRE Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD (skippable) [1]
Length
6
GRE Type
The GRE protocol type, as defined in [4].
4.0 Error Values
The following table contains the name of Code [1] to be returned in a
Registration and Regional Registration Replies, the value for the
Code, and the section in which the error is first mentioned in this
specification.
Calhoun et al. expires February 2002 [Page 4]
INTERNET DRAFT September 2001
Error Name Value Section of Document
---------------------- ----- -------------------
PROTO_NOT_SUPPORTED TBD 3.0
5.0 GRE Encapsulation
When the Registration or Regional Registration Request has the 'G'
bit enabled, contains the GRE Key extension, all GRE [4] encapsulated
packets for the Mobile Node MUST include the value found in the
extension within the GRE Key field [5]. The receiver of the GRE frame
will use the Key field to identify the particular Mobility Binding.
6.0 IANA Considerations
The GRE Key extension defined in Section 2 and the GRE Type extension
are Mobile IP registration extension as defined in RFC 2002 [1] and
extended in RFC 2356 [6]. IANA should assign a value of 131 for this
purpose.
The Code values defined in Section 4 are error codes as defined in
RFC 2002 [1] and extended in RFC 2344 [7] and RFC 2356 [6].
7.0 Security Considerations
This specification does not introduce any new security
considerations, beyond those described in [1].
8.0 References
[1] C. Perkins, Editor. "IP Mobility Support". RFC 2002. October 1996.
[2] S. Bradner. "Key words for use in RFCs to Indicate Requirement Lev-
els". BCP 14. RFC 2119. March 1997.
[3] E. Gustafsson, A. Jonsson, C. Perkins. "Mobile IP Regional Regis-
tration", draft-ietf-mobileip-reg-tunnel-02.txt (work in progress),
March 2000.
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D. and Traina, P.,
"Generic Routing Encapsulation (GRE)," RFC 2784, March 2000.
[5] Gopal Dommety. "Key and Sequence Number Extensions to GRE". draft-
dommety-gre-ext-04.txt, June 2000. (work in progress)
Calhoun et al. expires February 2002 [Page 5]
INTERNET DRAFT September 2001
[6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
Mobile IP", RFC 2356, June 1998.
[7] G. Montenegro. Reverse Tunneling for Mobile IP. Request for Com-
ments (Proposed Standard) 2344, Internet Engineering Task Force,
May 1998.
9.0 Acknowledgements
The authors would like to thank the authors of draft-ietf-
mobileip-3Gwireless-ext-04.txt, given that some text from that Inter-
net Draft was copied into this specification.
10.0 Authors' Addresses
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
E-mail: pcalhoun@eng.sun.com
Gopal Dommety
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408 525 1404
E-mail: gdommety@cisco.com
Calhoun et al. expires February 2002 [Page 6]
INTERNET DRAFT September 2001
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 979 7673
Fax: +1 630 979 7673
E-Mail: tom.hiller@lucent.com
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 713 9359
Fax: +1 630 713 4982
E-Mail: mccap@lucent.com
Yingchun Xu
3Com Corporation
1800 West Central Road
Mount Prospect,
USA 60056
Phone: +1 847 342 6814
E-mail: Yingchun_Xu@3com.com
11.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). 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 docu-
ment 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 develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
Calhoun et al. expires February 2002 [Page 7]
INTERNET DRAFT September 2001
required to translate it into languages other than English. The lim-
ited 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 DIS-
CLAIMS 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."
Calhoun et al. expires February 2002 [Page 8]