< draft-eddy-rfc793bis-02.txt		draft-eddy-rfc793bis-03.txt >
	Internet Engineering Task Force W. Eddy, Ed.		Internet Engineering Task Force W. Eddy, Ed.
	Internet-Draft MTI Systems		Internet-Draft MTI Systems
	Obsoletes: 793 (if approved) March 27, 2014		Obsoletes: 793, 6093 (if approved) August 12, 2014
			Updates: 1122 (if approved)
	Intended status: Standards Track		Intended status: Standards Track
	Expires: September 28, 2014		Expires: February 13, 2015
	Transmission Control Protocol Specification		Transmission Control Protocol Specification
	draft-eddy-rfc793bis-02		draft-eddy-rfc793bis-03
	Abstract		Abstract
	This document specifies the Internet's Transmission Control Protocol		This document specifies the Internet's Transmission Control Protocol
	(TCP). TCP is an important transport layer protocol in the Internet		(TCP). TCP is an important transport layer protocol in the Internet
	stack, and has continuously evolved over decades of use and growth of		stack, and has continuously evolved over decades of use and growth of
	the Internet. Over this time, a number of changes have been made to		the Internet. Over this time, a number of changes have been made to
	TCP as it was specified in RFC 793, though these have only been		TCP as it was specified in RFC 793, though these have only been
	documented in a piecemeal fashion. This document collects and brings		documented in a piecemeal fashion. This document collects and brings
	those changes together with the protocol specification from RFC 793.		those changes together with the protocol specification from RFC 793.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 49 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 28, 2014.		This Internet-Draft will expire on February 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 47 ¶		skipping to change at page 2, line 47 ¶
	3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13		3.3. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 13
	3.4. Establishing a connection . . . . . . . . . . . . . . . . 19		3.4. Establishing a connection . . . . . . . . . . . . . . . . 19
	3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 26		3.5. Closing a Connection . . . . . . . . . . . . . . . . . . 26
	3.6. Precedence and Security . . . . . . . . . . . . . . . . . 28		3.6. Precedence and Security . . . . . . . . . . . . . . . . . 28
	3.7. Data Communication . . . . . . . . . . . . . . . . . . . 29		3.7. Data Communication . . . . . . . . . . . . . . . . . . . 29
	3.8. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33		3.8. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 33
	3.8.1. User/TCP Interface . . . . . . . . . . . . . . . . . 33		3.8.1. User/TCP Interface . . . . . . . . . . . . . . . . . 33
	3.8.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 40		3.8.2. TCP/Lower-Level Interface . . . . . . . . . . . . . . 40
	3.9. Event Processing . . . . . . . . . . . . . . . . . . . . 40		3.9. Event Processing . . . . . . . . . . . . . . . . . . . . 41
	3.10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 63		3.10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 64
	4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 68		4. Changes from RFC 793 . . . . . . . . . . . . . . . . . . . . 69
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 70		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
	6. Security and Privacy Considerations . . . . . . . . . . . . . 70		6. Security and Privacy Considerations . . . . . . . . . . . . . 72
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 71		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 73
	8.1. Normative References . . . . . . . . . . . . . . . . . . 71		8.1. Normative References . . . . . . . . . . . . . . . . . . 73
	8.2. Informative References . . . . . . . . . . . . . . . . . 71		8.2. Informative References . . . . . . . . . . . . . . . . . 73
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72		Appendix A. TCP Requirement Summary . . . . . . . . . . . . . . 73
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 76
	1. Purpose and Scope		1. Purpose and Scope
	In 1981, RFC 793 [2] was released, documenting the Transmission		In 1981, RFC 793 [2] was released, documenting the Transmission
	Control Protocol (TCP), and replacing earlier specifications for TCP		Control Protocol (TCP), and replacing earlier specifications for TCP
	that had been published in the past.		that had been published in the past.
	Since that time, TCP has been implemented many times, and has been		Since then, TCP has been implemented many times, and has been used as
	used as a transport protocol for numerous applications on the		a transport protocol for numerous applications on the Internet.
	Internet.
	For several decades, RFC 793 plus a number of other documents have		For several decades, RFC 793 plus a number of other documents have
	combined to serve as the specification for TCP [3]. Over time, a		combined to serve as the specification for TCP [4]. Over time, a
	number of errata have been identified on RFC 793, as well as		number of errata have been identified on RFC 793, as well as
	deficiencies in security, performance, and other aspects. A number		deficiencies in security, performance, and other aspects. A number
	of enhancements has grown and been documented separately. These were		of enhancements has grown and been documented separately. These were
	never accumulated together into an update to the base specification.		never accumulated together into an update to the base specification.
	The purpose of this document is to bring together all of the IETF		The purpose of this document is to bring together all of the IETF
	Standards Track changes that have been made to the basic TCP		Standards Track changes that have been made to the basic TCP
	functional specification and unify them into an update of the RFC 793		functional specification and unify them into an update of the RFC 793
	protocol specification. Some companion documents are referenced for		protocol specification. Some companion documents are referenced for
	important algorithms that TCP uses (e.g. for congestion control), but		important algorithms that TCP uses (e.g. for congestion control), but
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	provide explanation of the theory of operation, rationale, and		provide explanation of the theory of operation, rationale, and
	detailed discussion of design decisions. This document only focuses		detailed discussion of design decisions. This document only focuses
	on the normative behavior of the protocol.		on the normative behavior of the protocol.
	TEMPORARY EDITOR'S NOTE: This is an early revision in the process of		TEMPORARY EDITOR'S NOTE: This is an early revision in the process of
	updating RFC 793. Many planned changes are not yet incorporated.		updating RFC 793. Many planned changes are not yet incorporated.
	***Please do not use this revision as a basis for any work or		***Please do not use this revision as a basis for any work or
	reference.***		reference.***
	TODO: describe the subsequent structure of the document to-be (e.g.		A list of changes from RFC 793 is contained in Section 4.
	will it follow the newtcp BSD implementation?), and mention that a
	list of changes from RFC 793 will be kept in the final section
	TEMPORARY EDITOR'S NOTE: the current revision of this document does		TEMPORARY EDITOR'S NOTE: the current revision of this document does
	not yet collect all of the changes that will be in the final version.		not yet collect all of the changes that will be in the final version.
	The set of content changes planned for future revisions is roughly:		The set of content changes planned for each revision is roughly:
	-00 was a proposal for the scope of the document and description		-00 was a proposal for the scope of the document and description
	of the need for an update to RFC 793		of the need for an update to RFC 793
	-01 incorporated the RFC 793 section 3 content with no additional		-01 incorporated the RFC 793 section 3 content with no additional
	changes into XML2RFC format for easy tracking of the changes		changes into XML2RFC format for easy tracking of the changes
	between RFC 793 and future revisions of the document		between RFC 793 and future revisions of the document
	-02 incorporates the verified errata on RFC 793 as of March 20,		-02 incorporates the verified errata on RFC 793 as of March 20,
	2014		2014
	-03 and beyond are intended to incorporate changes from other RFCs		-03 incorporates urgent pointer changes from RFC 6093
			-04 will incorporate RFC 6528
			-05 and beyond are intended to incorporate changes from other RFCs
	that updated 793		that updated 793
	3. Functional Specification		3. Functional Specification
	3.1. Header Format		3.1. Header Format
	TCP segments are sent as internet datagrams. The Internet Protocol		TCP segments are sent as internet datagrams. The Internet Protocol
	header carries several information fields, including the source and		header carries several information fields, including the source and
	destination host addresses [2]. A TCP header follows the internet		destination host addresses [2]. A TCP header follows the internet
	header, supplying information specific to the TCP protocol. This		header, supplying information specific to the TCP protocol. This
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 27 ¶
	The TCP Length is the TCP header length plus the data length in		The TCP Length is the TCP header length plus the data length in
	octets (this is not an explicitly transmitted quantity, but is		octets (this is not an explicitly transmitted quantity, but is
	computed), and it does not count the 12 octets of the pseudo		computed), and it does not count the 12 octets of the pseudo
	header.		header.
	Urgent Pointer: 16 bits		Urgent Pointer: 16 bits
	This field communicates the current value of the urgent pointer as		This field communicates the current value of the urgent pointer as
	a positive offset from the sequence number in this segment. The		a positive offset from the sequence number in this segment. The
	urgent pointer points to the sequence number of the last octet in a		urgent pointer points to the sequence number of the octet following
	sequence of urgent data. This field is only be interpreted in		the urgent data. This field is only be interpreted in segments
	segments with the URG control bit set. EDITOR'S NOTE: TODO need to		with the URG control bit set.
	incorporate RFC 6093 here.
	Options: variable		Options: variable
	Options may occupy space at the end of the TCP header and are a		Options may occupy space at the end of the TCP header and are a
	multiple of 8 bits in length. All options are included in the		multiple of 8 bits in length. All options are included in the
	checksum. An option may begin on any octet boundary. There are		checksum. An option may begin on any octet boundary. There are
	two cases for the format of an option:		two cases for the format of an option:
	Case 1: A single octet of option-kind.		Case 1: A single octet of option-kind.
	skipping to change at page 30, line 40 ¶		skipping to change at page 30, line 40 ¶
	RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]		RTO = min[UBOUND,max[LBOUND,(BETA*SRTT)]]
	where UBOUND is an upper bound on the timeout (e.g., 1 minute),		where UBOUND is an upper bound on the timeout (e.g., 1 minute),
	LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is		LBOUND is a lower bound on the timeout (e.g., 1 second), ALPHA is
	a smoothing factor (e.g., .8 to .9), and BETA is a delay variance		a smoothing factor (e.g., .8 to .9), and BETA is a delay variance
	factor (e.g., 1.3 to 2.0).		factor (e.g., 1.3 to 2.0).
	The Communication of Urgent Information		The Communication of Urgent Information
			As a result of implementation differences and middlebox interactions,
			new applications SHOULD NOT employ the TCP urgent mechanism.
			However, TCP implementations MUST still include support for the
			urgent mechanism. Details can be found in RFC 6093 [5].
	The objective of the TCP urgent mechanism is to allow the sending		The objective of the TCP urgent mechanism is to allow the sending
	user to stimulate the receiving user to accept some urgent data and		user to stimulate the receiving user to accept some urgent data and
	to permit the receiving TCP to indicate to the receiving user when		to permit the receiving TCP to indicate to the receiving user when
	all the currently known urgent data has been received by the user.		all the currently known urgent data has been received by the user.
	This mechanism permits a point in the data stream to be designated as		This mechanism permits a point in the data stream to be designated as
	the end of urgent information. Whenever this point is in advance of		the end of urgent information. Whenever this point is in advance of
	the receive sequence number (RCV.NXT) at the receiving TCP, that TCP		the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
	must tell the user to go into "urgent mode"; when the receive		must tell the user to go into "urgent mode"; when the receive
	sequence number catches up to the urgent pointer, the TCP must tell		sequence number catches up to the urgent pointer, the TCP must tell
	skipping to change at page 31, line 16 ¶		skipping to change at page 31, line 21 ¶
	transmitted. The URG control flag indicates that the urgent field is		transmitted. The URG control flag indicates that the urgent field is
	meaningful and must be added to the segment sequence number to yield		meaningful and must be added to the segment sequence number to yield
	the urgent pointer. The absence of this flag indicates that there is		the urgent pointer. The absence of this flag indicates that there is
	no urgent data outstanding.		no urgent data outstanding.
	To send an urgent indication the user must also send at least one		To send an urgent indication the user must also send at least one
	data octet. If the sending user also indicates a push, timely		data octet. If the sending user also indicates a push, timely
	delivery of the urgent information to the destination process is		delivery of the urgent information to the destination process is
	enhanced.		enhanced.
			A TCP MUST support a sequence of urgent data of any length. [3]
			A TCP MUST inform the application layer asynchronously whenever it
			receives an Urgent pointer and there was previously no pending urgent
			data, or whenvever the Urgent pointer advances in the data stream.
			There MUST be a way for the application to learn how much urgent data
			remains to be read from the connection, or at least to determine
			whether or not more urgent data remains to be read. [3]
	Managing the Window		Managing the Window
	The window sent in each segment indicates the range of sequence		The window sent in each segment indicates the range of sequence
	numbers the sender of the window (the data receiver) is currently		numbers the sender of the window (the data receiver) is currently
	prepared to accept. There is an assumption that this is related to		prepared to accept. There is an assumption that this is related to
	the currently available data buffer space available for this		the currently available data buffer space available for this
	connection.		connection.
	Indicating a large window encourages transmissions. If more data		Indicating a large window encourages transmissions. If more data
	arrives than can be accepted, it will be discarded. This will result		arrives than can be accepted, it will be discarded. This will result
	skipping to change at page 35, line 43 ¶		skipping to change at page 36, line 11 ¶
	which case, an automatic OPEN would be done. If the calling		which case, an automatic OPEN would be done. If the calling
	process is not authorized to use this connection, an error is		process is not authorized to use this connection, an error is
	returned.		returned.
	If the PUSH flag is set, the data must be transmitted promptly		If the PUSH flag is set, the data must be transmitted promptly
	to the receiver, and the PUSH bit will be set in the last TCP		to the receiver, and the PUSH bit will be set in the last TCP
	segment created from the buffer. If the PUSH flag is not set,		segment created from the buffer. If the PUSH flag is not set,
	the data may be combined with data from subsequent SENDs for		the data may be combined with data from subsequent SENDs for
	transmission efficiency.		transmission efficiency.
			New applications SHOULD NOT set the URGENT flag [5] due to
			implementation differences and middlebox issues.
	If the URGENT flag is set, segments sent to the destination TCP		If the URGENT flag is set, segments sent to the destination TCP
	will have the urgent pointer set. The receiving TCP will		will have the urgent pointer set. The receiving TCP will
	signal the urgent condition to the receiving process if the		signal the urgent condition to the receiving process if the
	urgent pointer indicates that data preceding the urgent pointer		urgent pointer indicates that data preceding the urgent pointer
	has not been consumed by the receiving process. The purpose of		has not been consumed by the receiving process. The purpose of
	urgent is to stimulate the receiver to process the urgent data		urgent is to stimulate the receiver to process the urgent data
	and to indicate to the receiver when all the currently known		and to indicate to the receiver when all the currently known
	urgent data has been received. The number of times the sending		urgent data has been received. The number of times the sending
	user's TCP signals urgent will not necessarily be equal to the		user's TCP signals urgent will not necessarily be equal to the
	number of times the receiving user will be notified of the		number of times the receiving user will be notified of the
	skipping to change at page 44, line 42 ¶		skipping to change at page 45, line 42 ¶
	resources".		resources".
	ESTABLISHED STATE		ESTABLISHED STATE
	CLOSE-WAIT STATE		CLOSE-WAIT STATE
	Segmentize the buffer and send it with a piggybacked		Segmentize the buffer and send it with a piggybacked
	acknowledgment (acknowledgment value = RCV.NXT). If there is		acknowledgment (acknowledgment value = RCV.NXT). If there is
	insufficient space to remember this buffer, simply return		insufficient space to remember this buffer, simply return
	"error: insufficient resources".		"error: insufficient resources".
	If the urgent flag is set, then SND.UP <- SND.NXT-1 and set the		If the urgent flag is set, then SND.UP <- SND.NXT and set the
	urgent pointer in the outgoing segments.		urgent pointer in the outgoing segments.
	FIN-WAIT-1 STATE		FIN-WAIT-1 STATE
	FIN-WAIT-2 STATE		FIN-WAIT-2 STATE
	CLOSING STATE		CLOSING STATE
	LAST-ACK STATE		LAST-ACK STATE
	TIME-WAIT STATE		TIME-WAIT STATE
	Return "error: connection closing" and do not service request.		Return "error: connection closing" and do not service request.
	skipping to change at page 69, line 28 ¶		skipping to change at page 70, line 28 ¶
	indentation is not exactly the same.		indentation is not exactly the same.
	The -02 revision of this document incorporates errata that have been		The -02 revision of this document incorporates errata that have been
	verified:		verified:
	Errata ID 573: Reported by Bob Braden (note: This errata basically		Errata ID 573: Reported by Bob Braden (note: This errata basically
	is just a reminder that RFC 1122 updates 793. Some of the		is just a reminder that RFC 1122 updates 793. Some of the
	associated changes are left pending to a separate revision that		associated changes are left pending to a separate revision that
	incorporates 1122. Bob's mention of PUSH in 793 section 2.8 was		incorporates 1122. Bob's mention of PUSH in 793 section 2.8 was
	not applicable here because that section was not part of the		not applicable here because that section was not part of the
	"functional specification" and the note on the urgent pointer will		"functional specification". Also the 1122 text on the
	be revised when changes to account for RFC 6093 are incorporated.		retransmission timeout also has been updated by subsequent RFCs,
	Also the 1122 text on the retransmission timeout also has been		so the change here deviates from Bob's suggestion to apply the
	updated by subsequent RFCs, so the change here deviates from Bob's		1122 text.)
	suggestion to apply the 1122 text.)
	Errata ID 574: Reported by Yin Shuming		Errata ID 574: Reported by Yin Shuming
	Errata ID 700: Reported by Yin Shuming		Errata ID 700: Reported by Yin Shuming
	Errata ID 701: Reported by Yin Shuming		Errata ID 701: Reported by Yin Shuming
	Errata ID 1283: Reported by Pei-chun Cheng		Errata ID 1283: Reported by Pei-chun Cheng
	Errata ID 1561: Reported by Constantin Hagemeier		Errata ID 1561: Reported by Constantin Hagemeier
	Errata ID 1562: Reported by Constantin Hagemeier		Errata ID 1562: Reported by Constantin Hagemeier
	Errata ID 1564: Reported by Constantin Hagemeier		Errata ID 1564: Reported by Constantin Hagemeier
	Errata ID 1565: Reported by Constantin Hagemeier		Errata ID 1565: Reported by Constantin Hagemeier
	Errata ID 1571: Reported by Constantin Hagemeier		Errata ID 1571: Reported by Constantin Hagemeier
	Errata ID 1572: Reported by Constantin Hagemeier		Errata ID 1572: Reported by Constantin Hagemeier
	skipping to change at page 70, line 19 ¶		skipping to change at page 71, line 19 ¶
	There is an errata 3305 currently reported that need to be		There is an errata 3305 currently reported that need to be
	verified, held, or rejected by the ADs; it is addressing the same		verified, held, or rejected by the ADs; it is addressing the same
	issue as draft-gont-tcpm-tcp-seq-validation and was not attempted		issue as draft-gont-tcpm-tcp-seq-validation and was not attempted
	to be applied to this document.		to be applied to this document.
	Not related to RFC 793 content, this revision also makes small tweaks		Not related to RFC 793 content, this revision also makes small tweaks
	to the introductory text, fixes indentation of the pseudoheader		to the introductory text, fixes indentation of the pseudoheader
	diagram, and notes that the Security Considerations should also		diagram, and notes that the Security Considerations should also
	include privacy, when this section is written.		include privacy, when this section is written.
			The -03 revision of this document revises all discussion of the
			urgent pointer in order to comply with RFC 6093, 1122, and 1011.
			Since 1122 held requirements on the urgent pointer, the full list of
			requirements was brought into an appendix of this document, so that
			it can be updated as-needed.
	TODO: Incomplete list of planned changes - these need to be added to		TODO: Incomplete list of planned changes - these need to be added to
	and made more specific, as the document proceeds:		and made more specific, as the document proceeds:
	1. incorporate 1122 additions		1. incorporate 1122 additions
	2. point to major additional docs like 1323bis and 5681		2. point to major additional docs like 1323bis and 5681
	3. incorporate relevant parts of 3168 (ECN)		3. incorporate relevant parts of 3168 (ECN)
	4. incorporate 6093 (urgent pointer)		4. incorporate 6528 (sequence number)
	5. incorporate 6528 (sequence number)		5. incorporate Fernando's new number-checking fixes (if past the
	6. incorporate Fernando's new number-checking fixes (if past the
	IESG in time)		IESG in time)
	7. point to PMTUD?		6. point to PMTUD?
	8. point to 5461 (soft errors)		7. point to 5461 (soft errors)
	9. mention 5961 state machine option		8. mention 5961 state machine option
	10. mention 6161 (reducing TIME-WAIT)		9. mention 6161 (reducing TIME-WAIT)
	11. incorporate 6429 (ZWP/persist)		10. incorporate 6429 (ZWP/persist)
	12. incorporate 6691 (MSS)		11. incorporate 6691 (MSS)
			12. look at Tony Sabatini suggestion for describing DO field
			13. clearly specify treatment of reserved bits (see TCPM thread on
			EDO draft April 25, 2014)
			14. look at possible mention of draft-minshall-nagle (e.g. as in
			Linux)
			15. make sure that clarifications in RFC 1011 are captured
			16. per TCPM discussion, discussion of checking reserved bits may
			need to be altered from 793
	5. IANA Considerations		5. IANA Considerations
	This memo includes no request to IANA. Existing IANA registries for		This memo includes no request to IANA. Existing IANA registries for
	TCP parameters are sufficient.		TCP parameters are sufficient.
	TODO: check whether entries pointing to 793 and other documents		TODO: check whether entries pointing to 793 and other documents
	obsoleted by this one should be updated to point to this one instead.		obsoleted by this one should be updated to point to this one instead.
	6. Security and Privacy Considerations		6. Security and Privacy Considerations
	TODO		TODO
			See RFC 6093 [5] for discussion of security considerations related to
			the urgent pointer field.
	Editor's Note: Scott Brim mentioned that this should include a		Editor's Note: Scott Brim mentioned that this should include a
	PERPASS/privacy review.		PERPASS/privacy review.
	7. Acknowledgements		7. Acknowledgements
	This document is largely a revision of RFC 793, which Jon Postel was		This document is largely a revision of RFC 793, which Jon Postel was
	the editor of. Due to his excellent work, it was able to last for		the editor of. Due to his excellent work, it was able to last for
	three decades before we felt the need to revise it.		three decades before we felt the need to revise it.
	Andre Oppermann was a contributor and helped to edit the first		Andre Oppermann was a contributor and helped to edit the first
	skipping to change at page 71, line 28 ¶		skipping to change at page 72, line 46 ¶
	Yoshifumi Nishida		Yoshifumi Nishida
	Pasi Sarolahti		Pasi Sarolahti
	On the TCPM mailing list, and at the IETF 88 meeting in Vancouver,		On the TCPM mailing list, and at the IETF 88 meeting in Vancouver,
	helpful comments, critiques, and reviews were received from (listed		helpful comments, critiques, and reviews were received from (listed
	alphebetically): David Borman, Yuchung Cheng, Martin Duke, Kevin		alphebetically): David Borman, Yuchung Cheng, Martin Duke, Kevin
	Lahey, Kevin Mason, Matt Mathis, Hagen Paul Pfeifer, Anthony		Lahey, Kevin Mason, Matt Mathis, Hagen Paul Pfeifer, Anthony
	Sabatini, Joe Touch, Reji Varghese, Lloyd Wood, and Alex Zimmermann.		Sabatini, Joe Touch, Reji Varghese, Lloyd Wood, and Alex Zimmermann.
	This document includes content from errata that were reported by		This document includes content from errata that were reported by
	(listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan,		(listed chronologically): Yin Shuming, Bob Braden, Morris M. Keesan,
	Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta		Pei-chun Cheng, Constantin Hagemeier, Vishwas Manral, Mykyta
	Yevstifeyev, EungJun Yi, Botong Huang.		Yevstifeyev, EungJun Yi, Botong Huang.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate		[1] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	8.2. Informative References		8.2. Informative References
	[2] Postel, J., "Transmission Control Protocol", STD 7, RFC		[2] Postel, J., "Transmission Control Protocol", STD 7, RFC
	793, September 1981.		793, September 1981.
	[3] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.		[3] Braden, R., "Requirements for Internet Hosts -
			Communication Layers", STD 3, RFC 1122, October 1989.
			[4] Duke, M., Braden, R., Eddy, W., Blanton, E., and A.
	Zimmermann, "A Roadmap for Transmission Control Protocol		Zimmermann, "A Roadmap for Transmission Control Protocol
	(TCP) Specification Documents", draft-ietf-tcpm-tcp-		(TCP) Specification Documents", draft-ietf-tcpm-tcp-
	rfc4614bis-00 (work in progress), August 2013.		rfc4614bis-07 (work in progress), July 2014.
			[5] Gont, F. and A. Yourtchenko, "On the Implementation of the
			TCP Urgent Mechanism", RFC 6093, January 2011.
			Appendix A. TCP Requirement Summary
			This section is adapted from RFC 1122.
			TODO: this needs to be seriously redone, to use 793bis section
			numbers instead of 1122 ones, and all 1122 requirements need to be
			reflected in 793bis text.
			| | | | |S| |
			| | | | |H| |F
			| | | | |O|M|o
			| | |S| |U|U|o
			| | |H| |L|S|t
			| |M|O| |D|T|n
			| |U|U|M| | |o
			| |S|L|A|N|N|t
			|1122 |T|D|Y|O|O|t
			FEATURE |SECTION | | | |T|T|e
			-------------------------------------------------|--------|-|-|-|-|-|--
			| | | | | | |
			Push flag | | | | | | |
			Aggregate or queue un-pushed data |4.2.2.2 | | |x| | |
			Sender collapse successive PSH flags |4.2.2.2 | |x| | | |
			SEND call can specify PUSH |4.2.2.2 | | |x| | |
			If cannot: sender buffer indefinitely |4.2.2.2 | | | | |x|
			If cannot: PSH last segment |4.2.2.2 |x| | | | |
			Notify receiving ALP of PSH |4.2.2.2 | | |x| | |1
			Send max size segment when possible |4.2.2.2 | |x| | | |
			| | | | | | |
			Window | | | | | | |
			Treat as unsigned number |4.2.2.3 |x| | | | |
			Handle as 32-bit number |4.2.2.3 | |x| | | |
			Shrink window from right |4.2.2.16| | | |x| |
			Robust against shrinking window |4.2.2.16|x| | | | |
			Receiver's window closed indefinitely |4.2.2.17| | |x| | |
			Sender probe zero window |4.2.2.17|x| | | | |
			First probe after RTO |4.2.2.17| |x| | | |
			Exponential backoff |4.2.2.17| |x| | | |
			Allow window stay zero indefinitely |4.2.2.17|x| | | | |
			Sender timeout OK conn with zero wind |4.2.2.17| | | | |x|
			| | | | | | |
			Urgent Data | | | | | | |
			Pointer indicates first non-urgent octet |4.2.2.4 |x| | | | |
			Arbitrary length urgent data sequence |4.2.2.4 |x| | | | |
			Inform ALP asynchronously of urgent data |4.2.2.4 |x| | | | |1
			ALP can learn if/how much urgent data Q'd |4.2.2.4 |x| | | | |1
			| | | | | | |
			TCP Options | | | | | | |
			Receive TCP option in any segment |4.2.2.5 |x| | | | |
			Ignore unsupported options |4.2.2.5 |x| | | | |
			Cope with illegal option length |4.2.2.5 |x| | | | |
			Implement sending & receiving MSS option |4.2.2.6 |x| | | | |
			Send MSS option unless 536 |4.2.2.6 | |x| | | |
			Send MSS option always |4.2.2.6 | | |x| | |
			Send-MSS default is 536 |4.2.2.6 |x| | | | |
			Calculate effective send seg size |4.2.2.6 |x| | | | |
			| | | | | | |
			TCP Checksums | | | | | | |
			Sender compute checksum |4.2.2.7 |x| | | | |
			Receiver check checksum |4.2.2.7 |x| | | | |
			| | | | | | |
			Use clock-driven ISN selection |4.2.2.9 |x| | | | |
			| | | | | | |
			Opening Connections | | | | | | |
			Support simultaneous open attempts |4.2.2.10|x| | | | |
			SYN-RCVD remembers last state |4.2.2.11|x| | | | |
			Passive Open call interfere with others |4.2.2.18| | | | |x|
			Function: simultan. LISTENs for same port |4.2.2.18|x| | | | |
			Ask IP for src address for SYN if necc. |4.2.3.7 |x| | | | |
			Otherwise, use local addr of conn. |4.2.3.7 |x| | | | |
			OPEN to broadcast/multicast IP Address |4.2.3.14| | | | |x|
			Silently discard seg to bcast/mcast addr |4.2.3.14|x| | | | |
			| | | | | | |
			Closing Connections | | | | | | |
			RST can contain data |4.2.2.12| |x| | | |
			Inform application of aborted conn |4.2.2.13|x| | | | |
			Half-duplex close connections |4.2.2.13| | |x| | |
			Send RST to indicate data lost |4.2.2.13| |x| | | |
			In TIME-WAIT state for 2xMSL seconds |4.2.2.13|x| | | | |
			Accept SYN from TIME-WAIT state |4.2.2.13| | |x| | |
			| | | | | | |
			Retransmissions | | | | | | |
			Jacobson Slow Start algorithm |4.2.2.15|x| | | | |
			Jacobson Congestion-Avoidance algorithm |4.2.2.15|x| | | | |
			Retransmit with same IP ident |4.2.2.15| | |x| | |
			Karn's algorithm |4.2.3.1 |x| | | | |
			Jacobson's RTO estimation alg. |4.2.3.1 |x| | | | |
			Exponential backoff |4.2.3.1 |x| | | | |
			SYN RTO calc same as data |4.2.3.1 | |x| | | |
			Recommended initial values and bounds |4.2.3.1 | |x| | | |
			| | | | | | |
			Generating ACK's: | | | | | | |
			Queue out-of-order segments |4.2.2.20| |x| | | |
			Process all Q'd before send ACK |4.2.2.20|x| | | | |
			Send ACK for out-of-order segment |4.2.2.21| | |x| | |
			Delayed ACK's |4.2.3.2 | |x| | | |
			Delay < 0.5 seconds |4.2.3.2 |x| | | | |
			Every 2nd full-sized segment ACK'd |4.2.3.2 |x| | | | |
			Receiver SWS-Avoidance Algorithm |4.2.3.3 |x| | | | |
			| | | | | | |
			Sending data | | | | | | |
			Configurable TTL |4.2.2.19|x| | | | |
			Sender SWS-Avoidance Algorithm |4.2.3.4 |x| | | | |
			Nagle algorithm |4.2.3.4 | |x| | | |
			Application can disable Nagle algorithm |4.2.3.4 |x| | | | |
			| | | | | | |
			Connection Failures: | | | | | | |
			Negative advice to IP on R1 retxs |4.2.3.5 |x| | | | |
			Close connection on R2 retxs |4.2.3.5 |x| | | | |
			ALP can set R2 |4.2.3.5 |x| | | | |1
			Inform ALP of R1<=retxs<R2 |4.2.3.5 | |x| | | |1
			Recommended values for R1, R2 |4.2.3.5 | |x| | | |
			Same mechanism for SYNs |4.2.3.5 |x| | | | |
			R2 at least 3 minutes for SYN |4.2.3.5 |x| | | | |
			| | | | | | |
			Send Keep-alive Packets: |4.2.3.6 | | |x| | |
			- Application can request |4.2.3.6 |x| | | | |
			- Default is "off" |4.2.3.6 |x| | | | |
			- Only send if idle for interval |4.2.3.6 |x| | | | |
			- Interval configurable |4.2.3.6 |x| | | | |
			- Default at least 2 hrs. |4.2.3.6 |x| | | | |
			- Tolerant of lost ACK's |4.2.3.6 |x| | | | |
			| | | | | | |
			IP Options | | | | | | |
			Ignore options TCP doesn't understand |4.2.3.8 |x| | | | |
			Time Stamp support |4.2.3.8 | | |x| | |
			Record Route support |4.2.3.8 | | |x| | |
			Source Route: | | | | | | |
			ALP can specify |4.2.3.8 |x| | | | |1
			Overrides src rt in datagram |4.2.3.8 |x| | | | |
			Build return route from src rt |4.2.3.8 |x| | | | |
			Later src route overrides |4.2.3.8 | |x| | | |
			| | | | | | |
			Receiving ICMP Messages from IP |4.2.3.9 |x| | | | |
			Dest. Unreach (0,1,5) => inform ALP |4.2.3.9 | |x| | | |
			Dest. Unreach (0,1,5) => abort conn |4.2.3.9 | | | | |x|
			Dest. Unreach (2-4) => abort conn |4.2.3.9 | |x| | | |
			Source Quench => slow start |4.2.3.9 | |x| | | |
			Time Exceeded => tell ALP, don't abort |4.2.3.9 | |x| | | |
			Param Problem => tell ALP, don't abort |4.2.3.9 | |x| | | |
			| | | | | | |
			Address Validation | | | | | | |
			Reject OPEN call to invalid IP address |4.2.3.10|x| | | | |
			Reject SYN from invalid IP address |4.2.3.10|x| | | | |
			Silently discard SYN to bcast/mcast addr |4.2.3.10|x| | | | |
			| | | | | | |
			TCP/ALP Interface Services | | | | | | |
			Error Report mechanism |4.2.4.1 |x| | | | |
			ALP can disable Error Report Routine |4.2.4.1 | |x| | | |
			ALP can specify TOS for sending |4.2.4.2 |x| | | | |
			Passed unchanged to IP |4.2.4.2 | |x| | | |
			ALP can change TOS during connection |4.2.4.2 | |x| | | |
			Pass received TOS up to ALP |4.2.4.2 | | |x| | |
			FLUSH call |4.2.4.3 | | |x| | |
			Optional local IP addr parm. in OPEN |4.2.4.4 |x| | | | |
			-------------------------------------------------|--------|-|-|-|-|-|--
			FOOTNOTES: (1) "ALP" means Application-Layer program.
	Author's Address		Author's Address
	Wesley M. Eddy (editor)		Wesley M. Eddy (editor)
	MTI Systems		MTI Systems
	US		US
	Email: wes@mti-systems.com		Email: wes@mti-systems.com
End of changes. 23 change blocks.
	45 lines changed or deleted		244 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/