As per Relevance of the word tunneling, we have this rfc below:
Network Working Group G. Montenegro,
Request for Comments: 3024 Sun Microsystems, Inc
Obsoletes: 2344 January 2001
Category: Standards
Reverse Tunneling for Mobile IP,
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
Mobile Internet Protocol (IP) uses tunneling from the home agent
the mobile node's care-of address, but rarely in the
direction. Usually, a mobile node sends its packets through a
on the foreign network, and assumes that routing is independent
source address. When this assumption is not true, it is
to establish a topologically correct reverse tunnel from the care-
address to the home agent
This document proposes backwards-compatible extensions to Mobile
to support topologically correct reverse tunnels. This document
not attempt to solve the problems posed by firewalls located
the home agent and the mobile node's care-of address
This document obsoletes RFC 2344.
Montenegro Standards Track [Page 1]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Table of
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 .......................................... 30
Montenegro Standards Track [Page 2]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
1.
Section 1.3 of the Mobile IP specification [1] lists the
assumption
It is assumed that IP unicast datagrams are routed based on
destination address in the datagram header (i.e., not by
address).
Because of security concerns (for example, IP spoofing attacks),
in accordance with RFC 2267 [8] and CERT [3] advisories to
effect, routers that break this assumption are increasingly
common
In the presence of such routers, the source and destination
address in a packet must be topologically correct. The
tunnel complies with this, as its endpoints (home agent address
care-of address) are properly assigned addresses for their
locations. On the other hand, the source IP address of a
transmitted by the mobile node does not correspond to the
prefix from where it emanates
This document discusses topologically correct reverse tunnels
Mobile IP does dictate the use of reverse tunnels in the context
multicast datagram routing and mobile routers. However, the
IP address is set to the mobile node's home address, so these
are not topologically correct
Notice that there are several uses for reverse tunnels regardless
their topological correctness
- Mobile routers: reverse tunnels obviate the need for
tunneling [1].
- Multicast: reverse tunnels enable a mobile node away from
to (1) join multicast groups in its home network, and (2)
transmit multicast packets such that they emanate from its
network [1].
- The TTL of packets sent by the mobile node (for example,
sending packets to other hosts in its home network) may be
low that they might expire before reaching their destination
A reverse tunnel solves the problem as it represents a
decrement of one [5].
Montenegro Standards Track [Page 3]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
1.1.
The discussion below uses terms defined in the Mobile
specification. Additionally, it uses the following terms
Forward
A tunnel that shuttles packets towards the mobile node.
starts at the home agent, and ends at the mobile node's care-
address
Reverse
A tunnel that starts at the mobile node's care-of address
terminates at the home agent
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [9].
1.2.
Mobility is constrained to a common IP address space (that is,
routing fabric between, say, the mobile node and the home agent
not partitioned into a "private" and a "public" network).
This document does not attempt to solve the firewall
problem. Rather, it assumes one of the following is true
- There are no intervening firewalls along the path of
tunneled packets
- Any intervening firewalls share the security
necessary to process any authentication [6] or encryption [7]
headers which may have been added to the tunneled packets
The reverse tunnels considered here are symmetric, that is, they
the same configuration (encapsulation method, IP address endpoints
as the forward tunnel. IP in IP encapsulation [2] is assumed
stated otherwise
Route optimization [4] introduces forward tunnels initiated at
correspondent host. Since a mobile node may not know if
correspondent host can decapsulate packets, reverse tunnels in
context are not discussed here
Montenegro Standards Track [Page 4]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
1.3.
Why not let the mobile node itself initiate the tunnel to the
agent? This is indeed what it should do if it is already
with a topologically correct co-located care-of address
However, one of the primary objectives of the Mobile IP
is not to require this mode of operation
The mechanisms outlined in this document are primarily intended
use by mobile nodes that rely on the foreign agent for forward
support. It is desirable to continue supporting these mobile nodes
even in the presence of filtering routers
2.
A mobile node arrives at a foreign network, listens for
advertisements and selects a foreign agent that supports
tunnels. It requests this service when it registers through
selected foreign agent. At this time, and depending on how
mobile node wishes to deliver packets to the foreign agent, it
requests either the Direct or the Encapsulating Delivery
(section 5).
In the Direct Delivery Style, the mobile node designates the
agent as its default router and proceeds to send packets directly
the foreign agent, that is, without encapsulation. The foreign
intercepts them, and tunnels them to the home agent
In the Encapsulating Delivery Style, the mobile node encapsulates
its outgoing packets to the foreign agent. The foreign
decapsulates and re-tunnels them to the home agent, using the
agent's care-of address as the entry-point of this new tunnel
Montenegro Standards Track [Page 5]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
3. New Packet
3.1. Mobility Agent Advertisement
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]
the additional 'T' bit
T Agent offers reverse tunneling service
A foreign agent that sets the 'T' bit MUST support the
Delivery Style. Encapsulating Delivery Style SHOULD be supported
well (section 5).
Using this information, a mobile node is able to choose a
agent that supports reverse tunnels. Notice that if a mobile
does not understand this bit, it simply ignores it as per [1].
3.2. Registration
Reverse tunneling support is added directly into the
Request by using one of the "rsvd" bits. If a foreign or home
that does not support reverse tunnels receives a request with the 'T
bit set, the Registration Request fails. This results in
registration denial (failure codes are specified in section 3.4).
Home agents SHOULD NOT object to providing reverse tunnel support
because they "SHOULD be able to decapsulate and further
packets addressed to themselves, sent by a mobile node" [1]. In
case of topologically correct reverse tunnels, the packets are
sent by the mobile node as distinguished by its home address
Rather, the outermost (encapsulating) IP source address on
datagrams is the care-of address of the mobile node
In Registration Requests sent by a mobile node, the Time to
field in the IP header MUST be set to 255. This limits a denial
service attack in which malicious hosts send false
Requests (see Section 6).
Montenegro Standards Track [Page 6]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
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
'T' bit
T If the 'T' bit is set, the mobile node asks its
agent to accept a reverse tunnel from the care-
address. Mobile nodes using a foreign agent care-
address ask the foreign agent to reverse-tunnel
packets
3.3. Encapsulating Delivery Style
The Encapsulating Delivery Style Extension MAY be included by
mobile node in registration requests to further specify
tunneling behavior. It is expected to be used only by the
agent. Accordingly, the foreign agent MUST consume this
(that is, it must not relay it to the home agent or include it
replies to the mobile node). As per Section 3.6.1.3 of [1],
mobile node MUST include the Encapsulating Delivery Style
after the Mobile-Home Authentication Extension, and before
Mobile-Foreign Authentication Extension, if present
The Encapsulating Delivery Style Extension MUST NOT be included
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
forward tunnel (that is, IP in IP is assumed unless
otherwise). For more details on the delivery styles, please refer
section 5.
Montenegro Standards Track [Page 7]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Foreign agents SHOULD support the Encapsulating Delivery
Extension
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
130
0
3.4. New Registration Reply
Foreign and home agent registration replies MUST convey if
reverse tunnel request failed. These new reply codes are defined
Service denied by the foreign agent
74 requested reverse tunnel
75 reverse tunnel is mandatory and 'T' bit not
76 mobile node too
79 delivery style not
NOTE: Code 79 has not yet been assigned by IANA
Service denied by the home agent
137 requested reverse tunnel
138 reverse tunnel is mandatory and 'T' bit not
139 requested encapsulation
In response to a Registration Request with the 'T' bit set,
nodes may receive (and MUST accept) code 70 (poorly formed request
from foreign agents and code 134 (poorly formed request) from
agents. However, foreign and home agents that support
tunneling MUST use codes 74 and 137, respectively
In addition to setting the 'T' bit, the mobile node also MAY
the Encapsulating Delivery Style by including the
extension. If a foreign agent does not implement the
Montenegro Standards Track [Page 8]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Delivery Style, it MUST respond to the mobile node with code 79
(delivery style not supported). This also applies if the
agent does not support a requested delivery style that may be
in the future
Absence of the 'T' bit in a Registration Request MAY elicit
with codes 75 and 138 at the foreign agent and the home agent
respectively
Forward and reverse tunnels are symmetric, that is, both are able
use the same tunneling options negotiated at registration.
implies that the home agent MUST deny registrations if an
form of tunneling is requested (code 139). Notice that Mobile IP [1]
already defines the analogous failure code 72 for use by the
agent
4. Changes in Protocol
Unless otherwise specified, behavior specified by Mobile IP [1]
assumed. In particular, if any two entities share a
security association, they MUST use the appropriate
Extension (Mobile-Foreign, Foreign-Home or Mobile-Home
Extension) when exchanging registration protocol datagrams.
admissible authentication extension (for example the Mobile-
Authentication Extension) MUST always be present to
registration messages between a mobile node and its home agent
Reverse tunneling imposes additional protocol processing
on mobile entities. Differences in protocol behavior with respect
Mobile IP [1] are specified in the subsequent sections
4.1. Mobile Node
This section describes how the mobile node handles registrations
request a reverse tunnel
4.1.1. Sending Registration Requests to the Foreign
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.
is meant to limit the reverse tunnel hijacking attack (Section 6).
The mobile node MAY optionally include an Encapsulating
Style Extension
Montenegro Standards Track [Page 9]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.1.2. Receiving Registration Replies from the Foreign
Possible valid responses are
- A registration denial issued by either the home agent or
foreign agent
a. The mobile node follows the error checking guidelines
[1], and depending on the reply code, MAY try modifying
registration request (for example, by eliminating
request for alternate forms of encapsulation or
style), and issuing a new registration
b. Depending on the reply code, the mobile node MAY try
the 'T' bit, eliminating the Encapsulating Delivery
Extension (if one was present), and issuing a
registration. Notice that after doing so the
may succeed, but due to the lack of a reverse tunnel
transfer may not be possible
- The home agent returns a Registration Reply indicating that
service will be provided
In this last case, the mobile node has succeeded in establishing
reverse tunnel between its care-of address and its home agent.
the mobile node is operating with a co-located care-of address,
MAY encapsulate outgoing data such that the destination address
the outer header is the home agent. This ability to
reverse-tunnel packets is discussed further in section 5.4.
If the care-of address belongs to a separate foreign agent,
mobile node MUST employ whatever delivery style was requested (
or Encapsulating) and proceed as specified in section 5.
A successful registration reply is an assurance that both the
agent and the home agent support whatever alternate forms
encapsulation (other than IP in IP) were requested. Accordingly,
mobile node MAY use them at its discretion
4.2. Foreign Agent
This section describes how the foreign agent handles
that request a reverse tunnel
Montenegro Standards Track [Page 10]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.2.1. Receiving Registration Requests from the Mobile
A foreign agent that receives a Registration Request with the 'T'
set processes the packet as specified in the Mobile IP
[1], and determines whether it can accommodate the forward
request. If it cannot, it returns an appropriate code.
particular, if the foreign agent is unable to support the
form of encapsulation it MUST return code 72. If it cannot
the requested form of delivery style it MUST return code 79 (
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
'T' bit not set).
The foreign agent MUST verify that the TTL field of the IP header
set to 255. Otherwise, it MUST reject the registration with code 76
(mobile node too distant). The foreign agent MUST limit the rate
which it sends these registration replies to a maximum of one
second
As a last check, the foreign agent verifies that it can support
reverse tunnel with the same configuration. If it cannot, it
return a Registration Reply denying the request with code 74
(requested reverse tunnel unavailable).
4.2.2. Relaying Registration Requests to the Home
Otherwise, the foreign agent MUST relay the Registration Request
the home agent
Upon receipt of a Registration Reply that satisfies validity checks
the foreign agent MUST update its visitor list, including
that this mobile node has been granted a reverse tunnel and
delivery style expected (section 5).
While this visitor list entry is in effect, the foreign agent
process incoming traffic according to the delivery style,
it and tunnel it from the care-of address to the home agent'
address
4.3. Home Agent
This section describes how the home agent handles registrations
request a reverse tunnel
Montenegro Standards Track [Page 11]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
4.3.1. Receiving Registration Requests from the Foreign
A home agent that receives a Registration Request with the 'T'
set processes the packet as specified in the Mobile IP
[1] and determines whether it can accommodate the forward
request. If it cannot, it returns an appropriate code.
particular, if the home agent is unable to support the requested
of encapsulation it MUST return code 139 (requested
unavailable).
The home agent MAY reject registration requests without the 'T'
set by denying them with code 138 (reverse tunnel is mandatory and '
T' bit not set).
As a last check, the home agent determines whether it can support
reverse tunnel with the same configuration as the forward tunnel.
it cannot, it MUST send back a registration denial with code 137
(requested reverse tunnel unavailable).
Upon receipt of a Registration Reply that satisfies validity checks
the home agent MUST update its mobility bindings list to
that this mobile node has been granted a reverse tunnel and the
of encapsulation expected
4.3.2. Sending Registration Replies to the Foreign
In response to a valid Registration Request, a home agent MUST
a Registration Reply to the mobile node
After a successful registration, the home agent may
encapsulated packets addressed to itself. Decapsulating such
and blindly injecting them into the network is a potential
weakness (section 6.1). Accordingly, the home agent MUST implement
and, by default, SHOULD enable the following check for
packets addressed to itself
The home agent searches for a mobility binding whose care-
address is the source of the outer header, and whose mobile
address is the source of the inner header
If no such binding is found, or if the packet uses an
mechanism that was not negotiated at registration the home agent
silently discard the packet and SHOULD log the event as a
exception
Home agents that terminate tunnels unrelated to Mobile IP (
example, multicast tunnels) MAY turn off the above check, but
practice is discouraged for the aforementioned reasons
Montenegro Standards Track [Page 12]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
While the registration is in effect, a home agent MUST process
valid reverse tunneled packet (as determined by checks like
above) by decapsulating it, recovering the original packet, and
forwarding it on behalf of its sender (the mobile node) to
destination address (the correspondent host).
5. Mobile Node to Foreign Agent Delivery
This section specifies how the mobile node sends its data traffic
the foreign agent. In all cases, the mobile node learns the
agent's link-layer address from the link-layer header in the
advertisement
5.1. Direct Delivery
This delivery mechanism is very simple to implement at the
node, and uses small (non-encapsulated) packets on the link
the mobile node and the foreign agent (potentially a very slow link).
However, it only supports reverse-tunneling of unicast packets,
does not allow selective reverse tunneling (section 5.4).
5.1.1. Packet
The mobile node MUST designate the foreign agent as its
router. Not doing so will not guarantee encapsulation of all
mobile node's outgoing traffic, and defeats the purpose of
reverse tunnel. The foreign agent MUST
- detect packets sent by the mobile node,
- modify its forwarding function to encapsulate them
forwarding
5.1.2. Packet Header Format and
This section shows the format of the packet headers used by
Direct Delivery style. The formats shown assume IP in
encapsulation [2].
Packet format received by the foreign agent (Direct Delivery Style):
IP fields
Source Address = mobile node's home
Destination Address = correspondent host's
Upper Layer
Packet format forwarded by the foreign agent (Direct Delivery Style):
Montenegro Standards Track [Page 13]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
IP fields (encapsulating header):
Source Address = foreign agent's care-of
Destination Address = home agent's
Protocol field: 4 (IP in IP
IP fields (original header):
Source Address = mobile node's home
Destination Address = correspondent host's
Upper Layer
These fields of the encapsulating header MUST be chosen as follows
IP Source
Copied from the Care-of Address field within the
Request
IP Destination
Copied from the Home Agent field within the most
successful Registration Reply
IP Protocol
Default is 4 (IP in IP [2]), but other methods of
MAY be used as negotiated at registration time
5.2. Encapsulating Delivery
This mechanism requires that the mobile node implement encapsulation
and explicitly directs packets at the foreign agent by designating
as the destination address in a new outermost header. Mobile
that wish to send either broadcast or multicast packets MUST use
Encapsulating Delivery Style
5.2.1 Packet
The foreign agent does not modify its forwarding function. Rather
it receives an encapsulated packet and after verifying that it
sent by the mobile node, it
- decapsulates to recover the inner packet
- re-encapsulates, and sends it to the home agent
If a foreign agent receives an un-encapsulated packet from a
node which had explicitly requested the Encapsulated Delivery Style
then the foreign agent MUST NOT reverse tunnel such a packet
rather MUST forward it using standard, IP routing mechanisms
Montenegro Standards Track [Page 14]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
5.2.2. Packet Header Format and
This section shows the format of the packet headers used by
Encapsulating Delivery style. The formats shown assume IP in
encapsulation [2].
Packet format received by the foreign agent (Encapsulating
Style):
IP fields (encapsulating header):
Source Address = mobile node's home
Destination Address = foreign agent's
Protocol field: 4 (IP in IP
IP fields (original header):
Source Address = mobile node's home
Destination Address = correspondent host's
Upper Layer
The fields of the encapsulating IP header MUST be chosen as follows
IP Source
The mobile node's home address
IP Destination
The address of the agent as learned from the IP source
of the agent's most recent successful registration reply
IP Protocol
Default is 4 (IP in IP [2]), but other methods of
MAY be used as negotiated at registration time
Packet format forwarded by the foreign agent (Encapsulating
Style):
IP fields (encapsulating header):
Source Address = foreign agent's care-of
Destination Address = home agent's
Protocol field: 4 (IP in IP
IP fields (original header):
Source Address = mobile node's home
Destination Address = correspondent host's
Upper Layer
These fields of the encapsulating IP header MUST be chosen
follows
Montenegro Standards Track [Page 15]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
IP Source
Copied from the Care-of Address field within the
Request
IP Destination
Copied from the Home Agent field within the most
successful Registration Reply
IP Protocol
Default is 4 (IP in IP [2]), but other methods of
MAY be used as negotiated at registration time
5.3. Support for Broadcast and Multicast
If a mobile node is operating with a co-located care-of address
broadcast and multicast datagrams are handled according to
4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using
foreign agent care-of address MAY have their broadcast and
datagrams reverse-tunneled by the foreign agent. However, any
nodes doing so MUST use the encapsulating delivery style
This delivers the datagram only to the foreign agent. The
decapsulates it and then processes it as any other packet from
mobile node, namely, by reverse tunneling it to the home agent
5.4. Selective Reverse
Packets destined to local resources (for example, a nearby printer
might be unaffected by ingress filtering. A mobile node with a co
located care-of address MAY optimize delivery of these packets by
reverse tunneling them. On the other hand, a mobile node using
foreign agent care-of address MAY use this selective
tunneling capability by requesting the Encapsulating Delivery Style
and following these guidelines
Packets NOT meant to be reversed tunneled
Sent using the Direct Delivery style. The foreign agent
process these packets as regular traffic: they MAY
forwarded but MUST NOT be reverse tunneled to the home agent
Montenegro Standards Track [Page 16]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Packets meant to be reverse tunneled
Sent using the Encapsulating Delivery style. The foreign
MUST process these packets as specified in section 5.2:
MUST be reverse tunneled to the home agent
6. Security
The extensions outlined in this document are subject to the
considerations outlined in the Mobile IP specification [1].
Essentially, creation of both forward and reverse tunnels involves
authentication procedure, which reduces the risk for attack
6.1. Reverse-tunnel Hijacking and Denial-of-Service
Once the tunnel is set up, a malicious node could hijack it to
packets into the network. Reverse tunnels might exacerbate
problem, because upon reaching the tunnel exit point packets
forwarded beyond the local network. This concern is also present
the Mobile IP specification, as it already dictates the use
reverse tunnels for certain applications
Unauthenticated exchanges involving the foreign agent allow
malicious node to pose as a valid mobile node and re-direct
existing reverse tunnel to another home agent, perhaps
malicious node. The best way to protect against these attacks is
employing the Mobile-Foreign and Foreign-Home
Extensions defined in [1].
If the necessary mobility security associations are not available
this document introduces a mechanism to reduce the range
effectiveness of the attacks. The mobile node MUST set to 255
TTL value in the IP headers of Registration Requests sent to
foreign agent. This prevents malicious nodes more than one hop
from posing as valid mobile nodes. Additional codes for use
registration denials make those attacks that do occur easier
track
With the goal of further reducing the attacks the Mobile IP
Group considered other mechanisms involving the use
unauthenticated state. However, these introduce the possibilities
denial-of-service attacks. The consensus was that this was too
of a trade-off for mechanisms that guarantee no more than weak (non
cryptographic) protection against attacks
Montenegro Standards Track [Page 17]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
6.2. Ingress
There has been some concern regarding the long-term effectiveness
reverse-tunneling in the presence of ingress filtering.
conjecture is that network administrators will target reverse
tunneled packets (IP in IP encapsulated packets) for filtering.
ingress filtering recommendation spells out why this is not the
[8]:
Tracking the source of an attack is simplified when the source
more likely to be "valid."
6.3. Reverse Tunneling for Disparate Address
There are security implications involved with the foreign agent'
using link-layer information to select the proper reverse tunnel
mobile node packets (section A.3). Unauthenticated link-layers
a malicious mobile node to misuse another's existing reverse tunnel
and inject packets into the network
For this solution to be viable, the link-layer MUST
authenticate traffic received by the foreign agent from the
nodes. Unauthenticated link-layer technologies (for example
ethernet) are not recommended to implement disparate address support
7. IANA
The Encapsulating Delivery Style extension defined in section 3.3
a Mobile IP registration extension as defined in [1]. IANA
the value of 130 for this purpose at the time of the publication
RFC 2344.
The Code values defined in section 3.4 are error codes as defined
[1]. They correspond to error values associated with rejection
the home and foreign agents. At the time of the publication of
2344, IANA assigned codes 74-76 for the foreign agent rejections
codes 137-139 for the home agent rejections. The code for '
style not supported' has been assigned a value of 79 by the IANA
this purpose
8.
The encapsulating style of delivery was proposed by Charlie Perkins
Jim Solomon has been instrumental in shaping this document into
present form. Thanks to Samita Chakrabarti for helpful comments
disparate address space support, and for most of the text in
A.4.
Montenegro Standards Track [Page 18]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
[1] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[2] Perkins, C., "IP Encapsulation within IP", RFC 2003,
1996.
[3] Computer Emergency Response Team (CERT), "IP Spoofing
and Hijacked Terminal Connections", CA-95:01, January 1995.
Available via anonymous ftp from info.cert.org
/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:
Denial of Service Attacks which employ IP Source
Spoofing", RFC 2267, January 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate
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",
2486, January 1999.
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J.
E. Lear, "Address Allocation for Private Internets", BCP 5,
1918, February 1996.
[13] Dommety, G., "Key and Sequence Number Extensions to GRE",
2890, August 2000.
Montenegro Standards Track [Page 19]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Editor and Chair
Questions about this document may be directed at
Gabriel E.
Sun
Laboratories,
29, chemin du Vieux
38240
Phone: +33 476 18 80 45
EMail: gab@sun.
The working group can be contacted via the current chairs
Basavaraj
Nokia
6000 Connection
Irving, TX 75039
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Raj.Patil@nokia.
Phil
1501 West Shure
Arlington Heights, IL 60004
Phone: +1 847-632-3148
EMail: QA3445@email.mot.
Montenegro Standards Track [Page 20]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Appendix A: Disparate Address Space
Mobile IP [1] assumes that all the entities involved (
node, foreign agent and home agent) have addresses within
same globally routable address space. In many
scenarios, when a mobile node leaves its home network it
wander into a region where its home address is not routable
known by the local routing fabric. Similarly, the IP
of the foreign agent and the home agent may belong to
address spaces, which precludes their exchanging
protocol messages directly. These issues are
particularly if the entities involved use addresses from
ranges specified in RFC1918 [12] to support private networks
Accurately speaking, the use of private addresses is not
only cause. It may, in fact, be the most common, but the root
the problem lies in the use of disparate address spaces.
example, corporations often have several properly
address ranges. They typically advertise reachability to only
subset of those ranges, leaving the others for use
within the corporate network. Since these ranges are
routable in the general Internet, their use leads to the
problems encountered with "private" addresses, even though
are not taken from the ranges specified in RFC1918.
Even if the mobile node, home agent and foreign agent all
within the same address space, problems may arise if
correspondent node does not. However, this problem is
specific to Mobile IP, and is beyond the scope of
document. The next section limits even further the scope of
issues relevant to this document. A subsequent section
how reverse tunneling may be used to tackle them
A.1. Scope of the Reverse Tunneling
Reverse tunneling (as defined in this document) may be used
cope with disparate address spaces, within the
constraints
- There are no provisions to solve the case in which
correspondent node and the mobile node are in
address spaces. This limits the scope of the problem
only those issues specific to Mobile IP
- The foreign agent and the home agent are directly
to each other by virtue of residing in the same
space. This limits the scope of the problem to only
simplest of cases. This also implies that the
Montenegro Standards Track [Page 21]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
protocol itself has a direct path between the
agent and the home agent, and, in this respect, is
affected by disparate address spaces. This
also applies to mobile nodes operating with a co-
care-of address. In this case, reverse tunneling is
complete and elegant solution
- There are no additional protocol elements beyond
defined by Mobile IP [1] and reverse tunneling.
particular, additional extensions to the
requests or replies, or additional bits in
header--although potentially useful--are outside the
of this document
In spite of the limitations, reverse tunneling may be used
solve the most common issues. The range of problems that can
solved are best understood by looking at some simple diagrams
Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS
Mc Fa Fb Hb Hc
[MN]-----------------[FA]----------------[HA]---------------[Y
Addr space A Addr space B Addr space
In this diagram, there are three disparate address spaces: A, B
C. The home agent (HA) has one address each on address spaces B
C, and the foreign agent (FA), on address spaces A and B. The
node's (MN) has a permanent address, Mc, within address space C
In the most common scenario both A and C are "private"
spaces, and B is the public Internet
Suppose MN sends a packet to correspondent node (Y) in its
network. Presumably, MN has no difficulties delivering this
to the FA, because it does so using layer 2 mechanisms. Somehow,
FA must realize that this packet must be reverse tunneled, and
must fetch the proper binding to do so. Possible mechanisms
outlined in section A.3.
However, once the packet is in address space B it becomes non
routable. Note that ingress filtering only exacerbates the problem
because it adds a requirement of topological significance to
source IP address in addition to the that of the destination address
As Mobile IP matures, others entities may be defined (for example
AAA servers). Their addition places even more requirements on
address spaces in use
Montenegro Standards Track [Page 22]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Reverse tunneling adds a topologically significant IP header to
packet (source IP address of Fb, destination of Hb) during
transit within address space B. Assuming IP in IP
(although others, like GRE are also possible), this is what
packet looks like
Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO
+-----------------+
| +-------+|
| Fb->Hb | Mc->Yc||
| +-------+|
+--------+--------+
HA receives this packet, recovers the original packet, and since
is cognizant of address space C, delivers it to the
interface
Of course, for this to happen, the care-of address registered by
MN is not the usual Fa, but Fb. How this happens is outside
scope of this document. Some possible mechanisms are
- FA recognizes mobile nodes whose addresses fall within
private address ranges specified by RFC1918. In this case,
foreign agent could force the use of Fb as the care-of address
perhaps by rejecting the initial registration request with
appropriate error message and supplemental information
- FA could be configured to always advertise Fb as long as H->
and Fb->H are guaranteed to be valid forward and
tunnels, respectively, for all values of H. Here, H is
address of any home agent whose mobile nodes may register
FA
- FA could indicate that it supports disparate address spaces
a currently undefined 'P' bit in its advertisements, and
indication of the relevant address space for any or all of
care-of addressed by including an NAI [11] or a realm
(perhaps a variant of the NAI). Alternatively, mobile nodes
configured could solicit the NAI or realm indicator
in response to advertisements with the 'P' bit set
Additionally, the mobile node needs to supply the appropriate
for its home agent: Hb instead of the usual Hc. How this happens
outside the scope of this document. Some possible mechanisms are
- This determination could be triggered in response to using
foreign agent's Fb as the care-of address
Montenegro Standards Track [Page 23]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
- The mobile node could always use Hb as its home agent address
specially (1) if Hb is routable within address space C, or (2)
if MN is certain never to be at home (in some configurations
the mobile nodes are always roaming).
- The mobile node could be configured with different home
addresses and their corresponding address space (
indicated via an NAI [11] or a variant of it).
Another major issue introduced by private addresses is that of two
more mobile nodes with the same numeric IP address
Figure A3: MOBILE NODES WITH CONFLICTING
Mc=M H1b H1
[MN1]-------+ +----[HA1]----+---------
| | |
| | | space
Address | | Address +----------
Space Fa-[FA]-Fb
A | | B +---------
| | |
| | | space
[MN2]-------+ +----[HA2]----+---------
Md=M H2b H2
Suppose there are two address spaces A and B, and a foreign
(FA) with interfaces on both. There are two home agents (HA1
HA2) in address space B, with addresses H1b and H2b, respectively
Each of the home agents has an interface in a private address
in addition to address space B: HA1 has H1c on C, and HA2 has H2d
D. MN1 and MN2 are two mobile nodes with home addresses Mc and Md
corresponding to address space C and D, respectively
If Mc and Md are private addresses as defined in RFC1918, they may
numerically equivalent (both equal to M). Because of this,
foreign agent can no longer rely on only the mobile node's
address to disambiguate amongst its different bindings
A.2. Terminating Forward Tunnels at the Foreign
In figure A1, suppose the correspondent node Y sends a packet to
mobile node at address Mc. The packet is intercepted by the
agent at Hc and tunneled towards the mobile node via address Fb
Montenegro Standards Track [Page 24]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Once the packet reaches FA (via address Fb), the foreign agent
identify which of its registered mobile nodes is the
destination for the internal packet. In order to do so, it needs
identify the proper binding via a tuple guaranteed to be unique
all of its mobile nodes
The unique tuple sufficient for demultiplexing IP in IP
[IPIP] (protocol 4) is
- destination IP address of the encapsulated (internal)
This is mobile node MN's home address (Mc in the
example). At first glance, it seems like this is unique
all mobile nodes, but as mentioned above, with
addresses another mobile may have an address Md
equivalent to Mc
- source IP address of the external
This, the remote end of the tunnel, is Hb in the above example
- destination IP address of the external
This, the local end of the tunnel, is Fb in the above example
The three values above are learned from a successful registration
are the mobile node's home address, the home agent's address and
care-of address. Thus, it is possible to identify the right binding
Once FA identifies the ultimate destination of the packet, Mc,
delivers the internal packet using link layer mechanisms
GRE packets [10] (protocol 47) are only handled if their
Type field has a value of 0x800 (other values are outside the
of this document), and are demultiplexed based on the same tuple
IP in IP packets. In GRE terminology, the tuple is
- destination IP address of the payload (internal)
- source IP address of the delivery (external)
- destination IP address of the delivery (external)
Notice that the Routing, Sequence Number, Strict Source Route and
fields have been deprecated from GRE [10]. However, a
document specifies their use [13].
Montenegro Standards Track [Page 25]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
The above tuples work for IP-in-IP or GRE encapsulation, and
that the inner packet is in the clear. Encapsulations which
the inner packet header are outside the scope of this document
A.3. Initiating Reverse Tunnels at the Foreign
In figure A3, suppose mobile node M1 sends a packet to
correspondent node in its home address space, C, and mobile node M
sends a packet to a correspondent node in its home address space, D
At FA, the source addresses for both packets will be seen as M,
this is not sufficient information. The unique tuple required
identify the proper binding is
- link-layer information related to the
This may be in the form of a MAC address, a PPP session (
incoming interface) or channel coding for a digital
service. Device ID's can also be used in this context
- source IP address of the IP header
As was pointed out, this by itself is not guaranteed to
unique
This information must be established and recorded at
time. The above items are sufficient for the foreign agent to
the proper binding to use. This, in turn, produces the address
the home agent, and the reverse tunneling options negotiated
the registration process. The foreign agent can now proceed
reverse tunneling
A.4. Limited Private Address
The Limited Private Address Scenario (LPAS) has received
attention from the cellular wireless industry, so it is useful
define it and to clarify what its requirements are
LPAS is a subset of the disparate address space scenario discussed
this appendix. This section explains how LPAS could be
given the current state of the Mobile IP specifications
Montenegro Standards Track [Page 26]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Figure A4: EXAMPLE PRIVATE ADDRESS
10.10.1.2
+----+ IF1=COA1+-------+ HAA2 +-----+
| MN1|------------------------| FA |---------| HA2 |
+----+ +------------| | +-----+
| IF2=COA2+-------+
+---+ |
| |
+-----+ |
| MN2 | |
+-----+ |
10.10.1.2 |
| HAA
+------+
| HA1 |
+------+
The above figure presents a very simple scenario in which
addresses are used. Here, "private addresses" are strictly
defined in RFC 1918 [12]. In this deployment scenario, the
entities that have private addresses are the mobile nodes.
agent and home agent addresses are publicly routable on the
Internet. More specifically, the care-of addresses advertised by
foreign agents (COA1 and COA2 in Figure A4) and the home
addresses used by mobile nodes in registration requests (HAA1
HAA2 in Figure A4) are publicly routable on the general Internet.
a consequence, any Mobile IP tunnels can be established between
home agent home address and any foreign agent care-of address
Also, note that two different mobile nodes (MN1 and MN2) with
same private address (10.10.1.2) are visiting the same foreign
FA. This is supported as long as MN1 and MN2 are serviced
different home agents. Hence, from any given home agent'
perspective, each mobile node has a unique IP address, even if
happens to be a private address as per RFC 1918.
Operation in the presence of route optimization [4] is outside
scope of this document
Requirements for the above private address scenario
Mobile node requirements
Mobile nodes intending to use private addresses with Mobile
MUST set the 'T' bit and employ reverse tunneling.
node's private addresses within a given address space MUST
unique. Thus two mobile nodes belonging to a single home
Montenegro Standards Track [Page 27]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
cannot have the same private addresses. Thus, when
or sending tunneled traffic for a mobile node, the
endpoints are used to disambiguate amongst conflicting
node addresses
If the mobile node happens to register with multiple
agents simultaneously through the same foreign agent,
must be some link-layer information that is distinct for
mobile node. If no such distinct link-layer information
available, the mobile nodes MUST use unique address
Foreign agent requirements
All advertising interfaces of the foreign agent MUST
publicly routable care-of address. Thus, a mobile node with
private address visits the foreign agent only in its
routable network
Foreign agents MUST support reverse tunneling in order
support private addressed mobile nodes. If a foreign
receives a registration request from a mobile node with
private address, and the mobile node has not set the 'T' bit
the foreign agent SHOULD reject it
When delivering packets to or receiving packets from
nodes, foreign agents MUST disambiguate among mobile node
conflicting private addresses by using link-layer
as mentioned previously (Appendix section A.2 and A.3).
foreign agent in absence of route optimization, should
sure that two mobile nodes visiting the same foreign
corresponds with each other through their respective
agents
If a foreign agent supports reverse tunneling, then it
support the simple scenario of private address
described in this section
Home agent requirements
Any home agent address used by mobile nodes in
request MUST be a publicly routable address. Home agents
not support overlapping private home addresses, thus
private home address of a mobile node registered with a
agent is unique. When the 'T' bit is set in the
request from the mobile node, the home agent MUST recognize
accept registration request from mobile nodes with
Montenegro Standards Track [Page 28]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
addresses. Also, the home agent SHOULD be able to
private addresses out of its address pool to mobile nodes
use as home addresses. This does not contravene home
processing in section 3.8 of [1].
Appendix B: Changes from RFC2344
This section lists the changes with respect to the previous
of this document (RFC2344).
- Added Appendix A on support for Disparate Addresses spaces
private addresses
- Added the corresponding section (6.3) under '
Considerations'.
- Made Encapsulating Delivery Support optional by demoting
a MUST to a should. This also required defining a new
code 79 (assigned by IANA).
- Mentioned the possibility of an admissible
extension which may be different from the Mobile-
authentication extension
- An IANA considerations section was added
Montenegro Standards Track [Page 29]
RFC 3024 Reverse Tunneling for Mobile IP, revised January 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Montenegro Standards Track [Page 30]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
