Anything In Anything ( AYIYA ) es un protocolo de red de computadoras para administrar protocolos de tunelización IP en uso entre redes de Protocolo de Internet separadas . Se utiliza con mayor frecuencia para proporcionar tránsito IPv6 a través de un enlace de red IPv4 cuando la traducción de direcciones de red enmascara una red privada con una única dirección IP que puede cambiar con frecuencia debido al aprovisionamiento de DHCP por parte de los proveedores de servicios de Internet .
Características
El protocolo tiene las siguientes características: [1]
- Túnel de protocolos de red dentro de otro protocolo IP
- La seguridad de la red se proporciona al evitar que los paquetes tunelizados sean falsificados o reproducibles
- Manejo transparente de la traducción de direcciones de red
- El punto final de al menos uno de los dos puntos finales del túnel debería poder cambiar para proporcionar funciones de movilidad.
Corredores de túneles
Muchas redes de consumidores son aprovisionadas por proveedores de servicios de Internet mediante traducción de direcciones de red (NAT) que excluye [2] [3] [4] el uso de túneles del protocolo IP 41 ( IPv6 tunelizado en IPv4, ya sea RFC 4213 o RFC 3056), a menos reconfigure su configuración de NAT. En algunos casos, esto es imposible ya que NAT no se puede configurar para reenviar el protocolo 41 a un host específico. También puede haber casos en los que varios puntos finales estén detrás del mismo NAT, cuando se utilicen varios NAT o cuando el usuario no tenga ningún control sobre la configuración de NAT. Esta es una situación no deseada ya que limita la implementación de IPv6, que estaba destinado a resolver el problema de la perturbación en las comunicaciones de extremo a extremo causadas por NAT, que se crearon debido al espacio de direcciones limitado en primer lugar.
Este problema se puede resolver canalizando los paquetes IPv6 sobre el Protocolo de datagramas de usuario (UDP), el Protocolo de control de transmisión (TCP) o el Protocolo de transmisión de control de flujo (SCTP). Teniendo en cuenta que varios puntos finales separados podrían estar detrás de la misma NAT o que el punto final público recibe una nueva dirección IP, es necesario identificar el punto final del que provienen ciertos paquetes y los puntos finales deben poder cambiar, por ejemplo, las direcciones de origen de el protocolo de transporte sobre la marcha sin dejar de ser identificable como el mismo punto final. El protocolo descrito en este documento es independiente del protocolo de transporte y carga útil. Un ejemplo es IPv6-in-UDP-in-IPv4, que es una configuración típica que pueden utilizar los agentes de túneles IPv6 .
Movilidad
AYIYA se puede utilizar para aprovisionar hosts móviles canalizando el tráfico desde la dirección de casa al agente de casa a través de una red subyacente. Cualquier host remoto con el que se comunique el host móvil no necesita soporte AYIYA. Cuando el host remoto admite AYIYA, también podría configurar directamente un túnel con el host móvil estableciendo un túnel directo. El host remoto puede determinar si un host admite AYIYA consultando los registros del Sistema de nombres de dominio y utilizando un algoritmo de clave pública / privada para autenticar los paquetes.
+ ------------- + + ------------ +, --------. + ------------- +| Anfitrión móvil | <--AYIYA--> | Agente de inicio | <----> {Internet} <----> | Host remoto |+ ------------- + + ------------ + '--------' + ---------- --- +
El uso de AYIYA para proporcionar IPv6 para un host, en efecto, ya brinda movilidad para ese punto final, ya que puede usar su dirección IPv6 independientemente de la ubicación geográfica.
Formato de paquete
Bits 0-3 | 4 - 7 | 8 - 11 | 12 - 15 | 16 - 19 | 20 - 23 | 24 - 31 | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0 | Longitud de la identidad | Tipo de identidad | Longitud de la firma | Método hash | método de autentificación | Código de operación | Encabezado siguiente | |||||||||||||||||||||||||
32 | Época | |||||||||||||||||||||||||||||||
Identidad | ||||||||||||||||||||||||||||||||
Firma |
Para la operación de IPv6 sobre IPv4-UDP, como en el escenario de uso más común, la identidad es la dirección IPv6 del punto final (16 bytes) y la firma es un hash SHA1 (20 bytes). El encabezado tiene un total de 8 + 16 + 20 = 44 bytes. Encapsulado en UDP e IPv4, la sobrecarga del túnel es 44 + 8 + 20 = 72 bytes. A través de Ethernet, esto permite una MTU de 1428 bytes.
Implementaciones
El protocolo AYIYA se ha implementado en AICCU .
Referencias
- ^ Massar, J. "AYIYA: cualquier cosa en cualquier cosa" . IETF . (Borrador de Internet)
- ^ RFC 2993: T. Hain (noviembre de 2000). "Implicaciones arquitectónicas de NAT" . IETF .
- ^ "Cualquier cosa en cualquier cosa (AYIYA)" . SixXS .
- ^ RFC 4891: R. Graveman; M. Parthasarathy; P. Savola; H. Tschofenig (mayo de 2007). "Uso de IPsec para proteger túneles IPv6 en IPv4" . IETF .