Migración de estrategias IPv4 a IPv6

Como todos saben, estamos fuera de las direcciones IPv4 y pronto (si no es que ya) nos trasladaremos a IPv6. ¿Cuáles son algunas buenas estrategias y prácticas para migrar una red IPv4 completa a IPv6?

No tengo una estrategia completa, pero esta es la forma aproximada en que lo hice en $ JOB [-1]:

1. Obtenga un bloqueo de IPv6, ya sea de su operador actual o de un RIR
2. También es posible que desee marcar un bloque fc00 :: / 7 (Local único) para subredes completamente internas si tiene un bloque ISP y alguna vez necesita volver a numerar
3. Decida su IGP v6, IS-IS sigue siendo una opción más segura que OSPFv3, pero muchos kits no lo harán IS-IS
4. Muestra v6 en tu kit principal, desde el borde de Internet hasta los conmutadores principales de CC
5. Mencione el tránsito v6, si tiene que ir a un túnel BGP desde he.net puede funcionar mientras espera que los ISP se atasquen en la última década (recuerde habilitar v6 en su malla iBGP si tiene uno)
6. Cree servicios de infraestructura v6, principalmente DNS, v4 accesible está bien aquí
7. Habilite v6 en una red de servidor único (probablemente tendría un firewall denegado predeterminado aquí)
8. Prueba la conectividad v6 al mundo, ¿romperá las cosas?
9. Encienda v6 en una segunda red de servidor para la redundancia
10. Abra un servidor DHCPv6 si desea usarlo
11. Muestra v6 en una red de acceso único (el personal de TI es una buena opción aquí)
12. Prueba. Asegúrate de que nada se rompa
13. Muestra v6 en las redes de servidores restantes
14. Agregue un servidor de nombres v6 para sus dominios y una entrada v6 DNS para un MX (uno, o todos menos uno, son buenas opciones para qué apilar doble)

Ahora, al abrir nuevos servicios o actualizarlos, puede probar si funcionan en la v6 y agregar los registros DNS apropiados (casi todos los servicios web "simplemente funcionarán"), eventualmente podría comenzar a buscar los servicios restantes en la v4 y corregirlos , pero no hay prisa por eso.

Creo que es importante separar dos objetivos diferentes aquí:

• Manejo de la habilitación de IPv6. Los principales problemas con este objetivo generalmente tienen que ver con equipos en su red que no admiten IPv6, y debe usar algún tipo de solución de túnel / transporte para evitar esos elementos. 6 y 6PE son muy populares.
• Por otro lado, hay estrategias para enfrentar el agotamiento de la dirección IPv4. La única manera de resolver este problema es implementar algún tipo de NAT (NAT de nivel de operador, DSLite, NAT64 ...)

Algunas tecnologías resuelven el primer problema, algunas resuelven el segundo y otras resuelven ambas.

Todo está evolucionando muy rápidamente y hay que estar atento a las nuevas soluciones que surjan. Por ejemplo. Una solución que está recibiendo mucha atención últimamente es MAP-E y MAP-T, que actualmente están en estado de borrador (MAP-E está cerca de convertirse en RFC) y le permiten implementar IPv6 y resolver el agotamiento de direcciones IPv4 de una manera muy inteligente camino. Puede obtener más información en http://tools.ietf.org/html/draft-ietf-softwire-map-06

Para obtener información más detallada, necesitaría conocer el contexto y los requisitos. Quiero decir, las soluciones dependen del tipo de red (un proveedor de servicios es muy diferente a un proveedor de contenido o una red de pequeñas empresas) y el objetivo que está tratando de lograr.

Saludos cordiales,

Diego Nuevo

¿Migración de IPv6 a alto nivel?

1. Habilite IPv6 en toda la red, hasta que las capacidades y conectividad de IPv6 estén a la par con IPv4.
2. Espere a que llegue el día en que IPv4 ya no sea relevante.

Ahora para el nivel bajo:

Obtenga un prefijo (idealmente de un RIR) y haga que lo anuncien, recomendaría OSPFv3 para su IGP a menos que esté ejecutando una red plana grande para la que cree que IS-IS es más adecuado. Si tiene un equipo heredado que solo es IPv4, considere evitarlo haciendo túneles 6in4 o GRE a través del equipo.

Tenga un plan para la administración de direcciones, el espacio IPv6 no es valioso, si tiene un / 32 y cree que los clientes querrán algo más grande que un / 64, dirija el espacio suficiente hasta su equipo; si un solo enrutador o par de enrutadores atiende a 100 clientes y cada uno obtiene un / 56, su IGP no debe contener cada / 56: asigne un / 48 para ese enrutador (par) y ya está. El espacio IPv6 es tan grande que la fragmentación de subred nunca debería ser necesaria si lo está haciendo bien.

Asegúrese de que todos los servicios que ejecute tengan doble pila, ya sea DNS, correo electrónico, lo que sea, en la mayoría de los casos es tan simple como asegurarse de que el servicio esté configurado para escuchar en v6 y su DNS tenga un registro AAAA. Si proporciona servicios de alojamiento, servidores, etc., sea proactivo al informar a las personas que pueden apilar sus ofertas de manera dual.

Comience a familiarizarse con las tecnologías que evitarán el desastre cuando no tenga espacio IPv4 y tampoco pueda obtener más: mantenga el pulso de cosas como NAT64 y 464XLAT para que cuando llegue el momento, pueda determinar la viabilidad de tener IPv6 solo hosts en comparación con el uso del espacio RFC6598 y NAT44 (4). Configurar un laboratorio, experimentar.

¿Luego? Espere a Fomentar la desconexión de IPv4.

Si bien las direcciones IPv4 ya no se dan como dulces, eso no significa que sea innecesario o práctico deshacerse de IPv4 por completo en el futuro cercano.

Activar ipv6 es un buen primer paso /networkengineering//a/261/20201 hace un buen trabajo cubriendo eso. Esto le permite interactuar con dispositivos solo v6 en Internet, reduce la carga en sus NAT y, por lo tanto, reduce la cantidad de IP / puertos externos necesarios para servir esos NAT. Con grandes servicios como Google y Facebook que admiten IPv6, es probable que una proporción significativa del tráfico de Internet se mueva (he visto cifras tan altas como 70%).

La siguiente pregunta que debe hacerse es si su organización es lo suficientemente grande como para correr el riesgo de quedarse sin IPv4 privado . Para la gran mayoría de las organizaciones, la respuesta será no.

Suponiendo que la respuesta es no, veo pocas razones para eliminar el IPv4 privado de las implementaciones existentes en el futuro cercano. Deshacerse de IPv4 privado puede simplificar un poco la administración a largo plazo, pero a corto plazo traerá una gran cantidad de rotura adicional para obtener poca ganancia.

Si se está quedando sin v4 pública, el siguiente paso sería auditar su uso de v4 pública. Busque direcciones v4 públicas desperdiciadas que puedan liberarse cambiando las subredes. Busque sistemas que puedan migrar de ipv4 público a ipv6 o ipv4 privado. Considere esquemas como balanceadores de carga y DNAT que pueden aplicar un pequeño grupo de direcciones públicas V4 exactamente donde se necesitan y, en algunos casos, compartir una dirección pública v4 entre múltiples servicios.

Considere la implementación de una puerta de enlace NAT64 / DNS64 para que los nuevos sistemas se puedan hacer solo v6 y aún tengan acceso a recursos en Internet ipv4.