Independent Submission V. QwQ Internet-Draft 10 May 2026 Intended status: Informational Expires: 11 November 2026 The PRF Protocol draft-prf-protocol-01 Abstract This document describes the PRF protocol ("Prf is Reversed Frp"), a lightweight, binary-length-prefixed TCP relay messaging protocol. PRF enables peer-to-peer tunneling of TCP connections through a public middle relay node, originally designed for Minecraft multiplayer sessions behind NAT or firewall environments. The protocol defines three roles - Server, Client, and Middle - and a set of four wireframe message types for room registration, connection requests, worker handoff, and direct Minecraft client handshake parsing. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 11 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components QwQ Expires 11 November 2026 [Page 1] Internet-Draft PRF Protocol May 2026 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Byte Order . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Primitive Types . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. Integer (int32) . . . . . . . . . . . . . . . . . . . 4 3.2.2. String . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.3. Byte Array (bytes) . . . . . . . . . . . . . . . . . 4 4. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Type "S" - Server Registration . . . . . . . . . . . . . 5 4.1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.2. Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.3. Response . . . . . . . . . . . . . . . . . . . . . . 5 4.1.4. Reconnection . . . . . . . . . . . . . . . . . . . . 5 4.1.5. Polling . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Type "C" - Client Connection Request . . . . . . . . . . 6 4.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Format . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.3. Response . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Type "W" - Worker Handoff . . . . . . . . . . . . . . . . 7 4.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. Format . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.3. Response . . . . . . . . . . . . . . . . . . . . . . 7 4.3.4. HAProxy PROXY Protocol Header . . . . . . . . . . . . 7 4.4. Type null - Untyped Raw Stream Inspection . . . . . . . . 8 4.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.2. Recognized Format: Minecraft Client Handshake . . . . 8 4.4.3. Room ID Extraction . . . . . . . . . . . . . . . . . 9 4.4.4. Failure Handling . . . . . . . . . . . . . . . . . . 9 5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 9 6. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Server Registration and Client Connection . . . . . . . . 11 6.2. Untyped Raw Stream Inspection (e.g., Minecraft Client) . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 QwQ Expires 11 November 2026 [Page 2] Internet-Draft PRF Protocol May 2026 1. Introduction PRF is a custom application-layer protocol that operates over raw TCP sockets. It is designed to facilitate TCP port forwarding between peers that cannot directly connect to each other due to network constraints, such as Network Address Translation (NAT) or firewall restrictions. A publicly accessible middle relay node brokers connections between a Server (which hosts a service) and a Client (which wishes to access that service). The protocol does not provide encryption, authentication, or integrity protection. It is intended for use in trusted or low-risk environments where the primary concern is connectivity rather than confidentiality. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Roles The PRF protocol defines three distinct roles: *Server (Mode 1):* The party that hosts the actual service (e.g., a Minecraft server). It registers a room identifier with the Middle node and waits for incoming Client connections to be forwarded. *Client (Mode 2):* The party that wishes to access the Server's service. It sends a connection request to the Middle node specifying a room identifier. *Middle (Mode 3):* A publicly accessible relay node that brokers connections between Servers and Clients. It maintains a mapping of room identifiers to registered Servers and pending Client connections. 2. Protocol Overview PRF is a request-response protocol in which all communication flows through the Middle node. The Server registers with the Middle and then polls for pending Client connections. The Client sends a connection request to the Middle. When a Client is matched with a Server, the Middle assigns a Client Worker Identifier (CW-ID) and notifies the Server. The Server then initiates a worker connection back to the Middle to claim the Client, after which a bidirectional TCP tunnel is established. QwQ Expires 11 November 2026 [Page 3] Internet-Draft PRF Protocol May 2026 The protocol also defines a null-type mode in which no type identifier is sent. In this mode, the Middle node inspects the raw initial bytes of the TCP stream to determine routing. One recognized payload format in this mode is the Minecraft client handshake packet, making the protocol compatible with native Minecraft clients without requiring the PRF Client tool. 3. Wire Format 3.1. Byte Order All multi-byte numeric fields are transmitted in network byte order (big-endian). 3.2. Primitive Types 3.2.1. Integer (int32) A 32-bit signed integer encoded in 4 bytes, big-endian. The maximum value is 2,147,483,647. 3.2.2. String A string is encoded as a length-prefixed sequence of UTF-8 bytes: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (int32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (UTF-8 bytes) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field specifies the number of UTF-8 bytes that follow. 3.2.3. Byte Array (bytes) A byte array is encoded identically to a String, with a 4-byte length prefix followed by the raw bytes. Unlike String, the payload of a byte array is not assumed to be valid UTF-8. 4. Message Types Every message sent to the Middle node begins with a type identifier field, which is a length-prefixed string containing one of the following four values. The type identifier determines how the remainder of the message is parsed. QwQ Expires 11 November 2026 [Page 4] Internet-Draft PRF Protocol May 2026 4.1. Type "S" - Server Registration 4.1.1. Purpose Sent by the Server to register a room identifier with the Middle node. 4.1.2. Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ("S") | Room ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Room ID (UTF-8 bytes) ... | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is the UTF-8 string "S". The Room ID is a UTF-8 string of at most 30 bytes identifying the room. 4.1.3. Response Upon receiving a Type "S" message, the Middle node sends a response string. *Success vs. Failure:* The first character of the response string determines the outcome. A response beginning with > (U+003E) indicates success; any other response indicates failure. The remainder of the string is a server-defined, internationalized (i18n) message that MAY be displayed to the user but MUST NOT be used for protocol-level decision making. 4.1.4. Reconnection If the Room ID ends with the character v (U+0076, case-insensitive) and the room ID is already registered, the Middle node evicts the existing Server registration and replaces it with the new connection. The evicted Server receives the string "EXIT" (without a leading type identifier) on its poll channel, indicating that it should terminate. 4.1.5. Polling After successful registration, the Server enters a polling loop. The Middle node sends a String (without a leading type identifier) to the Server at intervals of up to 5 seconds: QwQ Expires 11 November 2026 [Page 5] Internet-Draft PRF Protocol May 2026 * An empty string ("") serves as a keepalive signal; the Server takes no action. * A non-empty string is a CW-ID (Client Worker Identifier) of the form CW, where is a decimal integer. The Server MUST spawn a streamer to handle this Client connection by sending a Type "W" message. 4.2. Type "C" - Client Connection Request 4.2.1. Purpose Sent by the Client to request a connection to a room identified by its Room ID. 4.2.2. Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ("C") | Room ID (String, max 30) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is the UTF-8 string "C". The Room ID is the identifier of the target room, at most 30 bytes. 4.2.3. Response Upon receiving a Type "C" message, the Middle node sends a response string. *Success vs. Failure:* The first character of the response string determines the outcome. A response beginning with > (U+003E) indicates success; any other response indicates failure. The remainder of the string is a server-defined, internationalized (i18n) message that MAY be displayed to the user but MUST NOT be used for protocol-level decision making. If the response indicates success, the Client SHOULD proceed to establish a bidirectional tunnel. QwQ Expires 11 November 2026 [Page 6] Internet-Draft PRF Protocol May 2026 4.3. Type "W" - Worker Handoff 4.3.1. Purpose Sent by the Server's streamer to claim a pending Client connection. 4.3.2. Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type Length (= 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type ("W") | CW-ID (String, max 30) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type field is the UTF-8 string "W". The CW-ID field is the Client Worker Identifier previously received from the Middle during polling. 4.3.3. Response Upon receiving a Type "W" message, the Middle node sends a response string. *Success vs. Failure:* The first character of the response string determines the outcome. A response beginning with > (U+003E) indicates success; any other response indicates failure. The remainder of the string is a server-defined, internationalized (i18n) message that MAY be displayed to the user but MUST NOT be used for protocol-level decision making. On success, a bidirectional tunnel is established between this streamer's socket and the corresponding Client's socket. The response message MAY contain the IP address of the connected Client as informational text. 4.3.4. HAProxy PROXY Protocol Header If the room identifier starts with the character V (U+0056, case- insensitive), the Middle node prepends a HAProxy PROXY protocol version 1 header [PROXY] to the Client-to-Server direction of the tunnel before bridging. The header has the following format: PROXY TCP4 192.0.2.1 10000 10000\r\n QwQ Expires 11 November 2026 [Page 7] Internet-Draft PRF Protocol May 2026 Where is the actual IP address of the Client. The destination address and port are placeholders (192.0.2.1:10000). This mechanism allows the target service to obtain the real Client IP address. 4.4. Type null - Untyped Raw Stream Inspection 4.4.1. Purpose When a connection arrives at the Middle node without a leading type identifier string, the Middle enters an untyped raw stream inspection mode. Rather than rejecting the connection, the Middle reads the initial bytes from the TCP stream and attempts to identify a recognized payload format. If a format is recognized, the Middle extracts routing information (the room identifier) and bridges the connection; if not, the connection is terminated with an error. This is not a general-purpose passthrough - it is a protocol-defined extension point that allows PRF to interoperate with existing application protocols without requiring a PRF-specific client. The specific format described below is the Minecraft client handshake, which PRF happens to be compatible with by design. 4.4.2. Recognized Format: Minecraft Client Handshake The Minecraft client handshake packet is one payload format recognized in the null-type mode. When the Middle identifies this format, it extracts a room identifier from the Server Name Indication (SNI) hostname carried in the packet. The packet format is defined by the Minecraft protocol. Within PRF, the relevant fields are: QwQ Expires 11 November 2026 [Page 8] Internet-Draft PRF Protocol May 2026 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Packet Length (VarInt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet ID = 0x00 (Byte) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol Version (VarInt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Name Length (VarInt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Name (UTF-8 bytes) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port (Unsigned Short) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next State (VarInt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Total Packet Length MUST be at least 10 bytes and at most 100 bytes. The Packet ID MUST be 0x00 (Handshake). The Server Name Length MUST be at least 5. 4.4.3. Room ID Extraction The Middle node extracts the subdomain from the Server Name (SNI) hostname by taking all characters before the first . (U+002E) character. For example, if the SNI is myroom.relay.example.com, the extracted room ID is myroom. The full handshake packet is buffered and forwarded unmodified to the target Server after the tunnel is established. 4.4.4. Failure Handling If the room ID cannot be found, the Middle node sends a Minecraft Disconnect/Login packet (Packet ID 0x00) to the Client with a JSON reason string in the format: {"text":""} This terminates the Client connection with an appropriate error message displayed in the Minecraft client. 5. Protocol Constants The following constants are defined by the PRF protocol: QwQ Expires 11 November 2026 [Page 9] Internet-Draft PRF Protocol May 2026 +===================+===========+===============================+ | Constant | Value | Description | +===================+===========+===============================+ | Maximum Room ID | 30 bytes | Maximum UTF-8 byte length of | | Length | | a room/server identifier | +-------------------+-----------+-------------------------------+ | Maximum Response | 100 bytes | Maximum UTF-8 byte length of | | Length | | a Middle response string | +-------------------+-----------+-------------------------------+ | Minimum MC Packet | 10 bytes | Minimum Minecraft handshake | | Length | | packet total length | +-------------------+-----------+-------------------------------+ | Maximum MC Packet | 100 bytes | Maximum Minecraft handshake | | Length | | packet total length | +-------------------+-----------+-------------------------------+ | Minimum Server | 5 bytes | Minimum SNI hostname length | | Name Length | | | +-------------------+-----------+-------------------------------+ | Maximum VarInt | 5 | Maximum bytes for a single | | Bytes | | VarInt encoding | +-------------------+-----------+-------------------------------+ | Poll Interval | 5 seconds | Interval at which the Server | | | | polls for new CW-IDs | +-------------------+-----------+-------------------------------+ | Initial Read | 5 seconds | Middle socket read timeout | | Timeout | | for type detection | +-------------------+-----------+-------------------------------+ | Reconnect Delay | 10 | Delay before a Server | | | seconds | reconnects after disconnect | +-------------------+-----------+-------------------------------+ | Streamer Bridge | 10 | Delay before a MiddleStreamer | | Delay | seconds | begins bridging data | +-------------------+-----------+-------------------------------+ | CW-ID Prefix | "CW" | Prefix for Client Worker | | | | Identifiers | +-------------------+-----------+-------------------------------+ | PROXY destination | 192.0.2.1 | Placeholder destination IP in | | address | | PROXY header | +-------------------+-----------+-------------------------------+ | PROXY destination | 10000 | Placeholder destination port | | port | | in PROXY header | +-------------------+-----------+-------------------------------+ Table 1 QwQ Expires 11 November 2026 [Page 10] Internet-Draft PRF Protocol May 2026 6. Protocol Flow 6.1. Server Registration and Client Connection The following diagram illustrates the normal protocol flow for a Server registering and a Client connecting: Server Middle Client | | | |--- "S" + roomId ------------>| | |<-- ">success" ---------------| | | | | | |<-- "C" + roomId -------------| | |--- ">success" -------------->| | | | |<-- "CW0" (poll) -------------| | |--- "W" + "CW0" ------------->| | |<-- ">success ()" ---------| | | | | |<================== Bidirectional Tunnel ===================>| | (raw TCP relay) | (raw TCP relay) | 6.2. Untyped Raw Stream Inspection (e.g., Minecraft Client) Native Client Middle Server | | | |--- MC Handshake ------------>| | | (SNI: myroom.relay.example.com) | | | |--- extracts roomId="myroom" | | |--- assigns CW-ID | | | | | |--- "CW0" (poll) ------------>| | |<-- "W" + "CW0" --------------| | | | |<================== Bidirectional Tunnel ===================>| | (handshake forwarded) | (handshake forwarded) | 7. Security Considerations The PRF protocol as defined in this document does not provide any form of encryption, authentication, or integrity protection. All data, including room identifiers, is transmitted in cleartext over TCP. The following security implications should be considered: * *Traffic Interception:* Any party on the network path can read all tunneled data, including the room identifier and any application- layer content. QwQ Expires 11 November 2026 [Page 11] Internet-Draft PRF Protocol May 2026 * *Traffic Injection:* Without integrity protection, an attacker can inject or modify packets in transit. * *Room ID Enumeration:* Room identifiers are transmitted in cleartext and can be observed or guessed by an attacker, allowing unauthorized connection to a Server. * *No Server Authentication:* Clients have no cryptographic means to verify that they are connecting to the intended Server or through a legitimate Middle node. * *No Client Authentication:* Servers accept connections from any Client that provides the correct room identifier. PRF is designed to provide no additional security guarantees beyond those offered by the underlying transport. The protocol itself does not perform encryption, authentication, content inspection, or access control. Consequently, the overall security of a PRF-tunneled connection depends entirely on the security properties of the application-layer protocol carried within the tunnel. Implementations and deployments SHOULD ensure that the tunneled protocol provides its own encryption and authentication if confidentiality and integrity are required. 8. IANA Considerations This document has no IANA actions. --- back 9. Acknowledgements The PRF protocol name is a playful backronym: "Prf is Reversed Frp," referencing the frp (Fast Reverse Proxy) tool that inspired its design. 10. Normative References [PROXY] HAProxy Technologies, "HAProxy Proxy Protocol", 2011, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . QwQ Expires 11 November 2026 [Page 12] Internet-Draft PRF Protocol May 2026 Author's Address Venti QwQ Email: huzpsb@qq.com QwQ Expires 11 November 2026 [Page 13]