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

Separate the two BIND replies

04

BIND asks the proxy to listen for an incoming secondary connection. Listening and accepting the peer are distinct events.

DIAGRAMRead RFC section 6 ↗
RFC 1928 · § 6EXAMPLE
3 / 3
Separate the two BIND repliesThree BIND stages with a pre-existing primary application/control connection assumed, not drawn. First reply follows listener creation and reports the proxy listening endpoint198.51.100.9 port41000; no incoming peer exists yet. After the anticipated incoming connection succeeds, a second REP00 reports peer203.0.113.20 port50000 to the client. Only then does the incoming secondary leg relay data through the proxy. First and second bound fields have different meanings; any failure follows failure-reply closing rules.Incoming secondary connection now relaysClientSOCKSPeerpeer datarelayed dataBoth BIND stages completedThe first reply alone was not a peer
03
Relay only after the incoming leg exists.

Both the listener stage and successful incoming-peer stage have completed. The secondary connection now relays peer data through the proxy to the client.

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

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.

KEY POINT

A listening address is not yet a connected peer.

  • BIND is used for applications needing an incoming secondary connection, normally after a primary CONNECT connection. It is a request to the SOCKS server, not a command built into FTP.
  • The first reply follows socket creation/bind and reports the proxy listening address and port. The client can notify the application server over the existing primary/control connection.
  • The second reply occurs only after the anticipated incoming connection succeeds or fails. Its BND.ADDR/BND.PORT identify the connecting host. Wait for this outcome before treating the incoming peer leg as established.
DETAILS

The primary application/control connection is assumed established and omitted from the drawing; notification is described, not a direct new SOCKS message to the peer. First reply example198.51.100.9:41000, second reply203.0.113.20:50000. Both use the same reply field names but different meanings. Held errata8867/3947 are not labeled verified. A failure at either stage follows section6 failure closing rules.

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 ↗