GRE key for Mobile IPv4: Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4
A Mobile IPv4 extension that lets a Foreign Agent and Home Agent agree on the GRE key that labels each tunneled data stream.
Yegani, P., Leung, K., Lior, A., Chowdhury, K., and J. Navali, "Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4", RFC 6245, DOI 10.17487/RFC6245, May 2011, <https://www.rfc-editor.org/info/rfc6245>.
@misc{rfc6245,
series = {Request for Comments},
number = 6245,
howpublished = {RFC 6245},
publisher = {RFC Editor},
doi = {10.17487/RFC6245},
url = {https://www.rfc-editor.org/info/rfc6245},
author = {P. Yegani and K. Leung and A. Lior and K. Chowdhury and J. Navali},
title = {{Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4}},
pagetotal = 8,
year = 2011,
month = may,
} RFC text
Contents
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.
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
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.
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:
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.
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].
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>.
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
AI ELI5
On this page
§1Why a GRE Key for Mobile IPv4
RFC 6245 defines a new extension for a Foreign Agent (FA) running Mobile IP for IPv4. The extension lets the FA request Generic Routing Encapsulation (GRE) tunneling without disturbing the Home Agent (HA) behavior specified for Mobile IPv4 in RFC 5944. The extension carries the GRE key from RFC 2890 that is needed to set up a GRE tunnel between the FA and the HA.
The motivation is operator networks whose home networks consist of multiple Virtual Private Networks (VPNs) that may have overlapping home addresses. If the tuple of Care of Address, Home Address and Home Agent Address is the same across several subscriber sessions, the FA and HA can use the GRE key to tell the sessions' data streams apart. With plain IP-in-IP tunneling the streams cannot be distinguished, which the RFC calls a significant drawback.
Many kids share one tunnel and have the same address. A number sticker on each parcel tells the helpers whose parcel is whose.
§2Foreign Agent Behavior
The FA MUST support IP-in-IP tunneling for Mobile IPv4. It may also support GRE tunneling, for example to allow overlapping private home addresses. An FA that can do GRE should set the G bit in the Flags field of the Agent Advertisement it sends to the Mobile Node (MN). An FA that cannot do GRE MUST reset that bit, and if the MN then sets G in its Registration Request, the FA answers with the code 'requested encapsulation unavailable' (72).
If the MN sets neither the G bit nor the D bit (decapsulation by the mobile node, used with a co-located care-of address), and local policy lets the FA override, the FA MUST include the GRE Key Extension in the Registration Request it passes to the HA. The presence of the extension is a request for GRE encapsulation and takes precedence over the G bit. The FA MUST NOT change the G bit itself, because it is protected by the Mobile-Home Authentication extension.
When GRE is used and the D bit is not set, the FA MUST include a GRE key in all Registration Requests: initial, renewal and de-registration. It may send a key of value zero to signal that the HA assigns GRE keys in both directions. How keys are assigned is outside the scope of the memo. The extension goes after any MN-HA and MN-FA Challenge and MN-AAA extensions and before any FA-HA Auth extension.
The foreign helper says whether it can use number stickers. If the traveler did not ask for stickers but the helper wants them, the helper adds a note to the request without touching the traveler's signed paperwork.
§3Home Agent and Mobile Node Behavior
The HA MUST process the extension in Registration Requests following RFC 5944. The extension is non-skippable, so an HA that does not recognize it MUST silently discard the message and use other forms of encapsulation, such as IP-in-IP, when the mobile node asks for them. An HA that recognizes the extension but is not configured for GRE MUST send a Registration Reply (RRP) with code 'requested encapsulation unavailable (139)' from RFC 3024.
If a Registration Request carries the extension but not the G bit, the HA SHOULD behave as though G were set. When the HA supports GRE, it SHOULD accept the request with code 'registration accepted (0)', MUST assign a GRE key and MUST include the extension in the reply, and in every reply to a request that included it, when a key is available.
If the initial request carries a key of zero, the HA SHOULD accept it, MUST assign keys for both directions and MUST return them in the extension. An MN that is capable of GRE encapsulation SHOULD set the G bit in its Registration Request.
The home helper either understands the sticker note and replies with its own sticker number, or it says it cannot do stickers. If it has never heard of stickers, it ignores the request and the old way is used.
§4The GRE Key Extension Format
Once keys are exchanged, GRE keying is allowed to be asymmetric. The FA assigns a key for traffic it will receive and the HA may assign its own. The FA then uses the HA-assigned key in the GRE header for reverse tunneling, and the HA uses the FA-assigned key. The extension MAY appear in Registration Requests or Replies and tells the recipient which value to place in the GRE Key field.
The extension has four fields: an 8-bit Type of 48 (non-skippable), a Sub-Type of 0, a Length of 4, and a four-octet Key Identifier. The key is assigned during registration and inserted in every GRE packet of the user traffic.
The note has a label saying what kind of note it is, a size, and then the sticker number itself. Each side uses the other side's number on parcels it sends.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
TYPE | Type | 1 byte | 48 | Identifies the extension; non-skippable. |
SUB-TYPE | Sub-Type | 1 byte | 0 | Sub-type of the extension. |
LENGTH | Length | 2 bytes | 4 | Length of the extension data. |
KEY-ID | Key Identifier | 4 bytes | Four-octet value assigned during registration and inserted in every GRE packet of the user traffic. |
§5IANA Registrations
IANA assigned Type value 48 for this extension from the non-skippable range (0-127) of Mobile IP extensions. The extension also creates a new sub-type numbering space, in which value 0 is assigned from the range 0 to 255. New sub-type values are approved through Expert Review with Specification Required.
The official list of note types got a new entry, number 48, and a new small list for sub-kinds where only the first slot is used so far.
§6Security Considerations
The specification introduces no new security considerations beyond those in RFC 5944. The RFC adds that, despite its name, the GRE Key Extension has little to do with security. Here the word key is an index or demultiplexing value used to tell packets of one flow from another within a GRE tunnel. It is not a cryptographic shared secret to be protected.
The number sticker is just a label to sort parcels. It is not a secret password.