Network Working Group Y. Zhang Internet-Draft J. Liu Intended status: Standards Track Nanjing University Expires: 20 July 2026 C. Zheng Institute of Spacecraft System Engineering 16 January 2026 IPv6 Stateless Address Autoconfiguration for Satellite Networks using Topology-Embedded Interface Identifiers draft-zhang-ipv6-satellite-slaac-00 Abstract 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. 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 20 July 2026. Zhang, et al. Expires 20 July 2026 [Page 1] Internet-Draft Sat-SLAAC-Topo January 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. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Specification . . . . . . . . . . . . . . . . . . . 6 6.1. Node Configuration Variables . . . . . . . . . . . . . . 6 6.2. Interface Identifier Generation Algorithm . . . . . . . . 7 6.2.1. IID Format Layout . . . . . . . . . . . . . . . . . . 8 6.2.2. Relationship to Modified EUI-64 and RFC 7136 . . . . 8 6.3. Address Configuration . . . . . . . . . . . . . . . . . . 9 6.3.1. Link-Local Address Formation . . . . . . . . . . . . 9 6.3.2. Global Address Formation . . . . . . . . . . . . . . 9 6.4. Duplicate Address Detection (DAD) . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7.1. Privacy and Topology Exposure . . . . . . . . . . . . . . 10 7.2. Address Scanning . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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) [RFC4862], and an optimized Duplicate Zhang, et al. Expires 20 July 2026 [Page 2] Internet-Draft Sat-SLAAC-Topo January 2026 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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). Zhang, et al. Expires 20 July 2026 [Page 3] Internet-Draft Sat-SLAAC-Topo January 2026 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 [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 Zhang, et al. Expires 20 July 2026 [Page 4] Internet-Draft Sat-SLAAC-Topo January 2026 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. 4. 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. Zhang, et al. Expires 20 July 2026 [Page 5] Internet-Draft Sat-SLAAC-Topo January 2026 * *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. 5. Protocol Overview 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. 6. Protocol Specification This section specifies the algorithm for generating the Topology- Embedded Interface Identifier. 6.1. 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"). Zhang, et al. Expires 20 July 2026 [Page 6] Internet-Draft Sat-SLAAC-Topo January 2026 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 [CCSDS-AOS]). 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. 6.2. 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)): 1. *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). 2. *Form Topology Field (16 bits):* Combine the triplet variables into a 16-bit field. Let Topo16 = (Shell_ID << 14) | (Orbit_ID << 8) | Sat_ID. 3. *Prepare Spacecraft and Interface Fields:* Ensure Spacecraft_ID fits in 28 bits. Let SCID28 = Spacecraft_ID & 0x0FFFFFFF. Let Int4 = Interface_Code & 0x0F. Zhang, et al. Expires 20 July 2026 [Page 7] Internet-Draft Sat-SLAAC-Topo January 2026 4. *Construct the 64-bit IID:* The 64-bit identifier is the concatenation of the above fields: IID = (Hash16 << 48) | (Topo16 << 32) | (SCID28 << 4) | Int4 6.2.1. IID Format Layout 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 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. 6.2.2. 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 [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. Zhang, et al. Expires 20 July 2026 [Page 8] Internet-Draft Sat-SLAAC-Topo January 2026 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. 6.3. Address Configuration 6.3.1. 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:: 6.3.2. Global Address Formation 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. 6.4. 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: 1. *SHOULD* use Optimistic DAD as defined in [RFC4429]. This allows the Interface to begin communication immediately upon configuration, without waiting for the DAD delay. 2. *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. Zhang, et al. Expires 20 July 2026 [Page 9] Internet-Draft Sat-SLAAC-Topo January 2026 7. Security Considerations 7.1. 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., [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. 7.2. 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. 8. IANA Considerations This document has no IANA actions. The Constellation_ID_String is managed locally by the network administrator. 9. Acknowledgements This document is based on technical concepts for satellite network addressing. The authors acknowledge the contributions of the satellite networking research community. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Zhang, et al. Expires 20 July 2026 [Page 10] Internet-Draft Sat-SLAAC-Topo January 2026 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, . [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [CCSDS-AOS] Consultative Committee for Space Data Systems, "AOS Space Data Link Protocol", CCSDS 732.0-B-3, September 2015. Authors' Addresses Ye Zhang Nanjing University Nanjing China Email: 522024230092@smail.nju.edu.cn Jun Liu Nanjing University Nanjing China Email: Johnson.liu@nju.edu.cn Zhang, et al. Expires 20 July 2026 [Page 11] Internet-Draft Sat-SLAAC-Topo January 2026 Changgang Zheng Institute of Spacecraft System Engineering Beijing China Email: changgang.zheng@eng.oxfordalumni.org Zhang, et al. Expires 20 July 2026 [Page 12]