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 NATs 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 cannot 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 NATs are used or when the user has no control at all over the NAT setup. This is an undesired situation as it limits the deployment of IPv6 , which was meant to solve the problem of the disturbance in end to end communications caused 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 separate endpoints could be behind the same NAT and/or that the public endpoint can change on the fly, there is also a need to identify the endpoint that certain packets are coming from and endpoints need to be able to change e.g. source addresses of the transporting protocol on the fly while still being identifiable as the same endpoint. The protocol described in this document is independent of the transport and payload's protocol. An examples could be IPv6-in-UDP-in-IPv4, which is a typical setup that can be used by IPv6 Tunnel Brokers . This document does not describe how to determine the identity, signature type or the inner and outer protocols. These should be negotiated manually or automatically by e.g. using TSP or a relevant protocol which is capable of describing the configuration parameters of AYIYA tunnels. Seperate documents for the configuration protocols supporting AYIYA should include the details on how this is done. Additionally this document describes how AYIYA could be used in both a multihoming and in a mobility scenario.

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. | Receiver | +--------+ +----------+ ]]>

The AYIYA protocol has a header with 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDLen | IDType| SigLen|HshMeth|AutMeth| OpCode| Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Epoch Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Identity : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Signature : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All fields are in network byte order (Big Endian). The base AYIYA header without an identity or signature is 8 bytes.

The IDLen (Identity Length) Field defines the length of the Identity Field in a power of 2 in octets. e.g. a Lenght of 4 is 2^4 = 16 bytes.

The Identity Type specifies what kind of Identity is included in the header. The Idenity field is used by the receiver to determine which sender sent the packet, this is done as there is an assumption that the source endpoint, the source IP address or the source port, may change arbitrarily which will be the case when the sender is behind a NAT, using DHCP, PPP or using IPv6 privacy extensions and thus has a changing address. Even though the endpoint is suspectible to change, the Identity will remain the same unless negotiated otherwise. Currently defined Identity types are: - 0x0 None - 0x1 Integer - 0x2 ASCII string Types 0x3 till 0xf are reserved for future usage. The type of identity used by an AYIYA tunnel is negotiated either manually or automatically outside this protocol, these fields are included to allow verification of the type and also to allow multiple types to be used by one receiver at the same time. ASCII strings are NULL padded when they do not fill the complete identity field. The types are multifunctional, e.g. type 0x01 could contain an IPv4 address when the length of the identity is 0x2 or could contain an IPv6 address when the length is 0x4. A string could contain DNS names. The exact content of the Identity Field is defined by the users of this protocol and out of scope of this document. If the Identity Type is None, the Identity Field is absent from the packet. The Signature Field, if present, will then directly follow the Epoch Time Field. In case the Signature Field is not present the payload will directly follow the Epoch Time field. The Identity Length Field must be 0 in this case.

The SigLen describes the length of the hash and is specified in octets divided by four. e.g. a SigLen of 3 means the signature is 12 bytes long, a SigLen of 15 means that the Signature is 60 bytes long. The protocol thus allows for a maximum signature of 480 bits.

The HshMeth (Hashing Method) bits describe the type of the Hashing Method used to create the signature of the packet. By hashing the complete packet we can verify that the packet did not change during transit between sender and receiver. Currently defined Hashing Methods are: - 0x0 No hash - 0x1 MD5 - 0x2 SHA1 As there are known collisions for MD5 it is advised to use SHA1 as a default Hashing Method. Hashing Methods 0x3 to 0xf are reserved for future usage. When the Hashing Method is 0x0, AuthMeth and SigLen MUST also be set to 0 and the packet doesn't include a Signature, the payload, defined by the Next Header, then directly follows the Identity field, which may also be absent depending on it's type.

AuthMeth (Authentication Method) describes the type of the Authentication Method. By authenticating the packet we can verify that the sender really originated from the sender, of course assuming that the Authentication Method has not been compromised. The AYIYA protocol doesn't have any options for encryption. Encryption can be done in the payload. The currently defined Authentication Methods are: - 0x0 No authentication - 0x1 Hash using a Shared Secret - 0x2 Hash using a public/private key method Authentication Methods 0x3 to 0xf are reserved for future usage. In the case where an implementation does not support or expect the received Identity or Signature Type (e.g. because it was configured for a different type) it MUST silently discard the packet. The user may be notified of this event.

The Operation Code can request special operation on the packet. Currently - 0x0 No Operation / Heartbeat - 0x1 Forward - 0x2 Echo Request - 0x3 Echo Request and Forward - 0x4 Echo Response The No Operation OpCode allows the packet to be used for updating the latest received time, see the next section for the rationale why this packet is also dubbed a Heartbeat Packet. The Forward OpCode specifies that this is a normal packet which is to be forwarded. The Echo Request OpCode requests that the payload is echoed back to the sender, the OpCode of the returned packet should then be set to Echo Response. The payload of the Echo Request packet MUST NOT be forwarded. When the OpCode is set to Echo Request and Forward then the packet must be echoed back to the sender and also forwarded as a normal packet. This allows the Heartbeat functionality, as discussed in the next chapter, to be integrated into the normal packet stream. It can also be used to ensure that a packet is delivered to the other end of the tunnel. Values 0x3 till 0xf are reserved for future extensions.

The Next Header, like in IPv6, contains the protocol value of the payload following the AYIYA Packet Header. There is no length field as that can be deduced from the protocol that is carrying this packet.

Epoch Time is the time in seconds since "00:00:00 1970-01-01 UTC". Both the sender and the receiver are advised to be synchronized using NTP to make sure that their clocks clocks do not differ too much even after travelling the intermediate networks between the sender and the receiver. The number of seconds since the above date are stored in a 32 bit unsigned integer in network byte order. The Epoch Time is included to be able to guard against replay attacks. See the Security Considerations section for more details.

The Epoch Time will loop in 2038 when the 32 bit unsigned integer reaches it's maximum value. This will cause that the difference between the two times is larger than the advised timeout time even though the difference is not that big. To avoid a service interruption, because the time in the packet is not inside the limits of the clock shift time, every implementation MUST handle times in the range (0-timeout)..0 specially and compensate the loop, e.g. by shifting away from the looptime. Typical C code which handles the verification of the epochtime is included as an example: = -CLOCK_OFF) || (epochtime >= -CLOCK_OFF)) { // Shift the times out of the loop range i = (curr_time + (CLOCK_OFF*2)) - (epochtime + (CLOCK_OFF*2)); } else i = curr_time - epochtime; // The clock may be faster, thus flip the sign if (i < 0) i = -i; // Compare the clock offset if (i > CLOCK_OFF) { // Time is off, silently drop the packet return false; } // Time is in the allowed range return true; } ]]> Theory for the above: for simplicity let's assume the loop is around 10000. Sender sends an epochtime of 9990, but the receiver's time is at 10 already, thus we apply the shift and the times become: (9990 + 240)%10000 = 230 and (10 + 240)%10000 = 250 the difference !(250 - 230) is 20, which is in the allowed clock_off range. If we didn't apply this compensation the difference would have been !(10 - 9990) = 9980 seconds which would mean the packet would have been dropped even though the packets time is valid.

As the receiver will disable the tunnel after it has not received a packet from the sender after a configured time the sender should send packets to the other side of the tunnel with the Next Header field set to 59 (No Next Header) but the payload may contain data which is private to the implementation. The implementation could include a sequence number in the payload like is common with ICMP echo packets. The receiver will reply on reception of this packet returning the exact payload the sender transmitted allowing the sender to compare the information and deduce latency information and other statistical information from it using the implementation specific data contained in the payload. This packet allows the sender to test the tunnel's functionality. If the signature is not correct, either because of the wrong shared secret, wrong hash, wrong identity or connectivity problems, the sender will not get a reply and could notify the user of this situation. Senders should send these packets once per 60 seconds as the receiver is usually configured to disable the tunnel after it has received no packets for a timeout time of 120 seconds. An implementation could choose to not send the heartbeat packet when it has already sent a packet in the last 60 seconds thus avoiding a small overhead in transmission and processing of these extra heartbeat packets. Receivers MUST handle every correctly verified packet as the last received one. A side effect of this Heartbeat Packet is that a NAT will update it's mappings and keep the same source/destination ports in cases where AYIYA is encapsulated inside UDP, for instance. An implementation could choose to not send any heartbeat packets, but this will cause the connecitivity, provided by the tunnel, to be interrupted until the sender sends a packt again.

When there is no Hashing there neither is no signing of the packet and the header won't include a Signature. If a received packet contains flags that the packet contains a hash or that the packet contains an authentication then the receiver must verifiy that the signature provided is correct by following the same procedure as taken by the sender and comparing the results of the signatures. When the signatures match the packet can be processed further. When the signatures do not match the receiver MUST silently ignore the packet and may notify the user.

When there is no Authentication we create the signature of the packet by initializing the signature of the packet to NULL. The rest of the fields and the payload should also be initialized as to be sent over the wire. The signature is then made over the complete packet using the Hashing Method defined by the type. Thus over the AYIYA header and the payload. This method allows verification that the packet has not been incidentally mangled along it's route to the receiver. It does not provide any security or authenticity that the packet has been forcefully mangled.

To create the signature of the packet, the Signature Field MUST be set to the signature of the shared secret, this signature is made using the same hashing method as the one specified in the Signature Type Field. The signature is then made over the complete packet, thus the AYIYA header and the payload. By hashing the shared secret we allow shared secrets of arbitrary lengths to be used. Which shared secret is used is out of scope of this document and this should be described by manual or automatic configuration documents which should describe the definition of the shared secret. The result is stored in the Signature field, which contains the signature of the shared secret while hashing. Implementations could precache the hashed shared secret and would thus not require the knowlegde of the real shared secret. This method thus allows verification that the packet has not been modified along it's path from sender to receiver and also allows verification that the sender or receiver, who should be the only parties knowning the shared secrets, where the originators of this packet. This withouth sending the shared secret over the network.

The Signature Field of the header is initialized to NULL. The rest of the fields and the payload should also be initialized as to be sent over the wire. A hash defined by the HshMeth Field is then calculated over the complete packet. After that the Public / Private Key signature is calculated, the result of which is stored in the Signature Field.

Some of the Identity Types could represent an IPv4 or IPv6 address or a hostname. Using normal (reverse) DNS lookup procedures the additional properties relating to these identities can then also be found out using DNS. These properties could be altnerate endpoint addresses, pointers to home agents or public keys. This can be used for the multihoming and mobility scenarios to bootstrap the initial connection. When a receiver receives the first packet from a, upto then unknown identity, it could lookup the identities additional properties like it's public key to be able to authenticate the received packet.

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 the natural successor of the combination of the proto-41 tunneling protocol and the SixXS Heartbeat protocol. Thanks to Christian Strauf, Brian Carpenter and Pim van Pelt for valuable comments which improved this document and therefore the protocol a lot.

The shared secret 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 would enable a 3rd party to send traffic in both directions and thus posing as the actual user. The inclusion of the Epoch Time along with the verification on the receiver side should guard against replay attacks. The receiver MUST ensure that the time difference between local clock and the epochtime never differ for more than 60 seconds. This allows for a tolerance of latency and time-shifts. Note that the Epoch Time doesn't guard against resending of the same packet. A solution could be to add a sequence number in the AYIYA protocol but that would overcomplicate the receivers as they would need to keep state and even re-order packets, which is something that is not wanted with a protocol that is built to allow packets to drop. Upper layer protocols should have protection mechanisms against this. e.g. TCP has it's own sequence numbering. Any packet that is not well formed or contains a invalid signature MUST be silently dropped, appropriate logging may be done of these issues but in that case a rate limit 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 would then go to the spoofed source address. As a side effect of this protocol, when a sender can not or does not send a packet in time, the tunnel is detected as defunct and the receiver will dispose of it. This could be the case when the sender's connectivity is interrupted. Disposition of the tunnel will also make sure that no packets will be forwarded over the tunnel to an endpoint which might not be expecting this kind of traffic as it is not the host that heartbeated the last time. This situation could arise for instance when DHCP changes the endpoint address or a host which dials into a PPP pool disconnects, after which the next dialin, by another host receives the former hosts endpoint address. This document specifies a tunneling protocol which can circumvent administrative policies implied by a firewall. This firewall can prohibit the communication between sender and reciever. If such a policy is in place, then that is an administrative policy which should not be tried to be circumvented. Using tunneling in general opens up a new hole into a network which might be used for gaining access into that network. When and one or both of the outer addresses is a address, any process that receives the AYIYA packets can still make the relation to that single host as the Identity in the AYIYA packet doesn't change. The limited privacy effect of RFC3041 is thus removed in this case.

As AYIYA is a generic tunneling protocol it can be used in many different scenario's amongst which the scenarios described in this section. Note that TEST-NET addresses used in the scenarios could never reach a Tunnel Server over the public Internet due to filtering of these documentation prefixes.

The main scenario where AYIYA is intended to be used is for solving the problem where a IPv4 host is behind a NAT and wants to tunnel to a Tunnel Server . As many NAT's don't support forwarding protocol 41 or require manual configuration of the NAT, using AYIYA and encapsulating the AYIYA packet including the payload inside IPv4 UPD is a good solution. The AYIYA packet includes an identity, thus the endpoint address of the client does not need to be known and the tunnel can be brought and kept up up at wish by the user when it's client notifies the Tunnel Server of it's existence by sending AYIYA packets. This type of tunnel will generally use a Identity Type of 0x3, the Identity Field will contain the IPv6 address of the endpoint of the tunnel from the direction where the packet is coming from, the Signature Type will be 0x2 (SHA-1).

The packet send over the wire will have the following format: This setup causes a per-packet overhead of: 20 (IPv4) + 8 (UDP) + 8+16+20 (AYIYA+Identity+Signature) = 72 bytes. This allows encapsulation of packets of 1428 bytes over Ethernet, which has a MTU of 1500 bytes. As the minimum MTU of IPv6 packets is 1280 bytes, any medium with at least an MTU of (1280 + 72 =) 1352 bytes can be used for AYIYA without having to fragment the packets.

This scenario demonstrates a typical situation where this protocol will mainly be used: tunneling to multiple endhosts behind a NAT. In this scenario the Tunnel Server acts as a receiver in server mode which does not initiate any tunneling as it does not know the source endpoint of the clients, which might change at arbitrary timepoints. In this scenario the server is assumed to have a static endpoint. The server does not send heartbeats to check connectivity, it is up to the client to send the heartbeats at the agreed regular intervals making sure the server does not dispose of the tunnel. This setup allows both clients behind the NAT to change their private IPv4 addresses and also allows the NAT to change its public IPv4 or source port numbers. The server will notice the changes of source IP or port numbers and can reconfigure its tunnel to send to the specific host:port combination for which a mapping will exist at the NAT and the packet can go through the NAT.

(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 AYIYA is capable of crossing any NAT. As an AYIYA Server uses the AYIYA port as the source port and the address that received the initial AYIYA packet from the client as a source address, Restricted Cone NATs, Port-Restricted Cone NATs and Symmetric NATs can be traversed. If the mapping would change the next packet coming from the client would update the host:port mapping on the Tunnel Server. The four main types of NAT's are described in the Teredo document.

This scenario would typically encapsulate AYIYA and the payload inside IPv4 and UDP. Schematically this would look like:

AYIYA can also be used as a tunneling protocol for solving multihoming problems. For instance the following packet could be crafted which encapsulates IPv6 inside IPv6. The encapsulated packet could contain a source/destination address which could be described as the identifiers of this multihoming protocol. The outer IPv6 addresses are the locators.

A typical Multihoming scenario. Site A is connected to the Internet using two independent upstream providers (Provider 1 and Provider 2). Every host inside Site A has two addresses, one from Provider 1 (2001:db8:1000::/48) and one from Provider 2 (2001:db8:2000::/48). Both upstream providers correctly filter egress traffic making sure that only source addresses assigned to Site A from their own address space is sent to the Internet, thus protecting against spoofing. The SiteRouters must thus make sure that only the correctly sourced packets are sent outward. Either the Host or the SiteRouters could support AYIYA, in the first case the SiteRouters MUST never do any additional AYIYA tunneling, this can be accomplished easily by checking that the IPv6 Next Header or IPv4 Protocol field doesn't contain the value mentioning that the next header is an AYIYA header. If this value is not set to be an AYIYA header, the SiteRouters MAY initiate AYIYA traffic to the remote host or site using their Site Identifiers. This allows host-host, host-site and also site-site multihoming. The hosts communicating with each other using this setup would need to agree on which identities, hashing, authentication methods and shared secrets or private/public keys they use. This is out of scope for this document.

The following figure depicts an example IPv6 TCP packet which is encapsulated using AYIYA inside IPv4 or IPv6 which demonstrates its protocol independency. The Next Header field of the outer IPv6 packet directly contains a IPv6 Next Header value of IANA:TBD. The Next Header field of the AYIYA Header contains the value of 41 (IPv6). The locators used are IPv4 or IPv6 addresses, while the identifiers and the actual protocol addresses that are being multihomed are IPv6. This scenario could allow a host to decide to start communicating with another host over IPv4 when an IPv6 route is not available or doesn't have the required properties, based on latency for instance. If the locator of a host changes, that host can directly send a heartbeat packet to the other host notifying that host of the change. The receiving host recognises the new locator as a valid source as the signature can be verified and sets it's outgoing packets to use this new endpoint. As the identifiers are encapsulated, existing connections or communications won't notice this change.

AYIYA could be used in a mobility situation for tunneling it's Home Address back to the Home Agent, thus acting as a normal tunnel situation and for the Remote Host it seems the communication is happening directly. In this case the remote host doesn't need to support AYIYA. When the Remote Host does support AYIYA, it could also directly setup a tunnel with the mobile host, circumventing that traffic is sent over the Home Agent. The Remote Host can determine if a host supports AYIYA by looking up properties in DNS and use a Public/Private Key algorithm to authenticate the packets without prior information, e.g. the keys, needing to be available. The following diagram illustrates this. | Home Agent | +-------------+ +------------+ ^ ^ | | AYIYA IPv4/IPv6 | | v v +-------------+ +-------------+ | Remote Host | | Remote Host | | + AYIYA | | | +-------------+ +-------------+ ]]> The exact mechanism for determining the public/private key and the identities used are out of scope for this document.

IANA will need to allocate a protocol number value for "AYIYA" allowing AYIYA packets to be directly encapsulated inside IPv4, IPv6 or possibly any other future protocols. IANA will need to allocate a port number in the case where AYIYA is used over UDP , TCP or SCTP or any other protocol supporting port numbers. A port number request has been made through normal port allocation procedures requesting a system port.