libp2p: The Networking Layer Underneath IPFS

IPFS libp2p is the layer that makes every other piece of this series' retrieval story actually possible. The DHT lookup that finds who has a CID and the Bitswap exchange that fetches its blocks both assume two peers can already open a secure connection and speak to each other, and neither protocol handles that part itself. libp2p is what does: peer identity, connection security, multiple simultaneous data streams, and getting through the NATs and firewalls most home and office connections sit behind.

TL;DR:

• libp2p began as IPFS's own wire protocol and has since become a standalone, modular peer-to-peer networking framework used by other projects too
• Every peer has a PeerID derived from its own public key, not assigned by any central authority, and every network address is written as a self-describing multiaddr rather than a bare IP and port
• Connections are secured with the Noise protocol (the recommended baseline, supported by all current implementations) or TLS 1.3, then a stream multiplexer, Yamux is the modern default, mplex is deprecated, lets many independent data streams share one underlying connection
• Getting two peers connected at all, when either or both sit behind a NAT, uses AutoNAT to detect the problem, Circuit Relay to bridge a connection through a third peer, and a hole-punching protocol called DCUtR to try upgrading that relayed connection into a direct one
• AIOZ Pin's dedicated gateways skip this entire stack for a request: a plain HTTP call to a known, already-reachable host, no peer dialing, no NAT traversal, no multiplexer negotiation required

Where libp2p Sits in the Stack

The DHT and Bitswap sections of this series both describe what gets exchanged between peers, provider records in one case, actual blocks in the other, but neither describes how two peers that have never talked before actually establish a connection capable of carrying that exchange. That's libp2p's job, sitting one layer below both. A DHT lookup and a Bitswap want-have message both travel as libp2p streams over a libp2p connection; strip libp2p out and there is no transport for either protocol to run on.

What Problem libp2p Actually Solves

libp2p started life as IPFS's own peer-to-peer wire protocol before being pulled out into its own standalone, modular framework, reusable by any project that needs peer-to-peer networking rather than only IPFS. The problem it solves is one every earlier P2P project had independently reinvented: identity, security, transport negotiation, and NAT traversal all have to be solved before an application's actual logic can run, and none of that logic is specific to what the application does with the connection once it exists. libp2p packages those pieces as swappable, composable modules instead of a single fixed protocol, which is also why it supports multiple transports, security protocols, and multiplexers rather than mandating exactly one of each.

Peer Identity: Derived, Not Assigned

A libp2p PeerID is not handed out by a server or registry, it is derived directly from a peer's own public key. This mirrors the same content-addressing logic covered earlier in this series applied to identity instead of data: nobody has to trust a central authority's claim about who a peer is, because a peer's ID can be independently verified against the key it actually signs with. A peer proves it owns a given PeerID the same way a CID proves content wasn't tampered with, through direct cryptographic verification, not an appeal to authority.

Multiaddrs: Addresses That Describe Themselves

Where a location-based address like an HTTP URL bundles protocol and host together in one fixed syntax, libp2p addresses, multiaddrs, are composable and self-describing: /ip4/198.51.100.7/tcp/4001/p2p/QmPeerID reads left to right as a stack of nested protocols, IPv4 at this address, over TCP on this port, ending at this specific peer identity. The same peer can be reachable over multiple multiaddrs at once, different transports, different networks, and a connecting peer can try any of them without the address format itself needing to change.

Securing a Connection: Noise and TLS

Once two peers have found each other's addresses, libp2p negotiates a security protocol before any application data flows. Noise is the recommended baseline and is supported by every current libp2p implementation; TLS 1.3 is also supported as an alternative. After that handshake completes, a second negotiation, multistream-select, runs again on top of the now-secured connection to agree on which stream multiplexer to use next.

One Connection, Many Streams: Yamux and Mplex

A single libp2p connection between two peers can carry many independent logical streams at once, so a DHT lookup and a Bitswap exchange with the same peer don't need separate connections. Yamux is the modern, preferred multiplexer, supporting flow control through backpressure so one stream can't flood the others sharing the same connection. Mplex, an earlier multiplexer, is now deprecated in favor of it.

Getting Through NATs and Firewalls

Most peers on the real internet sit behind a NAT or firewall that blocks unsolicited inbound connections, which would make direct peer-to-peer connectivity the exception rather than the rule if libp2p didn't account for it directly. AutoNAT lets a peer determine whether it's actually reachable from the outside, functionally equivalent to what STUN does in traditional NAT-traversal setups. When two peers can't connect directly, Circuit Relay establishes a connection routed through a third, publicly reachable peer instead, a working but bandwidth- and time-limited fallback. From that relayed connection, DCUtR (Direct Connection Upgrade through Relay) coordinates hole punching between the two original peers, attempting to upgrade the relayed link into a direct one so the relay isn't needed for the rest of the session.

Where AIOZ Pin's Gateways Skip All of This

Everything above describes what it costs to connect to an arbitrary, possibly-behind-a-NAT peer on the open network: identity verification, security handshake, multiplexer negotiation, and potentially a relay-then-hole-punch sequence before any actual content moves. A request to an AIOZ Pin dedicated gateway is a plain HTTP GET to infrastructure that is already public, already reachable, and already holding the content, none of that connection-establishment sequence applies. This is a different, earlier point in the pipeline than the DHT-and-Bitswap negotiation this series already covered skipping, that was about skipping content discovery and transfer negotiation; this is about skipping the peer-connection setup those protocols would have needed in the first place.

Frequently Asked Questions

What is libp2p in IPFS? The peer-to-peer networking framework IPFS runs on: peer identity, connection security, stream multiplexing, and NAT traversal, all as the transport layer DHT and Bitswap operate over.

Is libp2p specific to IPFS? No. It started as IPFS's wire protocol but was pulled out into a standalone, modular framework other peer-to-peer projects also use independently of IPFS.

How is a PeerID different from an IP address? A PeerID is derived from a peer's own public key and can be cryptographically verified; an IP address is just a network location assigned by an ISP or network operator, with no built-in identity guarantee.

What is a multiaddr? A self-describing network address format that stacks protocol layers explicitly, like transport and port and destination peer, rather than relying on one fixed address syntax the way a URL does.

Why does libp2p need both Circuit Relay and hole punching? Circuit Relay provides an immediate, working connection through a third peer when two peers can't connect directly. DCUtR then tries to upgrade that relayed connection into a direct one, so the relay's limited bandwidth isn't needed for the rest of the session.

Do AIOZ Pin's gateways use libp2p at all? A gateway request itself is plain HTTP, not a libp2p connection. The gateway's own infrastructure may still participate in the IPFS network over libp2p to source content, but the client making the request never has to negotiate any of it.

Related Reading

• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - the two protocols that run as libp2p streams over the connections this article describes
• Content Addressing vs. Location Addressing: Why IPFS Needs Pinning - the same address-derived-from-content logic applied to data instead of peer identity
• How IPFS Really Works: Merkle DAGs, Chunking, and Content Routing Explained - the series overview this article's networking layer sits underneath
• IPFS Private Networks: Swarm Keys Explained - how a swarm key restricts connections at exactly this layer, before any DHT or Bitswap activity
• IPFS Transports: TCP vs. QUIC Explained - what actually runs underneath the connections this article describes
• GossipSub: How IPFS's PubSub Layer Actually Works - the push-based messaging protocol built on top of this same networking layer
• AIOZ Pin Dedicated Gateways: Simple, High-Performance IPFS Access - the product feature that bypasses the connection setup covered above
• Types of IPFS Nodes: The Different Roles, Explained - the relay-node role this article's Circuit Relay v2 coverage feeds directly into

References

• IPFS Docs: libp2p
• libp2p: Hole Punching
• libp2p specs: Circuit Relay v2