[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                W. T. Teo
INTERNET DRAFT                                       National University
                                                            of Singapore
                                                                   Y. Li
                                                      Bay Networks, Inc.

        Mobile IP extension for Private Internets Support (MPN)

Status of This Memo

   This document is a submission to the Mobile-IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the mobile-ip@smallworks.com mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe),
   ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This memo specifies enhancements to Mobile IP that allow IP mobility
   support across routing realms. The protocol allows a mobile node to
   have the same home network connectivity, regardless of its current
   routing realm network point of attachment. It is designed to work in
   the presence of address collisions and network address translations.
   Private networks connected to the public Internet can extend IP
   mobility support to cover the public Internet and other private
   networks. Movement from a private home network to the public foreign
   network, from a private home network to another private foreign
   network or from the public home network to a private foreign network
   are possible under the MPN framework.






Teo and Li                  Expires May 1999                    [Page 1]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


1. Introduction

   Mobile IP [1] allows a node to move from its home network, the IP
   subnet indicated by its home address. When away from the home
   network, datagrams destined to the node are tunnelled to a care-of
   address in the visited network. This assumes a node's address is
   sufficient to identify the node's location in the Internet and IP
   unicast datagrams can be routed solely based on the destination
   address in the datagram header. This is only true when the node's
   mobility is constrained within a common routing realm. For example,
   this routing realm could be the global public Internet or a localized
   private network.

   These assumptions are not valid beyond the mobile node's routing
   realm. Therefore, Mobile IP cannot ensure mobility across different
   routing realms. MPN is an extension to the Mobile IP base protocol
   that enables this mobility support spanning multiple routing realms.

1.1 MPN Framework

                        Global Public Internet
            .              ________________              .
            . +------+    (                )    +------+ . Private
            . |Public|   (         VPN      )   |Public| . Network
            .-|Agent |--(          Tunnel /==)--|Agent |-.   c
     Private. +------+   (        /======/  )   +------+ ..........
     Network. +------+  / (______/_________)
        A   . |Public| /         |
            .-|Agent |-          |
            . +------+    +------------+
    .........             |Public Agent|
                          +------------+
                                 |
                      ...................
                      .Private Network B.
                      .                 .

   In MPN, the central routing realm is the global public Internet. All
   other routing realms (private routing realms) depend on this global
   routing infrastructure for wide area mobility.

   Unlike the central routing realm which has numerous public networks,
   each private network constitutes an independent routing realm.
   Examples of private networks are intranets, extranets and virtual
   private networks.

   These private routing realms are globally identified in the public
   Internet by their public agents. Public agents are the private



Teo and Li                  Expires May 1999                    [Page 2]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   networks link to the public Internet. For example, the public agent
   may be a border router or a Internet service provider network point
   of presence.

   An independent private network (e.g. private network A) may have more
   than one link to the public Internet, i.e. there are more than one
   public agents.

   A private routing realm may consists of multiple networks physically
   located in separate sites. For example, private network B and private
   network C may form a virtual private network. There will be a VPN
   tunnel established between the two networks, to route traffic between
   the two different physical sites. This VPN tunnel is transparent in
   the MPN framework. For such network configurations, in the context of
   MPN, the networks represent a single private routing realm. There is
   no cross routing realm movement if a node moves to another physical
   site within such a network.

   All the public agents in a private routing realm should be advertised
   in the public agents advertisement extension [ref Section 3.1]. In
   MPN, public agents provide the tunnel routing required by visiting
   mobile nodes. The public agents' addresses are also used in movement
   detection. Mobile nodes from a private network are configured with
   the public agents' addresses in their routing realm. These addresses
   are used to determine the mobile node's current routing realm.

1.2 Addressing Concerns

   IP addresses are topologically significant and unique only within a
   routing realm. By enabling mobility across multiple routing realms,
   there may be address collisions due to overlapping address space in
   the visited routing realm.

   MPN is designed to work in the presence address collisions and solve
   the problem of tunneling across independent routing realms. However,
   MPN is not intended to provide communication across routing realms.
   The determination of the end host and the routing mechanisms for end-
   to-end communication in the home routing realm is independent of MPN.
   There are other protocols that provide communication across routing
   realms such as NAT [5] and PAID [7]. Their operation is transparent
   to MPN.

1.3 Mobile Node Concerns

   When a mobile node enters a foreign routing realm and its visited
   network link is broadcast-orientated (such as Ethernet), the mobile
   node MUST used a co-located care-of address, instead of a local
   foreign agent care-of address. This is to avoid address ambiguity on



Teo and Li                  Expires May 1999                    [Page 3]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   the broadcast link due to home address collisions.

   A private mobile node should use a co-located care-of address (if
   possible) even when the foreign routing realm visited network link is
   not broadcast-orientated. As the local foreign agent is not the
   forward or reverse tunnel endpoint, end-to-end encryption can be
   supported.

1.4 Mobility Support

   The mobility support in Mobile IP allows a mobile node to be always
   identified by its home address, when it roams from its home network.
   The mobile node's reachability by other nodes and its accessibility
   to other nodes is not explicit in Mobile IP. This is because a common
   routing fabric is assumed.

   In MPN, mobility support is more accurately defined as maintaining
   the same home network connectivity. The mobile node should have
   access to all nodes that is reachable within its home network, even
   when it migrates into another routing realm. Similarly, all nodes
   that can reach the mobile node within its home network, should be
   able to reach the mobile node when it moves to another routing realm
   (if MPN mobility support is available in the visited network).

1.5 Design Goals

   The design goals of MPN are:

   1. The MPN protocol shall require minimum changes and support all
      functions of the Mobile IP base protocol.

   2. The MPN protocol must not affect the operation of Mobile IP
      mobile nodes and mobility agents.

   2. The MPN protocol shall be migratory. It will enable the upgrading
      of a private network in phases while maintaining backward
      compatibility with a basic MPN deployment.

1.6 Protocol Requirements

   No protocol enhancements are required for public agents in a basic
   MPN deployment. However, there are security risks involved when
   permitting unrestricted tunneling into a private network, for a basic
   MPN deployment. The reverse tunneling is required in MPN to maintain
   home network connectivity.

1.7 New Architectural Entity




Teo and Li                  Expires May 1999                    [Page 4]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   Public Agent

         A router or firewall that connects a private network to the
         global public Internet [ref Section 1.1]. A public agent may be
         located at the private network's border or at the private
         network's ISP. The public agent MUST have a public IP address,
         which is reachable from the global public Internet. All nodes
         within the private network MUST be able to reach the public
         agent using this public IP address. The public agent MUST be
         able to route to all local home agents and care-of addresses
         within the private network.

1.8 Terminology

   Unless otherwise specified, the document adopts all the terminology
   defined in "IP Mobility Support" [1] [2].

   This document introduces the following terms:

   Private Network

         A network separated from the global public Internet with access
         restrictions. A private network typically assigns nodes private
         addresses specified in RFC 1918 [8] and the addresses may not
         be routable by the general public Internet. For this document,
         private networks only refer to private networks connected to
         the global public Internet and not physically isolated
         networks.

   Private Mobile Node

         A mobile node whose home network is in a Private Network.

   Public Mobile Node

         A mobile node whose home network is in the global public
         Internet.

   Routing Realm

         The global public Internet and each private network constitute
         individual routing realms [ref Section 1.1] This document
         operates on the paradigm that interconnecting routing realms
         may have overlapping address space but within a routing realm,
         all IP addresses are unique and unicast datagrams are routable
         solely based on the destination address in the datagram header.

   Home Routing Realm



Teo and Li                  Expires May 1999                    [Page 5]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


         A routing realm which the mobile node's home network is
         located.

   Foreign Routing Realm

         Any routing realm other than the mobile node's Home Routing
         Realm.

   Visited Routing Realm

         A network other than a mobile node's Home Routing Realm, to
         which the mobile node is currently located.

   Passive Public Agent

         A GRE [9] router. In a basic MPN deployment, a passive public
         agent route GRE tunnels (where IP is both the delivery and
         payload protocol). There is no MPN protocol ehancements
         required. A passive agent is not aware of nodes movement and it
         need not process MPN registration messages or maintain any
         mobility binding and security associations. This enables the
         immediate deployment of public agents.

   Active Public Agent

         A GRE router. In addition, an active agent processes and relay
         MPN registration messages. It MUST maintain mobility bindings
         of successful registrations and may have security associations.
         Security policies for visiting mobile nodes may be enforced for
         the whole network at the active public agent. A active public
         agent may provide routing optimizations and tunnel circuit
         switching [ref Section 7].

   Home Public Agent

         A public agent in the mobile node's Home Routing Realm. All
         Private Mobile Nodes MUST be assigned one or more public home
         agents. A public mobile node may be assigned a public home
         agent located at its home network domain.

   Foreign Public Agent

         Any public agent other than the mobile node's Home Public
         Agent.

   Mobility Binding

         The association of a home address with a care-of address and



Teo and Li                  Expires May 1999                    [Page 6]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


         any intermediate tunnel destinations (public home/foreign agent
         address), along with the remaining lifetime of that
         association.

   Local Home Agent

         A home agent in Mobile IP terminology.

   Local Foreign Agent

         A foreign agent in Mobile IP terminology.

   Mobility Agent

         Either a local home agent, local foreign agent or a public
         agent.

2. Tunneling

   Tunneling is a means to alter the normal IP routing for datagrams, by
   delivering them to intermediate destinations that would otherwise not
   be selected by the (network part of the) IP destination address in
   the original IP header.

2.1 Reverse tunneling

   A bidirectional tunnel is established when a mobile node is in a
   foreign routing realm. In order for the mobile node to have the same
   level of network connectivity as it does when in its home network,
   nodes that are reachable only when the mobile node is in the home
   routing realm or home network, should be accessible in the visited
   network. Packets destined to a node's address in another routing
   realm will probably not be delivered using the existing routing
   mechanism in the visited routing realm. A reverse tunnel [4] is used
   to deliver datagrams originating from the mobile node back to the
   home routing realm or home network. This will allow the datagrams to
   be routed to the correct correspondent nodes in the presence of
   address collisions and security restrictions. The reverse tunnel exit
   point need not be the mobile node's local home agent.

2.2 GRE encapsulation

   IP in IP encapsulation [3] is the default tunneling mechanism used in
   Mobile IP. While it is useful for re-routing a datagram from one
   point to another, the mechanism is unsuitable when multiple
   transitional points are required, to traverse across different
   routing realms. To achieve such functionality, the encapsulation
   method must support source routing or the intermediate destinations



Teo and Li                  Expires May 1999                    [Page 7]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   must be dynamically configured to forward the datagram to the next
   correct tunneling point.

   MPN uses Generic Routing Encapsulation [9] as the default
   encapsulation method to tunnel across different routing realms. GRE
   provides a Source Route Entry (SRE) in the tunnel header. Using a SRE
   with an Address Family indicating an IP loose source route (Strict
   Source Route flag cleared), the intermediate destinations can be
   specified.

   In the case of MPN, the SRE's IP address list will include any public
   agent along the tunnel route and the tunnel endpoint. Typically the
   tunnel endpoint is the local home agent (for a reverse tunnel) or the
   care-of address (for a forward tunnel).

2.3 Overall Encapsulated Packet

   The diagram below provides an overview of the GRE tunnelled packet
   layout.

   +-------------------+    +------------------------
   |                   |    |
   | IP Delivery Header| -> | ... Protocol Type 47
   |                   |    |
   +-------------------+    +------------------------
   |                   |    | ... Protocol Type 0x800
   |     GRE Header    | -> +------------------------    +-------------
   |                   |    | ... Source Route Entry  -> | ... Address
   |                   |    |                            | Family 0x800
   |                   |    |                            |
   +-------------------+    +------------------------    +-------------
   |                   |    | ...  Original IP Header
   |    IP Payload     | -> +------------------------
   |                   |    |
   --------------------+    +------------------------

2.4 GRE SRE Processing

   All the intermediate tunnel destinations (the public agents) MUST
   process the GRE header as specified in [8]. The local home agent and
   the mobile node MUST be able to perform GRE encapsulation and
   decapsulation.

   The diagram below illustrates forward GRE tunneling (from the local
   home agent to the mobile node co-located care-of address) when the
   mobile node moves from the private home routing realm into a private
   visted routing realm. The same route but in reverse is typically
   taken by the reverse GRE tunnel.



Teo and Li                  Expires May 1999                    [Page 8]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   Private Home Routing Realm
   --------------------------
   private home network: 10.0.0.0/8
   correspondent node address: 10.10.10.10
   MN home address: 10.0.0.10
   MN local home agent address: 10.0.0.1
   MN public home agent address: 192.32.174.44

   Private Visited Routing Realm
   -----------------------------
   private visited network: 10.0.0.0/8
   advertised public foreign agent address: 200.9.2.1
   MN co-located care-of address: 10.20.20.20

   S1 and D1 represent the original IP header's source and destination
   addresses respectively. S2 and D2 represent the IP delivery header's
   source and destination addresses respectively.


                              Global Public Internet
                                ________________
                               (                )
                              (                  )
                             (                    )
                              (                  )
                               (________________)
                                  |           |
             {S2=192.32.174.44,^  |           |  |{S2=192.32.174.44,
              D2=200.9.2.1}    |  |           |  | D2=200.9.2.1}
               {S1=10.10.10.10,|  |           |  |{S1=10.10.10.10
                D1=10.0.0.10}  |  |           |  v D1=10.0.0.10}
                 +------------------+       +----------------------+
                 | Public Home Agent|       | Public Foreign Agent |
                 +------------------+       +----------------------+
                        |                         |
                Private | Home Network    Private | Visited Network
       -------------------------------    -------------------------
       {S2=10.10.10.1,   ^ |                 |   |{S2=200.9.2.1,
        D2=192.32.174.44}| |                 |   | D2=10.20.20.20}
         {S1=10.10.10.10,| |                 |   |{S1=10.10.10.10,
          D1=10.0.0.10}  | +--+             +--+ v D1=10.0.0.10}
                           |--|             |--|
                          /____\           /____\
                        10.10.10.1       10.20.20.20
                     Local Home Agent    Mobile Node

2.5 ICMP messages




Teo and Li                  Expires May 1999                    [Page 9]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   The public agents should handle ICMP messages from within the GRE
   tunnel as specified in [3], including the maintenance of tunnel "soft
   state".

3. MPN Agent Advertisement

   Mobile IP's agent advertisements allow a mobile node to detect
   movement across IP subnets. MPN includes a public agent advertisement
   extension to Mobile IP's agent advertisements. This allows a mobile
   node to determine its current routing realm.

   All MPN extension type values are selected from the range 128 to 255.
   As specified in Mobile IP, values in this range can be silently
   ignored by mobile nodes supporting only the Mobile IP based protocol.

3.1 Public Agent Extension

   This extension MUST be included in all local home agents' and local
   foreign agents' agent advertisements. All public agents that serve as
   a public home agent for any mobile node in the routing realm MUST be
   included in the list of Public Agent Entries. The presence of this
   extension also indicates that the advertiser supports MPN.

   The Public Agent Advertisement Extension is defined as follows:

    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    |P|        Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               zero or more Public Agent Entries               |
   |                           ...                                 |

   Type     128

   Length   (2 + 8*N), where N is the number of public agent entries.

   P        Public Network. The network is accessible from the global
            public Internet (not a private network)

   The Public Agent Entry is defined as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Preference  |R|F|P|T| rsvd  |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Public Agent Address                    |



Teo and Li                  Expires May 1999                   [Page 10]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Preference  cost indicator. 0 means the public foreign agent is busy
               and will not tunnel datagrams for additional mobile
               nodes.

   Lifetime    The longest lifetime (measured in seconds) that this
               public foreign agent is willing to accept in any
               registration request. A value of 0xffff indicates
               infinity.

   R           Registration required. Registration with the public
               foreign agent is required. The public foreign agent will
               maintain the mobility binding of successful
               registrations. If the 'R' bit is not set, the Lifetime
               field is undefine and can be assumed to be infinite. If
               the 'R' bit is set, the 'P' bit can be assumed to be set.

   F           Foreign Public Agent. This public agent offers service as
               a foreign public agent in this routing realm.

   P           Registration Proxy. This public agent will relay the
               registration message to the next mobility agent or mobile
               node (registration reply).

   T           Tunnel Circuit Switching. This public agent supports
               tunnel circuit switching [ref Section 7].

   The Public Agent Address MUST be a public IP address reachable from
   the global public Internet.

   A public agent MUST always be prepared to serve the mobile nodes for
   which it is the public home agent.

   The Public Agent Advertisement Extension MUST be before the Mobility
   Agent Advertisement Extension.

3.2 Choosing a Public Agent

   Having only one public agent for a routing realm will be a single
   point of failure and possible bottleneck device.

   The public agent entries [refer Section 3.1] carry with each public
   agent address a preference identifier. To select a public agent, one
   has to rely on heuristics approaches. The easiest may be to always
   choose the "preferred public foreign agent" - the public agent entry
   with the maximum preference value or alternatively chose the public
   home/foreign agent randomly. This will spread the tunneled traffic on



Teo and Li                  Expires May 1999                   [Page 11]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   different routes and introduce better load sharing and more
   redundancy to the network.

3.3 Absent Agent Advertisment

   Agent advertisements are needed to determine the current routing
   realm. If there is no agent advertisement detected, a mobile node
   should send agent solicitations, even when it acquires a co-located
   care-of address. This is to determine if the mobile node is within
   its home routing realm.

   In the absence of agent advertisements, a mobile node should proceed
   as if the current routing realm is the global public Internet. This
   implies, a public mobile node should proceed as specified in Mobile
   IP, and a private mobile node should proceed as specified in the
   private home routing realm to public visited routing realm movement
   scenario [ref Section 6.3].

3.4 Movement Detection

   To determine the current routing realm, a mobile node should check
   the 'P' bit in the Public Agent Advertisement Extension.

   Public Mobile Node
   ------------------
   If the 'P' bit is set, the mobile node is in its home routing realm
   and it can proceed as specified in Mobile IP.

   If the 'P' bit is not set, the mobile node is in a private routing
   realm and it should proceed as specified in the public home routing
   realm to private visited routing realm movement scenario [ref Section
   6.1]

   Private Mobile Node
   -------------------
   If the 'P' bit is set, the mobile node is in the global public
   Internet and it should proceed as specified in the private home
   routing realm to public visited routing realm movement scenario [ref
   Section 6.3]

   If the 'P' bit is not set, the mobile node MUST search all the Public
   Agent Entries. If one of the public agent addresses advertised
   matches the mobile node's assigned public home agent address, it is
   in its home routing realm and can proceed as specified in Mobile IP.
   If there is no matching public agent address, the mobile node is in a
   private foreign routing realm and it should proceed as specified in
   the private home routing realm to private foreign routing realm
   movement scenario [ref Section 6.2]



Teo and Li                  Expires May 1999                   [Page 12]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   Once the current routing realm is determined, the mobile node can
   detect movement between IP subnets as specified in Mobile IP.

4. MPN Registration

   Registration allows mobile nodes to communicate their current
   reachability information to the mobility agents. The following
   sections describes registration across routing realms.

   There are two registration procedures. One via the mobility agents
   that relays the registration to the mobile node's local home agent,
   and one by tunneling the registration to the mobile node's local home
   agent. By default, the registration messages are tunneled unless all
   intermediate tunnel destinations (the public agents) support
   registration relay ('P' bit is set in the Public Agent Entry [ref
   Section 3.1]).

4.1 Public Agent Registration Extension

   All registration request and reply MUST include the Public Agent
   Registration extension. This extension MUST be before the Mobile-Home
   Authentication extension. The extension is an explicit notification
   of the source route (public agents) that SHOULD be traversed between
   the home routing realm and visited routing realms.

   There may be additional routing realms crossed implicity but they are
   transparent to MPN and no additional intermediate tunnel destinations
   are specified i.e. not included in the Public Agent Registration
   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    |H|F|R|T|      Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Public Home Agent Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Public Foreign Agent Address               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type     128

   Length   10

   H        Public Home Agent Present

            If the Public Home Agent Present bit is set to 1, then the
            public home agent address field is valid and indicate an



Teo and Li                  Expires May 1999                   [Page 13]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


            intermediate tunnel destination requested.

   F        Public Foreign Agent Present

            If the Foreign Home Agent Present bit is set to 1, then the
            public home agent address field is valid and represent an
            intermediate tunnel destination requested.

   R        Registration Relay. If the 'R' bit is set, the mobile node
            or local home agent requests that the public agents relays
            the registration messages.

   T        Tunnel Circuit Switching. If the 'T' bit is set, the mobile
            node requests that the mobility agents uses tunnel circuit
            switching.

4.2 Registration Considerations

Tunneling of Registration Messages

   All mobility agents except the local foreign agent MUST be able to
   process GRE tunneled packets. This enables the mobile node to reverse
   tunnel the registration request to its local home agent and for the
   local home agent to forward tunnel the registration reply in a basic
   MPN deployment.

Registration Relay

   A private mobile node MUST NOT request a public foreign agent to
   relay its registration request (set 'R' bit in Public Agent
   Registration extension) if its public home agent does not support
   registration relay.

Public Foreign Agent

   A public foreign agent that requires registration ('R' bit is set in
   the Public Agent Entry) MUST tunnel the registration message to the
   local home agent if the 'H' bit is set but the 'R' bit is not set in
   the Public Agent Registration extension, with the public home agent
   as the intermediate tunnel destination.

Local Foreign Agent

   A local foreign agent that requires registration ('R' bit is set in
   the Mobility Agent Extension) MUST process the Public Agent
   Registration Extension and relay the registration message to the next
   mobility agent.




Teo and Li                  Expires May 1999                   [Page 14]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


Local Home Agent

   The local home agent MUST return the same public agent registration
   extension (in the registration request) for all registration replies.

5. Security Extensions

   There can be security associations between public agents and Mobile
   IP mobility agents.

    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    |         SPI  ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ... SPI (cont.)          |       Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Mobile-Public Home Authentication Extension

   Type  35

   Mobile-Public Foreign Authentication Extension

   Type  36

   Public Foreign-Public Home Authentication Extension

   Type  37

6. Movement Scenarios

   Only movement across routing realms need to be considered. Mobility
   support within the home routing realm is provided by the Mobile IP
   base protocol. Only the differences from Mobile IP is illustrated.

   The movement detection algorithm is specified in Section 3.4 In all
   the scenarios, the mobile node will typically establish a
   bidirectional tunnel with its local home agent.

6.1 Public Home Routing Realm to Private Visited Routing Realm

   A public foreign agent 10.0.0.1 is selected from the public agent
   entries ('F' bit is set) advertised.

   Registration Request
   --------------------




Teo and Li                  Expires May 1999                   [Page 15]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   IP fields:

      Source Address       MN co-located care-of address

      Destination Address  10.0.0.1

   Mobile IP fields:

      The 'D' bit, 'G' bit and 'R' bit is set.

   Public Agent Registration extension fields:

      The 'F' bit is set.

      Public Foreign Agent Address  10.0.0.1

   If the public foreign agent 10.0.0.1 supports registration relay, the
   mobile node's local home agent.

   Registration Reply
   ------------------

   Public Agent Registration extension fields:

   If the 'R' bit is not set, the registration message must be tunneled
   in the reverse direction.

   Bidirectional Tunnel
   --------------------

   On successful registration, a bidirectional GRE tunnel is established
   between the mobile node and local home agent.

   Mobile Node <--> Public Foreign Agent <--> Local Home Agent

   Routing Optimization
   --------------------

   The public foreign agent may be the reverse tunnel endpoint. This
   should be determined by the mobile node.

6.2 Private Home Routing Realm to Private Visited Routing Realm

   The scenario is similar to Section 6.1 except there is now a public
   home agent.

   Registration Request
   --------------------



Teo and Li                  Expires May 1999                   [Page 16]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   The Public Agent Registration fields:

      The 'H' bit and 'F' bit is set.

      Public Foreign Agent Address  10.0.0.1

      Public Home Agent Address     MN public home agent

   If both the public home agent and public foreign agent supports
   registration relay, the 'R' bit set, else the registration message
   must be tunneled to the mobile's node local home agent.

   Bidirectional Tunnel
   --------------------

   On successful registration, a bidirectional GRE tunnel is established
   between the mobile node and local home agent.

   Mobile Node <--> Public Foreign Agent <--> Public Home Agent
                                                   ^
                                                   |
                                                   |
                                              Local Home Agent

   Routing Optimization
   --------------------

   The public home agent may be the reverse tunnel endpoint. This should
   be determined by the mobile node.

   ,ti 0 6.3 Private Home Routing Realm to Public Visited Routing Realm

   The scenario is similar to Section 6.2 except there is now no public
   foreign agent.

   Registration Request
   --------------------

   IP fields:

      Source Address       MN co-located care-of address

      Destination Address  MN public home agent

   Mobile IP fields:

      The 'D' bit, 'G' bit and 'R' bit is set.




Teo and Li                  Expires May 1999                   [Page 17]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   Public Agent Registration extension fields:

      The 'H' bit is set.

      Public Home Agent Address     MN public home agent

   If the public home agent supports registration relay, the 'R' bit is
   set, else the registration message must be tunneled to the mobile
   node's local home agent.

   Bidirectional Tunnel
   --------------------

   On successful registration, a bidirectional GRE tunnel is established
   between the mobile node and local home agent.

   Mobile Node <--> Public Home Agent <--> Local Home Agent

   Routing Optimization
   --------------------

   The public home agent may be the reverse tunnel endpoint. This should
   be determined by the mobile node.

7. Tunnel Circuit Switching

   This section describes an alternative encapsulation mechanism to
   tunnel across multiple routing realms.

   In MPN, bidirectional tunneling is used to deliver datagrams between
   the mobile node and its local home agent. In tunnel circuit
   switching, the bidirection tunnel is a virtual routing circuit with
   the mobile node's co-located care-of address and its local home agent
   as the circuit end points. When the mobile node and its local home
   agent are in different routing realms, the virtual circuit must be
   routed through public agent(s).

   The diagram illustrates all the MPN entities in a virtual circuit
   that crosses three separate routing realms - private home network to
   global public internet to private visited network.

   Mobile Node <--> Public Foreign  <--> Public Home <--> Home Agent
                        Agent               Agent

7.1 Conventional Datagram Tunneling

   Typically, there are only two entities involved in tunneling - the
   encapsulator and decapsulator - as the tunnel is established within a



Teo and Li                  Expires May 1999                   [Page 18]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   common routing realm. There is generally no benefit to establishing a
   virtual circuit since the tunnel header already stores both tunnel
   endpoints addresses.

   In MPN, to tunnel from the home agent to the care-of address and vice
   versa, the IP addresses of each of the intermediate tunnel
   destinations which routes the tunneled packet are required.

   In the conventional approach, all these routing information are
   recorded in the tunnel header. However, this information is
   duplicated for every datagram tunneled. The additional information is
   also only relevant to the public agents. Establishing a tunnel
   circuit can reduce this overhead.

7.2 Tunnel Identifier

   Tunnel identifiers (TIDs) are assigned by public agents. They are
   used by MPN entities to correctly switch the tunnel circuits. The
   TIDs are unique to a public agent and have no relation to the TIDs
   assigned by other public agent.

   IP fragmentation must not occur in a tunnel circuit switching point
   as the TID is stored within the IP payload. Note the same requirement
   applies to GRE tunnels.

   The TID assigned must be authenticated to prevent modification during
   tunnel circuit establishment. Since a Mobile-Home security
   association MUST exist in Mobile IP, it is used for the TID
   authenticaton.

   During the mobile node registration process, the public agents
   allocate their TIDs in the TID extension of the registration request.
   The TID extension MUST not be included in the Mobile-Home
   Authentication extension. If the registration process is successful,
   the home agent MUST include the TID extension in the Mobile-Home
   Authentication extension in registration reply.

   The public agents MUST verify that the TID in the TID extension of
   the registration reply is the original value allocated. If the value
   is changed, the public agent MUST indicate a registration failure in
   the code field of the registration reply.

7.3 Tunnel Identifier 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    |H|F|        Reserved           |



Teo and Li                  Expires May 1999                   [Page 19]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Public Home Agent TID    |    Public Foreign Agent TID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type     129

   Length   6

   H        Public Home Agent TID Present

            If the Public Home Agent TID Present bit is set to 1, then
            the public home agent TID field is valid.

   F        Public Foreign Agent TID Present

            If the Foreign Home Agent TID Present bit is set to 1, then
            the public home agent TID field is valid.

7.4 Tunnel Circuit Packet

   The tunnel circuit IP header protocol type field is 56.  A circuit
   label is inserted between the tunnel circuit IP header and the
   encapsulated payload.

Circuit Label

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|D| Reserved  |              TID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   R     Reverse Bit
         If set, the packet is tunneled from the mobile node to its
         local home agent (reverse tunneling).

   D     Decapsulation Bit
         If set, the packet should be decapsulated and forwarded using
         the existing routing mechanism.

7.5 Data Structures

   A public agent MUST associate the TID with the following information.

   Index    H  R  Next Hop IP Address     Next Hop TID
   -----    -  -  -------------------     ------------
   TID      0  0  Care-of Address         Unchanged



Teo and Li                  Expires May 1999                   [Page 20]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


            0  1  Home Public Agent       Home Public Agent TID
            1  0  Foreign Public Agent    Foreign Public Agent TID
            1  1  Home Agent              Unchanged

   H     If set, the public agent is a Public Home Agent.
   R     If set, the tunnel circuit is a reverse tunnel ('R' bit is set
         in the circuit label)

8. Security Considerations

   GRE is a cleartext encapsulation mechanism and does not protect the
   data from eavesdroppers. The mobile node and its local home agent
   should establish an end-to-end bidirectional tunnel and encrypt it if
   privacy is a concern.

   Due to the current lack of trust for the Internet at large, a secure
   channel should be established from a private mobile node to its
   private home routing realm. Traffic between the private mobile node
   and its public home agent's external interface should be encrypted.

Firewall Filter Rules

   Access control at the public agents into the private network should
   be provided as any node that gains access to it, can access the
   private network as well.

   Firewalls can deny mobile traffic on a per private routing realm
   basis or per public network basis. To control the visitor list on a
   per mobile node basis, the public agents MUST be active public
   agents. It is also possible to filter traffic based on the TID.

Implementation Status

   A prototype implementation of MPN by W. T. Teo, one of the authors,
   is now undergoing testing.

Acknowledgements

   Many thanks to Dr. Y. C. Tay at the National University of Singapore
   for supporting this joint work as well as for his valuable comments.

   This work was supported in part by National University of Singapore
   ARF grant RP960683.

References

    [1] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October
        1996



Teo and Li                  Expires May 1999                   [Page 21]


Internet Draft     <draft-teoyli-mobileip-mvpn-01.txt>     November 1998


    [2] C. Perkins. "IP Mobility Support Version 2",
        <draft-ietf-mobileip-v2-00.txt>, November 1997

    [3] C. Perkins, "IP Encapsulation within IP", RFC 2003, May 1996

    [4] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May
        1998.

    [5] P. Srisuresh, K. Egevang, "Traditional IP Network Address
        Translator (Traditional NAT)",
        <draft-ietf-nat-traditional-01.txt> - work in progress, November
        1998

    [6] P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT)
        Terminology and Considerations",
        <draft-ietf-nat-terminology-01.txt> - work in progress, October
        1998

    [7] Y. Li, W. T. Teo, "IP Private Address Identification",
        <draft-yliteo-mobileip-paid-01.txt> - work in progress, November
        1998

    [8] Rekhter, Y., Moskowitz, B. Karrenberg, D., G. de Groot, and
        Lear, E. "Address Allocation for Private Internets", RFC 1918,
        February 1996

    [9] S. Hanks, T. Li, D. Farinacci and P. Traina, "Generic Routing
        Encapsulation over IPv4 networks", RFC 1702, October 1994

   [10] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994

Author's Address

   W. T. Teo Department of ISCS National University of Singapore Lower
   Kent Ridge Crescent SINGAPORE 119260

   E-mail: teoweetu@comp.nus.edu.sg

   Y. Li Bay Networks, Inc.  BL60-304 600 Technology Park Drive
   Billerica, MA 01821

   Phone:  1-978-916-1130 Fax:    1-978-670-8760 E-mail:
   yli@BayNetworks.COM







Teo and Li                  Expires May 1999                   [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/