[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
IPv6 Operations                                                J. Massar
Internet-Draft                                               Unfix/SixXS
Expires: November 24, 2004                                  May 26, 2004

                      AYIYA: Anything In Anything

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 24, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


   This document defines a tunneling protocol that can be encapsulated
   in any other protocol. Using authentication tokens multiple tunnels
   can be created from behind the same NAT. The tokens allow one to
   identify the sender of the packet thus making it possible to
   automatically switch over the endpoint. This protocol is intended as
   an alternative to the proto-41 protocol in use for tunneling IPv6
   over IPv4 packets over the internet. Due to the authentication this
   protocol is especially useful for dynamic non-24/7 endnodes which are
   located      behind NATs and want to use for instance a IPv6 Tunnel
   Broker. The protocol can carry any payload and thus is not limited to
   only IPv6 over IPv4 but can also be used for IPv4 over IPv6 and many
   other combinations of protocols.

Massar                 Expires November 24, 2004                [Page 1]

Internet-Draft        AYIYA: Anything In Anything               May 2004

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  AYIYA Packet format  . . . . . . . . . . . . . . . . . . . . .  3
   4.  Heartbeat  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  6
   7.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1   Tunneling to multiple endhosts behind a NAT  . . . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9

Massar                 Expires November 24, 2004                [Page 2]

Internet-Draft        AYIYA: Anything In Anything               May 2004

1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Introduction

   Many users are currently located behind NAT's which prohibit the
   usage of proto-41 IPv6 in IPv4 tunnels unless they manually
   reconfigure their NAT setup which in some cases is impossible as the
   NAT can't be configured to forward proto-41 ([RFC1933]) to a specific
   host. There might also be cases when multiple endpoints are behind
   the same NAT, when multiple NAT's are used or when the user has no
   control at all on the NAT setup. This is a undesired situation as it
   limits the deployment of IPv6, which was meant to solve the problem
   of the disturbance in end to end communications by NATs, which where
   created because of limited address space, in the first place.

   This problem can be solved easily by tunneling the IPv6 packets over
   either UDP, TCP or even SCTP. Taking into consideration that multiple
   seperate endpoints could be behind the same NAT and/or that the
   public endpoint can change on the fly there is also a need to be able
   to identify packets as coming from a certain endpoint and to be able
   to automatically change the endpoint on the fly. The protocol
   described in this document is protocol independent and can be run
   over and also encapsulate any protocol. Examples are
   IPv6-in-UDP-in-IPv4, which is a typical setup which can be used by
   Tunnel Brokers.

   This protocol doesn't describe how to determine the identity,
   signature type or the inner and outer protocols. These should be
   negotiated manually or automatically by eg using TSP or a relevant
   protocol which is capable of describing ayiya tunnels.

3.  AYIYA Packet format

   The AYIYA protocol is put inside the data part of either UDP
   [RFC0768], TCP [RFC0793] or SCTP [RFC2960] which are the currently
   defined transport protocols, future transport protocols could also be
   used. The transport protocol can be run over both IPv4 or IPv6 or any
   other future protocol. Schematically this will look like the
   following diagram.

   +--------+                    +--------+
   | Client | <--- Internet ---> | Server |
   +--------+                    +--------+

Massar                 Expires November 24, 2004                [Page 3]

Internet-Draft        AYIYA: Anything In Anything               May 2004

   A complete on the wire packet will have the following format.

   |       Delivery Header         |
   |        IPv4/IPv6/...          |
   |       Transport Header        |
   |        TCP/UDP/SCTP/...       |
   |          AYIYA Header         |
   |        Payload packet         |

   The AYIYA protocol header and has the following 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
   | Identity Type | SignatureType |  Next Header  |   Reserved    |
   |                           Epoch Time                          |
   :                                                               :
   :                            Identity                           :
   :                                                               :
   :                                                               :
   :                            Signature                          :
   :                                                               :

   Epoch Time is the time in seconds since "00:00:00 1970-01-01 UTC".
   Both the client and the server are advised to be synchronized using
   NTP [RFC2030] to make sure that the system clocks of the hosts don't
   differ to much even after travelling the intermediate networks
   between the client and the server. The number of seconds since the
   above date are stored in a 32 bit unsigned integer in network byte

Massar                 Expires November 24, 2004                [Page 4]

Internet-Draft        AYIYA: Anything In Anything               May 2004

   The Identity Type specifies what kind of Identity is included in the
   header. Currently defined are:

    - 0x01  32 bit integer  (4 bytes)
    - 0x02  64 bit integer  (8 bytes)
    - 0x03 128 bit integer (16 bytes)
    - 0x04 256 bit integer (32 bytes)
    - 0x11   4 byte ASCII string
    - 0x12   8 byte ASCII string
    - 0x13  16 byte ASCII string
    - 0x14  32 byte ASCII string

   Other values are reserved. The kind of identity used by a tunnel is
   negotiated outside this protocol. ASCII strings are NULL padded if
   they don't fill the complete identity field.

   The Signature Type contains the kind of signature used by the
   protocol. Currently defined are:

    - 0x01 MD5  (128 bit - 16 bytes)
    - 0x01 SHA1 (160 bit - 20 bytes)

   The Next Header, like in IPv6, contains the protocol value of the
   payload following the Heartbeat Header. There is no length field as
   we can deduce that already from the protocol that is carrying this
   packet. A Next Header value of 0xffff is special, see the following
   Heartbeat section.

   The Reserved field is reserved and should be initialized to NULL.

   The signature field should contain the hash of the password specified
   for the identity in the same hashing method as to be used for hashing
   the packet itself. The signature is then made over the complete
   packet, thus the header and payload. By hashing the password we allow
   arbitrarily lenght passwords to be used. Implementations could choose
   to precache the hashed password and thus also requiring having the
   cleartext password. The packet, header and payload can then be sent
   to the server. This method thus allows verification of the password
   without sending the password over the network. The server does the
   same thing, taking the header part of the packet, adding the password
   and calculating the signature which can then be compared with the
   signature which was sent by the client. If these match the packet can
   be processed further. When the signatures don't match the server MUST
   silently ignore the packet.

4.  Heartbeat

   As the server will disable the tunnel after it has not received a

Massar                 Expires November 24, 2004                [Page 5]

Internet-Draft        AYIYA: Anything In Anything               May 2004

   packet from the client after a configured time the client should send
   packets to the other side of the tunnel with the Next Header field to
   0xffff, the payload should contain a 32 bit sequence number and may
   be filled with other informations. The server will reply this packet
   with the same payload allowing the client to compare the information
   and deduce latency information and other statistical information from
   it. This packet also allows the client to test if at least the tunnel
   to the server works. If the signature is not correct, either because
   of the wrong password, wrong hash, wrong identity or connectivity
   problems the client won't get a reply and could notify the client of
   this situation.

   Clients should send these packets once per 60 seconds as the server
   is usually configured to disable the tunnel after 120 seconds.

5.  Acknowledgements

   The protocol presented has formed during the existence of SixXS
   [SIXXS] to allow the users of the various tunnel servers provisioned
   by SixXS to have a dynamic non-static IPv4 endpoint which could even
   be located behind a NAT. This protocol is a combination of the
   proto-41 tunneling protocol and the additional SixXS Heartbeat

6.  Security Considerations

   The password used [RFC1321] must never be made publicly available to
   3rd parties otherwise that 3rd party could sign a packet and
   automatically reconfigure the tunnel endpoint. This could lead into
   the 3rd party sending traffic in both directions and thus posing as
   the actual user.

   The inclusion of the epochtime along with the verification on the
   Tunnel Server side should guard against any replay attacks. The
   Tunnel Server MUST limit that the local clock compared to the
   timestamp from the packet MUST never differ for more than 60 seconds,
   this allows for at least some latency and time-desync.

   Any packet that is not well formed or contains a invalid signature
   MUST be silently dropped, appropriate loggin may be done of these
   issues but in that case a ratelimit must be applied to not clutter
   the logs with these messages. Invalid signatures MUST be handled as
   possibly being spoofed, thus no packet MUST be sent back as these
   packets will then go to the spoofed address.

   A side effect of this protocol is that whenever the client host
   cannot or does not send a packet in time to the Tunnel Server that it
   will deconfigure the tunnel. This could be the case when the client's

Massar                 Expires November 24, 2004                [Page 6]

Internet-Draft        AYIYA: Anything In Anything               May 2004

   connectivity is interrupted.

7.  Scenarios

7.1  Tunneling to multiple endhosts behind a NAT

   This scenario demonstrates the scenario where this protocol will find
   it's main usage: tunneling to multiple endhosts behind a NAT. This
   setup allows both clients to change their private IPv4 addresses and
   also to allow the NAT to change it's public IPv4 and source port
   numbers. The server will notice the change of source IP and port
   numbers and can reconfigure it's tunnel to send to the specific
   host:port combination for which a mapping will exist at the NAT and
   the packet will go through the NAT, not considering firewalling
   effects. If firewalls are in place then that is an administrative
   policy which should not be tried to be circumvented.     NAT
   ,----------.  (1) | (2)  ,--------.
   | Client A |------|------|        |
   `----------'      |      | Tunnel |
   ,----------.      |      | Server |
   | Client B |------|------|        |
   `----------'  (3) | (4)  `--------'

   (1) = src =, dst =
   (2) = src =, dst =
   (3) = src =, dst =
   (4) = src =, dst =

   Note that TEST-NET [RFC3300] addresses could never reach a Tunnel
   Server over the public Internet due to filtering of this
   documentation prefix.

8  References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

Massar                 Expires November 24, 2004                [Page 7]

Internet-Draft        AYIYA: Anything In Anything               May 2004

   [RFC1933]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 1933, April 1996.

   [RFC2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L. and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3300]  Reynolds, J., Braden, R., Ginoza, S. and A. De La Cruz,
              "Internet Official Protocol Standards", RFC 3300, November

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [SIXXS]    Massar, J. and P. van Pelt, "SixXS - IPv6 Deployment &
              Tunnelbroker", <http://www.sixxs.net>.

Author's Address

   Jeroen Massar
   Hofpoldersingel 45
   Gouda  2807 LW

   EMail: jeroen@unfix.org
   URI:   http://unfix.org/~jeroen/

Massar                 Expires November 24, 2004                [Page 8]

Internet-Draft        AYIYA: Anything In Anything               May 2004

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an

Massar                 Expires November 24, 2004                [Page 9]

Internet-Draft        AYIYA: Anything In Anything               May 2004



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Massar                 Expires November 24, 2004               [Page 10]