summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6245.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6245.txt')
-rw-r--r--doc/rfc/rfc6245.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6245.txt b/doc/rfc/rfc6245.txt
new file mode 100644
index 0000000..0914ec5
--- /dev/null
+++ b/doc/rfc/rfc6245.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Yegani
+Request for Comments: 6245 Juniper Networks
+Category: Standards Track K. Leung
+ISSN: 2070-1721 Cisco Systems
+ A. Lior
+ Bridgewater Systems
+ K. Chowdhury
+ J. Navali
+ Cisco Systems
+ May 2011
+
+
+ Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4
+
+Abstract
+
+ The Generic Routing Encapsulation (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 set
+ up the necessary protocol interfaces prior to receiving the mobile
+ node traffic. The new extension allows a Foreign Agent to request
+ GRE tunneling without disturbing the Home Agent behavior specified
+ for Mobile IPv4. GRE tunneling with the Key field allows the
+ operators to have home networks that consist of multiple Virtual
+ Private Networks (VPNs), which may have overlapping home addresses.
+ 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 Foreign Agent and Home Agent
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6245.
+
+
+
+Yegani, et al. Standards Track [Page 1]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Terminology .....................................................3
+ 3. GRE Key Extension ...............................................3
+ 4. Operation and Use of the GRE Key Extension ......................3
+ 4.1. Foreign Agent Requirements for GRE Tunneling Support .......3
+ 4.2. Home Agent Requirements for GRE Tunneling Support ..........4
+ 4.3. Mobile Node Requirements for GRE Tunneling Support .........5
+ 5. GRE Key Extension and Tunneling Procedures ......................5
+ 6. IANA Considerations .............................................6
+ 7. Security Considerations .........................................6
+ 8. Acknowledgements ................................................7
+ 9. Normative References ............................................7
+
+1. Introduction
+
+ This document specifies a new extension for use by a Foreign Agent
+ (FA) operating Mobile IP for IPv4. The new extension allows a
+ Foreign Agent to request Generic Routing Encapsulation (GRE)
+ [RFC2784] tunneling without disturbing the Home Agent (HA) behavior
+ specified for Mobile IPv4 [RFC5944]. This extension contains the GRE
+ key [RFC2890] required for establishing a GRE tunnel between the FA
+ and the HA.
+
+ GRE tunneling with the Key field allows the operators to have home
+ networks that consist of multiple Virtual Private Networks (VPNs),
+ which may have overlapping home addresses. When the tuple <Care of
+ Address, Home Address, and Home Agent Address> is the same across
+
+
+
+
+
+
+
+Yegani, et al. Standards Track [Page 2]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+ 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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119]. Other
+ terminology is used as already defined in [RFC5944].
+
+3. GRE Key Extension
+
+ The format of the GRE Key Extension conforms to the extension format
+ specified for Mobile IPv4 [RFC5944]. 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.
+
+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
+ [RFC5944]. The FA may support GRE tunneling that can be used, for
+ example, to allow for overlapping private home IP addresses
+ (Section 4.2.2.5 of [X.S0011-E]). If the FA is capable of supporting
+ GRE encapsulation, it should set the 'G' (GRE encapsulation) bit in
+ the Flags field in the Agent Advertisement message sent to the Mobile
+ Node (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 [RFC5944].
+
+ If the MN does not set the 'G' bit and does not set the 'D'
+ (Decapsulation by mobile node) bit (i.e., the mobile node does not
+ request GRE tunneling and is not using a co-located care-of address),
+ and the local policy allows the FA to override the 'G' bit setting
+ received from the MN, the FA MUST include the GRE Key Extension as
+ defined in this memo in the Registration Request (RRQ) that it
+ propagates to the HA. The presence of this extension is a request
+ for GRE encapsulation that takes precedence over the setting of the
+ 'G' bit in the Registration Request. The FA MUST NOT modify the 'G'
+ bit in the Registration Request because it is protected by the
+ Mobile-Home Authentication extension.
+
+
+
+
+Yegani, et al. Standards Track [Page 3]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+ 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 (RRP) message to the MN with code 'requested
+ encapsulation unavailable' (72) per [RFC5944].
+
+ If the FA allows GRE encapsulation, and either the MN requested GRE
+ encapsulation or local policy dictates using GRE encapsulation for
+ the session, and the 'D' bit is not set (i.e., the mobile node is not
+ using a co-located care-of address), 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 FA may include a GRE key of
+ value zero in the GRE Key Extension to signal that the HA assigns GRE
+ keys in both directions. 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 [RFC5944].
+ This extension SHALL be added after the MN-HA and MN-FA Challenge and
+ MN-AAA (Mobile Node - Authentication, Authorization, and Accounting)
+ 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 [RFC5944] in
+ processing this extension in Registration Request messages.
+
+ If the HA receives the GRE Key Extension in a Registration Request
+ and does not recognize this non-skippable extension, it MUST silently
+ discard the message. The HA MUST use other alternative forms of
+ encapsulation (e.g., IP-in-IP tunneling), when requested by the
+ mobile node per [RFC5944].
+
+ 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 (139)' [RFC3024].
+
+ 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 the 'G'
+ bit is set in the Registration Request; i.e., the presence of a GRE
+ Key Extension indicates a request for GRE encapsulation.
+
+ If the HA receives the GRE Key Extension in a Registration Request,
+ and it recognizes the GRE Key Extension as well as supports GRE
+ encapsulation, the following procedures should apply:
+
+
+
+
+
+Yegani, et al. Standards Track [Page 4]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+ o The HA SHOULD accept the RRQ and send an RRP with code
+ 'registration accepted (0)'.
+
+ o The HA MUST assign a GRE key and include the GRE Key Extension in
+ the RRP before sending it to the FA.
+
+ o The HA MUST include the GRE Key Extension in all RRPs in response
+ to any RRQ that included the GRE Key Extension, when a GRE key is
+ available for the registration.
+
+ If the HA receives the GRE Key Extension in the initial Registration
+ Request and recognizes the GRE Key Extension carrying a GRE key value
+ of zero, it SHOULD accept the RRQ and send an RRP with code
+ 'registration accepted (0)', and the following procedures apply:
+
+ o The HA MUST assign GRE keys for both directions and include these
+ keys in the GRE Key Extension in the RRP before sending it to
+ the FA.
+
+ o The HA MUST include the GRE Key Extension in the RRP in response
+ to the initial RRQ that included the 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
+ [RFC5944].
+
+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 or
+ Registration Replies [RFC5944]. The GRE Key Extension is used to
+ inform the recipient of the Mobile IP request of the value to be used
+ in the GRE Key field.
+
+
+
+
+
+
+
+Yegani, et al. Standards Track [Page 5]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+ 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 | Sub-Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Key Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: GRE Key Extension
+
+ Type
+
+ 48 - An 8-bit identifier of the GRE Key Extension type
+ (non-skippable)
+
+ Sub-Type
+
+ 0
+
+ Length
+
+ 4
+
+ Key Identifier
+
+ This is a four-octet value assigned during registration and
+ inserted in every GRE packet of the user traffic.
+
+6. IANA Considerations
+
+ The GRE Key Extension defined in this memo is a Mobile IP extension
+ as defined in [RFC5944]. IANA has assigned a Type value (48) for
+ this extension from the non-skippable range (0-127).
+
+ The GRE Key Extension introduces a new sub-type numbering space,
+ where the value 0 has been assigned from the range 0 to 255.
+ Approval of new GRE Key Extension sub-type values is to be made
+ through Expert Review with Specification Required.
+
+7. Security Considerations
+
+ This specification does not introduce any new security
+ considerations, beyond those described in [RFC5944].
+
+
+
+
+
+
+
+
+Yegani, et al. Standards Track [Page 6]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+ Despite its name, the GRE Key Extension has little to do with
+ security. The word "Key" here is not used in the cryptographic sense
+ of a shared secret that must be protected but rather in the sense of
+ an "index" or demultiplexing value that can be used to distinguish
+ packets belonging to a given flow within a GRE tunnel.
+
+8. Acknowledgements
+
+ Thanks to Jun Wang, Gopal Dommety, and Sri Gundavelli for their
+ helpful comments, offline discussions, and review of the initial
+ draft version of this document. Also, Pete McCann and Simon
+ Mizikovsky provided valuable review comments.
+
+9. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+ Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+ March 2000.
+
+ [RFC2890] Dommety, G., "Key and Sequence Number Extensions to
+ GRE", RFC 2890, September 2000.
+
+ [RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP,
+ revised", RFC 3024, January 2001.
+
+ [RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4,
+ Revised", RFC 5944, November 2010.
+
+ [X.S0011-E] 3rd Generation Partnership Project 2, "cdma2000 Wireless
+ IP Network Standard: Simple IP and Mobile IP Access
+ Services", 3GPP2 X.S0011-002-E Version 1.0,
+ November 2009, <http://www.3gpp2.org/Public_html/specs/
+ X.S0011-002-E_v1.0_091116.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yegani, et al. Standards Track [Page 7]
+
+RFC 6245 GRE Key Ext. for MIP4 May 2011
+
+
+Authors' Addresses
+
+ Parviz Yegani
+ Juniper Networks
+ 1194 North Mathilda Ave.
+ Sunnyvale, California 94089
+ USA
+ Phone: +1 408-759-1973
+ EMail: pyegani@juniper.net
+
+
+ Kent Leung
+ Cisco Systems Incorporated
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+ Phone: +1 408 526 5030
+ EMail: kleung@cisco.com
+
+
+ Avi Lior
+ Bridgewater Systems Corporation
+ 303 Terry Fox Drive
+ Ottawa, Ontario K2K 3J1
+ Canada
+ Phone: +1 613-591-6655
+ EMail: avi@bridgewatersystems.com
+
+
+ Kuntal Chowdhury
+ Cisco Systems Incorporated
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+ EMail: kchowdhu@cisco.com
+
+
+ Jay Navali
+ Cisco Systems Incorporated
+ 170 West Tasman Drive
+ San Jose, California 95134
+ USA
+ EMail: jnavali@cisco.com
+
+
+
+
+
+
+
+
+Yegani, et al. Standards Track [Page 8]
+