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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 draft-ietf-lisp-mn

Network Working Group                                       D. Farinacci
Internet-Draft                                                 V. Fuller
Intended status: Informational                                  D. Lewis
Expires: February 3, 2011                                       D. Meyer
                                                     Cisco Systems, Inc.
                                                          August 2, 2010


                            LISP Mobile Node
                       draft-meyer-lisp-mn-03.txt

Abstract

   This document describes how a lightweight version of LISP's ITR/ETR
   functionality can be used to provide seamless mobility to a mobile
   node.  The LISP Mobility Architecture uses standard LISP
   functionality to provide scalable mobility for LISP mobile nodes.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on February 3, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Farinacci, et al.       Expires February 3, 2011                [Page 1]


Internet-Draft              LISP Mobile Node                 August 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  4
   4.  Architecture Overview  . . . . . . . . . . . . . . . . . . . .  6
   5.  Design Requirements  . . . . . . . . . . . . . . . . . . . . .  6
     5.1.  User Requirements  . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Network Requirements . . . . . . . . . . . . . . . . . . .  7
   6.  LISP Mobile Node Operation . . . . . . . . . . . . . . . . . .  7
     6.1.  Addressing Architecture  . . . . . . . . . . . . . . . . .  8
     6.2.  Control Plane Operation  . . . . . . . . . . . . . . . . .  8
     6.3.  Data Plane Operation . . . . . . . . . . . . . . . . . . .  9
   7.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  LISP Mobile Node to a Stationary Node in a LISP Site . . . 10
       7.1.1.  Handling Unidirectional Traffic  . . . . . . . . . . . 10
     7.2.  LISP Mobile Node to a Non-LISP Stationary Node . . . . . . 11
     7.3.  LISP Mobile Node to LISP Mobile Node . . . . . . . . . . . 12
       7.3.1.  One Mobile Node is Roaming . . . . . . . . . . . . . . 12
       7.3.2.  Both Mobile Nodes are Roaming  . . . . . . . . . . . . 12
     7.4.  Non-LISP Site to a LISP Mobile Node  . . . . . . . . . . . 13
     7.5.  LISP Site to LISP Mobile Node  . . . . . . . . . . . . . . 13
   8.  Multicast and Mobility . . . . . . . . . . . . . . . . . . . . 13
   9.  RLOC Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Mobile Node's RLOC is not Globally Routable  . . . . . . . 14
     9.2.  Mobile Node's RLOC is an EID . . . . . . . . . . . . . . . 15
   10. Mobility Example . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 17
     10.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 17
   11. LISP Implementation in a Mobile Node . . . . . . . . . . . . . 17
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     12.1. Proxy ETR Hijacking  . . . . . . . . . . . . . . . . . . . 19
     12.2. LISP mobile node using an EID as its RLOC  . . . . . . . . 19
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   14. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     15.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21



Farinacci, et al.       Expires February 3, 2011                [Page 2]


Internet-Draft              LISP Mobile Node                 August 2010


1.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


2.  Introduction

   The Locator/ID Separation Protocol (LISP) [LISP] specifies an
   architecture and mechanism for replacing the addresses currently used
   in the Internet with two separate name spaces: Endpoint Identifiers
   (EIDs), used within sites, and Routing Locators (RLOCs), used by the
   transit networks that make up the Internet infrastructure.  To
   achieve this separation, LISP defines protocol mechanisms for mapping
   from EIDs to RLOCs.  The currently deployed mapping infrastructure is
   comprised of LISP Map-Servers and Map-Resolvers [LISP-MS], and is
   tied together with LISP+ALT [LISP-ALT].

   This document specifies the behavior of a new LISP network element:
   the LISP Mobile Node in which a subset of LISP functionality can be
   implemented to provide mobile node roaming.

   A LISP mobile node implements lightweight Ingress Tunnel Router and
   Egress Tunnel Router functionality.  Design goals for the LISP
   mobility architecture include:

   o  Keeping TCP connections alive while roaming.

   o  Allowing the mobile node to communicate with other mobile nodes
      while either or both are roaming.

   o  Allowing the mobile node to multi-home (i.e., use multiple
      interfaces concurrently).

   o  Allow the mobile node to be a server.  That is, any mobile node or
      stationary node can find and connect to a mobile node as a server.

   o  Provide shortest path bidirectional data paths between a mobile
      node and any other stationary or mobile node.

   o  Does not require fine-grained routes in the core network.

   o  Does not require home-agent or foreign agent network elements (and
      hence no triangle routing is required in the data plane
      [RFC3220]).

   The LISP mobility architecture requires that the network use LISP



Farinacci, et al.       Expires February 3, 2011                [Page 3]


Internet-Draft              LISP Mobile Node                 August 2010


   Map-Server [LISP-MS] and LISP Interworking [LISP-IW] technology to
   allow a LISP mobile node to roam and to be discovered in an efficient
   and scalable manner.

   The protocol mechanisms described in this document apply those cases
   in which a node's IP address changes frequently.  For example, when a
   mobile node roams, it is typically assigned a new IP address (i.e.,
   one of its IP address changes).  Similarly, a broadband subscriber
   may have its address change frequently; as such, a broadband
   subscriber can use the LISP Mobile Node mechanisms defined in this
   specification.

   The remainder of this document is organized as follows: Section 3
   defines the terms used in this document.  Section 4 provides a
   overview of salient features of the LISP-MN architecture, and
   Section 5 describes design requirements for the LISP-MN architecture,
   Section 6 provides the detail of LISP-MN data and control plane
   operation.  Section 7 specifies how the LISP-MN protocol operates.
   Section 8 specifies multicast operation for LISP mobile nodes, and
   Section 9 lists other considerations for the LISP-MN architecture.
   Section 12 outlines the security considerations for a LISP mobile
   node.  Finally, Section 11 specifies the LISP implementation which
   resides in a mobile node.


3.  Definition of Terms

   This section defines the terms used in this document.

   Stationary Node (SN):  A non-mobile node who's IP address remains
      relatively unchanged.  That is, its IP address does not change as
      frequently as a fast roaming mobile hand-set or broadband
      connection.

   Endpoint ID (EID):  This is the traditional LISP EID [LISP], and is
      the address that a LISP mobile node uses as its address for
      transport connections.  A LISP mobile node never changes its EID,
      which is typically a /32 or /128 prefix and is assigned to a
      loopback interface.  Note that the mobile node can have multiple
      EIDs, and these EIDs can be from different address families.

   Routing Locator (RLOC):  This is the traditional LISP RLOC, and is a
      routable address that can be used to reach a mobile node.

   Ingress Tunnel Router (ITR):  An ITR is a router that accepts an IP
      packet with a single IP header (more precisely, an IP packet that
      does not contain a LISP header).  The router treats this "inner"
      IP destination address as an EID and performs an EID-to-RLOC



Farinacci, et al.       Expires February 3, 2011                [Page 4]


Internet-Draft              LISP Mobile Node                 August 2010


      mapping lookup.  The router then prepends an "outer" IP header
      with one of its globally routable RLOCs in the source address
      field and the result of the mapping lookup in the destination
      address field.  Note that this destination RLOC may be an
      intermediate, proxy device that has better knowledge of the EID-
      to-RLOC mapping closer to the destination EID.  In general, an ITR
      receives IP packets from site end-systems on one side and sends
      LISP-encapsulated IP packets toward the Internet on the other
      side.  A LISP mobile node, however, when acting as an ITR LISP
      encapsulates all packet that it originates.

   Egress Tunnel Router (ETR):  An ETR is a router that accepts an IP
      packet where the destination address in the "outer" IP header is
      one of its own RLOCs.  The router strips the "outer" header and
      forwards the packet based on the next IP header found.  In
      general, an ETR receives LISP-encapsulated IP packets from the
      Internet on one side and sends decapsulated IP packets to site
      end-systems on the other side.  A LISP mobile node, when acting as
      an ETR, decapsulates packets that are then typically processed by
      the mobile node.

   LISP Mobile Node Architecture (LISP-MN Architecture):  An
      architecture which uses LISP to provide fast roaming for mobile
      hand-sets.

   LISP Mobile Node:  A LISP capable fast roaming mobile hand-set.

   Proxy ETR (PETR):  An infrastructure element used to decapsulate
      packets sent from mobile nodes non-LISP sites.  Proxy ETRs are
      described in [LISP-IW].

   Map-cache:  A data structure which contains an EID-prefix, its
      associated RLOCs, and the associated policy.  Map-cache's are
      typically found in ITRs and PTRs.

   Negative Map-Reply:  A Negative Map-Reply is a Map-Reply that
      contains a coarsely aggregated non-LISP prefix.  Negative Map-
      Replies are typically generated by Map-Resolvers, and are used to
      inform an ITR (mobile or stationary) that a site is not a LISP
      site.  A LISP mobile node encapsulate packets to destinations
      covered by the negative Map-Reply are encapsulated to a PETR.

   Proxy Tunnel Router (PTR):  PTRs are used to provide
      interconnectivity between sites that use LISP EIDs and those that
      do not.  They act as a gateway between the Legacy Internet and the
      LISP enabled Network.  A given PTR advertises one or more highly
      aggregated EID prefixes into the public Internet and acts as the
      ITR for traffic received from the public Internet.  Proxy Tunnel



Farinacci, et al.       Expires February 3, 2011                [Page 5]


Internet-Draft              LISP Mobile Node                 August 2010


      Routers are described in [LISP-IW].

   Roaming Event:  A Roaming Event occurs when there is a change in a
      LISP mobile node's RLOC set.


4.  Architecture Overview

   The LISP-MN architecture described in this document uses the Map-
   Server/Map-Resolver service interface in conjunction with a light-
   weight ITR/ETR implementation in the mobile node to provide scalable
   fast mobility.  The LISP-MN control-plane uses a Map-Server as an
   anchor point, which provides control-plane scalability.  In addition,
   the LISP-MN data-plane takes advantage of shortest path routing, and
   therefore does not increase packet delivery latency.


5.  Design Requirements

   This section outlines the design requirements for the LISP-MN
   architecture, and is divided into User Requirements (Section 5.1) and
   Network Requirements (Section 5.2).

5.1.  User Requirements

   This section describes the user functionality that the LISP-MN
   architecture provides to a LISP mobile node.

   Transport Connection Survivability:  The LISP-MN architecture MUST
      allow a LISP mobile node to roam while keeping transport
      connections alive.

   Simultaneous Roaming:  The LISP-MN architecture MUST allow a LISP
      mobile node to talk to another LISP mobile node while both are
      roaming.

   Multihoming:  The LISP-MN architecture MUST allow for simultaneous
      use of multiple Internet connections by a LISP mobile node.  In
      addition, the architecture MUST allow for the LISP mobile node to
      specify ingress traffic engineering policies as documented in
      [LISP].  That is, the mobile node must be able to specify both
      active/active and active/passive policies for ingress traffic.

   Shortest Path Data Plane:  The LISP-MN architecture MUST allow for
      shortest path bidirectional traffic between a LISP mobile node and
      a stationary node, and between a LISP mobile node and another LISP
      mobile node (i.e., without triangle routing in the data path).
      This provides a low-latency data path between the LISP mobile node



Farinacci, et al.       Expires February 3, 2011                [Page 6]


Internet-Draft              LISP Mobile Node                 August 2010


      and the nodes that it is communicating with.

5.2.  Network Requirements

   This section describes the network functionality that the LISP-MN
   architecture provides to a LISP mobile node.

   Routing System Scalability:  The LISP-MN architecture MUST NOT
      require injection of fine-grained routes into the core network.

   Mapping System Scalability:  The LISP-MN architecture MUST NOT
      require additional state in the mapping system.  In particular,
      any mapping state required to support LISP mobility MUST BE
      confined to the LISP mobile node's Map-Server and the ITRs which
      are talking to the LISP mobile node.

   Component Reuse:  The LISP-MN architecture MUST use existing LISP
      infrastructure components.

   Home Agent/Foreign Agent:  The LISP-MN architecture MUST NOT require
      the use of home-agent or foreign-agent infrastructure components
      [RFC3220].

   Readdressing:  The LISP-MN architecture MUST NOT require TCP
      connections to be reset when the mobile node roams.  In
      particular, since the IP address associated with a transport
      connection will not change as the mobile node roams, TCP
      connections not reset.


6.  LISP Mobile Node Operation

   The LISP-MN architecture is built from three existing LISP
   components: A very lightweight implementation of LISP that runs in an
   LISP mobile node, and the existing Map-Server [LISP-MS] and
   Interworking [LISP-IW] infrastructures.  A LISP mobile node typically
   sends and receives LISP encapsulated packets (exceptions include
   management protocols such as DHCP).

   The LISP-MN architecture makes a single mobile node look like a LISP
   site in accordance with the LISP architecture as defined in [LISP].
   The mobile node implements ITR and ETR functionality.  All packets
   the mobile node originates are LISP encapsulated, and all packets
   received by a LISP mobile node will be LISP encapsulated.

   When a mobile node roams onto a new network, it receives a new RLOC.
   Since the mobile node is an authoritative ETR for its EID-prefix, it
   MUST Map-Register it's updated RLOC set.  As soon as the registration



Farinacci, et al.       Expires February 3, 2011                [Page 7]


Internet-Draft              LISP Mobile Node                 August 2010


   is complete, new sessions can be established immediately.  Sessions
   that are encapsulating to RLOCs that did not change during the
   roaming event are not by the roaming event (or subsequent mapping
   update).  Finally, the mobile node MUST update the ITRs and PTRs that
   have cached a previous mapping.  It does this using the techniques
   described in Section 6.2.

6.1.  Addressing Architecture

   A LISP mobile node is typically statically provisioned with an EID
   that it uses for all transport connections.  This EID will change
   infrequently (if at all; assignment of a LISP mobile node's EID is is
   typically a subscription time event).  The key point is that the
   relatively fixed EID allows the LISP mobile node's transport
   connections to survive roaming events.  As usual, an EID can be
   either an IPv4 or an IPv6 address.  The LISP mobile node's RLOC set
   changes dynamically during roaming events, and the RLOC set can
   contain both IPv4 or IPv6 addresses.

   A LISP mobile node is also statically provisioned with the address of
   a Map-Server and with a corresponding authentication key.  Like the
   mobile node's EID, both the Map-Server address and authentication key
   change very infrequently (again, these are anticipated to be
   subscription time parameters).  Since the LISP mobile node's Map-
   Server is configured to advertise an aggregated EID-prefix that
   covers the LISP mobile node's EID, changes to the LISP mobile node's
   mapping are not propagated further into the mapping system.  This
   property provides for scalable fast mobility.

   A LISP mobile node is also be provisioned with the address of a Map-
   Resolver.  A mobile node may also learn the address of a Map-Resolver
   though a dynamic protocol such as DHCP [RFC2131].

   Finally, note that if, for some reason, a mobile node's EID is re-
   provisioned, the mobile node's Map-Server address may also have to
   change in order to keep mobile node's EID within the aggregate
   advertised by the Map-Server (this is discussed in greater detail in
   Section 6.2).

6.2.  Control Plane Operation

   A roaming event occurs when the LISP mobile node receives a new RLOC.
   Because the new address is a new RLOC from the LISP mobile node's
   perspective, it must update its EID-to-RLOC mapping with its Map-
   Server; it does this using the Map-Register mechanism described in
   [LISP].

   Note that a LISP mobile node may or may not respond to Map-Requests.



Farinacci, et al.       Expires February 3, 2011                [Page 8]


Internet-Draft              LISP Mobile Node                 August 2010


   In particular, a LISP mobile node MAY instruct its Map-Server to
   proxy respond to Map-Requests by setting the Proxy-Map-Reply bit in
   the Map-Register message [LISP].  In this case the Map-Server
   responds with a non-authoritative Map-Reply so that an ITR or PTR
   will know that the ETR didn't directly respond.  A mobile node may
   want the Map-Server to respond on its behalf for a variety of
   reasons, including minimizing control traffic on radio links and
   minimizing battery utilization.

   Because the mobile node's Map-Server is pre-configured to advertise
   an aggregate covering the LISP mobile node's EID prefix, the database
   mapping change associated with the roaming event is confined to the
   Map-Server and those ITRs that have cached the previous mapping.  The
   LISP mobile node can cause the mappings cached in remote ITRs to be
   refreshed by using small Time To Live (TTL) on its mappings, sending
   Map-Requests with piggybacked mapping data, or by setting the Solicit
   Map Request (SMR) bit in subsequent data packets.

   If a LISP mobile node does not have a mapping for a destination it
   wants to communicate with, it sends a Map-Request to its Map-Resolver
   as detailed in [LISP-MS].  The mobile node respects the priority and
   weights of the destination LISP site's mapping and as such adheres to
   the policy of the destination site.  Finally, if the destination
   address matches a negative map-cache entry, the mobile node
   encapsulates the matching packets to a PETR.

6.3.  Data Plane Operation

   A key feature of LISP-MN control-plane architecture is the use of the
   Map-Server as an anchor point; this allows control of the scope to
   which changes to the mapping system must be propagated during roaming
   events.

   The LISP-MN data-plane architecture, on the other hand, does not rely
   on additional LISP infrastructure for communication between LISP
   nodes (mobile or stationary).  Data packets take the shortest path to
   and from the mobile node to other LISP nodes; as noted above, low
   latency shortest paths in the data-plane is an important goal for the
   LISP-MN architecture (and is important for delay-sensitive
   applications like gaming and voice-over-IP).  Note that a LISP mobile
   node will need additional interworking infrastructure when talking to
   non-LISP sites [LISP-IW]; this is consistent with the design of any
   host at a LISP site which talks to a host at a non-LISP site.

   In general, the LISP mobile node data-plane operates in the same
   manner as the standard LISP data-plane with one exception: all
   packets generated by a LISP mobile node are LISP encapsulated.
   Because data packets are always encapsulated to a RLOC, packets



Farinacci, et al.       Expires February 3, 2011                [Page 9]


Internet-Draft              LISP Mobile Node                 August 2010


   travel on the shortest path from LISP mobile node to another LISP
   stationary or mobile node.  When the LISP mobile node is sending
   packets to a stationary or mobile node in a non-LISP site, it sends
   LISP-encapsulated packets to a PETR which then decapsulates the
   packet and forwards it to its destination.


7.  Protocol Operation

   There are five distinct connectivity cases considered by the LISP-MN
   architecture.  The five mobility cases are:

      LISP Mobile Node to a Stationary Node in a LISP Site.

      LISP Mobile Node to a Non-LISP Site.

      LISP Mobile Node to a LISP Mobile Node.

      Non-LISP Site to a LISP Mobile Node.

      LISP Site to a LISP Mobile Node.

   The remainder of this section covers these cases in detail.

7.1.  LISP Mobile Node to a Stationary Node in a LISP Site

   After a roaming event, a LISP mobile node MUST immediately register
   its EID-to-RLOC mapping with its configured Map-Server(s).  This
   allows LISP sites sending Map-Requests to the LISP mobile node to
   receive the current mapping.

   On the other hand, ITRs and PTRs which may have cached previous
   mappings must be informed that the mapping has changed.  A LISP
   mobile node MAY use the SMR bit on data packets it is sending to LISP
   sites, or it MAY send a Map-Request with Map-Data to update active
   ITRs to effect this update.

7.1.1.  Handling Unidirectional Traffic

   A problem may arise when traffic is flowing unidirectionally between
   sites.  In this case, data-plane techniques such as setting the SMR
   bit to update the mappings can't be used.

   For example, consider the "square routing" packet flow case depicted
   in Figure 1.  In this case, a host X with site border routers A and B
   wants to send packets to a host Y with site border routers C and D.
   Suppose that X has a default route pointing at A, and that A forwards
   traffic for Y to C (which then forwards it on it on to Y).  Y also



Farinacci, et al.       Expires February 3, 2011               [Page 10]


Internet-Draft              LISP Mobile Node                 August 2010


   has a default route that points at D, which forwards traffic destined
   for X to B. In this scenario, routers A, B, C, and D see only
   unidirectional traffic between hosts X and Y.

   If X is a LISP mobile node and B is a ITR (or PTR), the mobile node
   can't use the data-plane techniques described in Section 7.1 to
   update the PTR's mapping because the mobile node forwards neither
   data nor control traffic to the PTR.  Thus the ITR's map-cache entry
   for the mobile node will have to have its TTL expire before it can
   learn a new mapping for the mobile node.  As a result, LISP mobile
   SHOULD set the TTL on the mappings in its Map-Replies to be in the
   1-2 minute range.



               Source                              Destination
                 Site               Core                Site
                        \                         /
                         \                       /
               +----> A  |    -------------->   |  C ------+
               |         |                      |          |
               X         |                      |          Y
               ^         |                      |          |
               +----- B  |    <--------------   |  D <-----+
                        /                       \
                       /                         \



                   Figure 1: Square Routing Packet Flow

7.2.  LISP Mobile Node to a Non-LISP Stationary Node

   LISP mobile nodes use the LISP Interworking infrastructure
   (specifically a PETR) to reach non-LISP sites.  In general, the PETR
   will be co-located with the LISP mobile node's Map-Server.  This
   ensures that the LISP packets being decapsulated are from sources
   that have Map-Registered to the Map-Server.  A LISP mobile node MAY
   install a default map-cache entry that points at a PETR for use with
   negative Map-Replies.

   When a LISP mobile node roams, it continues to uses its configured
   PETR and Map-Server.  This may add stretch to packets sent from a
   LISP mobile node to a non-LISP destination.







Farinacci, et al.       Expires February 3, 2011               [Page 11]


Internet-Draft              LISP Mobile Node                 August 2010


7.3.  LISP Mobile Node to LISP Mobile Node

   LISP mobile node to LISP mobile node communication is an instance of
   LISP-to-LISP communication with three sub-cases:

   o  Both LISP mobile nodes are stationary.  This is covered in
      Section 7.1.

   o  Only one LISP mobile node is roaming.  This is covered in
      Section 7.3.1.

   o  Both LISP mobile nodes are roaming.  This is covered in
      Section 7.3.2

7.3.1.  One Mobile Node is Roaming

   In this case, the roaming mobile mode can find the stationary mobile
   node by sending Map-Request for its EID-prefix.  After receiving a
   Map-Reply, the roaming node can encapsulate data packets directly to
   the non-roaming mobile node node.

   The roaming mobile node, on the other hand, MUST update its Map-
   Server with the new mapping data as described in Section 7.1.  It MAY
   also use the cache management techniques described in Section 7.1 to
   provide for timely updates of remote ITR caches.  Once the roaming
   mobile node has updated its Map-Server, the non-roaming mobile node
   can retrieve the new mapping data (if it hasn't already received an
   updated mapping via one of the mechanisms described in Section 7.1)
   and the stationary mobile node can encapsulate data directly to the
   roaming mobile node.

7.3.2.  Both Mobile Nodes are Roaming

   When both mobile nodes are roaming, they both will both receive new
   RLOCs, and as a result both need register their new mappings to their
   Map Servers.  However, because both mobile node's map-cache entries
   contain old RLOCs, neither can update the other using the data-plane
   techniques described in Section 7.1.

   A mobile node can, however, force itself to issue Map-Requests by
   clearing its map-cache.  These Map-Requests MAY contain the updated
   mapping information for the mobile node.  Hence a LISP mobile node
   MUST clear its map-cache whenever it roams onto a new network (i.e.,
   receives a new RLOC).  This will cause the mobile node to issue a new
   Map-Request the next time it sends a data packet to the other mobile
   node.  The Map-Request will follow the mapping infrastructure to the
   new location of the correspondent mobile node.




Farinacci, et al.       Expires February 3, 2011               [Page 12]


Internet-Draft              LISP Mobile Node                 August 2010


7.4.  Non-LISP Site to a LISP Mobile Node

   Hosts in non-LISP sites talk to other LISP hosts, whether mobile or
   stationary, using the PTR infrastructure.  Because LISP mobile nodes
   always encapsulate packets, though subtle the behave differently than
   as described in [LISP-IW].  In particular, stationary ITRs do not
   encapsulate packets to a non-LISP host while LISP mobile node do.  A
   PETR is required to decapsulated those packets that are destined from
   the LISP mobile node to a non-LISP host.  Packets from the non-LISP
   site host return to the mobile node through a PTR, which non-LISP
   encapsulates packets to the mobile node.  Inasmuch as all traffic
   forwarded through a PTR is unidirectional traffic, a mobile node
   should use the technique described in Section 7.1.1.  In particular,
   a LISP mobile node SHOULD set the TTL on the mappings in its Map-
   Replies to be in 1-2 minute range.

7.5.  LISP Site to LISP Mobile Node

   When a mobile node roams onto a new network, it needs to update the
   caches in any ITRs that might have stale mappings.  This is analogous
   to the case in that a stationary LISP site is renumbered; in that
   case ITRs that have cached the old mapping must be updated.  This is
   done using the techniques described in Section 7.1.

   When a LISP router in a stationary site is performing both ITR and
   ETR functions, a mobile node can update the stationary site's map-
   caches using techniques described in Section 7.1.  However, when the
   LISP router in the stationary site is performing is only ITR
   functionality, these techniques can not be used because the ITR is
   not receiving data traffic from the mobile node.  In this case, the
   mobile node should use the technique described in Section 7.1.1.  In
   particular, a LISP mobile node SHOULD set the TTL on the mappings in
   its Map-Replies to be in 1-2 minute range.


8.  Multicast and Mobility

   Inasmuch as a mobile node performs both ITR and ETR functionality, it
   should also perform a lightweight version of multicast ITR/ETR
   functionality described in [LISP-MCAST].  When a mobile node
   originates a multicast packet, it will encapsulate the packet with a
   multicast header, where the source address in the outer header is one
   of it's RLOC addresses and the destination address in the outer
   header is the group address from the inner header.  The interfaces in
   which the encapsulated packet is sent on is discussed below.

   To not require PIM functionality in the LISP mobile node as
   documented in [LISP-MCAST], the LISP mobile node resorts to using



Farinacci, et al.       Expires February 3, 2011               [Page 13]


Internet-Draft              LISP Mobile Node                 August 2010


   encapsulated IGMP for joining groups and for determining which
   interfaces are used for packet origination.  When a LISP mobile node
   joins a group, it obtains the map-cache entry for the (S-EID,G) it is
   joining.  It then builds a IGMP report encoding (S-EID,G) and then
   LISP encapsulates it with UDP port 4341.  It selects an RLOC from the
   map-cache entry to send the encapsulated IGMP Report.

   When other LISP mobile nodes are joining an (S-EID,G) entry where the
   S-EID is for a LISP mobile node, the encapsulated IGMP Report will be
   received by the mobile node multicast source.  The mobile node
   multicast source will remember the interfaces the encapsulated IGMP
   Report is received on and build an outgoing interface list for it's
   own (S-EID,G) entry.  If the list is greater than one, then the
   mobile node is doing replication on the source-based tree for which
   it is the root.

   When other LISP routers are joining (S-EID,G), they are instructed to
   send PIM encapsulated Join-Prune messages.  However, to keep the
   mobile node as simple as possible, the mobile node will not be able
   to process encapsulated PIM Join-Prune messages.  Because the map-
   cache entry will have a MN-bit indicating the entry is for a mobile
   node, the LISP router will send IGMP encapsulated IGMP Reports
   instead.

   When the mobile node is sending a multicast packet, it can operate in
   two modes, multicast-origination-mode or unicast-origination-mode.
   When in multicast-origination-mode, the mobile node multicast-source
   can encapsulate a multicast packet in another multicast packet, as
   described above.  When in unicast-origination-mode, the mobile node
   multicast source encapsulates the multicast packet into a unicast
   packet and sends a packet to each encapsulated IGMP Report sender.

   These modes are provided depending on whether or not the mobile
   node's network it is currently connected can support IP multicast.


9.  RLOC Considerations

   This section documents cases where the expected operation of the
   LISP-MN architecture may require special treatment.

9.1.  Mobile Node's RLOC is not Globally Routable

   When a mobile node receives a non-globally routable IPv4 [RFC1918] or
   IPv6 [RFC4193] address during a roaming event, it cannot advertise it
   globally (i.e., use it as an RLOC in a Map-Reply).  This is because
   the scope of the private address is bounded by the current
   topological location where the mobile node resides.  The use of



Farinacci, et al.       Expires February 3, 2011               [Page 14]


Internet-Draft              LISP Mobile Node                 August 2010


   private address with LISP is detailed in [LISP-NAT].

9.2.  Mobile Node's RLOC is an EID

   When a LISP mobile node roams into a LISP site, the "RLOC" it is
   assigned may be an address taken from the site's EID-prefix.  In this
   case, the mobile node will Map-Register a mapping from its statically
   assigned EID to the "RLOC" it received from the site.  This scenario
   creates another level of indirection: the mapping from the mobile
   node's EID to a site assigned EID.  The mapping from the mobile
   node's EID to the site assigned EID allow the mobile node to be
   reached by sending packets using the mapping for the EID; packets are
   delivered to site's EIDs use the same LISP infrastructure that all
   LISP hosts use to reach the site.

   A packet egressing a LISP site destined for a LISP mobile node that
   resides in a LISP site will have three headers: an inner header that
   is built by the host and is used by transport connections, a middle
   header that is built by the site's ITR and is used by the
   destination's ETR to find the current topological location of the
   mobile node, and an outer header (also built by the site's ITR) that
   is used to forward packets between the sites.

   Consider a site A with EID-prefix 1.0.0.0/8 and RLOC A and a site B
   with EID-prefix 2.0.0.0/8 and RLOC B. Suppose that a host S in site A
   with EID 1.0.0.1 wants to talk to a LISP mobile node MN that has
   registered a mapping from EID 240.0.0.1 to "RLOC" 2.0.0.2 (where
   2.0.0.2 allocated from site B's EID prefix, 2.0.0.0/8 in this case).
   This situation is depicted in Figure 2.






















Farinacci, et al.       Expires February 3, 2011               [Page 15]


Internet-Draft              LISP Mobile Node                 August 2010


  Site has EID-prefix 1.0.0.0/8                   Site has EID-prefix 2.0.0.0/8
      S has EID 1.0.0.1                                MN has EID 240.0.0.1
                                                       MN has RLOC 2.0.0.2
      --------------                                      --------------
    /                \          ---------------         /                \
   |          ITR-A'  |       /                 \      |  ETR-B'          |
   |                  |      |                   |     |                  |
   |   S              |      |      Internet     |     |              MN  |
   |    \             |      |                   |     |             ^    |
   |     \            |      |                   |     |            /     |
   |      --> ITR-A   |       \                 /      |  ETR-B ----      |
    \                /          ---------------         \                /
      --------------                                      --------------
       |       |  |                                          ^       ^  ^
       |       |  |                                          |       |  |
       |       |  |           outer-header: A -> B           |       |  |
       |       |  +------------------------------------------+       |  |
       |       |     RLOCs used to find which site MN resides        |  |
       |       |                                                     |  |
       |       |                                                     |  |
       |       |              middle-header: A -> 2.0.0.2            |  |
       |       +-----------------------------------------------------+  |
       |            RLOCs used to find topological location of MN       |
       |                                                                |
       |                                                                |
       |                 inner-header: 1.0.0.1 -> 240.0.0.1             |
       +----------------------------------------------------------------+
                           EIDs used for TCP connection



              Figure 2: Mobile Node Roaming into a LISP Site

   In this case, the inner header is used for transport connections, the
   middle header is used to find topological location of the LISP mobile
   node (the LISP mobile node Map-Registers the mapping 240.0.0.1 ->
   2.0.0.2 when it roams into site B), and the outer header is used to
   move packets between sites (A and B in Figure 2).


10.  Mobility Example

   This section provides an example of how the LISP mobile node is
   integrated into the base LISP Architecture [LISP].







Farinacci, et al.       Expires February 3, 2011               [Page 16]


Internet-Draft              LISP Mobile Node                 August 2010


10.1.  Provisioning

   The LISP mobile node needs to be configured with the following
   information:

      An EID, assigned to its loopback address

      A key for map-registration

      An IP address of a Map-Resolver (this could be learned
      dynamically)

      An IP address of its Map-Server and Proxy ETR

10.2.  Registration

   After a LISP roams to a new network, it MUST immediately register its
   new mapping this new RLOC (and associated priority/weight data) with
   its Map-Server.

   The LISP mobile node MAY chose to set the 'proxy' bit in the map-
   register to indicate that it desires its Map-Server to answer map-
   requests on its behalf.


11.   LISP Implementation in a Mobile Node

   This section will describe a possible approach for developing a
   lightweight LISP-MN implementation.  A LISP mobile node will
   implement a LISP sub-layer inside of the IP layer of the protocol
   stack.  The sub-layer resides between the IP layer and the link-
   layer.

   For outgoing unicast packets, once the header that contains EIDs is
   built and right before an outgoing interface is chosen, a LISP header
   is prepended to the outgoing packet.  The source address is set to
   the local RLOC address (obtained by DHCP perhaps) and the destination
   address is set to the RLOC associated with the destination EID from
   the IP layer.  To obtain the RLOC for the EID, the mobile node
   maintains a map-cache for destination sites or destination mobile
   nodes to which it is currently talking.  The map-cache lookup is
   performed by doing a longest match lookup on the destination address
   the IP layer put in the first IP header.  Once the new header is
   prepended, a route table lookup is performed to find the interface in
   which to send the packet or the default router interface is used to
   send the packet.

   When the map-cache does not exist for a destination, the mobile node



Farinacci, et al.       Expires February 3, 2011               [Page 17]


Internet-Draft              LISP Mobile Node                 August 2010


   may queue or drop the packet while it sends a Map-Request to it's
   configured Map-Resolver.  Once a Map-Reply is returned, the map-cache
   entry stores the EID-to-RLOC state.  If the RLOC state is empty in
   the Map-Reply, the Map-Reply is known as a Negative Map-Reply in
   which case the map-cache entry is created with a single RLOC, the
   RLOC of the configured Map-Server for the mobile node.  The Map-
   Server that serves the mobile node also acts as a Proxy ETR (PETR) so
   packets can get delivered to hosts in non-LISP sites to which the
   mobile node is sending.

   For incoming unicast packets, LISP sub-layer in the mobile node
   simply decapsulates the packets and delivers to the IP layer.  In
   addition, if the SMR-bit is set in the LISP header, the mobile node
   will schedule a timer to later send a Map-Request to the source
   address of the received encapsulated packet.  Optionally, the loc-
   reach-bits can be processed by the LISP sub-layer.  That is, the
   source EID from the packet is looked up in the map-cache and if the
   loc-reach-bits settings have changed, store the loc-reach-bits from
   the packet and note which RLOCs for the map-cache entry should not be
   used.

   A background task that runs off a timer should be run so the mobile
   node can send periodic Map-Register messages to the Map-Server.  The
   Map-Register message should also be triggered when the mobile node
   detects a change in IP address for a given interface.  The mobile
   node should send Map-Registers to the same Map-Register out each of
   it's operational links.  This will provide for robustness on radio
   links with which the mobile node is associated.

   A mobile node receives a Map-Request when it has Map-Registered to a
   Map-Server with the Proxy-bit set to 0.  That means, the mobile node
   wishes to send authoritative Map-Replies for Map-Requests that are
   targeted at the mobile node.  If the Proxy-bit is set in Map-
   Registers, then the Map-Server will send non-authoritative Map-
   Replies on behalf of the mobile node.  In this case, the Map-Server
   never encapsulates Map-Requests to the mobile node.  The mobile node
   can save resources by not receiving Map-Requests.

   To summarize, a LISP sub-layer should implement:

   o  Encapsulating and decapsulating data packets.

   o  Sending and receiving of Map-Request control messages.

   o  Receiving and optionally sending Map-Replies.

   o  Sending Map-Register messages periodically.




Farinacci, et al.       Expires February 3, 2011               [Page 18]


Internet-Draft              LISP Mobile Node                 August 2010


   The key point about the LISP sub-layer is that no other components in
   the protocol stack need changing; just the insertion of this sub-
   layer between the IP layer and the interface layer-2 encapsulation/
   decapsulation layer.


12.  Security Considerations

   Security for the LISP-MN architecture builds upon the security
   fundamentals found in LISP [LISP] for data-plane security and the
   LISP Map Server [LISP-MS] registration security.  Security issues
   unique to the LISP-MN architecture are considered below.

12.1.  Proxy ETR Hijacking

   The Proxy ETR (or PETR) that a LISP mobile node uses as its
   destination for non-LISP traffic must use the security association
   used by the registration process outlined in Section 6.2 and
   explained in detail in the LISP-MS specification [LISP-MS].  These
   measures prevent third party injection of LISP encapsulated traffic
   into a Proxy ETR.  Importantly, a PETR MUST NOT decapsulate packets
   from non-registered RLOCs.

12.2.  LISP mobile node using an EID as its RLOC

   For LISP packets to be sent to a LISP mobile node which has an EID
   assigned to it as an RLOC as described in Section 9.2), the LISP site
   must allow for incoming and outgoing LISP data packets.  Firewalls
   and stateless packet filtering mechanisms must be configured to allow
   UDP port 4341 and UDP port 4342 packets.


13.  Acknowledgments

   Noel Chiappa, Andrew Partan, and John Zwiebel provided insightful
   comments on early versions of this document.  A special thanks goes
   to Mary Nickum for her attention to detail and effort in editing
   early versions of this document.


14.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC2434].


15.  References




Farinacci, et al.       Expires February 3, 2011               [Page 19]


Internet-Draft              LISP Mobile Node                 August 2010


15.1.  Normative References

   [LIG]      Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
              draft-ietf-lisp-lig-00.txt (work in progress),
              August 2010.

   [LISP]     Farinacci, D., Fuller, V., Lewis, D., and D. Meyer,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-08.txt (work in progress), August 2010.

   [LISP-ALT]
              Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
              Alternative Topology (LISP+ALT)",
              draft-ietf-lisp-alt-04.txt (work in progress), April 2010.

   [LISP-IW]  Lewis, D., Farinacci, D., Fuller, V., and D. Meyer,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-00.txt (work in progress),
              May 2009.

   [LISP-MCAST]
              Farinacci, D., Meyer, D., Venaas, S., and J. Zwiebel,
              "LISP for Multicast Environments",
              draft-ietf-lisp-multicast-03.txt (work in progress),
              April 2010.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP MAP Server",
              draft-ietf-lisp-ms-05.txt (work in progress), April 2010.

   [LISP-NAT]
              Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "NAT
              Traversal for the Locator/ID Separation Protocol (LISP)",
              draft-x-lisp-nat-traversal-00.txt (work in progress),
              April 2010.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3220]  Perkins, C., "IP Mobility Support for IPv4", RFC 3220,
              January 2002.



Farinacci, et al.       Expires February 3, 2011               [Page 20]


Internet-Draft              LISP Mobile Node                 August 2010


   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

15.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.


Authors' Addresses

   Dino Farinacci
   Cisco Systems, Inc.
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dino@cisco.com


   Vince Fuller
   Cisco Systems, Inc.
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: vaf@cisco.com


   Darrel Lewis
   Cisco Systems, Inc.
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com


   David Meyer
   Cisco Systems, Inc.
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: dmm@1-4-5.net






Farinacci, et al.       Expires February 3, 2011               [Page 21]


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