IPv6 Stateless Address Autoconfiguration for Satellite Networks using Topology-Embedded Interface Identifiers

Introduction This document specifies the steps a satellite Node takes to autoconfigure its Interfaces in IP version 6 (IPv6) within a constellation network. The autoconfiguration process includes generating a Link-Local Address based on deterministic topological parameters, generating Global Unicast Addresses via Stateless Address Autoconfiguration (SLAAC) , and an optimized Duplicate Address Detection (DAD) procedure to verify the uniqueness of the addresses on a Link. Traditional stateless autoconfiguration mechanisms often rely on hardware identifiers (such as IEEE 802 MAC addresses) to generate Interface Identifiers (IIDs). However, satellite networks often utilize data link protocols that lack globally unique hardware addresses, such as the CCSDS AOS Space Data Link Protocol . Furthermore, in large-scale non-geostationary orbit (NGSO) constellations, network operators require addresses that carry semantic location information to facilitate routing and management without maintaining a centralized state database. This document defines a "Topology-Embedded Interface Identifier" generation algorithm. By embedding the satellite's Shell, Orbit, and Satellite Index into the address, the network achieves "semantic addressing," facilitating simplified routing policies and operational troubleshooting. This mechanism ensures that all configured addresses are highly likely to be unique on a given Link by design. Consequently, this document recommends the use of Optimistic Duplicate Address Detection (Optimistic DAD) , allowing immediate use of addresses to minimize link establishment latency—a critical factor for dynamic space environments.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms. Capitalized terms indicate specific definitions used within the context of this protocol.

Node: A device that implements IP. In the context of this document, a Node typically refers to a satellite, a ground station, or a gateway functioning within the constellation network.
Router: A Node that forwards IP packets not explicitly addressed to itself. Most satellites in the constellation function as Routers, forwarding packets across Inter-Satellite Links (ISLs).
Host: Any Node that is not a Router.
Link: A communication facility or medium over which Nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples in this context include Inter-Satellite Links (ISL) using laser or microwave (Ka/Ku band), and Ground-to-Satellite links. The protocol described in this document applies to both Ethernet-framed Links and non-Ethernet Links such as CCSDS AOS .
Interface: A Node's attachment to a Link. On a satellite Node, Interfaces are typically designated by their directional orientation relative to the orbit (e.g., prograde, retrograde, cross-plane).
Address: An IP-layer identifier for an Interface or a set of Interfaces.
Link-Layer Address: A link-layer identifier for an Interface. In Ethernet networks, this is the MAC address. In satellite networks using CCSDS or proprietary framing, this identifier may be derived from the Spacecraft ID (SCID) or be non-existent. This document specifies how to generate an IPv6 Interface Identifier even when a hardware Link-Layer Address is absent.
Satellite Node Triplet: A tuple of three integers [Shell_ID, Orbit_ID, Sat_ID] that uniquely identifies the satellite's logical position within the constellation topology. This tuple is the primary input for the topology-embedded address generation.
Shell: An orbital altitude layer of the constellation topology. In the address generation algorithm, this is represented by the integer Shell_ID. Used to distinguish between multi-layer constellations (e.g., LEO vs. VLEO layers).
Orbit: An orbital plane within a Shell. In the address generation algorithm, this is represented by the integer Orbit_ID.
Satellite Index: The specific position of a satellite within an Orbit, typically numbered sequentially based on mean anomaly or phase. In the address generation algorithm, this is represented by the integer Sat_ID.
Spacecraft ID: A unique hardware or mission identifier assigned to the physical spacecraft chassis (also referred to as SCID). Unlike the Satellite Node Triplet, which may change if a satellite maneuvers to a new slot, the Spacecraft ID is permanent to the hardware.
Interface Code: A locally unique 4-bit identifier assigned to each physical or logical Interface on a satellite (e.g., 0x1 for Int-1/Prograde, 0x2 for Int-2/Retrograde).
Constellation Hash: A 16-bit hash value derived from the Constellation ID String. It is used to prevent address collisions between different satellite networks using the same private address space logic.
Topology-Embedded Interface Identifier: A 64-bit Interface Identifier (IID) constructed by concatenating the Constellation Hash, Satellite Node Triplet, Spacecraft ID, and Interface Code. It provides semantic addressing regarding the Node's location.
Constellation ID String: A human-readable ASCII string (e.g., "LEO-001-MISSION") that uniquely identifies the constellation network. It is hashed to form the high-order bits of the IID.

Design Goals This document specifies a method for generating IIDs to be used with IPv6 SLAAC. The design aims to achieve the following goals:

Network-Wide Uniqueness by Design: The generation algorithm MUST guarantee that the resulting IIDs are unique within the administrative domain. By relying on deterministic planning data, the mechanism minimizes address collisions by design.
Semantic Addressing: The resulting IPv6 addresses MUST be semantically meaningful. Peer Nodes SHOULD be able to extract the topological location (Shell, Orbit, and Satellite Index) of an Interface directly from the address bits.
Independence from Hardware Addresses: The method MUST be applicable to Links that lack a globally unique hardware address (e.g., CCSDS AOS links).
Support for High-Dynamics: The mechanism MUST support rapid Link establishment. By ensuring uniqueness deterministically, the addresses allow for "Optimistic" configuration, enabling Interfaces to enter the "Preferred" state immediately.

Protocol Overview The autoconfiguration process follows the standard IPv6 SLAAC described in , with a specific modification to the IID generation algorithm. Nodes begin the autoconfiguration process by obtaining their topological parameters (Shell, Orbit, Satellite Index) from the satellite's Guidance, Navigation, and Control (GNC) system or mission data files. A Link-Local Address is formed by appending the Topology-Embedded Interface Identifier to the prefix FE80::/64. Because the orbital parameters are assigned via rigorous mission planning, the probability of a collision is negligible. Therefore, Nodes implementing this specification SHOULD employ Optimistic DAD . This allows the Node to treat the Address as available for use immediately, skipping the delay associated with waiting for Neighbor Solicitation (NS) timeouts. Upon configuring a Link-Local Address, the Node sends a Router Solicitation (RS) to discover on-link Routers (neighboring satellites). Upon receipt of a Router Advertisement (RA) containing a Prefix Information Option (PIO) with the A-flag set, the Node generates global addresses by appending the same Topology-Embedded Interface Identifier to the advertised prefix.

Protocol Specification This section specifies the algorithm for generating the Topology-Embedded Interface Identifier.

Node Configuration Variables A Node MUST maintain the following configuration variables. These variables are typically provisioned via the mission control plane.

Constellation_ID_String (Variable Length)

A human-readable ASCII string identifying the satellite network (e.g., "LEO-SAT-NET-V1").

Satellite_Node_Triplet

Three integers representing the Node's topological position. The default bit-widths are:

Shell_ID: 2 bits (Values 0-3). Corresponds to the Shell.

Orbit_ID: 6 bits (Values 0-63). Corresponds to the Orbit.

Sat_ID: 8 bits (Values 0-255). Corresponds to the Satellite Index.

Note: Implementations MAY support configurable bit-widths for the Triplet, provided the total length of the Triplet field remains 16 bits.

Spacecraft_ID (28 bits)

A globally unique identifier assigned to the physical spacecraft chassis (e.g., derived from CCSDS SCID defined in CCSDS 732.0-B-3 ). If the native SCID is shorter than 28 bits, it is padded with leading zeros.

Interface_Code (4 bits)

A locally unique identifier for the Interface.

Interface Identifier Generation Algorithm The IID is a 64-bit value constructed by concatenating the constellation hash, topological parameters, spacecraft identity, and interface code. The IID is generated as follows (using network byte order (big-endian)):

Calculate Constellation Hash (16 bits): Compute the 16-bit Cyclic Redundancy Check (CRC) of the Constellation_ID_String. The standard CRC-16-CCITT polynomial (0x1021) SHOULD be used. Let Hash16 = CRC16_CCITT(Constellation_ID_String).
Form Topology Field (16 bits): Combine the triplet variables into a 16-bit field. Let Topo16 = (Shell_ID << 14) | (Orbit_ID << 8) | Sat_ID.
Prepare Spacecraft and Interface Fields: Ensure Spacecraft_ID fits in 28 bits. Let SCID28 = Spacecraft_ID & 0x0FFFFFFF. Let Int4 = Interface_Code & 0x0F.
Construct the 64-bit IID: The 64-bit identifier is the concatenation of the above fields: IID = (Hash16 << 48) | (Topo16 << 32) | (SCID28 << 4) | Int4

IID Format Layout The bit layout of the resulting IID is shown in Figure 1.

Constellation Hash: 16-bit CRC hash of the Constellation ID String.
Shl: 2-bit identifier for the orbital shell.
Orbit: 6-bit identifier for the orbital plane.
Sat ID: 8-bit identifier for the satellite position within the orbit.
Spacecraft ID: 28-bit unique hardware identifier (e.g., CCSDS SCID).
Int: 4-bit identifier for the specific network interface.

Relationship to Modified EUI-64 and RFC 7136 The IID generated by this mechanism is semantically opaque to the IPv6 layer but semantically meaningful to the satellite management plane. In accordance with , the "Universal/Local" (u) and "Individual/Group" (g) bits (which correspond to bits 6 and 7 of the first byte of the IID, i.e., bits 6 and 7 of the Constellation Hash) are NOT reserved for special semantic handling by the IPv6 stack. Implementations MUST NOT attempt to flip the 'u' bit (bit 6) to invert semantic universality, as this would alter the Constellation Hash value and break the verification logic. The generated IID is treated as an opaque 64-bit string by the IPv6 layer but is assumed to be unique within the scope of the Link and the constellation administrative domain. While this mechanism implements semantic addressing for the benefit of the management plane and satellite routing fabric, the IID remains semantically opaque to the standard IPv6 forwarding plane outside the constellation domain.

Address Configuration

Link-Local Address Formation The Link-Local Address is formed by prepending the well-known prefix FE80::/64 to the IID generated in Section 6.2. Link-Local Address = FE80:: <Topology-Embedded IID>

Global Address Formation When a Node receives a Router Advertisement (RA) containing a Prefix Information Option (PIO) with the Autonomous flag (A-flag) set, it forms a Global Unicast Address by appending the IID generated in Section 6.2 to the advertised prefix.

Duplicate Address Detection (DAD) The deterministic nature of the generation algorithm provides a high assurance of uniqueness within the satellite constellation. Therefore, Nodes implementing this specification:

SHOULD use Optimistic DAD as defined in . This allows the Interface to begin communication immediately upon configuration, without waiting for the DAD delay.
MAY disable DAD entirely for Global Unicast Addresses if the Link technology guarantees point-to-point isolation or if the management plane guarantees unique assignment of the Spacecraft_ID and Satellite_Node_Triplet.

If a DAD conflict is detected (an exceedingly rare event indicating a hash collision or configuration error), the Node MUST NOT configure the Address and SHOULD log a management error.

Security Considerations

Privacy and Topology Exposure This mechanism explicitly embeds topological location (Shell, Orbit, Satellite Index) and hardware identity (Spacecraft ID) into the IPv6 Address. While this provides operational benefits for routing and troubleshooting, it exposes the constellation's internal topology to any Node that can view the IP headers. This mechanism MUST NOT be used for Interfaces directly exposed to the public Internet or end-user terminals (UE) where privacy extensions (e.g., or temporary addresses) are more appropriate. It is intended solely for the infrastructure Links (Inter-Satellite Links, Feeder Links) within the controlled administrative domain of the satellite constellation.

Address Scanning The deterministic structure of the addresses makes the network address space predictable. An attacker with knowledge of the constellation parameters (Orbit count, Satellite count) could infer valid addresses for scanning attacks. Network operators MUST implement strict ingress filtering (ACLs) at the constellation edge (Gateways) to prevent unauthorized external access to infrastructure addresses.

IANA Considerations This document has no IANA actions. The Constellation_ID_String is managed locally by the network administrator.

Acknowledgements This document is based on technical concepts for satellite network addressing. The authors acknowledge the contributions of the satellite networking research community.