namensgebung

1 files changed, 0 insertions, 672 deletions

diff --git a/draft-gsenger-anycast-relay-00.txt b/draft-gsenger-anycast-relay-00.txt
deleted file mode 100644
index 588d4d6..0000000
--- a/draft-gsenger-anycast-relay-00.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                         O. Gsenger
-Internet-Draft                                                March 2007
-Expires: September 2, 2007
-
-
-                        Anycast stream relaying
-                     draft-gsenger-anycast-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 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 stream relaying              March 2007
-
-
-1.  Introduction
-
-   anytun defines a Host Anycast Service as defined in rfc1546.  It can
-   be used to build high scalable and redundant tunnel services.  It
-   supports both UDP and TCP connections.  Additionally to the
-   possibility of establashing an unicast TCP connection over an anycast
-   address as suggested in rfc1546, it supports real anycast TCP
-   connections with state syncronisation and heuristic state forecast.
-   It also has a relay mode, that makes it possible, that only one of
-   the connection endpoints has to use the anytun protocol.  This can be
-   used to make connections through Firewalls or behind a NAT Router
-
-   RFC3068 [1] DTD.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 3]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-2.  Operation modes
-
-   This section gives an overview of possible operation modes und usage
-   scenarios.  Please note, that the protocols used in the figures are
-   only examples and that anytun itself does not care about either
-   transport protocols or encapsulated protocols.  Routing and network
-   address translation is not done by anytun.  Each implemetation MAY
-   choose it's own way of doing this task (e.g. using functions provided
-   by the operating system).  Anytun is used to establish and controll
-   tunnnels, to encapsulate and encrypt data.
-
-2.1.  Tunnel modes
-
-2.1.1.  Tunneling Mode
-
-   An example of anytun used in tunnel mode
-
-             -----------                      -----------
-             |   RTP   |      ----------      |   RTP   |
-             -----------  ->  |server 1|  ->  -----------
-             |   UDP   |      ----------      |   UDP   |
-             -----------                      -----------
-   -----     |   IPv6  |      ----------      |   IPv6  |     -----
-   |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
-   -----     |  anytun |      ----------      |  anytun |     -----
-   #####     -----------                      -----------     #####
-             |   UDP   |      ----------      |   UDP   |
-   client 1  -----------  ->  |server 3|  ->  -----------     client 2
-             |   IPv4  |      ----------      |   IPv4  |
-             -----------                      -----------
-             |   ...   |       anycast        |   ...   |
-
-                                 Figure 1
-
-   In tunneling mode the payload of the anytun packet is transmitted
-   from one unicast host to the anycast server.  This server makes a
-   routing descision based on the underlying protocol and transmits a
-   new anytun package to one or more clients depending on the routing
-   descition.  The server MAY also route the packet to a directly
-   connected network or a service running on the server, but please
-   note, that this is only usefull for anycast host services like DNS
-   and that the services HAVE TO be running on all servers in order to
-   work.
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 4]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-2.1.2.  Open tunnel mode
-
-   An example of anytun used in open tunnel mode
-
-             -----------
-             |   RTP   |      ----------
-             -----------  ->  |server 1|  ->
-             |   UDP   |      ----------      -----------
-             -----------                      |   RTP   |
-   -----     |   IPv6  |      ----------      -----------     -----
-   |   |  -> -----------  ->  |server 2|  ->  |   UDP*  |  -> |   |
-   -----     |  anytun |      ----------      -----------     -----
-   #####     -----------                      |   IPv6* |     #####
-             |   UDP   |      ----------      -----------
-   client 1  -----------  ->  |server 3|  ->  |   ...   |    host
-             |   IPv4  |      ----------                     not using
-             -----------                                     anytun
-             |   ...   |       anycast
-                                              *changed source address
-                                               or port
-
-                                 Figure 2
-
-   In open tunnel mode only one of two clients talking to each other
-   over the servers MUST use the anytun protocol.  When a client using
-   the anytun protocol wants to tunnel data, it is building a connection
-   to the anycast servers using the anytun protocol.  The anycast
-   servers relay the encapsulated packages directly to the destination
-   without using the anytun protocol.  The source address of the
-   datagramm HAS TO be changed to the anycast address of the server.
-   The anytun servers act like a source NAT router, therefor for the
-   destination it saems that it is talking to the client directly.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 5]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-2.1.3.  relay mode
-
-   An example of anytun used in relay mode
-
-             -----------
-   -----     |   RTP   |      ----------
-   |   |  -> -----------  ->  |server 1|  ->
-   -----     |   UDP** |      ----------      -----------
-   #####     -----------                      |   RTP   |
-             |   IPv6**|      ----------      -----------     -----
-   host      -----------  ->  |server 2|  ->  |   UDP*  |  -> |   |
-   not using |   ...   |      ----------      -----------     -----
-   anytun                                     |   IPv6* |     #####
-                              ----------      -----------
-             -----------  ->  |server 3|      |   ...   |    host
-   -----     |  anytun |      ----------                     not using
-   |   |  -> -----------                                     anytun
-   -----     |   IPv4  |       anycast
-   #####     -----------
-   connection|   ...   |
-   controller
-
-    *changed source address or port
-    **changed destination address or port
-
-                                 Figure 3
-
-   In relay mode the anycast serveres directly repaet the packetes of
-   clients, only the source and destination addresses are changed.  The
-   anytun protocol is only used for controll messages, but not fr
-   encapsulation.
-
-2.2.  Transport modes
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 6]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-2.2.1.  anycast udp mode
-
-   An example of anytun used with udp transport
-
-             -----------                      -----------
-             |   RTP   |      ----------      |   RTP   |
-             -----------  ->  |server 1|  ->  -----------
-             |   UDP   |      ----------      |   UDP   |
-             -----------                      -----------
-   -----     |   IPv6  |      ----------      |   IPv6  |     -----
-   |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
-   -----     |  anytun |      ----------      |  anytun |     -----
-   #####     -----------                      -----------     #####
-             |   UDP   |      ----------      |   UDP   |
-   client 1  -----------  ->  |server 3|  ->  -----------     client 2
-             |   IPv4  |      ----------      |   IPv4  |
-             -----------                      -----------
-             |   ...   |       anycast        |   ...   |
-
-                                 Figure 4
-
-   In anycast udp mode the data between clients and anycast serveres is
-   carried by udp packets.  Packets are routed by the serveres from one
-   client to another.  Because udp is stateless no inforamtion has to be
-   syncronised
-
-2.2.2.  anycast light udp mode
-
-   An example of anytun used with udp transport
-
-             -----------                      -----------
-             |   RTP   |      ----------      |   RTP   |
-             -----------  ->  |server 1|  ->  -----------
-             |   UDP   |      ----------      |   UDP   |
-             -----------                      -----------
-   -----     |   IPv6  |      ----------      |   IPv6  |     -----
-   |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
-   -----     |  anytun |      ----------      |  anytun |     -----
-   #####     -----------                      -----------     #####
-             |lightUDP |      ----------      |lightUDP |
-   client 1  -----------  ->  |server 3|  ->  -----------     client 2
-             |   IPv4  |      ----------      |   IPv4  |
-             -----------                      -----------
-             |   ...   |       anycast        |   ...   |
-
-                                 Figure 5
-
-   The light UDP mode is neerly the same as the normal UDP mode, the
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 7]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-   only difference is, that the udp size is set to the udp header lenght
-   and not to the length of the full packet and therefor the checksum is
-   only calculated for the udp header itself.  So there is no error
-   correction or detection done on the payload.  This can be usefull if
-   realtime data is beeing transimittet or the tunneled protocol does
-   error correction/detection by itself.
-
-2.2.3.  Protocol specification
-
-2.2.3.1.  Header format
-
-2.2.3.2.  Protocol field
-
-   The protocol field defines the payload protocol.  ETHER TYPE protocol
-   numerbers are used. http://www.iana.org/assignments/ethernet-numbers
-   .  The values 0000-05DC are reserverd and not used at the moment.
-
-   Some exmples for protocol types
-
-   HEX
-   0000 Reserved
-   .... Reserved
-   05DC Reserved
-   0800 Internet IP (IPv4)
-   6558 transparent ethernet bridging
-   86DD IPv6
-
-                                 Figure 6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 8]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-Appendix A.  The appan
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 9]
-
-Internet-Draft           Anycast stream relaying              March 2007
-
-
-3.  References
-
-   [1]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
-        RFC 3068, June 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007              [Page 10]
-
-Internet-Draft           Anycast 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 11]
-
-Internet-Draft           Anycast 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 12]
-