summaryrefslogtreecommitdiff
path: root/internet-draft-anycast-tcp-stream-relay.txt
diff options
context:
space:
mode:
Diffstat (limited to 'internet-draft-anycast-tcp-stream-relay.txt')
-rw-r--r--internet-draft-anycast-tcp-stream-relay.txt392
1 files changed, 392 insertions, 0 deletions
diff --git a/internet-draft-anycast-tcp-stream-relay.txt b/internet-draft-anycast-tcp-stream-relay.txt
new file mode 100644
index 0000000..ad91815
--- /dev/null
+++ b/internet-draft-anycast-tcp-stream-relay.txt
@@ -0,0 +1,392 @@
+
+
+
+Network Working Group O. Gsenger
+Internet-Draft March 2007
+Expires: September 2, 2007
+
+
+ Anycast TCP stream relaying
+ draft-gsenger-anycast-tcp-stream-relay-00
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ 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."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 2, 2007.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 1]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+Abstract
+
+ The anycast tunneling (anytun) protocol defines a protocol used for
+ communication between unicast clients and anycast servers. It can be
+ used for tunneling information between 2 clients over the servers or
+ in relay mode to transmit data form the client over the servers to a
+ third party not using the protocol and vice versa.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 2]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+1. full anycast tcp
+
+1.1. Introduction
+
+ TCP is statefull, this is a big problem, because every anycast server
+ has to know the tcp state. The TCP state has to be synced between
+ the servers, that meens a lot of overhead. To keep this amount small
+ and therefor make anycast TCP connections efficient some tricks MUST
+ be used. This is considered to be a real hack, so it is not
+ recommendid to use this mode unless it is really necessary. It might
+ for instance be necessary to build connection trough special kind of
+ NAT routers or firewalls.
+
+1.2. Reducing syncronisaton overhead
+
+1.2.1. Fragmentation
+
+ The only way of fully supporting fragmentation would be to syncronise
+ fragments between all anycast servers. This is considered to be to
+ much overhead, so there are two non perfect solutions for this
+ problems. Either fragmentation HAS TO be disabled or if not all
+ fragments arrive at the same server the ip datagramm HAS TO be
+ discarded. As routing changes are not expected to occure very
+ frequently, the ip datagram will get retransmitted by TCP and all
+ fragments will arrive at the new server.
+
+1.2.2. sequence number
+
+ It is nessarary to send tcp segments with a correct sequence number,
+ that appear to come from the same host, in order to get a valid
+ connecton to the client. Syncronisation of sequence numbers would
+ mean to much overhead, so it hast to be provided by the relayed data.
+ The relayed data from the anycast serveres point of view, consits of
+ multible datastream, each directed from one client to anotherIn
+ tunneling mode all anytun packets from the client
+
+1.3. keep alive message request
+
+ Most NAT routers need a tcp connection to transmit some packets once
+ in while to stay open. In full anycast tcp mode anytun hast to
+ predict the tcp state including the sequence number. Synconisation
+ of the sequence number would be to much overhead, so a keep alive
+ intervall is agreed. This interval is used to calculate the sequemce
+ number.
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 3]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+Appendix A. The appan
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 4]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+2. References
+
+ [1] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
+ RFC 3068, June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 5]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+Author's Address
+
+ Othmar Gsenger
+ Sporgasse 6
+ Graz 8010
+ AT
+
+ Phone:
+ Email: otti@wirdorange.org
+ URI: http://anytun.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 6]
+
+Internet-Draft Anycast TCP stream relaying March 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Gsenger Expires September 2, 2007 [Page 7]
+