



Network Working Group                                       D. Farinacci
Internet-Draft                                               lispers.net
Intended status: Experimental                                  V. Moreno
Expires: 15 July 2026                                  P. Pillay-Esnault
                                                             Independent
                                                         11 January 2026


                      LISP for Satellite Networks
               draft-farinacci-lisp-satellite-network-08

Abstract

   This specification describes how the LISP architecture and protocols
   can be used over satellite network systems.  The LISP overlay runs on
   earth using the satellite network system in space as the underlay.

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 15 July 2026.

Copyright Notice

   Copyright (c) 2026 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.




Farinacci, et al.         Expires 15 July 2026                  [Page 1]

Internet-Draft         LISP for Satellite Networks          January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Mapping System  . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  EID Mobility  . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Satellite RLOCs and Underlay Routing  . . . . . . . . . . . .   7
   7.  Satellite Opportunistic Forwarding  . . . . . . . . . . . . .   7
   8.  Underlay Performance  . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   11. Test and Deployment Experience  . . . . . . . . . . . . . . .   8
     11.1.  GS-xTRs Direct (non-NAT) . . . . . . . . . . . . . . . .   9
     11.2.  GS-xTRs Direct (NAT) . . . . . . . . . . . . . . . . . .   9
     11.3.  GS-xTR to LISP-xTR (NAT) . . . . . . . . . . . . . . . .  10
     11.4.  GS-xTR Direct to non-LISP Host (NAT and Interwork) . . .  11
     11.5.  GS-xTR to non-LISP Host (NAT and Interwork)  . . . . . .  11
     11.6.  EID-Mobility Direct (non-NAT)  . . . . . . . . . . . . .  12
     11.7.  GS-xTRs Direct ISLs  . . . . . . . . . . . . . . . . . .  13
     11.8.  GS-xTR Laptop on Overlay and Underlay (NAT no
            Interwork) . . . . . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     12.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  17
   Appendix B.  Document Change Log  . . . . . . . . . . . . . . . .  18
     B.1.  Changes to draft-farinacci-lisp-satellite-network-08  . .  18
     B.2.  Changes to draft-farinacci-lisp-satellite-network-07  . .  18
     B.3.  Changes to draft-farinacci-lisp-satellite-network-06  . .  18
     B.4.  Changes to draft-farinacci-lisp-satellite-network-05  . .  18
     B.5.  Changes to draft-farinacci-lisp-satellite-network-04  . .  18
     B.6.  Changes to draft-farinacci-lisp-satellite-network-03  . .  18
     B.7.  Changes to draft-farinacci-lisp-satellite-network-02  . .  18
     B.8.  Changes to draft-farinacci-lisp-satellite-network-01  . .  19
     B.9.  Changes to draft-farinacci-lisp-satellite-network-00  . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   This specification describes how a LISP overlay structure can run on
   top of a satellite network underlay.  The approach is similar to how
   [I-D.haindl-lisp-gb-atn] is used in Aeronautical Telecommunications
   Networks and [I-D.farinacci-lisp-mobile-network] is used in cellular
   networks.






Farinacci, et al.         Expires 15 July 2026                  [Page 2]

Internet-Draft         LISP for Satellite Networks          January 2026


   This satellite deployment use-case requires no changes to the LISP
   architecture or standard protocol specifications.  In addition, any
   LISP implementations that run on a device with an existing satellite
   interface does not need to be upgraded.

   Even though an overlay should not concern itself with the operation
   of an underlay, the requirements from
   [I-D.lhan-problems-requirements-satellite-net] are considered but
   outside the scope of this document.

   The LISP overlay requirements are:

   1.  There will be no EID state in the satellite network underlay.

   2.  The satellite underlay is completely unaware of the overlay
       running over it.

   3.  The overlay requires the underlay network to deliver packets to
       RLOC addresses.

   4.  The underlay network can transport IPv4 or IPv6 packets and can
       be dual-stack.

   5.  When path optimization in the underlay is available, an RLOC-
       record can be a source route of satellite hops.


   The diagram below illustrates a 4 satellite system where each have
   Inter-Satellite-Links (ISLs) for connectivity between them and edge
   satellites with RF links to Ground Stations.  The EID connectivity to
   the xTRs is achieved via typical IP network connectivity where EIDs
   can be directly connected, one or more switch hops away, one or more
   router hops away, or any combination.


















Farinacci, et al.         Expires 15 July 2026                  [Page 3]

Internet-Draft         LISP for Satellite Networks          January 2026


                             in space (underlay)
       +--------------------------------------------------------------+
       |                                                              |
       |     sat     ISL     sat     ISL     sat     ISL     sat      |
       |    ))*((  -------  ))*((  -------  ))*((  -------  ))*((     |
       |      |                                               |       |
       |      |                                               |       |
       |      |up/down RF-link                 up/down RF-link|       |
       |      |                                               |       |
       |      |                                               |       |
       +------|-----------------------------------------------|-------+
              |                                               |
              |                                               |
              |               on earth (overlay)              |
       +------|-----------------------------------------------|-------+
       |      |                                               |       |
       |    GS-xTR             [mapping system]            GS-xTR     |
       |     /  \                                           /  \      |
       |    /    \                                         /    \     |
       |   /      \                                       /      \    |
       |  /        \                                     /        \   |
       | EIDs ... EIDs                                  EIDs ... EIDs |
       |                                                              |
       +--------------------------------------------------------------+

               Figure 1: Overlay on Earth, Underlay in Space

   The LISP mapping system runs on the earth-resident Internet and
   requires reachability by xTRs before LISP encapsulation can occur
   over the satellite network underlay.

   EIDs are known only to the overlay xTR nodes.  EIDs are not routable
   or require state in the satellite network.  This provides great value
   for scaling and EID mobility.


2.  Definition of Terms

   Inter-Satellite-Links (ISLs):  are phased-array laser wireless links
      that transmit within or across orbits in space to other
      satellites.  They are different than satellite downlinks which are
      RF links to Ground-Stations.

   xTR:  is a LISP data-plane device. xTR is the general term for ITR,
      ETR, or RTR.  The formal and authoritative definition is in
      [RFC9300].  When a LISP xTR runs on a ground station device, it is
      called a GS-xTR.




Farinacci, et al.         Expires 15 July 2026                  [Page 4]

Internet-Draft         LISP for Satellite Networks          January 2026


   Ground-Station (GS):  is a device on the ground that has wireless
      links to a satellite node in space
      [I-D.lhan-problems-requirements-satellite-net].  When a Ground-
      Station is an LISP xTR, it encapsulates and decapsulates packets
      sent and received on satellite links according to the forwarding
      procedures in [RFC9300] and [RFC9301].  A GS can also be part of
      the satellite network system but isn't deployed as a GS-xTR.  In
      this scenario, the GS is part of the underlay and assumes the
      satellite network system, with its attached ground stations,
      deliver RLOC addressed packets.  When a satellite is in relay mode
      (not using ISLs), a LISP RTR can be used to support traffic
      engineering where a GS-ITR encapsulates through a single satellite
      hop to a GS-RTR which decapsulates and re-encapsulates through
      another single satellite hop to a GS-ETR.  See [I-D.ietf-lisp-te]
      for details, and how LISP-TE can also be used with multiple
      satellite hops.

   source-GS-xTR:  is the LISP ITR which does a mapping system lookup to
      obtain and cache the destination-RLOC for the destination-EID.  It
      then encapsulates the packet and sends it on the uplink whatever
      satellite that is in coverage range.

   destination-GS-xTR:  is the LISP ETR which receives a LISP
      encapsulated packet on the downlink from the satellite that is in
      coverage range over it.  The outer header is stripped and packet
      is delivered to local EID on the ground.

   EID:  defined as an Endpoint-ID in [RFC9300].  An EID is assigned to
      devices that reside behind GS-xTRs and are registered to the LISP
      mapping system with a satellite network address which is used as
      an RLOC.

   RLOC:  defined as a Routing Locator in [RFC9300].  Within the scope
      of this specification, the RLOC is the satellite network address
      of a GS-xTR where the satellite network knows how to forward
      packets to this RLOC address.


3.  Overview

   Here is how a packet flow sequence occurs from a source-EID to a
   destination-EID when the underlay is a satellite network:

   1.  source-EID originates an IP packet to a destination-EID.  The
       addresses in the packet are EIDs.

   2.  The packet travels to the GS-xTR (source-GS-xTR) via traditional
       IP routing.



Farinacci, et al.         Expires 15 July 2026                  [Page 5]

Internet-Draft         LISP for Satellite Networks          January 2026


   3.  The source-GS-xTR does a map-cache lookup for destination-EID to
       obtain the RLOC for the destination-GS-xTR.

   4.  If map-cache lookup fails, a mapping system lookup is performed
       for destination-EID.

   5.  The source-GS-xTR LISP encapsulates the packet and sends it on
       the uplink to the satellite.  The RLOC addresses in the outer
       header are source-GS-xTR and destination-GS-xTR.

   6.  The satellite network delivers the packet to Ground-Station
       addressed as destination-GS-xTR.

   7.  The destination-GS-xTR decapsulates the LISP packet by stripping
       the outer header and delivering the packet to the destination-EID
       on the ground.


4.  Mapping System

   The LISP mapping system holds EID-to-RLOC-set mappings.  They are
   kept up to date by GS-xTRs and all the mechanisms from [RFC9301] are
   available for use.  The mappings can contain RLOCs that are not GS-
   xTRs thereby allowing load-splitting between both satellite and
   terrestrial paths.  The RLOC-set can also contain multicast RLOCs
   that can be reachable via satellite or terrestrial paths.

   All of IPv4, IPv6, and MAC EIDs can be registered to the mapping
   system to create multi-address-family L3 overlays as well as L2
   overlays on the satellite underlay.  That is, GS-xTR RLOCs can be
   used with these EID address types.

   Even though the satellite network is deployed to offer global
   Internet services, it may just carry routes and connectivity to GS-
   xTR addresses (their RLOC addresses).  If this is the case, the LISP
   critical infrastructure may not be reachable by the satellite network
   or the satellite nodes themselves.  Therefore, the mapping system can
   be deployed in GS-xTRs which can be reached by the satellite network.

   This specification recommends the mapping system reside on earth and
   if the satellite network does offer global Internet connectivity, the
   mapping system can reside anywhere on earth.  So even for rural based
   deployments of GS-xTRs, where the only connectivity is through a
   satellite interface link, the LISP critical infrastructure is always
   reachable.






Farinacci, et al.         Expires 15 July 2026                  [Page 6]

Internet-Draft         LISP for Satellite Networks          January 2026


   When satellite connectivity changes from a GS-xTR within its coverage
   range, the RLOC of the GS-xTR does not change.  Therefore, there is
   no need to update the mapping system when this happens.  This
   provides more scale to the total system since the LISP overlay is
   providing a level of indirection.

5.  EID Mobility

   EID-mobility [I-D.ietf-lisp-eid-mobility] is supported so devices can
   roam to other xTRs and are found by mapping system updates for remote
   xTRs encapsulating to the EID.  GS-xTRs learn EIDs on the ground
   dynamically via the mechanisms in [I-D.ietf-lisp-eid-mobility].

6.  Satellite RLOCs and Underlay Routing

   The address format of a GS-xTR RLOC depends on the design of the
   satellite network system.  The LISP RLOC formatting is flexible to
   accommodate new address types such as GPS coordinate based addressing
   or other forms of satellite addressing such as described in
   Section 7.  The only requirement is that they are routable by the
   satellite network system.

   If the satellite network supports IP forwarding and IP addresses are
   assigned to the RF-links on the GS-xTRs, then the satellite network
   just needs to make these "attachment point addresses" routable in the
   satellite network routing system.  And if the satellite network
   desires to scale the route state in its routing system, it can use
   prefix aggregation, a local design matter to the satellite network
   routing system.  When this is the case, the RLOC is a standard AFI
   encoded IPv4 or IPv6 address.

   If the satellite network underlay supports a source-routing
   mechanism, the same approach can be used as a LISP overlay on a
   terrestrial underlay running Segment Routing [RFC8754].  The source-
   route is encoded in an RLOC-record stored in the mapping system that
   is formatted as a list of satellite hop addresses.

7.  Satellite Opportunistic Forwarding

   A satellite constellation network could perform packet forwarding
   with little or no control-plane.  Using GPS (lat, long, alt)
   coordinate addressing, a satellte router could route packets
   physically closer to a destination GS-xTR.  This technique uses
   opportunistic forwarding where decisions are made at the instant a
   satellite router receives a packet and needs to choose an ISL
   interface to get the packet closer to the destination.





Farinacci, et al.         Expires 15 July 2026                  [Page 7]

Internet-Draft         LISP for Satellite Networks          January 2026


   The satellite router uses a packet header that contains the
   destination GPS address for the GS-xTR.  The source GS-xTR prepends
   this header on the packet before it sends it on the RF uplink to the
   nearest satellite overhead.  The satellte router can decide to send
   the packet to a next-hop satellite in the same orbit or to a next-hop
   satellite in an adjacent orbit, as long as the packet is getting
   closer to the destination GPS address.  A satellite router decides
   the proximity of adjacent orbits to determine if the packet is
   actually getting closer to the destination GPS address.

   For a given implementation, satellite routers in the same orbit or in
   adjacent orbits, which have good signal quality, exchange hello
   messages to advertise their position with a GPS address (lat, long,
   alt).  These messages are very small in size and are sent
   periodically with second-granular frequency.  This indicates to a
   satellite router, which direction to send the packet to get it closer
   to its GPS address location.

8.  Underlay Performance

   The RLOC probing procedures in [RFC9301] can provide underlay
   telemetry measurement [I-D.farinacci-lisp-telemetry] so the overlay
   can tell how well the satellite network is performing.  And if the
   underlay under performs or telemetry metrics change, the GS-xTR can
   select another RLOC, possibly to a terrestrial RLOC.

9.  Security Considerations

   There are no specific security considerations at this time for this
   use-case.  However, existing LISP security functionality documented
   in [RFC9301], [RFC9303], [I-D.ietf-lisp-eid-anonymity], and
   [I-D.farinacci-lisp-ecdsa-auth] can be used when the LISP overlay
   runs over a satellite network underlay.

   Data-plane encryption can be used to make the satellite underlay more
   secure.  See LISP Data-Plane Confidentiality [RFC8061] for more
   details.  This solution can work when packets take multiple satellite
   hops and/or Ground-Station hops.

10.  IANA Considerations

   There are no requests for IANA at this time.

11.  Test and Deployment Experience

   This section will describe the various LISP deployment combinations
   as well as progress updates of testing LISP over SpaceX's Starlink
   satellite network [STARLINK].



Farinacci, et al.         Expires 15 July 2026                  [Page 8]

Internet-Draft         LISP for Satellite Networks          January 2026


   In the following sections, the mapping system is running in a cloud
   provider VM and is accessible by all LISP xTRs in all the testing
   scenarios.  The LISP RTR also runs in the VM which is providing NAT-
   traversal services as well as LISP to non-LISP connectivity [RFC6832]
   via LISP-NAT.

11.1.  GS-xTRs Direct (non-NAT)

                               satellite(s)
                                  /   \
                                 /     \
                                /       \
                               /         \
                           dish           dish
                            |               |
                            |               |
                        wifi-router      wifi-router
                            ^                ^
                           / \              / \
                         GS-xTR            GS-xTR

           Figure 2: Each GS-xTR is one-hop away on WiFi Network

   This test has not been performed at this time since we are seeking
   more Starlink participants.  This section will be updated in the next
   document revision.  We are not sure we will be able to test this case
   since the Starlink provided wifi-routers are doing NAT translation.

11.2.  GS-xTRs Direct (NAT)

                               satellite(s)
                               /    |      \
                              /     |       \
                             /      |        \
                            /       |         \
                        dish       dish        dish
                         /          |             \
                        /           |              \
              wifi-router       colo-pop           wifi-router
                  ^                 |                  ^
                 / \                |                 / \
                GS-xTR          LISP-RTR            GS-xTR

           Figure 3: Each GS-xTR is one-hop away on WiFi Network

   This test has not been performed at this time since we are seeking
   more Starlink participants.  This section will be updated in the next
   document revision.  When this occurs, packets will flow from GS-xTR



Farinacci, et al.         Expires 15 July 2026                  [Page 9]

Internet-Draft         LISP for Satellite Networks          January 2026


   to RTR to GS-xTR since NAT-traversal is occurring in the wifi-
   routers.  The LISP-RTR is many hops away from the colocation-pop
   router, which has a direct connection to the satellite dish.

   Starlink only supports a carrier-grade NAT (CGNAT) solution so the
   Decentralized-NAT procedures in [I-D.farinacci-lisp-lispers-net-nat]
   have been challenging to get the above configuration to work.

11.3.  GS-xTR to LISP-xTR (NAT)

              satellite(s)
                 /   \
                /     \
               /       \                      LISP-RTR
              /         \                         |
          dish           dish                     |
            |             |                +-------------+
            |             |                | Terrestrial |
        wifi-router    colocation-pop ---- |  Internet   | ---- LISP-xTR
            ^                              +-------------+
           / \
          GS-xTR

          Figure 4: GS-xTR on WiFi Network to LISP-xTR in VM

   In this deployment scenario, the GS-xTR is a laptop, assigned an EID
   and communicating with the EID assigned to an xTR running in a cloud
   VM.  Since NAT-traversal is used on the wifi-routers, packets flow
   through the LISP-RTR.

   There are cases where Decentralized-NAT
   [I-D.farinacci-lisp-lispers-net-nat] can work from GS-xTR to LISP-xTR
   so packet flow does not traverse a third-party device like a LISP-
   RTR.  Testing experience has revealed that Cloud Providers implement
   more standard NAT functionality versus limited translation
   functionality of a CGNAT.

   The laptop is assigned EID 240.1.1.1 and LISP-xTR is assigned EID
   240.11.11.11.  Here is ping output initiated from the laptop:












Farinacci, et al.         Expires 15 July 2026                 [Page 10]

Internet-Draft         LISP for Satellite Networks          January 2026


      laptop -> ping -c 5 240.11.11.11
      PING 240.11.11.11 (240.11.11.11): 56 data bytes
      64 bytes from 240.11.11.11: icmp_seq=0 ttl=62 time=xx ms
      64 bytes from 240.11.11.11: icmp_seq=1 ttl=62 time=xx ms
      64 bytes from 240.11.11.11: icmp_seq=2 ttl=62 time=xx ms
      64 bytes from 240.11.11.11: icmp_seq=3 ttl=62 time=xx ms
      64 bytes from 240.11.11.11: icmp_seq=4 ttl=62 time=xx ms

      --- 240.11.11.11 ping statistics ---
      5 packets transmitted, 5 packets received, 0.0% packet loss

11.4.  GS-xTR Direct to non-LISP Host (NAT and Interwork)

                               satellite(s)
                               /    |     \
                              /     |      \
                             /      |       \
                            /       |        \
                        dish       dish      dish
                         /          |           \
                        /           |            \
              wifi-router       colo-pop         wifi-router
                  ^                 |                ^
                 / \                |               / \
                GS-xTR          LISP-RTR        non-LISP-Host

           Figure 5: GS-xTR and Host one-hop away on WiFi Network

   This test has not been performed at this time since we are seeking
   more Starlink participants.  This section will be updated in the next
   document revision.  When this occurs, packets will flow from GS-xTR
   to RTR to non-LISP-Host since both NAT-traversal and LISP-NAT support
   is required.  The LISP-RTR is many hops away from the colo-pop
   router, which has a direct connection to the satellite dish.

11.5.  GS-xTR to non-LISP Host (NAT and Interwork)















Farinacci, et al.         Expires 15 July 2026                 [Page 11]

Internet-Draft         LISP for Satellite Networks          January 2026


            satellite(s)
               /   \
              /     \
             /       \                      LISP-RTR
            /         \                         |
        dish           dish                     |
          |             |                +-------------+
          |             |                | Terrestrial |
      wifi-router    colocation-pop ---- |  Internet   | ---- non-LISP-Host
          ^                              +-------------+
         / \
        GS-xTR

           Figure 6: GS-xTR on WiFi to non-LISP-Host in VM

   In this deployment scenario, the GS-xTR is a laptop, assigned an EID
   and communicating with the non-EID assigned to non-LISP Host running
   in a cloud VM.  When this occurs, packets will flow from GS-xTR to
   RTR to non-LISP-Host since both NAT-traversal and LISP-NAT support is
   required.

   The laptop is assigned EID 240.1.1.1 and non-LISP-Host is the Google
   DNS server 8.8.8.8.  Here is ping output initiated from the laptop:

      laptop -> ping -c 5 -S 240.1.1.1 8.8.8.8
      PING 8.8.8.8 (8.8.8.8) from 240.1.1.1: 56 data bytes
      64 bytes from 8.8.8.8: icmp_seq=0 ttl=43 time=xx ms
      64 bytes from 8.8.8.8: icmp_seq=1 ttl=43 time=xx ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=43 time=xx ms
      64 bytes from 8.8.8.8: icmp_seq=3 ttl=43 time=xx ms
      64 bytes from 8.8.8.8: icmp_seq=4 ttl=43 time=xx ms

      --- 8.8.8.8 ping statistics ---
      5 packets transmitted, 5 packets received, 0.0% packet loss

   This may be a likely connectivity option since not all equipment
   connected to the satellite network will be LISP GS-xTRs.

11.6.  EID-Mobility Direct (non-NAT)












Farinacci, et al.         Expires 15 July 2026                 [Page 12]

Internet-Draft         LISP for Satellite Networks          January 2026


                               satellite(s)
                                  /   \
                                 /     \
                                /       \
                               /         \
                           dish           dish
                            |               |
                            |               |
                        wifi-router      wifi-router
                            ^                ^
                           / \              / \
                         GS-xTR            GS-xTR
                          |  |              |  |
                       EID1  EID2  ...   EID2  EID3

           Figure 7: Each GS-xTR is one-hop away on WiFi Network

   This test has not been performed yet.  In this test a device assigned
   with EID2 will be able to roam across GS-xTRs and keep connections up
   and running between EID1 and EID3.  This can also happen when EID2
   talks to a non-LISP host (via an RTR running LISP-NAT interworking
   services).

   In this test scenario, EIDs are assigned to devices that reside
   behind GS-xTRs (via wireless or wired links) and do not run LISP.
   The GS-xTRs, which run LISP, encapsulate/decapsulate packets on
   behalf of the host devices.  The GS-xTR RLOC addresses are routable
   by the satellite network (like in the previous test scenarios)
   allowing for the host devices to communicate while the satellite
   network keeps no state about EID addresses.

11.7.  GS-xTRs Direct ISLs

          satellite ---(ISL)--- satellite ---(ISL)--- satellite
              |                     |                     |
              |                     |                     |
              |                     |                     |
              |                     |                     |
             dish                  dish                  dish
              |                     |                     |
              |                     |                     |
          wifi-router           colo-pop              wifi-router
              ^                     |                     ^
             / \                    |                    / \
           GS-xTR               LISP-RTR               GS-xTR

           Figure 8: Each GS-xTR is one-hop away on WiFi Network




Farinacci, et al.         Expires 15 July 2026                 [Page 13]

Internet-Draft         LISP for Satellite Networks          January 2026


   This test has not been performed.  It will be tested when the
   satellite network has proven it can support ISL links and satellite
   routing reliably.

11.8.  GS-xTR Laptop on Overlay and Underlay (NAT no Interwork)

            satellite(s)
               /   \                                     overlay
              /     \                                  +-----------+
             /       \                        xTR ---- | LISP site | (240.11.11.11)
        dish           dish                    |       +-----------+
          |             |                      |
          |             |                +-------------+
      wifi-router    colocation-pop ---- |  Internet   | ---- non-LISP-Host
          ^                              +-------------+        underlay
         / \                                                    (8.8.8.8)
        GS-xTR

                Figure 9: GS-xTR on WiFi dual function

   The GS-xTR sends packet natively for non-EID destination 8.8.8.8:

   dino-macbook -> ping -c 5 8.8.8.8
   PING 8.8.8.8 (8.8.8.8): 56 data bytes
   64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=25.741 ms
   64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=17.197 ms
   64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=17.870 ms
   64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=21.806 ms
   64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=16.966 ms

   --- 8.8.8.8 ping statistics ---
   5 packets transmitted, 5 packets received, 0.0% packet loss
   round-trip min/avg/max/stddev = 16.966/19.916/25.741/3.400 ms

   The GS-xTR sends encapsulated packets for EID destination
   240.11.11.11:















Farinacci, et al.         Expires 15 July 2026                 [Page 14]

Internet-Draft         LISP for Satellite Networks          January 2026


dino-macbook -> ping -c 5 240.11.11.11
PING 240.11.11.11 (240.11.11.11): 56 data bytes
64 bytes from 240.11.11.11: icmp_seq=0 ttl=62 time=288.063 ms
64 bytes from 240.11.11.11: icmp_seq=1 ttl=62 time=325.043 ms
64 bytes from 240.11.11.11: icmp_seq=2 ttl=62 time=152.507 ms
64 bytes from 240.11.11.11: icmp_seq=3 ttl=62 time=191.567 ms
64 bytes from 240.11.11.11: icmp_seq=4 ttl=62 time=231.620 ms

--- 240.11.11.11 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 152.507/237.760/325.043/62.591 ms

dino-macbook -> mc 240.11.11.11

LISP Map-Cache for localhost:8080, hostname dino-macbook.lan, release 0.593

EID [1]240.11.11.11/32, uptime 0:00:39, ttl 1440m
  RLOC 18.237.14.154:43799, state unreach-state since 0:00:22, a-xtr1@tp-43799
    packet-count: 2, packet-rate: 0 pps, byte-count: 168, bit-rate: 0.0 mbps
    rtts [-1, -1, -1], hops [?/?, ?/?, ?/?], latencies [?/?, ?/?, ?/?]
  RLOC 34.217.110.112, state up-state since 0:00:39, RTR
    packet-count: 17, packet-rate: 0 pps, byte-count: 1428, bit-rate: 0.0 mbps
    rtts [0.121, -1, -1], hops [26/22, ?/?, ?/?], latencies [0.083/0.034, ?/?, ?/?]

12.  References

12.1.  Normative References

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              DOI 10.17487/RFC1700, October 1994,
              <https://www.rfc-editor.org/info/rfc1700>.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832,
              DOI 10.17487/RFC6832, January 2013,
              <https://www.rfc-editor.org/info/rfc6832>.

   [RFC8061]  Farinacci, D. and B. Weis, "Locator/ID Separation Protocol
              (LISP) Data-Plane Confidentiality", RFC 8061,
              DOI 10.17487/RFC8061, February 2017,
              <https://www.rfc-editor.org/info/rfc8061>.

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.




Farinacci, et al.         Expires 15 July 2026                 [Page 15]

Internet-Draft         LISP for Satellite Networks          January 2026


   [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
              Cabellos, Ed., "The Locator/ID Separation Protocol
              (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
              <https://www.rfc-editor.org/info/rfc9300>.

   [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
              Ed., "Locator/ID Separation Protocol (LISP) Control
              Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
              <https://www.rfc-editor.org/info/rfc9301>.

   [RFC9303]  Maino, F., Ermagan, V., Cabellos, A., and D. Saucez,
              "Locator/ID Separation Protocol Security (LISP-SEC)",
              RFC 9303, DOI 10.17487/RFC9303, October 2022,
              <https://www.rfc-editor.org/info/rfc9303>.

12.2.  Informative References

   [I-D.farinacci-lisp-ecdsa-auth]
              Farinacci, D. and E. Nordmark, "LISP Control-Plane ECDSA
              Authentication and Authorization", Work in Progress,
              Internet-Draft, draft-farinacci-lisp-ecdsa-auth-03, 4
              September 2018, <https://datatracker.ietf.org/doc/html/
              draft-farinacci-lisp-ecdsa-auth-03>.

   [I-D.farinacci-lisp-lispers-net-nat]
              Farinacci, D., "lispers.net LISP NAT-Traversal
              Implementation Report", Work in Progress, Internet-Draft,
              draft-farinacci-lisp-lispers-net-nat-11, 30 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-farinacci-
              lisp-lispers-net-nat-11>.

   [I-D.farinacci-lisp-mobile-network]
              Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
              for the Mobile Network", Work in Progress, Internet-Draft,
              draft-farinacci-lisp-mobile-network-18, 19 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-farinacci-
              lisp-mobile-network-18>.

   [I-D.farinacci-lisp-telemetry]
              Farinacci, D., Ouissal, S., and E. Nordmark, "LISP Data-
              Plane Telemetry", Work in Progress, Internet-Draft, draft-
              farinacci-lisp-telemetry-12, 15 April 2024,
              <https://datatracker.ietf.org/doc/html/draft-farinacci-
              lisp-telemetry-12>.

   [I-D.haindl-lisp-gb-atn]
              Haindl, B., Lindner, M., Moreno, V., Portoles-Comeras, M.,
              Maino, F., and B. Venkatachalapathy, "Ground-Based LISP



Farinacci, et al.         Expires 15 July 2026                 [Page 16]

Internet-Draft         LISP for Satellite Networks          January 2026


              for the Aeronautical Telecommunications Network", Work in
              Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27
              March 2023, <https://datatracker.ietf.org/doc/html/draft-
              haindl-lisp-gb-atn-09>.

   [I-D.ietf-lisp-eid-anonymity]
              Farinacci, D., Pillay-Esnault, P., and W. Haddad, "LISP
              EID Anonymity", Work in Progress, Internet-Draft, draft-
              ietf-lisp-eid-anonymity-17, 19 September 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              eid-anonymity-17>.

   [I-D.ietf-lisp-eid-mobility]
              Portoles-Comeras, M., Ashtaputre, V., Maino, F., Moreno,
              V., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
              Unified Control Plane", Work in Progress, Internet-Draft,
              draft-ietf-lisp-eid-mobility-17, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-
              eid-mobility-17>.

   [I-D.ietf-lisp-te]
              Farinacci, D., Kowal, M., Lahiri, P., and P. Pillay-
              Esnault, "LISP Traffic Engineering", Work in Progress,
              Internet-Draft, draft-ietf-lisp-te-24, 9 January 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-te-
              24>.

   [I-D.lhan-problems-requirements-satellite-net]
              Han, L., Li, R., Retana, A., Chen, M., Su, L., and T.
              Jiang, "Problems and Requirements of Satellite
              Constellation for Internet", Work in Progress, Internet-
              Draft, draft-lhan-problems-requirements-satellite-net-06,
              4 January 2024, <https://datatracker.ietf.org/doc/html/
              draft-lhan-problems-requirements-satellite-net-06>.

   [STARLINK] "High-Level SpaceX Starlink Technology
              Description",  https://www.starlink.com/technology,
              September 2022.

Appendix A.  Acknowledgments

   The authors would like to thank the LISP working group for their
   review of this specification.  A special thank you goes to Lin Han
   for email discussions on this topic.







Farinacci, et al.         Expires 15 July 2026                 [Page 17]

Internet-Draft         LISP for Satellite Networks          January 2026


Appendix B.  Document Change Log

B.1.  Changes to draft-farinacci-lisp-satellite-network-08

   *  Submitted January 2026.

   *  Update references and document timer.

B.2.  Changes to draft-farinacci-lisp-satellite-network-07

   *  Submitted July 2025.

   *  Update references and document timer.

B.3.  Changes to draft-farinacci-lisp-satellite-network-06

   *  Submitted January 2025.

   *  Update references and document timer.

B.4.  Changes to draft-farinacci-lisp-satellite-network-05

   *  Submitted August 2024.

   *  Update references and document timer.

B.5.  Changes to draft-farinacci-lisp-satellite-network-04

   *  Submitted February 2024.

   *  Update references and document timer.

B.6.  Changes to draft-farinacci-lisp-satellite-network-03

   *  Submitted August 2023.

   *  Add section about how an overlay interacts with a satellite
      underlay when it provides packet routing on ISLs using
      opportunitic forwarding with GPS addressing.

B.7.  Changes to draft-farinacci-lisp-satellite-network-02

   *  Submitted February 2023.

   *  Add references to proposed standard documents.

   *  Refer to lispsers.net Decentralized-NAT for testing direct xTR to
      xTR.



Farinacci, et al.         Expires 15 July 2026                 [Page 18]

Internet-Draft         LISP for Satellite Networks          January 2026


   *  Added test case where the GS-xTR is both on the underlay and the
      LISP overlay.

B.8.  Changes to draft-farinacci-lisp-satellite-network-01

   *  Submitted September 2022.

   *  Added text about how the mapping system is used in a rural
      location when the only Internet link available is the satellite
      link.

   *  Added the Test and Deployment Experience section to document what
      has been tested so far.

B.9.  Changes to draft-farinacci-lisp-satellite-network-00

   *  Initial posting April 2022.

Authors' Addresses

   Dino Farinacci
   lispers.net
   San Jose, CA
   United States of America
   Email: farinacci@gmail.com


   Victor Moreno
   Independent
   Mountain View, CA
   United States of America
   Email: victor@magooit.com


   Padma Pillay-Esnault
   Independent
   Santa Clara, CA
   United States of America
   Email: padma.ietf@gmail.com












Farinacci, et al.         Expires 15 July 2026                 [Page 19]
