idnits 2.17.1 

draft-ietf-tcpm-tcp-roadmap-05.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 20.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1471.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1448.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1455.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1461.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 198: '...      MUST, SHOULD, MAY, SHOULD NOT, a...'
     RFC 2119 keyword, line 252: '...he algorithm from a SHOULD to a MUST."...'
     RFC 2119 keyword, line 476: '...      sender SHOULD set its congestion...'


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (September 29, 2005) is 6774 days in the past.  Is
     this intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? 'RFC2026' on line 1106 looks like a reference

  -- Missing reference section? 'RFC0793' on line 1100 looks like a reference

  -- Missing reference section? 'RFC1122' on line 1103 looks like a reference

  -- Missing reference section? 'KP87' on line 1390 looks like a reference

  -- Missing reference section? 'Jac88' on line 1386 looks like a reference

  -- Missing reference section? 'JK92' on line 1380 looks like a reference

  -- Missing reference section? 'RFC2460' on line 1109 looks like a reference

  -- Missing reference section? 'RFC2581' on line 1117 looks like a reference

  -- Missing reference section? 'RFC2873' on line 1123 looks like a reference

  -- Missing reference section? 'RFC2474' on line 1112 looks like a reference

  -- Missing reference section? 'RFC2988' on line 1127 looks like a reference

  -- Missing reference section? 'RFC1323' on line 1132 looks like a reference

  -- Missing reference section? 'RFC2675' on line 1120 looks like a reference

  -- Missing reference section? 'RFC3168' on line 1152 looks like a reference

  -- Missing reference section? 'RFC3042' on line 1148 looks like a reference

  -- Missing reference section? 'MAF04' on line 1394 looks like a reference

  -- Missing reference section? 'RFC3390' on line 1156 looks like a reference

  -- Missing reference section? 'RFC3782' on line 1166 looks like a reference

  -- Missing reference section? 'RFC2018' on line 1138 looks like a reference

  -- Missing reference section? 'RFC2883' on line 1144 looks like a reference

  -- Missing reference section? 'RFC3517' on line 1159 looks like a reference

  -- Missing reference section? 'RFC1948' on line 1135 looks like a reference

  -- Missing reference section? 'RFC1321' on line 423 looks like a reference

  -- Missing reference section? 'RFC2385' on line 1141 looks like a reference

  -- Missing reference section? 'RFC3562' on line 1163 looks like a reference

  -- Missing reference section? 'RFC2140' on line 1181 looks like a reference

  -- Missing reference section? 'RFC3124' on line 1187 looks like a reference

  -- Missing reference section? 'RFC2861' on line 1184 looks like a reference

  -- Missing reference section? 'RFC3465' on line 1190 looks like a reference

  -- Missing reference section? 'SCWA99' on line 1403 looks like a reference

  -- Missing reference section? 'RFC3449' on line 1356 looks like a reference

  -- Missing reference section? 'RFC3522' on line 1193 looks like a reference

  -- Missing reference section? 'RFC3540' on line 1196 looks like a reference

  -- Missing reference section? 'RFC3649' on line 1200 looks like a reference

  -- Missing reference section? 'RFC3708' on line 1203 looks like a reference

  -- Missing reference section? 'RFC3742' on line 1209 looks like a reference

  -- Missing reference section? 'RFC4015' on line 1170 looks like a reference

  -- Missing reference section? 'RFC4138' on line 1212 looks like a reference

  -- Missing reference section? 'RFC1106' on line 1219 looks like a reference

  -- Missing reference section? 'RFC1110' on line 1222 looks like a reference

  -- Missing reference section? 'RFC1146' on line 1225 looks like a reference

  -- Missing reference section? 'RFC1263' on line 1228 looks like a reference

  -- Missing reference section? 'RFC1379' on line 1231 looks like a reference

  -- Missing reference section? 'RFC1644' on line 1234 looks like a reference

  -- Missing reference section? 'RFC1693' on line 1237 looks like a reference

  -- Missing reference section? 'RFC0813' on line 1242 looks like a reference

  -- Missing reference section? 'RFC0814' on line 1245 looks like a reference

  -- Missing reference section? 'RFC0816' on line 1248 looks like a reference

  -- Missing reference section? 'RFC0817' on line 1251 looks like a reference

  -- Missing reference section? 'RFC0872' on line 1254 looks like a reference

  -- Missing reference section? 'RFC0896' on line 1259 looks like a reference

  -- Missing reference section? 'RFC0964' on line 1262 looks like a reference

  -- Missing reference section? 'RFC1072' on line 1274 looks like a reference

  -- Missing reference section? 'RFC1185' on line 1284 looks like a reference

  -- Missing reference section? 'RFC2914' on line 1343 looks like a reference

  -- Missing reference section? 'RFC2488' on line 1323 looks like a reference

  -- Missing reference section? 'RFC2757' on line 1331 looks like a reference

  -- Missing reference section? 'RFC2760' on line 1334 looks like a reference

  -- Missing reference section? 'MM96' on line 1398 looks like a reference

  -- Missing reference section? 'RFC3135' on line 1349 looks like a reference

  -- Missing reference section? 'RFC3481' on line 1360 looks like a reference

  -- Missing reference section? 'RFC3819' on line 1369 looks like a reference

  -- Missing reference section? 'RFC0879' on line 1256 looks like a reference

  -- Missing reference section? 'RFC1071' on line 1270 looks like a reference

  -- Missing reference section? 'RFC1624' on line 1299 looks like a reference

  -- Missing reference section? 'RFC1936' on line 1302 looks like a reference

  -- Missing reference section? 'RFC2525' on line 1327 looks like a reference

  -- Missing reference section? 'RFC2923' on line 1346 looks like a reference

  -- Missing reference section? 'RFC3360' on line 1353 looks like a reference

  -- Missing reference section? 'RFC3493' on line 1365 looks like a reference

  -- Missing reference section? 'RFC1066' on line 1266 looks like a reference

  -- Missing reference section? 'RFC1156' on line 1277 looks like a reference

  -- Missing reference section? 'RFC1213' on line 1287 looks like a reference

  -- Missing reference section? 'RFC2012' on line 1305 looks like a reference

  -- Missing reference section? 'RFC2452' on line 1319 looks like a reference

  -- Missing reference section? 'RFC4022' on line 1374 looks like a reference

  -- Missing reference section? 'RFC1180' on line 1281 looks like a reference

  -- Missing reference section? 'RFC1470' on line 1294 looks like a reference

  -- Missing reference section? 'RFC2398' on line 1309 looks like a reference

  -- Missing reference section? 'RFC1337' on line 1291 looks like a reference

  -- Missing reference section? 'RFC2415' on line 1312 looks like a reference

  -- Missing reference section? 'RFC2416' on line 1315 looks like a reference

  -- Missing reference section? 'RFC2884' on line 1339 looks like a reference


     Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 90 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                            M. Duke
3	Internet-Draft                                      Boeing Phantom Works
4	Expires: April 2, 2006                                         R. Braden
5	                                      USC Information Sciences Institute
6	                                                                 W. Eddy
7	                                         Verizon Federal Network Systems
8	                                                              E. Blanton
9	                                      Purdue University Computer Science
10	                                                      September 29, 2005

12	               A Roadmap for TCP Specification Documents
13	                     draft-ietf-tcpm-tcp-roadmap-05

15	Status of this Memo

17	   By submitting this Internet-Draft, each author represents that any
18	   applicable patent or other IPR claims of which he or she is aware
19	   have been or will be disclosed, and any of which he or she becomes
20	   aware will be disclosed, in accordance with Section 6 of BCP 79.

22	   Internet-Drafts are working documents of the Internet Engineering
23	   Task Force (IETF), its areas, and its working groups.  Note that
24	   other groups may also distribute working documents as Internet-
25	   Drafts.

27	   Internet-Drafts are draft documents valid for a maximum of six months
28	   and may be updated, replaced, or obsoleted by other documents at any
29	   time.  It is inappropriate to use Internet-Drafts as reference
30	   material or to cite them other than as "work in progress."

32	   The list of current Internet-Drafts can be accessed at
33	   http://www.ietf.org/ietf/1id-abstracts.txt.

35	   The list of Internet-Draft Shadow Directories can be accessed at
36	   http://www.ietf.org/shadow.html.

38	   This Internet-Draft will expire on April 2, 2006.

40	Copyright Notice

42	   Copyright (C) The Internet Society (2005).

44	Abstract

46	   This document contains a "roadmap" to the Requests for Comments (RFC)
47	   documents relating to the Internet's Transmission Control Protocol
48	   (TCP).  This roadmap provides a brief summary of the documents
49	   defining TCP and various TCP extensions that have accumulated in the
50	   RFC series.  This serves as a guide and quick reference for both TCP
51	   implementers and other parties who desire information contained in
52	   the TCP-related RFCs.

54	Table of Contents

56	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
57	   2.   Basic Functionality  . . . . . . . . . . . . . . . . . . . .   5
58	   3.   Recommended Enhancements . . . . . . . . . . . . . . . . . .   8
59	     3.1  Congestion Control and Loss Recovery Extensions  . . . . .   9
60	     3.2  SACK-based Loss Recovery and Congestion Control  . . . . .  10
61	     3.3  Dealing with Forged Segments . . . . . . . . . . . . . . .  11
62	   4.   Experimental Extensions  . . . . . . . . . . . . . . . . . .  13
63	   5.   Historic Extensions  . . . . . . . . . . . . . . . . . . . .  17
64	   6.   Support Documents  . . . . . . . . . . . . . . . . . . . . .  19
65	     6.1  Foundational Works . . . . . . . . . . . . . . . . . . . .  19
66	     6.2  Difficult Network Environments . . . . . . . . . . . . . .  21
67	     6.3  Implementation Advice  . . . . . . . . . . . . . . . . . .  23
68	     6.4  Management Information Bases . . . . . . . . . . . . . . .  24
69	     6.5  Tools and Tutorials  . . . . . . . . . . . . . . . . . . .  26
70	     6.6  Case Studies . . . . . . . . . . . . . . . . . . . . . . .  26
71	   7.   Undocumented TCP Features  . . . . . . . . . . . . . . . . .  28
72	   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  30
73	   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  31
74	   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  32
75	   11.  Informative References . . . . . . . . . . . . . . . . . . .  33
76	     11.1   Basic Functionality  . . . . . . . . . . . . . . . . . .  33
77	     11.2   Recommended Enhancements . . . . . . . . . . . . . . . .  33
78	     11.3   Experimental Extensions  . . . . . . . . . . . . . . . .  34
79	     11.4   Historic Extensions  . . . . . . . . . . . . . . . . . .  35
80	     11.5   Support Documents  . . . . . . . . . . . . . . . . . . .  36
81	     11.6   Informative References Outside the RFC Series  . . . . .  38
82	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  39
83	        Intellectual Property and Copyright Statements . . . . . . .  41

85	1.  Introduction

87	   A correct and efficient implementation of the Transmission Control
88	   Protocol (TCP) is a critical part of the software of most Internet
89	   hosts.  As TCP has evolved over the years, many distinct documents
90	   have become part of the accepted standard for TCP.  At the same time,
91	   a large number of more experimental modifications to TCP have also
92	   been published in the RFC series, along with informational notes,
93	   case studies, and other advice.

95	   As an introduction to newcomers and an attempt to organize the
96	   plethora of information for old hands, this document contains a
97	   "roadmap" to the TCP-related RFCs.  It provides a brief summary of
98	   the RFC documents that define TCP.  This should provide guidance to
99	   implementers on the relevance and significance of the standards track
100	   extensions, informational notes, and best current practices that
101	   relate to TCP.

103	   This document is not an update of RFC 1122, and is not a rigorous
104	   standard for what needs to be implemented in TCP.  This document is
105	   merely an informational roadmap that captures, organizes, and
106	   summarizes most of the RFC documents that a TCP implementer,
107	   experimenter, or student should be aware of.  Particular comments or
108	   broad categorizations that this document makes about individual
109	   mechanisms and behaviors are not to be taken as definitive, nor
110	   should the content of this document alone influence implementation
111	   decisions.

113	   This roadmap includes a brief description of the contents of each
114	   TCP-related RFC.  In some cases, we simply supply the abstract or a
115	   key summary sentence from the text as a terse description.  In
116	   addition, a letter code after an RFC number indicates its category in
117	   the RFC series (see BCP 9 [RFC2026] for explanation of these
118	   categories):

120	      S - Standards Track (Proposed Standard, Draft Standard, or
121	      Standard)

123	      E - Experimental

125	      B - Best Current Practice

127	      I - Informational

129	   Note that the category of an RFC does not necessarily reflect its
130	   current relevance.  For instance, RFC 2581 is nearly universally
131	   deployed although it is only a Proposed Standard.  Similarly, some
132	   Informational RFCs contain significant technical proposals for
133	   changing TCP.

135	   This roadmap is divided into four main sections.  Section 2 lists the
136	   RFCs that describe absolutely required TCP behaviors for proper
137	   functioning and interoperability.  Further RFCs that describe
138	   strongly encouraged, but not essential, behaviors are listed in
139	   Section 3.  Experimental extensions that are not yet standard
140	   practices, but potentially could be in the future, are described in
141	   Section 4.

143	   The reader will probably notice that these three sections are broadly
144	   equivalent to MUST/SHOULD/MAY specifications (per RFC 2119), and
145	   while the authors support this intuition, this document is merely
146	   descriptive; it does not represent a binding standards track
147	   position.  An individual implementer still needs to examine the
148	   standards documents themselves to evaluate specific requirement
149	   levels.

151	   A small number of older experimental extensions that have not been
152	   widely implemented, deployed, and used are noted in Section 5.  Many
153	   other supporting documents that are relevant to the development,
154	   implementation, and deployment of TCP are described in Section 6.
155	   Within each section, RFCs are listed in the chronological order of
156	   their publication dates.

158	   A small number of fairly ubiquitous important implementation
159	   practices that are not currently documented in the RFC series are
160	   listed in Section 7.

162	2.  Basic Functionality

164	   A small number of documents compose the core specification of TCP.
165	   These define the required basic functionalities of TCP's header
166	   parsing, state machine, congestion control, and retransmission
167	   timeout computation.  These base specifications must be correctly
168	   followed for interoperability.

170	   RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981)

172	      This is the fundamental TCP specification document [RFC0793].
173	      Written by Jon Postel as part of the Internet protocol suite's
174	      core, it describes the TCP packet format, the TCP state machine
175	      and event processing, and TCP's semantics for data transmission,
176	      reliability, flow control, multiplexing, and acknowledgement.

178	      Section 3.6 of RFC 793, describing TCP's handling of the IP
179	      precedence and security compartment, is mostly irrelevant today.
180	      RFC 2873 changed the IP precedence handling, and the security
181	      compartment portion of the API is no longer implemented or used.
182	      In addition, RFC 793 did not describe any congestion control
183	      mechanism.  Otherwise, however, the majority of this document
184	      still acurately describes modern TCPs.  RFC 793 is the last of a
185	      series of developmental TCP specifications, starting in the
186	      Internet Experimental Notes (IENs) and continuing in the RFC
187	      series.

189	   RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
190	   (October 1989)

192	      This document [RFC1122] updates and clarifies RFC 793, fixing some
193	      specification bugs and oversights.  It also explains some features
194	      such as keep-alives and Karn's and Jacobson's RTO estimation
195	      algorithms [KP87][Jac88][JK92].  ICMP interactions are mentioned
196	      and some tips are given for efficient implementation.  RFC 1122 is
197	      an Applicability Statement, listing the various features that
198	      MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be present in
199	      standards-conforming TCP implementations.  Unlike a purely
200	      informational "roadmap", this Applicability Statement is a
201	      standards document, and gives formal rules for implementation.

203	   RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
204	   (December 1998)

206	      This document [RFC2460] is of relevance to TCP because it defines
207	      how the pseudo-header for TCP's checksum computation is derived,
208	      when 128-bit IPv6 addresses are used instead of 32-bit IPv4
209	      addresses.  Additionally, RFC 2675 describes TCP changes required
210	      to support IPv6 jumbograms.

212	   RFC 2581 S: "TCP Congestion Control" (April 1999)

214	      Although RFC 793 did not contain any congestion control
215	      mechanisms, today congestion control is a required component of
216	      TCP implementations.  This document [RFC2581] defines the current
217	      versions of Van Jacobson's congestion avoidance and control
218	      mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88].  RFC
219	      2001 was a conceptual precursor that was obsoleted by RFC 2581.

221	      A number of behaviors that together comprise what the community
222	      refers to as "Reno TCP", are described in RFC 2581.  The name
223	      "Reno" comes from the Net/2 release of the 4.3 BSD operating
224	      system.  This is generally regarded as the least common
225	      denominator among TCP flavors currently found running on Internet
226	      hosts.  Reno TCP includes the congestion control features of slow
227	      start, congestion avoidance, fast retransmit, and fast recovery.

229	      RFC 1122 mandates the implementation of a congestion control
230	      mechanism, and RFC 2581 details the currently accepted mechanism.
231	      RFC 2581 differs slightly from the other documents listed in this
232	      section, as it does not affect the ability of two TCP endpoints to
233	      communicate; however, congestion control remains a critical
234	      component of any widely-deployed TCP implementation and is
235	      required for the avoidance of congestion collapse and to ensure
236	      fairness among competing flows.

238	   RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (June
239	   2000)

241	      This document [RFC2873] removes from the TCP specification all
242	      processing of the precedence bits of the TOS byte of the IP
243	      header.  This resolves a conflict over the use of these bits
244	      between RFC 793 and Differentiated Services [RFC2474].

246	   RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)

248	      Abstract: "This document defines the standard algorithm that
249	      Transmission Control Protocol (TCP) senders are required to use to
250	      compute and manage their retransmission timer.  It expands on the
251	      discussion in section 4.2.3.1 of RFC 1122 and upgrades the
252	      requirement of supporting the algorithm from a SHOULD to a MUST."
253	      [RFC2988]

255	3.  Recommended Enhancements

257	   This section describes recommended TCP modifications that improve
258	   performance and security.  RFCs 1323 and 3168 represent fundamental
259	   changes to the protocol.  RFC 1323, based on RFCs 1072 and 1185,
260	   allows better utilization of high bandwidth-delay product paths by
261	   providing some needed mechanisms for high-rate transfers.  RFC 3168
262	   describes a change to the Internet's architecture, where routers
263	   signal end-hosts of growing congestion levels, and can do so before
264	   packet losses are forced.  Section 3.1 lists improvements in the
265	   congestion control and loss recovery mechanisms specified in RFC
266	   2581.  Section 3.2 describes further refinements that make use of
267	   selective acknowledgements.  Section 3.3 deals with the problem of
268	   preventing forged segments.

270	   RFC 1323 S:  "TCP Extensions for High Performance" (May 1992)

272	      This document [RFC1323] defines TCP extensions for window scaling,
273	      timestamps, and protection against wrapped sequence numbers, for
274	      efficient and safe operation over paths with large bandwidth-delay
275	      products.  These extensions are commonly found in currently-used
276	      systems; however, they may require manual tuning and
277	      configuration.  One issue in this specification that is still
278	      under discussion concerns a modification to the algorithm for
279	      estimating the mean RTT when timestamps are used.

281	   RFC 2675 S: "IPv6 Jumbograms" (August 1999)

283	      IPv6 supports longer datagrams than were allowed in IPv4.  These
284	      are known as Jumbograms, and use with TCP has necessitated changes
285	      to the handling of TCP's MSS and Urgent fields (both 16 bits).
286	      This document [RFC2675] explains those changes.  While it
287	      describes changes to basic header semantics, these changes should
288	      only affect the use of very large segments, such as IPv6
289	      jumbograms, which are currently rarely used in the general
290	      Internet.  Supporting the behavior described in this document does
291	      not affect interoperability with other TCP implementations when
292	      using IPv4 or non-jumbogram IPv6.  This document states that
293	      jumbograms are to only be used when it can be guaranteed that all
294	      receiving nodes, including each router in the end-to-end path,
295	      will support jumbograms.  If even a single node that that does not
296	      support jumbograms is attached to a local network, then no host on
297	      that network may use jumbograms.  This explains why jumbogram use
298	      has been rare, and why this document is considered a performance
299	      optimzation rather than part of TCP over IPv6's basic
300	      functionality.

302	   RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
303	   to IP" (September 2001)

305	      This document [RFC3168] defines a means for end hosts to detect
306	      congestion before congested routers are forced to discard packets.
307	      Although congestion notification takes place at the IP level, ECN
308	      requires support at the transport level (e.g., in TCP) to echo the
309	      bits and adapt the sending rate.  This document updates RFC 793 to
310	      define two previously-unused flag bits in the TCP header for ECN
311	      support.  RFC 3540 provides a supplementary (experimental) means
312	      for more secure use of ECN, and RFC 2884 provides some sample
313	      results from using ECN.

315	3.1  Congestion Control and Loss Recovery Extensions

317	   Two of the most important aspects of TCP are its congestion control
318	   and loss recovery features.  Since TCP traditionally (in the absence
319	   of ECN) uses losses to infer congestion, there is a rather intimate
320	   coupling between congestion control and loss recovery mechanisms.
321	   There are several extensions to both features, and more often than
322	   not, a particular extension applies to both.  In this sub-section, we
323	   group enhancements to either congestion control, loss recovery, or
324	   both, which can be performed unilaterally - without negotiating
325	   support between endpoints.  In the next sub-section, we group the
326	   extensions which specify or rely on the SACK option, which must be
327	   negotiated bilaterally.  TCP implementations should include the
328	   enhancements from both sub-sections so that TCP senders can perform
329	   well without regard to the feature sets of other hosts they connect
330	   to.  For example, if SACK use is not successfully negotiated, a host
331	   should use the NewReno behavior as a fall-back.

333	   RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
334	   (January 2001)

336	      Abstract: "This document proposes Limited Transmit, a new
337	      Transmission Control Protocol (TCP) mechanism that can be used to
338	      more effectively recover lost segments when a connection's
339	      congestion window is small, or when a large number of segments are
340	      lost in a single transmission window."  [RFC3042]
341	      Tests from 2004 showed that Limited Transmit was deployed in
342	      roughly one third of the web servers tested [MAF04].

344	   RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)

346	      This document [RFC3390] updates RFC 2581 to permit an initial TCP
347	      window of three or four segments during the slow-start phase,
348	      depending on the segment size.

350	   RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
351	   Algorithm" (April 2004)

353	      This document [RFC3782] specifies a modification to the standard
354	      Reno fast recovery algorithm, whereby a TCP sender can use partial
355	      acknowledgements to make inferences determining the next segment
356	      to send in situations where SACK would be helpful, but isn't
357	      available.  While it is only a slight modification, the NewReno
358	      behavior can make a significant difference in performance when
359	      multiple segments are lost from a single window of data.

361	3.2  SACK-based Loss Recovery and Congestion Control

363	   The base TCP specification in RFC 793 provided only a simple
364	   cumulative acknowledgment mechanism.  However, a selective
365	   acknowledgment (SACK) mechanism provides performance improvement in
366	   the presence of multiple packet losses from the same flight, more
367	   than outweighing the modest increase in complexity.  A TCP should be
368	   expected to implement SACK, however SACK is a negotiated option and
369	   is only used if support is advertised by both sides of a connection.

371	   RFC 2018 S: "TCP Selective Acknowledgement Options" (October 1996)

373	      This document [RFC2018] defines the basic selective
374	      acknowledgement (SACK) mechanism for TCP.

376	   RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
377	   Option for TCP" (July 2000)

379	      This document [RFC2883] extends RFC 2018 to cover the case of
380	      acknowledging duplicate segments.

382	   RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based
383	   Loss Recovery Algorithm for TCP" (April 2003)

385	      This document [RFC3517] describes a relatively sophisticated
386	      algorithm that a TCP sender can use for loss recovery when SACK
387	      reports more than one segment lost from a single flight of data.
388	      While support for the exchange of SACK information is widely
389	      implemented, not all implementations use an algorithm as
390	      sophisticated as that described in RFC 3517.

392	3.3  Dealing with Forged Segments

394	   By default, TCP lacks any cryptographic structures to differentiate
395	   legitimate segments and those spoofed from malicious hosts.  Spoofing
396	   valid segments requires correctly guessing a number of fields.  The
397	   documents in this sub-section describe ways to make that guessing
398	   harder, or prevent it from being able to negatively impact a
399	   connection.

401	   The TCPM working group is currently in progress towards fully
402	   understanding and defining mechanisms for preventing spoofing attacks
403	   (including both spoofed TCP segments and ICMP datagrams).  Some of
404	   the solutions being considered rely on TCP modifications, while
405	   others rely on security at lower layers (like IPsec) for protection.

407	   RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)

409	      This document [RFC1948] describes the TCP vulnerability that
410	      allows an attacker to send forged TCP packets, based upon guessing
411	      the initial sequence number in the three-way handshake.  Simple
412	      defenses against exploitation are then described.  Some variation
413	      is implemented in most currently-used operating systems.

415	   RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
416	   Option" (August 1998)

418	      From document: "This document describes currrent existing practice
419	      for securing BGP against certain simple attacks.  It is understood
420	      to have security weaknesses against concerted attacks.

422	      This memo describes a TCP extension to enhance security for BGP.
423	      It defines a new TCP option for carrying an MD5 [RFC1321] digest
424	      in a TCP segment.  This digest acts like a signature for that
425	      segment, incorporating information known only to the connection
426	      end points.  Since BGP uses TCP as its transport, using this
427	      option in the way described in this paper significantly reduces
428	      the danger from certain security attacks on BGP."  [RFC2385]

430	      TCP MD5 options are currently only used in very limited contexts,
431	      primarily for defending BGP exchanges between routers.  Some
432	      deployment notes for those using TCP MD5 are found in the later
433	      RFC 3562, "Key Management Considerations for the TCP MD5 Signature
434	      Option" [RFC3562].  A draft that is currently in the RFC Editor's
435	      queue for publication [tcpmd5app] deprecates TCP MD5 for use
436	      outside BGP.

438	4.  Experimental Extensions

440	   The RFCs in this section are still experimental, but may become
441	   proposed standards in the future.  At least part of the reason that
442	   they are still experimental is to gain more wide-scale experience
443	   with them before making a standards track decision.  By their
444	   publication as experimental RFCs, it is hoped that the community of
445	   TCP researchers will analyze and test the contents of these RFCs.
446	   Although encouraged for experimentation, there is not yet formal
447	   consensus that these are fully logical and safe behaviors.  Wide-
448	   scale deployment of implementations that use these features should be
449	   well thought-out in terms of consequences.

451	   RFC 2140 I: "TCP Control Block Interdependence" (April 1997)

453	      This document [RFC2140] suggests how TCP connections between the
454	      same endpoints might share information, such as their congestion
455	      control state.  To some degree, this is done in practice by a few
456	      operating systems; for example, Linux currently has a destination
457	      cache.  Although this RFC is technically informational, the
458	      concepts it describes are in experimental use, so we include it in
459	      this section.

461	      A related proposal, the Congestion Manager, is specified in RFC
462	      3124 [RFC3124].  The idea behind the Congestion Manager, moving
463	      congestion control outside of individual TCP connections,
464	      represents a modification to the core of TCP, which supports
465	      sharing information among TCP connections as well.  Although a
466	      Proposed Standard, some pieces of the Congestion Manager support
467	      architecture have not been specified yet, and it has not achieved
468	      use or implementation beyond experimental stacks, so it is not
469	      listed among the standard TCP enhancements in this roadmap.

471	   RFC 2861 E: "TCP Congestion Window Validation" (June 2000)

473	      This document [RFC2861] suggests reducing the congestion window
474	      over time when no packets are flowing.  This behavior is more
475	      aggressive than that specified in RFC 2581, which says that a TCP
476	      sender SHOULD set its congestion window to the initial window
477	      after an idle period of an RTO or greater.

479	   RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
480	   (ABC)" (February 2003)

482	      This document [RFC3465] suggests that congestion control use the
483	      number of bytes acknowledged rather than the number of
484	      acknowledgements received.  This has been implemented in Linux.
485	      The ABC mechanism behaves differently than the standard method
486	      when there is not a one-to-one relationship between data segments
487	      and acknowledgements.  ABC still operates within the accepted
488	      guidelines, but is more robust to delayed ACKs and ACK-division
489	      [SCWA99][RFC3449].

491	   RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003)

493	      This document [RFC3522] suggests using timestamps to detect
494	      spurious timeouts.

496	   RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
497	   with Nonces" (June 2003)

499	      This document [RFC3540] suggests a modified ECN to address
500	      security concerns, and updates RFC 3168.

502	   RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December
503	   2003)

505	      This document [RFC3649] suggests a modification to TCP's steady-
506	      state behavior to efficiently use very large windows.

508	   RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs)
509	   and Stream Control Transmission Protocol (SCTP) Duplicate
510	   Transmission Sequence Numbers (TSNs) to Detect Spurious
511	   Retransmissions" (February 2004)

513	      Abstract: "TCP and Stream Control Transmission Protocol (SCTP)
514	      provide notification of duplicate segment receipt through
515	      Duplicate Selective Acknowledgement (DSACKs) and Duplicate
516	      Transmission Sequence Number (TSN) notification, respectively.
517	      This document presents conservative methods of using this
518	      information to identify unnecessary retransmissions for various
519	      applications."  [RFC3708]

521	   RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion
522	   Windows" (March 2004)

524	      This document [RFC3742] describes a more conservative slow-start
525	      behavior to prevent massive packet losses when a connection uses a
526	      very large window.

528	   RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)

530	      This document [RFC4015] describes the response portion of the
531	      Eifel algorithm, which can be used in conjunction with one of
532	      several methods of detecting when loss recovery has been
533	      spuriously entered, such as the Eifel detection algorithm in RFC
534	      3522, the algorithm in RFC 3708, or F-RTO in RFC 4138.

536	      Abstract: "Based on an appropriate detection algorithm, the Eifel
537	      response algorithm provides a way for a TCP sender to respond to a
538	      detected spurious timeout.  It adapts the retransmission timer to
539	      avoid further spurious timeouts, and can avoid - depending on the
540	      detection algorithm - the often unnecessary go-back-N retransmits
541	      that would otherwise be sent.  In addition, the Eifel response
542	      algorithm restores the congestion control state in such a way that
543	      packet bursts are avoided."

545	      RFC 4015 is itself a Proposed Standard.  The consensus of the TCPM
546	      working group was to place it in this section of the roadmap
547	      document due to three factors.

549	      1.  RFC 4015 operates on the output of a detection algorithm, for
550	          which there is currently no available mechanism on the
551	          standards track.

553	      2.  The working group was not aware of any wide deployment and use
554	          of RFC 4015.

556	      3.  The concensus of the working group, after a discussion of the
557	          known Intellectual Property Rights claims on the techniques
558	          described in RFC 4015, identified this section of the roadmap
559	          as an appropriate location.

561	   RFC 4138 E: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
562	   Spurious Retransmission Timeouts with TCP and the Stream Control
563	   Transmission Protocol" (August 2005)

565	      The F-RTO detection algorithm [RFC4138] provides another option
566	      for inferring spurious retransmission timeouts.  Unlike some
567	      similar detection methods, F-RTO does not rely on the use of any
568	      TCP options.

570	5.  Historic Extensions

572	   The RFCs listed here define extensions that have thus far failed to
573	   arouse substantial interest from implementers, or were found to be
574	   defective for general use.

576	   RFC 1106 "TCP Big Window and NAK Options" (June 1989) - found
577	   defective

579	      This RFC [RFC1106] defined an alternative to the Window Scale
580	      option for using large windows, and described the "negative
581	      acknowledgement" or NAK option.  There is a comparison of NAK and
582	      SACK methods, and early discussion of TCP over satellite issues.
583	      RFC 1110 explains some problems with the approaches described in
584	      RFC 1106.  The options described in this document have not been
585	      adopted by the larger community, although NAKs are used in the
586	      SCPS-TP adaptation of TCP for satellite and spacecraft use,
587	      developed by the Consultive Committee for Space Data Systems
588	      (CCSDS) .

590	   RFC 1110 "A Problem with the TCP Big Window Option" (August 1989) -
591	   deprecates RFC 1106

593	      Abstract: "The TCP Big Window option discussed in RFC 1106 will
594	      not work properly in an Internet environment which has both a high
595	      bandwidth * delay product and the possibility of disordering and
596	      duplicating packets.  In such networks, the window size must not
597	      be increased without a similar increase in the sequence number
598	      space.  Therefore, a different approach to big windows should be
599	      taken in the Internet."  [RFC1110]

601	   RFC 1146 E "TCP Alternate Checksum Options" (March 1990) - lacked
602	   interest

604	      This document [RFC1146] defined more robust TCP checksums than the
605	      16-bit ones-complement in use today.  A typographical error in RFC
606	      1145 is fixed in RFC 1146, otherwise the documents are the same.

608	   RFC 1263 "TCP Extensions Considered Harmful" (October 1991) - lacked
609	   interest

611	      This document [RFC1263] argues against "backwards compatible" TCP
612	      extensions.  Specifically mentioned are several TCP enhancements
613	      that have been successful, including timestamps, window scaling,
614	      PAWS, and SACK.  RFC 1263 presents an alternative approach called
615	      "protocol evolution", whereby several evolutionary versions of TCP
616	      would exist on hosts.  These distinct TCP versions would represent
617	      upgrades to each other and could be header-incompatible.
618	      Interoperability would be provided by having a virtualization
619	      layer select the right TCP version for a particular connection.
620	      This idea did not catch on with the community, while the type of
621	      extensions RFC 1263 specifically targeted as harmful did become
622	      popular.

624	   RFC 1379 I "Extending TCP for Transactions -- Concepts" (November
625	   1992) - found defective

627	      See RFC 1644.

629	   RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional
630	   Specification" (July 1994) - found defective

632	      The inventors of TCP believed that cached connection state could
633	      have been used to eliminate TCP's 3-way handshake, to support two-
634	      packet request/response exchanges.  RFCs 1379 [RFC1379] and 1644
635	      [RFC1644] show that this is far from simple.  Furthermore, T/TCP
636	      floundered on the ease of denial-of-service attacks that can
637	      result.  One idea pioneered by T/TCP lives on in RFC 2140, in the
638	      sharing of state across connections.

640	   RFC 1693 E "An Extension to TCP: Partial Order Service" (November
641	   1994) - lacked interest

643	      This document [RFC1693] defines a TCP extension for applications
644	      that do not care about the order in which application-layer
645	      objects are received.  Examples are multimedia and database
646	      applications.  In practice, these applications either accept the
647	      possible performance loss because of TCP's strict ordering, or
648	      they use more specialized transport protocols.

650	6.  Support Documents

652	   This section contains several classes of documents that do not
653	   necessarily define current protocol behaviors, but are nevertheless
654	   of interest to TCP implementers.  Section 6.1 describes several
655	   foundational RFCs that give modern readers a better understanding of
656	   the principles underlying TCP's behaviors and development over the
657	   years.  The documents listed in Section 6.2 provide advice on using
658	   TCP in various types of network situations that pose challenges above
659	   those of typical wired links.  Some implementation notes can be found
660	   in Section 6.3.  The TCP Management Information Bases are described
661	   in Section 6.4.  RFCs that describe tools for testing and debugging
662	   TCP implementations or contain high-level tutorials on the protocol
663	   are listed Section 6.5, while Section 6.6 lists a number of case
664	   studies that have explored TCP performance.

666	6.1  Foundational Works

668	   The documents listed in this section contain information that is
669	   largely duplicated by the standards documents previously discussed.
670	   However, some of them contain a greater depth of problem statement
671	   explanation or other context.  Particularly, RFCs 813-817 (known as
672	   the "Dave Clark Five"), describe some early problems and solutions
673	   (RFC 815 only describes the reassembly of IP fragments, and is not
674	   included in this TCP roadmap).

676	   RFC 813: "Window and Acknowledgement Strategy in TCP" (July 1982)

678	      This document [RFC0813] contains an early discussion of Silly
679	      Window Syndrome and its avoidance, and motivates and describes the
680	      use of delayed acknowledgements.

682	   RFC 814: "Name, Addresses, Ports, and Routes" (July 1982)

684	      Suggestions and guidance for the design of tables and algorithms
685	      to keep track of various identifiers within a TCP/IP
686	      implementation are provided by this document [RFC0814].

688	   RFC 816: "Fault Isolation and Recovery" (July 1982)

690	      In this document [RFC0816], TCP's response to indications of
691	      network error conditions such as timeouts or received ICMP
692	      messages is discussed.

694	   RFC 817: "Modularity and Efficiency in Protocol Implementation" (July
695	   1982)

697	      This document [RFC0817] contains implementation suggestions that
698	      are general and not TCP-specific.  However, they have been used to
699	      develop TCP implementations and describe some performance
700	      implications of the interactions between various layers in the
701	      Internet stack.

703	   RFC 872: "TCP-ON-A-LAN" (September 1982)

705	      Conclusion: "The sometimes-expressed fear that using TCP on a
706	      local net is a bad idea is unfounded."  [RFC0872]

708	   RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)

710	      This document  [RFC0896] contains some early experiences with
711	      congestion collapse and some initial thoughts on how to avoid it
712	      using congestion control in TCP.

714	   RFC 964: "Some Problems with the Specification of the Military
715	   Standard Transmission Control Protocol" (November 1985)

717	      This document [RFC0964] points out several specification bugs in
718	      the US Military's MIL-STD-1778 document, which was intended as a
719	      successor to RFC 793.  This serves to remind us of the difficulty
720	      in specification writing (even when working from existing
721	      documents!).

723	   RFC 1072: "TCP Extensions for Long-Delay Paths" (October 1988)

725	      This document [RFC1072] contains early explanations of the
726	      mechanisms that were later described by RFCs 1323 and 2018, which
727	      obsolete it.

729	   RFC 1185: "TCP Extension for High-Speed Paths" (October 1990)

731	      This document [RFC1185] builds on RFC 1072 to describe more
732	      advanced strategies for dealing with sequence number wrapping and
733	      detecting duplicates from earlier connections.  This document was
734	      obsoleted by RFC 1323.

736	   RFC 2914 B: "Congestion Control Principles" (September 2000)

738	      This document [RFC2914] motivates the use of end-to-end congestion
739	      control for preventing congestion collapse and providing fairness
740	      to TCP.

742	6.2  Difficult Network Environments

744	   As the internetworking field has explored wireless, satellite,
745	   cellular telephone, and other kinds of link-layer technologies, a
746	   large body of work has built up on enhancing TCP performance for such
747	   links.  The RFCs listed in this section describe some of these more
748	   challenging network environments and how TCP interacts with them.

750	   RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard
751	   Mechanisms" (January 1999)

753	      From abstract: "While TCP works over satellite channels there are
754	      several IETF standardized mechanisms that enable TCP to more
755	      effectively utilize the available capacity of the network path.
756	      This document outlines some of these TCP mitigations.  At this
757	      time, all mitigations discussed in this document are IETF
758	      standards track mechanisms (or are compliant with IETF
759	      standards)."  [RFC2488]

761	   RFC 2757 I: "Long Thin Networks" (January 2000)

763	      Several methods of improving TCP performance over long thin
764	      networks, such as geosynchronous satellite links, are discussed in
765	      this document [RFC2757].  A particular set of TCP options is
766	      developed that should work well in such environments, and be safe
767	      to use in the global Internet.

769	   RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February
770	   2000)

772	      This document [RFC2760] discusses the advantages and disadvantages
773	      of several different experimental means of improving TCP
774	      performance over long-delay or error-prone paths.  These include:
775	      T/TCP, larger initial windows, byte counting, delayed
776	      acknowledgements, slow start thresholds, NewReno and SACK-based
777	      loss recovery, FACK [MM96], ECN, various corruption-detection
778	      mechanisms, congestion avoidance changes for fairness, use of
779	      multiple parallel flows, pacing, header compression, state
780	      sharing, and ACK congestion control, filtering, and
781	      reconstruction.  While RFC 2488 looks at standard extensions, this
782	      document focuses on more experimental means of performance
783	      enhancement.

785	   RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate Link-
786	   Related Degradations" (June 2001)

788	      From abstract: "This document is a survey of Performance Enhancing
789	      Proxies (PEPs) often employed to improve degraded TCP performance
790	      caused by characteristics of specific link environments, for
791	      example, in satellite, wireless WAN, and wireless LAN
792	      environments.  Different types of Performance Enhancing Proxies
793	      are described as well as the mechanisms used to improve
794	      performance."  [RFC3135]

796	   RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry"
797	   (December 2002)

799	      From abstract: "This document describes TCP performance problems
800	      that arise because of asymmetric effects.  These problems arise in
801	      several access networks, including bandwidth-asymmetric networks
802	      and packet radio subnetworks, for different underlying reasons.
803	      However, the end result on TCP performance is the same in both
804	      cases: performance often degrades significantly because of
805	      imperfection and variability in the ACK feedback from the receiver
806	      to the sender.

808	      The document details several mitigations to these effects, which
809	      have either been proposed or evaluated in the literature, or are
810	      currently deployed in networks."  [RFC3449]

812	   RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation
813	   Wireless Networks" (February 2003)

815	      From abstract: "This document describes a profile for optimizing
816	      TCP to adapt so that it handles paths including second (2.5G) and
817	      third (3G) generation wireless networks."  [RFC3481]

819	   RFC 3819 B: "Advice for Internet Subnetwork Designers" (July 2004)

821	      This document [RFC3819] describes how TCP performance can be
822	      negatively impacted by some particular lower-layer behaviors, and
823	      provides guidance in designing lower-layer networks and protocols
824	      to be amicable to TCP.

826	6.3  Implementation Advice

828	   RFC 879: "The TCP Maximum Segment Size and Related Topics" (November
829	   1983)

831	      Abstract: 'This memo discusses the TCP Maximum Segment Size Option
832	      and related topics.  The purposes is to clarify some aspects of
833	      TCP and its interaction with IP.  This memo is a clarification to
834	      the TCP specification, and contains information that may be
835	      considered as "advice to implementers".'  [RFC0879]

837	   RFC 1071: "Computing the Internet Checksum" (September 1988)

839	      This document [RFC1071] lists a number of implementation
840	      techniques for efficiently computing the Internet checksum (used
841	      by TCP).

843	   RFC 1624 I: "Computation of the Internet Checksum via Incremental
844	   Update" (May 1994)

846	      Incrementally updating the Internet checksum is useful to routers
847	      in updating IP checksums.  Some middleboxes that alter TCP headers
848	      may also be able to incrementally update the TCP checksum.  This
849	      document [RFC1624] expands upon the explanation of the incremental
850	      update proceedure in RFC 1071.

852	   RFC 1936 I: "Implementing the Internet Checksum in Hardware" (April
853	   1996)

855	      This document [RFC1936] describes the motivation for implementing
856	      the Internet checksum in hardware, rather than software, and
857	      provides an example implementation.

859	   RFC 2525 I: "Known TCP Implementation Problems" (March 1999)

861	      From abstract: "This memo catalogs a number of known TCP
862	      implementation problems.  The goal in doing so is to improve
863	      conditions in the existing Internet by enhancing the quality of
864	      current TCP/IP implementations."  [RFC2525]

866	   RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000)

868	      From abstract: "This memo catalogs several known Transmission
869	      Control Protocol (TCP) implementation problems dealing with Path
870	      Maximum Transmission Unit Discovery (PMTUD), including the long-
871	      standing black hole problem, stretch acknowlegements (ACKs) due to
872	      confusion between Maximum Segment Size (MSS) and segment size, and
873	      MSS advertisement based on PMTU."  [RFC2923]

875	   RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August
876	   2002)

878	      This document [RFC3360] is a plea that firewall vendors not send
879	      gratuitous TCP RST (Reset) packets when unassigned TCP header bits
880	      are used.  This practice prevents desirable extension and
881	      evolution of the protocol and hence is potentially harmful to the
882	      future of the Internet.

884	   RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February
885	   2003)

887	      This document [RFC3493] describes the de facto standard sockets
888	      API for programming with TCP.  This API is implemented nearly
889	      ubiquitously in modern operating systems and programming
890	      languages.

892	6.4  Management Information Bases

894	   The first MIB module defined for use with SNMP (in RFC 1066 and its
895	   update, RFC 1156) was a single monolithic MIB module, called MIB-I.
896	   This evolved over time to be MIB-II (RFC 1213).  It then became
897	   apparent that having a single monolithic MIB module was not scalable,
898	   given the number and breadth of MIB data definitions that needed to
899	   be included.  Thus, additional MIB modules were defined, and those
900	   parts of MIB-II which needed to evolve were split off.  Eventually,
901	   the remaining parts of MIB-II were also split off, with the TCP-
902	   specific part being documented in RFC 2012.

904	   RFC 2012 was obsoleted by RFC 4022, which is the primary TCP MIB
905	   document today.  MIB-I, defined in RFC 1156, has been obsoleted by
906	   the MIB-II specification in RFC 1213.  For current TCP implementers,
907	   RFC 4022 should be supported.

909	   RFC 1066: "Management Information Base for Network Management of TCP/
910	   IP-based Internets" (August 1988)

912	      This document [RFC1066] was the description of the TCP MIB.  It
913	      was obsoleted by RFC 1156.

915	   RFC 1156 S: "Management Information Base for Network Management of
916	   TCP/IP-based Internets" (May 1990)

918	      This document [RFC1156] describes the required MIB fields for TCP
919	      implementations, with minor corrections and no technical changes
920	      from RFC 1066, which it obsoletes.  This is the standards track
921	      document for MIB-I.

923	   RFC 1213 S: "Management Information Base for Network Management of
924	   TCP/IP-based Internets: MIB-II" (March 1991)

926	      This document [RFC1213] describes the second version of the MIB in
927	      a monolithic form.  RFC 2012 updates this document by splitting
928	      out the TCP-specific portions.

930	   RFC 2012 S: "SNMPv2 Management Information Base for the  Transmission
931	   Control Protocol using SMIv2" (November 1996)
932	      This document [RFC2012] defined the TCP MIB, in an update to RFC
933	      1213.  It is now obsoleted by RFC 4022.

935	   RFC 2452 S: "IP Version 6 Management Information Base for the
936	   Transmission Control Protocol" (December 1998)

938	      This document [RFC2452] augments RFC 2012 by adding an IPv6-
939	      specific connection table.  The rest of 2012 holds for any IP
940	      version.

942	      Although it is a standards track document, RFC 2452 is considered
943	      a historic mistake by the MIB community, as it is based on the
944	      idea of parallel IPv4 and IPv6 structures.  Although IPv6 requires
945	      new structures, the community has decided to define a single
946	      generic structure for both IPv4 and IPv6.  This will aid in
947	      definition, implementation, and transition between IPv4 and IPv6.

949	   RFC 4022 S: "Management Information Base for the Transmission Control
950	   Protocol (TCP)" (March 2005)

952	      This document [RFC4022] obsoletes RFC 2012 and RFC 2452, and
953	      specifies the current standard for the TCP MIB that should be
954	      deployed.

956	6.5  Tools and Tutorials

958	   RFC 1180 I: "TCP/IP Tutorial" (January 1991)

960	      This document [RFC1180] is an extremely brief overview of the
961	      TCP/IP protocol suite as a whole.  It gives some explanation as to
962	      how and where TCP fits in.

964	   RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
965	   Monitoring and Debugging TCP/IP Internets and Interconnected Devices"
966	   (June 1993)

968	      A few of the tools that this document [RFC1470] describes are
969	      still maintained and in use today, for example ttcp and tcpdump.
970	      However, many of the tools described do not relate specifically to
971	      TCP and are no longer used or easily available.

973	   RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998)

975	      This document  [RFC2398] describes a number of TCP packet
976	      generation and analysis tools.  While some of these tools are no
977	      longer readily available or widely used, for the most part they
978	      are still relevant and useable.

980	6.6  Case Studies
981	   RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992)

983	      This document [RFC1337] points out a problem with acting on
984	      received reset segments while in the TIME-WAIT state.  The main
985	      recommendation is that hosts in TIME-WAIT ignore resets.  This
986	      recommendation might not currently be widely implemented.

988	   RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size"
989	   (September 1998)

991	      This document [RFC2415] presents results of some simulations using
992	      TCP initial windows greater than 1 segment.  The analysis
993	      indicates that user-perceived performance can be improved by
994	      increasing the initial window to 3 segments.

996	   RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three
997	   Buffers" (September 1998)

999	      This document [RFC2416] uses simulation results to clear up some
1000	      concerns about using an initial window of 4 segments when the
1001	      network path has less provisioning.

1003	   RFC 2884 I: "Performance Evaluation of Explicit Congestion
1004	   Notification (ECN) in IP Networks" (July 2000)

1006	      This document [RFC2884] describes experimental results that show
1007	      some improvements to the performance of both short and long-lived
1008	      connections due to ECN.

1010	7.  Undocumented TCP Features

1012	   There are a few important implementation tactics for the TCP that
1013	   have not yet been described in any RFC.  Although this roadmap is
1014	   primarily concerned with mapping the TCP RFCs, this section is
1015	   included because an implementer needs to be aware of these important
1016	   issues.

1018	   SYN Cookies

1020	      A mechanism known as "SYN cookies" is widely used to thwart TCP
1021	      SYN flooding attacks, in which an attacker sends a flood of SYNs
1022	      to a victim but fails to complete the 3-way handshake.  The result
1023	      is exhaustion of resources at the server.  The SYN cookie
1024	      mechanism allows the server to return a cleverly-chosen initial
1025	      sequence number that has all the required state for the secure
1026	      completion of the handshake.  Then the server can avoid saving
1027	      connection state during the 3-way handshake and thus survive a SYN
1028	      flooding attack.

1030	      A web search for "SYN cookies" will reveal a number of useful
1031	      descriptions of this mechanism, although there is currently no RFC
1032	      on the matter.

1034	   Header Prediction

1036	      Header prediction is a trick to speed up the processing of
1037	      segments.  Van Jacobson and Mike Karels developed the technique in
1038	      the late 1980s.  The basic idea is that some processing time can
1039	      be saved when most of a segment's fields can be predicted from
1040	      previous segments.  A good description of this was sent to the
1041	      TCP-IP mailing list by Van Jacobson on March 9, 1988:

1043	         Quite a bit of the speedup comes from an algorithm that we
1044	         ('we' refers to collaborator Mike Karels and myself) are
1045	         calling "header prediction".  The idea is that if you're in the
1046	         middle of a bulk data transfer and have just seen a packet, you
1047	         know what the next packet is going to look like:  It will look
1048	         just like the current packet with either the sequence number or
1049	         ack number updated (depending on whether you're the sender or
1050	         receiver).  Combining this with the "Use hints" epigram from
1051	         Butler Lampson's classic "Epigrams for System Designers", you
1052	         start to think of the tcp state (rcv.nxt, snd.una, etc.) as
1053	         "hints" about what the next packet should look like.

1055	         If you arrange those "hints" so they match the layout of a tcp
1056	         packet header, it takes a single 14-byte compare to see if your
1057	         prediction is correct (3 longword compares to pick up the send
1058	         & ack sequence numbers, header length, flags and window, plus a
1059	         short compare on the length).  If the prediction is correct,
1060	         there's a single test on the length to see if you're the sender
1061	         or receiver followed by the appropriate processing.  E.g., if
1062	         the length is non-zero (you're the receiver), checksum and
1063	         append the data to the socket buffer then wake any process
1064	         that's sleeping on the buffer.  Update rcv.nxt by the length of
1065	         this packet (this updates your "prediction" of the next
1066	         packet).  Check if you can handle another packet the same size
1067	         as the current one.  If not, set one of the unused flag bits in
1068	         your header prediction to guarantee that the prediction will
1069	         fail on the next packet and force you to go through full
1070	         protocol processing.  Otherwise, you're done with this packet.
1071	         So, the *total* tcp protocol processing, exclusive of
1072	         checksumming, is on the order of 6 compares and an add.

1074	8.  Security Considerations

1076	   This document introduces no new security considerations.  Each RFC
1077	   listed in this document attempts to address the security
1078	   considerations of the specification it contains.

1080	9.  IANA Considerations

1082	   This document contains no IANA considerations.

1084	10.  Acknowledgments

1086	   This document grew out of a discussion on the end2end-interest
1087	   mailing list, the public list of the End-to-End Research Group of the
1088	   IRTF, and continued development under the IETF's TCP Maintenance and
1089	   Minor Extensions (TCPM) working group.  We thank Joe Touch, Reiner
1090	   Ludwig, Pekka Savola, Gorry Fairhurst, and Sally Floyd for their
1091	   contributions, in particular.  The chairs of the TCPM working group,
1092	   Mark Allman and Ted Faber, have been instrumental in the development
1093	   of this document.  Keith McCloghrie provided some useful notes and
1094	   clarification on the various MIB-related RFCs.

1096	11.  Informative References

1098	11.1  Basic Functionality

1100	   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
1101	              RFC 793, September 1981.

1103	   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
1104	              Communication Layers", STD 3, RFC 1122, October 1989.

1106	   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
1107	              3", BCP 9, RFC 2026, October 1996.

1109	   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
1110	              (IPv6) Specification", RFC 2460, December 1998.

1112	   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
1113	              "Definition of the Differentiated Services Field (DS
1114	              Field) in the IPv4 and IPv6 Headers", RFC 2474,
1115	              December 1998.

1117	   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
1118	              Control", RFC 2581, April 1999.

1120	   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
1121	              RFC 2675, August 1999.

1123	   [RFC2873]  Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
1124	              Processing of the IPv4 Precedence Field", RFC 2873,
1125	              June 2000.

1127	   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
1128	              Timer", RFC 2988, November 2000.

1130	11.2  Recommended Enhancements

1132	   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
1133	              for High Performance", RFC 1323, May 1992.

1135	   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
1136	              RFC 1948, May 1996.

1138	   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
1139	              Selective Acknowledgment Options", RFC 2018, October 1996.

1141	   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
1142	              Signature Option", RFC 2385, August 1998.

1144	   [RFC2883]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
1145	              Extension to the Selective Acknowledgement (SACK) Option
1146	              for TCP", RFC 2883, July 2000.

1148	   [RFC3042]  Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
1149	              TCP's Loss Recovery Using Limited Transmit", RFC 3042,
1150	              January 2001.

1152	   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
1153	              of Explicit Congestion Notification (ECN) to IP",
1154	              RFC 3168, September 2001.

1156	   [RFC3390]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
1157	              Initial Window", RFC 3390, October 2002.

1159	   [RFC3517]  Blanton, E., Allman, M., Fall, K., and L. Wang, "A
1160	              Conservative Selective Acknowledgment (SACK)-based Loss
1161	              Recovery Algorithm for TCP", RFC 3517, April 2003.

1163	   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
1164	              Signature Option", RFC 3562, July 2003.

1166	   [RFC3782]  Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
1167	              Modification to TCP's Fast Recovery Algorithm", RFC 3782,
1168	              April 2004.

1170	   [RFC4015]  Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
1171	              for TCP", RFC 4015, February 2005.

1173	   [tcpmd5app]
1174	              Bellovin, S. and A. Zinin, "Standards Maturity Variance
1175	              Regarding the TCP MD5 Signature Option (RFC 2385) and the
1176	              BGP-4 Specification", (draft-iesg-tcpmd5app-01 in RFC
1177	              Editor queue), September 2004.

1179	11.3  Experimental Extensions

1181	   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
1182	              April 1997.

1184	   [RFC2861]  Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
1185	              Window Validation", RFC 2861, June 2000.

1187	   [RFC3124]  Balakrishnan, H. and S. Seshan, "The Congestion Manager",
1188	              RFC 3124, June 2001.

1190	   [RFC3465]  Allman, M., "TCP Congestion Control with Appropriate Byte
1191	              Counting (ABC)", RFC 3465, February 2003.

1193	   [RFC3522]  Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
1194	              for TCP", RFC 3522, April 2003.

1196	   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
1197	              Congestion Notification (ECN) Signaling with Nonces",
1198	              RFC 3540, June 2003.

1200	   [RFC3649]  Floyd, S., "HighSpeed TCP for Large Congestion Windows",
1201	              RFC 3649, December 2003.

1203	   [RFC3708]  Blanton, E. and M. Allman, "Using TCP Duplicate Selective
1204	              Acknowledgement (DSACKs) and Stream Control Transmission
1205	              Protocol (SCTP) Duplicate Transmission Sequence Numbers
1206	              (TSNs) to Detect Spurious Retransmissions", RFC 3708,
1207	              February 2004.

1209	   [RFC3742]  Floyd, S., "Limited Slow-Start for TCP with Large
1210	              Congestion Windows", RFC 3742, March 2004.

1212	   [RFC4138]  Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
1213	              An Algorithm for Detecting Spurious Retransmission
1214	              Timeouts with TCP and the Stream Control Transmission
1215	              Protocol (SCTP)", RFC 4138.

1217	11.4  Historic Extensions

1219	   [RFC1106]  Fox, R., "TCP big window and NAK options", RFC 1106,
1220	              June 1989.

1222	   [RFC1110]  McKenzie, A., "Problem with the TCP big window option",
1223	              RFC 1110, August 1989.

1225	   [RFC1146]  Zweig, J. and C. Partridge, "TCP alternate checksum
1226	              options", RFC 1146, March 1990.

1228	   [RFC1263]  O'Malley, S. and L. Peterson, "TCP Extensions Considered
1229	              Harmful", RFC 1263, October 1991.

1231	   [RFC1379]  Braden, B., "Extending TCP for Transactions -- Concepts",
1232	              RFC 1379, November 1992.

1234	   [RFC1644]  Braden, B., "T/TCP -- TCP Extensions for Transactions
1235	              Functional Specification", RFC 1644, July 1994.

1237	   [RFC1693]  Connolly, T., Amer, P., and P. Conrad, "An Extension to
1238	              TCP : Partial Order Service", RFC 1693, November 1994.

1240	11.5  Support Documents

1242	   [RFC0813]  Clark, D., "Window and Acknowledgement Strategy in TCP",
1243	              RFC 813, July 1982.

1245	   [RFC0814]  Clark, D., "Name, addresses, ports, and routes", RFC 814,
1246	              July 1982.

1248	   [RFC0816]  Clark, D., "Fault isolation and recovery", RFC 816,
1249	              July 1982.

1251	   [RFC0817]  Clark, D., "Modularity and efficiency in protocol
1252	              implementation", RFC 817, July 1982.

1254	   [RFC0872]  Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982.

1256	   [RFC0879]  Postel, J., "TCP maximum segment size and related topics",
1257	              RFC 879, November 1983.

1259	   [RFC0896]  Nagle, J., "Congestion control in IP/TCP internetworks",
1260	              RFC 896, January 1984.

1262	   [RFC0964]  Sidhu, D. and T. Blumer, "Some problems with the
1263	              specification of the Military Standard Transmission
1264	              Control Protocol", RFC 964, November 1985.

1266	   [RFC1066]  McCloghrie, K. and M. Rose, "Management Information Base
1267	              for network management of TCP/IP-based internets",
1268	              RFC 1066, August 1988.

1270	   [RFC1071]  Braden, R., Borman, D., Partridge, C., and W. Plummer,
1271	              "Computing the Internet checksum", RFC 1071,
1272	              September 1988.

1274	   [RFC1072]  Jacobson, V. and R. Braden, "TCP extensions for long-delay
1275	              paths", RFC 1072, October 1988.

1277	   [RFC1156]  McCloghrie, K. and M. Rose, "Management Information Base
1278	              for network management of TCP/IP-based internets",
1279	              RFC 1156, May 1990.

1281	   [RFC1180]  Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180,
1282	              January 1991.

1284	   [RFC1185]  Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for
1285	              High-Speed Paths", RFC 1185, October 1990.

1287	   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
1288	              for Network Management of TCP/IP-based internets:MIB-II",
1289	              STD 17, RFC 1213, March 1991.

1291	   [RFC1337]  Braden, B., "TIME-WAIT Assassination Hazards in TCP",
1292	              RFC 1337, May 1992.

1294	   [RFC1470]  Enger, R. and J. Reynolds, "FYI on a Network Management
1295	              Tool Catalog: Tools for Monitoring and Debugging TCP/IP
1296	              Internets and Interconnected Devices", RFC 1470,
1297	              June 1993.

1299	   [RFC1624]  Rijsinghani, A., "Computation of the Internet Checksum via
1300	              Incremental Update", RFC 1624, May 1994.

1302	   [RFC1936]  Touch, J. and B. Parham, "Implementing the Internet
1303	              Checksum in Hardware", RFC 1936, April 1996.

1305	   [RFC2012]  McCloghrie, K., "SNMPv2 Management Information Base for
1306	              the Transmission Control Protocol using SMIv2", RFC 2012,
1307	              November 1996.

1309	   [RFC2398]  Parker, S. and C. Schmechel, "Some Testing Tools for TCP
1310	              Implementors", RFC 2398, August 1998.

1312	   [RFC2415]  Poduri, K., "Simulation Studies of Increased Initial TCP
1313	              Window Size", RFC 2415, September 1998.

1315	   [RFC2416]  Shepard, T. and C. Partridge, "When TCP Starts Up With
1316	              Four Packets Into Only Three Buffers", RFC 2416,
1317	              September 1998.

1319	   [RFC2452]  Daniele, M., "IP Version 6 Management Information Base for
1320	              the Transmission Control Protocol", RFC 2452,
1321	              December 1998.

1323	   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
1324	              Over Satellite Channels using Standard Mechanisms",
1325	              BCP 28, RFC 2488, January 1999.

1327	   [RFC2525]  Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
1328	              J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
1329	              TCP Implementation Problems", RFC 2525, March 1999.

1331	   [RFC2757]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
1332	              Vaidya, "Long Thin Networks", RFC 2757, January 2000.

1334	   [RFC2760]  Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
1335	              Henderson, T., Heidemann, J., Touch, J., Kruse, H.,
1336	              Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP
1337	              Research Related to Satellites", RFC 2760, February 2000.

1339	   [RFC2884]  Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
1340	              Explicit Congestion Notification (ECN) in IP Networks",
1341	              RFC 2884, July 2000.

1343	   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
1344	              RFC 2914, September 2000.

1346	   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
1347	              RFC 2923, September 2000.

1349	   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
1350	              Shelby, "Performance Enhancing Proxies Intended to
1351	              Mitigate Link-Related Degradations", RFC 3135, June 2001.

1353	   [RFC3360]  Floyd, S., "Inappropriate TCP Resets Considered Harmful",
1354	              BCP 60, RFC 3360, August 2002.

1356	   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
1357	              Sooriyabandara, "TCP Performance Implications of Network
1358	              Path Asymmetry", BCP 69, RFC 3449, December 2002.

1360	   [RFC3481]  Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and
1361	              F. Khafizov, "TCP over Second (2.5G) and Third (3G)
1362	              Generation Wireless Networks", BCP 71, RFC 3481,
1363	              February 2003.

1365	   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
1366	              Stevens, "Basic Socket Interface Extensions for IPv6",
1367	              RFC 3493, February 2003.

1369	   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
1370	              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
1371	              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
1372	              RFC 3819, July 2004.

1374	   [RFC4022]  Raghunarayan, R., "Management Information Base for the
1375	              Transmission Control Protocol (TCP)", RFC 4022,
1376	              March 2005.

1378	11.6  Informative References Outside the RFC Series

1380	   [JK92]    Jacobson, V. and M. Karels, "Congestion Avoidance and
1381	             Control", This paper is a revised version of [Jac88], that
1382	             includes an additional appendix.  This paper has not been
1383	             traditionally published, but is currently available at
1384	             ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.

1386	   [Jac88]   Jacobson, V., "Congestion Avoidance and Control", ACM
1387	             SIGCOMM 1988 Proceedings, in ACM Computer Communication
1388	             Review, 18 (4), pp. 314-329, August 1988.

1390	   [KP87]    Karn, P. and C. Partridge, "Round Trip Time Estimation",
1391	             ACM SIGCOMM 1987 Proceedings, in ACM Computer Communication
1392	             Review, 17 (5), pp. 2-7, August 1987.

1394	   [MAF04]   Medina, A., Allman, M., and S. Floyd, "Measuring the
1395	             Evolution of Transport Protocols in the Internet", ACM
1396	             Computer Communication Review, 35 (2), April 2005.

1398	   [MM96]    Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
1399	             Refining TCP Congestion Control", ACM SIGCOMM 1996
1400	             Proceedings, in ACM Computer Communication Review 26 (4),
1401	             pp. 281-292, October 1996.

1403	   [SCWA99]  Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
1404	             "TCP Congestion Control with a Misbehaving Receiver", ACM
1405	             Computer Communication Review, 29 (5), pp. 71-78,
1406	             October 1999.

1408	Authors' Addresses

1410	   Martin Duke
1411	   Boeing Phantom Works
1412	   PO Box 3707, MC 7L-49
1413	   Seattle, WA  98124-2207

1415	   Phone: 425-865-1182
1416	   Email: martin.duke@boeing.com

1418	   Robert Braden
1419	   USC Information Sciences Institute
1420	   Marina del Rey, CA  90292-6695

1422	   Phone: 310-448-9173
1423	   Email: braden@isi.edu
1424	   Wesley M. Eddy
1425	   Verizon Federal Network Systems
1426	   21000 Brookpark Rd, MS 54-5
1427	   Cleveland, OH  44135

1429	   Phone: 216-433-6682
1430	   Email: weddy@grc.nasa.gov

1432	   Ethan Blanton
1433	   Purdue University Computer Science
1434	   250 N. University St.
1435	   West Lafayette, IN  47907

1437	   Email: eblanton@cs.purdue.edu

1439	Intellectual Property Statement

1441	   The IETF takes no position regarding the validity or scope of any
1442	   Intellectual Property Rights or other rights that might be claimed to
1443	   pertain to the implementation or use of the technology described in
1444	   this document or the extent to which any license under such rights
1445	   might or might not be available; nor does it represent that it has
1446	   made any independent effort to identify any such rights.  Information
1447	   on the procedures with respect to rights in RFC documents can be
1448	   found in BCP 78 and BCP 79.

1450	   Copies of IPR disclosures made to the IETF Secretariat and any
1451	   assurances of licenses to be made available, or the result of an
1452	   attempt made to obtain a general license or permission for the use of
1453	   such proprietary rights by implementers or users of this
1454	   specification can be obtained from the IETF on-line IPR repository at
1455	   http://www.ietf.org/ipr.

1457	   The IETF invites any interested party to bring to its attention any
1458	   copyrights, patents or patent applications, or other proprietary
1459	   rights that may cover technology that may be required to implement
1460	   this standard.  Please address the information to the IETF at
1461	   ietf-ipr@ietf.org.

1463	Disclaimer of Validity

1465	   This document and the information contained herein are provided on an
1466	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1467	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1468	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1469	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1470	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1471	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1473	Copyright Statement

1475	   Copyright (C) The Internet Society (2005).  This document is subject
1476	   to the rights, licenses and restrictions contained in BCP 78, and
1477	   except as set forth therein, the authors retain all their rights.

1479	Acknowledgment

1481	   Funding for the RFC Editor function is currently provided by the
1482	   Internet Society.