Path signals
draft-hardie-path-signals-00
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Expired & archived
|
|
---|---|---|---|
Author | Ted Hardie | ||
Last updated | 2017-05-01 (Latest revision 2016-10-28) | ||
Replaced by | draft-iab-path-signals, draft-iab-path-signals, RFC 8558 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document discusses the nature of the signals as they are seen by on-path elements and reflects on best practices for transports which encrypt their state mechanics.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)