RFC 6245

Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4

📅 published May 2011, from ietf

RFC 6245: Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 🎀

Okay bestie, first the title block 💅 This is RFC 6245, published in May 2011 as a Standards Track document (ISSN 2070-1721). The authors are P. Yegani (Juniper Networks), K. Leung (Cisco Systems), A. Lior (Bridgewater Systems), K. Chowdhury (Cisco Systems), and J. Navali (Cisco Systems). The header doesn't list anything it obsoletes or updates, so there's no drama there ✨

Abstract ✨

The GRE spec has a Key field, and it MAY hold a value that identifies one particular GRE data stream 🔑 This spec adds a new Mobile IP extension for passing that key value around. It also lets the Mobility Agents set up their protocol interfaces before any mobile node traffic arrives 🧚 A Foreign Agent can ask for GRE tunneling without disturbing how the Home Agent works in Mobile IPv4 💖

GRE tunneling with the Key field lets operators run home networks made of multiple Virtual Private Networks (VPNs), which can have overlapping home addresses 🦋 When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across several subscriber sessions, GRE tunneling gives the Foreign Agent and Home Agent a way to tell each session's data streams apart using the GRE key. Without that key identifier, the streams can't be told apart from each other. That's a big drawback when you're 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). More info on Internet Standards is in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6245.

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, since 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 doc specifies a new extension for a Foreign Agent (FA) that's running Mobile IP for IPv4 💅 The extension lets a Foreign Agent ask for Generic Routing Encapsulation (GRE) [RFC2784] tunneling without messing with how the Home Agent (HA) behaves under Mobile IPv4 [RFC5944]. It carries the GRE key [RFC2890] that's needed to set up a GRE tunnel between the FA and the HA.

GRE tunneling with the Key field lets operators run home networks made of multiple Virtual Private Networks (VPNs), which can have overlapping home addresses. When the tuple <Care of Address, Home Address, and Home Agent Address> is the same across several subscriber sessions, GRE tunneling gives the FA and the HA a way to identify each session's data streams by the GRE key. Without this key identifier, the data streams can't be distinguished from each other. That's a significant drawback when you're 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]. Any other terminology is used as already defined in [RFC5944].

3. GRE Key Extension 🗝️

The GRE Key Extension follows the extension format specified for Mobile IPv4 [RFC5944], so it fits right in 💖 The Foreign Agent uses this extension option to give the Home Agent the GRE key and any other info it needs to set up 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, which 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 can support GRE encapsulation, it should set the 'G' (GRE encapsulation) bit in the Flags field of the Agent Advertisement message it sends to the Mobile Node (MN) during Mobile IP session establishment.

If the MN doesn't set the 'G' bit, the FA MAY fall back to using IP-in-IP encapsulation for the session per [RFC5944].

If the MN doesn't set the 'G' bit and doesn't set the 'D' (Decapsulation by mobile node) bit (meaning the mobile node isn't requesting GRE tunneling and isn't using a co-located care-of address), and local policy lets the FA override the 'G' bit setting received from the MN, then the FA MUST include the GRE Key Extension defined in this memo in the Registration Request (RRQ) it passes on to the HA. The presence of this extension is a request for GRE encapsulation, and it 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's protected by the Mobile-Home Authentication extension 🔒

If the FA doesn't 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 says to use GRE encapsulation for the session, and the 'D' bit isn't set (meaning the mobile node isn't 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. How GRE keys get assigned 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] when processing this extension in Registration Request messages.

If the HA receives the GRE Key Extension in a Registration Request and doesn't 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 the mobile node requests them per [RFC5944] 🙈

If the HA receives the GRE Key Extension in a Registration Request and recognizes it, but isn't 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. In other words, 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 and also supports GRE encapsulation, the following procedures should apply:

  • The HA SHOULD accept the RRQ and send an RRP with code registration 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 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 it 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:

  • 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.
  • 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 can support 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 🎀

okay so GRE tunneling support for Mobile IP is giving asymmetric GRE keying 💅. The FA assigns a GRE key for the encapsulated traffic, and the HA can assign its own GRE key too. Once the keys have been swapped, 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 shown below. 🦋

The GRE Key Extension MAY be included in Registration Requests or Registration Replies [RFC5944]. Its whole job is to tell the recipient of the Mobile IP request what value to put 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 📸

Here's what each field does, bestie:

  • Type: 48, an 8-bit identifier for the GRE Key Extension type. It's non-skippable 🔒
  • Sub-Type: 0 🍓
  • Length: 4 📏
  • Key Identifier: a four-octet value assigned during registration and inserted in every GRE packet of the user traffic. This is the main character here 👑

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 also introduces a new sub-type numbering space, where the value 0 has been assigned from the range 0 to 255. New GRE Key Extension sub-type values get approved through Expert Review with Specification Required 🧚

7. Security Considerations 💀

This specification does not introduce any new security considerations, beyond those described in [RFC5944].

Okay, real talk, bestie 😭 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. It's used 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. So no, nobody's guarding a secret here 🙈

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

📦 where this page comes from