inet256 / inet256

Identity Based Network API with 256-Bit Addresses

INET256

A 256 bit address space for peer-to-peer hosts/applications.

The value proposition:

All you have to know to send messages to another process is its address, which will never change.

All you have to do to recieve messages is generate a private, public key pair and connect to the INET256 daemon

The INET256 API and Address Spec: Spec

The architecture of the reference implementation: Mesh256

Documentation for the daemon's config file: Daemon Config

Features

• Stable addresses derived from public keys
• Secure communication to other nodes in the network
• Best-effort delivery like IP or UDP. At-most-once delivery, unlike IP and UDP.
• Messages are never corrupted. If it gets there, it's correct.
• Easy to add/remove/change routing algorithms.
• Addresses are plentiful. Spawn a new node for each process. Every process gets its own address, no need for ports.
• Daemon can run without root or NET_ADMIN capability.
• IPv6 Portal for IPv6 over INET256. Exposed as a TUN device. (requires NET_ADMIN).
• Autopeering and transport address discovery help make peering easy.

Getting Started

Running with Systemd

Install the inet256 binary to /usr/local/bin/inet256

Install the systemd unit files

$ just install-systemd

Start the service

$ systemctl start inet256

Running with Docker

First build the docker image

$ just docker

Then create the configuration files

$ mkdir myconfig
$ inet256 create-config > myconfig/config.yml
$ inet256 keygen > myconfig/private_key.pem

Finally, run docker container.

$ docker run -it --rm --net=host -v ./myconfig:/config:ro inet256:local

Mesh256

The reference implementation of an INET256 Service, which lives in this repository, is called mesh256. It uses a distributed routing algorithm to allow nodes on the network to discover paths between one another.

Network Routing Protocols

The autoconfiguring, distributed routing algorithms of the sort required are under active research, and we don't want to couple mesh256 to any one algorithm as the state of the art could change rapidly.

Users are ultimately in control of which networks they participate in. Networks can be selected in the configuration file.

We are eager to add other protocols. Check out networks/beaconnet for an example of simple routing protocol. It's a good place to start.

Utilities/Applications

This project provides tools for using INET256 networks, some of which are not yet implemented

• IPv6 Portal (TUN Device). Similar to CJDNS and Yggdrasil.
• IPv4 VPN, declarative mappings from INET256 -> IPv4. similar to WireGuard.
• netcat. Send newline separated messages to other nodes: inet256 nc.
• echo. A server to echo messages back to the sender: inet256 echo.
• Central Discovery Server to keep track of roaming peers. inet256 central-discovery

Code Tour

• pkg/inet256 API definitions. Mostly things required by the spec.

• pkg/mesh256 The reference implementation of an INET256 Service.

• pkg/inet256d The daemon that manages setting up transports, autopeering, discovery, the actual INET256 service, and the HTTP API.

• pkg/inet256ipv6 Logic for bridging INET256 to IPv6. Includes the IPv6 portal.

• pkg/inet256test A test suite for Network implementations.

• pkg/autopeering Autopeering interface definition and implementations

• pkg/discovery discovery interface definition and implementations

• networks/ Network implementations, routing logic is in these.

• client/ Client implementations, these connect to the daemon.

License

Code in this repository is by default licensed under the GPL as defined in LICENSE. Some of the sub-directories contain their own LICENSE files for the LGPL, or MPL as defined therein. That license applies to the sub-directory.

In summary: you should be able to import an INET256 client in a language of your choice and do whatever you want. But other than clients, the implementation is strongly copyleft.

inet256's Issues

Centralized Tracker

One way to make peering very easy is to have a centralized tracker. Nodes announce themselves to the tracker with a heartbeat including transport addresses they would like to advertise, and can also lookup the transport addresses of any other node using the tracker. The heartbeats would be signed with the Nodes public key, to prevent DOS attacks.

The upside of this is you don't even have to know transport addresses to peer. You just add your desired one-hop peers into your configuration and you are good to go.
There are definitely downsides to this. The centralized server would know where everyone was connecting from. I think a lot of users would want to make this trade off for the sake of convenience.

Python Client

IPv6 Portal Linux Setup

The IPv6 portal needs to run some operating specific commands on the TUN device in order to assign it an ipv6 address and subnet. Right now this only happens on darwin. It should be pretty easy to add it for linux as well using the ip command.

This would be a change to pkg/inet256ipv6/portal.go adding another switch case for linux.

NodeJS Client

Daemon should listen on a UNIX socket.

The daemon should be able to expose the gRPC API on a unix socket, and maybe should do this by default.

I'm not sure what the defaults should be as far as a path goes. Docker might set a good example.
Notably we don't require the daemon to run as root or with any special permissions, and each user could in theory run their own daemon.