Minecraft:NetherNet

NetherNet is a peer-to-peer networking transport used in Minecraft:Bedrock Edition, built on WebRTC. It uses WebRTC data channels to exchange game data between clients and servers. With HTTP signaling, the connection is negotiated through HTTP requests before game data is exchanged over the established WebRTC connection.<ref name="nethernet-guide">Template:Cite</ref>

HTTP signaling

With HTTP signaling, the client uses two endpoints to check server support and negotiate a WebRTC connection. A successful capability check provides server information, after which the client exchanges SDP messages with the server through the signaling service.<ref name="nethernet-guide" />

Capability check

The client sends Template:Cd. A successful response has a 2xx status, an Template:Cd content type, and a JSON object with server information. A non-2xx response indicates that NetherNet is unavailable, and the client does not continue with connection setup.<ref name="nethernet-guide" />

Field	Type	Description
Template:Cd	String	Server name.
Template:Cd	Number	Bedrock protocol version supported by the server.
Template:Cd	String	Bedrock game version.
Template:Cd	String	Name of the loaded world.
Template:Cd	Number	Current player count.
Template:Cd	Number	Maximum player count.
Template:Cd	Number	Default game mode: 0 for Survival, 1 for Creative, or 2 for Adventure.

SDP exchange

The client sends one HTTP request per connection attempt:

Direction	Method and path	Content type	Body
Client to server	Template:Cd	Template:Cd	The complete SDP offer, including ICE candidates.
Server to client	HTTP 2xx response	Template:Cd	The complete SDP answer, including ICE candidates.

The Template:Cd path value identifies the client to the signaling service. Its value is treated as an opaque string. A non-2xx response ends the attempt; the client does not retry automatically. NetherNet's HTTP signaling gathers all ICE candidates before the offer or answer is sent. The signaling service routes the offer to the host and returns its answer. It is not involved in the game-data connection after setup.<ref name="nethernet-guide" />

Connection sequence

1. The client checks support with Template:Cd.
2. The client creates a WebRTC peer connection and the two data channels described below.
3. The client gathers ICE candidates and sends its SDP offer to Template:Cd.
4. The signaling service forwards the offer to the host.
5. The host creates an SDP answer, gathers its ICE candidates, and returns the answer through the signaling service.
6. The client applies the answer. The client and host perform ICE connectivity checks, establish DTLS and SCTP, and open the data channels.
7. Game data flows between the client and host over the WebRTC connection.<ref name="nethernet-guide" />

The client configuration for HTTP signaling uses UDP ICE candidates, disables trickle ICE,<ref>RFC 8838: Trickle ICE</ref> and bundles data channels over one transport. The offer and answer each carry all gathered ICE candidates.<ref name="nethernet-guide" />

The client has no STUN or TURN servers configured and gathers only local candidates. The host's answer must include a candidate reachable by the client; a host behind NAT may need a publicly reachable candidate.<ref name="nethernet-guide" />

Identity and trust

The client's a=identity assertion identifies the authenticated player and is validated by the server.<ref name="identity-rfc">RFC 8827: WebRTC Security Architecture, section 5</ref> An offer without an assertion may be accepted or rejected according to the server's authentication policy. The server's answer must contain an assertion for its operator identity; the client checks it before accepting the connection.<ref name="nethernet-guide" />

The attribute contains a base64-encoded JSON object with an identity provider (Template:Cd) and an Template:Cd string. The assertion contains a JWT and a detached JWS covering the WebRTC certificate fingerprints. The client's token is issued by the Minecraft authentication service, while the server's token is self-signed using its operator key.<ref name="nethernet-guide" />

With HTTPS signaling, the client relies on TLS to authenticate the server. With plaintext HTTP signaling, the client uses TOFU: it prompts the player the first time it sees an operator key, then remembers that key for later connections. The a=identity attribute is required in the answer for both cases.<ref name="nethernet-guide" />

Data channels

The client opens two SCTP data channels. The host accepts both channels and can send and receive on them.<ref name="nethernet-guide" />

Channel	Delivery	Use
Template:Cd	Reliable and ordered	Data that must arrive in order. Supports fragmentation.
Template:Cd	Unreliable and unordered	Latency-sensitive data that can tolerate loss. Does not support fragmentation.

The unreliable channel sets Template:Cd to Template:Cd.<ref name="nethernet-guide" />

Message framing

Each data-channel message begins with a one-byte header. The receiver removes this byte before processing the payload.<ref name="nethernet-guide" />

Header value	Meaning
Template:Cd	Complete message, or the final fragment of a fragmented message.
Template:Cd where Template:Cd	Fragment with Template:Cd more fragments to follow.

Unfragmented messages have a header value of Template:Cd. The maximum unfragmented payload is the negotiated SCTP message size limit minus one byte for the header. On Template:Cd, oversized messages are split into fragments. Their header values count down to zero, and the receiver reassembles the payloads in order. On Template:Cd, the header is always zero; oversized messages are dropped rather than fragmented.<ref name="nethernet-guide" />

Game data

NetherNet transports Minecraft:Bedrock Edition game data through WebRTC data channels. It provides the transport and message framing mechanisms, while the game packets themselves follow the Minecraft:Bedrock Edition protocol. Individual packet structures are documented at Minecraft:Bedrock Edition protocol/Packets.<ref name="nethernet-guide" />

Use in Bedrock Edition

NetherNet became the default transport for Minecraft:Bedrock Dedicated Server in Minecraft:26.50.<ref>Template:Cite</ref> In Minecraft:26.60, Minecraft:RakNet was deprecated, and the dedicated server's warning for connections not using NetherNet was changed to an error.<ref>Template:Cite</ref>