1
“Transición de IPv4 a IPv6 bajo un enfoque de la gestión de las Tecnologías de Información”
Alumno: César Benítez Jiménez
Matrícula: 04343976
Materia: Telecomunicaciones en la empresa
Profesor: César García Martínez
Carrera: Maestría en Gestión de las TI
Agosto de 2009
2
Índice
Introducción ..................................................................................................................... 3
Problemática a resolver .................................................................................................. 3
Marco Teórico .................................................................................................................. 4
¿Qué es IPv6? ............................................................................................................... 4
Diferencias técnicas entre los protocolos IPv4 e IPv6 .................................................... 6
Metodología para la transición ..................................................................................... 13
Descripción conceptual ............................................................................................... 13 Mecanismos de túnel ................................................................................................... 13
Propuesta de Solución .................................................................................................. 15
Descripción de la propuesta ......................................................................................... 15 Perspectiva del proyecto de transición .................................................................... 15
Acerca del autor ............................................................................................................. 20
Bibliografía ..................................................................................................................... 21
3
Introducción
Cuando hablamos de la nueva era de un mundo globalizado donde es cada vez mayor el uso de
aplicaciones que operan a través de la Internet, no nos preguntamos como funciona esta red de redes,
simplemente exigimos, cada vez con mayor fuerza como consumidores, que los mecanismos implantados
en ésta red, funcionen adecuadamente en todo momento. Si consideramos además que la movilidad, es
una de las funcionalidades que la informática y las telecomunicaciones han traído recientemente a un gran
porcentaje de los habitantes del orbe, no pasa por nuestra mente la complejidad que implica proveer tales
servicios a un precio cada vez más bajo, de manera eficiente y en forma segura.
Es en este contexto que, como parte de la materia de Telecomunicaciones en la empresa y como parte del
programa de maestría de gestión en tecnologías de información, he desarrollado el presente trabajo, el
cual está orientado a proveer un contexto de la imperiosa necesidad que las organizaciones, tanto públicas
como privadas, deben considerar en el futuro relativamente cercano, como una estrategia técnica y táctica
para implantar la versión seis del protocolo usado en la Internet, el cual referiremos en lo sucesivo como
IPv6.
Problemática a resolver
Se ha identificado hasta el momento como el centro de la problemática, el agotamiento de direcciones
públicas del protocolo de Internet como la principal razón por la cual es necesario definir una estrategia
que permita la paulatina convivencia de la versión que actualmente soporta las aplicaciones de Internet
(IPv4). El concepto anterior, ha sido hasta ahora soportado mediante algunos mecanismos que permiten
compartir una dirección pública a múltiples direcciones privadas hacia el interior de una organización, pero
lamentablemente, el gran crecimiento del número de dispositivos móviles y el crecimiento de aplicaciones
desarrolladas, como lo son las aplicaciones multimedia para estos dispositivos, implica que se requiere
integrar los mecanismos que aseguren el servicio en todas las características necesarias de confiabilidad,
eficiencia, costo y seguridad de la información.
Dado que es menester de la administración de la tecnología informática proveer de tales mecanismos, el
protocolo IPv6 los provee de manera implícita de modo que, ante la adaptación de este nuevo modelo, no
solo se permite, sino que se obliga la implantación de los mismos. Consecuentemente, ante la resolución
de la principal problemática, el desarrollo de la tecnología que reemplace al protocolo previo, debió
realizarse de modo que se mejoraran varios de los aspectos que la versión anterior no consideró bajo el
contexto en el que nos encontramos y por ende deben resaltarse como beneficios que la transición
conlleva.
4
Además de resolver el problema principal del límite de direcciones, las siguientes características forman
parte de los beneficios derivados de la implantación de IPv6:
Administración más eficiente de las direcciones
Eliminación de los métodos que permitieron extender la vida del protocolo IPv4
Administración más sencilla del protocolo TCP/IP
Diseño moderno para el enrutamiento de los paquetes en las redes
Mejor soporte para el [multicasting]1
Mejor soporte para la seguridad
Mejor soporte para las redes y los dispositivos móviles
Marco Teórico
¿Qué es IPv6?
IPv6 es un protocolo de capa de red, el cual de la misma forma que IPv4 no está orientado a
conexión, sin garantía de envío (es decir no hay retransmisiones por el protocolo en sí mismo), sin
capacidad de control de lujo ni manejo de congestión.
Si tomamos como referencia el modelo OSI, este protocolo opera precisamente en la capa de red,
de la misma manera que lo hace su antecesor hoy en día. La figura no.1 denota su ámbito de
aplicación.
Figura 1. Ámbito de aplicación del protocolo IPv6
Fuente: Introducción al IPv6 por Roque Gagliano LACNIC Latinoamérica
1 Muticasting: Método que permite transmitir una señal de datos a múltiples locaciones de manera simultánea, lo cual permite el uso
adecuado de la capacidad de los enlaces de datos.
5
IPv6 es una versión mejorada al protocolo IPv4 del cual se había pronosticado su desaparición
hacia los principios del siglo XXI, sin embargo, dada la aparición de algunos mecanismos como la
traducción de direcciones de red (NAT pos sus siglas del inglés) hacia el año 1993, el agotamiento
de direcciones públicas del Internet se prolongo por varios años mas. Acorde a Geoff Huston del
Asia Pacific [NIC]2 tal agotamiento fue planeado para ocurrir hacia finales del año 2010, sin
embargo ante la aparición de los mecanismos mencionados, se anticipa ahora que durante varios
años los dos protocolos deberán convivir de manera simultánea hasta el año 2030
aproximadamente. La figura 2 muestra el plan originalmente concebido por la fuerza de tarea de
transición a IPv6 en el área de Asia Pacífico.
Figura 2. Plan original de transición hacia IPv6. Fuente Introducción a IPv6 por Roque Gagliano, LACNIC Latinoamérica
Dado que es evidente que el plan original de transición a IPv6 no tuvo mayor impacto en las
operaciones de tecnologías de información se plantea un nuevo escenario donde se sostiene que
ambos protocolos convivirán hasta el año 2030 aproximadamente. Este plan lo representa
Gagliano en la figura 3 a continuación
2 Planificando IPv6, Portal IPv6 {en línea http://portalipv6.lacnic.net/es/ipv6/documentos/presentaciones}
6
Figura 3. Nuevo plan de transición hacia IPv6. Fuente Planificación de IPv6 por Roque Gagliano, LACNIC Latinoamérica
Diferencias técnicas entre los protocolos IPv4 e IPv6
Direccionamiento
Acorde a [Kozierok]3, la primera razón técnica entre los dos protocolos radica en el número de bits
que se emplean para representar direcciones. En el protocolo IPv4, el número de bits empleados
para representar una dirección estaba limitado a 32 bits, separados en cuatro bytes de ocho bits
cada uno. Dada esta representación el límite teórico máximo de direcciones utilizables era de 2 x
1032
direcciones ó 4,294,967,296 direcciones, de las cuales un porcentaje se desperdiciaba por los
mecanismos especificados para pruebas y/ó aplicaciones especificas. La representación de estos
bytes para las personas que administraban las redes operando en este protocolo los denotaban
como cuatro octetos en nomenclatura decimal separados por puntos de la forma AA.BB.CC.DD,
donde cada valor podía tomar desde cero hasta 255 como máximo.
Por su parte el protocolo IPv6 emplea 128 bits para esta representación, otorgando un número
infinitamente grande de direcciones máximas a ser empleadas. Este número podemos
representarlo como 3.4 x 1038
, por lo que sobra decir que esta capacidad de direcciones debiera
ser suficiente para muchos años mas de operaciones tecnológicas en el mundo.
El formato de direcciones en IPv6 se representa en forma hexadecimal mediante dieciséis campos
separados por dos puntos (:), agregando algunas reglas para proveer un resumen en las
3 Charles M. Kozierok, The TCP/IP Guide, Chapter 24, IPV6 Overview, Changes and Transition
7
direcciones y así proveer mecanismos de administración más simple. El formato de tal
direccionamiento toma entonces el formato de ocho palabras de dieciséis bits cada una
AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:GGGG:HHHH
En este formato es posible realizar un resumen de las direcciones cuando existan campos
consecutivos de las palabras con valor cero. Esto es, si se tiene la dirección
805B:2D9D:DC28:0000:0000:FC57:D4C8:1FFF al aplicar la regla que acabamos de mencionar, la
misma dirección se representaría como 805B:2D9D:DC28::FC57:D4C8:1FFF. A esta convención
se le denomina como compresión de ceros y sólo puede aplicarse en una ocasión en una dirección
del formato IPv6.
La representación empleada para el direccionamiento de IPv6 tiene además algunas restricciones
de asignación, según lo especifica el IANA, organismo asignado para la administración de
direcciones en el Internet y se simplifica en el cuadro a continuación:
IPv6 Prefix Allocation Reference ----------- ---------- --------- 0000::/8 Reserved by IETF [RFC4291] 0100::/8 Reserved by IETF [RFC4291] 0200::/7 Reserved by IETF [RFC4048] 0400::/6 Reserved by IETF [RFC4291] 0800::/5 Reserved by IETF [RFC4291] 1000::/4 Reserved by IETF [RFC4291] 2000::/3 Global Unicast [RFC4291] 4000::/3 Reserved by IETF [RFC4291] 6000::/3 Reserved by IETF [RFC4291] 8000::/3 Reserved by IETF [RFC4291] A000::/3 Reserved by IETF [RFC4291] C000::/3 Reserved by IETF [RFC4291] E000::/4 Reserved by IETF [RFC4291] F000::/5 Reserved by IETF [RFC4291] F800::/6 Reserved by IETF [RFC4291] FC00::/7 Unique Local Unicast [RFC4193] FE00::/9 Reserved by IETF [RFC4291] FE80::/10 Link Local Unicast [RFC4291] FEC0::/10 Reserved by IETF [RFC3879] FF00::/8 Multicast [RFC4291]
Cuadro 1: Direcciones reservadas según el IANA. Fuente http://www.iana.org/assignments/ipv6-address-space
Según [Kozierok]4, Los tipos de direcciones que encontramos en IPv6 son tres y nos sirven para
identificar tanto origen como destino:
Unicast: Son aquellas que representan una interface única hacia un sistema único a
la vez. Los paquetes son enviados sólo a un destino.
Multicast: Representa aquellos casos donde desde una interface se generan
datagramas hacia varios destinos al mismo tiempo, pero no a todos.
Anycast: Este representa un caso especial donde un paquete se envía a múltiples
destinos, no a todos, solo algunos al mismo tiempo, seleccionados según convenga.
Esta es una implementación única de IPv6.
4 Charles M. Kozierok, The TCP/IP Guide, Chapter 25, IPV6 Addressing
8
A diferencia de IPv4, no existe el concepto de broadcast, el cual estaba destinado para enviar un
paquete a todos los dispositivos de la misma red (o subred si fuera el caso).
Encabezado de IPv4 vs. El encabezado de IPv6
Dentro de las especificaciones técnicas entre los dos protocolos, la primera diferencia que
encontramos es el formato del [encabezado]5 de los paquetes entre los dos protocolos.
El primero de los campos del encabezado es la versión, la cual como es de esperarse se usaba
con un valor 4 para IPv4 y debe usar 6 para el protocolo IPv6.
El segundo de los campos6 es un valor de cuatro bits, el cual tiene dos esquemas de aplicación. El
primero de ellos acorde al RFC 1883, se utiliza cuando desde la perspectiva del dispositivo que los
envía, se puede controlar la congestión en el medio. Los usos de este campo se denotan como se
indica a continuación:
Valor Tipo de tráfico 0 Tráfico no caracterizado 1 Tráfico de llenado de muy baja prioridad (Noticias por ejemplo) 2 Transferencia de datos no atendida (e-mail por ejemplo) 3 Uso reservado 4 Transferencia de datos masiva (FTP o NFS por ejemplo) 5 Uso reservado 6 Tráfico interactivo (Telnet o terminal remota por ejemplo) 7 Tráfico de control de Internet (protocolos ruteo por ejemplo)
El segundo método de aplicación de este campo se refiere a cuando el dispositivo que envía los
datos no tiene control sobre la congestión del medio y por tanto se deben enviar los datagramas7
en forma continua para que lleguen al destino en forma continua. Los valores restantes de la tabla
(8-15) son los disponibles para este método.
El tercero de los campos del RFC 1883, se refiere al manejo de una etiqueta de flujo de los datos.
Este campo se emplea para dar un tratamiento especial a los paquetes (desde la perspectiva del
dispositivo que lo genera), ya sea unicast8 o multicast y tiene que ver con aplicaciones de uso
futuro principalmente.
El cuarto de los campos del encabezado de los paquetes de IPv6 se podría traducir como carga y
se refiere a la cantidad de datos que lleva el paquete. Dado que se emplean 16 bits para tal
representación un solo paquete puede contener entonces hasta 65,536 bytes de longitud. Una
característica inherente en IPv6 es el tratamiento de paquetes jumbo, y en cuyo caso este campo
se indica como cero y el valor verdadero deberá ser indicado en la extensión de encabezado
llamada salto por salto.
El quinto de los campos se refiere a la identificación de un paquete posterior a ser enviado.
5 [encabezado] Douglas E. Comer, Redes globables de información con Internet y TCP/IP, Capítulo 29
6 Nota: Aunque en IPv4 algunos de los campos tenían especificación para manejar calidad de servicio, ésta aplicación era rara vez
habilitada por parte de los fabricantes de equipo de telecomunicaciones. En IPv6 ésta aplicación es forzosa. 7 Datagrama: Forma de unidad de datos para la capa de red de acuerdo al modelo OSI.
8 Unicast: Envío de información desde un único emisor a un único receptor.
9
El sexto campo se indica como límite de saltos y de manera análoga al campo TTL de IPv4 sirve
para indicar el número máximo de dispositivos por los que ese paquete puede pasar antes de
llegar al destinatario.
Los últimos dos campos del encabezado de IPv6 se emplean para indicar la dirección IP del origen
(sexto campo) y la dirección IP del destino (séptimo campo)
La siguiente figura denota los cambios entre los encabezados de los paquetes IPv4 vs. IPv6.
Figura 4. Comparación en el formato de direcciones entre ambos protocolos. Fuente seminario de migración a IPv6, en
línea {http://www.fh-wedel.de/~si/seminare/ws08/Ausarbeitung/08.ipv6/layout2.html}
Encabezados de extensión en IPv6
Precisa Kozierok que dentro de las singularidades de los [encabezados]9 de IPv6 tiene que ver con
la posibilidad de crear paquetes Jumbo según observamos en la especificación de los campos de
estos paquetes. Para obtener aún mejoras mayores con la implantación del nuevo protocolo, se
crearon algunas particularidades que facilitan el procesamiento más eficiente de este protocolo y
tales especificaciones se incluyeron como encabezados de extensión. Dado el contexto del
presente trabajo, nos limitaremos a enlistar tales usos en la tabla anexa, y solo mencionaremos
que durante el intercambio de datos (transmisión) puede observarse la aplicación de estos
códigos en el orden que están listados:
Tipo de encabezado Valor del campo Siguiente encabezado
Opciones salto-a-salto 0
Encabezado de ruteo 43
Encabezado de fragmento 44
Carga de encapsulamiento10
de seguridad 50
9 Charles M. Kozierok, The TCP/IP Guide, Chapter 26, Datagram encapsulation and Formating
10 Encapsulamiento: Es el proceso por el cual los datos que se deben enviar a través de una red se deben colocar en paquetes que
se puedan administrar y rastrear y consiste en ocultar los detalles de implementación de un objeto, pero a la vez se provee una interfaz pública por medio de sus operaciones permitidas.
10
Encabezado de autenticación 51
Encabezado de opciones del destino 60
No hay siguiente encabezado 59
Aplicaciones de red
ICMPv6
Dado que IPv6 es una versión más reciente que IPv4, el protocolo ICMP fue mejorado de manera
significativa. IGMP también ha sido implementado dentro de ICMPv6. De propósito múltiple y
diseñado para realizar funciones tales como detectar errores en la interpretación de paquetes,
realizar diagnósticos, realizar funciones como descubrimiento de vecinos y detectar direcciones
IPv6 multicast. Los mensajes ICMPv6 están subdivididos en dos clases: mensajes de error y
mensajes informativos. Los mensajes ICMPv6 son enviados dentro de paquetes IPv6 los cuales a
su vez pueden llevar las extensiones de encabezado de IPv6.
La lista siguiente contiene los mensajes de error en IPv6:
1 Destino Inalcanzable 2 Paquete Demasiado Grande 3 Tiempo Agotado 4 Problema de Parámetros
Así mismo existen los mensajes informativos, los cuales proveen de mensajes de diagnóstico,
mensajes para la administración de grupos multicast y mensajes de descubrimiento de vecinos.
Como ejemplo se enlistan dos códigos del tipo de diagnóstico.
128 Solicitud de Eco 129 Respuesta de Eco
El soporte de ICMPv6 es obligatorio en cualquiera de las implementaciones de interfaces de IPv6.
DNS en IPv6
Las direcciones IPv6 se representan en el Sistema de Nombres de Dominio (DNS) mediante
registros AAAA (también llamados registros de cuádruple A ó quad-A, por tener una longitud
cuatro veces la de los registros A para IPv4). Este concepto integra parte de las mejoras
significativas en IPv6 y fue una de las dos propuestas al tiempo que se estaba diseñando la
arquitectura IPv6. El RFC 3596 es el estándar propuesto para implementación del modelo AAAA
dentro de IPv6.
Mecanismos de Transición
Como premisa al diseño de IPv6, se especificó que el nuevo protocolo debía coexistir con la
versión 4 del protocolo IP. Para ello, se desarrollaron junto con el mismo los mecanismos de
transición. Los mecanismos de transición se dividen en 3 grupos:
11
Doble pila
Traducción
Túneles
Doble pila
Se trata de mantener en simultáneo en un dispositivo, tanto la pila del protocolo IPv4, como la de
IPv6. De esta manera, dependiendo de la pila que tenga implementada el nodo al cual queremos
comunicarnos, es la pila IPv4 o IPv6 que se utilizará.
Traducción
Este mecanismo de transición realiza una "traducción" similar a la que efectúa el NAT, donde es
modificada la cabecera IPv4 a una cabecera IPv6.
El más conocido dentro de este grupo es NAT-PT. Sin embargo, este tipo de mecanismos no es
de los más recomendados.
Túneles
Cuando un paquete IPv6 tiene que ser transportado a través de una red que sólo es IPv4, pueden
utilizarse túneles para lograrlo. Un túnel trabaja encapsulando un paquete IPv6 dentro de un
paquete IPv4 para que el mismo pueda viajar por estas redes. El paquete es a su vez
desencapsulado al llegar al destino, que deberá ser un nodo IPv6 o doble pila.
Túneles IPv6 sobre IPv4
Los túneles proporcionan un mecanismo para utilizar la infraestructura montada bajo IPv4 mientras
avance la transición hacia el pleno soporte de IPv6. Este mecanismo consiste en el
encapsulamiento de datagramas IPv6 en paquetes IPv4. Los extremos finales del túnel siempre
son los responsables de realizar la operación de encapsulado y/ó desencapsulado de paquetes.
Los túneles pueden ser utilizados de formas diferentes:
Router a router. Routers con doble pila (IPv6/IPv4) se conectan mediante una
infraestructura IPv4 y transmiten tráfico IPv6. El túnel comprende un segmento que incluye
la ruta completa, extremo a extremo, que siguen los paquetes IPv6.
Host a router. Hosts de doble pila se conectan a un router intermedio (también de
doble pila), alcanzable mediante una infraestructura IPv4. El túnel comprende el
primer segmento de la ruta seguida por los paquetes.
12
Host a host. Hosts de doble pila interconectados por una infraestructura IPv4. El
túnel comprende la ruta completa que siguen los paquetes.
Router a host. Routers de doble pila que se conectan a hosts también de doble pila. El
túnel comprende el último segmento de la ruta.
Los túneles se clasifican según el mecanismo por el que el nodo que realiza el encapsulado
determina la dirección del nodo extremo del túnel. En los dos primeros casos (router a router y
host a router), el paquete IPv6 es creado hacia un router. El extremo final de este tipo de túnel es
un router intermedio que debe desencapsular el paquete IPv6 y reenviarlo a su destino final. En
este caso, el extremo final del túnel es distinto del destino del destino final del paquete, por lo que
la dirección en el paquete IPv6 no proporciona la dirección IPv4 del extremo final del túnel. La
dirección del extremo final del túnel ha de ser determinada a través de información de
configuración en el nodo que realiza el túnel. Es lo que se denomina “túnel configurado”,
describiendo aquel tipo de túnel cuyo extremo final es explícitamente configurado (Algunos autores
describen este túnel como manual)
En los otros dos casos (host a host y router a host), el paquete IPv6 es encapsulado durante todo
el recorrido a su nodo destino. El extremo final del túnel es el nodo destino del paquete, y por
tanto, la dirección IPv4 está contenida en la dirección IPv6. Este caso se denomina “túnel
automático”.
Protocolos de doble pila
En general, el término doble pila se refiere a una duplicación completa de todos los niveles de la
pila de protocolos de aplicaciones en la capa de red. Un ejemplo de duplicación completa es un
sistema que ejecuta los protocolos OSI y TCP/IP.
Son múltiples los sistemas operativos que traen sus propias implementaciones de doble pila para
IPv4 e IPv6. Entre ellos que se encuentran, Windows XP, Windows Vista, Solaris y varias
instancias de LINUX. Al instalar el sistema operativo, se elige entre habilitar los protocolos IPv6 en
la capa de IP o utilizar únicamente los protocolos IPv4 predeterminados. El resto de la pila TCP/IP
es idéntica. Por lo tanto, en IPv4 e IPv6 pueden ejecutarse los mismos protocolos de transporte,
TCP UDP y SCTP. Además, se pueden ejecutar las mismas aplicaciones. La figura anexa muestra
una vista concebida desde el enfoque del modelo OSI.
13
Figura 5: En este marco de referencia los subconjuntos de enrutamiento y hosts se actualizan para admitir IPv6, además de
IPv4 en forma simultánea. Fuente: Guía de administración del sistema: servicios IP de Sun Microsystems, Abril de 2009.
Metodología para la transición
Descripción conceptual
Como parte del presente trabajo no se encontró consenso respecto al uso de una metodología
generalmente aceptada para la transición a IPv6. Varios organismos continúan realizando foros de
discusión y fuerzas de tarea orientadas a desarrollar propuestas integrales para la transición hacia IPv6.
Dado lo anterior resulta evidente que para realizar el proceso de transición, se requieren soportar ambos
protocolos durante varios años, y para ello, en esta sección se refieren los mecanismos disponibles para
implantar IPv6 en las organizaciones. Posteriormente se realizará el enfoque administrativo de los
aspectos gerenciales de manejo del proyecto de adopción desde varias perspectivas.
Mecanismos de túnel
La primera propuesta implica la adopción de que ambos protocolos existirán de manera simultánea
en los clientes, por lo que el uso de túneles para transportar paquetes de datos de IPv6 sobre
redes IPv4 será el primer modelo de adopción del protocolo. Existen varios mecanismos para ello
según se enlista a continuación:
Túnel manual
Esta configuración se aplica en aquellos casos donde el administrador de la red requiere mantener
un control absoluto del tráfico por cada protocolo. Este mecanismo requiere mayor trabajo
administrativo pero incrementa el nivel de control sobre el avance del proyecto de transición. El
uso de este mecanismo obliga emplear traductores de protocolo en el punto de salida de la red de
la organización
14
Túnel automático
Este tipo de túnel facilita su tiempo de implementación pero requiere contemplar los casos
extremos de tráfico, por lo cual el uso no es recomendable fuera de redes cuyo número de
usuarios es muy limitado.
Túnel 6 a 4
Este mecanismo permite hace un mapeo de prefijos desde las direcciones IPv6 hacia las
direcciones IPv4 de destino. Este es un mecanismo ampliamente usado actualmente y seguirá
siendo adecuado aún en aquellas redes que hayan adoptado la mayoría de los clientes en IPv6,
ya que tiene un encabezado menor que otros tipos de túnel.
Túnel broker
Este es un servicio (típicamente ofrecido por terceros) de transporte de red, el cual permite que
usando la infraestructura existente se logra alcanzar destinos que operan en un protocolo
diferente. Como mecanismo de prueba, éste permite tomar una adopción temprana desde los
clientes ó como recurso para el final de la transición.
Túnel Teredo
Este mecanismo permite el transporte de paquetes desde dispositivos de doble pila usando
mecanismos de relevadores y sistemas de traducción de direcciones de IPv4 (NAT por sus siglas
en inglés). Este tipo de túnel ha estado implementado en varios sistemas operativos incluyendo los
de Microsoft, pero no es compatible con todos los mecanismos de traducción existentes.
Consecuentemente a esta situación de incompatibilidad, existe una variante simétrica de este tipo
de túnel, que emplea las siglas SYMTeredo que puede usarse en los casos de incompatibilidad
descritos en esta sección.
Túnel BIS
Este tipo de túnel toma su nombre de las siglas en inglés “Bump in the stack”, permitiendo que
sistemas de cómputo que solo soporten IPv4 en su stack, pueden emplear un componente de
software que realiza las funciones de traducción hacia IPv6, implicando desarrollo para cada
equipo que así lo requiere. Este tipo de túnel podría ser último recurso en algunos casos.
15
Propuesta de Solución
Descripción de la propuesta
En el contexto del presente trabajo, mencionamos que éste se desarrollaría desde una aproximación de la
administración de servicios de Tecnología de Tecnología y por tanto el enfoque de las siguientes
secciones se desarrollará acorde a la estrategia planteada.
Como hemos visto en el marco teórico del presente trabajo, existen algunos mecanismos que permiten
una convivencia de ambos protocolos durante algún tiempo. Dado que no es objetivo del presente trabajo
identificar los aspectos de influencia que provoquen una rápida adopción del protocolo IPv6, el enfoque de
la metodología propuesta se resalta asumiendo que no existe, por ahora, una presión para concluir un
proyecto de transición en un tiempo determinado, sin embargo, asumiremos que la una probable presión
de índole económico se dará a partir del agotamiento de direcciones públicas en el Internet, y ante esto,
los gobiernos de algunos países desarrollados (como Japón) empujarán la implantación de la versión seis
del protocolo IP. Así mismo, dado el grado de avance que hasta ahora se ha logrado en cuanto a la
adopción de IPv6, deberemos también asumir que eventualmente los fabricantes de software y hardware
adoptarán el soporte del protocolo en cuestión en un tiempo determinado que permita a las organizaciones
realizar los planes correspondientes y acorde a los mecanismos presentes para adquisición tecnología.
Perspectiva del proyecto de transición
Desde un punto de vista administrativo, para realizar un plan de transición hacia la adopción de
IPv6 deberíamos comenzar con la definición de un [proyecto]11
, el cual, debe de incluir una fase de
iniciación, una de planificación, una de ejecución y una de cierre. A manera de referencia, el
modelo planteado de resolución se limita a la fase de planeación. Lo anterior implica que, acorde al
contexto estratégico que la tecnología tenga para la empresa, será entonces menester de cada
organización liberar recursos para el proyecto de transición hacia IPv6 (fase de iniciación), el
control de recursos (fase de ejecución), y el proceso para completar la transición (fase de cierre).
Elementos del modelo de proyecto de transición
Dentro de los elementos que se han identificado hasta ahora, se enlistan a continuación los
elementos que conforman parte del alcance del plan de proyecto para la transición, definiendo el
mínimo de los elementos que deberán ser identificados en aquellas organizaciones que deseen
realizar un el proceso iniciación del proyecto.
Infraestructura de telecomunicaciones
11
Project Management Body Of Knowledge, 4ta Edición, Página 12, 2008
16
Dentro de este rubro, es evidente que aquellas organizaciones que se encuentren en la fase
temprana de iniciación del proyecto, evaluarán las razones que los empujen a la realización de
este proyecto. Indistintamente de la razón que lo motive, en este rubro se refieren a los
componentes que deberán ser contemplados como parte del alcance de los trabajos a ser
incluidos en el plan del proyecto.
Redes de área local
Como hemos descrito anteriormente, el protocolo IPv6 es una especificación de la capa de
red del modelo OSI, y por tanto aquellos equipos que trabajen en esta capa deberán ser
integrados dentro del plan de evaluación. Dado que hemos referido un modelo de
transición de coexistencia de los dos protocolos en forma simultánea, como parte de este
rubro deberán ser evaluados los conmutadores de red local, los cuales reciben las
conexiones de los usuarios ya sea en forma alámbrica como inalámbrica (puntos de
acceso). Estos conmutadores tradicionalmente proveen el soporte en las primeras dos
capas del modelo OSI y, en estricta teoría, no deberían de requerir de reemplazo, sin
embargo, algunas versiones poseen la habilidad de realizar funciones de capa tres, y por
ende, el soporte de IPv6 debe ser considerado. Así mismo, aquellos conmutadores que
tengan la capacidad de ser administrados en forma remota, trabajan en conformidad con el
protocolo SNMP, el cual fue modificado acorde al protocolo IPv6 y por tanto requieren del
soporte para la transición.
Así mismo, en este rubro deberán ser considerados algunos servicios de red que han sido
modificados en IPv6. Para organizaciones que emplean el servicio DHCP, éste es uno de
los servicios que han permitido administrar redes en forma eficiente, y que debe ser parte
del plan de transición. Así mismo la resolución de nombres también sufrió cambios y debe
ser evaluada la base instalada en la organización, así como una definición formal del inicio
del soporte del protocolo en IPv6, como parte de la estrategia del resto de los
componentes que se enlistan en esta sección.
Red de área amplia (WAN)
En esta sección debemos considerar que residen la mayoría de los equipos que deben
estar integrados en el alcance del proyecto de transición. Los routers son el principal
elemento que interconecta edificios corporativos con redes de sucursales y con la Internet,
por tanto este es el elemento crucial a ser identificado en el plan de transición. Forman
parte de esta área, otros elementos que soportan la estrategia de seguridad perimetral de
las redes de las organizaciones, como pueden ser detectores de intrusos o los muros de
fuego (firewalls), también se incluyen convertidores de protocolos, puntos de acceso para
redes virtuales, servidores de caché, puntos de interconexión con redes de proveedores y
17
clientes, accesos remotos para asociados, servidores de contenido y el conjunto de
software de monitoreo y administración de todos estos elementos. En este mismo
contexto, el protocolo IPv6 obligó a definir nuevas especificaciones para los protocolos de
intercambio de rutas (ruteo), por lo que para el modelo sugerido es necesario integrar con
prioridad los equipos de esta categoría, previamente al resto de los elementos del proyecto
de transición.
Servicios multimedia (voz, video, aplicaciones de tiempo real)
En este contexto, debemos considerar que en los reciente años, son múltiples los
proveedores que han ido transformando el transporte de estos servicios, a través del
protocolo TCP/IP, y por tanto resulta indispensable en el proceso de levantamiento de
información, identificar aquellos casos donde el soporte por parte del fabricante esté
contemplado. Existe la probabilidad que en algunas ocasiones el soporte de esos
productos ya no se encuentre disponible, lo cual no implica necesariamente que los
equipos tengan que desecharse, pero debe ser evaluada la inconveniencia que esto
represente con el paso del tiempo por administrar dos redes durante varios años. Si los
usuarios finales van a estar forzados a soportar ambos protocolos, entonces no hay una
necesidad apremiante para acelerar el reemplazo de estos equipos. Por otro lado, algunos
de los motivadores que podrían motivar una implantación acelerada, serán aquellas
condiciones donde estos servicios estén integrados en redes privadas de gran magnitud,
debido a que, como referimos previamente, dentro de los beneficios de la versión seis del
protocolo IP, encontramos que hay varios diferenciadores en cuanto al manejo de la
calidad de servicio dentro de los parámetros de IPv6, así como un manejo transparente,
integro y con posibilidad de manejar transmisiones de gran tamaño a lo largo de rutas de
redes distantes. Estos aspectos, son quizás algunas variables que deben ser consideradas
como parte del plan integral de transición y que promuevan una transición en plazos
relativamente cortos por los beneficios identificados acorde al contexto de la organización.
Aplicaciones empresariales/corporativas
En este rubro el proceso de inventario requiere contemplar dos escenarios. Para cada una de las
aplicaciones cuya producción radica en servidores, tanto empresariales como servicios de
terceros, se requiere evaluar el plan de migración, tanto de los servidores que soportan las
aplicaciones, como de aquellos elementos que complementan el servicio, incluyendo, motores de
bases de datos, aplicaciones de usuario y mecanismos de enlace de las aplicaciones. Como es de
esperarse, los servidores que soportan estas aplicaciones deberán soportar en forma nativa el
protocolo IPV6 para integrar su migración en un ambiente controlado. Así mismo, cada aplicación
podrá requerir de la modificación de los componentes de enlace entre aplicaciones (sockets) y con
esto un inventario de todas las aplicaciones es necesario. Adicionalmente, en aquellos casos
18
donde el servidor no pueda ser actualizado, será necesario identificar el impacto de migración de
estas aplicaciones en el futuro, de modo que se soporten debidamente. Si lo amerita la aplicación,
túneles BIS deberán desarrollarse para el soporte continuo ó inclusive pudieran ser necesarios
traductores de protocolo cuando el número de servidores sea elevado.
En el contexto de las aplicaciones, los clientes que se conecten a ellas se consideran en un rubro
por separado en la siguiente sección.
Clientes/Usuarios finales
Un elemento que pudiera resultar relativamente fácil de implementar son los usuarios finales, los
cuales comprenden para una organización, un elemento que tradicionalmente se reemplaza en
tiempos relativamente cortos. Como parte de este escenario, el elemento de la planeación de
versiones de sistema operativo y un inventario completo del parque instalado, resultan ser quizás,
los factores que faciliten o compliquen el plan de transición. Como parte de un conjunto de mejores
prácticas, los administradores de redes de usuario pudieran caer en la tentación de habilitar a los
usuarios finales de manera automática, lo cual reduce el ciclo de implantación, pero complica la
administración. Debemos por tanto considerar que en función de las políticas existentes en la
organización, este rubro debe formar parte integral de los principios administrativos del área de
tecnologías de información.
Aplicaciones integrales de administración
En aquellas circunstancias donde una organización mantenga aplicaciones para administración de
recursos informáticos, un elemento que cobra relevancia es aquel que integra a este rubro, siendo
que al integrar plataformas nuevas tecnológicas, cobra mayor relevancia mantener el mismo nivel
de administración tras la transición al nuevo protocolo. En este contexto, podemos decir que la
plataforma de monitoreo de red, es quizás la práctica que mida, de manera efectiva, que el
proceso de transición ha sido efectuado acorde a las expectativas de servicio definidas por el
proyecto de transición.
Respecto a los costos de implantación del proyecto
Una vez efectuado el inventario correspondiente a los elementos que conforman el proyecto de
transición a IPv6, es necesario que cada uno de ellos contemple las variables de los costos
derivados de equipo nuevo de cómputo y telecomunicaciones, las costos de administración de dos
esquemas de red coexistiendo, el tiempo de afectación en servicios por pruebas y los costos de
diferir la transición hacia tiempos posteriores. En este contexto, un esquema de administración de
riesgos que contemple el peso de los elementos identificados es parte de la visibilidad financiera
que se debe contemplar como parte del plan del proyecto de transición.
El contexto técnico de la organización
19
Uno de los aspectos que pueden alterar el diseño del plan de proyecto es el tiempo que se tome
en la aplicación del soporte el protocolo IPv6 en la agenda de los grupos de gobierno de TI, grupo
de arquitectura tecnológica o estándares corporativos. Dado que cada organización puede integrar
maneras diferentes de adopción de tecnología, este aspecto es sin duda uno que quizás implique
un factor que demore la adopción de IPv6, pero que, una vez liberado, permitiría una adopción
controlada del protocolo.
Políticas
En este contexto, existe la posibilidad de que algunos ambientes de operación mantengan políticas
estrictas para el manejo de los datos en lo que respecta al medio de transmisión, formato de los
paquetes, alternativas de tráfico y uso de redes acorde a especificaciones del contexto de la
organización. Particularmente en esta sección, es necesario identificar que acorde al cambio que
se anticipa por la introducción de IPv6, será necesario realizar reformas a las políticas, según haya
sido identificado en el alcance del proyecto de transición, probado en los distintos ambientes de
laboratorio y efectivamente integrado en los contratos de servicio de proveedores tales como sean
de servicio, de soporte técnico, de administración de la infraestructura técnica, etc.
Dentro de este tenor, debe integrarse que como parte de los beneficios de la transición a IPv6,
algunas características hacia el interior de la organización, en lo que respecta a la asignación de
direcciones, rangos de crecimiento y uso de recursos del internet.
Algunas políticas externas que han sufrido cambios, tienen que ver con la manera como se
asignan direcciones públicas en IPv6, y por tanto, estas han de tener repercusiones en la manera
como se realizan acuerdos de interconexión con empresas terceras como proveedores, socios de
negocio y alianzas estratégicas. El impacto de estos cambios debe ser evaluado como parte del
plan de proyecto de transición.
Conclusiones
Como parte de la gestión de sistemas de información, el proyecto de transición hacia IPv6, debe
contemplar un proceso de inventario de la tecnología existente en una organización, la cual, hoy en día,
tiende a continuar creciendo en un mundo no solo globalizado, sino también completamente
interconectado. Por lo anterior el proceso para realizar una transición ordenada, debe ser evaluado de
manera paulatina, en la medida que cada organización mantenga un ambiente controlado.
Dado que el contexto actual en el cual nos encontramos, aún es posible la coexistencia del protocolo IPv4
con el IPv6, me resulta difícil creer que habrá un presión en el corto plazo para acelerar los procesos de
20
adopción de IPv6, sin embargo, en la agenda de los ejecutivos y el personal técnico relacionados con las
tecnologías de información, resulta importante contemplar los elementos referidos a lo largo del trabajo, en
la agenda tecnológica, de modo tal que como parte de inversiones futuras, se contemple el soporte a IPv6
tanto en el aspecto mismo de la infraestructura como de las operaciones futuras. Este aspecto,
evidentemente implicará en el mediano plazo, que los distintos jugadores de las industrias de tecnologías
de cómputo y telecomunicaciones, deberán acelerar y evidentemente promover la adopción de este
protocolo.
La adopción de IPv6 como tal, provee algunos elementos que permitirán a las organizaciones, proveer
servicios de manera más segura y acorde a niveles de servicio esperados, pero sólo se podrán obtener los
beneficios, si los grupos involucrados en la administración de la tecnología, los grupos que especifican los
estándares de trabajo y los grupos que gobiernan las especificaciones, logran ponerse de acuerdo en un
modelo acorde a las necesidades de cada organización.
Finalmente para los profesionales de las Tecnologías de Información y Telecomunicaciones, nos resulta
evidente que debemos promover el mensaje de los beneficios del protocolo, de modo que soportemos
debidamente a las organizaciones donde tengamos influencia técnica y/ó de toma de decisiones.
Acerca del autor César Benítez, es Licenciado en Sistemas de computación administrativa, graduado de la Universidad del
Valle de México y actualmente cursa la maestría de gestión de tecnologías de información. César cuenta
con más de veinte años de experiencia profesional en empresas de Telecomunicaciones entre las que se
encuentran Alcatel-Lucent, Lucent Tecnologies y AT&T. Como parte de su trayectoria profesional, ha
trabajado en áreas de administración de la tecnología, administración de proyectos y servicio al cliente en
un entorno internacional que integra en especial a países en todo el continente Americano.
21
Bibliografía
Computer Networks, Fourth Edition Andrew S. Tanenbaum Prentice Hall PTR, 2003
TCP/IP Blueprints Bobin Burk, Martin J. Bligh, Thomas Lee et al. SAMS Publishing, 1997
TCP/IP Guide, A comprehensive, Illustrated Internet Protocol Reference Charles M Kozierok No Star Press, 2005
Portal IPv6, en español Portal de Transición a IPv6 de América Latina y el Caribe En línea <http://portalipv6.lacnic.net/>
Guía de los fundamentos para la dirección de proyectos (Guía del PMBOK) 4ta. Edición Project Management Institute, 2008
Redes globales de información con Internet y TCP/IP, 3ra. Edición Douglas E. Comer Pearson, 1995
22
RFCs Consultados como referencia en el IETF En línea <http://www.ietf.org/rfc/rfc1883.txt>
RFC Descriptción
2464 Transmission of IPv6 Packets over Ethernet Networks
2467 Transmission of IPv6 Packets over FDDI Networks
2470 A method for the transmission of IPv6 Packets over TokenRing Networks
2472 IPv6 over PPP
2491 IPv6 over NBMA networks
2492 IPv6 over ATM Networks
2497 Transmission of IPv6 packets over ARCnet networks
2590 Transmission of IPv6 Packets over FrameRelay Networks
2460 IPv6 Specification
2461 Neighbor Discovery for IPv6
3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery
2463 ICMP for IPv6
2675 IPv6 jumbograms
1881 IPv6 Address Allocation Management
1887 An Architecture for IPv6 Unicast Address Allocation
1924 A Compact Representation of IPv6 Addresses
3513 IPv6 Addressing Architecture
3587 An IPv6 Aggregatable Global Unicast Address Format
3177 Recommendations on IPv6 Address Allocations to sites
2375 IPv6 Multicast Address Assignment
3307 Allocation Guidelines for IPv6 Multicast Addresses
2462 IPv6 Stateless Address Autoconfiguration
3484 Default Address Selection for IPv6
2894 Router renumbering for IPv6
2732 Format for Literal IPv6 Addresses in URL's
3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
3633 IPv6 Prefix Options for DHCPv6
3736 Stateless DHCP for IPv6
1886 DNS extensions to support IPV6
2874 DNS extensions to support IPv6 address aggregation and renumbering
3363 Representing IPv6 addresses in DNS
3364 Tradeoffs in DNS Support for IPv6
3646 DNS Configuration options for DHCPv6
3750 Unmanaged Networks IPv6 transition scenarios
2473 Generic Packet Tunneling in IPv6 specification
2893 Transition Mechanisms for IPv6 Hosts and Routers
2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels (6over4)
3056 Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels (6to4)
3053 IPv6 Tunnel broker
3142 An IPv6-to-IPv4 Transport Relay Translator (TCP-UDP Relay)
3089 A Socks-based IPv6-IPv4 gateway mechanism
2767 Dual Stack hosts using the Bump-In-the-Stack technique
3493 Basic Socket Interface Extensions for IPv6
3542 Advanced Sockets API for IPv6
2473 Generic Packet Tunneling in IPv6 specification
2401 Security Architecture for the Internet Protocol
2402 IP Authentication Header
2406 IP Encapsulating Security Protocol (ESP)
3162 Radius on IPv6
3756 IPv6 ND Trust Models and Threats
2711 IPv6 Router Alert Option
2185 Routing Aspects of IPv6 Transition
2545 Use of BGP4 Multiprotocol Extensions for IPv6
Top Related