Anything In Anything

Anything In Anything (AYIYA) is a computer networking protocol for managing IP tunneling protocols in use between separated Internet Protocol networks. It is most often used to provide IPv6 transit over an IPv4 network link when network address translation masquerades a private network with a single IP address that may change frequently because of DHCP provisioning by Internet service providers.

IPv6 transition mechanisms
Standards Track
Experimental
Informational
Drafts
Deprecated

Features

The protocol has the following features:[1]

  • Tunneling of networking protocols within another IP protocol
  • Network security is provided by preventing tunneled packets to be spoofable or replayable
  • Transparent handling of network address translation
  • The endpoint of at least one of the two tunnel endpoints should be able to change to provide mobility features.

Tunnel brokers

Many consumer networks are provisioned by Internet service providers using network address translation (NAT) which precludes[2][3][4] the usage of IP protocol 41 tunnels (IPv6 tunnelled in IPv4, either RFC 4213 or RFC 3056) unless they manually reconfigure their NAT setup. In some cases, this is impossible as the NAT cannot be configured to forward protocol 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 were created because of limited address space in the first place.

This problem can be solved by tunneling the IPv6 packets over either User Datagram Protocol (UDP), Transmission Control Protocol (TCP) or the Stream Control Transmission Protocol (SCTP). Taking into consideration that multiple separate endpoints could be behind the same NAT or that the public endpoint receives a new IP address, there is 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 is IPv6-in-UDP-in-IPv4, which is a typical setup that can be used by IPv6 tunnel brokers.

Mobility

AYIYA may be used to provision mobile hosts by tunneling traffic from the Home Address to the Home Agent over an underlying network. Any remote host that the mobile host communicates with does not need AYIYA support. When the remote host does support AYIYA, it could also directly set up a tunnel with the mobile host establishing a direct tunnel. The remote host can determine whether a host supports AYIYA by querying for Domain Name System records and use a public/private key algorithm to authenticate the packets.

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

Using AYIYA to provide IPv6 for a host is in effect already providing mobility for that end point as it can use its IPv6 address regardless of geographic location.

Packet format
  Bits 0 - 3 4 - 7 8 - 11 12 - 15 16 - 19 20 - 23 24 - 31
0 Identity Length Identity Type Signature Length Hash Method Authentication Method Operation Code Next Header
32 Epoch Time
   
Identity
 
   
Signature
 

For IPv6 over IPv4-UDP operation, as in the most common use scenario, the identity is the IPv6 Address of the endpoint (16 bytes) and the signature is an SHA1 hash (20 bytes). The header has a total of 8 + 16 + 20 = 44 bytes. Encapsulated in UDP and IPv4 the tunnel overhead is 44 + 8 + 20 = 72 bytes. Over Ethernet this allows an MTU of 1428 bytes.

Implementations

The AYIYA protocol has been implemented in AICCU.

References
  1. Massar, J. "AYIYA: Anything In Anything". IETF. (Internet draft)
  2. RFC 2993: T. Hain (November 2000). "Architectural Implications of NAT". IETF.
  3. "Anything In Anything (AYIYA)". SixXS.
  4. RFC 4891: R. Graveman; M. Parthasarathy; P. Savola; H. Tschofenig (May 2007). "Using IPsec to Secure IPv6-in-IPv4 Tunnels". IETF.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.