Anything In Anything

From Wikipedia, the free encyclopedia

The five-layer TCP/IP model
5. Application layer

DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · BGP · (more)
4. Transport layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
3. Network/internet layer
IP (IPv4 · IPv6) · OSPF · IS-IS · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more)
2. Data link layer
802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more)
1. Physical layer
Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more)
This box: view • talk • edit

Anything In Anything or AYIYA is a draft tunneling protocol. The protocol addresses the following problems:

  • Tunneling of any protocol in any protocol
This is where the name is derived from
The tunneled packets should not be spoofable or replayable
  • NAT awareness
The tunnel should work over a NAT
The endpoint of at least one of the two hosts should be able to change

The draft itself covers the deep details on how this is accomplished and how the protocol works in detail. Below are some scenarios on how this protocol can be used to solve some problems.

Contents

[edit] Using AYIYA for Tunnel Brokers

Many users are currently located behind NATs which prohibit the usage of proto-41 IPv6 in IPv4 tunnels RFC 3056 unless they manually reconfigure their NAT setup. In some cases, this is impossible as the NAT cannot be configured to forward proto-41 RFC 1933 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 RFC 3513, which was meant to solve the problem of the disturbance in end to end communications caused by NATs, which were 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 example could be IPv6-in-UDP-in-IPv4, which is a typical setup that can be used by IPv6 Tunnel Brokers.

[edit] Using AYIYA for mobility

AYIYA could be used in a mobility situation for tunneling its 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.

+-------------+             +------------+         ,~~~~~~~~.         +-------------+
| Mobile Host | <--AYIYA--> | Home Agent | <----> { Internet } <----> | Remote Host |
+-------------+             +------------+         '~~~~~~~~'         +-------------+

Using AYIYA to provide IPv6 for an endhost is in effect already providing mobility for that endhost as it can take it's IPv6 address along anywhere it wants to go as it signals the Home Agent when the tunnel endpoint changes so that the Home Agent knows where to send new packets.

[edit] Packet Format

  Bits 0 - 7 8 - 15 16 - 23 24 - 31
0 Identity Type SignatureType Next Header Reserved
32 Epoch Time
   
Identity
 
   
Signature
 

For IPv6 over IPv4-UDP operation, as in general use, the Identity is the IPv6 Address of the endpoint (16 bytes) and the signature is an SHA1 hash (20 bytes). The header is then a total of 8 + 16 + 20 = 52 bytes. This allows an MTU of 1428 over Ethernet (MTU : 1500).

More details on the SixXS site: AYIYA and of course in the draft.

[edit] Implementations

The following implementations are available: AICCU