IPv6 Stateless Address Autoconfiguration for Satellite Networks using Topology-Embedded Interface Identifiers
draft-zhang-ipv6-satellite-slaac-00

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:: <Topology-Embedded IID>

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,
              <https://www.rfc-editor.org/info/rfc2119>.

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,
              <https://www.rfc-editor.org/info/rfc4429>.

   [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,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
              February 2014, <https://www.rfc-editor.org/info/rfc7136>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc7217>.

   [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]