Minecraft:NetherNet

NetherNet is MinecraftTemplate:'s peer-to-peer networking transport, built on WebRTC. The client uses WebRTC data channels to exchange game data with a server. With HTTP signaling, the connection is negotiated through HTTP requests, then established directly between the client and server.<ref name="nethernet-guide">Template:Cite</ref>

HTTP signaling

The client uses two HTTP endpoints. A successful capability check tells the client that the server supports NetherNet and provides server details. The client then uses the SDP exchange endpoint to negotiate a WebRTC connection.<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 carries a signed token and a signature for the WebRTC certificate fingerprints. The client's token is issued by the Minecraft authentication service; the server's token is self-signed with 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 carries Minecraft:Bedrock Edition game data in its data-channel messages. Game-packet formats 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> Support for Minecraft:RakNet connections is scheduled to end in Minecraft:26.60.