protokoll umbenannt

1 files changed, 0 insertions, 672 deletions

diff --git a/internet-draft-anytun.txt b/internet-draft-anytun.txt
deleted file mode 100644
index e61e7ca..0000000
--- a/internet-draft-anytun.txt
+++ /dev/null
@@ -1,672 +0,0 @@
-
-
-
-Network Working Group                                         O. Gsenger
-Internet-Draft                                                March 2007
-Expires: September 2, 2007
-
-
-                  anycast tunneling and relay protocol
-                     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 tunneling and relay protocol        March 2007
-
-
-Abstract
-
-   The anycast tunneling and relay protocol (anytun) defines a protocol
-   used for communication between unicast clients and anycast servers.
-   It can be used for tunneling information between 2 clients over the
-   anycast servers or in relay mode to transmit data form the client
-   over the anycast servers to a third party not using the protocol and
-   vice versa.  Unlike other tunneling protocols like GRE or IPIP
-   tunnels which indeed will work with anycast as well, anytun directly
-   includes cryptography and authentication.  In relay mode it also
-   supports source NAT with integrated NAT transversal.  It is intended
-   to deliver a high performance and reliability solution for tunneling
-   and relaying of data over servers, where direct client to client
-   connections are not possible or not wanted.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 2]
-
-Internet-Draft    anycast tunneling and relay protocol        March 2007
-
-
-1.  Introduction
-
-   anytun defines a Host Anycast Service as defined in rfc1546.  It uses
-   a peer-to-peer achitecture, with anycast servers and unicast clients.
-   It can be used to build high scalable and redundant tunnel services.
-   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 tunneling and relay protocol        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.  Usage scenarions
-
-2.1.1.  tunneling from unicast client over anycast servers to unicast
-        client
-
-   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 tunneling and relay protocol        March 2007
-
-
-2.1.2.  tunneling from client to a server connected network
-
-   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.
-
-2.2.  Transport modes
-
-   Anytun does not define wich lower layer protocols HAVE TO be used,
-   but it's most likely used on top of udp.  This section should only
-   discuss some issues on udp in combination with anycasting and
-   tunnels.
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 5]
-
-Internet-Draft    anycast tunneling and relay protocol        March 2007
-
-
-2.2.1.  Using UDP
-
-   An example of anytun used with udp as 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 3
-
-   When using UDP no flow controll or retransmission is done, neigther
-   by UDP nor anytun.  The encapsulated protocol HAS TO take care of
-   this tasks if needed.  UDP however has a checksum of the complete udp
-   datagram, so a packet gets discarded if there is a biterror in the
-   payload
-
-2.2.2.  Using lightUDP
-
-   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 4
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 6]
-
-Internet-Draft    anycast tunneling and relay protocol        March 2007
-
-
-   The difference between normal UDP and lightUDP is, that the udp size
-   is not set to the length of the full packet, but to the lenght of the
-   data used for the checksum and therefor the checksum is only
-   calculated for that part.  When using lightUDP, the lenght HAS tO be
-   set to the udp header length + the anytun header lenght.  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.  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 encapsulated protocol can do a retransmission and all
-   fragments will arrive at the new server.
-
-2.3.  Protocol specification
-
-2.3.1.  Header format
-
-   Protocol Format
-
-        0                   1                   2                   3
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |V=2|   ????????????????????    |       sequence number         | |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | |    payload lenght             |      payload type             | |
-   | |-------------------------------+-------------------------------| |
-   | |              ....        payload        ...                   | |
-                                     +-------------------------------+ |
-   | |                               |       padding (OPTIONAL)      | |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   | ~                          MKI (OPTIONAL)                       ~ |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   | :                 authentication tag (RECOMMENDED)              : |
-   | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
-   |                                                                   |
-   +- Encrypted Portion*                      Authenticated Portion ---+
-
-                                 Figure 5
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 7]
-
-Internet-Draft    anycast tunneling and relay protocol        March 2007
-
-
-2.3.2.  payload type 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 tunneling and relay protocol        March 2007
-
-
-Appendix A.  The appan
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gsenger                 Expires September 2, 2007               [Page 9]
-
-Internet-Draft    anycast tunneling and relay protocol        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 tunneling and relay protocol        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 tunneling and relay protocol        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]
-