Known Limitations

IronIP solves a specific problem. It does not solve every problem. Honest scoping of what's enough and what isn't.

What BCA proves

BCA verification proves that a registered identity exists and corresponds to this IPv6 address. That's the core guarantee.

It does not prove that the packet you just received came from the device that owns this address. That's a different property, and whether it's needed depends on the network.

Where BCA alone is sufficient

Private / controlled networks.

Examples: factory floors, ATEX zones, private mesh, dedicated VLANs, building management, industrial SCADA.

Where BCA needs to be paired with per-packet authentication

Public / shared networks.

Examples: shared campus Wi-Fi, public infrastructure, multi-tenant edge, carrier networks.

BCA as IPsec bootstrap — no PKI required

For public networks, the standard answer is IPsec. The hard part of IPsec has always been key distribution — every device needs a certificate from a CA, or a pre-shared key.

BCA parameters already contain a public key cryptographically bound to the device and anchored in Bitcoin. That key can establish IPsec Security Associations directly — no CA, no certificate infrastructure, no OCSP responders.

Traditional IPsec:
  Device → Certificate Authority → PKI cert
    → cert distribution → OCSP/CRL
    → IKE negotiation → IPsec SA
  // heavy infrastructure, per-device cert cost, CA is single point of failure

BCA + IPsec:
  Device → BCA params (pubkey included)
    → verifier already has the key
    → IKE negotiation → IPsec SA
  // no CA, no cert distribution, Bitcoin anchor survives CA shutdown

Same security. No PKI. The BCA registration is the key distribution. See IPsec Integration for the build plan.

Other limitations

Revocation

IronIP doesn't currently support revocation. If a device is compromised, its BCA IPv6 address remains verifiable. Mitigations:

Device compromise

If the device's private key is extracted, an attacker can sign on behalf of the device. BCA verifies the identity; it doesn't verify liveness or non-compromise. Pair with:

Chain dependency

IronIP depends on Bitcoin (or a chosen chain) continuing to exist and produce blocks. Mitigations:

Constrained device floor

Devices need to:

This rules out the very lowest-end 8-bit microcontrollers. Most modern IoT silicon (Cortex-M3/M4 and up) handles it comfortably.

Not peer-reviewed

The Ducroux paper (arXiv:2311.15842) is a preprint by nChain AG. It has not been peer-reviewed at a top security venue. No production deployments exist; this is a first implementation. The cryptographic primitives (SHA-256, Merkle trees, Bitcoin PoW) are individually battle-tested. The novel contribution is the specific combination for IPv6 address generation.

For certification-sensitive deployments (Common Criteria, FIPS 140-3), independent security review would be a prerequisite.

What IronIP explicitly doesn't replace

See also