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. The connection is negotiated through HTTP signaling, 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.

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. Treat it as an opaque string. A non-2xx response ends the attempt; the client does not retry automatically. NetherNet uses full ICE, so candidate gathering completes 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 described in Mojang's guide 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" />

Identity and trust

Both the offer and answer include an a=identity<ref name="identity-rfc">RFC 8827: SDP Identity Attribute</ref> attribute. The client's assertion identifies the authenticated player and is validated by the server. The server's answer must also 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 opaque Template:Cd. The assertion carries a signed token and a signature for the WebRTC certificate fingerprints. The client and server provide different identity assertions for their respective roles.<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<ref name="identity-rfc" /> 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.

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. 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; messages too large for a single SCTP message 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 Bedrock Edition protocol/Packets.<ref name="nethernet-guide" />

Use in Bedrock Edition

NetherNet became the default transport for Bedrock Dedicated Server in Minecraft:26.50. Minecraft:RakNet is deprecated in the Minecraft:26.60.22 Preview.<ref>Template:Cite</ref><ref>Template:Cite</ref>