A.3. Initiating Reverse Tunnels at the Foreign Agent
In figure A3, suppose 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 addresses for both packets will be seen as M, thus
this is not sufficient information. The unique tuple required to
identify the proper binding is:
- link-layer information related to the MN
This may be in the form of a MAC address, a PPP session (or
incoming interface) or channel coding for a digital cellular
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 be
unique.
This information must be established and recorded at registration
time. The above items are sufficient for the foreign agent to select
the proper binding to use. This, in turn, produces the address of
the home agent, and the reverse tunneling options negotiated during
the registration process. The foreign agent can now proceed with
reverse tunneling.
A.4. Limited Private Address Scenario
The Limited Private Address Scenario (LPAS) has received much
attention from the cellular wireless industry, so it is useful to
define it and to clarify what its requirements are.
LPAS is a subset of the disparate address space scenario discussed in
this appendix. This section explains how LPAS could be deployed
given the current state of the Mobile IP specifications.
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 |
+------+
The above figure presents a very simple scenario in which private
addresses are used. Here, "private addresses" are strictly those
defined in RFC1918 [12]. In this deployment scenario, the only
entities that have private addresses are the mobile nodes. Foreign
agent and home agent addresses are publicly routable on the general
Internet. More specifically, the care-of addresses advertised by the
foreign agents (COA1 and COA2 in Figure A4) and the home agent
addresses used by mobile nodes in registration requests (HAA1 and
HAA2 in Figure A4) are publicly routable on the general Internet. As
a consequence, any Mobile IP tunnels can be established between any
home agent home address and any foreign agent care-of address.
Also, note that two different mobile nodes (MN1 and MN2) with the
same private address (10.10.1.2) are visiting the same foreign agent
FA. This is supported as long as MN1 and MN2 are serviced by
different home agents. Hence, from any given home agent's
perspective, each mobile node has a unique IP address, even if it
happens to be a private address as per RFC1918.
Operation in the presence of route optimization [4] is outside the
scope of this document.
Requirements for the above private address scenario:
Mobile node requirements:
Mobile nodes intending to use private addresses with Mobile IP
MUST set the 'T' bit and employ reverse tunneling. Mobile
node's private addresses within a given address space MUST be
unique. Thus two mobile nodes belonging to a single home agent
cannot have the same private addresses. Thus, when receiving
or sending tunneled traffic for a mobile node, the tunnel
endpoints are used to disambiguate amongst conflicting mobile
node addresses.
If the mobile node happens to register with multiple home
agents simultaneously through the same foreign agent, there
must be some link-layer information that is distinct for each
mobile node. 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. Thus, a mobile node with a
private address visits the foreign agent only in its publicly
routable network.
Foreign agents MUST support reverse tunneling in order to
support private addressed mobile nodes. If a foreign agent
receives a registration request from a mobile node with a
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 mobile
nodes, foreign agents MUST disambiguate among mobile node with
conflicting private addresses by using link-layer information
as mentioned previously (Appendix section A.2 and A.3). A
foreign agent in absence of route optimization, should make
sure that two mobile nodes visiting the same foreign agent
corresponds with each other through their respective home
agents.
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 used by mobile nodes in registration
request MUST be a publicly routable address. Home agents will
not support overlapping private home addresses, thus 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 request 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 does not contravene home agent
processing in section 3.8 of [1].
Appendix B: Changes from RFC2344
This section lists the changes with respect 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 required 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
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
Funding for the RFCEditor function is currently provided by the
Internet Society.