internet-draft-anytun.txt

   1
   2
   3
   4 Network Working Group                                         O. Gsenger
   5 Internet-Draft                                                March 2007
   6 Expires: September 2, 2007
   7
   8
   9                         Anycast stream relaying
  10                      draft-gsenger-anycast-relay-00
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt.
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html.
  34
  35    This Internet-Draft will expire on September 2, 2007.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The IETF Trust (2007).
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Gsenger                 Expires September 2, 2007               [Page 1]
  56 \f
  57 Internet-Draft           Anycast stream relaying              March 2007
  58
  59
  60 Abstract
  61
  62    The anycast tunneling (anytun) protocol defines a protocol used for
  63    communication between unicast clients and anycast servers.  It can be
  64    used for tunneling information between 2 clients over the servers or
  65    in relay mode to transmit data form the client over the servers to a
  66    third party not using the protocol and vice versa.
  67
  68
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Gsenger                 Expires September 2, 2007               [Page 2]
 112 \f
 113 Internet-Draft           Anycast stream relaying              March 2007
 114
 115
 116 1.  Introduction
 117
 118    anytun defines a Host Anycast Service as defined in rfc1546.  It can
 119    be used to build high scalable and redundant tunnel services.  It
 120    supports both UDP and TCP connections.  Additionally to the
 121    possibility of establashing an unicast TCP connection over an anycast
 122    address as suggested in rfc1546, it supports real anycast TCP
 123    connections with state syncronisation and heuristic state forecast.
 124    It also has a relay mode, that makes it possible, that only one of
 125    the connection endpoints has to use the anytun protocol.  This can be
 126    used to make connections through Firewalls or behind a NAT Router
 127
 128    RFC3068 [1] DTD.
 129
 130
 131
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Gsenger                 Expires September 2, 2007               [Page 3]
 168 \f
 169 Internet-Draft           Anycast stream relaying              March 2007
 170
 171
 172 2.  Operation modes
 173
 174    This section gives an overview of possible operation modes und usage
 175    scenarios.  Please note, that the protocols used in the figures are
 176    only examples and that anytun itself does not care about either
 177    transport protocols or encapsulated protocols.  Routing and network
 178    address translation is not done by anytun.  Each implemetation MAY
 179    choose it's own way of doing this task (e.g. using functions provided
 180    by the operating system).  Anytun is used to establish and controll
 181    tunnnels, to encapsulate and encrypt data.
 182
 183 2.1.  Tunnel modes
 184
 185 2.1.1.  Tunneling Mode
 186
 187    An example of anytun used in tunnel mode
 188
 189              -----------                      -----------
 190              |   RTP   |      ----------      |   RTP   |
 191              -----------  ->  |server 1|  ->  -----------
 192              |   UDP   |      ----------      |   UDP   |
 193              -----------                      -----------
 194    -----     |   IPv6  |      ----------      |   IPv6  |     -----
 195    |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
 196    -----     |  anytun |      ----------      |  anytun |     -----
 197    #####     -----------                      -----------     #####
 198              |   UDP   |      ----------      |   UDP   |
 199    client 1  -----------  ->  |server 3|  ->  -----------     client 2
 200              |   IPv4  |      ----------      |   IPv4  |
 201              -----------                      -----------
 202              |   ...   |       anycast        |   ...   |
 203
 204                                  Figure 1
 205
 206    In tunneling mode the payload of the anytun packet is transmitted
 207    from one unicast host to the anycast server.  This server makes a
 208    routing descision based on the underlying protocol and transmits a
 209    new anytun package to one or more clients depending on the routing
 210    descition.  The server MAY also route the packet to a directly
 211    connected network or a service running on the server, but please
 212    note, that this is only usefull for anycast host services like DNS
 213    and that the services HAVE TO be running on all servers in order to
 214    work.
 215
 216
 217
 218
 219
 220
 221
 222
 223 Gsenger                 Expires September 2, 2007               [Page 4]
 224 \f
 225 Internet-Draft           Anycast stream relaying              March 2007
 226
 227
 228 2.1.2.  Open tunnel mode
 229
 230    An example of anytun used in open tunnel mode
 231
 232              -----------
 233              |   RTP   |      ----------
 234              -----------  ->  |server 1|  ->
 235              |   UDP   |      ----------      -----------
 236              -----------                      |   RTP   |
 237    -----     |   IPv6  |      ----------      -----------     -----
 238    |   |  -> -----------  ->  |server 2|  ->  |   UDP*  |  -> |   |
 239    -----     |  anytun |      ----------      -----------     -----
 240    #####     -----------                      |   IPv6* |     #####
 241              |   UDP   |      ----------      -----------
 242    client 1  -----------  ->  |server 3|  ->  |   ...   |    host
 243              |   IPv4  |      ----------                     not using
 244              -----------                                     anytun
 245              |   ...   |       anycast
 246                                               *changed source address
 247                                                or port
 248
 249                                  Figure 2
 250
 251    In open tunnel mode only one of two clients talking to each other
 252    over the servers MUST use the anytun protocol.  When a client using
 253    the anytun protocol wants to tunnel data, it is building a connection
 254    to the anycast servers using the anytun protocol.  The anycast
 255    servers relay the encapsulated packages directly to the destination
 256    without using the anytun protocol.  The source address of the
 257    datagramm HAS TO be changed to the anycast address of the server.
 258    The anytun servers act like a source NAT router, therefor for the
 259    destination it saems that it is talking to the client directly.
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Gsenger                 Expires September 2, 2007               [Page 5]
 280 \f
 281 Internet-Draft           Anycast stream relaying              March 2007
 282
 283
 284 2.1.3.  relay mode
 285
 286    An example of anytun used in relay mode
 287
 288              -----------
 289    -----     |   RTP   |      ----------
 290    |   |  -> -----------  ->  |server 1|  ->
 291    -----     |   UDP** |      ----------      -----------
 292    #####     -----------                      |   RTP   |
 293              |   IPv6**|      ----------      -----------     -----
 294    host      -----------  ->  |server 2|  ->  |   UDP*  |  -> |   |
 295    not using |   ...   |      ----------      -----------     -----
 296    anytun                                     |   IPv6* |     #####
 297                               ----------      -----------
 298              -----------  ->  |server 3|      |   ...   |    host
 299    -----     |  anytun |      ----------                     not using
 300    |   |  -> -----------                                     anytun
 301    -----     |   IPv4  |       anycast
 302    #####     -----------
 303    connection|   ...   |
 304    controller
 305
 306     *changed source address or port
 307     **changed destination address or port
 308
 309                                  Figure 3
 310
 311    In relay mode the anycast serveres directly repaet the packetes of
 312    clients, only the source and destination addresses are changed.  The
 313    anytun protocol is only used for controll messages, but not fr
 314    encapsulation.
 315
 316 2.2.  Transport modes
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Gsenger                 Expires September 2, 2007               [Page 6]
 336 \f
 337 Internet-Draft           Anycast stream relaying              March 2007
 338
 339
 340 2.2.1.  anycast udp mode
 341
 342    An example of anytun used with udp transport
 343
 344              -----------                      -----------
 345              |   RTP   |      ----------      |   RTP   |
 346              -----------  ->  |server 1|  ->  -----------
 347              |   UDP   |      ----------      |   UDP   |
 348              -----------                      -----------
 349    -----     |   IPv6  |      ----------      |   IPv6  |     -----
 350    |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
 351    -----     |  anytun |      ----------      |  anytun |     -----
 352    #####     -----------                      -----------     #####
 353              |   UDP   |      ----------      |   UDP   |
 354    client 1  -----------  ->  |server 3|  ->  -----------     client 2
 355              |   IPv4  |      ----------      |   IPv4  |
 356              -----------                      -----------
 357              |   ...   |       anycast        |   ...   |
 358
 359                                  Figure 4
 360
 361    In anycast udp mode the data between clients and anycast serveres is
 362    carried by udp packets.  Packets are routed by the serveres from one
 363    client to another.  Because udp is stateless no inforamtion has to be
 364    syncronised
 365
 366 2.2.2.  anycast light udp mode
 367
 368    An example of anytun used with udp transport
 369
 370              -----------                      -----------
 371              |   RTP   |      ----------      |   RTP   |
 372              -----------  ->  |server 1|  ->  -----------
 373              |   UDP   |      ----------      |   UDP   |
 374              -----------                      -----------
 375    -----     |   IPv6  |      ----------      |   IPv6  |     -----
 376    |   |  -> -----------  ->  |server 2|  ->  -----------  -> |   |
 377    -----     |  anytun |      ----------      |  anytun |     -----
 378    #####     -----------                      -----------     #####
 379              |lightUDP |      ----------      |lightUDP |
 380    client 1  -----------  ->  |server 3|  ->  -----------     client 2
 381              |   IPv4  |      ----------      |   IPv4  |
 382              -----------                      -----------
 383              |   ...   |       anycast        |   ...   |
 384
 385                                  Figure 5
 386
 387    The light UDP mode is neerly the same as the normal UDP mode, the
 388
 389
 390
 391 Gsenger                 Expires September 2, 2007               [Page 7]
 392 \f
 393 Internet-Draft           Anycast stream relaying              March 2007
 394
 395
 396    only difference is, that the udp size is set to the udp header lenght
 397    and not to the length of the full packet and therefor the checksum is
 398    only calculated for the udp header itself.  So there is no error
 399    correction or detection done on the payload.  This can be usefull if
 400    realtime data is beeing transimittet or the tunneled protocol does
 401    error correction/detection by itself.
 402
 403 2.2.3.  Protocol specification
 404
 405 2.2.3.1.  Header format
 406
 407 2.2.3.2.  Protocol field
 408
 409    The protocol field defines the payload protocol.  ETHER TYPE protocol
 410    numerbers are used. http://www.iana.org/assignments/ethernet-numbers
 411    .  The values 0000-05DC are reserverd and not used at the moment.
 412
 413    Some exmples for protocol types
 414
 415    HEX
 416    0000 Reserved
 417    .... Reserved
 418    05DC Reserved
 419    0800 Internet IP (IPv4)
 420    6558 transparent ethernet bridging
 421    86DD IPv6
 422
 423                                  Figure 6
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Gsenger                 Expires September 2, 2007               [Page 8]
 448 \f
 449 Internet-Draft           Anycast stream relaying              March 2007
 450
 451
 452 Appendix A.  The appan
 453
 454
 455
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503 Gsenger                 Expires September 2, 2007               [Page 9]
 504 \f
 505 Internet-Draft           Anycast stream relaying              March 2007
 506
 507
 508 3.  References
 509
 510    [1]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
 511         RFC 3068, June 2001.
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Gsenger                 Expires September 2, 2007              [Page 10]
 560 \f
 561 Internet-Draft           Anycast stream relaying              March 2007
 562
 563
 564 Author's Address
 565
 566    Othmar Gsenger
 567    Sporgasse 6
 568    Graz  8010
 569    AT
 570
 571    Phone:
 572    Email: otti@wirdorange.org
 573    URI:   http://anytun.org/
 574
 575
 576
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615 Gsenger                 Expires September 2, 2007              [Page 11]
 616 \f
 617 Internet-Draft           Anycast stream relaying              March 2007
 618
 619
 620 Full Copyright Statement
 621
 622    Copyright (C) The IETF Trust (2007).
 623
 624    This document is subject to the rights, licenses and restrictions
 625    contained in BCP 78, and except as set forth therein, the authors
 626    retain all their rights.
 627
 628    This document and the information contained herein are provided on an
 629    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 630    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 631    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 632    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 633    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 634    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 635
 636
 637 Intellectual Property
 638
 639    The IETF takes no position regarding the validity or scope of any
 640    Intellectual Property Rights or other rights that might be claimed to
 641    pertain to the implementation or use of the technology described in
 642    this document or the extent to which any license under such rights
 643    might or might not be available; nor does it represent that it has
 644    made any independent effort to identify any such rights.  Information
 645    on the procedures with respect to rights in RFC documents can be
 646    found in BCP 78 and BCP 79.
 647
 648    Copies of IPR disclosures made to the IETF Secretariat and any
 649    assurances of licenses to be made available, or the result of an
 650    attempt made to obtain a general license or permission for the use of
 651    such proprietary rights by implementers or users of this
 652    specification can be obtained from the IETF on-line IPR repository at
 653    http://www.ietf.org/ipr.
 654
 655    The IETF invites any interested party to bring to its attention any
 656    copyrights, patents or patent applications, or other proprietary
 657    rights that may cover technology that may be required to implement
 658    this standard.  Please address the information to the IETF at
 659    ietf-ipr@ietf.org.
 660
 661
 662 Acknowledgment
 663
 664    Funding for the RFC Editor function is provided by the IETF
 665    Administrative Support Activity (IASA).
 666
 667
 668
 669
 670
 671 Gsenger                 Expires September 2, 2007              [Page 12]
 672 \f