Encode the target and its address type
02A request names a command and target address. ATYP tells the receiver how many address bytes to read.
ATYP04 reserves sixteen address octets for2001:db8::20 before the same two-byte port. Do not use the IPv4 four-byte boundary for this field.
Source for this drawing: RFC 1928 · Read RFC section 4 ↗
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
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Address type determines the address boundary.
- The request fields are VER, CMD, RSV, ATYP, DST.ADDR and two-byte DST.PORT. VER=05 and RSV=00. Commands are CONNECT01, BIND02 and UDP ASSOCIATE03.
- ATYP01 carries four IPv4 address octets; ATYP04 carries sixteen IPv6 address octets. ATYP03 carries one length octet followed by that many domain-name octets, with no terminating NUL.
- DST.PORT and reply BND.PORT use network octet order: most significant byte first. If the negotiated method supplies integrity/confidentiality encapsulation, requests MUST use that encapsulation.
The layout is schematic, not proportional byte widths. The examples show an unencapsulated no-auth CONNECT request to port443, encoded01 BB. Target ports and addresses are chosen examples, not authorization decisions. The domain example.org occupies11 ASCII octets; internationalized domain processing and DNS resolution details are outside this bounded encoder.
Read the RFC section ↗