SCION: a reference implementation of an Internet architecture with explicit trust

A replacement architecture, not a new transport

SCION is the open source implementation of SCION, which stands for Scalability, Control and Isolation On next-generation Networks, and it is described as a future Internet architecture. The three properties it claims are route control, failure isolation and explicit trust information for end to end communication.

Those three words are the whole argument. Route control means the source of a packet chooses a path through the network rather than leaving it to the routing system. Failure isolation means a failure in one part of the network does not affect unrelated paths. Explicit trust information means the receiver knows which autonomous systems the traffic passed through, rather than inferring it from hop counts that anyone can forge.

That is why the project is a set of cooperating services rather than a library you import. The top level of the repository is the deployment: router/, control/, dispatcher/, daemon/, scion/, scion-pki/ and gateway/ are the components, and each of those has its own directory. The daemon is the process that joins the network and talks to its peers, the control plane is the service that computes and distributes path information, and the router forwards the data packets along the chosen path.

The primary language is Go, the licence is Apache-2.0, the homepage is scion.org, and the last push was on 2026-10-20. Releases are frequent: v0.15.1 in August 2026, v0.15.0 in April 2026 and v0.14.0 in November 2025, each named after an Alpine peak.

Install a package, or build it and watch out for cgo

Installation is straightforward if you are on a supported platform. Installation packages for Debian and derivatives are available for x86-64, arm64, x86-32 and arm, in the latest release, and packages for in-development versions are available from the nightly build. Alternatively, naked pre-built binaries are available for Linux x86-64 from the same two places.

Building from source has a trap, and the README flags it in a warning block. SCION can be built with go build, and to build all the binaries used in a deployment, excluding the testing and development tools, you run:

go build -o bin ./router/... ./control/... ./dispatcher/... ./daemon/... ./scion/... ./scion-pki/... ./gateway/...

The warning is about cgo. The control service and the daemon need cgo for their SQLite driver, and building them requires a C compiler. Without one, go silently sets CGO_ENABLED=0, the build still succeeds, and both binaries fail at startup, as soon as they try to open their database.

That failure mode is nasty precisely because the build gives no warning. A green build followed by a runtime failure at the point where the process tries to open its database is the kind of thing that costs an afternoon. The go.mod confirms why the dependency is there, with mattn/go-sqlite3 in the require list.

The README is also clear that the go build path is not the default way to build SCION. The default uses Bazel, because that allows you to run all the tests and the linters, and the documentation site has the setup instructions for Bazel and the full development environment.

Bazel is the real build system, and the Makefile shows the artefacts

The Makefile in the repository makes the Bazel workflow concrete, and its target list is a good inventory of what the project produces.

The build target removes the contents of bin/ and then runs bazel build on the scion target, untarring the result into bin. The build-dev target does the same for three targets, scion, scion-ci and scion-topo, so a developer gets the command line client, the continuous integration client and the topology generator in one step.

Distribution targets exist per platform and per package format. dist-deb and dist-rpm build the Debian and RPM packages, and dist-openwrt builds the OpenWrt ipk packages, with a separate dist-openwrt-testing target. Each of them depends on dist-check-cgo, except the OpenWrt ones, and the comment explains why: the cgo test only covers the deb and rpm architectures, while the OpenWrt platform has no cgo_off and has its own musl C toolchain, and those packages were always built with cgo.

That comment is a small but useful piece of engineering history. It tells you that the project takes its cgo requirement seriously enough to test for it on the platforms where it can, and that OpenWrt support is a deliberate, separately maintained target rather than an accident.

The rest of the Makefile covers the other recurring work: antlr for the parser generation, gazelle, protobuf, mocks, mocksdiff, licenses, docker-images, go.mod, test, test-integration, and the scion-topo and git-version helpers. The repository also has a bazel-remote.yml, which is the cache configuration for the build, and .bazelversion, which pins the Bazel version.

The repository holds a lot more than the Go service code

The top level listing of the repository is long, and it shows that a network architecture project is not just a daemon.

There is spec/ for the specifications, proto/ for the protocol definitions with a buf.yaml alongside, antlr/ for the grammar and the antlr.bzl rule, and rules_openapi/ for the API description handling. There is a demo/ directory with drkey/ and file_transfer/ subdirectories, which are the two things you most want to see working: a demonstration of the cryptographic key exchange that underpins SCION's path verification, and a demonstration of transferring a file over a SCION path.

Then there is testing/, with an acceptance/ directory at the top level as well, private/ for the parts that are not open, and tools/ for the utility binaries. The topology/ directory holds the topology generators that produce the synthetic network SCION runs over, which is the mechanism that makes a global test network reproducible.

The build infrastructure is Bazel native throughout, with MODULE.bazel and its lock file for the module system, BUILD.bazel at the root, scion.bzl and non_module_deps.bzl for custom rules, and nogo.bzl with nogo.json for the static analysis configuration. There is a .golangci.yml for golangci-lint, a .semgrepignore, a .flake8 for the Python tooling, and a .coveragerc for coverage.

The go.mod shows the dependency list, and it is a long one for a network stack. grpc and the connect RPC framework appear alongside netlink libraries, an eBPF library, a QUIC implementation, a Prometheus client, an OpenTracing library, a Jaeger command line tool, an OpenAPI code generator, a JWX library for JSON web tokens, and cobra with viper for the command line and configuration.

Joining the network means joining a test deployment

There is no way to use SCION on the public internet, and the README says so by pointing you at SCIONLab.

If you are interested in playing with SCION in an operational global test deployment of SCION, the instruction is to join SCIONLab. That is a real deployment of the architecture, with real routers and a real control plane, operated by the project, and joining it is how you get packets to travel over SCION paths rather than over IP.

For production deployments, the awesome-scion list contains pointers to them. That is a different artefact from the codebase: it is a curated index of who is running SCION and where, which is the kind of list you consult before deciding whether an architecture has left the lab.

The communication channels are worth noting too, because they tell you who maintains it. There is a Slack workspace with an invite link, and a federated Matrix instance with a #dev room, and the Matrix room is on the project's own instance at matrix.scion.org. The project is a research consortium rather than a single company, and the reference implementation here is the artefact that the SCIONLab deployment and the production deployments run.

The contribution guide, the Contributor Covenant and the doc/ directory round out the picture. The repository is not archived, the default branch is master, and the project publishes no GitHub releases beyond the tagged versions listed in the README.

How SCION compares to changing the routing protocol

The alternative to a new architecture is improving the existing one, and the difference in approach is the whole point of the project.

The incremental route is to extend IP. Add an option header, add a path segment list, add a signature, and let each hop verify and forward. That approach has the enormous advantage of deployability, because it works over the network you already have, and the disadvantage that the path information and the trust information are properties of the existing infrastructure, which does not have either.

SCION takes the opposite position. It replaces the forwarding plane with a system where the source computes a path, the control plane distributes the information needed to use it, and every packet carries proof of which path it took and who authorised it. The result is that failure isolation is a property of the design rather than of careful BGP configuration, and that the trust information is explicit rather than inferred.

The cost is that you need a new network. There is no partial adoption, no sidecar and no tunnel. Running SCION means running SCION routers, a control plane and a daemon, and it means the endpoints have to be willing to use a path that the rest of the internet does not know about. That is why the project's growth path is a global test deployment first and production deployments later, and why the awesome-scion index of real deployments is the metric that matters more than the code.

The reference implementation being in Go is also a deliberate choice worth noting, since the ecosystem of network software in Go is large and the project builds on grpc, QUIC and eBPF rather than inventing its own transport.

Editorial conclusion

Adopt SCION if you are working on network architecture, want to run a global test deployment, or need a concrete example of path-based routing with explicit trust relationships. Do not adopt it as a drop-in replacement for the IP network, since it is a research architecture with its own topology, not a transport you can turn on for one connection. Before you build it, install a C compiler, because without one the Go build silently disables cgo and the control service and daemon then fail at startup when they open their SQLite database, and use the Bazel path for anything beyond a quick local build, since that is what the project uses for tests and linters.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. scionproto/scion on GitHub