Visual RFC.
ALL RFCs / RFC 1928
Read the RFC ↗
RFC 1928 / SOCKS PROXY RELAY

Keep UDP headers and TCP association lifetime distinct

05

UDP ASSOCIATE uses a TCP control connection, then separate header-wrapped UDP datagrams travel through its relay endpoint.

DIAGRAMRead RFC section 7 ↗
RFC 1928 · § 7EXAMPLE
6 / 6
Keep UDP headers and TCP association lifetime distinctSix UDP association scenes. TCP CMD03 with unknown all-zero client endpoint obtains relay192.0.2.10 port53000 while TCP stays open. A standalone IPv6-target datagram sent to that relay carries22 header octets before Hi; verified3198 corrects the old20-byte allowance. Target replies are encapsulated back to the client without a new delivery acknowledgement. Independent wrong-source and unsupported-fragment datagrams stop before forwarding. Closing control TCP ends the association; later UDP cannot preserve it. This model does not implement fragmentation reassembly or a proxy service.Control TCP closed: association endedClientSOCKSTCP control terminatedASSOCIATION ENDEDkeep association alive with UDPLater datagrams cannot revive it
06
End the association when TCP closes.

The control TCP connection terminates, ending the association. A later UDP packet cannot keep that association alive and is stopped from using it.

Source for this drawing: RFC 1928 · Read RFC section 7 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A request starts a conversation.

A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.

Helpful first, if these ideas are unfamiliar

RFC 9293 TCP RFC 768 UDP RFC 8200 IPv6

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

What changed
RFC1928 §7 IPv6 allowance20Verified erratum3198:22 octets

The IPv6 SOCKS UDP header totals2+1+1+16+2=22 octets before payload and method-dependent overhead. The programming-interface allowance is corrected from20 to22.

Read the updated RFC section ↗
KEY POINT

The UDP relay belongs to a live TCP association.

  • UDP ASSOCIATE DST.ADDR/DST.PORT describe where the client expects to send UDP from. If unknown, the client MUST use an all-zero address and port. The reply BND endpoint is where the client MUST send relay datagrams; the server MAY use the request information to limit access.
  • Each UDP request has two reserved00 octets, FRAG, ATYP, destination address, port and DATA. The relay silently forwards or drops; returning datagrams MUST get the SOCKS UDP header and required method encapsulation. Verified erratum3198 gives IPv6 overhead22 bytes, not20.
  • The relay MUST record the expected client IP and MUST drop another source IP. Fragment support is optional; without it every nonzero FRAG MUST be dropped. The association terminates when its TCP connection terminates.
DETAILS

FRAG00 is standalone. With fragmentation implemented, the high bit marks the final fragment and positions are1–127; reassembly rules apply and the timer MUST be at least5 seconds. This guide does not implement reassembly. The programming interface MUST reserve10+method bytes for IPv4,262+method for domains and22+method for IPv6, the last corrected by3198. Domain262 is the maximum-name allowance, not every domain header size. Addresses, relay port53000 and payload Hi are fictional. No UDP delivery acknowledgement, automatic reliability, SOCKS VPN or confidentiality is implied.

Read the RFC section ↗

All chapters in RFC 1928

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗