IPv6 Wireless Access in Satellite Networks (IPWASN): Problem Statement and Use Cases
draft-lee-6man-ipv6-satellite-networks-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jimin Lee , Jaehoon Paul Jeong , Bien Aime Mugabarigira , Takuya Yoshihiro | ||
| Last updated | 2026-05-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-6man-ipv6-satellite-networks-00
6man Working Group J. Lee, Ed.
Internet-Draft J. Jeong, Ed.
Intended status: Informational B.A. Mugabarigira
Expires: 29 November 2026 Sungkyunkwan University
T. Yoshihiro
Wakayama University
28 May 2026
IPv6 Wireless Access in Satellite Networks (IPWASN): Problem Statement
and Use Cases
draft-lee-6man-ipv6-satellite-networks-00
Abstract
This document describes use cases and a problem statement for IPv6
Wireless Access in Satellite Networks (IPWASN). IPWASN aims at the
IPv6-based wireless access in Non-Terrestrial Networks (NTNs), that
is, satellite networks. It considers NTN characteristics such as
dynamic topology, multi-hop communication over inter-satellite links,
High-Altitude Platform Station (HAPS)-assisted relay paths, frequent
handovers, variable link quality, and intermittent connectivity.
Based on these characteristics, this document identifies key
challenges in applying existing IPv6 protocols to NTN environments.
It also analyzes the applicability of current IPv6 mechanisms and
outlines requirements to support efficient data forwarding, Quality
of Service (QoS), Segment Routing (SR)-based traffic engineering, and
connectivity in satellite-based networks.
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 29 November 2026.
Lee, et al. Expires 29 November 2026 [Page 1]
Internet-Draft IPWASN May 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPWASN Reference Scenario . . . . . . . . . . . . . . . . . . 6
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7.1. Neighbor Discovery and First-hop Security . . . . . . . . 20
7.2. Mobility Management and Control-plane Security . . . . . 21
7.3. Trajectory, Contact, and Privacy Considerations . . . . . 21
7.4. Other Threats . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
Non-Terrestrial Networks (NTNs), which integrate satellites, High-
Altitude Platform Stations (HAPS), and terrestrial networks, have
emerged as a key technology for next-generation wireless
communication systems that aim to provide seamless global
connectivity. In particular, Low Earth Orbit (LEO) satellite
networks enable wide-area coverage and continuous service
availability in regions where terrestrial infrastructure is limited
or unavailable, such as maritime, aeronautical, and remote
environments. With the rapid deployment of large-scale satellite
constellations, NTNs are increasingly considered an essential
component for extending communication services beyond the limitations
of ground-based infrastructures.
Lee, et al. Expires 29 November 2026 [Page 2]
Internet-Draft IPWASN May 2026
To support NTN environments, standardization bodies have defined
technologies that incorporate satellite communications into existing
mobile network architectures. In 3GPP Release 17 [TS-23.501-Rel17],
the fundamental architecture and procedures for NTN support are
specified, including adaptations for satellite-specific
characteristics such as propagation delay and Doppler effects.
Furthermore, 3GPP Release 18 [TS-23.501-Rel18] extends these
capabilities by addressing enhanced features such as multi-link
operation, handover optimization, and the utilization of Inter-
Satellite Links (ISLs). These efforts aim to enable seamless
integration between satellite networks and terrestrial networks while
ensuring consistent service delivery across heterogeneous
environments.
In addition, routing and packet delivery mechanisms for satellite
networks have been investigated by the IETF. A routing architecture
for satellite networks has been defined, taking into account ISLs and
dynamic link environments [RFC9717]. Segment Routing (SR)
architecture [RFC8402] and the data plane of Multi-Protocol Label
Switching (MPLS) [RFC8660] provide source-routing mechanisms that may
be useful for traffic engineering in satellite networks, while SRv6
mechanisms based on the IPv6 Segment Routing Header [RFC8754] provide
an IPv6-native approach for steering packets through selected network
paths. This work highlights the need for network-layer mechanisms
that can adapt to rapidly changing connectivity conditions and
provide reliable data delivery across multi-hop satellite paths.
Meanwhile, the IETF has standardized a wide range of IPv6-based
mechanisms to support communications in highly dynamic and mobile
environments. Based on the IPv6 specification [RFC8200], mobility
management protocols such as Mobile IPv6 [RFC6275], Proxy Mobile IPv6
[RFC5213], Network Mobility (NEMO) Basic Support [RFC3963], and
Distributed Mobility Management (DMM) [RFC7429] have been defined to
support IP-based communication across heterogeneous access networks.
Furthermore, IPv6 Wireless Access in Vehicular Environments (IPWAVE)
has identified key challenges related to high mobility and dynamic
topology [RFC9365]. These characteristics are also present in NTN
environments, making such prior work directly relevant for extending
IPv6-based communication to satellite networks.
HAPS has become an important component in NTN architectures. The ITU
describes HAPS systems as platforms that can support broadband
connectivity and transmission links between mobile networks and core
networks [ITU-HAPS]. HAPS may provide relay, aggregation, and
coverage-extension functions between terrestrial users, LEO
satellites, and ground stations. Academic studies on HAPS
architectures have identified backhaul, public-safety, Internet of
Things (IoT), and wide-area wireless service scenarios as important
Lee, et al. Expires 29 November 2026 [Page 3]
Internet-Draft IPWASN May 2026
deployment targets [HAPS-ARCH]. For IPWASN, HAPS introduces
additional forwarding choices and additional operational constraints.
This is because traffic may traverse satellite-only, HAPS-assisted,
or hybrid satellite-HAPS-ground paths, depending on service
requirements and link availability.
This document considers IPv6 Wireless Access in Satellite Networks
(IPWASN). This IPWASN aims at the IPv6-based wireless access in
NTNs. It presents use cases and a problem statement of IPWASN to
reflect the characteristics of satellite networks. The scope of this
document includes LEO satellite-based NTN environments, multi-hop
communication using ISLs, HAPS-assisted relay paths, dynamic
topology, handover, intermittent connectivity, the support of Quality
of Service (QoS), and IPv6-based routing, forwarding, traffic
engineering, and mobility management. This document does not define
a new protocol. Instead, it identifies the gaps, requirements by
analyzing the existing IPv6 protocols, MPLS, SR-MPLS, SRv6, and
mobility-related mechanisms. They may need to be profiled, combined,
or extended for NTN environments.
In particular, data forwarding issues, including multi-hop packet
delivery, path selection, service continuity, and connectivity
maintenance under dynamic network conditions, remain important
considerations. This document also discusses QoS considerations for
latency-sensitive and bandwidth-intensive services such as text
messaging, emergency data, voice, video streaming, video
conferencing, and live media delivery over HTTP/3 [RFC9114] and QUIC
[RFC9000]. Therefore, the further analysis of IPv6-based mechanisms
is required to support efficient and reliable communications in IPv6
satellite networks.
Studies on trajectory-based data forwarding in vehicular networks
show that predictable movement information can be used to improve
multihop forwarding decisions. Travel Prediction-based Data
Forwarding (TPD) uses shared trajectories to predict encounter
opportunities and construct forwarding sequences for delay-and-
delivery-ratio-aware packet delivery [TPD-COMNET-2015]. Trajectory-
based Statistical Forwarding (TSF) uses a destination trajectory and
packet-delay distributions to select rendezvous target points for
infrastructure-to-mobile delivery [TSF-TMC-2012]. Although satellite
networks differ from vehicular networks, IPWASN can use similar
design insights such as predictable trajectories of satellite and
HAPS, and scheduled contact opportunities can be exploited for path
computation, forwarding preparation, and disruption-tolerant packet
delivery.
Lee, et al. Expires 29 November 2026 [Page 4]
Internet-Draft IPWASN May 2026
2. Terminology
This section provides definitions of the key terms and concepts used
throughout this document. The terminology is intended to establish a
common understanding of the components and operational
characteristics of IPv6-based wireless access in satellite networks.
* Non-Terrestrial Networks (NTNs): NTN refers to a network
architecture that integrates satellite systems, High-Altitude
Platform Stations (HAPS), and terrestrial networks to provide
wide-area communication services. In this document, NTN primarily
focuses on satellite-based communication systems that extend
network coverage beyond the limitations of ground-based
infrastructures.
* Low Earth Orbit (LEO): LEO refers to satellites operating in low
Earth orbit, typically characterized by relatively low altitude
and high mobility. Due to their orbital movement, LEO satellites
introduce dynamic network topology and frequent link changes,
which significantly impact routing and data forwarding in NTN
environments.
* Inter-Satellite Link (ISL): ISL refers to communication links
established directly between satellites. These links enable
multi-hop data forwarding across satellite networks without
relying solely on ground stations, and play a key role in
extending connectivity and improving network resilience in NTN
environments.
* User Equipment (UE): UE denotes end-user devices that access
network services through NTN infrastructure. In this document, UE
may include mobile terminals, IoT devices, or other communication
endpoints that connect to satellite networks via service links.
* Ground Station (GS): GS refers to terrestrial infrastructure that
connects satellite networks to ground-based networks or the
Internet. Ground stations serve as gateways for data exchange
between NTN and terrestrial networks, supporting feeder links and
network interconnection.
* High-Altitude Platform Station (HAPS): HAPS refers to an aerial
platform operating in the stratosphere and used to provide
communication services or relay connectivity. In IPWASN, a HAPS
may act as an intermediate node between UE, LEO satellites, ground
stations, and terrestrial networks. An HAPS can assist service
continuity, improve coverage in remote or disaster areas, and
provide an additional path for traffic engineering when direct
satellite-to-ground connectivity is limited.
Lee, et al. Expires 29 November 2026 [Page 5]
Internet-Draft IPWASN May 2026
* QoS Class: A QoS class refers to a group of application flows with
similar requirements for latency, jitter, packet loss, bandwidth,
reliability, and priority. IPWASN considers QoS classes such as
text and emergency data, voice, real-time video, bulk data, and
delay-tolerant IoT traffic.
* Segment Routing (SR): SR refers to source routing based on an
ordered list of instructions called segments [RFC8402]. SR can be
instantiated over the MPLS data plane as SR-MPLS [RFC8660] or over
IPv6 as SRv6 using the Segment Routing Header and SRv6 network
programming mechanisms [RFC8754] [RFC8986].
3. IPWASN Reference Scenario
This section describes a reference scenario for IPv6 Wireless Access
in Satellite Networks (IPWASN) considered in this document. This
scenario illustrates an NTN environment where a User Equipment (UE)
accesses IPv6 services through a network composed of LEO satellites,
Inter-Satellite Links (ISLs), HAPS nodes, ground stations, and
terrestrial networks. The purpose of this scenario is to provide a
common understanding of the network structure and communication paths
used in the subsequent problem statement and use cases.
In this scenario, UEs may connect directly to nearby LEO satellites
through service links or may connect through an HAPS relay when the
HAPS provides a better access path, a more stable relay, or
additional coverage. The satellites are interconnected via ISLs,
forming a multi-hop network in space. HAPS nodes may provide
intermediate relay, aggregation, and backhaul functions between a UE,
satellites, ground stations, and terrestrial networks. Ground
stations serve as gateways between the satellite/HAPS network and
terrestrial networks, enabling access to the IPv6 Internet.
Depending on the availability of feeder links, HAPS links, ISLs, and
the relative positions of satellites and ground stations, data
packets may be delivered directly to a ground station, forwarded
across multiple satellites, forwarded through an HAPS, or delivered
through a hybrid satellite-HAPS-ground path before reaching a
gateway.
Due to the orbital movement of LEO satellites, the network topology
changes continuously over time. As satellites move along their
trajectories, service links between UEs and satellites are frequently
re-established, and ISLs among satellites may also be dynamically
created or reconfigured. HAPS nodes are more stable than LEO
satellites from the viewpoint of ground users, but they still
introduce additional link-state, capacity, and coverage constraints.
As a result, an End-to-End (E2E) communication path between a UE and
the terrestrial network may vary over time even for ongoing sessions.
Lee, et al. Expires 29 November 2026 [Page 6]
Internet-Draft IPWASN May 2026
In addition, connectivity between satellites and ground stations may
not always be available due to geographic constraints or satellite
visibility. In such cases, packets may need to be forwarded across
multiple satellite hops, through an HAPS, or through another
available relay until a suitable ground station becomes reachable.
This introduces challenges in path selection, data forwarding, QoS
preservation, and connectivity maintenance in dynamic network
conditions.
+-------------------------------------------+
| Satellite Network |
| |
| +---------+ ISL +---------+ |
| | LEO Sat | <----> | LEO Sat | |
| | A | | B | |
| +----+----+ +----+----+ |
| ^ ^ |
| | ISL | ISL |
| v v |
| +----+----+ ISL +----+----+ |
| | LEO Sat | <----> | LEO Sat | |
| | C | | D | |
| +----+----+ +----+----+ |
+-------^------------------^----------------+
| |
Service Feeder/
Link ISL Path
| |
v v
+-------+---+ +-----+-----+
| UE | | HAPS |
| / User | <----> | Relay / |
| Station | Access | Backhaul |
+-----------+ Link +---^-+^----+
| \
| \ HAPS-GS Link
v \
+----+----+ \
| Ground | \
| Station | \
| Gateway | \
+----^----+ \
| \
v v
+----+----+ +---+---+
| IPv6 | | Edge |
| Internet| | Cloud |
+---------+ +-------+
Lee, et al. Expires 29 November 2026 [Page 7]
Internet-Draft IPWASN May 2026
Figure 1: Reference Scenario for HAPS-assisted IPv6 Wireless
Access in Satellite Networks
Figure 1 shows the reference scenario considered in this document.
The scenario includes service links between a UE and satellites, HAPS
access and backhaul links, ISLs among satellites, feeder links
between satellites and ground stations, and IPv6 connectivity toward
terrestrial networks. This follows the high-level view of user
stations, satellites, gateways, and the Internet described in
[RFC9717], while expanding the satellite network to show multiple LEO
satellites connected by ISLs and HAPS-assisted relay paths. This
reference scenario serves as a baseline for discussing the challenges
of IPv6-based communication in NTN environments, including dynamic
topology, multi-hop data forwarding across multiple satellites, HAPS-
assisted forwarding, QoS support, traffic engineering, handover, and
intermittent connectivity.
4. Problem Statement
Non-Terrestrial Networks (NTNs) introduce network characteristics
that are fundamentally different from those of conventional
terrestrial networks due to high satellite mobility, heterogeneous
aerial and space links, and large-scale distributed network
structures. These characteristics create several challenges for
IPv6-based communication in satellite and HAPS-assisted NTN
environments.
* *Dynamic Topology and Route Instability:* In LEO satellite
environments, a network topology changes continuously over time
due to the orbital movement of satellites. Service links between
a UE and satellites, ISLs, satellite-to-HAPS links, and HAPS-to-
ground links may be dynamically established, reconfigured, or
disconnected according to satellite movement, platform
availability, weather, spectrum conditions, and network policy.
These frequent topology changes may affect routing table
convergence and make stable path maintenance difficult. As a
result, existing IPv6 routing mechanisms, which are primarily
designed for more stable terrestrial environments, may experience
limitations in NTN environments.
* *Complexity of Multi-hop Packet Delivery:* Satellite networks
commonly rely on multi-hop communication through ISLs in order to
provide wide-area connectivity. Depending on satellite
visibility, HAPS availability, and gateway reachability, packets
may traverse multiple satellites, an HAPS relay, or a hybrid
satellite-HAPS-ground path before reaching terrestrial networks.
However, in dynamic topology environments, forwarding paths may
continuously change, potentially causing packet loss, jitter,
Lee, et al. Expires 29 November 2026 [Page 8]
Internet-Draft IPWASN May 2026
reordering, route instability, and forwarding inefficiency. Path
selection and network state awareness therefore remain important
considerations in IPv6-based NTN communication.
* *HAPS-assisted Relay and Hybrid Path Management:* HAPS can improve
coverage and provide relay or backhaul capacity, especially in
remote, maritime, aeronautical, and disaster-recovery
environments. However, the introduction of HAPS also creates
hybrid paths with different delay, bandwidth, link-layer, and
operational characteristics. A path through an HAPS may be
preferable for some flows because of coverage or gateway
visibility, while a direct satellite path may be preferable for
other flows because of capacity, policy, or topology. IPv6
forwarding mechanisms need to account for these heterogeneous path
properties without creating excessive control-plane churn.
* *Frequent Handover and Session Continuity:* Due to the rapid
movement of LEO satellites, a UE may frequently switch serving
satellites within short periods of time. In HAPS-assisted
environments, the UE may also switch between satellite access,
HAPS access, and terrestrial access depending on coverage and
service policy. Such frequent handovers may affect IP session
continuity and increase signaling overhead for mobility management
procedures. Existing mobility management mechanisms, such as
Mobile IPv6 and Proxy Mobile IPv6, were primarily developed for
terrestrial wireless environments and may encounter challenges in
NTN environments characterized by long propagation delays and
dynamic connectivity conditions.
* *Long Delay, Jitter, and Link Variability:* Satellite
communication environments typically experience relatively long
RTT and varying link quality due to altitude, propagation
distance, Doppler effects, atmospheric conditions, antenna
tracking, gateway visibility, and congestion. HAPS-assisted paths
may reduce some propagation delay compared with satellite-only
paths, but may introduce different capacity and interference
constraints. These characteristics may affect transport
protocols, congestion control, path selection, and resource
utilization in IPv6-based satellite communication.
* *QoS Support for Heterogeneous Application Classes:* IPWASN needs
to support application classes with very different service
expectations. Text messaging and emergency data may tolerate
delay but require high reliability and priority treatment. Voice
requires bounded delay and jitter. Video streaming requires
adequate throughput and controlled packet loss to avoid
rebuffering. Video conferencing and live media require low
conversational latency, low jitter, and sufficient uplink and
Lee, et al. Expires 29 November 2026 [Page 9]
Internet-Draft IPWASN May 2026
downlink capacity. IoT traffic may be delay-tolerant and energy
constrained. DiffServ provides a framework for packet
classification and per-hop behaviors in IP networks [RFC2474], and
RFC 4594 provides configuration guidance for service classes
[RFC4594]. However, NTN environments require further analysis of
how such QoS classes can be preserved across satellite handover,
HAPS relay changes, ISL reconfiguration, and gateway changes.
* *Traffic Engineering and Programmable Forwarding:* Multi-hop
satellite paths may need to be selected according to service
requirements such as latency, jitter, bandwidth, reliability,
priority, policy, and gateway availability. SR-MPLS [RFC8660] can
steer traffic through MPLS label stacks, while SRv6 mechanisms
[RFC8754] [RFC8986] can steer packets using IPv6-based segment
identifiers and network programming behaviors. SR Policy
[RFC9256] provides a framework for steering traffic into source-
routed policies with candidate paths and optimization objectives.
However, NTN environments require further analysis of segment-list
size, Maximum SID Depth constraints, SRH overhead, MPLS label-
stack depth, control-plane scalability, policy recomputation
frequency, and fast recovery during satellite mobility and link
changes.
* *Direct-to-Device Satellite Access:* Direct smartphone access to
satellite networks is emerging for messaging, emergency data, and
limited data services. Such access may be extended in the future
toward richer voice or video services, but bandwidth, latency,
antenna, power, and duplexing constraints remain significant.
IPWASN needs to consider how direct-to-device satellite access
fits into the broader IPv6 architecture, including how service
classes are mapped, how emergency traffic is prioritized, and how
traffic is routed when full-duplex or high-throughput service
requires dedicated ground stations, HAPS relays, or optical/laser
links.
Lee, et al. Expires 29 November 2026 [Page 10]
Internet-Draft IPWASN May 2026
Another important characteristic of satellite networks is that
satellite movement and orbital trajectories are generally
predictable. Unlike many terrestrial mobile environments, future
satellite positions and link availability can often be estimated in
advance. Such predictability may provide opportunities for improving
routing decisions, SR Policy computation, forwarding efficiency,
handover preparation, and connectivity management in NTN
environments. TPD and TSF demonstrate that trajectory information
can reduce forwarding uncertainty by predicting encounters, selecting
suitable forwarders or rendezvous points, and bounding delivery
probability or delay [TPD-COMNET-2015] [TSF-TMC-2012]. In IPWASN,
analogous information may include satellite ephemeris data, HAPS
flight plans, scheduled ISL availability, gateway visibility windows,
and predicted UE-to-satellite contact intervals.
In addition, NTN environments may experience intermittent
connectivity due to satellite movement, temporary link disruptions,
limited gateway visibility, HAPS availability, weather, or disaster
conditions. In some situations, E2E paths between a UE and
terrestrial networks may not always be immediately available.
Therefore, additional considerations for handling intermittent
connectivity and maintaining communication reliability are required
in IPv6-based NTN environments.
Consequently, IPv6 communication in NTN environments requires further
analysis regarding how existing IPv6 protocols and mechanisms can
support dynamic topology adaptation, HAPS-assisted forwarding, QoS
classification, SR-MPLS/SRv6-based traffic engineering, multi-hop
data forwarding, mobility management, and intermittent connectivity.
Additional requirements reflecting the characteristics of satellite
networks also need to be identified.
5. Use Cases
This section describes representative use cases in which IPWASN can
be utilized in NTN environments. These use cases illustrate
communication scenarios that involve satellite mobility, HAPS-
assisted relay paths, multi-hop data forwarding, intermittent
connectivity, QoS variability, and heterogeneous network integration.
The purpose of these scenarios is to identify key considerations and
requirements for IPv6-based communication in satellite networks.
* *Remote Area Connectivity:* In remote environments such as
maritime regions, deserts, mountainous areas, and rural regions
where terrestrial communication infrastructure is limited or
unavailable, a UE may rely on satellite networks to access IPv6
services and Internet connectivity. HAPS may be deployed as a
regional relay or backhaul node to extend coverage and reduce the
Lee, et al. Expires 29 November 2026 [Page 11]
Internet-Draft IPWASN May 2026
dependency on immediate satellite-to-ground visibility. In such
environments, direct communication between end users and
terrestrial networks may not always be possible, requiring packets
to be forwarded through multiple satellites, through HAPS, or
through a hybrid path. Maintaining IPv6 connectivity, supporting
multi-hop packet delivery, and selecting paths according to link
availability and QoS class become important considerations.
* *Maritime and Aeronautical Communications:* Moving platforms such
as ships and aircraft require continuous network connectivity
while traveling across wide geographic regions. Communication may
depend not only on direct satellite access but also on packet
forwarding through multiple satellites or HAPS nodes before
reaching a ground station connected to terrestrial networks. As
aircraft or vessels move across satellite and HAPS coverage areas,
frequent handovers may occur. Such handovers may affect session
continuity and introduce signaling overhead. Long-distance
communication over satellite links may also experience long
propagation delays and varying link quality, affecting E2E data
delivery performance.
* *UAV and Aerial Network Integration:* Unmanned Aerial Vehicles
(UAVs), HAPS, and other aerial platforms may utilize NTN
connectivity for data collection, surveillance, environmental
monitoring, or communication relay services. In particular, UAVs
and HAPS can operate as intermediate communication nodes in areas
where terrestrial infrastructure is unavailable or partially
disconnected. Communication paths may involve multiple network
layers consisting of satellites, HAPS, UAVs, and terrestrial
nodes. Since these platforms have different mobility and coverage
characteristics, IPv6-based communication mechanisms need to
consider dynamic path selection, multi-hop forwarding, and
connectivity maintenance in heterogeneous aerial networking
environments.
* *Disaster Recovery Communications:* During disaster situations,
terrestrial communication infrastructure may become damaged,
overloaded, or temporarily unavailable. Satellite networks and
HAPS can provide emergency communication services for first
responders, public safety systems, and affected users. An HAPS
may provide local coverage, aggregation, or backhaul when
terrestrial towers are unavailable, while LEO satellites may
provide wide-area reachability. Disaster environments may involve
unstable topology conditions, unpredictable traffic patterns, and
intermittent network connectivity. Emergency traffic may require
priority forwarding and resilient path selection across satellite
and HAPS relays.
Lee, et al. Expires 29 November 2026 [Page 12]
Internet-Draft IPWASN May 2026
* *Direct Smartphone Access to Satellite Networks:* Smartphones or
small mobile terminals may access satellite services directly for
text messaging, emergency notification, location reporting, or
low-rate data exchange. Such services may be delay-tolerant but
often require high reliability and priority handling. Future
voice, video, or full-duplex services may require additional
network support, including HAPS relays, dedicated ground stations,
higher-capacity feeder links, or optical inter-satellite or
satellite-ground links. IPWASN should consider how IPv6
addressing, QoS marking, mobility, and traffic steering apply to
direct-to-device access.
* *Video Streaming and Interactive Media over NTN:* End users in
remote, maritime, aeronautical, or disaster-recovery environments
may use NTN access for video streaming, live broadcasting, video
conferencing, online education, and cloud-based collaboration.
These services include downlink-heavy cases such as video
streaming and uplink-heavy or bidirectional cases such as live
video upload and conferencing. HTTP/3 over QUIC can reduce head-
of-line blocking at the transport layer and supports encrypted,
multiplexed application traffic over UDP, but satellite mobility,
long RTT, handover, changing ISL paths, and HAPS relay changes can
still affect bitrate adaptation, startup delay, rebuffering, and
conversational latency. Therefore, IPWASN needs to consider how
QoS-aware forwarding, traffic engineering, and mobility support
can preserve media quality across dynamic NTN paths.
* *IoT and Intermittent Connectivity Services:* Satellite-based IoT
environments may include sensors, monitoring systems, and low-
power communication devices deployed in remote or infrastructure-
limited regions. Such devices may periodically connect to
satellite or HAPS networks to transmit sensing information or
operational data. Continuous E2E connectivity may not always be
available due to satellite movement, limited visibility, HAPS
availability, or power constraints of IoT devices. As a result,
data delivery may rely on intermittent communication
opportunities, temporary packet buffering, or delayed forwarding
mechanisms. IPv6-based communication in NTN environments needs to
consider intermittent connectivity and efficient data delivery
mechanisms for satellite-based IoT services.
Lee, et al. Expires 29 November 2026 [Page 13]
Internet-Draft IPWASN May 2026
6. Requirements
This section describes key requirements for supporting IPWASN based
on the problem statements and use cases discussed in previous
sections. These requirements are intended to identify important
considerations for applying IPv6-based communication mechanisms in
NTN environments characterized by dynamic topology, satellite
mobility, HAPS-assisted relay paths, multi-hop communication, QoS
variability, traffic engineering, and intermittent connectivity.
* *HAPS-assisted NTN Architecture Support:* IPWASN should support
architectures in which HAPS nodes are used as relay, access,
aggregation, or backhaul nodes between a UE, LEO satellites,
ground stations, and terrestrial networks. IPv6 mechanisms should
be able to represent HAPS-assisted paths as first-class forwarding
alternatives rather than as an external non-IP transport detail.
The architecture should allow satellite-only, HAPS-assisted,
terrestrial, and hybrid paths to be selected according to
reachability, QoS class, policy, and gateway availability.
* *Adaptation to Dynamic Topology:* Due to the orbital movement of
satellites, NTN environments experience continuous network
topology change. IPv6 routing and forwarding mechanisms need to
adapt to frequent topology changes while minimizing routing
instability, convergence delay, and signaling overhead.
Predictable satellite movement patterns and HAPS coverage
characteristics may provide opportunities for improving routing,
pre-computing candidate paths, preparing handovers, and reducing
service disruption.
* *Support for Multi-hop and Hybrid Data Forwarding:* Satellite
networks commonly rely on multi-hop communication through ISLs to
provide wide-area connectivity. HAPS-assisted deployments add
additional hybrid forwarding choices through satellite-HAPS-ground
and UE-HAPS-ground paths. IPv6-based communication mechanisms
should support efficient packet forwarding across multiple
satellite and HAPS hops while considering varying network
conditions, dynamic path changes, QoS requirements, and gateway
availability. Path selection and forwarding efficiency remain
important considerations for reliable E2E communication in NTN
environments.
* *Trajectory- and Contact-aware Forwarding:* IPWASN should consider
forwarding mechanisms that can use predictable satellite, HAPS,
and gateway contact information. Inspired by TPD and TSF,
forwarding decisions may use predicted encounters, contact
windows, target rendezvous points, delivery probability, expected
delivery delay, and source-routed forwarding sequences
Lee, et al. Expires 29 November 2026 [Page 14]
Internet-Draft IPWASN May 2026
[TPD-COMNET-2015] [TSF-TMC-2012]. Such mechanisms should account
for stale or inaccurate prediction information, packet header
overhead for carrying forwarding sequences, scalability of
contact-graph computation, and consistency with IPv6, SR-MPLS,
SRv6, and DTN-related mechanisms.
* *Mobility Management and Session Continuity:* A UE may frequently
change serving satellites due to the rapid movement of LEO
satellites. The UE may also switch between direct satellite
access, HAPS access, and terrestrial access. IPv6 mobility
management mechanisms need to support session continuity while
reducing signaling overhead and service disruption during handover
procedures. Existing mobility management approaches designed for
terrestrial wireless environments may require additional
considerations in NTN environments characterized by long
propagation delay, heterogeneous access links, and dynamic
connectivity conditions.
* *Handling of Intermittent Connectivity:* NTN environments may
experience intermittent connectivity due to satellite movement,
temporary link disruption, limited gateway visibility, HAPS
unavailability, weather conditions, or disaster conditions.
IPv6-based communication mechanisms should consider communication
continuity even when E2E paths are not immediately available.
Approaches related to Delay/Disruption Tolerant Networking (DTN)
architecture [RFC4838], Bundle Protocol Version 7 [RFC9171],
buffering, scheduled contacts, and opportunistic forwarding may be
relevant for supporting packet delivery in intermittently
connected satellite environments.
* *QoS Class Identification and Treatment:* IPWASN should analyze
how traffic can be classified into QoS classes and how those
classes can be preserved across satellite, HAPS, and ground
network segments. DiffServ marking in IPv6 packets [RFC2474] and
DiffServ service-class guidance [RFC4594] provide useful starting
points, but NTN-specific treatment needs to consider long RTT,
jitter, asymmetric capacity, handover, packet loss, and
intermittent connectivity. At a minimum, IPWASN should consider
separate treatment for emergency text/data, conversational voice,
interactive video, streaming video, bulk data, control-plane
signaling, and delay-tolerant IoT traffic.
* *QoS Parameter Mapping:* Each QoS class should be mapped to
relevant parameters such as one-way delay, RTT, jitter, packet
loss, bandwidth, reliability, priority, and tolerance to
disruption. For example, emergency text may require high
reliability and priority while tolerating higher delay; voice and
conferencing require bounded delay and jitter; streaming video
Lee, et al. Expires 29 November 2026 [Page 15]
Internet-Draft IPWASN May 2026
requires sustained throughput and controlled loss; and IoT traffic
may require energy efficiency and delay-tolerant delivery. These
mappings should guide path selection, queue management, admission
control, and traffic engineering decisions. Table 1 summarizes
representative QoS classes for IPWASN.
* *SR-MPLS and SRv6-based Traffic Engineering:* Segment Routing may
provide useful traffic-engineering tools for IPWASN. SR-MPLS can
reuse the MPLS forwarding plane to steer traffic through selected
paths, while SRv6 can provide IPv6-native source routing and
service function chaining by using IPv6 segment identifiers and
SRv6 endpoint behaviors [RFC8986]. SR Policy [RFC9256] provides a
framework for steering traffic according to candidate paths,
optimization objectives, constraints, and policy colors. IPWASN
should analyze how SR-MPLS and SRv6 can support QoS-aware
forwarding, HAPS-assisted path selection, gateway selection, fast
reroute, and path optimization in NTN networks.
* *Fast Reroute and Handover Preparation:* IPWASN should analyze
fast reroute mechanisms for link changes, satellite handovers,
HAPS relay changes, and gateway outages. SR Policy protection and
local protection mechanisms can provide candidate techniques, and
BFD [RFC5880] may be useful for detecting failures. However, NTN
environments require careful evaluation of detection timers, false
positives under variable delay, pre-computation of backup paths,
and interaction with scheduled satellite mobility.
* *Gap Analysis for Existing MPLS and SR Technologies:* Existing
MPLS, SR-MPLS, SRv6, and SR Policy mechanisms were not designed
specifically for rapidly moving satellite constellations and HAPS-
assisted paths. IPWASN should therefore identify gaps related to
label-stack depth, SRH overhead, Maximum SID Depth, MTU impact,
segment-list compression, control-plane update rate, path-
computation scalability, state distribution, OAM, failure
detection, and policy consistency during frequent topology
changes. This gap analysis should compare existing technologies
with NTN requirements before any new protocol extension is
proposed. Table 2 summarizes initial analysis items.
* *Scalability for Large-scale Satellite Networks:* Large-scale
satellite constellations may involve a significant number of
satellites, HAPS nodes, gateways, and user devices operating
simultaneously. IPv6-based communication mechanisms should
consider scalability in terms of addressing, routing information
management, segment information, forwarding efficiency, QoS state,
telemetry, and overall network operation in large distributed NTN
environments.
Lee, et al. Expires 29 November 2026 [Page 16]
Internet-Draft IPWASN May 2026
* *Operational Observability and Management:* IPWASN should consider
how operators can observe and manage dynamic satellite and HAPS
paths. Useful information may include current and predicted link
availability, QoS class performance, handover events, SR Policy
state, packet loss, jitter, delay, and gateway utilization. Such
information is needed for troubleshooting, policy computation, SLA
reporting, and automated traffic engineering.
+==============+==================+============+===================+
|Traffic Class | Representative |Primary QoS | Forwarding |
| | Services |Requirements| Considerations |
+==============+==================+============+===================+
|Emergency | Emergency |High | Priority |
|text/data | message, |reliability,| forwarding, |
| | location report, |high | resilient path |
| | public-safety |priority, | selection, store- |
| | alert |loss | and-forward |
| | |avoidance; | support during |
| | |delay | disruption |
| | |tolerant | |
| | |within | |
| | |service | |
| | |policy | |
+--------------+------------------+------------+-------------------+
|Conversational| Voice call, |Bounded one-| Low-latency path |
|voice | push-to-talk, |way delay, | selection, |
| | public-safety |low jitter, | jitter-aware |
| | voice |moderate | queueing, fast |
| | |bandwidth, | reroute during |
| | |controlled | handover |
| | |packet loss | |
+--------------+------------------+------------+-------------------+
|Interactive | Video |Low latency,| QoS-aware SR |
|video | conferencing, |low jitter, | policy, |
| | live media, |sufficient | bandwidth-aware |
| | remote |uplink and | admission |
| | assistance |downlink | control, rapid |
| | |bandwidth, | recovery from |
| | |low packet | path changes |
| | |loss | |
+--------------+------------------+------------+-------------------+
|Streaming | Video streaming, |Sustained | Throughput-aware |
|video | online |throughput, | path steering, |
| | education, |controlled | cache or edge |
| | downlink media |loss, | selection, |
| | delivery |rebuffering | adaptation to |
| | |avoidance; | link-rate changes |
| | |less strict | |
Lee, et al. Expires 29 November 2026 [Page 17]
Internet-Draft IPWASN May 2026
| | |latency than| |
| | |conferencing| |
+--------------+------------------+------------+-------------------+
|IoT sensing | Telemetry, |Low | Opportunistic |
| | environmental |bandwidth, | forwarding, |
| | sensing, asset |high energy | aggregation, |
| | monitoring |efficiency, | scheduled contact |
| | |delay | use, minimal |
| | |tolerance, | signaling |
| | |reliability | overhead |
| | |according to| |
| | |application | |
+--------------+------------------+------------+-------------------+
|Control and | Routing updates, |High | Separate |
|routing | mobility |reliability,| treatment from |
|signaling | signaling, path- |bounded | best-effort |
| | computation |delivery | traffic, |
| | state, OAM |time, | authentication, |
| | |protection | rate control, and |
| | |from | policy |
| | |congestion | consistency |
| | |and spoofing| |
+--------------+------------------+------------+-------------------+
Table 1: Representative QoS Classes for IPWASN
+=============+================+=================+==================+
| NTN | Existing | Gap in IPWASN | Analysis |
| Requirement | MPLS/SR | Environments | Direction |
| | Capability | | |
+=============+================+=================+==================+
| QoS-aware | SR Policy can | Satellite, | Analyze how |
| path | steer traffic | HAPS, and | latency, |
| steering | by candidate | gateway | bandwidth, |
| | path, | conditions | reliability, and |
| | preference, | change rapidly, | gateway |
| | constraints, | so policy | availability are |
| | and color. | validity can | measured and |
| | | expire before | bound to SR |
| | | or during use. | policies. |
+-------------+----------------+-----------------+------------------+
| Fast | MPLS and SR | LEO handover | Evaluate pre- |
| reroute | deployments | and HAPS relay | computed backup |
| during | can use local | changes may be | segment lists |
| handover | protection, | scheduled | and timer |
| | backup paths, | mobility events | settings that |
| | and failure | rather than | avoid false |
| | detection | ordinary | failure |
Lee, et al. Expires 29 November 2026 [Page 18]
Internet-Draft IPWASN May 2026
| | mechanisms. | failures. | detection under |
| | | | variable RTT. |
+-------------+----------------+-----------------+------------------+
| Dynamic | SR-MPLS label | Long multi-hop | Study segment |
| segment- | stacks and | ISL or | compression, |
| list | SRv6 segment | satellite-HAPS- | hierarchical |
| management | lists encode | ground paths | segments, |
| | explicit | may exceed | binding SIDs, |
| | forwarding | practical label | and path |
| | instructions. | stack depth or | abstraction for |
| | | Maximum SID | large |
| | | Depth. | constellations. |
+-------------+----------------+-----------------+------------------+
| Header and | SR-MPLS uses | SRH overhead or | Quantify |
| MTU | label stacks; | deep MPLS label | overhead for |
| efficiency | SRv6 uses the | stacks can | representative |
| | Segment | reduce | path lengths and |
| | Routing | effective | identify limits |
| | Header for | payload | for low-rate |
| | explicit | capacity on | direct-to-device |
| | segment | constrained NTN | links. |
| | lists. | links. | |
+-------------+----------------+-----------------+------------------+
| HAPS- | SR can steer | HAPS introduces | Define metrics |
| assisted | packets | aerial relay | and policy |
| hybrid path | through | availability, | inputs for |
| selection | selected | access/backhaul | choosing |
| | nodes and | capacity, and | satellite-only, |
| | service | coverage | HAPS-assisted, |
| | functions in | constraints | terrestrial, or |
| | terrestrial | that are not | hybrid paths. |
| | or provider | common in fixed | |
| | networks. | networks. | |
+-------------+----------------+-----------------+------------------+
| Control- | Existing | Large satellite | Analyze |
| plane | routing and | constellations | aggregation, |
| scalability | controller- | produce | prediction-based |
| | based SR | frequent | computation, |
| | deployments | topology events | policy lifetime, |
| | distribute | and large | and consistency |
| | topology, | numbers of | across |
| | segment, and | time-dependent | satellite, HAPS, |
| | policy state. | candidate | and ground |
| | | paths. | domains. |
+-------------+----------------+-----------------+------------------+
| OAM and | MPLS, SR- | Intermittent | Evaluate |
| telemetry | MPLS, and | links, long | lightweight OAM, |
| | SRv6 have OAM | RTT, and moving | scheduled |
Lee, et al. Expires 29 November 2026 [Page 19]
Internet-Draft IPWASN May 2026
| | and telemetry | relays may make | measurement, and |
| | mechanisms | continuous | correlation with |
| | for path | probing | ephemeris, HAPS |
| | validation | expensive or | position, and |
| | and failure | misleading. | gateway |
| | localization. | | visibility. |
+-------------+----------------+-----------------+------------------+
Table 2: Initial SR Gap Analysis for IPWASN
7. Security Considerations
This document does not define new protocols packet formats, or on-
the-wire behaviors. However, IPWASN combines IPv6 forwarding,
mobility management, QoS treatment, traffic engineering, and
intermittent-connectivity support in satellite and HAPS-assisted NTN
environments. Therefore, deployments need to consider security and
privacy risks that arise when existing IPv6 mechanisms are applied to
highly dynamic and geographically wide-area wireless networks. The
security considerations in RFC 9365 for IPv6 wireless access in
vehicular environments are relevant because both environments involve
mobile nodes, changing attachment points, neighbor discovery,
mobility management, and privacy-sensitive location information
[RFC9365].
7.1. Neighbor Discovery and First-hop Security
In IPWASN, IPv6 Neighbor Discovery (ND) and first-hop functions may
operate over satellite service links, HAPS-assisted access links, and
gateway-facing links. As discussed in RFC 9365, ND-related
procedures can be abused for flooding, address spoofing,
impersonation, and denial-of-service attacks [RFC9365]. In NTN
environments, the impact of such attacks may be amplified by long
RTT, constrained radio resources, intermittent connectivity, and
frequent handover. Implementations and deployments should therefore
filter suspicious ND traffic, rate-limit control messages where
appropriate, authenticate routers or access nodes when feasible, and
consider secure ND-related mechanisms such as SEND [RFC3971] or other
deployment-specific authentication mechanisms.
Address ownership and source-address validation are also important
for satellite access because spoofed IPv6 addresses may consume
scarce satellite or HAPS capacity, pollute neighbor caches, or
interfere with mobility bindings and traffic engineering policies.
Operational guidance for IPv6 security [RFC9099] and known
operational ND problems [RFC6583] should be considered when profiling
ND behavior for IPWASN.
Lee, et al. Expires 29 November 2026 [Page 20]
Internet-Draft IPWASN May 2026
7.2. Mobility Management and Control-plane Security
IPWASN mobility management may involve frequent UE handovers among
satellites, HAPS nodes, gateways, and terrestrial access networks.
Similar to the mobility-management threats described in RFC 9365, a
malicious node may attempt to register bogus identities, create false
mobility bindings, exhaust resources in gateways or mobility anchors,
or interfere with handover signaling [RFC9365]. Mobility-related
control messages and tunnel endpoints should be mutually
authenticated and protected for integrity and confidentiality.
Secure channels such as IPsec [RFC4301] or TLS [RFC8446] may be used
according to the deployment architecture.
Traffic-engineering and source-routing state also require protection.
SR-MPLS and SRv6 policies, segment lists, contact schedules, and
path-computation inputs can affect where packets are forwarded.
Unauthorized modification of such information may cause traffic
interception, blackholing, loop formation, policy bypass, or service
degradation. Operators should protect control-plane distribution
channels, authenticate path-computation entities, and validate
forwarding policy updates before applying them in satellites, HAPS
nodes, gateways, and ground networks.
7.3. Trajectory, Contact, and Privacy Considerations
TPD and TSF show that trajectory information can improve forwarding
by predicting encounters and rendezvous points [TPD-COMNET-2015]
[TSF-TMC-2012]. In IPWASN, similar inputs may include satellite
ephemeris data, HAPS trajectories, gateway visibility, link
schedules, and UE location or attachment information. These inputs
can be operationally valuable, but they are also security- and
privacy-sensitive. False trajectory or contact information may cause
incorrect path computation, delayed delivery, excessive packet
replication, or routing around intended policy constraints. Such
information should therefore be authenticated, integrity protected,
and checked against operator policy and telemetry when used for
forwarding or handover decisions.
Location, attachment, and contact-history data can reveal user
movement, service usage, emergency activity, or sensitive operational
patterns. RFC 9365 notes that logging and address information can
create privacy risks in mobile wireless environments [RFC9365].
IPWASN deployments should minimize collected location and contact
data, protect stored and transmitted logs, restrict access to
trajectory and telemetry databases, and consider IPv6 address-
generation privacy guidance [RFC7721] where applicable.
Lee, et al. Expires 29 November 2026 [Page 21]
Internet-Draft IPWASN May 2026
7.4. Other Threats
IPWASN may rely on multi-hop paths through satellites, HAPS nodes,
relay nodes, gateways, and terrestrial networks. Authentication or
key-establishment messages may experience delay or loss over such
paths, and compromised intermediate nodes may attempt to observe,
delay, replay, or drop traffic. E2E security for user traffic and
strong operational security for management interfaces are therefore
important. Operators should also consider zero-trust assumptions for
cross-domain NTN deployments, where satellite operators, HAPS
operators, mobile network operators, and terrestrial Internet
providers may be separate administrative entities.
8. References
8.1. Normative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583,
DOI 10.17487/RFC6583, March 2012,
<https://www.rfc-editor.org/info/rfc6583>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
Lee, et al. Expires 29 November 2026 [Page 22]
Internet-Draft IPWASN May 2026
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[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>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey,
"Operational Security Considerations for IPv6 Networks",
RFC 9099, DOI 10.17487/RFC9099, August 2021,
<https://www.rfc-editor.org/info/rfc9099>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
8.2. Informative References
[TS-23.501-Rel17]
"System Architecture for the 5G System (5GS); Stage 2
(Release 17)",
Available: https://www.3gpp.org/DynaReport/23501.htm, June
2023.
[TS-23.501-Rel18]
"System Architecture for the 5G System (5GS); Stage 2
(Release 18)",
Available: https://www.3gpp.org/DynaReport/23501.htm,
March 2024.
Lee, et al. Expires 29 November 2026 [Page 23]
Internet-Draft IPWASN May 2026
[ITU-HAPS] "High-altitude platform systems", 2026.
[HAPS-ARCH]
Alsharif, M.S., Kim, J., and J.H. Kim, "High Altitude
Platform Stations (HAPS): Architecture and System
Performance", arXiv 2103.03431,
Available: https://arxiv.org/abs/2103.03431, March 2021.
[TPD-COMNET-2015]
Jeong, J.P., Kim, J., Hwang, T., Xu, F., Guo, S., Gu,
Y.J., Cao, Q., Liu, M., and T. He, "TPD: Travel
Prediction-based Data Forwarding for Light-Traffic
Vehicular Networks", Computer Networks Volume 93, pp.
166-182, DOI 10.1016/j.comnet.2015.10.016, December 2015,
<https://doi.org/10.1016/j.comnet.2015.10.016>.
[TSF-TMC-2012]
Jeong, J., Guo, S., Gu, Y., He, T., and D.H.C. Du,
"Trajectory-Based Statistical Forwarding for Multihop
Infrastructure-to-Vehicle Data Delivery", IEEE
Transactions on Mobile Computing Volume 11, Number 10, pp.
1523-1537, DOI 10.1109/TMC.2011.189, October 2012,
<https://doi.org/10.1109/TMC.2011.189>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
Lee, et al. Expires 29 November 2026 [Page 24]
Internet-Draft IPWASN May 2026
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7429] Liu, D., Ed., Zuniga, JC., Ed., Seite, P., Chan, H., and
CJ. Bernardos, "Distributed Mobility Management: Current
Practices and Gap Analysis", RFC 7429,
DOI 10.17487/RFC7429, January 2015,
<https://www.rfc-editor.org/info/rfc7429>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9365] Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
Environments (IPWAVE): Problem Statement and Use Cases",
RFC 9365, DOI 10.17487/RFC9365, March 2023,
<https://www.rfc-editor.org/info/rfc9365>.
[RFC9717] Li, T., "A Routing Architecture for Satellite Networks",
RFC 9717, DOI 10.17487/RFC9717, January 2025,
<https://www.rfc-editor.org/info/rfc9717>.
Acknowledgments
This work was supported by Institute of Information & Communications
Technology Planning & Evaluation (IITP) grant funded by the Korea
Ministry of Science and ICT (MSIT) (No. RS-2024-00398199, Standard
Development of SDV Software Framework for Intelligent Convergence
Services).
Contributors
This document is made by the group effort of 6man Working Group. The
authors sincerely appreciate the contributions of 6man Working Group.
The following are the coauthors of this document:
Lee, et al. Expires 29 November 2026 [Page 25]
Internet-Draft IPWASN May 2026
Tae (Tom) Oh
School of Information
Rochester Institute of Technology
335 John Street
Rochester, NY 14623
United States of America
Phone: +1 585 475 7642
Email: thoics@rit.edu
Byoungman (Robert) An
Intelligent Information R and D Division Mobility Platform Research Center
Global R and D Center 6th floor
#22, Daewangpangyo-ro 712beon-gil
Seongnam
Gyeonggi-Do
13488
Republic of Korea
Phone: +82 31 739 7463
Email: bman@keti.re.kr
URI: https://www.keti.re.kr/eng/main/main.php
Yiwen Shen
Department of Software
Ajou University
206 Worldcup-Ro, Yeongtong-Gu
Suwon
Gyeonggi-Do
16499
Republic of Korea
Email: chrisshen@ajou.ac.kr
URI: https://chrisshen.github.io
Xiaohong (Dawn) Yu
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: rna0415@skku.edu
URI: https://iotlab.skku.edu/people-dawnyu.php
Lee, et al. Expires 29 November 2026 [Page 26]
Internet-Draft IPWASN May 2026
Xudong Wang
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: wangwudong28@skku.edu
URI: https://iotlab.skku.edu/people-Xudong-Wang.php
Eunjin Hwang
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: eunijhwang@skku.edu
URI: https://iotlab.skku.edu/people-Eunjin-Hwang.php
Shota Okazaki
Graduate School of Systems Engineering
Wakayama University
930 Sakaedani, Wakayama
640-8510
Japan
Email: okazaki.shota@g.wakayama-u.ac.jp
Authors' Addresses
Jimin Lee (editor)
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: jm.lee98@skku.edu
URI: https://iotlab.skku.edu/people-Jimin-Lee.php
Lee, et al. Expires 29 November 2026 [Page 27]
Internet-Draft IPWASN May 2026
Jaehoon Paul Jeong (editor)
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Bien Aime Mugabarigira
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: bienaime@skku.edu
URI: https://iotlab.skku.edu/people-Bien-Aime.php
Takuya Yoshihiro
Faculty of Systems Engineering
Wakayama University
930 Sakaedani, Wakayama
640-8510
Japan
Email: tac@wakayama-u.ac.jp
Lee, et al. Expires 29 November 2026 [Page 28]