AYIYA: Anything In Anything

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

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 () 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.

The AYIYA protocol is put inside the data part of either UDP , TCP or SCTP 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. | Server | +--------+ +--------+ ]]>

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 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 order.

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.

As the server will disable the tunnel after it has not received a 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.

The protocol presented has formed during the existence of 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 protocol.

The password used 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 connectivity is interrupted.

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.

(1) = src = 10.10.0.1:1234, dst = 192.0.2.42:3740 (2) = src = 192.0.2.5:4321, dst = 192.0.2.42:3740 (3) = src = 10.10.9.2:7890, dst = 192.0.2.42:3740 (4) = src = 192.0.2.5:5678, dst = 192.0.2.42:3740 Note that TEST-NET addresses could never reach a Tunnel Server over the public Internet due to filtering of this documentation prefix.