rfc3024.txt

最新的RFC

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


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.









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


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: [phone]
   EMail: [e-mail]


   The working group can be contacted via the current chairs:

   Basavaraj Patil
   Nokia Networks
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  [phone]
   Fax :   [phone]
   EMail:  [e-mail]


   Phil Roberts
   Motorola
   1501 West Shure Drive
   Arlington Heights, IL 60004
   USA

   Phone:  [phone]
   EMail:  [e-mail]















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


Appendix 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 many deployment
   scenarios, when a mobile node leaves its home network it may
   wander into a region where its home address is not 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 precludes their exchanging registration
   protocol messages directly.  These issues are possible
   particularly if the entities involved use addresses from the
   ranges specified in RFC1918 [12] to support private networks.

   Accurately speaking, the use of private addresses is not the
   only cause.  It may, in fact, be the most common, but the root of
   the problem lies in the use of disparate address spaces.  For
   example, corporations often have several properly allocated
   address ranges.  They typically advertise reachability to only a
   subset of those ranges, leaving the others for use exclusively
   within the corporate network.  Since these ranges are not
   routable in the general Internet, their use leads to the same
   problems encountered with "private" addresses, even though they
   are not taken from the ranges specified in RFC1918.

   Even if the mobile node, home agent and foreign agent all reside
   within the same address space, problems may arise if the
   correspondent node does not.  However, this problem is not
   specific to Mobile IP, and is beyond the scope of this
   document.  The next section limits even further the scope of the
   issues relevant to this document.  A subsequent section explains
   how reverse tunneling may be used to tackle them.

A.1. Scope of the Reverse Tunneling Solution

   Reverse tunneling (as defined in this document) may be used to
   cope with disparate address spaces, within the following
   constraints:

      -  There are no provisions to solve the case in which the
         correspondent node and the mobile node are in disparate
         address spaces.  This limits the scope of the problem to
         only those issues specific to Mobile IP.

      -  The foreign agent and the home agent are directly reachable
         to each other by virtue of residing in the same address
         space.  This limits the scope of the problem to only the
         simplest of cases.  This also implies that the registration



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


         protocol itself has a direct path between the foreign
         agent and the home agent, and, in this respect, is not
         affected by disparate address spaces.  This restriction
         also applies to mobile nodes operating with a co-located
         care-of address.  In this case, reverse tunneling is a
         complete and elegant solution.

      -  There are no additional protocol elements beyond those
         defined by Mobile IP [1] and reverse tunneling.  In
         particular, additional extensions to the registration
         requests or replies, or additional bits in the
         header--although potentially useful--are outside the scope
         of this document.

   In spite of the limitations, reverse tunneling may be used to
   solve the most common issues.  The range of problems that can be
   solved are best understood by looking at 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 C

   In this diagram, there are three disparate address spaces:  A, B and
   C.  The home agent (HA) has one address each on address spaces B and
   C, and the foreign agent (FA), on address spaces A and B.  The mobile
   node's (MN) has a permanent address, Mc, within address space C.

   In the most common scenario both A and C are "private" address
   spaces, and B is the public Internet.

   Suppose MN sends a packet to correspondent node (Y) in its home
   network.  Presumably, MN has no difficulties delivering this packet
   to the FA, because it does so using layer 2 mechanisms.  Somehow, the
   FA must realize that this packet must be reverse tunneled, and it
   must fetch the proper binding to do so.  Possible mechanisms are
   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 the
   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 the
   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 the
   packet (source IP address of Fb, destination of Hb) during its
   transit within address space B.  Assuming IP in IP encapsulation
   (although others, like GRE are also possible), this is what the
   packet looks like:

      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
   is cognizant of address space C, delivers it to the appropriate
   interface.

   Of course, for this to happen, the care-of address registered by the
   MN is not the usual Fa, but Fb.  How this happens is outside the
   scope of this document.  Some possible mechanisms are:

      -  FA recognizes mobile nodes whose addresses fall within the
         private address ranges specified by RFC1918.  In this case, the
         foreign agent could force the use of Fb as the care-of address,
         perhaps by rejecting the initial registration request with an
         appropriate error message and supplemental information.

      -  FA could be configured to always advertise Fb as long as H->Fb
         and Fb->H are guaranteed to be valid forward and reverse
         tunnels, respectively, for all values 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 via
         a currently undefined 'P' bit in its advertisements, and an
         indication of the relevant address space for any or all of its
         care-of addressed by including an NAI [11] or a realm indicator
         (perhaps a variant of the NAI).  Alternatively, mobile nodes so
         configured could solicit the NAI or realm indicator information
         in response to advertisements with the 'P' bit set.

   Additionally, the mobile node needs to supply the appropriate address
   for its home agent: Hb instead of the usual Hc.  How this happens is
   outside the scope of this document.  Some possible mechanisms are:

      -  This determination could be triggered in response to using the
         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 agent
         addresses and their corresponding address space (perhaps
         indicated via an NAI [11] or a variant of it).

   Another major issue introduced by private addresses is that of 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     H2d

   Suppose 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, respectively.
   Each of the home agents has an interface in a private address space
   in addition to address space B: HA1 has H1c on C, and HA2 has H2d on
   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 be
   numerically equivalent (both equal to M).  Because of this, the
   foreign agent can no longer rely on only the mobile node's home
   address to disambiguate amongst its different bindings.

A.2. Terminating Forward Tunnels at the Foreign Agent

   In figure A1, suppose the correspondent node Y sends a packet to the
   mobile node at address Mc.  The packet is intercepted by the home
   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