Proceso de Transición de IPv4 a IPv6 en una Entidad de Gobierno en Costa Rica
15/04/2025
Escrito por Andrés Cortés*
La Municipalidad de Carrillo, es un gobierno local de Costa Rica ubicado en el cantón de Carrillo, distrito de Filadelfia el cual a mediados del año 2023 concluyó el proceso de transición y despliegue del protocolo IPv6 en su infraestructura de Tecnologías de Información y Comunicación, bajo el modelo de Dual Stack o Doble Pila, esto con el objetivo de enfrentar el problema del agotamiento del protocolo IPv4 en la región, así como para dar cumplimiento al marco normativo emitido por el Ministerio de Innovación, Ciencia, Tecnología y Telecomunicaciones (MICITT) a nivel de instituciones del gobierno central de Costa Rica; en lo que respecta a garantizar la continuidad de los servicios de comunicaciones internas y externas (red privada institucional y enlaces de internet de diversos proveedores).
Tomando en cuenta a su vez, que este proceso de migración trae consigo una serie de ventajas y beneficios que fortalecen las infraestructuras tecnológicas del Estado, potencializando la cadena de valor público sobre el portafolio de servicios brindados a los clientes internos y externos, y al mismo tiempo permite alcanzar un alto grado de madurez con respecto a las tendencias globales de conectividad y digitalización.
Estrategias y Fases del Proceso de Implementación
Estratégicamente este tipo de proyectos pueden ser planificados en fases, siguiendo la metodología “divide y vencerás”, con el objetivo de sistematizar el proceso de transición del protocolo IPv4 a IPv6 de manera paulatina y asertiva. Sumamente importante destacar, la recomendación de adquirir el pool de direccionamiento IPv6 directamente con el Registro Regional de Internet o Regional Internet Registry (RIR).
Esto con el objetivo de no generar dependencia alguna con un Proveedor de Servicio de Internet (ISP) local que provea el pool de direccionamiento IPv6 a configurar (interna y externamente). Por lo tanto esta acción estratégica permite alcanzar una autonomía en la gestión del pool de direccionamiento adquirido, y el/los ISP que la organización desee contratar solamente deberán realizar el anuncio a nivel de BGP, además en caso de finalizar el contrato con un ISP esto no conlleva u obliga a cambiar el direccionamiento en los dispositivos y elementos de configuración a nivel de la infraestructura de red interna y externa.
A continuación, se detallan cada una de las fases llevadas a cabo en el despliegue de IPv6 en la municipalidad, junto con recomendaciones para lograr alcanzar el éxito del proceso de transición:
Fase #1: Transferencia de conocimiento.
Independientemente de si el proyecto es ejecutado por el personal técnico interno de la organización o a través de la subcontratación de un servicio de implementación o consultoría, es sumamente importante y clave para el éxito llevar a cabo un proceso de “Transferencia de Conocimiento” que contemple básicamente las siguientes temáticas:
(Acceso libre, no requiere suscripción)
- Aspectos básicos de IPv6.
- Direccionamiento IPv6.
- Enrutamiento en IPv6.
- Configuración de servicios de infraestructura crítica de TIC.
- Comparativa IPv4 – IPv6.
- Configuración básica de IPv6 en dispositivos finales.
Esto con el objetivo de empoderar al personal técnico de la organización, para que cuente con los conocimientos suficientes para la acertada toma de decisiones durante el despliegue, además del desarrollo de destrezas con respecto a la configuración del protocolo IPv6, soporte y mantenimiento una vez concluido el proceso de transición.
Fase #2: Diagnóstico y Planeación
En la fase de diagnóstico y planeación llevada a cabo en la municipalidad se realizaron las actividades descritas en la gráfica, las cuales dieron como resultado el Plan de Implementación detallado que se materializó en la siguiente fase del proyecto.
Fase #3: Implementación
Para llevar a cabo el proceso de implementación en la municipalidad se realizaron las actividades descritas en la gráfica, las cuales dieron como resultado un documento con un enfoque técnico que detalla todas las configuraciones realizadas a nivel de hardware, software, servicios y elementos de configuración, asegurando que la organización opera plenamente bajo el protocolo IPv6 considerando los estándares de seguridad y funcionalidad definidos por la municipalidad.
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.
Hola Andrés,
Quería hacer una apreciación que es sumamente importante y que a menudo genera confusión. En el IETF no hemos definido ningún mecanismo de migración, ya que ello implica el apagado “total” de IPv4 y el encendido exclusivamente de IPv6. Migrar lo podemos aplicar a cambiar un Windows 10 por un Windows 11, caso en el cual no hay “resquicios” en la máquina de Windows 10.
Sin embargo en el camino de IPv4 a IPv6 hablamos de transición y coexistencia. El modelo que vosotros habéis adoptado de dual-stack lo confirma.
Por otro lado, mi recomendación es que ya no usemos mas este modelo, dado que no es necesario y podemos ir a un modelo que en IETF hemos bautizado IPv6-only con IPv4aaS (IPv4 as a Service), y que concretamente en redes corporativas como son las redes de una organización/municipalidad, estamos hablando de IPv6-Mostly.
La idea es que se puede configurar la infraestructura (routers, switches, APs, firewalls, etc.) de la red con dual-stack o IPv6 only (con excepción de algunos dispositivos que mantendremos como IPv6-only). Sin embargo, se habilita la opción DHCP 108 e incluso un NAT64 (por ejemplo en un router o firewall, pues está ampliamente soportado en estos dispositivos), y ello permite que los clientes en la red puedan decidir de forma autónoma si necesitan direcciones IPv6 solo, o si también necesitan IPv4. Y cuando estos dispositivos que solo requieren direcciones IPv6 necesitan acceder a destinos solo-IPv4, automáticamente ese tráfico es encaminado a través del NAT64. También es conveniente, aunque opcional, configurar la opción de DNS64 en el DNS de la red.
Hemos estado trabajando en IETF en este campo los últimos años, y ha sido probado en grandes redes corporativas (por ejemplo la red de Google). En el pasado IETF122 en Bangkok lo hemos utilizado bajo prueba, pero en el próximo IETF123 (Julio 2025) en Madrid, será la red por defecto.
Esto viene ayudado por los sistemas operativos de dispositivos inalámbricos, celulares, y sobremesa, que ya vienen incorporando también el CLAT, dado que esta funcionalidad de IPv6-Mostly, no es mas que un 464XLAT aplicado a redes corporativas, y por eso los grandes fabricantes de sistemas operativos han apostado por ello.
Sería interesante también entender cuantas sedes tiene la municipalidad, como se ha afrontado el plan de direccionamiento, etc.
Igualmente si proporcionas URLs de páginas web de la institución o servicios públicos alojados en dicha red, podemos verificar desde el exterior, si todo es correcto, pues nos hemos encontrado con muchos casos de despliegues con pequeños fallos, que sin embargo son críticos. De hecho en instituciones de Costa Rica así lo descubrimos hace años y había problemas en la conectividad internacional y filtrados inapropiados desde hacía años. Eso confirma que las pruebas desde el interior de la red, o desde el exterior de la misma, no son suficientes si no se realizan desde multiples ASNs ubicados en otras regiones.
Otro aspecto fundamental y que quizás se ha realizado, pero no se menciona en el artículo, es el uso de IPAM (IP Address Management), que es fundamental en IPv6 (diría que también en IPv4, pero nos hemos acostumbrado a hojas de cálculo u otros tipos de documentos). Hay variedad de muy buenas herramientas open source para cumplir con este objetivo.