LISP Mobile Node

Status of This Memo

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

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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

This Internet-Draft will expire on 17 July 2024.¶

Copyright Notice

Copyright (c) 2024 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

2. Definition of Terms

This section defines the terms used in this document.¶

Stationary Node (SN):

A non-mobile node who's IP address changes infrequently. That is, its IP address does not change as frequently as a fast roaming mobile hand-set or a broadband connection and therefore the EID to RLOC mapping is relatively static.¶

Endpoint ID (EID):

This is the traditional LISP EID [RFC9300], 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 in general a routable address that can be used to reach a mobile node. Note that there are cases in which an mobile node may receive an address that it thinks is an RLOC (perhaps via DHCP) which is either an EID or an RFC 1918 address [RFC1918]. This could happen if, for example, if the mobile node roams into a LISP domain or a domain behind a Network Address Translator (NAT)) See Section 10 for more details.¶

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

Proxy Ingress Tunnel Router (PITR):

PITRs 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 PITR 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 Ingress Tunnel Routers are described in [RFC6832].¶

Proxy Egress Tunnel Router (PETR):

An infrastructure element used to decapsulate packets sent from mobile nodes to non-LISP sites. Proxy Egress Tunnel Routers are described in [RFC6832].¶

LISP Mobile Node (LISP-MN):

A LISP capable fast roaming mobile hand-set.¶

Map-cache:

A data structure which contains an EID-prefix, its associated RLOCs, and the associated policy. Map-caches are typically found in ITRs and PITRs.¶

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

Roaming Event:

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

3. Design Overview

The LISP-MN design described in this document uses the Map-Server/Map-Resolver service interface in conjunction with a light-weight ITR/ETR implementation in the LISP-MN 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.¶

4. Design Requirements

This section outlines the design requirements for a LISP-MN, and is divided into User Requirements (Section 4.1) and Network Requirements (Section 4.2).¶

5. LISP Mobile Node Operation

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

The LISP-MN design makes a single mobile node look like a LISP site as described in in [RFC9300] by implementing ITR and ETR functionality. Note that one subtle difference between standard ITR behavior and LISP-MN is that the LISP-MN encapsulates all non-local, non-LISP site destined outgoing packets to a PETR.¶

When a LISP-MN roams onto a new network, it receives a new RLOC. Since the LISP-MN is the authoritative ETR for its EID-prefix, it must Map-Register it's updated RLOC set. New sessions can be established as soon as the registration process completes. Sessions that are encapsulating to RLOCs that did not change during the roaming event are not affected by the roaming event (or subsequent mapping update). However, the LISP-MN must update the ITRs and PITRs that have cached a previous mapping. It does this using the techniques described in Section 6.¶

6. Updating Remote Caches

A LISP-MN has five mechanisms it can use to cause the mappings cached in remote ITRs and PITRs to be refreshed:¶

Map Versioning:

If Map Versioning [RFC9302] is used, an ETR can detect if an ITR is using the most recent database mapping. In particular, when mobile node's ETR decapsulates a packet and detects the Destination Map-Version Number is less than the current version for its mapping, in invokes the SMR procedure described in [RFC9300]. In general, SMRs are used to fix the out of sync mapping while Map-Versioning is used to detect they are out of sync. [RFC9302] provides additional details of the Map Versioning process.¶

Data Driven SMRs:

An ETR may elect to send SMRs to those sites it has been receiving encapsulated packets from. This will occur when an ITR is sending to an old RLOC (for which there is one-to-one mapping between EID-to-RLOC) and the ETR may not have had a chance to send an SMR the ITR.¶

Setting Small TTL on Map Replies:

The ETR (or Map Server) may set a small Time to Live (TTL) on its mappings when responding to Map Requests. The TTL value should be chosen such that changes in mappings can be detected while minimizing control traffic. In this case the ITR is a SN and the ETR is the MN.¶

Piggybacking Mapping Data:

If an ITR and ETR are co-located, an ITR may elect to send Map-Requests with piggybacked mapping data to those sites in its map cache or to which it has recently encapsulated data in order to inform the remote ITRs and PITRs of the change.¶

Temporary PITR Caching:

The ETR can keep a cache of PITRs that have sent Map-Requests to it. The cache contains the RLOCs of the PITRs so later when the locator-set of a LISP-MN changes, SMR messages can be sent to all RLOCs in the PITR cache. This is an example of a control-plane driven SMR procedure.¶

7. Protocol Operation

There are five distinct connectivity cases considered by the LISP-MN design. 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.¶

   +-------------------------------------------+
   |                                           |
   |                                           | DP
   v   DP              DP            MQ        |
   X -----> Internet -----> PITR ------------> Y
                             ^      LEDP       |
                             |                 |
                             +-----------------+
                                     MR

  DP:   Data Packet
  LEDP: LISP Encapsulated Data Packet
  MQ:   Map Request
  MR:   Map Reply

8. Multicast and Mobility

Since a LISP-MN performs both ITR and ETR functionality, it should also perform a lightweight version of multicast ITR/ETR functionality described in [RFC6831]. When a LISP-MN 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-MN as documented in [RFC6831], the LISP-MN resorts to using encapsulated IGMP for joining groups and for determining which interfaces are used for packet origination. When a LISP-MN 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-MNs are joining an (S-EID,G) entry where the S-EID is for a LISP-MN, the encapsulated IGMP Report will be received by the LISP-MN multicast source. The LISP-MN 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 LISP-MN 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 LISP-MN as simple as possible, the LISP-MN 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 LISP-MN, the LISP router will send IGMP encapsulated IGMP Reports instead.¶

When the LISP-MN is sending a multicast packet, it can operate in two modes, multicast-origination-mode or unicast-origination-mode. When in multicast-origination-mode, the LISP-MN multicast-source can encapsulate a multicast packet in another multicast packet, as described above. When in unicast-origination-mode, the LISP-MN 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 design may require special treatment.¶

  EID-prefix 1.0.0.0/8                           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

10. LISP Mobile Nodes behind NAT Devices

When a LISP-MN resides behind a NAT device, it will be allocated a private RLOC address. The private RLOC address is used as the source address in the outer header for LISP encapsulated packets. The NAT device will translate the source address and source UDP port in the LISP encapsulated packet. The NAT device will keep this translated state so when packets arrive from the public side of the NAT, they can be translated back to the stored state. For remote LISP ITRs, PITRs, and RTRs, will need to know the translated RLOC address and port so they can encapsulate to the LISP-MN traversing the NAT device.¶

Procedures a LISP-MN should follow when it resides behind a NAT, will follow the LISP xTRs procedures in specification [I-D.ermagan-lisp-nat-traversal]. There are LISP-MN implementations that follow procedures in [I-D.farinacci-lisp-lispers-net-nat].¶

11. Mobility Example

This section provides an example of how the LISP-MN is integrated into the base LISP Design [RFC9300].¶

12. LISP Implementation in a Mobile Node

This section will describe a possible approach for developing a lightweight LISP-MN implementation. A LISP-MN 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 LISP-MN maintains a map-cache for destination sites or destination LISP-MNs 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 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 LISP-MN. The Map-Server that serves the LISP-MN also acts as a Proxy ETR (PETR) so packets can get delivered to hosts in non-LISP sites to which the LISP-MN is sending.¶

For incoming unicast packets, the LISP sub-layer simply decapsulates the packets and delivers to the IP layer. The loc-reach-bits can be processed by the LISP sub-layer. Specifically, 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.¶

In terms of the LISP-MN detecting which RLOCs from each stored map-cache entry is reachable, it can use any of the Locator Reachability Algorithms from [RFC9300].¶

A background task that runs off a timer should be run so the LISP-MN can send periodic Map-Register messages to the Map-Server. The Map-Register message should also be triggered when the LISP-MN detects a change in IP address for a given interface. The LISP-MN 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 LISP-MN receives a Map-Request when it has Map-Registered to a Map-Server with the Proxy-bit set to 0. This means that the LISP-MN wishes to send authoritative Map-Replies for Map-Requests that are targeted at the LISP-MN. If the Proxy-bit is set when the LISP-MN registers, then the Map-Server will send non-authoritative Map-Replies on behalf of the LISP-MN. In this case, the Map-Server never encapsulates Map-Requests to the LISP-MN. The LISP-MN can save resources by not receiving Map-Requests (note that the LISP-MN will receive SMRs which have the same format as Map-Requests).¶

To summarize, a LISP sub-layer should implement:¶

• Encapsulating and decapsulating data packets.¶

• Sending and receiving of Map-Request control messages.¶

• Receiving and optionally sending Map-Replies.¶

• Sending Map-Register messages periodically.¶

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

13. Security Considerations

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

Authors' Addresses