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

Versions: 00

   Internet Engineering Task Force                      Farid Adrangi
   INTERNET DRAFT                                       Prakash Iyer
   Category: Informational                              Intel Corp.

   <draft-adrangi-mobileip-nat-vpn-problem-stat-req-00>
   Date:    January 2002


        Problem Statement and Requirements for Mobile IPv4 Traversal
        Across VPN or 'NAT and VPN' Gateways


   Status of this Memo

        This document is an Internet-Draft and is in full conformance
        with all provisions of Section 10 of RFC2026.

        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."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

        To view the entire list of current Internet-Drafts, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
        ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
        Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
        Coast), or ftp.isi.edu (US West Coast).

   Abstract

        This draft describes the problem statement and specifies the
        solution requirements for MIPv4 traversal across VPN or 'NAT
        and VPN' gateways.  The 'NAT and VPN' case refers to a network
        topology in which the MIPv4 traffic has to traverse one or more
        NAT gateway(s) followed by a VPN gateway in the path to its
        final destination.  Requirements and problems associated with
        MIPv4 traversal through NAT gateways NOT involving VPNs is
        outside the scope of this draft.


   Table of Contents

Expires August 2002.                                          [Page 1]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002



   1. Introduction....................................................2
   2. Terminology.....................................................3
   3. Acronyms........................................................3
   4.0. Roaming Scenarios.............................................4
   4.1. Roaming Inside the Home Network...............................5
   4.2. Roaming Outside the Home Network..............................5
   4.2.1. Roaming Outside the Home Network in a Routable Address Space
   (where, FA-assisted routing is not used)...........................6
   4.2.2 Roaming Outside the Home Network in Routable Address Space
   (where, FA-assisted routing is used)...............................6
   4.2.3 Roaming Outside the Home Network in a non-Routable Address
   Space..............................................................7
   5. Problem Statement...............................................8
   5.1. MIPv4 Incompatibilities with VPN Gateways.....................8
   5.2. MIPv4 Incompatibilities with NAT Gateways.....................9
   6. The Requirements................................................9
   6.1. Implications of Intervening NAT Gateways......................9
   6.2. Implications of Cascaded NAT.................................10
   6.3. MIPv4 Protocol...............................................10
   6.5. Functional Entities..........................................10
   6.6. Multi-vendor Interoperability................................10
   6.7. Fast MIPv4 Handoffs..........................................10
   6.8. Preservation of Existing VPN Infrastructure..................11
   6.9. Preserve Existing DMZ Traversal Policies.....................11
   6.10 Support For Route Optimization...............................11
   6.11 MIPv4 Registration SA Management.............................11
   6.12 Security Implications........................................11
   7. References.....................................................11


   1. Introduction

        Multi-subnetted IEEE 802.11 WLAN networks are being widely
        deployed in Enterprise Intranets - in many cases requiring a
        VPN tunnel to connect back and access Intranet resources, and
        public areas such as airports, coffee shops, convention centers
        and shopping malls. Many of these WLAN networks also employ NAT
        to translate between non-routable and routable IPv4 care-of
        (point of attachment) addresses. WWAN networks such as those
        based on GPRS and eventually EDGE and UMTS are also starting to
        see deployment. These deployments are paving the way for
        applications and usage scenarios requiring TCP/IP session
        persistence and constant reachability while connecting back to
        a secured (VPN protected), target 'home' network. This in turn
        drives the need for a mobile VPN solution that is multi-vendor
        interoperable, providing seamless access with persistent VPN
        sessions and through NAT gateways when needed. This draft
        identifies example usage scenarios, defines a problem statement
        based on the scenarios and specifies requirements that MUST be
        met to ensure broad deployment of multi-vendor interoperable
        solutions.

Adrangi, Iyer            Expires January 2002                 [Page 2]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002



        The important sections of this draft are organized as follows:

            Section 4: Describe roaming scenarios to motivate the
                       problem statement

            Section 5: Describes a problem statement for MIPv4
                       traversal across VPN and NAT gateways.

           Section 6: Specifies the requirements for a solution to
                       support multi-vendor seamless IPv4 mobility
                       across VPN or the 'NAT VPN' gateways.

   2. Terminology

        Traditional NAT:
        Network Address Translation.  "Traditional NAT would allow
        hosts within a private network to transparently access hosts in
        the external network, in most cases.  In a traditional NAT,
        sessions are uni-directional, outbound from the private
        network." ' [RFC2663]. Traditional NAT' are of two types:
        Basic NAT and NAPT.

        Basic NAT:
        "With Basic NAT, a block of external addresses are set aside
        for translating addresses of hosts in a private domain as they
        originate sessions to the external domain.  For packets
        outbound from the private network, the source IP address and
        related fields such as IP, TCP, UDP and ICMP header checksums
        are translated.  For inbound packets, the destination IP
        address and the checksums as listed above are translated." û
        [RFC2663]


        NAPT:
        Network Address Port Translation.  "NAPT extends the notion of
        translation one step further by also translating transport
        identifier (e.g., TCP and UDP port numbers, ICMP query
        identifiers).  This allows the transport identifiers of a
        number of private hosts to be multiplexed into the transport
        identifiers of a single external address.  NAPT allows a set of
        hosts to share a single external address.  Note that NAPT can
        be combined with Basic NAT so that a pool of external addresses
        are used in conjunction with port translation." û [RFC2663]

   3. Acronyms
        ACL: Access Control List
        GRE: Generic Routing Encapsulation
        MIPv4: Mobile IP for IPv4
        MIPv6: Mobile IP for IPv6
        VPN: Virtual Private Network


Adrangi, Iyer            Expires January 2002                 [Page 3]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


        MN-Perm: Permanent home address of the MN
        MN-COA: Co-located care-of address of the MN
        WLAN: IEEE 802.11 Wireless Local Area Network

   4.0. Roaming Scenarios

        This section describes roaming scenarios, wherein MIPv4 traffic
        has to traverse VPN or the 'NAT and VPN' gateways.  The
        scenarios are constructed based on a multi-subnetted MIPv4
        enabled Intranet (hereafter, referred by Home Network or VPN
        domain) protected by an IPsec-based VPN gateway as depicted in
        Figure 4.0a.

        +---------+       +------+   +---------------------------+
        |         |       |      |   |Home network / VPN Domain  |
        |         |       |IPsec-|   | +----+ +-----+ +----+     |
        |Internet |       |based |<->| |HA-1  | HA-2| |HA-n|     |
        |         |       |      |   | +----+ +-----+ +----+     |
        |         |       | VPN  |   |                           |
        +---------+       +------+   | +----+ +-----+ +----+     |
                                     | |FA-1| | FA-2| |FA-n|     |
                                     | +----+ +-----+ +----+     |
                                     |                           |
                                     | +----+ +-----+ +-----+    |
                                     | |MN-1| | MN-2| | MN-n|    |
                                     | +----+ +-----+ +-----+    |
                                     +---------------------------+

           Figure 4.0a Home Network protected by a VPN Gateway

        The home network, depicted in Figure 4.0a, may include both
        wired (IEEE 802.3) and IEEE 802.11 wireless LAN deployments.
        However, it is also possible to see IEEE 802.11 deployments
        outside the home network due to perceived lack of 802.1x
        security, as depicted in Figure 4.0b.


        +---------+       +------+   +---------------------------+
        |         |       |      |   |Home network / VPN Domain  |
        |         |       |IPsec-|   | +----+ +-----+ +----+     |
        |Internet |   |-->|based |<->| |HA-1| | HA-2| |HA-n|     |
        |         |   |   |      |   | +----+ +-----+ +----+     |
        |         |   |   | VPN  |   |                           |
        +---------+   |   +------+   | +----+ +-----+ +----+     |
                      |              | |FA-1| | FA-2| |FA-n|     |
                      |              | +----+ +-----+ +----+     |
           +-----------------+       |                           |
           |                 |       | +----+ +-----+ +-----+    |
           | 802.11 Wireless |       | |MN-1| | MN-2| | MN-n|    |
           |  Network        |       | +----+ +-----+ +-----+    |
           |                 |       +---------------------------+
           +-----------------+

Adrangi, Iyer            Expires January 2002                 [Page 4]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002



        Figure 4.0b' IEEE 802.11 Wireless deployment outside the home
                     network

        To help describe scenarios in the following sections, we have
        used the aid of an imaginary nomadic user, called Dr. Joe.
        Dr. Joe is a chief surgeon in a hospital, and always on the
        move. He leverages his wireless MIPv4 enabled hand-held device
        to access his patient' records, communicate with his
        colleagues and staff, and stay reachable in case of any
        emergencies.  For clarity, we assume that Dr. Joe' hospital
        employs a network similar to the one showed in Figure 4.0a
        (MIPv4 enabled network protected by a VPN, and includes both
        wired and IEEE 802.11 wireless deployments).

   4.1. Roaming Inside the Home Network

        Dr. Joe' needs for constant reachablity and maintaining his
        current transport connections as he roams from one network link
        to another are met by standard MIPv4 deployment inside the home
        network. Please note that NATÆed networks might be seen inside
        the home network, however, draft-mobileip-nat-traversal-00.txt
        solves the problem, as the mobile node's home agent will most
        likely be directly reachable by the mobile node.

   4.2. Roaming Outside the Home Network

        Dr. Joe frequently visits other clinics and hospitals, in which
        a multi-subnetted IEEE 802.11 hot spot network is utilized to
        provide Internet access for visitors.  Dr. Joe leverages the
        hot spot network to connect to his home network, and he would
        also like to maintain his transport connections to the home
        network as he roams from one network link to another in the hot
        spot network.

        This implies that the MIPv4 traffic destined to the home
        network MUST run inside an IPsec tunnel (i.e, MIP/IP/ESP/IP)
        established between the mobile node and the home networkÆs VPN
        gateway.  Moreover, the IPsecÆed MIPv4 traffic may also have to
        traverse a NAT gateway or a foreign agent in the path to the
        VPN gateway.  The following sub-sections illustrate these
        possibilities.











Adrangi, Iyer            Expires January 2002                 [Page 5]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


   4.2.1. Roaming Outside the Home Network in a Routable Address Space
   (where, FA-assisted routing is not used)

        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  |-----------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
           |  |                      | +----+ +-----+ +----+     |
           |  |<-- IPsec Tunnel      | |FA-1| | FA-2| |FA-n|     |
           |  |                      | +----+ +-----+ +----+     |
           |  |                      |                           |
       +---|--|---+                  | +----+ +-----+ +-----+    |
       |   |  |   |                  | |MN-1| |MN-2 | |MN-n |    |
       | +-|--|-+ |                  | +----+ +-----+ +-----+    |
       | | MN   | |                  |                           |
       | +------+ |                  +---------------------------+
       | Multi-   |
       | Subnetted|
       | Hot Spot |
       |          |
       +----------+

   4.2.2 Roaming Outside the Home Network in Routable Address Space
   (where, FA-assisted routing is used)

         There is a notion of trusted FA, where there is a SA
         established between the FA and home VPN gateway.  In this
         case, IPsec tunnel end-points are the FA and home VPN gateway.
         Furthermore, It is also possible for the MN in a trusted FA
         region to have end-to-end security with its home VPN gateway.
         This implies that there will be two pairs of IPsec tunnels,
         one between the FA and home VPN gateway, and the other between
         the MN and its home VPN gateway. Figure 4.3.2a shows the MN in
         a trusted FA region, where there is only an IPsec tunnel
         between the FA and home VPN gateway.

         In a non-trusted FA region, where there is no SA established
         between the FA and home gateway, there will always be a single
         IPsec tunnel established between the MN and its home VPN
         gateway, as depicted in Figure 4.3.2b.











Adrangi, Iyer            Expires January 2002                 [Page 6]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
        +--|--|----+                 | +----+ +-----+ +----+     |
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     |
        | | FA |   |                 | +----+ +-----+ +----+     |
        | +----+   |                 |                           |
        |          |                 | +----+ +-----+ +-----+    |
        | +----+   |                 | |MN-1| |MN-2 | |MN-n |    |
        | |MN  |   |                 | +----+ +-----+ +-----+    |
        | +----+   |                 |                           |
        | Multi-   |                 +---------------------------+
        | Subnetted|
        | Hot Spot |
        +----------+

        Figure 4.3.2a - the MN in trusted FA region



        +---------+       +------+   +---------------------------+
        |Internet |       |      |   |Home network /VPN Domain   |
        |  |--------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
        +--|--|----+                 | +----+ +-----+ +----+     |
        | +|--|+   |                 | |FA-1| | FA-2| |FA-n|     |
        | ||FA||   |                 | +----+ +-----+ +----+     |
        | +|--|+   |                 |                           |
        |  |  |<------- IPsec Tunnel | +----+ +-----+ +-----+    |
        | +|--|+   |                 | |MN-1| |MN-2 | |MN-n |    |
        | |MN  |   |                 | +----+ +-----+ +-----+    |
        | +----+   |                 |                           |
        | Multi-   |                 +---------------------------+
        | Subnetted|
        | Hot Spot |
        +----------+

        Figure 4.3.2b - the MN in non-trusted FA region


   4.2.3 Roaming Outside the Home Network in a non-Routable Address
   Space

         Note that the MN's home agent is not directly reachable in
         this case.  Therefore, draft-mobileip-nat-traversal-00.txt
         cannot be directly applied.  Furthermore, cascaded NAT gateway


Adrangi, Iyer            Expires January 2002                 [Page 7]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


         deployment is also a possibility, but not shown in the
         diagram.

        +---------+       +------+   +---------------------------+
        | Internet|       |      |   |Home network /VPN Domain   |
        |  ---------------|IPsec-|   | +----+ +-----+ +----+     |
        |  |  ------------|based |<->| |HA-1  | HA-2| |HA-n|     |
        +--|--|---+       |VPN   |   | +----+ +-----+ +----+     |
           |  |           +------+   |                           |
        +--|--|+                     | +----+ +-----+ +----+     |
        | NAT ||                     | |FA-1| | FA-2| |FA-n|     |
        +--|--|+                     | +----+ +-----+ +----+     |
           |  |<------ IPsec Tunnel  |                           |
        +--|--|----+                 | +----+ +-----+ +-----+    |
        | +----+   |                 | |MN-1| |MN-2 | |MN-n |    |
        | | MN |   |                 | +----+ +-----+ +-----+    |
        | +----+   |                 |                           |
        | Multi-   |                 +---------------------------+
        | Subnetted|
        | Hot Spot |
        +----------+


   5. Problem Statement

        This section describes MIPv4 incompatibilities with IPsec-based
        VPN and NAT gateways, in the context of the roaming scenarios
        outlined in section 4.

   5.1. MIPv4 Incompatibilities with VPN Gateways

        There are two problems associated with MIPv4 and VPN
        incompatibilities.

        Problem 1: The MN could roam into a foreign subnet with a FA.
        If the MN were to associate a VPN tunnel with its CoA, the FA
        (which is likely in a different administrative domain) cannot
        parse the IPsec tunnel SA and will not be able to setup SAs
        with the MN's VPN gateway and will consequently be not able to
        relay MIPv4 packets between the MN and the VPN gateway.
        `
        Problem 2: The MN could roam into a foreign subnet without a FA
        and obtain a CoA at its point of attachment (via [DHCP] or some
        other means). In an end-to-end security model, an IPsec tunnel
        that terminates at the VPN gateway MUST protect the IP traffic
        originating at the MN. If the IPsec tunnel is associated with
        the CoA, the tunnel SA MUST be refreshed after each IP subnet
        handoff which could have some performance implications on real-
        time applications.




Adrangi, Iyer            Expires January 2002                 [Page 8]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


        It is important to note that only IPsec tunnel mode is
        applicable here, as the mobile node connecting to the home
        network MUST establish an IPsec tunnel SA to the VPN gateway.

   5.2. MIPv4 Incompatibilities with NAT Gateways

        There are also two problems associated with MIPv4 and NAT
        incompatibilities:

        Problem 1: When an MN roams from its 'home' network (which may
        or may not be in a routable IP address space) protected by a
        VPN to a foreign network behind a NAT gateway, it acquires a
        non-routable care-of address (most likely through [DHCP]). The
        acquired non-routable care-of address is passed to the HA
        through a registration request.  This causes the MN to lose its
        connectivity to its home network, since the HA will not be able
        to forward the MN's packets to the non-routable care-of
        address.

        Problem 2: Even if we solve the first problem, an intervening
        NAT gateway in a foreign network will not always be able to
        demultiplex inbound IP-in-IP reverse tunneled MIPv4 data
        packets.  Because, NAPT gateways will simply not be able to
        route the inbound IP-in-IP packets, as they rely on IP address
        and transport identifier to route the packets from routable to
        non-routable address space or vice a versa. And, in the case of
        Basic NAT, consider two MNs that are registered with the same
        Home Agent (HA).  The inbound packets destined to the two MNs
        from the HA will have the same source and destination IP
        addresses ' making it difficult for the NAT to route the
        packets inside.

        The implications on Minimal IP [RFC2004] and GRE encapsulation
        [RFC1701] modes of MIPv4 are similar to IP-in-IP tunneling.

        Draft [MIP-NAT] describes a solution to the NAT traversal
        problem when VPNs are not involved. In this draft, we only
        discuss NAT traversal requirements where the HA is behind a VPN
        gateway and hence not directly reachable by the MN.

   6. The Requirements

   This section describes the requirements that are intended to
   establish a framework where in a solution can be developed to
   support MIPv4 traversal across VPN or 'NAT and VPN' gateways.


   6.1. Implications of Intervening NAT Gateways

        - The solution MUST work with both Basic NAT and NAPT.



Adrangi, Iyer            Expires January 2002                 [Page 9]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


        - The solution MUST not require any configuration or software
        changes to exiting NAT gateways.

        The reason for the above constraints is to not limit the
        solution to network topologies that employ certain types of NAT
        gateways and to enable deployment of MIPv4 in networks that
        have currently deployed non-modifiable NAT gateways.

   6.2. Implications of Cascaded NAT

        Cascaded NAT deployment is seen in some network topologies
        (case in point, a residential NAT gateway connected to a NATÆed
        ISP network). Therefore, the solution MUST support cascaded
        NAT.

   6.3. MIPv4 Protocol

        - The solution MUST be compliant with MIPv4 protocol [RFC
        3220].
        - The solution MAY introduce new extensions to MIPv4 protocol
        per guidelines specified in the MIPv4 RFCs. However, it is
        highly desirable to avoid any changes to MIPv4 mobility agents
        such as the FA and HA in order to overcome barriers to
        deployment.

   6.5. Functional Entities

        The solution MAY introduce a MIPv4 compliant functional entity
        that helps MIPv4 traversal across VPN or the ôNAT and VPNö
        gateways. However, scalability, manageability and availability
        implications introduced by that functional entity MUST be well
        understood. The functional entity MAY be implemented as a
        standalone entity or combined with another device such as a VPN
        gateway.

   6.6. Multi-vendor Interoperability

        Multi-vendor interoperability is a key requirement. In most
        Enterprises, MIPv4 mobility agents are likely to be deployed in
        existing routers from vendor X while VPN client/server
        solutions may come from vendor Y and mobility clients (MN) may
        come from yet another vendor. Medium and large Enterprises that
        typically purchase and deploy best-of-breed multi-vendor
        solutions for IP routing, VPNs, firewalls etc. are unlikely to
        revamp their infrastructure in favor of single-vendor end-to-
        end integrated solutions, preferring instead to reuse as much
        of their deployed infrastructure as possible. The solution
        proposed MUST enable such scenarios to be easily accommodated.

   6.7. Fast MIPv4 Handoffs



Adrangi, Iyer            Expires January 2002                [Page 10]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


        It is imperative to keep the key management overhead down to a
        minimum, in order to support fast handoffs across IP subnets.
        Hence, the solution MUST propose a mechanism whereby the IPsec
        tunnel SA can be bound to the invariant home IP address of the
        MN and applicable to static and dynamic home address
        assignment.

   6.8. Preservation of Existing VPN Infrastructure

        This implies the following:

        - The solution MUST preserve the investment in existing VPN
        gateways
        - The solution MAY require software upgrades to VPN gateways to
        explicitly support MIPv4 users

        - The solution MUST preserves VPN security requirements that
        are not inferior to what is already provided to existing
        "nomadic computing" remote access users, i.e. for
        confidentiality, primary and secondary authentication, message
        integrity, protection against replay attacks and related
        security services.

   6.9. Preserve Existing DMZ Traversal Policies

        The solution MUST be compatible with existing DMZ policies with
        respect to ACLs.

   6.10 Support For Route Optimization

        MIPv4 route optimization is not widely supported, as it
        requires changes to both MN's home agent and the correspondent
        node.  Hence, The solution MAY or MAY NOT support MIPv4 Route
        Optimization [ROUTE-OPT].

   6.11 MIPv4 Registration SA Management

        Mechanisms to manage MIPv4 Registration SAs are outside the
        scope of this draft.

   6.12 Security Implications

        The solution MUST NOT introduce any new vulnerabilities to the
        MIPv4 protocol as specified in related RFCs.

   7. References

   [RFC3220] RFC 3220 ' IP mobility support for IPv4
   [RFC3024] RFC 3024 ' Reverse tunneling for mobile IP
   [RFC2004] RFC 2004 ' Minimal encapsulation within IP
   [RFC1701] RFC 1701 ' Generic Routing encapsulation


Adrangi, Iyer            Expires January 2002                [Page 11]


Internet Draft  draft-adrangi-mobileip-nat-vpn-problem-stat-req-00
                             January 2002


   [RFC2119] RFC 2119 - Key words for use in RFCs to Indicate
   Requirement Levels
   [RFC1918] RFC 1918 ' Address Allocation for Private Internets
   [RFC2663] RFC 2663 - IP Network Address Translator (NAT) Terminology
   and Considerations
   [DHCP] RFC 2131 ' Dynamic Host Configuration Protocol
   [MIPv4-SEC-GUIDE] draft-bpatil-mobileip-sec-guide-01.txt -
   Requirements / Implementation Guidelines for Mobile IP using IP
   Security
   [[LOCAL-LINK] ' Dynamic Configuration of Iv4 Link-Local Addresses,
                   <draft-ietf-zeroconf-ipv4-linklocal-03>
   [ROUTE-OPT] ' Route Optimization in Mobile IP, <draft-ietf-mobileip-
   optim-10.txt>
   [MIP-NAT]' Mobile IP NAT/NAPT Traversal using UDP Tunneling,
   <draft-mobileip-nat-traversal.00.txt>



   Authors:

   Farid Adrangi
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR
   USA

   Phone: 503-712-1791
   Email: farid.adrangi@intel.com


   Prakash Iyer
   Intel Corporation
   2111 N.E. 25th Avenue
   Hillsboro, OR
   USA

   Phone: 503-264-1815
   Email: prakash.iyer@intel.com















Adrangi, Iyer            Expires January 2002                [Page 12]


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