IPv6

Seguimos teniendo tiempo. Desde aquel famoso Día Mundial de IPv6 de 2011, dónde los principales operadores en internet pusieron en funcionamiento su infraestructura para este protocolo, no se ha vuelto a oír mucho movimiento. Pero sí es verdad que se van planteando posibilidades y se van perfilando opciones de migración. Los tiempos no se han fijado y teniendo en cuenta el alcance global, la cosa va para largo.

Esto no quita que se empiece a plantear y a estudiar cómo enfocar esta migración. Si bien, dependemos de la propia tecnología, ISPs, software de los dispositivos, etc. la mayoría de implicados están poniéndose al día sin dilación y siempre es recomendable entender la situación. Claro está que antes de mover un dedo hay que entender bien los funcionamientos de los protocolos, y ver sus implicaciones tanto a nivel de seguridad, como de gestión y configuración, para estar preparado ante cualquier posible eventualidad.

IPv6 cambia por completo la visión que tenemos de las comunicaciones. El hecho de disponer de una única dirección para encontrar cualquier equipo, sin necesidad de realizar NAT, así como el hecho de tener obligatoriamente IPSEC en el propio protocolo, nos hace rediseñar la base de nuestra visión de las redes. Este protocolo redefine la esencia de las comunicaciones a todos los niveles.

Debemos sentarnos y valorar las implicaciones de este cambio, y plantearnos los primeros pasos para acometerlo. Para simplificar, sin entrar en detalles técnicos, podemos decir que hay 3 modelos de migración a estudiar:

  • Doble Pila: Los dispositivos de red soportan ambos protocolos, y utilizan cada uno de ellos en función de la configuración de los destinos. En principio es muy sencillo y escalable, pero implica tener duplicidades que pueden repercutir en la gestión y los recursos de la infraestructura.
  • Tunelización: Consiste en encapsular los paquetes IPv6 en paquetes IPv4, de manera que para la mayor parte de la topología IPv4 es transparente, salvo en los extremos dónde se encapsula y se desencapsula el protocolo. Los dispositivos extremos trabajarían como si de un túnel se tratase.
  • Traducción: Se requiere una traducción entre protocolos cuando algún dispositivo implicado no soporta, o no contempla uno de los protocolos, generalmente no soporta IPv4. Se requiere un pool de direcciones para asignar en la propia traducción.

Desde mi punto de vista, obviamente dependerá de cada caso, creo que la primera opción sería la ideal. De esta manera tenemos los dos entornos en funcionamiento y podemos ir pasando servicios poco a poco, de manera lo más transparente posible para los usuarios/clientes, los que en el fondo mandan, y a los que no queremos marear nunca más de lo necesario.

Mi intención con esta entrada era recordar que IPv6 cada vez está más cerca, y que hay que empezar a contemplar opciones, que ya están muy trilladas, y no podemos dormirnos en los laureles. Pero que no nos entre el pánico porque en nuestro sector, gracias a Dios, se plantea siempre todo desde el punto de vista de la simplicidad para todas las partes y de la manera más transparente posible de cara a la gestión de servicios.

Lo que está claro a fin de cuentas, viendo cómo avanza la tecnología hoy en día, es que no cabe la posibilidad de quedarnos anclados en el pasado. Si no nos actualizamos, poco a poco iremos perdiendo servicios que solo estarán disponibles para los nuevos protocolos. Y al final sí que nos entrará la sicosis de estar aislados del mundo.

Comments

  1. Hola,

    IPSEC ya no es obligatorio en IPv6. En el RFC 6434 se puede leer lo siguiente:
    Previously, IPv6 mandated implementation of IPsec and recommended the
    key management approach of IKE. This document updates that
    recommendation by making support of the IPsec Architecture [RFC4301]
    a SHOULD for all IPv6 nodes

  2. Gracias Jose, le echaré un ojo :)

  3. Acertada tu reflexión. Es cierto que no se oye mucho «ruido» en torno a IPv6, pero eso no significa que debamos obviarlo. Además, la primera de las 3 opciones de convivencia es la mejor sin duda.
    Saludos

Trackbacks

  1. […] Security A(r)tWork […]