From c96250dccdb4d34d76192bf1f59fb6ad9842ce45 Mon Sep 17 00:00:00 2001 From: Othmar Gsenger Date: Mon, 16 Apr 2007 14:06:57 +0000 Subject: rfc split --- internet-draft-anycast-tcp-stream-relay.txt | 392 ++++++++++++++++++++++++++++ 1 file changed, 392 insertions(+) create mode 100644 internet-draft-anycast-tcp-stream-relay.txt (limited to 'internet-draft-anycast-tcp-stream-relay.txt') 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] + -- cgit v1.2.3