rfc split

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]
+