Los beneficios derivados de un protocolo nuevo deben ser equilibrados por los costos asociados a la transición del sistema existente. Los desarrolladores de IPV6 reconocieron que no todos los sistemas se actualizaran de IPV4 a Ipv6 en el futuro inmediato y que para algunos otros sistemas, podrá no ser en años. La mayoría de las redes son sistemas heterogéneos, con diverso routers, equipos, etc. fabricados por Empresas diferentes. Otro punto de traba (mucho más grande) seria la Wordwide Internet, que opera a través de 24 zonas diferentes de tiempo. Actualizar este sistema en un proceso único sería aun más difícil. Dado las dificultades antes mencionadas en contraste, llega a ser necesario desarrollar estrategias que permitan la coexistencia de IPV4 e IPV6.

The benefits derived from a new protocol must also be balanced by the costs associated with making a transition from the existing system. The developers of IPV6 recognized that no all systems would upgrade from IPV4 to Ipv6 in the immediate future, and that for some systems, that upgrade may not be for years. To complicate matters, most internetworks are heterogeneous systems, with various routers, host, etc. manufactured by different vendors. Another (much larger) issue becomes the wordwide Internet , which operates across 24 different time zones. Upgrading this system in a single process would be even more difficult. Given the above constraints, it therefore becomes necessary to develop strategies for IPV4 and IPV6 to coexist.

A finales de los 80 y comienzo de los 90, el área de la RFC 1726, comisionada a la IPng escogió los criterios técnicos para la próxima generación de la IP. Para definir este juego de criterios se basaron en los procesos de evaluación de la Ipng y consideraron los siguientes 17 puntos que deben tomarse en cuenta:

1. Escalable. El protocolo IPng debe ser escalable permitiendo identificación y direccionamiento de al menos 10¹² sistemas finales y 10⁹ redes individuales.
2. Topología Flexible. La arquitectura de enrutamiento y el protocolo Ipng deben soportar diferentes topologías de redes.
3. Gestión. El Router debe ser capaz de procesar y despachar él trafico Ipng a la capacidad del canal, comercialmente disponible, a velocidades altas.
4. Servicio Robusto. El servicio de la red y su enrutamiento asociado y el protocolo de control deben ser robusto.
5. Transición. El protocolo debe cumplir con el esquema de transmisión Straight Forward, establecido en el protocolo actual Ipv4.
6. Independencia del Medio. El protocolo debe trabajar atravesando redes de diferentes LAN, WAN y MAN, con un enlace individual con rango de velocidades desde bits por segundo hasta gigabits por segundo.
7. Servicio de Datagrama Cambiante. El protocolo debe soportar un servicio de datagrama deliberadamente cambiante.
8. Configuración Administración y operación. El protocolo debe ser de fácil configuración y operación distribuida, configuración automática de Hosts y Routers.
9. Operación segura. Ipng debe proveer normas para redes Seguras.
10. Unico Nombre. Ipng debe asignar todas las IP como objetos globales, con nombres únicos para la Internet.
11. 11.Acceso y documentación. El protocolo que define Ipng, es un protocolo asociado y de enrrutamiento y debe ser publicado en los estándares RFCs disponibles gratuitamente sin derechos de licencias de implantación
12. Multicast. El protocolo debe soportar tanto Multicast como unicast en la transmisión de paquetes.
13. Extensible. El protocolo debe ser extensible; este debe ser capaz de ser desarrollado para satisfacer futuros servicios necesarios en Internet.
14. Servicios de red. El protocolo debe permitir que la red asocie paquetes por clase de servicio y puedan proveer este cuando el servicio especifico lo reuniera.
15. Movilidad. El protocolo debe soportar equipos móviles, redes e interedes.
16. Protocolo de Control. El protocolo debe incluir elementalmente soporte de pruebas y gestión de redes.
17. Redes Privadas. Ipng debe permitir que los usuarios puedan construir redes privadas sobre la base de la infraestructura de la Internet.

Tomando en consideración estos criterios surgieron varias propuestas para IPv6, de las cuales se decidió realizar una sintaxis de múltiples esfuerzos de la IETP, SIPP, TUBA, CIDR y SDRP, los cuales en conjunto lograban abarcar todos los criterios antes mencionados.

La RFC 1752 enumera las siguientes capacidades de la Ipng formalmente llamada Ipv6:

1. Expansión de direccionamiento y enrutamiento. Incrementa el campo de direccionamiento de 32 bits a 128 bits, permitiendo gran numero de direcciones o nodos, definiendo nuevos tipos de red.
2. Simplifica el formato de encabezado, elimina o hace opcional alguno de los campos del encabezado IPv4 para reducir la sobrecarga en los paquetes, suministrando así compensación por lo largo del direccionamiento el cual es cuatro veces más largo pero el encabezado Ipv6 es solo 40 octetos comparado con los 20 del Ipv4.
3. Extensión del encabezamiento y opciones. Las opciones del IPV6 son colocadas por separado del encabezado, justo después de este.
4. Autoconfiguración. Soporta asignaciones dinámicas de IP (DHCP)
5. Routers Fuentes. Soporta en el encabezado demanda de fuente, protocolo de enrutamiento (SDRP), completando la determinada ruta por el protocolo de enrutamiento existente.
6. Una simple y flexible transición.

Dentro de esto se pueden mencionar los siguientes casos:

1. Actualización incremental. Permite que los existentes equipos con Ipv4, puedan ser actualizados sin ser dependiente de otros equipos o routers.
2. Desarrollo Incremental. Los nuevos equipos y routers IPV6, pueden ser instalados al mismo tiempo sin pre requisitos.
3. Fácil direccionamiento. Cuando existen instalados equipos o Routers IPV4, y son actualizados con IPV6, estos pueden continuar con su direccionamiento, sin necesidad de una nueva dirección
4. Bajos costos de implantación. Poca o ninguna preparación es necesaria para actualizar el Ipv4 existente a IPV6 o para desarrollar un nuevo sistema completamente IPV6.

7. Calidad de la capacidad de servicio. Una nueva capacidad es direccionar con la capacidad de etiquetar paquetes que vienen de tráficos particulares, por el cual el remitente ha requerido un especial tratamiento, lo cual no es una calidad de servicio estándar ó es el requerimiento de un servicio en tiempo real.

El Encabezado IPV6.

El encabezado IPV6 consta de 40 octetos de largo con 8 campos definidos:

El Campo Versión es de 4 bits e identifica la versión del protocolo.

El Campo Probity, este es de 4 bits y habilita una fuente para identificar la petición; este esta dividido en dos rangos:

0-7: Fuente Provista de control de congestión

8-15 requerimiento de paquete en tiempo real.

El Campo Flow Label es de 24 bits de largo y puede ser usado para casos en los que se requiera especificar cierto paquete con calidad de servicio no estándar.

El Campo Payload length es de 16 bit de largo, el cual mide la longitud dada en octetos. El valor más grande permitido es 65535 y él más pequeño es 0.

El Campo Next Header es de 8 bits de largo y este identifica el encabezado inmediatamente seguido al encabezado IPV6. Este campo es igual que en el protocolo IPV4. Ejemplos:

El Campo de Hop limit es de 8 bits de largo y este decrementa por cada nodo que transmite el paquete, cuando este llega a cero el paquete es descartado y se envía un mensaje de error al origen.

El campo de Dirección Fuente es de 128 bits de largo e identifica el equipo que origino el paquete transmitido.

El campo de Dirección Destino es de 128 bits de largo e identifica el equipo al cual esta dirigido el paquete transmitido.

El direccionamiento IPV4 es típicamente representado en notación decimal. Tal como 32 bits de direccionamiento dividido en cuatro secciones de 8 bits cada una, y cada sección es representada en un numero decimal de 0 a 255 por ejemplo: 129.144.52.38.

IPV6 tiene un direccionamiento de 128bits de largo y por lo tanto requiere un método diferente de representación, según especificaciones RFC 1884, la representación preferible es la siguiente:

X:X:X:X:X:X:X:X, donde cada X representa 16 bits y cada una de estas secciones son representadas en hexadecimal, por ejemplo una dirección IPV6 podría ser: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210

Note que cada sección es de 16 bits y están separadas por dos puntos y su representación es con cuatro números hexadecimales. Cualquiera de las secciones podría contener puro cero y estos no son requeridos, por ejemplo:

1080:0000:0000:0000:0008:0800:200C:417C, esta puede ser simplificada de lo siguiente manera 1080:0:0:0:8:800:200C:417C, inclusive podría resumirse más colocándole :: como múltiples grupos de ceros consecutivos, quedando: 1080::8:800:200C417C.

El direccionamiento IPV6 de 128 bits pueden ser dividido en un numero de subcampos que provee una máxima flexibilidad para ambas IP la actual IPV4 y la futura Ipv6. El primer bit define el tipo especifico de direccionamiento IPV6, el cual es definido como Prefijo. En este campo se puede definir: si es un direccionamiento unicast, unicast geográfico, o Multicast entre otros.

El beneficio derivado de un nuevo protocolo debe ser balanceado por el costo asociado al realizar la transición del sistema actual.

El desarrollo de IPV6 reconociendo que no todos los sistemas podrán ser actualizados en años, dado a que muchas conexiones de redes son sistemas heterogéneos, con Routers de diferentes fabricantes por otro lado se tiene la World Wide Web Internet, la cual opera a través de 24 diferentes tipos de zonas. Actualizar este sistema en un simple proceso seria muy difícil, en contraste se hace necesario desarrollar estrategias para que la IPV4 coexista con la IPV6.

Actualmente hay dos mecanismos para la IPV4 pueda coexistir con la IPV6:

1. Una Ley dual IP, Haciendo un Túnel de Ipv6 sobre IPV4.

Leyes de IP dual

El mecanismo para que IPV4 e IPV6 coexistan, es que el stack de ambos protocolos sean implementados en un mismo dispositivo (Router, PC o Servidor), el cual esta referido como un nodo IPV6/IPV4.

El nodo IPV6/IPV4 tiene la capacidad de enviar y recibir ambos tipos de paquetes IPV4 e IPV6 y puede interoperar con un dispositivo IPV4 usando paquetes IPV4 y con un dispositivo IPV6 usando paquetes IPV6. El Nodo IPV&/IPV4 puede ser configurado con direcciones soportadas en ambos protocolos, como un protocolo de configuración dinámica (DHCP), conjuntamente con un protocolo de inicio (BOOTP)y el sistema de nombre de Dominio(DNS), los cuales deben ser involucrados en este proceso.

2. Entubamiento.

Entubamiento es el proceso por el cual la información de un protocolo es encapsulado dentro del Frame de otro protocolo o sistema, poniendo disponible la data original para ser cargada sobre el otro protocolo. Los escenarios para entubar IPV6/IPV4 fueron designados para poder utilizar la infraestructura existente IPV4 para que cargue paquetes IPV6 encapsulado la información IPV6 dentro del paquete IPV4.

Del Proceso de encapsulamiento resulta un paquete IPV4 que contiene ambos encabezados el de IPV& y el de IPV4. El encapsulamiento incluye tres pasos: encapsulamiento, desencapsulamiento y manejo del túnel o Tubo.

En el nodo encapsulador (emisor o punto de entrada del túnel) el encabezado IPV4 es creado y encapsulado el paquete a transmitir, en el nodo descapsulador (Receptor o salida del Túnel)el encabezado iIPV4 es removido y el paquete IPV6 es procesado. En adición el nodo encapsulador puede mantener la información de configuración considerando el túnel establecido con un máximo tamaño de unidad de referencia soportada por el Túnel (MTU).

RFC 1993 definió cuatro posibles configuraciones de Túneles que pueden ser establecidos entre Routers y equipos:

Routers a Routers: Routers IPV6/IPV4 que están separados por una infraestructura IPV4 con un túnel IPV6 entre ellos mismos, en este caso el túnel puede ser colocado sobre un segmento del camino end to end del paquete.

Host a Router: un Host IPV6/IPV4 hace un túnel de un paquete IPV6 hacia un Router IPV6/IPV4 el cual es alcanzable por una infraestructura IPV4, en este caso el túnel se puede colocar en el primer segmento del camino end to end del paquete.

Host a Host: Un Host IPV6/IPV4 que está interconectado por una infraestructura puede hacer un túnel del paquete IPV6 a través de la infraestructura IPV4 en este caso, el Túnel se coloca en el camino entero end to end del paquete.

Router a Host: Un Router IPV6/IPV4 puede entregar paquetes IPV6 para un equipo IPV6/IPV4 el cual es el destino final . En este el caso el túnel se deberá colocar al final del segmento del camino end to end del paquete.

Para que un túnel este operativo, las direcciones de ambos extremos del túnel y los destinos del paquete deben ser conocidos, y estas dos direcciones no necesariamente son las mismas, la menera en la cual la dirección al final del túnel es determinada define los tipos de túneles, que pueden ser automático o configurado.

Bibliografia.

Mankin, Allison, "The trillon Node Internet: an update on IPV6". ComNet 1996 Conferencia. Enero 1996

Gross Paul. "IESG deliberations on Routeing and Addressing". RFC 1380, Noviembre 1992

Bradner Scott and Allison Manking "IP:netx Generations (Ipng) White paper solicitation". RFC 1550, Deciembre 1993.

Bradner Scott and Allison Manking "The recommendation for the IP netx Generations protocol" . RFC 1752. Enero 1995.

Winston Jesus Ortega, Ingeniero de Sistemas egresado de La Universidad Experimental Politécnica "Antonio José de Sucre", Vice Rectorado "Luis Caballero Mejias", en el año 1992. En la actualidad estudiante del Post Grado En comunicaciones y redes de comunicación de datos de la Escuela Eléctrica de La Universidad Central de Venezuela.

Actualmente me desempeño como analista en la Electricidad de Caracas C.A. en el Departamento De Infraestructura tecnología e información en el área de Operaciones. Específicamente en la Operación de Equipos de Internetworking en general incluyendo: Configuraciones Cambios, monitoreo. Administración Direcciones IP. Y participo en los Proyectos: Tivoli, Cambios y Migración de Redes.