| Internet-Draft | Sat-SLAAC-Topo | January 2026 |
| Zhang, et al. | Expires 20 July 2026 | [Page] |
This document specifies a Stateless Address Autoconfiguration (SLAAC) mechanism tailored for satellite constellation networks. It describes how a Host generates IPv6 Interface Identifiers (IIDs) based on deterministic orbital topology parameters and spacecraft identifiers, rather than hardware Media Access Control (MAC) addresses.¶
By embedding topological information (Shell, Orbit, Satellite Index) directly into the IID, this method provides semantic addressing, allowing network operators and routing protocols to derive physical location information solely from the IPv6 address. This approach guarantees global uniqueness within the constellation, minimizes the need for Duplicate Address Detection (DAD), and is suitable for Links typically found in space environments, such as CCSDS AOS or space-based Ethernet.¶
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 20 July 2026.¶
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.¶
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) [RFC4862], 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 [CCSDS-AOS]. 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) [RFC4429], allowing immediate use of addresses to minimize link establishment latency—a critical factor for dynamic space environments.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms. Capitalized terms indicate specific definitions used within the context of this protocol.¶
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.¶
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).¶
Any Node that is not a Router.¶
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 [CCSDS-AOS].¶
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).¶
An IP-layer identifier for an Interface or a set of Interfaces.¶
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.¶
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.¶
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).¶
An orbital plane within a Shell. In the address generation algorithm, this is represented by the integer Orbit_ID.¶
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.¶
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.¶
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).¶
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.¶
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.¶
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.¶
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.¶
The autoconfiguration process follows the standard IPv6 SLAAC described in [RFC4862], 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 [RFC4429]. This allows the Node to treat the Address as available for use immediately, skipping the delay associated with waiting for Neighbor Solicitation (NS) [RFC4861] timeouts.¶
Upon configuring a Link-Local Address, the Node sends a Router Solicitation (RS) [RFC4861] to discover on-link Routers (neighboring satellites). Upon receipt of a Router Advertisement (RA) [RFC4861] 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.¶
This section specifies the algorithm for generating the Topology-Embedded Interface Identifier.¶
A Node MUST maintain the following configuration variables. These variables are typically provisioned via the mission control plane.¶
A human-readable ASCII string identifying the satellite network (e.g., "LEO-SAT-NET-V1").¶
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.¶
A globally unique identifier assigned to the physical spacecraft chassis (e.g., derived from CCSDS SCID defined in CCSDS 732.0-B-3 [CCSDS-AOS]). If the native SCID is shorter than 28 bits, it is padded with leading zeros.¶
A locally unique identifier for the Interface.¶
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¶
The bit layout of the resulting IID is shown in Figure 1.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Constellation Hash (16) |Shl| Orbit (6) | Sat ID (8)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Spacecraft ID (High 28 bits) |Int(4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Topology-Embedded IID Layout
¶
16-bit CRC hash of the Constellation ID String.¶
2-bit identifier for the orbital shell.¶
6-bit identifier for the orbital plane.¶
8-bit identifier for the satellite position within the orbit.¶
28-bit unique hardware identifier (e.g., CCSDS SCID).¶
4-bit identifier for the specific network interface.¶
The IID generated by this mechanism is semantically opaque to the IPv6 layer but semantically meaningful to the satellite management plane.¶
In accordance with [RFC7136], 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.¶
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>¶
When a Node receives a Router Advertisement (RA) [RFC4861] 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.¶
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 [RFC4429]. 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.¶
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., [RFC7217] 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.¶
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.¶
This document has no IANA actions. The Constellation_ID_String is managed locally by the network administrator.¶
This document is based on technical concepts for satellite network addressing. The authors acknowledge the contributions of the satellite networking research community.¶