Developers Program · 2 contributors so far

Build the protocol the Internet upgrades to.

IPv8 is a managed, backward-compatible successor to IPv4. We're recruiting C, Rust, and Linux kernel developers to ship the reference implementation — AF_INET8, FIB8, MFT, ARP8, ICMPv8, DNS8, and the ZoneServer userspace stack. Every commit lands in public. Every contributor is named in the spec.

§ Reference Implementation — Milestones

Five phases, scoped by deliverable.

Ordered by dependency, not by calendar. Each phase has explicit deliverables and a sharp acceptance test. Pick the one your skills fit.

  1. Phase 1
    01/05

    Linux Kernel Module

    Fork net/ipv4/ into a parallel net/ipv8/ stack. Native L3 protocol implementation. Two hosts in different ASNs communicate via IPv8 through a router. Statically configured, no dynamic services yet.

    Deliverables
    • net/ipv8/ kernel module (~17 new C files, ~5,000 lines)
    • AF_INET8 socket family registration
    • Ethertype 0x88B5 packet handling
    • ipv8ctl userspace configuration tool
    • ping8 userspace testing tool
    • Test harness: 3 network namespace topologies (single-ASN, dual-ASN, dual-gateway)
    • GitHub Actions CI building against Linux 6.6 LTS
    Acceptance

    Two hosts in separate ASNs ping each other through an IPv8 router across a veth topology. tcpdump shows correctly-formed IPv8 frames. Dual default gateways with parity-based primary/secondary selection demonstrably working.

  2. Phase 2
    02/05

    64-Bit Address Space and Routing

    Static multi-ASN topology with proper routing infrastructure. Foundation for dynamic services.

    Deliverables
    • struct in8_addr (8 octets: 32-bit ASN + 32-bit IPv4-style host portion)
    • FIB8 with longest-prefix match keyed on (ASN, prefix) tuples
    • Static route management via netlink
    • ARP8 dual-probe capability negotiation (IPv4/IPv8 simultaneous discovery)
    • ICMPv8 echo request/reply
    • IPv4 reservation handling preserved within host portion (127/8, 169.254/16, 224/4, RFC 1918, broadcast)
    • ASN-aware forwarding decisions
    • Parity-based default gateway selection
    Acceptance

    Static routes propagate correctly. Hosts in ASN 65001 ping hosts in ASN 65002 through one or more IPv8 routers. Failover from primary to secondary gateway completes within 10 packets.

  3. Phase 3
    03/05

    MFT Tables and Routing State

    Multi-protocol Forwarding Tables — the runtime state that drives IPv8 routing decisions. Distinct from the FIB (which holds configured routes) because MFT tracks active forwarding state including neighbor capabilities, peering relationships, and learned reachability.

    Deliverables
    • MFT data structures: neighbor table, peering table, learned reachability table
    • Neighbor liveness tracking (integrates with ARP8 cache, adds protocol-level liveness)
    • Per-neighbor capability flags (IPv4-only, IPv8-capable, both)
    • Hot-path lookup optimization for forwarding decisions
    • MFT inspection tools: ipv8ctl mft show, ipv8ctl mft neighbors
    • Sync between MFT and FIB on routing changes
    Acceptance

    MFT correctly reflects active topology. Neighbor failures detected within configured timeout. MFT inspection tools show accurate runtime state. Forwarding decisions on hot path complete in microseconds.

  4. Phase 4
    04/05

    DNS Injection and A8 Records

    DNS integration for IPv8 address resolution. New A8 record type, parity-based selection among multiple records, IPv4 fallback after configurable attempt threshold.

    Deliverables
    • A8 record type definition (IANA RR-type allocation request)
    • Resolver library extensions for A8 lookup
    • nslookup8 userspace tool
    • DNSSEC-pattern signing for A8 records (using IANA-issued ASN keypair)
    • Parity-based client-side selection among multiple A8 returns
    • Automatic IPv4 fallback after 5 failed IPv8 attempts (configurable; -f flag forces IPv8-only)
    • WHOIS8 public key injection point for DNSSEC validation
    Acceptance

    A8 records resolve correctly. DNSSEC signatures validate against WHOIS8-published public keys. IPv8-aware applications can use unprefixed hostnames; resolver handles protocol selection transparently.

  5. Phase 5
    05/05

    Zone Server Userspace

    Operational services running on top of the kernel module. DHCP8, NetLog8, basic identity binding.

    Deliverables
    • DHCP8 server and client (userspace daemons)
    • NetLog8 collector (Zone Server side) and client (endpoint side)
    • Active/standby failover via parity-based selection
    • Basic MAC-based identity binding (records MAC at first appearance, permits, logs)
    • Zone Server pair coordination (active/active at server level, active/standby per client)
    • Administrative interface for Zone Server configuration
    Acceptance

    Endpoint comes up, gets address via DHCP8, establishes NetLog8 to primary Zone Server. Kill primary; failover to secondary within 10 packets. Restart primary; resync without disruption.

§ Sign up

Get on the contributor list.

Tell us what you've shipped. We'll send the onboarding pack and pair you with the phase that fits.

We use your details only to coordinate the IPv8 build. No marketing.