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