Visual RFC.
ALL RFCs / RFC 6587
Read the RFC ↗
RFC 6587 / LEGACY LOG TRANSPORT

Separate syslog roles from the TCP session

01

Syslog carries event messages from an originator toward a collector, sometimes through a relay. On each transport hop, a sender connects to a receiver. Transmission Control Protocol (TCP) supplies an ordered byte stream. This Historic RFC records deployed plain-TCP behavior; it does not recommend plain TCP for new secure logging systems.

DIAGRAMRead RFC section 3.2 ↗
RFC 6587 · § 3.2EXAMPLE
4 / 4
Separate syslog roles from the TCP sessionTwo fixed transport roles: sender creates fictional message A, initiates a connection to the configured listening receiver, then sends A/B with a separate TCP ACK arrow returning below the application exchange. Last state is a separate close example with B application outcome unknown. TCP acknowledgements are not collector storage confirmation; closure may be initiated by either endpoint.SenderReceiverLegacy plain TCP · HistoricConnection closes · either hostB stored? Application outcome unknown
04
Close without inventing a syslog success response.

Separate closure example: either TCP host can initiate close. The illustrated connection closes with message B’s application outcome unknown. There is no syslog application-level final success reply in this observed transport.

Source for this drawing: RFC 6587 · Read RFC section 3.2 ↗

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

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

RFC 9293 TCP RFC 3629 UTF-8 RFC 9846 TLS 1.3 (current)

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 syslog transport session carries application messages one way; TCP traffic can still go both ways.

  • RFC 6587 describes observations of legacy implementations, not a new Standards Track protocol with an RFC 2119 MUST/SHOULD/MAY requirement set. Its IESG Note and §4 recommend the separate TLS transport in RFC 5425; this guide preserves that distinction.
  • The transport sender initiates TCP toward the listening receiver. Sender and receiver roles stay fixed for that session. An originator or relay can be the sender; a relay or collector can be the receiver on a particular hop.
  • Observed syslog-over-TCP sessions have no application-level back-channel or acknowledgement. TCP acknowledgements, error recovery and flow control are transport functions, not proof that the collector stored an event.
  • There is no standardized TCP port assignment for this legacy protocol. TCP/514 is frequently observed but is assigned to the Shell protocol, not allocated here to syslog. Configure compatible endpoints instead of treating that observed default as an RFC requirement.
  • Either TCP endpoint can initiate closure. The document describes graceful closure on errors TCP cannot correct and no syslog application-status notification. Closing a session gives no end-to-end confirmation for messages still in transit.
DETAILS

Historic interoperability explanation only. The sample header abbreviates no transport header. No real logs or sockets are used. A relay’s transport role is per hop, not identical to the original event creator.

Read the RFC section ↗

All chapters in RFC 6587

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 ↗