Whitepaper — ip.space Foundation

Executive Summary

The orbital internet is being built right now. Satellite constellations are multiplying, orbital datacenters are emerging, and the next frontier of the internet is taking shape in low Earth orbit and beyond. But unlike the terrestrial internet, which was built on a foundation of open standards, neutral governance, and shared routing infrastructure, the orbital internet is at risk of becoming a collection of proprietary, fragmented walled gardens.

ip.space is a proposed framework and neutral non-profit foundation to prevent that outcome. We propose extending the Internet Protocol to orbital infrastructure through open peering standards, a community-governed registry, and a neutral routing fabric that any operator can participate in regardless of their satellite platform, ground station provider, or commercial interests.

ip.space Foundation, Inc. is a newly formed Texas non-profit corporation, currently applying for 501(c)(3) status. We have no operational infrastructure today. What we have is a framework, a founding vision, and a domain: ip.space. We are publishing this document to plant a flag, start a conversation, and recruit the engineers, operators, researchers, and organizations who will build this with us.

The terrestrial internet was not built by one company. It was built by a community that agreed on open standards and neutral governance. The orbital internet deserves the same foundation. The window to get this right is open now.

1. The Problem: The Orbital Internet is Ungoverned

Satellite Internet is Exploding

The number of operational satellites in low Earth orbit has grown dramatically in recent years. As of 2024, more than 7,500 active satellites orbit Earth, with multiple large-scale commercial constellation deployments underway or planned. Analysts project tens of thousands of additional satellites to be launched this decade alone. Orbital datacenters are moving from concept to reality, and space-based compute and edge infrastructure is attracting significant investment.

Yet beneath this growth lies a fundamental governance gap. Unlike every other layer of internet infrastructure, orbital internet routing operates without a neutral framework, without a shared addressing authority, and without the peering standards that have made the terrestrial internet function as a unified global network.

The Routing Problem

On the terrestrial internet, when two networks want to exchange traffic they establish a BGP peering session under a common framework. They have ASNs issued by a Regional Internet Registry, IP space allocated under clear policy, and routing policies published in Internet Routing Registries. On-orbit, none of this exists. Today:

Each large constellation operator routes traffic through its own proprietary internal network
There is no neutral on-orbit peering point where operators can exchange traffic directly
Smallsat operators have no framework for leveraging larger operators' ground infrastructure
Large operators have no standard mechanism for mutual peering with one another
Traffic that could be handed off on-orbit is instead dropped to ground, routed terrestrially, and relaunched to orbit unnecessarily

The Governance Gap

The five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, and AFRINIC) divide the world into geographic regions and administer IP address space within those regions. This model works for terrestrial infrastructure because networks are anchored to geography. Orbital infrastructure is not. A single LEO satellite passes over every RIR region in a single orbit. The Outer Space Treaty of 1967 establishes orbital space as a global commons, yet no RIR has been chartered to govern it, and no existing registry framework cleanly applies.

This governance vacuum will not remain empty. As orbital infrastructure scales, it will be filled either by the neutral community-driven process that built the terrestrial internet's governance institutions, or by the interests of the largest commercial operators. ip.space is a proposal for the former.

The Orbital Datacenter Moment

Orbital datacenters are an emerging infrastructure category attracting serious investment. Companies are actively developing platforms for compute, storage, and processing on-orbit, driven by real advantages of the orbital environment: persistent solar power, natural thermal management, and potential for low-latency access to a global network fabric.

But an orbital datacenter without routable IP connectivity is not a datacenter -it is an isolated box. The orbital datacenter market depends on the existence of a reliable, addressable, and neutrally governed orbital internet routing fabric. ip.space is the proposal for that fabric.

Space is the next frontier of the internet. Just as cloud computing required the existence of internet routing infrastructure to function, orbital compute requires orbital internet routing infrastructure. ip.space is the proposal for building that infrastructure correctly, from the start.

2. Introducing ip.space

ip.space Foundation, Inc. is a neutral non-profit foundation proposing a framework for open orbital internet routing and governance. Our purpose is to extend the Internet Protocol to orbital infrastructure through:

Open routing standards purpose-built for the orbital environment
A community-governed registry for orbital ASN and IPv6 address allocation
A neutral peering fabric connecting orbital operators without proprietary lock-in
Certified neutral ground station infrastructure providing terrestrial internet egress
A peering marketplace enabling operators to trade and exchange orbital traffic capacity
A partner directory connecting operators with hardware, transit, and integration partners

Everything ip.space proposes to build is designed to be open, neutral, and community-governed, modeled on the institutions that made the terrestrial internet work: ARIN, ISOC, the Linux Foundation, and the Internet Exchange Points that form the backbone of global internet exchange.

What ip.space Is Not

Not a satellite operator. We will not launch or operate satellites.
Not a commercial carrier. We will not sell internet connectivity to end users.
Not a government body. We have no regulatory authority.
Not a vendor. We have no product to sell you.

ip.space is infrastructure governance: the neutral layer that makes it possible for everyone else to build.

3. Proposed Technical Architecture

The architecture described in this section is a high-level proposal, not a finished specification. The details will be developed collaboratively through ip.space working groups. We are actively seeking engineers, researchers, and operators to contribute.

The ip.space network is proposed as a four-layer architecture, each layer building on the one below. Together they form a complete orbital internet routing fabric that integrates cleanly with the existing terrestrial internet without requiring any changes to terrestrial routing infrastructure.

Layer 1: The Identity Layer

A permissioned distributed ledger built on Hyperledger Fabric -the enterprise-grade blockchain framework maintained by the Linux Foundation. Every participant receives a cryptographic identity at onboarding. The ledger serves as the authoritative and tamper-evident record of:

ip.space-issued internal ASN assignments and their operator bindings
Registered external ASNs from operators bringing their own existing allocations
IPv6 allocations made by ip.space to native operators
Registered external IPv6 blocks from federated operators
Routing policies published and signed by each operator
Ground station certifications and their operational status
Peering agreements and transit relationships between operators

This layer's central purpose is autonomous ASN verification without requiring real-time ground contact. Orbital nodes cache cryptographically signed identity records, enabling trust verification locally during contact episodes -exactly as RPKI enables BGP origin validation without real-time RIR contact on the terrestrial internet. Route hijacking and ASN spoofing are addressed at the protocol level from the start.

Layer 2: The Addressing Layer

The orbital fabric is IPv6-native. IPv4 address space is exhausted at the IANA level; building on IPv4 would inherit decades of address scarcity and NAT complexity. ip.space will seek a large IPv6 allocation from ARIN to sub-allocate to native operators. Federated operators register their existing RIR prefixes, which are accepted and routed within the fabric. Ground station edge routers implement NAT64 for IPv4 compatibility.

Layer 3: The Routing Layer

A two-tier approach matching the right protocol to each environment, mirroring the terrestrial internet's well-established distinction between interior and exterior gateway protocols.

Interior: The Orbital Routing Protocol (ORP) -A purpose-built session and routing protocol for the orbital fabric. ORP is designed around several key principles:

Contact-aware operation: ORP treats the orbital environment as a series of discrete contact episodes rather than persistent sessions, recognizing that connectivity between any two nodes is predictable but intermittent.
Two-tier architecture: ORP addresses both intra-operator routing within a constellation (iORP) and inter-operator exchange between constellations, analogous to the IGP/EGP distinction on the terrestrial internet.
Beacon-driven discovery: Orbital nodes broadcast signed identity beacons on a shared radio channel, enabling autonomous neighbor discovery without ground coordination.
Operator-controlled peering policy: Operators define their own peering policy through a compact policy definition uplinked from the ground. ip.space validates ASN identity; operators make peering decisions.
Open and closed peering modes: Operators may choose to advertise reachability openly or require explicit bilateral relationships before exchanging routing information.
Autonomous trust verification: ASN validity is verified locally against cached and cryptographically signed records from the identity layer. No real-time ground contact is required.
Physical layer agnosticism: ORP operates as a session and policy protocol independent of the underlying radio system, designed for the computational and storage constraints of radiation-hardened orbital hardware.

ORP draws on and extends prior work by the IETF DTN working group, including the Bundle Protocol and Contact Graph Routing research. The ip.space ORP Working Group intends to publish a detailed specification as an Internet Draft through the IETF process.

Exterior: BGP at the Ground Station Edge -BGP runs only at the border between the orbital fabric and the terrestrial internet. From the terrestrial internet's perspective, ip.space ground stations are simply BGP peers. No changes are required to terrestrial routing infrastructure. This clean separation means ip.space is fully interoperable with the existing internet from day one.

Layer 4: The Edge Layer

The ip.space Edge Router (IER) is the proposed open source software stack that ground station partners deploy. Running on standard x86 hardware, it performs several functions simultaneously:

Runs ORP toward the orbital fabric, managing dynamic connectivity to orbital nodes
Runs BGP toward the terrestrial internet, announcing ip.space and operator prefixes
Validates ASN certificates against the ip.space identity layer
Enforces routing policies signed on the identity layer
Meters traffic for peering marketplace settlement
Implements NAT64 for IPv4 compatibility
Manages egress: native operator traffic via ip.space public block; federated operator traffic via their own ASN and prefix

4. Peering Models

ip.space enables three distinct peering models, not mutually exclusive:

Model A: Large Operator as Transit Provider -Large LEO constellation operators provide standardized transit to smallsat operators and new entrants. The smallsat operator gets a real ASN and IPv6 allocation without needing their own ground infrastructure. Transit relationships are commercially self-enforcing at the protocol level.
Model B: Smallsat Cooperative Peering -Two or more smallsat operators exchange traffic directly on-orbit. Traffic stays in space longer, hits the ground closer to its destination, and avoids unnecessary terrestrial routing hops. For latency-sensitive applications such as orbital edge compute and real-time telemetry, this difference is meaningful.
Model C: Large Operator Mutual Peering -Major operators peer on-orbit at orbital exchange points governed by ip.space policy, exchanging traffic the same way that terrestrial IXPs like DE-CIX and AMS-IX facilitate between major carriers. ip.space provides the neutral governance framework that makes mutual peering the natural, low-friction choice.

These three models together constitute the orbital internet's equivalent of the terrestrial internet's peering ecosystem. ip.space is the neutral fabric that makes all three possible simultaneously, while respecting each operator's commercial interests and peering policies.

5. Participation Models

Native Operators are organizations without existing public ASNs or IP allocations: new entrants to the orbital internet, smallsat startups, and research institutions. They receive an ip.space-issued ASN, IPv6 sub-allocation from ip.space's ARIN block, access to the orbital routing fabric and peering marketplace, and routing policy support. Their traffic egresses via ip.space's public ASN and IPv6 block.

Federated Operators are established organizations with existing public ASNs and IP allocations: major carriers, large constellation operators, and government agencies. They register their resources with ip.space, and at ground station egress they announce their own prefixes via their own BGP sessions. The terrestrial internet sees their real ASN -nothing changes about their existing routing relationships. For federated operators, ip.space is an extension of their existing network, not a replacement.

6. The Peering Marketplace

The ip.space Peering Marketplace is a proposed platform enabling orbital operators to list, discover, and transact traffic capacity in a neutral, transparent environment.

Transit Capacity

Large operators list available transit capacity -routes covered, ground station locations, SLA tiers, and pricing -both spot and reserved. Smallsat operators find and contract transit the way a network operator today might find upstream providers on a peering exchange.

Downlink Capacity

Operators with excess ground station downlink capacity list it for other operators to use. This turns ground station infrastructure from a fixed cost into a shared, tradeable asset.

On-Orbit Exchange Capacity

As inter-satellite links become more prevalent, operators will list on-orbit exchange capacity: the ability to accept and forward traffic between constellations on-orbit without touching the ground.

Settlement

Traffic settlement is handled through automated smart contract settlement on the identity layer. Traffic is metered at IER ground station egress points. Settlement executes automatically based on pre-agreed terms, eliminating billing disputes and reconciliation delays. ip.space operates as the neutral settlement layer.

7. The Partner Directory

The ip.space Partner Directory is a structured directory of organizations that have achieved ip.space certification or partnership status. We are seeking founding partners in every category:

Hardware Partners -Antenna, ground station, and orbital compute hardware manufacturers
Transit Partners -Certified constellation operators offering transit under ip.space framework
Ground Station Partners -Neutral ground station operators deploying IER
Integration Partners -System integrators, software vendors, monitoring providers
Research Partners -Universities, space agencies, research institutions

Founding partners in each category will be named in ip.space governance documents, will hold permanent founding partner status, and will have direct influence over the certification and directory standards developed for their category.

8. Governance

ip.space Foundation, Inc. is a Texas non-profit corporation governed by a board of directors, applying for 501(c)(3) tax-exempt status. The governance model is designed to be neutral and multi-stakeholder, modeled on the Internet Society, ARIN, and the Linux Foundation.

Proposed Membership Tiers

Researcher / Individual (Free or nominal) -Access to standards documents, working group participation
Startup Operator ($500-$2,500) -ip.space ASN allocation, IPv6 sub-allocation, marketplace access
Operator Member ($10,000-$25,000) -Full peering framework, working group voting rights, directory listing
Founding Member (Negotiated) -Shape standards from day one, permanent founding status, governance participation
Corporate Partner ($25,000-$100,000) -Partner directory certification, co-marketing, working group leadership

Proposed Working Groups

ORP Working Group: Define and publish the Orbital Routing Protocol specification, targeting IETF Internet Draft submission. Coordination with the IETF DTN working group and CCSDS.
IER Working Group: Develop and maintain the open source ip.space Edge Router software stack.
Policy Working Group: Develop routing policy frameworks, peering agreement standards, and registry allocation policies.

Registry Roadmap

Phase 1 (Now-Year 2): IRR Operator + Standards Body. Publish ORP draft, release IER v0.1, onboard founding members and ground stations, participate in ARIN and IETF community processes.
Phase 2 (Year 2-5): Operational Registry + ARIN Policy Participation. Operational registry services, marketplace beta, ARIN community policy engagement, first orbital peering sessions.
Phase 3 (Year 5+): Full RIR for the Orbital Region. Global Policy Proposal across all five RIRs, IANA recognition petition, direct IPv6 + ASN allocation, mature marketplace.

9. How to Get Involved

ip.space is a community project in its earliest stage. The following opportunities are open now:

Become a Founding Member -Shape the standards, policies, and governance of the orbital internet from the ground up. Founding member status is permanent.
Contribute to Working Groups -The ORP specification, IER software, and policy frameworks will be developed in the open.
Partner with ip.space -Hardware manufacturers, ground station operators, and technology vendors can join the partner directory and certification framework.
Donate to the Foundation -Support standards development, working group operations, and IER open source development.
Spread the Word -Present it at NANOG. Bring it to your IETF working group. Share it with your satellite industry contacts.

Contact us at: [email protected]

This is a draft published for community review and comment. The technical architecture described herein is a proposal subject to revision through community working group process.
Version 0.2 Draft · 2025 · Creative Commons Attribution 4.0 International (CC BY 4.0)