IPv6: La experiencia de Telecom
03/02/2011
Introducción
Cuando nos invitaron a compartir con la comunidad cómo se está viviendo en Telecom Argentina la transición de IPv4 a IPv6, volvieron a nuestras mentes los recuerdos de cómo fue explicar a “la gran Empresa”, que se agotaría ese recurso tan preciado que son las direcciones IPv4.
Gestionar los comienzos de IPv6 nos demostró que las comunicaciones IP no son solo un tema técnico. IPv6 es un cambio sin elección y sin vuelta atrás, que involucra tanto a los que administran las redes como al resto de la compañía.
En los comienzos, cada vez que se introducía el tema “IPv6”, recibíamos comentarios tales como:
– Falta mucho… hablamos más adelante
– ¡Cómo que se van a terminar las IPs!
– ¿Están seguros? ¿Cuándo?
La fecha ha llegado y gracias al trabajo desarrollado y a los planes en marcha, Telecom Argentina está preparada para comenzar a afrontar la transición hacia IPv6.
Telecom Argentina
Telecom Argentina S.A. es una empresa proveedora de servicios de comunicaciones en Argentina y Paraguay, que cuenta con resultados consolidados al 30/9/2010 de 17.843.000 clientes móviles, 1.330.000 accesos de banda ancha, 4.087.000 líneas en servicio de telefonía fija y 18 % de crecimiento en las ventas netas de servicios de voz, datos, internet y telefonía móvil en el último año.
Según la estimación de crecimiento de los servicios de datos e internet (móvil y fijo), para el 2011 será necesaria la asignación de 1.000.000 de nuevas direcciones IP para abastecer a nuestros clientes
Transición hacia IPv6
Antecedentes Históricos en Telecom:
Desde la actividad de innovación tecnológica que desarrolla la empresa, las proyecciones de agotamiento del pool de IPv4 comenzaron a analizarse en el año 2005, momento a partir del cual se adoptó como objetivo requerir el cumplimiento de los diversos estándares que componen IPv6 en todas las futuras licitaciones de nuevo equipamiento relacionados con servicios de acceso a internet, desde el Backbone hasta los CPE corporativos. Esta decisión permitió comenzar a contar con las herramientas formales necesarias para comenzar un futuro despliegue.
Hacia fines de 2007, comenzó el proceso de desarrollo de la ingeniería, focalizado en el backbone. Esta fase comprendió el análisis de detalle de las condiciones de soporte de IPv6 existentes en la infraestructura, identificando las partes de hardware y de software que debían ser reemplazadas por obsolescencia. En consecuencia, se elaboro un plan de reemplazo para ser ejecutado junto con el proceso de ampliación de infraestructura necesaria anual de los periodos siguientes. De ésta forma, la inversión requerida fue absorbida gradualmente dentro del proceso ordinario de crecimiento.
Durante 2008 y 2009 se ejecutaron los planes de capacidad que dotaron a la red del hardware y software necesario para soportar IPv6, entre otros drivers . En forma paralela, durante 2008 y 2009 también se realizaron las pruebas de laboratorio y la elaboración de los distintos parámetros de configuración a ser aplicados en la red a través de las ingenierías elaboradas ad-hoc. En ésta etapa se trabajó conjuntamente con el proveedor, ya que varias de las funcionalidades necesarias se hallaban en su roadmap interno de desarrollo, no liberadas aún para su uso.
En el ultimo trimestre de 2009 comenzó la implementación en la red en producción de la ingeniería con las configuraciones lógicas previamente probadas, comenzando con el estándar RFC 4798 denominado “6PE” (IPv6 packets transported from PE to PE inside MPLS network) .
En el segundo trimestre de 2010 se logró alcanzar el grado de despliegue y confiabilidad necesario directamente en campo para lograr el estado operativo de servicio regular en el backbone. Para ello, fue fundamental el trabajo en conjunto con un cliente, RIU (Redes de Interconexión Universitaria) y nuestro upstream provider TIS (Seabone es el backbone internacional de Telecom Italia, propiedad y operado por Telecom Italia Sparkle).
Hacia fines de 2010, se completaron en laboratorio los ensayos de homologación sobre el estándar RFC 4659, denominado “6VPE” (IPv6 packets transported from PE to PE inside VPN-MPLS network) y estan previstos la prueba directamente en campo y el despliegue en la red en el primer trimestre de 2011.
Gestión de direcciones IPv4
Si bien Telecom Argentina siempre mantuvo sus procesos de asignaciones acorde a las políticas de LACNIC, en los años 2008 y 2009 trabajó en reorganizar las asignaciones de todos los productos que requirieran IPv4 para afrontar el agotamiento del pool de IPv4 y con el fin de incrementar la eficiencia en la utilización de los espacios de direcciones IPv4 se definió un plan de adecuación
• Reorganización de las asignaciones de todos los productos con IPv4 pública
• Plan de recuperación de direcciones IP
• Concientización sobre agotamiento de IPv4 y un plan de introducción de IPv6
• Análisis de impacto en los sistemas de la compañía
Reorganización de las asignaciones de todos los productos con IPv4 pública
La ejecución del primer punto del plan, modificó las asignaciones de todos los productos de la Empresa, que requirieran IPv4, para ello se trabajo con las areas de mercadotecnia y desarrollo de Productos de los diferentes segmentos de clientes, redefiniendo que cantidad de direcciones IPv4 se le asignarían a cada servicio alineándolos a la ultima política de LACNIC. El mayor impacto lo causó el punto 2.3.2.8. Webhosting de la actual política que afectaba a clientes de datacenter.
Estas modificaciones fueron coordinadas por el área de procesos corporativos, que documentó y publicó en el portal interno los procesos acordados
Plan de recuperación de direcciones IP
Para llevar a cabo un plan de recuperación de direcciones IPv4 subutilizadas, se coordinó una Task Force para este fin, dando como resultado la recuperación de una gran cantidad de redes.
Concientización sobre agotamiento de IPv4 y un plan de introducción de IPv6
Reuniones con diferentes areas de la empresa transmitiéndoles “la noticia”, resolviendo dudas y mitos sobre el tema:
– Internet no se va a detener.
– Habrá direcciones IPv4 en producción en las redes por muchos años (de diferentes formas)
– IPv6 no sustituye a IPv4
– IPv6 es la evolución de IPv4
– No se trata de deshabilitar IPv4 para habilitar IPv6. NO ES UNA MIGRACIÓN
La implementación de IPv6 implica que IPv4 estará coexistiendo con IPv6, siendo las aplicaciones las responsables de decidir cual protocolo usarán.
Análisis de impacto en los sistemas de la compañía
Se analizó que sistemas se verían impactados y en qué plazo para realizar un plan de adecuación.
Experiencia en Activación de Servicio con IPv6
Se requirió un periodo de prueba de campo para estabilizar el servicio.
Las pruebas se iniciaron en la modalidad de túneles manuales IPv6 sobre IPv4. La solución se extendió hasta el upstream provider. Los resultados en esta etapa no fueron satisfactorios debido a la inestabilidad en el ruteo y la dificultad operativa en Identificación de problemas?
(complejidad y ruteo sub-óptimo).
Al migrar a la solución doble pila en el acceso, se logro mantener el mismo plano de envío de paquetes para IPv4 e IPV6, logrando una mejor predicción de trayectorias de tráfico y facilidad de la operación industrial a gran escala (simplificación del mantenimiento y la ingeniería).
El costo de la solución es mayor en doble pila (se construyen y mantienen dos redes, seguridad incluida).
Resolución DNS para direcciones IPv6
Se debe contar con un software de DNS Resolver que sea doble-pila, es decir, que soporte todos los elementos de resolución de direcciones IPv4 e IPv6 indistintamente (registros A, AAAA, ptr, etc.) y que este dentro del dominio IPv6 (0.d.3.1.1.0.0.2.ip6.arpa). También se debe realizar la resolución inversa del prefijo /32 asignado, la resolución inversa y directa de los inversos de cada host IPv6. Para la resolución autoritativa también se debe contar software doble-pila .
Como parte de la experiencia en activación de servicio en IPv6, durante octubre de 2010 desarrollamos pruebas de campo para verificar el estado de soporte de la resolucion doble pila en algunos servidores de contenidos, utilizando nuestro resolver de dns doble-pila.
La operación fue verificada en los algunos sitios, a los cuales es posible alcanzar con servicio de navegación web tanto en IPv4 como en IPv6: www.isoc.org, www.ietf.org, www.iana.org, www.arin.net y www.lacnic.net
En cambio, en sitios como ser www.yahoo.com.ar, www.ebay.com, www.flickr.com, www.linkedin.com y www.facebook.com aún no es posible alcanzarlos con servicio de navegación web en IPv6, dado que no están brindando resolución dns para IPv6, solo para IPv4.
Para el caso www.youtube.com y www.google.com, se utiliza una politica de IPv6 AAAA DNS Whitelist (para calificar requiere DNS servers separados para los usuarios de IPv6, no compartidos con usuarios solo de IPv4)
Desafíos en la Interconexión
Hipótesis:
“ Cuando una determinada cantidad de clientes tengan la posibilidad de acceder a IPv6, una parte de sus comunicaciones fallarán….”
Existen varios factores que determinan la calidad del conjunto de las interconexiones en Internet. En particular, debido al estadio temprano de despliegue de IPv6, es importante considerar la existencia de trayectorias con baja latencia, la simetría en trayectos IPv4 e IPv6 para el mismo sitio, la confiabilidad del estado operativo (soporte con procesos industriales), y la conectividad de DNS.
A partir de esta hipótesis, y como parte de la experiencia, verificamos la calidad de las rutas y trayectorias en algunos puntos de Internet, en forma comparativa tanto en IPv4 como en IPV6.
Como conclusión general, observamos que las trayectorias en IPv6 poseen una latencia del mismo orden de magnitud que las de IPv4. En cuanto a la simetría en la trayectoria IPv4-IPv6 para el mismo sitio, se observan asimetrías, siendo un aspecto a mejorar para la confiabilidad a futuro
Consideraciones finales
Para concluir, destacamos puntos importantes para tener en cuenta en la transición hacia IPv6 desarrollados (recomendaciones extraidas de la IETF RFC 6036, octubre de 2010- Emerging Service Provider Scenarios for IPv6 Deployment, informational, survey of a number of ISPs carried out in early 2010).
“Sin clientes que deseen IPv6, conseguir el respaldo de negocio es muy duro, el crecimiento y la seguridad de IPV6 no fue un foco para los vendedores hasta hace muy poco. Los operadores carecen de experiencia real en el uso de IPv6 con sus clientes, y la consiguiente falta de confianza causa demora en la adopción…”.
“La atención al cliente debe ser consciente de que IPv6 se está iniciando en la red o servidores. Hemos experimentado muchos bloqueos de aplicaciones en IPv6, aplicaciones que no hacen fallback a IPv4…”.
“La evangelización sigue siendo una necesidad, ya que parece que muchos ISP todavía no son conscientes de la necesidad de un plan de introducción de IPv6, y están inclinados a tomar el agotamiento de IPv4 como una falsa alarma, y parece también no ser conscientes de que NAT crea requisitos costosos de soporte”.
Y finalmente:
Don’t panic! The web isn’t full to capacity – yet
Agradecimientos:
A nuestros gerentes y directores que nos apoyan incondicionalmente en este proyecto y al equipo de trabajo que lo hace posible
Ing. Gabriel Castro
Gerencia Ingeniería de Transporte – Gerencia Ingeniería- Dirección de Tecnología- Dirección Red –TELECOM ARGENTINA
Ing. Marta Astaco
Gerencia Aseguramiento de Redes y Servicios- Dirección de Aseguramiento y Provisión de Redes y Servicios- Dirección Red- TELECOM ARGENTINA