Internet DRAFT - draft-ananth-tcpm-tcpoptext
draft-ananth-tcpm-tcpoptext
TCPM WG A. Ramaiah
Internet-Draft Cisco
Intended status: Informational March 25, 2012
Expires: September 26, 2012
TCP option space extension
draft-ananth-tcpm-tcpoptext-00.txt
Abstract
The document goals are as follows: Firstly, this document summarizes
the motivations for extending TCP option space. Secondly, It tries
to summarize the various known issues that needs to be taken into
account while extending the TCP option space. Thirdly, it briefly
provides a short summary of the various TCP option space proposals
that has been proposed so far. Some additional proposals which
includes variations to the existing proposals are also presented.
The goal of this document is to rejuvenate the discussions on this
topic and eventually to converge on a scheme for extending TCP option
space.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Ramaiah Expires September 26, 2012 [Page 1]
Internet-Draft TCP option space March 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Common issues with TCP option extension . . . . . . . . . . . 5
4. TCP option space extension proposals . . . . . . . . . . . . . 7
4.1. TCP LO and SLO . . . . . . . . . . . . . . . . . . . . . . 7
4.2. TCP DO field overload (Extended segments) . . . . . . . . 8
4.3. Increase (Double) TCP header size - TCPx2 . . . . . . . . 9
4.4. TCP LOIC . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5. Multiple segments with continuation . . . . . . . . . . . 11
4.6. TCP option cookies . . . . . . . . . . . . . . . . . . . . 12
4.7. Reuse/overload of other TCP fields . . . . . . . . . . . . 12
4.8. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 12
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Ramaiah Expires September 26, 2012 [Page 2]
Internet-Draft TCP option space March 2012
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]
Middlebox : the middlebox could be a proxy like PEP (performance
enhancing proxies), NAT device or a Firewall. Note : The term packet
and segment is used interchangeably in this document.
Ramaiah Expires September 26, 2012 [Page 3]
Internet-Draft TCP option space March 2012
2. Introduction
TCP [RFC0793] as part of its header includes TCP options which
provides some special functionality that can be negotiated by both
ends of the TCP connection. As the name implies, these aren't
mandatory but must be supported by both ends in order to be active on
a given TCP connection. Some examples of deployed TCP options
include TCP MSS, Window Scale, Selective ACK, Timestamps ([RFC1323]
). Many other TCP options have been proposed and have been in use in
different environments eg:- TCP-MD5 [RFC2385] is used to secure a BGP
session. The TCP option space limitation is imposed by the 4 bit
Data Offset (DO) field which restricts the total length of the TCP
header (including options) to 60 bytes ([RFC0793]). Since the
required fields of the TCP header consumes 20 bytes, this leaves 40
bytes as the maximum amount of space for use by TCP options.
2.1. Motivation
The TCP option space of 40 bytes which was considered reasonable for
the concurrent usage of some popular TCP options, is no longer able
to cater to needs of recent growing demands. Over the past few years
several new TCP options like TCP-UTO ([RFC5482]), TCP-AO ([RFC5925]),
experimental TCP options for acknowledgment congestion control
([RFC5690]), have been proposed. MultiPath TCP
([I-D.ietf-mptcp-multiaddressed]) is another feature which calls for
more TCP option space. Lastly middleboxes doing WAN optimization
functionality can also benefit with the increased TCP option space,
although it is not the intention of this memo to address such
requirements. It is mentioned here simply for the sake of
completeness.
Since it is not easy to extend TCP option space, TCP option space
hungry applications could move to a different protocol like SCTP
([RFC4960]), which for instance provides 255 chunks (each SCTP chunk
is analogous to a TCP option) Needless to mention, this is not always
possible and moving to a new protocol, at the least not only has all
the issues that is exhibited by a new TCP option but even more (like
general protocol upgrade and support, etc.,)
It is therefore expedient to extend the TCP option space to meet the
near term requirements coming from the various TCP applications for
active internet deployment and research.
Ramaiah Expires September 26, 2012 [Page 4]
Internet-Draft TCP option space March 2012
3. Common issues with TCP option extension
Typically any proposal trying to extend the TCP option space needs to
use some form of explicit signaling during the 3 way handshake of TCP
to negotiate the usage of TCP extended options. This is typically
accomplished by means of having a new TCP option or by using one of
the reserved bits of the TCP header. In the reminder of the text we
refer both of these methods simply as "TCP extended option(s)". The
following notes apply to either of these methods.
Any TCP option extension proposals needs to be aware of the following
design issues :-
End host backward compatibility - Any of the TCP option space
extension proposals needs to satisfy the following end-host
compatibility requirements :-
H1) Needs to have the capability to interoperate with stacks that
do not have ability to negotiate the TCP extended option space.
H2) If the TCP extended options could not be negotiated, then it
needs to fall back to normal mode of operation.
H3) It also needs to be noted that in some rare cases end-hosts
not understanding a TCP option simply echoes back the TCP
option in response. This is due to buggy implementation and
hence this is not a requirement at all. Just mentioned for the
sake of completeness.
Middle box interoperability - This is the toughest of the problems
in getting towards a cleaner solution for extending TCP option
space. It needs to be noted that middlebox interactions disrupt
the end-to-end flow characteristics and any solution is
susceptible to it's presence. TCP option space extension
proposals need to be aware of the following issues :-
M1) Some middleboxes terminate TCP connections (Performance
Enhancing Proxies) [RFC3135]
M2) Some middleboxes examine TCP payloads (Virus scanner,
firewall), some modify the TCP payloads (NAT ALG)
M3) In general middleboxes keep state which includes TCP sequence
numbers, some of them (proxies which do not terminate the TCP
connection) would adjust the sequence and acknowledgement
numbers on a per packet basis.
Ramaiah Expires September 26, 2012 [Page 5]
Internet-Draft TCP option space March 2012
M4) Some middleboxes strip unknown TCP options.
M5) Some middleboxes resegment TCP data.
M6) Some middleboxes drop packets containing unknown TCP options.
Among the above M4, M5 and M6 are not common, M1, M2 & M3 exhibits
varying degrees of commonality. Cases M2 and to some extent M3
proves to be the toughest candidate to work with for seamless TCP
option extension.
Another point worthy of mention would be that, the outgoing path or
the return path may change between connections or even during a
connection, which can lead to traversal of different middleboxes.
This simply means that the same middlebox behavior cannot be
guaranteed for all the packets of a given TCP connection.
Ramaiah Expires September 26, 2012 [Page 6]
Internet-Draft TCP option space March 2012
4. TCP option space extension proposals
The following section summarizes some of the existing TCP option
space proposals (section 4.1 to 4.4), touches upon some new ideas and
variations of the existing proposals (section 4.5 to 4.7), and
analyses each one of the proposal's strengths and weaknesses. It
needs to be emphasized that the new ideas (section 4.5 to 4.7) are by
no means a complete solution, but some general ideas which can be
used as building blocks or food for thought when trying to devise
solution for the TCP option space exhaustion issue.
4.1. TCP LO and SLO
This ID ([I-D.eddy-tcp-loo]) talks about the defining a new TCP
option that overrides the standard TCP DO field definition. This is
accomplished by means of a TCP Long Option (LO) which gets negotiated
during SYN. If both ends understand the LO option, then whenever the
LO option is present, the DO field of the standard TCP header would
be ignored for computing the TCP data offset. Instead the "Header
Length" specified in the LO option would be used to derive the Data
Offset. The LO option MUST be the first option present in the TCP
segment. The draft actually mandates the LO option to be present in
all segments, to circumvent odd bugs arising due to TCP segments with
different interpretations of DO with and without the presence of the
LO option.
The draft also defines a SYN Long Option (SLO). The purpose of this
option is to retain backward compatibility with hosts that do not
support the LO option. This is needed because a host which does not
understand the LO option would mistakenly treat anything past the DO-
specified boundary to be application data. The SLO option is used in
the case where 40 bytes (max option space in standard TCP) is not
enough to carry the desired TCP options to be sent on the SYN. It is
only used by devices issuing an active open, since the passive open
side can always use the LO option to send the long list of TCP
options. The left-off options are reliably delivered in the
subsequent data (and acknowledgment ) segments.
Discussion :
This proposal addresses the host backward compatibility well (H1 &
H2), since if the LO is not understood or stripped by a middlebox in
between it would simply proceed with standard TCP semantics. However
there is no provision for handling H3. This can be circumvented if
needed, but it not probably worth the effort since such hosts are
very uncommon in author's viewpoint. In the reminder of the
proposals H3's compatibility is not going to be discussed.
Ramaiah Expires September 26, 2012 [Page 7]
Internet-Draft TCP option space March 2012
Coming to the middlebox case, if the middlebox strips the TCP option
(M4), it is fine, since this option would not be negotiated. If the
SYN gets dropped by a middlebox (M6), then retransmission request may
be tried without the long option. For the case of PEP's (M1) if the
connection gets terminated, then the middlebox which doesn't
understand the LO option would reply with SYN+ACK without LO and it
is fine since fallback to normal mode would happen. But this
proposal (like any other proposal) may have implications with
resegmenting (M5) feature of some middleboxes (which do not
understand the LO option) since the TCP options gets blindly copied
in all segmented segments by the middlebox. This would cause the
end-host understanding the LO option to get confused, since it would
interpret the duplicated segments as containing the TCP options.
The issue of option data getting confused as payload due the
middlebox segmenting the TCP data can be circumvented by either
having the total length of the TCP segment OR the TCP sequence number
which points to the beginning of the data (instead of the proposed
header length field which points to the Data Offset). It also needs
to be noted that it is strongly advisable for any TCP options that
could not fit into the standard TCP option space (40 bytes) begin
after the 40 bytes boundary since any middlebox that cannot
understand the LO option and does some TCP header fields sanity can
get confused and drop the segment, if the new option is not fully
contained in the TCP option space.
This proposal would have an issue with middleboxes that do not
understand the extension and tries operate on the TCP payload (M2).
For M3, it really depends on the middlebox, if the middlebox sees the
next sequence number as lesser than the one it expects, it would
simply treat that as a duplicate (good thing), however for some
middleboxes if it tries to cache segments and perform retransmissions
etc., it may be a problematic.
4.2. TCP DO field overload (Extended segments)
This proposal ([I-D.kohler-tcpm-extopt]) tries to solve the TCP
option space issue by redefining the TCP DO field. Extended segments
approach overloads the meaning of the standard TCP Data Offset field,
keeping its original meaning for values of 5 and greater, but
redefining it for values less than 5. This is seen as acceptable
since values less than 5 are currently impossible, illegal, and
unusable. Extended segments avoid the need for new options by
changing the way that the existing standard header is parsed.
The granularity of option lengths that extended segments can support
is limited to the number of unusable Data Offset values (5, 0 through
4). Currently, the extended segments proposal defines 4 fixed
Ramaiah Expires September 26, 2012 [Page 8]
Internet-Draft TCP option space March 2012
lengths, and one "infinite" length that means the entire segment is
options, with no application data. The fixed option lengths are 48,
64, 128, and 256 bytes.
Discussion :
If the required per-data-segment TCP options space for some extension
or combination of extensions does not map to exactly one of the
extended DO values, then padding bytes are required. If 129 bytes of
options are required on a data segment, then a length of 256 must be
used, and 127 bytes of useless padding are added.
As far as the end host compatibilty goes, if the end host doesn't
understand the extended SYN (i.e. a SYN with DO < 5), the SYN would
get dropped which is the typical behavior. Instead if some
implementations who chose to send RST due to malformed segment (TCP
header validation failure) is problematic since the end host would
get confused whether the RST is due to its original intention (i.e.
listener not present on the server or some other known thing like
policy restrictions). The draft also mentions that extended SYN-ACKs
may be sent in response to non-extended SYNs. This complicates the
recovery procedure even more, if not understood, and goes against the
way that all current negotiable TCP extensions operate (only used on
SYN-ACK if advertised on SYN). Hence we can see that the fallback
(cases H1 and H2) is not smooth when compared to the LO proposal.
As the middlebox goes, it suffers the same set of issues as the LO
proposal. But there is no provision that can be made for the case of
re-segmentation by middleboxes (M5). So, extended segments approach
seems to be inferior compared to LO proposal in terms of robustness.
4.3. Increase (Double) TCP header size - TCPx2
This proposal([I-D.allman-tcpx2-hack]) was aimed to not just address
the TCP option space exhaustion but to address other myriad of issues
surrounding the TCP header fields. (like window size, reserved bits
etc.,) TCPx2 requires a new IP protocol number. It defines a new TCP
header which has all the original field sizes doubled. Hence the TCP
DO field becomes 8 bits instead of the original 4 bits.
Discussion :
Ideally this proposal seems to be the best long term solution for TCP
issues caused due the limits imposed by the various fields of TCP
header, which includes the TCP option space issue. However, for
short, medium or immediate term deployment it is not practical.
TCPx2 would face the same resistance (even worse since it is a new
entrant) from middleboxes as experienced by some "newer" protocols
Ramaiah Expires September 26, 2012 [Page 9]
Internet-Draft TCP option space March 2012
like SCTP etc., which hampered their successful adoption and
deployment. End hosts TCP/IP stacks need to change to support the
new IP protocol number, demux logic and new TCP header. The standard
algorithms like TCP checksum, TCP MAC computation etc., needs to
change, especially makes it difficult in cases where this
functionality is assisted by hardware. The sockets API or TCP API's
would have to change to accommodate the TCP header changes (src and
dest ports) and also to offer backward compatibility to existing TCP.
All the diagnostic tools surrounding etc., needs to change, the list
only continues.
4.4. TCP LOIC
The crux of this proposal ([I-D.yourtchenko-tcp-loic]) is to quickly
negotiate the LO (referred as LOIC in the document) option by sending
it in SYN segment and also fallback to normal mode if the remote end
or the middlebox drops the SYN. This is accomplished by sending 2
SYN's, one with the intent of negotiating the LO option and other one
which contains the all the options that needs to be negotiated
(includes the ones that cannot fit in the standard option space). To
prevent the TCP option space mistakenly read as data, the proposal
deliberately increments the checksum by 2 in the second SYN segment
(which contains the TCP options). If the end host (or middlebox)
doesn't understand the signalling (checksum + 2), it would drop the
segment and the first SYN would get replied with SYN+ACK without LO.
OTOH, if the stack understands the method, it would be able to
process the both the SYNs (all the TCP options) and reply back with
LO.
Discussion
This proposal cleverly avoids doing the option exchange dance after
the SYN segment gets ACKnowledged like seen in LO proposal (section
4.1) by sending duplicate SYN's. This proposal addresses the host
backward compatibility well (H1 & H2). However it has some issues.
The overloading of checksum can have other implications esp., with
some middeboxes that modify the checksum (NAT) which can rollover the
16 bit field and the checksum decrement would fail to work.
Overloading checksum would not bode well with diagnostic tools
(sniffers etc.,) and also in cases where checksum gets offloaded to
some hardware which needs to understand this method.
M1, M4, M6 are taken care of well by this proposal. It suffers the
same fate as other proposals as far as M5 is concerned. It exhibits
the same behavior as far as M2 and M3 goes, since the proposal sends
TCP options as part of the standard TCP header.
One other note worthy of mentioning would be, this proposal is in
Ramaiah Expires September 26, 2012 [Page 10]
Internet-Draft TCP option space March 2012
some sense similar to the concept of "extended segments". Extended
segments approach tries to overload (use the illegal unused values)
the DO field. One could argue that instead of mucking around with
the checksum you could actually send the second SYN with "incorrect"
( DO < 5) value. However if we throw in the middlebox into the
equation, the likelihood of a packet getting dropped by the middlebox
(firewall which does some TCP header validation) with DO field
incorrectly specified is more when compared to packet with incorrect
checksum. (This is because typically firewalls don't try to do
compute intensive operations like TCP checksum validation)
4.5. Multiple segments with continuation
Both, extended segments and LOIC (section 4.2 and section 4.4)
already mentions about sending multiple SYNs. This idea also uses
the same approach with a key difference, i.e. send multiple SYNs with
a "TCP continuation option". The TCP continuation option's purpose
(which is a simple option-kind option) is to convey to the other end
that "not all TCP options could be fit into to the current TCP
segment's standard option space (40 bytes) and subsequent segments
would convey the reminder of the option". For example lets us say we
have 100 bytes of TCP option, this would require 3 segments to
convey, the first 2 of which would have the TCP continuation option
set. The rationale for this kind of thinking is twofold. Firstly,
keeping in mind short term goals, TCP option space requirement isn't
very large, hence a few segments should do the task at hand.
Secondly, middleboxes (and end hosts) gets confused if you send
something in the data portion, hence don't take chance of putting
anything in the data portion of TCP.
The obvious drawback of this scheme is that if there a way too many
TCP options to be conveyed, then it would take more segments to
convey all of them. For SYN segments, send multiple SYNs, for Data
segments (during the middle of connection) try to send multiple data
segments (behave as though nagle is turned off) and piggyback TCP
options with TCP continuation. Well, this may sound outrageous but
it should at least get rid of the middlebox issue at the cost of
adding more processing and delay. Pick the devil.
Sending duplicate segments is generally ok and should not have
adverse middlebox effects. Sending old segments (ones that are
already ACKed is another school of thought. This is how keepalives
work where the sequence number is set to TCB.SNDUNA - 1, which
solicits a corrective ACK from the other end. Sending old data
segment, simply gets dropped and one could use that to convey TCP
options, but that may get clumsier since you really need TCP options
to be inline with the current data. Just mentioned here for the sake
of completeness.
Ramaiah Expires September 26, 2012 [Page 11]
Internet-Draft TCP option space March 2012
4.6. TCP option cookies
This is yet another interesting thought (at least in author's
opinion). The idea is to pack TCP options in a similar way TCP SYN
cookies did. i.e., instead of doing the "Option-Kind" OR "option-
kind-value", we could just have bit masks OR some encoding scheme
defined under a TCP option template. We can call it as a "TCP
template or TCP Master option". At least during the initial
negotiation this would be helpful to scavenge TCP option space. The
details of this need to be thought of and extensibility also needs to
be addressed. Compressing TCP options is another school of thought
along the similar lines, but the compression overhead needs space as
well, hence needs to be carefully thought about.
4.7. Reuse/overload of other TCP fields
Some of the schemes already tried to overload some TCP fields like
TCP DO (section 4.2) and TCP checksum overload (section 4.4).
Another tempting field to overload is the TCP urgent pointer. It
needs to be noted that the TCP urgent pointer is valid only when the
URG bit is set. Also the TCP urgent pointer is used only by some
legacy applications like Telnet and rlogin, both of which don't use
any advanced TCP options nor require such a functionality. Also
([RFC6093]), suggests deprecating its usage for newer applications.
It mentions that due to inconsistent interpretation of the urgent
pointer by end hosts and some middleboxes which clear the urgent flag
and urgent pointer, the urgent mechanism should be deprecated. But,
in authors opinion, the middleboxes that clear the urgent pointer
only for some given ports like telnet and FTP. Given all these
facts, it is not unreasonable to try to put this field to some good
use. The urgent pointer could be used to redefine the TCP DO field
in the same way the TCP DO redefinition scheme did but with a 16 bits
of precision as opposed to just 3 (values < 5). The hope is that
middleboxes (firewalls) would simply ignore the urgent pointer value
since the URG bit is not set. We could also use the Urgent pointer
for a fallback mechanism like the TCP checksum (LOIC) proposal did.
4.8. Miscellaneous
The previous sections have been trying to do a best possible effort
in identifying some candidates for scavenging TCP option space, some
ways of getting around the middleboxes etc., One school of thought
would be, it is sometimes ok to convey TCP options across multiple
segments (the TCP continuation option touched upon this aspect). for
example let's say there are 5 SACK blocks, they can't be conveyed
using a single TCP segment, this takes multiple TCP segments which is
ok (the way it is working today). It may be possible to do this for
other TCP options as well, which need not be conveyed on every packet
Ramaiah Expires September 26, 2012 [Page 12]
Internet-Draft TCP option space March 2012
like the TCP security option. For e.g., TCP timestamps need to be
conveyed on every segment, but care needs to be taken not to break
PAWS etc.,
Ramaiah Expires September 26, 2012 [Page 13]
Internet-Draft TCP option space March 2012
5. Conclusion
If we get this far in the document, the obvious question would be "is
there a winner?" clearly not since any method has some issue or the
other and most of them are vulnerable to the middlebox processing of
packets (in particular cases M2 and M3 are tough to circumvent with).
But, there are different types of middleboxes and it really needs to
be seen what percentage of them exists in different environments.
There was a recent interesting study [IMC2011], which focused on the
issues of extending TCP which includes the analysis of various
middlebox behaviors. This could be used as a reference point for any
new proposals on extending TCP which includes the TCP option space
extension proposals.
This document listed a plethora of solutions (some of which may be
half-baked) to address some common middlebox problems and graceful
fallback to regular TCP methods. Now, no solution is a perfect
solution and it is impossible to work around all the use cases
imposed by middleboxes. Moving to a new protocol also is not a
solution, hence we are left with no choice but to extend TCP that
works for most of the use cases. Lastly, but not the least, the hope
of this document is that it serves as a foundational document that
touches upon the various aspects of extending TCP option space and
acts as a motivational document to converge to a possible solution
for the TCP option space exhaustion issue.
Ramaiah Expires September 26, 2012 [Page 14]
Internet-Draft TCP option space March 2012
6. IANA Considerations
None.
Ramaiah Expires September 26, 2012 [Page 15]
Internet-Draft TCP option space March 2012
7. Security Considerations
None at this time.
Ramaiah Expires September 26, 2012 [Page 16]
Internet-Draft TCP option space March 2012
8. Acknowledgements
Thanks to Dan Wing and Andrew Yourtchenko for the initial review of
the draft.
Ramaiah Expires September 26, 2012 [Page 17]
Internet-Draft TCP option space March 2012
9. References
9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.allman-tcpx2-hack]
Allman, M., "TCPx2: Don't Fence Me In",
draft-allman-tcpx2-hack-00 (work in progress), May 2006.
[I-D.eddy-tcp-loo]
Eddy, W. and A. Langley, "Extending the Space Available
for TCP Options", draft-eddy-tcp-loo-04 (work in
progress), July 2008.
[I-D.ietf-mptcp-multiaddressed]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-multiaddressed-07 (work in
progress), March 2012.
[I-D.kohler-tcpm-extopt]
Kohler, E., "Extended Option Space for TCP",
draft-kohler-tcpm-extopt-00 (work in progress),
September 2004.
[I-D.yourtchenko-tcp-loic]
Yourtchenko, A., "Introducing TCP Long Options by Invalid
Checksum", draft-yourtchenko-tcp-loic-00 (work in
progress), April 2011.
[IMC2011] Honda et. al, M., "Internet Measurement conference 2011.
http://conferences.sigcomm.org/imc/2011/docs/p181.pdf",
November 2011.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Ramaiah Expires September 26, 2012 [Page 18]
Internet-Draft TCP option space March 2012
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, March 2009.
[RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding
Acknowledgement Congestion Control to TCP", RFC 5690,
February 2010.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the
TCP Urgent Mechanism", RFC 6093, January 2011.
Ramaiah Expires September 26, 2012 [Page 19]
Internet-Draft TCP option space March 2012
Author's Address
Anantha Ramaiah
Cisco
170 Tasman Drive
San Jose, CA 95134
USA
Phone: +1 (408) 525-6486
Email: ananth@cisco.com
Ramaiah Expires September 26, 2012 [Page 20]
