RFC 5845
Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6
RFC 5845: Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 🎀
okay bestie, this one is RFC 5845, published in June 2010 by the Internet Engineering Task Force (IETF) 🌸. It's on the Standards Track, so it's an official spec and not a vibe doc 💅. The authors are A. Muhanna and M. Khalil from Ericsson, and S. Gundavelli and K. Leung from Cisco 🫶. It's ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it stands on its own ✨.
Abstract 🌈
so this spec adds a brand-new mobility option 🦋. It lets the mobile access gateway and the local mobility anchor agree on using GRE (Generic Routing Encapsulation) encapsulation mode, and swap the downlink and uplink GRE keys. Those keys are how you mark which downlink and uplink traffic belongs to one specific mobility session 🔑. The same option can also just negotiate GRE encapsulation mode without swapping any keys, which is very flexible of it ngl 💜.
Status of This Memo 🍓
this one is an Internet Standards Track document 💖. It comes from the IETF, which means it reflects the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🔥. If you want more about Internet Standards, check Section 2 of RFC 5741. Info about its current status, errata, and feedback is at http://www.rfc-editor.org/info/rfc5845 🧚.
Copyright Notice 💅
the copyright is Copyright (c) 2010 IETF Trust and the authors, with all rights reserved 🎀. The doc is covered by BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date 📜. Read those carefully, because they spell out your rights and restrictions ‼️. Any code pulled out of this document has to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and comes with no warranty, same as that license says 🫶.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . 4
3.1. GRE Encapsulation Overview . . . . . . . . . . . . . . . . 4
3.2. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . 6
3.3. GRE Encapsulation and Key Exchange . . . . . . . . . . . . 6
3.3.1. Initial GRE Key Exchange . . . . . . . . . . . . . . . 6
3.3.2. GRE Key Exchange during Binding Re-Registration . . . 7
4. Mobile Access Gateway Considerations . . . . . . . . . . . . . 8
4.1. Extensions to the Conceptual Data Structure . . . . . . . 8
4.2. Operational Summary . . . . . . . . . . . . . . . . . . . 9
5. Local Mobility Anchor Considerations . . . . . . . . . . . . . 10
5.1. Extensions to the Binding Cache Entry . . . . . . . . . . 10
5.2. Operational Summary . . . . . . . . . . . . . . . . . . . 11
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Proxy Binding Update Message Extension . . . . . . . . . . 13
6.3. Proxy Binding Acknowledgement Message Extension . . . . . 14
6.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 14
7. Data Packets Processing Considerations . . . . . . . . . . . . 15
7.1. Tunneling Format . . . . . . . . . . . . . . . . . . . . . 15
7.2. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . 16
7.3. Mobile Access Gateway Operation . . . . . . . . . . . . . 18
7.3.1. Sending and Receiving Data Packets . . . . . . . . . . 18
7.4. Local Mobility Anchor Operation . . . . . . . . . . . . . 19
7.4.1. Sending and Receiving Data Packets . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 221. Introduction ✨
okay so the Proxy Mobile IPv6 spec [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] let you use IPv6 and IPv4 encapsulation modes from [RFC2473] and [RFC2003] for the tunneled traffic between the local mobility anchor (LMA) and the mobile access gateway (MAG) 🌸. But there are situations where those modes can't uniquely identify where the packets of one mobility session are supposed to go 😭. So we need an encapsulation mode with richer semantics 💅. Enter GRE (Generic Routing Encapsulation) [RFC2784], plus the Key extension from [RFC2890]. Together they have the semantics needed to make that distinction in Proxy Mobile IPv6 🦋.
this spec defines the GRE Key option, which is used to negotiate GRE encapsulation mode and exchange the uplink and downlink GRE keys 🔑. The negotiated downlink and uplink GRE keys can mark the downlink and uplink traffic for a specific mobility session 🎀. It also lets the MAG and LMA negotiate GRE encapsulation mode without exchanging the GRE keys at all 💜.
this has no impact on IPv4 or IPv6 mobile nodes 🙈.
2. Conventions and Terminology 💅
2.1. Conventions 🍓
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC 2119 [RFC2119] 📜.
2.2. Terminology 🧚
all the general mobility terminology and abbreviations mean what they mean in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213], and IPv4 Support for Proxy Mobile IPv6 [RFC5844] specs 🌈. These terms are used in this specification too 👑:
Downlink Traffic
the traffic in the tunnel between the local mobility anchor and the mobile access gateway, heading towards the mobile access gateway and tunneled at the local mobility anchor. This traffic is also called forward direction traffic. 🦋
Uplink Traffic
the traffic in the tunnel between the mobile access gateway and the local mobility anchor, heading towards the local mobility anchor and tunneled at the mobile access gateway. This traffic is also called reverse direction traffic. 🫶
Downlink GRE Key
the GRE key is assigned by the mobile access gateway and used by the local mobility anchor to mark the downlink traffic that belongs to a specific mobility session as described in this specification. 🔑
Uplink GRE Key
the GRE key is assigned by the local mobility anchor and used by the mobile access gateway to mark the uplink traffic that belongs to a specific mobility session as described in this specification. 🔑
A Policy Check
when a local mobility anchor receives an initial, handoff-triggered Binding Lifetime Extension, or Binding Lifetime Extension Proxy Binding Update for a mobility session, the local mobility anchor determines if the GRE encapsulation mode only or GRE encapsulation and GRE keys are required based on a policy check. This policy could be a per-MAG-LMA pair, a per-LMA local policy, a per-MN policy, or the combination of any of them. ⭐
3. GRE Encapsulation and Key Exchange 🎀
this section explains how GRE encapsulation mode gets negotiated and how the GRE keys get dynamically exchanged, using Proxy Mobile IPv6 [RFC5213] signaling 💖✨
3.1. GRE Encapsulation Overview ✨
okay so with the GRE Key option from this spec, the mobile access gateway (MAG) and the local mobility anchor (LMA) can either negotiate GRE encapsulation mode only, or GRE encapsulation mode plus swapping GRE keys to mark downlink and uplink traffic 🎀. If they only agree on encapsulation mode, then no GRE keys get used at all 🌸
BUT once the keys have been exchanged (per this spec), the MAG uses the uplink GRE key that the LMA assigned, and puts it in the GRE header of the uplink payload packet 💅 Same vibe in reverse: the LMA uses the downlink GRE key that was negotiated with the MAG, and puts it in the GRE header of the downlink payload packet 🦋
Here's the picture for the overlapping IPv4 private address [RFC1918] situation, where two operators have the same private address space and everything gets messy 😭
+------------+
| Operator-A |
| |
| 10.x.0.0/16|
+------------+
/
+------+ +------+ /
| | ========================== | | /
MN-1---| | / \ | | / Key-1
| M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic
MN-2---| A |--| |--| M |-
| G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2
MN-3---| | \ / | | \Traffic
| | ========================== | | \
MN-4---| | Proxy Mobile IPv6 Tunnel | | \
+------+ +------+ \
\
Operator-C: Access Network +------------+
| Operator-B |
| |
| 10.x.0.0/16|
+------------+Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping
Figure 1 shows one LMA giving mobility service to mobile nodes from different operators, all handed IPv4 addresses from the same overlapping private space 🌈 In this setup, the MAG and the LMA must be able to tell apart flows that belong to different operators 👑
MN-1 and MN-2 are visiting from Operator-A, and MN-3 and MN-4 are visiting from Operator-B 🧚 The MAG and LMA swap a specific pair of downlink and uplink GRE keys and store them as part of the mobile node's binding, so they know which flows belong to which mobile node 💜
The LMA and the MAG can tell each mobile node's flows apart using the GRE key in the GRE header of the tunneled payload packet, then route them to the right place ✨ Just a heads up though: the GRE keys in this spec only apply to the individual mobility binding that the Proxy Binding Update updated. They do NOT cover every binding the mobile might have registered through the procedures in [RFC5648] 🙈
3.2. GRE Encapsulation Mode Only 🍓
If the MAG wants GRE encapsulation mode only, with no GRE key exchange, the MAG MUST include the GRE Key option but leave out the GRE Key Identifier field in the Proxy Binding Update 💖
If the LMA supports GRE encapsulation and the Proxy Binding Update it receives has the GRE Key option with the GRE Key Identifier field left out, then the MAG is asking for GRE encapsulation without swapping GRE keys dynamically 🫶 If the Proxy Binding Update gets processed successfully, the LMA sends back a successful Proxy Binding Acknowledgement with the GRE Key option, again with the GRE Key Identifier field left out 🌸
When the MAG and LMA successfully agree on GRE encapsulation mode only, no GRE keys are used 🦋
3.3. GRE Encapsulation and Key Exchange 💅
These subsections explain how the MAG and LMA negotiate GRE encapsulation and swap downlink and uplink GRE keys during the Proxy Mobile IPv6 registration procedure ✨
3.3.1. Initial GRE Key Exchange 🎀
So, if the MAG decides GRE encapsulation is needed and GRE keys are required, based on things like private IPv4 address support [RFC1918], its own local policy, or a MAG-LMA peer agreement, then it MUST include the GRE Key option in the initial Proxy Binding Update sent to the LMA 👑 The MAG MUST put the downlink GRE key in the GRE Key Identifier field of that GRE Key option 🔥
Once the LMA successfully processes the initial Proxy Binding Update, and accepts both the GRE encapsulation request and the downlink GRE key after a policy check, the LMA MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field of a successful Proxy Binding Acknowledgement, then send it to the MAG 🦋
3.3.2. GRE Key Exchange during Binding Re-Registration 🌷
If the LMA has successfully negotiated and swapped the initial GRE keys with the MAG for a specific mobile node's mobility session, the LMA MUST keep the same negotiated uplink GRE key for the whole lifetime of that mobility session 💜 BUT, for administrative reasons (like an LMA reboot, for example), the LMA MAY change the uplink GRE key for the mobility session 😭 If it does, some packet loss might happen 🙈
If the MAG has successfully negotiated and swapped the initial GRE keys with the LMA for a specific mobile node's mobility session, the MAG MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update that asks for a Binding Lifetime Extension 🧚 In that case, if the LMA successfully processes the Proxy Binding Update, the LMA MUST return the same uplink GRE key that was exchanged with the MAG in the last successful Proxy Binding Update for that same mobility session, inside the GRE Key option of a successful Proxy Binding Acknowledgement message ✨
Now, during an inter-MAG handoff, if the new MAG decides GRE encapsulation and GRE key exchange are required (based on private IPv4 address support, its local policy, the MAG-LMA peer agreement, or an indication from the handoff process), the new MAG MUST include the GRE Key option with the downlink GRE key in the Proxy Binding Update used to request an after-handoff Binding Lifetime Extension 🌈 The new MAG MAY either pick a brand new downlink GRE key, or reuse the downlink GRE key the previous MAG used for the same binding 🍓 For the new MAG to know which downlink GRE key the previous MAG used, it might need a transfer of context from the previous MAG during the handoff 💀 Those mechanisms are out of scope for this specification 🫶
If the LMA successfully processes a handoff-triggered Binding Lifetime Extension Proxy Binding Update that includes a GRE Key option with a downlink GRE key, the LMA MUST return the same uplink GRE key that was exchanged with the previous MAG for that same mobility session, in the GRE Key option of a successful Proxy Binding Acknowledgement 👑
If the LMA gets a handoff-triggered Binding Lifetime Extension Proxy Binding Update without the GRE Key option, for a Binding Cache entry (BCE) that uses GRE keys and GRE encapsulation, then the LMA runs a policy check on GRE encapsulation and GRE key exchange 🔍 If the policy check says GRE encapsulation and GRE key exchange are required, the LMA MUST reject the Proxy Binding Update by sending a Proxy Binding Acknowledgement with the Status field set to GRE_KEY_OPTION_REQUIRED, as defined in Section 6.4 💅 Otherwise, the LMA SHOULD accept the Proxy Binding Update, and if it gets processed successfully, the LMA MUST return a successful Proxy Binding Acknowledgement without including the GRE Key option 🦋
4. Mobile Access Gateway Considerations 💖
4.1. Extensions to the Conceptual Data Structure ✨
Every MAG keeps a Binding Update List (BUL) entry for each mobile node that's currently attached, as explained in Section 6.1 of the Proxy Mobile IPv6 specification [RFC5213] 🌸 To support this spec, the conceptual Binding Update List entry data structure needs four new fields added to it 🎀
- A flag (GRE-encapsulation-enabled) that indicates whether GRE encapsulation is turned on for the mobile node's traffic 🦋
- The downlink GRE key used in the GRE encapsulation header of the tunneled payload packet going from the LMA to the MAG, destined for the mobile node. The MAG generates this GRE key and tells the LMA about it in the GRE Key option of the Proxy Binding Update message 💜
- The uplink GRE key used in the GRE encapsulation header of the tunneled payload packet going from the MAG to the LMA, originating from the mobile node. This GRE key is taken from the GRE Key Identifier field of the GRE Key option in the received Proxy Binding Acknowledgement message that the LMA sent, as specified in this document 🧚
- A flag that says whether the UDP-based TLV-header format (Section 7.2) is enabled for the mobile node's traffic. This flag is TRUE only when UDP tunneling as in [RFC5844] and GRE encapsulation as in this specification are both enabled for this mobility session 🔥
4.2. Operational Summary 🎀
okay bestie, this is the cheat sheet for the mobile access gateway (MAG) 🧚 Here's what it has to do:
- ✨ If the MAG figures out that GRE encapsulation mode only is what's needed, it MUST include the GRE Key option but leave out the GRE Key Identifier field in the Proxy Binding Update it sends to the local mobility anchor.
- 🔥 If the MAG figures out that GRE encapsulation and GRE keys are needed, it MUST include the GRE Key option with the downlink GRE key in the GRE Key Identifier field of that Proxy Binding Update, sent to the local mobility anchor.
- 💜 After a successful Proxy Binding Acknowledgement that has the GRE Key option but no GRE Key Identifier field, the MAG MUST update the mobile node's Binding Update List entry (the one from Section 4.1) by only setting the GRE-encapsulation-enabled flag.
- 💖 After a successful Proxy Binding Acknowledgement with the GRE Key option and the uplink GRE key in the GRE Key Identifier field, the MAG MUST update the related fields in that BUL entry. It also MUST use the assigned uplink GRE Key to tunnel all the traffic that belongs to this mobile node's BUL entry and that came from the mobile node, before forwarding the tunneled traffic to the local mobility anchor. Main character energy 👑
- 🙈 If the MAG includes the GRE Key option in a Proxy Binding Update for a mobile node, and the local mobility anchor accepts it with a success status code (less than 128) that is not GRE_KEY_OPTION_NOT_REQUIRED, but the reply has no GRE Key option, then the MAG MUST consider that the local mobility anchor doesn't support the GRE Key option, as per this specification. The MAG SHOULD NOT include the GRE Key option in any later Proxy Binding Update sent to that local mobility anchor. Not it 💀
- 🌸 If the MAG sent a Proxy Binding Update without the GRE Key option, but the Proxy Binding Acknowledgement comes back with the status code GRE_KEY_OPTION_REQUIRED (meaning GRE encapsulation and GRE keys are required), the MAG SHOULD resend the Proxy Binding Update with the GRE Key option. If the MAG doesn't support the GRE Key option, it MAY log the event and possibly raise an alarm to flag a possible misconfiguration. 🚨
- 🦋 If the MAG sent a Proxy Binding Update with the GRE Key option and the downlink GRE key included, and got back a successful Proxy Binding Acknowledgement with the status code GRE_KEY_OPTION_NOT_REQUIRED, the MAG MUST consider that GRE encapsulation and GRE keys are not required for this mobility session. It follows the Proxy Mobile IPv6 procedures in [RFC5213] for handling uplink and downlink traffic, and it MUST NOT include the GRE Key option in any later Proxy Binding Update sent to the local mobility anchor for this session. Bye bye GRE 👋
- 🍓 If the MAG has already successfully negotiated GRE encapsulation and swapped GRE keys with the local mobility anchor for a mobility session, it SHOULD NOT include the GRE Key option in the de-registration Proxy Binding Update.
- 🔥 When a packet comes in from the tunnel with a GRE header, the MAG MUST use the GRE key in the GRE extension header as an extra identifier to figure out which mobility session the packet belongs to. The GRE header is removed before anything else happens to it. Sorting it out like a pro 💅
5. Local Mobility Anchor Considerations ✨
5.1. Extensions to the Binding Cache Entry 💜
okay so when the local mobility anchor and the MAG successfully negotiate GRE encapsulation and swap their downlink and uplink GRE keys, the local mobility anchor MUST keep those keys as part of the mobile node's BCE. To make that happen, the BCE from Section 5.1 of the Proxy Mobile IPv6 specification [RFC5213] needs an upgrade. This spec adds four extra fields to it:
- 🎀 A flag that says whether GRE encapsulation is turned on for the mobile node's traffic flows.
- 🌈 The downlink GRE key, which the MAG assigns. It goes in the GRE encapsulation header of the tunneled payload packets going from the local mobility anchor to the MAG.
- 🧚 The uplink GRE key, which the local mobility anchor assigns. It goes in the GRE encapsulation header of the tunneled payload packets going from the MAG to the local mobility anchor.
- 🫶 A flag that says whether the UDP-based TLV-header format (Section 7.2) is enabled for the mobile node's traffic. This flag is TRUE only when UDP tunneling as in [RFC5844] and GRE encapsulation as in this specification are both enabled for the mobility session. Double-enabled, double-cute 🍓
5.2. Operational Summary 🦋
- ✨ If the local mobility anchor successfully processes a Proxy Binding Update with the GRE Key option, but the GRE Key Identifier field is left out for the initial GRE key exchange, the local mobility anchor MUST include the GRE Key option but omit the GRE Key Identifier field in its successful Proxy Binding Acknowledgement.
- 💖 If the local mobility anchor successfully processes a Proxy Binding Update with the GRE Key option and the downlink GRE key in the GRE Key Identifier field for the initial GRE key exchange (see Section 3.3.1), the local mobility anchor MUST include the GRE Key option with the uplink GRE key in the GRE Key Identifier field of its successful Proxy Binding Acknowledgement.
- 🔥 If GRE tunneling is negotiated and the downlink and uplink GRE keys have been swapped between the MAG and the local mobility anchor for a mobility session, the local mobility anchor MUST use the negotiated downlink GRE key in the GRE header of every packet headed to that mobile node over the GRE tunnel to the MAG.
- 🙅♀️ If the Proxy Binding Update doesn't contain the GRE Key option, and the local mobility anchor's policy check decides that GRE encapsulation and GRE keys are required (for example, overlapping IPv4 private addressing is in use, a local mobility anchor local policy says so, or there's an LMA-MAG peer agreement), the local mobility anchor MUST reject the request. It MUST send a Proxy Binding Acknowledgement to the MAG with the status code GRE_KEY_OPTION_REQUIRED, as defined in Section 6.4, to signal that GRE encapsulation and GRE keys are required.
- 🌸 If the local mobility anchor successfully processes a Proxy Binding Update with the GRE Key option, and a policy check says GRE encapsulation and GRE keys are not required for this binding (for example, private IPv4 addressing isn't in use), the local mobility anchor SHOULD send a successful Proxy Binding Acknowledgement to the MAG with the status code GRE_KEY_OPTION_NOT_REQUIRED. In that case, the local mobility anchor MUST NOT include the GRE Key option in the Proxy Binding Acknowledgement.
- 🧸 If the local mobility anchor successfully processes a de-registration Proxy Binding Update, it follows the same de-registration process as in the Proxy Mobile IPv6 specification [RFC5213]. That cleans up the Binding Cache entry and every resource tied to it, including the downlink and uplink GRE keys. Clean slate vibes 🧹
- 🌈 When a packet comes in from the tunnel with a GRE header, the local mobility anchor MUST use the GRE key in the GRE extension header as an extra identifier to figure out which mobility session the packet belongs to. The GRE header is removed before further processing takes place. 💅
6. Message Formats 🧚
6.1. GRE Key Option 🌸
okay, this part is the actual new mobility option! This section extends the Mobile IPv6 protocol messages from [RFC3775] to support GRE tunneling and GRE key exchange for Proxy Mobile IPv6. The GRE Key option is a brand new mobility option used in the Proxy Binding Update and Proxy Binding Acknowledgement messages that get swapped between the MAG and the local mobility anchor. It can be used to negotiate GRE encapsulation mode only, or GRE encapsulation plus swapping the downlink and uplink GRE keys. Those keys then show up in every GRE encapsulated payload packet to mark that specific mobile node's data traffic. Little label, big job 🏷️
The alignment requirement for this option is 4n.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GRE Key OptionHere's the breakdown of each field 👀
- Type:
33 - Length: An 8-bit unsigned integer telling you how many octets the option is, not counting the Type and Length fields. If Length is set to 2, the GRE Key Identifier field isn't carried in the option. If Length is set to 6, then either the downlink or the uplink GRE key is carried.
- Reserved: These fields are unused. The sender MUST initialize them to zero, and the receiver MUST ignore them. Nothing to see here, babe 🙈
- GRE Key Identifier: A 32-bit field holding the downlink or the uplink GRE key. This field only shows up in the GRE Key option when the GRE keys are being exchanged through the Proxy Binding Update and Proxy Binding Acknowledgement messages. The key moment 🔑
6.2. Proxy Binding Update Message Extension ✨
Okay so this spec gives the Proxy Binding Update message from [RFC5213] a glow-up with a brand new TLV-header format (T) flag 💖. Here's where the new (T) flag lives in the message, shown in Figure 3 🎀:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Proxy Binding Update Message
TLV-header format (T) 🦋
When set, this flag means the mobile access gateway is asking to use the TLV header for encapsulating IPv6 or IPv4 packets in IPv4. The TLV-header format is described in Section 7.2. None of the other fields or flags in the Proxy Binding Update are modified by this specification, so they stay exactly as they are 💅.
6.3. Proxy Binding Acknowledgement Message Extension 💜
Same energy here! This spec also extends the Proxy Binding Acknowledgement message from [RFC5213] with that same new TLV-header format (T) flag 🫶. The new (T) flag shows up in the message as shown in Figure 4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Proxy Binding Acknowledgement Message
TLV-header format (T) 🌸
When set, this flag tells us that the sender of the Proxy Binding Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4 using the TLV-header format. None of the other fields or flags in the Proxy Binding Acknowledgement are modified by this specification 🔥.
6.4. Status Codes 🍓
Okay, now the status codes! These values are defined for use in the Binding Acknowledgement message when using Proxy Mobile IPv6 💅.
GRE_KEY_OPTION_NOT_REQUIRED (2) 🌈
When the local mobility anchor gets a Proxy Binding Update with the GRE Key option, and a policy check says GRE encapsulation isn't needed for this specific mobility session, it uses this code to tell the mobile access gateway that the Proxy Binding Update was processed successfully, but GRE encapsulation and GRE keys are not required. Bestie, that's a glow-up with zero drama 🧚.
GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3) 🙈
If the local mobility anchor receives a Proxy Binding Update with the GRE Key option and the TLV-header format (T) flag set, the local mobility anchor uses this code to say that GRE encapsulation has been successfully negotiated, but the TLV-header format is NOT supported 💀.
GRE_KEY_OPTION_REQUIRED (163) 👑
When the local mobility anchor receives a Proxy Binding Update without the GRE Key option, and a policy check shows GRE encapsulation is required for this specific mobility session, it uses this code to reject the Proxy Binding Update. It also tells the mobile access gateway that GRE encapsulation and GRE keys are required. Not me being the bouncer at the door 😭.
7. Data Packets Processing Considerations 🧚
This section is the tea on how the local mobility anchor and mobile access gateway encapsulate and decapsulate data packets when GRE encapsulation and GRE keys are used to tunnel the mobile node's data traffic between these two mobile nodes 🦋.
7.1. Tunneling Format 🎀
When GRE encapsulation is used, the mobile access gateway is allowed to pick from various tunneling formats, depending on where the mobile access gateway is located and what the network can do between the mobile access gateway and the local mobility anchor. Using GRE encapsulation, as described in [RFC2784] and [RFC2890], the mobile access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or in IPv4, following the rules in [RFC5213] and [RFC5844] ✨.
If UDP-based tunneling is used together with GRE encapsulation between the mobile access gateway and the local mobility anchor, the TLV-header UDP tunneling format shown in Figure 5 MUST be used 🫶.
[IPv4 Header]
[UDP Header]
[TLV Header]
[GRE Header]
[Payload - IPv6 or IPv4 Header]
Upper Layer protocolsFigure 5: TLV-Header UDP-Based Encapsulation Header Order
When a UDP-based tunneling format is used between the mobile access gateway and the local mobility anchor, the TLV header is negotiated during the Proxy Binding Update/Acknowledgement exchange, as described in Sections 7.3 and 7.4. If the TLV-header format is agreed upon between the mobile access gateway and the local mobility anchor, the local mobility anchor expects the TLV header to follow the UDP header, as shown in Figure 5 💖.
The TLV header contains the Type field, the following payload packet header type, and its length. The Type field in the TLV header is always set to a value of 0. This makes processing faster because the receiver can tell whether what comes after the UDP header is a TLV-header Type field or an IP version field of an IP header 👑. So the TLV header can carry traffic other than IP, as indicated in the Next Header field. This distinction between IP and TLV encapsulation is needed, because the Proxy Binding Update (IP packet) and the data packets (GRE packets) can be sent over the same UDP tunnel 🌸.
When processing a UDP packet with the TLV-header format, if the receiving node finds that the payload packet length calculated from the UDP header length field is different from its length calculated from the TLV-header length field, the receiving node MUST discard the received IP packet 💀.
7.2. TLV-Header Tunneling Negotiation 💜
The mobile access gateway negotiates the format for tunneling payload traffic during the Proxy Mobile IPv6 registration procedure. If the mobile access gateway is required to use the TLV-header UDP encapsulation format, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update message sent to the local mobility anchor. If the local mobility anchor supports the TLV-header UDP tunneling format, the local mobility anchor SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement 🍓.
Otherwise, the TLV-header format (T) flag is cleared. Setting the TLV-header format (T) flag in the Proxy Binding Acknowledgement tells the mobile access gateway that it MUST use the TLV-header UDP encapsulation format for all packets tunneled to the local mobility anchor, for the entire duration the mobile node is attached to the mobile access gateway 🔥. The TLV-header UDP tunneling format SHOULD NOT change during a Binding Lifetime Extension Proxy Binding Update (re-registration) from the same mobile access gateway 🙈.
Any Proxy Binding Update message triggered by a handoff (Section 5.3.4 of [RFC5213]) may renegotiate the tunneling format. So, to avoid interoperability issues, the local mobility anchor MUST NOT set the TLV-header format (T) flag unless it was set in the Proxy Binding Update received from the mobile access gateway 🧚.
The TLV-header format is shown below in Figure 6 🦋:
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 | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: TLV-Header Format
Type 🎀
This field is always 0 (zero), and it tells the TLV header apart from the IPv4 and IPv6 headers.
Res. 💅
These fields are Reserved and unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Next Header 💖
An 8-bit unsigned integer that indicates the protocol number of the payload header following this TLV header. It is set to the protocol number as assigned by IANA in the "Assigned Internet Protocol Numbers" registry. For example, if an IPv6 header follows, it should be '41'; if a GRE header follows, it should be '47' ✨.
Length 🌈
A 16-bit unsigned integer indicating the length in octets of the payload following this header, excluding the TLV header itself 🫶.
7.3. Mobile Access Gateway Operation 👑
When sending a Proxy Binding Update message over an IPv4 transport network, the mobile access gateway follows the procedures specified in [RFC5844] for using IPv4-UDP encapsulation mode. However, when using a GRE header in conjunction with IPv4-UDP encapsulation mode is required, the mobile access gateway MUST set the TLV-header format (T) flag in the Proxy Binding Update and follow this specification for GRE encapsulation negotiation. If the received Proxy Binding Acknowledgement is successful, the TLV-header format (T) flag is set, and the GRE Key option is included, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the UDP-based TLV-header format (T) flag. In this case, the mobile access gateway MUST use the TLV-header UDP-based encapsulation format shown in Figure 5 ✨.
If the mobile access gateway receives a Proxy Binding Acknowledgement with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in response to a Proxy Binding Update with the GRE Key option and the (T) flag set, the mobile access gateway MUST use GRE encapsulation without UDP encapsulation 🙈. If the mobile access gateway is allowed to use GRE encapsulation without UDP tunneling, the mobile access gateway MUST update the mobile node's Binding Update List entry described in Section 4.1 by setting the GRE-encapsulation-enabled flag and the uplink and downlink GRE key fields. In this case, the mobile access gateway MUST set the UDP-based TLV-header format (T) flag to FALSE. A Proxy Binding Acknowledgement message with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T) flag cleared 💜. Alternatively, the mobile access gateway may resend the Proxy Binding Update to negotiate different tunneling options, e.g., using UDP-based tunneling without GRE encapsulation if possible, or de-register the mobile node mobility session 🦋.
7.3.1. Sending and Receiving Data Packets
okay so when the mobile access gateway is hanging out in an IPv6-enabled or IPv4-enabled network, it might need GRE encapsulation to tunnel IPv6 or IPv4 data packets to the local mobility anchor 🌸 if it successfully negotiated GRE encapsulation mode only, or GRE encapsulation plus GRE keys (as described in this spec), it encapsulates and decapsulates IPv6-or-IPv4 payload packets following the rules in [RFC5213] and [RFC5844], and makes sure the GRE header is there like this ✨
[IPv6 or IPv4 Header]
[GRE Header]
[Payload - IPv6 or IPv4 Header]
Upper Layer protocols
Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulationbut if the mobile access gateway is in an IPv4-only network where NAT has been detected on the path to the local mobility anchor, and it successfully negotiated GRE encapsulation and the TLV-header format, then it MUST use UDP TLV-header tunneling format when sending an IPv6-or-IPv4 payload packet to the local mobility anchor, following the format in Figure 5 🦋 the source and destination of the IPv4 outer header are the mobile node's IPv4 Proxy Care-of Address (IPv4-Proxy-CoA) and the IPv4 local mobility anchor address (IPv4-LMAA), respectively. the source and destination IP addresses of the IPv6-or-IPv4 payload data packet are the mobile node's IPv6-or-IPv4 home address (IPv6/IPv4-MN-HoA) and the IPv6-or-IPv4 corresponding node's address (IPv6/IPv4-CN-Addr), respectively 💖
7.4. Local Mobility Anchor Operation
so when the local mobility anchor gets a Proxy Binding Update that's encapsulated in UDP and has the IPv4 Home Address Request option ([RFC5844]), it has to follow all the steps in [RFC5213] and [RFC5844] 🙌 on top of that, if the TLV-header format (T) flag is set in the Proxy Binding Update, the local mobility anchor needs to figure out whether it can accept the TLV-header UDP-based encapsulation format. if it can, it SHOULD set the TLV-header format (T) flag in the Proxy Binding Acknowledgement. otherwise, the local mobility anchor MUST NOT set the TLV-header format (T) flag in the Proxy Binding Acknowledgement 💅
if the local mobility anchor (LMA) gets a Proxy Binding Update with the GRE Key option and the TLV-header format (T) flag set, and a policy check says GRE encapsulation is required, and the LMA supports TLV-header tunneling, and the LMA sent a successful Proxy Binding Acknowledgement with the TLV-header format (T) flag set, then the LMA MUST update the mobile node's Binding Cache entry described in Section 5.1 by setting the GRE-encapsulation-enabled flag and updating the uplink and downlink GRE key fields 🔥 on top of that, the LMA MUST set the UDP-based TLV-header format flag.
if the LMA gets a Proxy Binding Update with the GRE Key option and the TLV-header format (T) flag set, and a policy check says GRE encapsulation is required, but the LMA does not support TLV-header tunneling, and the Proxy Binding Update was successfully processed, then the LMA MUST send a successful Proxy Binding Acknowledgement with the status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED 🌈 this way, the LMA tells the mobile access gateway that GRE encapsulation was successfully negotiated, but the TLV-header UDP-based tunneling format is not supported. in this case, the LMA MUST update the mobile node's BCE described in Section 5.1 by setting the GRE encapsulation enabled flag and updating the uplink and downlink GRE key fields, and the LMA MUST set the UDP-based TLV-header format flag to FALSE 🫶
if the local mobility anchor and the mobile access gateway successfully negotiated the TLV-header UDP-based tunneling format and GRE encapsulation for a specific mobility session, the local mobility anchor handles data packets the way described in the next subsection ✨
7.4.1. Sending and Receiving Data Packets
the local mobility anchor may use GRE encapsulation to tunnel an IPv6 or IPv4 data packet to the mobile access gateway 🧚 if it has successfully negotiated GRE encapsulation with the mobile access gateway for a specific mobility session, it encapsulates and decapsulates IPv6-or-IPv4 payload data packets following the rules in [RFC5213] and [RFC5844], and makes sure the GRE header is present like in Figure 7.
when TLV-tunneling format and GRE encapsulation have both been successfully negotiated for a specific mobility session between the local mobility anchor and the mobile access gateway, the local mobility anchor follows the TLV-header UDP-based tunneling format and header order shown in Figure 5 to encapsulate IPv4 or IPv6 payload packets in IPv4 before sending the IPv4 packet to the mobile access gateway 💜 in this case, the source and destination of the IPv4 outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. the source and destination IP addresses of the IPv6-or-IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA, respectively. and when it decapsulates IPv4 packets received from the mobile access gateway for that same mobility session, the local mobility anchor keeps the same TLV-header UDP-based tunneling format and header order 🎀
8. IANA Considerations
this spec defines a new mobility option, the GRE Key option, described in Section 6.1 💖 it's carried in the Mobility Header, and its type value comes from the same numbering space as the other mobility options defined in the Mobile IPv6 specification [RFC3775].
this spec also defines three new Binding Acknowledgement status codes, described in Section 6.4, and IANA has allocated the numeric values as specified in Section 6.4 from the "Status Codes" registry of the Mobility IPv6 Parameters 🌸
9. Security Considerations
okay this part is SERIOUS bestie 😭 the GRE Key option, when it's carried in Proxy Binding Update and Proxy Binding Acknowledgement messages, reveals the group affiliation of a mobile node identified by its Network Access Identifier (NAI) or an IP address. that can help an attacker target flows that belong to a specific group 💀 this can be prevented by turning on confidentiality protection for the Proxy Binding Update and Proxy Binding Acknowledgement messages, where the presence of the NAI and GRE Key options is what links a mobile node to a specific group. it can also be avoided by turning on confidentiality protection for all the tunneled data packets between the mobile access gateway and the local mobility anchor, so all the markings stay hidden 🔒
in Proxy Mobile IPv6 [RFC5213], using IPsec [RFC4301] to protect a mobile node's data traffic is optional. Proxy Mobile IPv6 also recommends using Encapsulating Security Payload (ESP) [RFC4303] in tunnel mode when ESP is used to protect the mobile node's data traffic. however, when GRE encapsulation is used, both IPsec tunnel mode and transport mode can be used to protect the GRE header. the IPsec traffic selectors will contain the protocol number for GRE, and right now there's no mechanism to use the GRE key as a traffic selector 🙈
10. Acknowledgements
the authors would like to thank Alessio Casati, Barney Barnowski, Mark Grayson, and Parviz Yegani for their input on the need for this option 🫶 they also want to thank Charlie Perkins, Curtis Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review and comments 👑
11. References
11.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[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.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009.Authors' Addresses
Ahmad Muhanna
Ericsson, Inc.
2201 Lakeside Blvd.
Richardson, TX 75082
USA
EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil
Ericsson, Inc.
6300 Legacy Dr.
Plano, TX 75024
USA
EMail: Mohamed.khalil@ericsson.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: sgundave@cisco.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com📦 where this page comes from
- ietf: rfc5845 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms