One document matched: draft-yegani-gre-key-extension-00.txt
IETF Mobile IP Working Group Parviz Yegani
INTERNET DRAFT Gopal Dommety
Cisco Systems
Avi Lior
Bridgewater Corp.
Kuntal Chowdhury
Jay Navali
Starent Networks
10 July 2005
GRE Key Extension for Mobile IPv4
draft-yegani-gre-key-extension-00.txt
Status of This Memo
This document is a submission by the IETF MIPv4 Working Group Working
Group of the Internet Engineering Task Force (IETF). Comments should be
submitted to the mip4@ietf.org mailing list.
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.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
The GRE specification contains a Key field, which MAY contain a value
that is used to identify a particular GRE data stream. This
specification defines a new Mobile IP extension that is used to
exchange the value to be used in the GRE Key field. This extension
further allows the Mobility Agents to setup the necessary protocol
interfaces prior to receiving the mobile's traffic. The new extension
option allows a foreign agent to request GRE tunneling without
disturbing the Home Agent behavior specified for Mobile Ipv4 [2]. GRE
tunneling provides an advantage that allows operator?s private home
networks to be overlaid and allows the HA to provide overlapping home
addresses to different subscribers. When the tuple <Care of Address,
Yegani Expires xx Dec. 2005 [Page 2]
Internet Draft GRE Tunneling Extension 10 July 2005
Home Address and Home Agent Address> is the same across multiple
subscriber sessions, GRE
tunneling will provide a means for the FA and HA to identify data
streams for the individual sessions based on the GRE key. In the
absence of this key identifier, the data streams cannot be
distinguished from each other, a significant drawback when using IP-in-
IP tunneling.
1. Introduction
This document specifies a new extension for use by Foreign Agents
operating Mobile IP for IPv4. The new extension option allows a
foreign agent to request GRE tunneling without disturbing the Home
Agent behavior specified for Mobile IPv4 [2]. This extension contains
the GRE key and other necessary information required for establishing a
GRE tunnel between the FA and the HA.
GRE tunneling provides an advantage that allows operator?s private home
networks to be overlaid and it allows the HA to provide overlapping
home addresses to different subscribers. When the tuple <Care of
Address, Home Address and Home Agent Address> is the same across
multiple subscriber sessions, GRE tunneling will provide a means for
the FA and the HA to identify data streams for the individual sessions
based on the GRE key. In the absence of this key identifier, the data
streams cannot be distinguished from each other, a significant drawback
when using IP-in-IP tunneling.
2. Terminology
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 [1]. Other
terminology is used as already defined in [2].
3. GRE-Key Extension
The format of the GRE-Key Extension conforms to the Extension format
specified for Mobile IPv4 [RFC3344]. This extension option is used by
the Foreign Agent to supply GRE key and other necessary information to
the Home Agent to establish a GRE tunnel between the FA and the HA.
Yegani Expires xx Dec. 2005 [Page 3]
Internet Draft GRE Key Extension 10 July 2005
4. Operation and Use of the GRE-Key Extension
4.1 Foreign Agent Requirements for GRE Tunneling Support
The FA MUST support IP-in-IP tunneling of datagrams for Mobile
IPv4 [2]. The FA may support GRE tunneling that can be used, for
example, to allow for overlapping private home IP addresses
[X.S0011-D]. If the FA is capable of supporting GRE
encapsulation, it should set the ?G? bit in the Flags field
in the Agent Advertisement message sent to the MN during the
Mobile IP session establishment.
If the MN does not set the ?G? bit, the FA MAY fall back to using
IP-in-IP encapsulation for the session per RFC 3344.
If the MN does not set the ?G? bit, and the local policy allows
the FA to override the ?G? bit setting received from the MS, the
FA MUST include the GRE-Key Extension as defined in this memo in
the Registration Request message to request GRE encapsulation for
the session.
If the FA does not support GRE encapsulation, the FA MUST reset
the ?G? bit in the Agent Advertisement message. In this case, if
the MN sets the ?G? bit in the Registration Request message, the
FA returns a Registration Reply message to the MN with code
'Requested Encapsulation Unavailable? (0x48) per RFC 3344.
If the FA allows GRE encapsulation, and either the MN requested
GRE encapsulation or local policy dictates using GRE
encapsulation for the session, the FA MUST include the GRE Key in
the GRE-KEY Extension in all Mobile IP Registration Requests
(including initial, renewal and de-registration requests) before
forwarding the request to the HA. The GRE key assignment in the
FA and the HA is outside the scope of this memo.
The GRE Key Extension SHALL follow the format defined in RFC
3344. This extension SHALL be added after the MN-HA and MN-FA
Challenge and MN-AAA extensions (if any) and before the FA-HA
Auth extension (if any).
4.2 Home Agent Requirements for GRE Tunneling Support
The HA MUST follow the procedures specified in RFC 3344 in
processing this extension in Registration Request messages. If
the HA receives the GRE Key Extension in a Registration Request
Yegani Expires xx Dec. 2005 [Page 4]
Internet Draft GRE Tunneling Extension 10 July 2005
and does not recognize GRE Key Extension, it MUST send an RRP
with code ?Unknown Extension (0xY1)? per RFC 3344.
If the HA receives the GRE Key Extension in a Registration
Request and recognizes the GRE Key Extension but is not
configured to support GRE encapsulation, it MUST send an RRP with
code ?Requested Encapsulation Unavailable (0xYY)?.
If the HA receives a Registration Request with the 'G' bit set
but without the GRE Key Extension, it SHALL send an RRP with code
?Poorly Formed Request (0xY2)?.
If the HA receives a Registration Request with a GRE Key
Extension but without the ?G? bit set, the HA SHOULD treat this
as if ?G? bit is set in the Registration Request i.e., the
presence of GRE Key Extension indicates a request for GRE
encapsulation.
If the HA receives the GRE Key Extension in a Registration
Request and recognizes the GRE Key Extension as well as supports
GRE encapsulation, it SHOULD accept the RRQ and send a RRP with
code ?Accepted (0)?. The HA MUST assign a GRE key and include the
GRE Key Extension in the RRP before sending it to the FA. The HA
MUST include the GRE Key Extension in all RRPs in response to any
RRQ that included GRE Key Extension, when a GRE key is available
for the registration.
4.3 Mobile Node Requirements for GRE Tunneling Support
If the MN is capable of supporting GRE encapsulation, it SHOULD
set the ?G? bit in the Flags field in the Registration Request
per RFC 3344.
5. GRE Key Extension and Tunneling Procedures
GRE tunneling support for Mobile IP will permit asymmetric GRE
keying i.e., the FA assigns a GRE key for use in encapsulated
traffic and the HA can assign its own GRE key. Once the GRE keys
have been exchanged, the FA uses the HA-assigned key in the
encapsulating GRE header for reverse tunneling and the HA uses
the FA-assigned key in the encapsulating GRE header.
The format of the GRE Key Extension is as shown below.
The GRE Key extension MAY be included in Registration Requests [2],
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) [2]
Length
6
Reserved
This field MUST be set to zero (0).
Key Identifier
This is a four octet value assigned in the Registration and
inserted in every GRE frame.
6.0 IANA Considerations
The GRE Key extension defined in this memo is as defined in RFC 3344
[2]. IANA should assign a value for this Extension.
7. Security Considerations
This specification does not introduce any new security considerations,
beyond those described in [2].
8. Acknowledgements
Thanks to ?
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] C. Perkins. IP Mobility Support. Request for Comments (Proposed
Standard) 3344, Internet Engineering Task Force, August 2002.
[3] X.S0011-D cdma2000 Wireless IP Network Standard
[4] RFC 2890 Dommety, Key and Sequence Number Extensions to GRE,
September, 2000.
All references are normative.
Author Address
Questions about this memo can be directed to the author:
Yegani Expires xx Dec. 2005 [Page 7]
Internet Draft GRE Tunneling Extension 10 July 2005
Parviz Yegani
Cisco Systems, Inc.
(408) 83-5729
pyegani@cisco.com
Gopal Dommety
Cisco Systems, Inc.,
(408) 666-4757
gdommety@cisco.com
Avi Lior
Bridgewater Corp.
(613) 591-6655
lior@bridgewater.com
Kuntal Chowdhury
Starent Networks
(214) 550-1416
kchowdhury@starentnetworks.com
Jay Navali
Starent Networks
(978) 851-1141
jnavali@starentnetworks.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has made
any independent effort to identify any such rights. Information on the
procedures with respect to rights in RFC documents can be found in BCP
78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification
can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Yegani Expires xx Dec. 2005 [Page 6]
Internet Draft GRE Tunneling Extension 10 July 2005
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
| PAFTECH AB 2003-2026 | 2026-04-24 01:17:05 |