Network Working Group D. Farinacci Internet-Draft lispers.net Intended status: Experimental V. Moreno Expires: 1 February 2025 P. Pillay-Esnault Independent 31 July 2024 LISP for Satellite Networks draft-farinacci-lisp-satellite-network-05 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 1 February 2025. 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. Farinacci, et al. Expires 1 February 2025 [Page 1] Internet-Draft LISP for Satellite Networks July 2024 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-05 . . 18 B.2. Changes to draft-farinacci-lisp-satellite-network-04 . . 18 B.3. Changes to draft-farinacci-lisp-satellite-network-03 . . 18 B.4. Changes to draft-farinacci-lisp-satellite-network-02 . . 18 B.5. Changes to draft-farinacci-lisp-satellite-network-01 . . 18 B.6. 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. 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. Farinacci, et al. Expires 1 February 2025 [Page 2] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 3] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 4] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 5] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 6] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 7] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 8] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 9] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 10] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 11] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 12] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 13] Internet-Draft LISP for Satellite Networks July 2024 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 1 February 2025 [Page 14] Internet-Draft LISP for Satellite Networks July 2024 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, . [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, . [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality", RFC 8061, DOI 10.17487/RFC8061, February 2017, . [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, . Farinacci, et al. Expires 1 February 2025 [Page 15] Internet-Draft LISP for Satellite Networks July 2024 [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, . [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, . [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, . 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, . [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-08, 17 June 2024, . [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, . [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, . [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 1 February 2025 [Page 16] Internet-Draft LISP for Satellite Networks July 2024 for the Aeronautical Telecommunications Network", Work in Progress, Internet-Draft, draft-haindl-lisp-gb-atn-09, 27 March 2023, . [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-16, 19 February 2024, . [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-14, 30 April 2024, . [I-D.ietf-lisp-te] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering", Work in Progress, Internet-Draft, draft- ietf-lisp-te-19, 23 June 2024, . [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, . [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 1 February 2025 [Page 17] Internet-Draft LISP for Satellite Networks July 2024 Appendix B. Document Change Log B.1. Changes to draft-farinacci-lisp-satellite-network-05 * Submitted August 2024. * Update references and docment timer. B.2. Changes to draft-farinacci-lisp-satellite-network-04 * Submitted February 2024. * Update references and docment timer. B.3. 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.4. 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. * Added test case where the GS-xTR is both on the underlay and the LISP overlay. B.5. 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. Farinacci, et al. Expires 1 February 2025 [Page 18] Internet-Draft LISP for Satellite Networks July 2024 B.6. 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 1 February 2025 [Page 19]