RFC 3024
Reverse Tunneling for Mobile IP, revised
Network Working Group, G. Montenegro, Editor, Request for Comments: 3024, Sun Microsystems, Inc., obsoletes RFC 2344, January 2001, Category: Standards Track 🎀
Reverse Tunneling for Mobile IP, revised ✨
Status of this Memo
okay bestie, first things first 💅 this doc is a Standards Track protocol spec for the whole Internet community, and it's basically asking everyone to come talk about it and suggest improvements 🫶 for where things stand officially, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚 and the memo's distribution is totally unlimited, so share away 🦋
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 🔒
Abstract
okay so Mobile IP normally tunnels from the home agent out to the mobile node's care-of address 🏠➡️📱, but it almost never goes the other way 🙈 usually the mobile node just sends its packets out through a router on the foreign network and assumes routing doesn't care what source address it's using 💭 but that assumption falls apart sometimes, and that's when it's super handy to set up a topologically correct reverse tunnel from the care-of address back to the home agent ✨
this doc proposes backwards-compatible extensions to Mobile IP so topologically correct reverse tunnels can actually happen 🎀 and it does NOT try to fix the problems firewalls cause between the home agent and the care-of address (that's a whole other mess, not today 💀)
this document obsoletes RFC 2344. 🗑️
Table of Contents
1. Introduction ................................................... 3
1.1. Terminology .................................................. 4
1.2. Assumptions .................................................. 4
1.3. Justification ................................................ 5
2. Overview ....................................................... 5
3. New Packet Formats ............................................. 6
3.1. Mobility Agent Advertisement Extension ....................... 6
3.2. Registration Request ......................................... 6
3.3. Encapsulating Delivery Style Extension ....................... 7
3.4. New Registration Reply Codes ................................. 8
4. Changes in Protocol Behavior ................................... 9
4.1. Mobile Node Considerations ................................... 9
4.1.1. Sending Registration Requests to the Foreign Agent ......... 9
4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
4.2. Foreign Agent Considerations ................................. 10
4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
4.2.2. Relaying Registration Requests to the Home Agent ........... 11
4.3. Home Agent Considerations .................................... 11
4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
5. Mobile Node to Foreign Agent Delivery Styles ................... 13
5.1. Direct Delivery Style ........................................ 13
5.1.1. Packet Processing .......................................... 13
5.1.2. Packet Header Format and Fields ............................ 13
5.2. Encapsulating Delivery Style ................................. 14
5.2.1 Packet Processing ........................................... 14
5.2.2. Packet Header Format and Fields ............................ 15
5.3. Support for Broadcast and Multicast Datagrams ................ 16
5.4. Selective Reverse Tunneling .................................. 16
6. Security Considerations ........................................ 17
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
6.2. Ingress Filtering ............................................ 18
6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
7. IANA Considerations ............................................ 18
8. Acknowledgements ............................................... 18
References ........................................................ 19
Editor and Chair Addresses ........................................ 20
Appendix A: Disparate Address Space Support ....................... 21
A.1. Scope of the Reverse Tunneling Solution ................... 21
A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
A.4. Limited Private Address Scenario .......................... 26
Appendix B: Changes from RFC2344 .................................. 29
Full Copyright Statement .......................................... 301. Introduction 🌸
okay so Section 1.3 of the Mobile IP spec [1] has this assumption baked in:
It is assumed that IP unicast datagrams are routed based on the
destination address in the datagram header (i.e., not by source
address).and because of security worries (like IP spoofing 👀), plus RFC 2267 [8] and CERT [3] advisories saying the same thing, routers that break that assumption are becoming way more common 😭
when those routers show up, the source and destination IP addresses in a packet MUST be topologically correct 🫶 the forward tunnel is fine with this, since both its endpoints (home agent address and care-of address) are properly assigned for where they live ✨ but the source IP address on packets the mobile node sends does NOT match the network prefix it's actually coming from 💀
this doc is all about topologically correct reverse tunnels 🦋
1.1. Terminology 📖
the discussion uses terms from the Mobile IP spec, and it also defines these:
- Forward Tunnel: a tunnel that shuttles packets towards the mobile node 🚐 it starts at the home agent and ends at the mobile node's care-of address.
- Reverse Tunnel: a tunnel that starts at the mobile node's care-of address and terminates at the home agent 🔄
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 RFC 2119 [9]. 📏
1.2. Assumptions 🧠
mobility is constrained to a common IP address space 🌐 (so the routing fabric between, say, the mobile node and the home agent is NOT split into a "private" and a "public" network).
this doc doesn't try to solve the firewall traversal problem 🧱 instead it assumes one of these is true:
- there are no intervening firewalls along the path of the tunneled packets ✨
- any intervening firewalls share the security association needed to process any authentication [6] or encryption [7] headers that may have been added to the tunneled packets 🔐
the reverse tunnels considered here are symmetric, meaning they use the same configuration (encapsulation method, IP address endpoints) as the forward tunnel 💖 IP in IP encapsulation [2] is assumed unless stated otherwise.
route optimization [4] introduces forward tunnels that start at a correspondent host 🏃♀️ since a mobile node may not know whether the correspondent host can decapsulate packets, reverse tunnels in that context are NOT discussed here.
1.3. Justification 💅
why not just let the mobile node start the tunnel to the home agent itself? 🤔 honestly, that's exactly what it SHOULD do if it's already running with a topologically correct co-located care-of address ✨
BUT one of the main goals of the Mobile IP spec is to NOT require that mode of operation 🙅♀️
the mechanisms in this doc are mainly for mobile nodes that rely on the foreign agent for forward tunnel support 🎀 it's important to keep supporting those mobile nodes, even when filtering routers are around 🫶
2. Overview 🦋
okay so a mobile node arrives at a foreign network, listens for agent advertisements, and picks a foreign agent that supports reverse tunnels ✨ when it registers through that foreign agent, it asks for this service 📝 and depending on how it wants to deliver packets to the foreign agent, it also requests either the Direct or the Encapsulating Delivery Style (section 5) 💫
in the Direct Delivery Style, the mobile node names the foreign agent as its default router and sends packets straight to it, with NO encapsulation 📦 the foreign agent then intercepts them and tunnels them to the home agent 🚇
in the Encapsulating Delivery Style, the mobile node encapsulates ALL its outgoing packets to the foreign agent 🎁 the foreign agent decapsulates them and re-tunnels them to the home agent, using the foreign agent's care-of address as the entry point of this new tunnel 🌈
3. New Packet Formats 🧚
3.1. Mobility Agent Advertisement Extension 💜
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 | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |R|B|H|F|M|G|V|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more Care-of Addresses |
| ... |the ONLY change to the Mobility Agent Advertisement Extension [1] is the extra 'T' bit 🎀
T Agent offers reverse tunneling service.a foreign agent that sets the 'T' bit MUST support the Direct Delivery Style 💅 the Encapsulating Delivery Style SHOULD be supported as well (section 5) ✨
so using this info, a mobile node can pick a foreign agent that supports reverse tunnels 🦋 and if a mobile node doesn't understand this bit, it just ignores it as per [1] 🫶
to be continued in part 2 of 6, bestie 💖 stay tuned! 🌸
3.2. Registration Request 🎀
okay so reverse tunneling gets added straight into the Registration Request by grabbing one of the rsvd bits 💅 if a foreign or home agent doesn't support reverse tunnels and gets a request with the 'T' bit set, the Registration Request fails 😭 that's a registration denial, and the failure codes are in section 3.4 🦋
Home agents SHOULD NOT object to providing reverse tunnel support, bc they "SHOULD be able to decapsulate and further deliver packets addressed to themselves, sent by a mobile node" [1] 🫶 with topologically correct reverse tunnels, the packets aren't sent by the mobile node if you look at its home address. instead, the outermost (encapsulating) IP source address on those datagrams is the mobile node's care-of address 🌸
in Registration Requests sent by a mobile node, the Time to Live field in the IP header MUST be set to 255 ✨ this is what limits a denial of service attack where malicious hosts send fake Registration Requests (see Section 6) 🛡️ lowkey iconic
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 |S|B|D|M|G|V|T|-| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-+-the only change to the Registration Request packet is the extra 'T' bit 🦋
T: If the'T'bit is set, the mobile node asks its home agent to accept a reverse tunnel from the care-of address. mobile nodes using a foreign agent care-of address ask the foreign agent to reverse-tunnel its packets 💜
3.3. Encapsulating Delivery Style Extension 🧚
the Encapsulating Delivery Style Extension MAY be included by the mobile node in registration requests to further specify reverse tunneling behavior 🌈 it's expected to be used only by the foreign agent, so the foreign agent MUST consume this extension. that means it must not relay it to the home agent or include it in replies to the mobile node 🙈 as per Section 3.6.1.3 of [1], the mobile node MUST include the Encapsulating Delivery Style Extension after the Mobile-Home Authentication Extension, and before the Mobile-Foreign Authentication Extension, if present 📝
the Encapsulating Delivery Style Extension MUST NOT be included if the 'T' bit is not set in the Registration Request ❌
if this extension is absent, Direct Delivery is assumed. encapsulation is done according to what was negotiated for the forward tunnel (so IP in IP is assumed unless specified otherwise) 🍓 for more details on the delivery styles, check section 5 🔍
Foreign agents SHOULD support the Encapsulating Delivery Style Extension 💖
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type:
130 - Length:
0
3.4. New Registration Reply Codes 💅
foreign and home agent registration replies MUST convey if the reverse tunnel request failed 📮 these new reply codes are defined:
Service denied by the foreign agent:
74 requested reverse tunnel unavailable
75 reverse tunnel is mandatory and 'T' bit not set
76 mobile node too distant
79 delivery style not supported
NOTE: Code 79 has not yet been assigned by IANA.and
Service denied by the home agent:
137 requested reverse tunnel unavailable
138 reverse tunnel is mandatory and 'T' bit not set
139 requested encapsulation unavailablein response to a Registration Request with the 'T' bit set, mobile nodes may receive (and MUST accept) code 70 (poorly formed request) from foreign agents, and code 134 (poorly formed request) from home agents 🥹 however, foreign and home agents that support reverse tunneling MUST use codes 74 and 137, respectively 👑
in addition to setting the 'T' bit, the mobile node also MAY request the Encapsulating Delivery Style by including the corresponding extension ✨ if a foreign agent doesn't implement the Encapsulating Delivery Style, it MUST respond to the mobile node with code 79 (delivery style not supported). this also applies if the foreign agent doesn't support a requested delivery style that may be defined in the future 🔮
absence of the 'T' bit in a Registration Request MAY elicit denials with codes 75 and 138 at the foreign agent and the home agent, respectively 🙃
forward and reverse tunnels are symmetric, so both can use the same tunneling options negotiated at registration. this means the home agent MUST deny registrations if an unsupported form of tunneling is requested (code 139) 🚫 notice that Mobile IP [1] already defines the analogous failure code 72 for use by the foreign agent 🦋
4. Changes in Protocol Behavior 🌸
unless otherwise specified, behavior specified by Mobile IP [1] is assumed 💜 in particular, if any two entities share a mobility security association, they MUST use the appropriate Authentication Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication Extension) when exchanging registration protocol datagrams. an admissible authentication extension (for example the Mobile-Home Authentication Extension) MUST always be present to authenticate registration messages between a mobile node and its home agent 🔐
reverse tunneling adds extra protocol processing requirements on mobile entities 🧠 differences in protocol behavior with respect to Mobile IP [1] are specified in the subsequent sections 🌈
4.1. Mobile Node Considerations 📱
this section describes how the mobile node handles registrations that request a reverse tunnel 🦋
4.1.1. Sending Registration Requests to the Foreign Agent 📤
in addition to the considerations in [1], a mobile node sets the 'T' bit in its Registration Request to petition a reverse tunnel 🎀
the mobile node MUST set the TTL field of the IP header to 255. this is meant to limit the reverse tunnel hijacking attack (Section 6) 🛡️
the mobile node MAY optionally include an Encapsulating Delivery Style Extension ✨
4.1.2. Receiving Registration Replies from the Foreign Agent 📥
possible valid responses are:
- A registration denial issued by either the home agent or the foreign agent:
- a. The mobile node follows the error checking guidelines in [1], and depending on the reply code, MAY try modifying the registration request (for example, by eliminating the request for alternate forms of encapsulation or delivery style), and issuing a new registration. 🔄
- b. Depending on the reply code, the mobile node MAY try zeroing the
'T'bit, eliminating the Encapsulating Delivery Style Extension (if one was present), and issuing a new registration. notice that after doing so the registration may succeed, but due to the lack of a reverse tunnel, data transfer may not be possible 🥺
- The home agent returns a Registration Reply indicating that the service will be provided. ✅
in this last case, the mobile node has succeeded in establishing a reverse tunnel between its care-of address and its home agent 🎉 if the mobile node is operating with a co-located care-of address, it MAY encapsulate outgoing data so that the destination address of the outer header is the home agent. this ability to selectively reverse-tunnel packets is discussed further in section 5.4 💅
if the care-of address belongs to a separate foreign agent, the mobile node MUST employ whatever delivery style was requested (Direct or Encapsulating) and proceed as specified in section 5 🧚
a successful registration reply is an assurance that both the foreign agent and the home agent support whatever alternate forms of encapsulation (other than IP in IP) were requested. so the mobile node MAY use them at its discretion 💖
4.2. Foreign Agent Considerations 🏠
this section describes how the foreign agent handles registrations that request a reverse tunnel 🌷
4.2.1. Receiving Registration Requests from the Mobile Node 📨
a foreign agent that receives a Registration Request with the 'T' bit set processes the packet as specified in the Mobile IP specification [1], and determines whether it can accommodate the forward tunnel request 🧐 if it can't, it returns an appropriate code. in particular, if the foreign agent is unable to support the requested form of encapsulation, it MUST return code 72. if it can't support the requested form of delivery style, it MUST return code 79 (delivery style not supported) 🙅♀️
the foreign agent MAY reject Registration Requests without the 'T' bit set by denying them with code 75 (reverse tunnel is mandatory and 'T' bit not set) 🫠
the foreign agent MUST verify that the TTL field of the IP header is set to 255. otherwise, it MUST reject the registration with code 76 (mobile node too distant) 📏 the foreign agent MUST limit the rate at which it sends these registration replies to a maximum of one per second ⏱️
as a last check, the foreign agent verifies that it can support a reverse tunnel with the same configuration. if it can't, it MUST return a Registration Reply denying the request with code 74 (requested reverse tunnel unavailable) 😤
4.2.2. Relaying Registration Requests to the Home Agent 📬
otherwise, the foreign agent MUST relay the Registration Request to the home agent 💌
upon receipt of a Registration Reply that satisfies validity checks, the foreign agent MUST update its visitor list. that includes noting that this mobile node has been granted a reverse tunnel and the delivery style expected (section 5) 📋
while this visitor list entry is in effect, the foreign agent MUST process incoming traffic according to the delivery style, encapsulate it, and tunnel it from the care-of address to the home agent's address 🚇✨
4.3. Home Agent Considerations 🏡
this section describes how the home agent handles registrations that request a reverse tunnel 💜
4.3.1. Receiving Registration Requests from the Foreign Agent ✨
okay so when a home agent gets a Registration Request with the 'T' bit set, it handles the packet the way the Mobile IP specification [1] describes and checks whether it can take on the forward tunnel request 🎀. If it can't, it sends back an appropriate code. The big one is if it can't support the form of encapsulation that was asked for. In that case it MUST return code 139 (requested encapsulation unavailable) 💀
The home agent MAY also turn away registration requests that don't have the 'T' bit set. It does that by denying them with code 138 (reverse tunnel is mandatory and 'T' bit not set) 🙈
Then there's one last check. The home agent looks at whether it can support a reverse tunnel with the same setup as the forward tunnel. If it can't, it MUST send back a registration denial with code 137 (requested reverse tunnel unavailable) 😭
When a Registration Reply comes in and passes the validity checks, the home agent MUST update its mobility bindings list. This shows that the mobile node got a reverse tunnel and which type of encapsulation to expect 🦋
4.3.2. Sending Registration Replies to the Foreign Agent ✨
When a Registration Request is valid, the home agent MUST send a Registration Reply to the mobile node 💌
Once the registration is done, the home agent might get encapsulated packets that are addressed to itself. Decapsulating those and blindly shoving them into the network is a potential security weakness (section 6.1), so this is a big deal 🚨. That's why the home agent MUST implement, and by default SHOULD enable, this check for encapsulated packets addressed to itself:
The home agent searches for a mobility binding whose care-of
address is the source of the outer header, and whose mobile node
address is the source of the inner header.If there's no matching binding, or if the packet uses an encapsulation mechanism that wasn't negotiated at registration, the home agent MUST silently discard the packet. It SHOULD also log the event as a security exception 👀
Home agents that terminate tunnels that have nothing to do with Mobile IP, like multicast tunnels, MAY turn off the check above. Still, this is discouraged for the reasons already mentioned 🙅♀️
While the registration is active, the home agent MUST process each valid reverse tunneled packet (as determined by checks like the one above). It decapsulates the packet, recovers the original packet, and forwards it on behalf of its sender (the mobile node) to the destination address (the correspondent host) 🚀
5. Mobile Node to Foreign Agent Delivery Styles 🧚
This section explains how the mobile node sends its data traffic through the foreign agent. In every case, the mobile node learns the foreign agent's link-layer address from the link-layer header in the agent advertisement 📬
5.1. Direct Delivery Style 🌸
This delivery mechanism is super simple to build on the mobile node side. It uses small, non-encapsulated packets on the link between the mobile node and the foreign agent, which is great if that link is slow 🐢. The downside is that it only supports reverse-tunneling of unicast packets, and it can't do selective reverse tunneling (section 5.4) 😤
5.1.1. Packet Processing 💅
The mobile node MUST set the foreign agent as its default router. If it doesn't, all of the mobile node's outgoing traffic won't be guaranteed to get encapsulated, and then the whole reverse tunnel thing is pointless 💔. The foreign agent MUST:
- detect packets sent by the mobile node, and
- modify its forwarding function to encapsulate them before forwarding.
5.1.2. Packet Header Format and Fields 🎀
This section shows the header formats used by the Direct Delivery style. These formats assume IP in IP encapsulation [2] 🫶
The packet the foreign agent receives looks like this (Direct Delivery Style):
IP fields:
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer ProtocolThe packet the foreign agent forwards looks like this (Direct Delivery Style):
IP fields (encapsulating header):
Source Address = foreign agent's care-of address
Destination Address = home agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer ProtocolThe fields of the encapsulating header MUST be filled in like this:
IP Source Address: copied from the Care-of Address field within the Registration Request.IP Destination Address: copied from the Home Agent field within the most recent successful Registration Reply.IP Protocol Field: the default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time 🧁
5.2. Encapsulating Delivery Style 💖
This mechanism requires the mobile node to implement encapsulation. It sends packets straight to the foreign agent by making it the destination address in a new outermost header 📦. Mobile nodes that want to send broadcast or multicast packets MUST use the Encapsulating Delivery Style 📡
5.2.1 Packet Processing 🦋
The foreign agent doesn't change its forwarding function. Instead, it receives an encapsulated packet and, after confirming that the mobile node sent it, it:
- decapsulates to recover the inner packet, and
- re-encapsulates it and sends it to the home agent.
If a foreign agent gets an un-encapsulated packet from a mobile node that explicitly asked for the Encapsulated Delivery Style, the foreign agent MUST NOT reverse tunnel that packet. Instead, it MUST forward it using standard IP routing mechanisms 🛣️
5.2.2. Packet Header Format and Fields 🌈
This section shows the header formats used by the Encapsulating Delivery style. These formats assume IP in IP encapsulation [2] 🧚♀️
The packet the foreign agent receives looks like this (Encapsulating Delivery Style):
IP fields (encapsulating header):
Source Address = mobile node's home address
Destination Address = foreign agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer ProtocolThe fields of the encapsulating IP header MUST be filled in like this:
IP Source Address: the mobile node's home address.IP Destination Address: the address of the agent, as learned from the IP source address of the agent's most recent successful registration reply.IP Protocol Field: the default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time 🍓
The packet the foreign agent forwards looks like this (Encapsulating Delivery Style):
IP fields (encapsulating header):
Source Address = foreign agent's care-of address
Destination Address = home agent's address
Protocol field: 4 (IP in IP)
IP fields (original header):
Source Address = mobile node's home address
Destination Address = correspondent host's address
Upper Layer ProtocolThe fields of the encapsulating IP header MUST be filled in like this:
IP Source Address: copied from the Care-of Address field within the Registration Request.IP Destination Address: copied from the Home Agent field within the most recent successful Registration Reply.IP Protocol Field: the default is 4 (IP in IP [2]), but other methods of encapsulation MAY be used as negotiated at registration time ✨
5.3. Support for Broadcast and Multicast Datagrams 📣
If a mobile node is using a co-located care-of address, its broadcast and multicast datagrams are handled according to Sections 4.3 and 4.4 of the Mobile IP specification [1] 🌷. Mobile nodes that use a foreign agent care-of address MAY have their broadcast and multicast datagrams reverse-tunneled by the foreign agent. But any mobile node doing that MUST use the encapsulating delivery style 🫶
This only delivers the datagram to the foreign agent. The foreign agent then decapsulates it and processes it like any other packet from the mobile node, meaning it reverse tunnels it to the home agent 🚇
5.4. Selective Reverse Tunneling 🦋
Packets aimed at local resources, like a nearby printer, might not be affected by ingress filtering. A mobile node with a co-located care-of address MAY optimize delivery of these packets by not reverse tunneling them 🖨️. A mobile node using a foreign agent care-of address MAY also use this selective reverse tunneling capability. To do that, it requests the Encapsulating Delivery Style and follows these guidelines 💅
Packets that are NOT meant to be reverse tunneled:
- Send them using the Direct Delivery style. The foreign agent MUST process these packets as regular traffic. They MAY be forwarded, but they MUST NOT be reverse tunneled to the home agent 🚫
Packets that are meant to be reverse tunneled:
- Send them using the Encapsulating Delivery style. The foreign agent MUST process these packets as specified in section 5.2. They MUST be reverse tunneled to the home agent 🔁
6. Security Considerations 🔐
The extensions in this document are subject to the security considerations in the Mobile IP specification [1]. Basically, creating both forward and reverse tunnels involves an authentication procedure, and that cuts down the risk of attack 🛡️
6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks 😱
Once a tunnel is set up, a malicious node could hijack it and inject packets into the network. Reverse tunnels might make this worse, because once packets reach the tunnel exit point, they get forwarded beyond the local network 🚨. The Mobile IP specification has this concern too, since it already calls for reverse tunnels for certain applications.
Unauthenticated exchanges involving the foreign agent let a malicious node pretend to be a valid mobile node and redirect an existing reverse tunnel to another home agent, which might be yet another malicious node 🕵️♀️. The best way to protect against these attacks is to use the Mobile-Foreign and Foreign-Home Authentication Extensions defined in [1] 🔑
If the necessary mobility security associations aren't available, this document introduces a mechanism to shrink the range and effectiveness of these attacks. The mobile node MUST set the TTL value in the IP headers of Registration Requests sent to the foreign agent to 255. This stops malicious nodes that are more than one hop away from pretending to be valid mobile nodes 🙅. The additional codes for registration denials make the attacks that still happen easier to track 🕵️
The Mobile IP Working Group also considered other mechanisms that use unauthenticated state, hoping to reduce these attacks even more. However, those mechanisms open the door to denial-of-service attacks. The consensus was that this was too big a trade-off for mechanisms that only guarantee weak (non-cryptographic) protection against attacks 🥹
6.2. Ingress Filtering 🕵️♀️
Okay so, people have been worried that reverse tunneling might stop working once ingress filtering is in place 😬. The theory is that network admins would go after reverse-tunneled packets (IP in IP encapsulated packets) and filter them out. The ingress filtering recommendation explains why that's not really the case [8]:
Tracking the source of an attack is simplified when the source is more likely to be "valid."
6.3. Reverse Tunneling for Disparate Address Spaces 🫶
Now this part is kind of serious, bestie 🥺. The foreign agent can use link-layer information to pick the right reverse tunnel for mobile node packets (section A.3), and that comes with security implications. If the link layer isn't authenticated, a malicious mobile node can misuse someone else's existing reverse tunnel and inject packets into the network 😱.
So for this solution to actually be viable, the link-layer MUST securely authenticate traffic received by the foreign agent from the mobile nodes 🔐. Unauthenticated link-layer technologies (for example shared ethernet) are not recommended for implementing disparate address support 🙅♀️.
7. IANA Considerations 📋
The Encapsulating Delivery Style extension defined in section 3.3 is a Mobile IP registration extension, as defined in [1] 🎀. IANA assigned the value of 130 to it when RFC 2344 was published 💖.
The Code values defined in section 3.4 are error codes, as defined in [1] ✨. They match up with error values for rejections from the home and foreign agents. When RFC 2344 was published, IANA assigned codes 74-76 for the foreign agent rejections and codes 137-139 for the home agent rejections 🌸. The code for 'delivery style not supported' has since been assigned a value of 79 by IANA for this purpose 💅.
8. Acknowledgements 🫶🌈
The encapsulating style of delivery was proposed by Charlie Perkins 👑. Jim Solomon has been instrumental in shaping this document into its present form 🌟. Thanks to Samita Chakrabarti for helpful comments on disparate address space support, and for most of the text in section A.4 💜. She's literally iconic 💖.
References 📚
- [1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
- [2] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
- [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks and Hijacked Terminal Connections", CA-95:01, January 1995. Available via anonymous ftp from info.cert.org in /pub/cert_advisories.
- [4] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
- [5] Manuel Rodriguez, private communication, August 1995.
- [6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
- [7] Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406, November 1998.
- [8] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
- [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
- [11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
- [12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
- [13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, August 2000.
Editor and Chair Addresses 📬
Questions about this document may be directed at:
Gabriel E. Montenegro
Sun Microsystems
Laboratories, Europe
29, chemin du Vieux Chene
38240 Meylan
FRANCE
Phone: +33 476 18 80 45
EMail: gab@sun.comThe working group can be contacted via the current chairs:
Basavaraj Patil
Nokia Networks
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Raj.Patil@nokia.comPhil Roberts
Motorola
1501 West Shure Drive
Arlington Heights, IL 60004
USA
Phone: +1 847-632-3148
EMail: QA3445@email.mot.comAppendix A: Disparate Address Space Support 🧚
Mobile IP [1] assumes that all the entities involved (mobile node, foreign agent and home agent) have addresses within the same globally routable address space 🌍. In lots of deployments, when a mobile node leaves its home network, it might wander into a region where its home address isn't routable or known by the local routing fabric 🫠. Similarly, the IP addresses of the foreign agent and the home agent may belong to disparate address spaces, which means they can't exchange registration protocol messages directly 🙈. These issues are especially likely when the entities involved use addresses from the ranges specified in RFC1918 [12] to support private networks 🔒.
Accurately speaking, private addresses aren't the only cause ✨. They may actually be the most common one, but the root of the problem is the use of disparate address spaces 💡. For example, corporations often have several properly allocated address ranges 🏢. They usually advertise reachability to only a subset of those ranges and keep the others for use exclusively within the corporate network 🤫. Since these ranges aren't routable on the general Internet, using them causes the same problems as "private" addresses, even though they aren't taken from the ranges specified in RFC1918 💅.
Even if the mobile node, home agent and foreign agent all live in the same address space, problems can still come up if the correspondent node doesn't 👀. However, this problem isn't specific to Mobile IP and is beyond the scope of this document 🙃. The next section narrows the scope of the relevant issues even further, and a later section explains how reverse tunneling may be used to tackle them 🦋.
A.1. Scope of the Reverse Tunneling Solution 💖
okay so bestie, reverse tunneling 🦋 (as defined in this doc) can be used to cope with disparate address spaces, but it comes with some rules 💅:
- there are no provisions for the case where the correspondent node and the mobile node are in disparate address spaces 😭. this keeps the problem focused on the stuff that's specific to Mobile IP 🎀.
- the foreign agent and the home agent can reach each other directly because they live in the same address space 🧚. this keeps things simple, and it also means the registration protocol has a direct path between FA and HA, so disparate address spaces don't mess with it. this also applies to mobile nodes using a co-located care-of address. in that case reverse tunneling is a complete and elegant solution ✨.
- there are no extra protocol elements beyond what Mobile IP [1] and reverse tunneling already define 🌸. extra extensions to registration requests or replies, or extra bits in the header, could be useful, but they're out of scope for this document 🙈.
ngl the limits are real, but reverse tunneling still fixes the most common problems 👑. the best way to see which problems it can solve is with some simple diagrams 🍓.
Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES
Mc Fa Fb Hb Hc Yc
[MN]-----------------[FA]----------------[HA]---------------[Y]
Addr space A Addr space B Addr space Cokay this diagram has three disparate address spaces: A, B and C 🌈. the home agent (HA) has one address on each of spaces B and C, and the foreign agent (FA) has addresses on spaces A and B. the mobile node's (MN) permanent address, Mc, lives in address space C 💜.
in the most common setup, A and C are "private" address spaces and B is the public Internet 🌍.
so say MN sends a packet to correspondent node (Y) in its home network 💌. MN has no trouble getting that packet to the FA, because it uses layer 2 mechanisms to do it ✨. somehow the FA has to realize that this packet needs reverse tunneling, and it has to fetch the right binding to do that 🔥. possible mechanisms are outlined in section A.3 🧚.
but once the packet is in address space B, it becomes non-routable 😭. ingress filtering makes this even worse 💀, because it adds a requirement that the source IP address be topologically significant, on top of the destination address 🙈. and as Mobile IP matures, other entities might get defined (AAA servers, for example) 🍓. each new one adds even more requirements on the address spaces in use 💅.
reverse tunneling adds a topologically significant IP header to the packet while it's in address space B 🦋: source IP address Fb, destination Hb. assuming IP in IP encapsulation (though GRE is also possible) 🎀, the packet looks like this:
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+HA receives this packet, recovers the original packet, and since it knows about address space C, it delivers the packet to the right interface 👑.
for this to happen, the care-of address that MN registers can't be the usual Fa. it has to be Fb 💖. how that happens is outside the scope of this document ✨, but some possible mechanisms are:
- FA recognizes mobile nodes whose addresses fall within the private address ranges specified by RFC1918 🌸. in that case, the foreign agent could force the use of Fb as the care-of address, maybe by rejecting the initial registration request with an appropriate error message and supplemental information 💅.
- FA could always advertise Fb, as long as H->Fb and Fb->H are guaranteed to be valid forward and reverse tunnels, respectively, for every value of H 🧚. here H is the address of any home agent whose mobile nodes may register via FA 🍓.
- FA could indicate that it supports disparate address spaces with a not-yet-defined 'P' bit in its advertisements 🌈. it could also indicate the relevant address space for any or all of its care-of addresses by including an NAI [11] or a realm indicator (maybe a variant of the NAI) 💜. alternatively, mobile nodes set up to do so could ask for the NAI or realm indicator information in response to advertisements with the 'P' bit set 🦋.
MN also needs to supply the right address for its home agent: Hb instead of the usual Hc 🎀. how that happens is outside the scope of this document too 🙈, but some possible mechanisms are:
- this determination could be triggered when the foreign agent's Fb is used as the care-of address 👑.
- MN could always use Hb as its home agent address, especially (1) if Hb is routable within address space C, or (2) if MN is certain never to be at home (in some configurations, mobile nodes are always roaming) ✨.
- MN could be configured with different home agent addresses and their corresponding address space, maybe indicated via an NAI [11] or a variant of it 🌸.
another big issue that private addresses bring is two or more mobile nodes with the same numeric IP address 😭:
Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES
Mc=M H1b H1c
[MN1]-------+ +----[HA1]----+---------
| | | Address
| | | space C
Address | | Address +----------
Space Fa-[FA]-Fb Space
A | | B +---------
| | | Address
| | | space D
[MN2]-------+ +----[HA2]----+---------
Md=M H2b H2dso picture this 💀: there are two address spaces, A and B, and a foreign agent (FA) with interfaces on both 🧚. there are two home agents (HA1 and HA2) in address space B, with addresses H1b and H2b 🍓. each home agent also has an interface in a private address space: HA1 has H1c on C, and HA2 has H2d on D 🌈. MN1 and MN2 are two mobile nodes with home addresses Mc and Md, which belong to address spaces C and D 💜.
if Mc and Md are private addresses as defined in RFC1918, they can be numerically equal (both are M) 😭. because of that, the foreign agent can't rely only on the mobile node's home address to tell its different bindings apart 🙈.
A.2. Terminating Forward Tunnels at the Foreign Agent 🦋
okay so in figure A1, say the correspondent node Y sends a packet to the mobile node at address Mc 🎀. the home agent at Hc intercepts the packet and tunnels it toward the mobile node via address Fb 👑.
once the packet reaches FA (via address Fb), the foreign agent has to figure out which of its registered mobile nodes is the real destination of the inner packet ✨. to do that, it needs to find the right binding using a tuple that's guaranteed to be unique among all of its mobile nodes 🌸.
the unique tuple that's enough to demultiplex IP in IP packets [IPIP] (protocol 4) is:
- destination IP address of the encapsulated (internal) header 💅
this is mobile node MN's home address (Mc in the example above). at first glance it seems unique among all mobile nodes, but as we said above, with private addresses another mobile node may have an address Md that's numerically equal to Mc 😭.
- source IP address of the external header 🧚
this is the remote end of the tunnel, which is Hb in the example above.
- destination IP address of the external header 🍓
this is the local end of the tunnel, which is Fb in the example above.
the three values above get learned from a successful registration, and they're the mobile node's home address, the home agent's address and the care-of address 🌈. so it's possible to identify the right binding 💜. once FA works out the ultimate destination of the packet, Mc, it delivers the inner packet using link layer mechanisms 🦋.
GRE packets [10] (protocol 47) are only handled if their Protocol Type field is 0x800 (other values are outside the scope of this document) 🎀. they're demultiplexed using the same tuple as IP in IP packets. in GRE terminology, that tuple is:
- destination IP address of the payload (internal) packet 👑
- source IP address of the delivery (external) packet ✨
- destination IP address of the delivery (external) packet 🌸
not gonna lie, the Routing, Sequence Number, Strict Source Route and Key fields have been deprecated from GRE [10] 🙈. but a separate document specifies how to use them [13] 💅.
the tuples above work for IP-in-IP or GRE encapsulation, and they assume the inner packet is in the clear 🧚. encapsulations that encrypt the inner packet header are outside the scope of this document 🔥.
A.3. Initiating Reverse Tunnels at the Foreign Agent 🌈
in figure A3, say mobile node M1 sends a packet to a correspondent node in its home address space, C, and mobile node M2 sends a packet to a correspondent node in its home address space, D 💜.
at FA, the source address of both packets shows up as M, so that's not enough info on its own 😭. the unique tuple needed to identify the right binding is:
- link-layer information related to the MN 🦋
this can be a MAC address, a PPP session (or incoming interface), or channel coding for a digital cellular service 🎀. device IDs can be used here too 🍓.
- source IP address of the IP header 💀
as we already pointed out, this by itself isn't guaranteed to be unique 🙈.
this information must be established and recorded at registration time 👑. the items above are enough for the foreign agent to pick the right binding to use ✨. that binding gives the home agent's address and the reverse tunneling options negotiated during registration 🌸. the foreign agent can now go ahead with reverse tunneling 💖🫶
A.4. Limited Private Address Scenario 🎀
Okay so the Limited Private Address Scenario (LPAS) has been getting SO much attention from the cellular wireless industry 😭, so it's worth defining it and pinning down exactly what it needs. ✨
LPAS is basically a subset of the disparate address space scenario we've been talking about in this appendix. This section explains how LPAS could be deployed given where the Mobile IP specs are right now. 🦋
Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO
10.10.1.2
+----+ IF1=COA1+-------+ HAA2 +-----+
| MN1|------------------------| FA |---------| HA2 |
+----+ +------------| | +-----+
| IF2=COA2+-------+
+---+ |
| |
+-----+ |
| MN2 | |
+-----+ |
10.10.1.2 |
| HAA1
+------+
| HA1 |
+------+This figure is a super simple setup where private addresses show up. When we say "private addresses" we really mean the ones defined in RFC 1918 [12]. 💅 In this scenario, the only things with private addresses are the mobile nodes. The foreign agents and home agents both have publicly routable addresses on the general Internet. To be specific, the care-of addresses the foreign agents advertise (COA1 and COA2 in Figure A4) and the home agent addresses that mobile nodes put in registration requests (HAA1 and HAA2 in Figure A4) are all publicly routable on the general Internet. 🌸 So any Mobile IP tunnel can be set up between any home agent home address and any foreign agent care-of address. Iconic. 👑
Also, check this out: two different mobile nodes (MN1 and MN2) can have the exact same private address (10.10.1.2) and still be visiting the same foreign agent FA. 🙈 That works as long as MN1 and MN2 are served by different home agents. So from any given home agent's point of view, each mobile node has a unique IP address, even if that address is a private one under RFC 1918. Main character energy. 🧚
Operation with route optimization [4] is outside the scope of this document, so we're not touching that one. 🙅♀️
Mobile node requirements:
Mobile nodes that want to use private addresses with Mobile IP MUST set the 'T' bit and employ reverse tunneling. 🔥 A mobile node's private addresses within a given address space MUST be unique. Basically, two mobile nodes that belong to a single home agent can't have the same private addresses. So when tunneled traffic is being received or sent for a mobile node, the tunnel endpoints are what get used to tell apart conflicting mobile node addresses. 💜
If a mobile node happens to register with multiple home agents at the same time through the same foreign agent, there must be some link-layer information that's distinct for each mobile node. ngl this is the tricky bit. If no such distinct link-layer information is available, the mobile nodes MUST use unique address. 😭
Foreign agent requirements:
All advertising interfaces of the foreign agent MUST have publicly routable care-of address. 🎀 So a mobile node with a private address only visits the foreign agent inside its publicly routable network. Lowkey the cleanest rule in this whole appendix. 💖
Foreign agents MUST support reverse tunneling so they can support mobile nodes with private addresses. If a foreign agent gets a registration request from a mobile node with a private address, and that mobile node hasn't set the 'T' bit, the foreign agent SHOULD reject it. 🙅♀️
When packets are being delivered to or received from mobile nodes, foreign agents MUST disambiguate among mobile nodes with conflicting private addresses by using the link-layer information we mentioned earlier (Appendix section A.2 and A.3). 🦋 Without route optimization, a foreign agent should make sure that two mobile nodes visiting the same foreign agent correspond with each other through their respective home agents. Bestie, that's a lot of moving pieces but it's so satisfying. 🫶
If a foreign agent supports reverse tunneling, then it MUST support the simple scenario of private address support described in this section. ✨
Home agent requirements:
Any home agent address that mobile nodes use in registration requests MUST be a publicly routable address. 🌈 Home agents won't support overlapping private home addresses, so each private home address of a mobile node registered with a home agent is unique. 🍓 When the 'T' bit is set in the registration request from the mobile node, the home agent MUST recognize and accept registration requests from mobile nodes with private addresses. Also, the home agent SHOULD be able to assign private addresses out of its address pool to mobile nodes for use as home addresses. This doesn't contravene home agent processing in section 3.8 of [1]. 👑
Appendix B: Changes from RFC2344 💅
Okay, here's the glow-up history. This section lists what changed compared to the previous version of this document, RFC2344. 🎀
- Added Appendix A on support for Disparate Addresses spaces and private addresses. 🧚
- Added the corresponding section (6.3) under 'Security Considerations'. 🔥
- Made Encapsulating Delivery Support optional by demoting from a MUST to a should. This also meant defining a new error code 79 (assigned by IANA). 💜
- Mentioned the possibility of an admissible authentication extension, which may be different from the Mobile-Home authentication extension. 🌸
- An IANA considerations section was added. 🦋
Full Copyright Statement ⭐
Here's the legal stuff, and yes it's important, so it stays word-for-word. 🫶
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Huge thanks to the Internet Society, which is currently funding the RFC Editor function. Couldn't do this without them, bestie. 💖
📦 where this page comes from
- ietf: rfc3024 2001-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms