rfc3024.txt

RFC 的详细文档！

   Once the packet reaches FA (via address Fb), the foreign agent must
   identify which of its registered mobile nodes is the ultimate
   destination for the internal packet.  In order to do so, it needs to
   identify the proper binding via a tuple guaranteed to be unique among
   all of its mobile nodes.

   The unique tuple sufficient for demultiplexing 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 above
         example).  At first glance, it seems like this is unique among
         all mobile nodes, but as mentioned above, with private
         addresses another mobile may have an address Md numerically
         equivalent to Mc.

      -  source IP address of the external header

         This, the remote end of the tunnel, is Hb in the above example.

      -  destination IP address of the external header

         This, the local end of the tunnel, is Fb in the above example.

   The three values above are learned from a successful registration and
   are the mobile node's home address, the home agent's address and the
   care-of address.  Thus, it is possible to identify the right binding.
   Once FA identifies the ultimate destination of the packet, Mc, it
   delivers the internal packet using link layer mechanisms.

   GRE packets [10] (protocol 47) are only handled if their Protocol
   Type field has a value of 0x800 (other values are outside the scope
   of this document), and are demultiplexed based on the same tuple as
   IP in IP packets.  In GRE terminology, the 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

   Notice that the Routing, Sequence Number, Strict Source Route and Key
   fields have been deprecated from GRE [10].  However, a separate
   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 assume
   that the inner packet is in the clear.  Encapsulations which encrypt
   the inner packet header are outside the scope of this document.

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.










Montenegro                  Standards Track                    [Page 26]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


           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 RFC 1918 [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 RFC 1918.

   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



Montenegro                  Standards Track                    [Page 27]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


         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





Montenegro                  Standards Track                    [Page 28]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


         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.


























Montenegro                  Standards Track                    [Page 29]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


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 RFC Editor function is currently provided by the
   Internet Society.