1

Transicin de IPv4 a IPv6 bajo un enfoque de la gestin de las

Tecnologas de Informacin



Alumno: Csar Bentez Jimnez



Matrcula: 04343976



Materia: Telecomunicaciones en la empresa



Profesor: Csar Garca Martnez



Carrera: Maestra en Gestin de las TI



Agosto de 2009
2

ndice

Introduccin ..................................................................................................................... 3
Problemtica a resolver .................................................................................................. 3
Marco Terico .................................................................................................................. 4
Qu es IPv6? ............................................................................................................... 4
Diferencias tcnicas entre los protocolos IPv4 e IPv6 .................................................... 6
Metodologa para la transicin ..................................................................................... 13
Descripcin conceptual ............................................................................................... 13
Mecanismos de tnel ................................................................................................... 13
Propuesta de Solucin .................................................................................................. 15
Descripcin de la propuesta ......................................................................................... 15
Perspectiva del proyecto de transicin .................................................................... 15
Acerca del autor ............................................................................................................. 20
Bibliografa ..................................................................................................................... 21
3

Introduccin

Cuando hablamos de la nueva era de un mundo globalizado donde es cada vez mayor el uso de
aplicaciones que operan a travs 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 adems que la movilidad, es
una de las funcionalidades que la informtica y las telecomunicaciones han trado 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 ms 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 maestra de gestin en tecnologas de informacin, he desarrollado el presente trabajo, el
cual est orientado a proveer un contexto de la imperiosa necesidad que las organizaciones, tanto pblicas
como privadas, deben considerar en el futuro relativamente cercano, como una estrategia tcnica y tctica
para implantar la versin seis del protocolo usado en la Internet, el cual referiremos en lo sucesivo como
IPv6.

Problemtica a resolver

Se ha identificado hasta el momento como el centro de la problemtica, el agotamiento de direcciones
pblicas del protocolo de Internet como la principal razn por la cual es necesario definir una estrategia
que permita la paulatina convivencia de la versin que actualmente soporta las aplicaciones de Internet
(IPv4). El concepto anterior, ha sido hasta ahora soportado mediante algunos mecanismos que permiten
compartir una direccin pblica a mltiples direcciones privadas hacia el interior de una organizacin, pero
lamentablemente, el gran crecimiento del nmero de dispositivos mviles 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 caractersticas necesarias de confiabilidad,
eficiencia, costo y seguridad de la informacin.

Dado que es menester de la administracin de la tecnologa informtica proveer de tales mecanismos, el
protocolo IPv6 los provee de manera implcita de modo que, ante la adaptacin de este nuevo modelo, no
solo se permite, sino que se obliga la implantacin de los mismos. Consecuentemente, ante la resolucin
de la principal problemtica, el desarrollo de la tecnologa que reemplace al protocolo previo, debi
realizarse de modo que se mejoraran varios de los aspectos que la versin anterior no consider bajo el
contexto en el que nos encontramos y por ende deben resaltarse como beneficios que la transicin
conlleva.

4

Adems de resolver el problema principal del lmite de direcciones, las siguientes caractersticas forman
parte de los beneficios derivados de la implantacin de IPv6:
Administracin ms eficiente de las direcciones
Eliminacin de los mtodos que permitieron extender la vida del protocolo IPv4
Administracin ms sencilla del protocolo TCP/IP
Diseo 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 mviles


Marco Terico
Qu es IPv6?
IPv6 es un protocolo de capa de red, el cual de la misma forma que IPv4 no est orientado a
conexin, sin garanta de envo (es decir no hay retransmisiones por el protocolo en s mismo), sin
capacidad de control de lujo ni manejo de congestin.
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 da. La figura no.1 denota su mbito de
aplicacin.

Figura 1. mbito de aplicacin del protocolo IPv6
Fuente: Introduccin al IPv6 por Roque Gagliano LACNIC Latinoamrica


1
Muticasting: Mtodo que permite transmitir una seal de datos a mltiples locaciones de manera simultnea, lo cual permite el uso
adecuado de la capacidad de los enlaces de datos.
5

IPv6 es una versin mejorada al protocolo IPv4 del cual se haba pronosticado su desaparicin
hacia los principios del siglo XXI, sin embargo, dada la aparicin de algunos mecanismos como la
traduccin de direcciones de red (NAT pos sus siglas del ingls) hacia el ao 1993, el agotamiento
de direcciones pblicas del Internet se prolongo por varios aos mas. Acorde a Geoff Huston del
Asia Pacific [NIC]
2
tal agotamiento fue planeado para ocurrir hacia finales del ao 2010, sin
embargo ante la aparicin de los mecanismos mencionados, se anticipa ahora que durante varios
aos los dos protocolos debern convivir de manera simultnea hasta el ao 2030
aproximadamente. La figura 2 muestra el plan originalmente concebido por la fuerza de tarea de
transicin a IPv6 en el rea de Asia Pacfico.

Figura 2. Plan original de transicin hacia IPv6. Fuente Introduccin a IPv6 por Roque Gagliano, LACNIC Latinoamrica

Dado que es evidente que el plan original de transicin a IPv6 no tuvo mayor impacto en las
operaciones de tecnologas de informacin se plantea un nuevo escenario donde se sostiene que
ambos protocolos convivirn hasta el ao 2030 aproximadamente. Este plan lo representa
Gagliano en la figura 3 a continuacin

2
Planificando IPv6, Portal IPv6 {en lnea http://portalipv6.lacnic.net/es/ipv6/documentos/presentaciones}
6


Figura 3. Nuevo plan de transicin hacia IPv6. Fuente Planificacin de IPv6 por Roque Gagliano, LACNIC Latinoamrica


Diferencias tcnicas entre los protocolos IPv4 e IPv6

Direccionamiento
Acorde a [Kozierok]
3
, la primera razn tcnica entre los dos protocolos radica en el nmero de bits
que se emplean para representar direcciones. En el protocolo IPv4, el nmero de bits empleados
para representar una direccin estaba limitado a 32 bits, separados en cuatro bytes de ocho bits
cada uno. Dada esta representacin el lmite terico mximo de direcciones utilizables era de 2 x
10
32
direcciones 4,294,967,296 direcciones, de las cuales un porcentaje se desperdiciaba por los
mecanismos especificados para pruebas y/ aplicaciones especificas. La representacin 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 poda tomar desde cero hasta 255 como mximo.

Por su parte el protocolo IPv6 emplea 128 bits para esta representacin, otorgando un nmero
infinitamente grande de direcciones mximas a ser empleadas. Este nmero podemos
representarlo como 3.4 x 10
38
, por lo que sobra decir que esta capacidad de direcciones debiera
ser suficiente para muchos aos mas de operaciones tecnolgicas en el mundo.

El formato de direcciones en IPv6 se representa en forma hexadecimal mediante diecisis 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 administracin ms simple. El formato de tal
direccionamiento toma entonces el formato de ocho palabras de diecisis 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 direccin
805B:2D9D:DC28:0000:0000:FC57:D4C8:1FFF al aplicar la regla que acabamos de mencionar, la
misma direccin se representara como 805B:2D9D:DC28::FC57:D4C8:1FFF. A esta convencin
se le denomina como compresin de ceros y slo puede aplicarse en una ocasin en una direccin
del formato IPv6.

La representacin empleada para el direccionamiento de IPv6 tiene adems algunas restricciones
de asignacin, segn lo especifica el IANA, organismo asignado para la administracin de
direcciones en el Internet y se simplifica en el cuadro a continuacin:

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 segn el IANA. Fuente http://www.iana.org/assignments/ipv6-address-space

Segn [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 slo 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 enva a mltiples
destinos, no a todos, solo algunos al mismo tiempo, seleccionados segn convenga.
Esta es una implementacin 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 tcnicas 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 versin, 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 campos
6
es un valor de cuatro bits, el cual tiene dos esquemas de aplicacin. El
primero de ellos acorde al RFC 1883, se utiliza cuando desde la perspectiva del dispositivo que los
enva, se puede controlar la congestin en el medio. Los usos de este campo se denotan como se
indica a continuacin:
Valor Tipo de trfico
0 Trfico no caracterizado
1 Trfico 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 Trfico interactivo (Telnet o terminal remota por ejemplo)
7 Trfico de control de Internet (protocolos ruteo por ejemplo)

El segundo mtodo de aplicacin de este campo se refiere a cuando el dispositivo que enva los
datos no tiene control sobre la congestin del medio y por tanto se deben enviar los datagramas
7

en forma continua para que lleguen al destino en forma continua. Los valores restantes de la tabla
(8-15) son los disponibles para este mtodo.
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 unicast
8
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 podra traducir como carga y
se refiere a la cantidad de datos que lleva el paquete. Dado que se emplean 16 bits para tal
representacin un solo paquete puede contener entonces hasta 65,536 bytes de longitud. Una
caracterstica 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 extensin de encabezado
llamada salto por salto.
El quinto de los campos se refiere a la identificacin de un paquete posterior a ser enviado.

5
[encabezado] Douglas E. Comer, Redes globables de informacin con Internet y TCP/IP, Captulo 29
6
Nota: Aunque en IPv4 algunos de los campos tenan especificacin para manejar calidad de servicio, sta aplicacin era rara vez
habilitada por parte de los fabricantes de equipo de telecomunicaciones. En IPv6 sta aplicacin es forzosa.
7
Datagrama: Forma de unidad de datos para la capa de red de acuerdo al modelo OSI.
8
Unicast: Envo de informacin desde un nico emisor a un nico receptor.
9

El sexto campo se indica como lmite de saltos y de manera anloga al campo TTL de IPv4 sirve
para indicar el nmero mximo 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 direccin IP del origen
(sexto campo) y la direccin IP del destino (sptimo campo)

La siguiente figura denota los cambios entre los encabezados de los paquetes IPv4 vs. IPv6.

Figura 4. Comparacin en el formato de direcciones entre ambos protocolos. Fuente seminario de migracin a IPv6, en
lnea {http://www.fh-wedel.de/~si/seminare/ws08/Ausarbeitung/08.ipv6/layout2.html}

Encabezados de extensin 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 segn observamos en la especificacin de los campos de
estos paquetes. Para obtener an mejoras mayores con la implantacin del nuevo protocolo, se
crearon algunas particularidades que facilitan el procesamiento ms eficiente de este protocolo y
tales especificaciones se incluyeron como encabezados de extensin. 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 (transmisin) puede observarse la aplicacin de estos
cdigos en el orden que estn listados:

Tipo de encabezado Valor del campo Siguiente encabezado
Opciones salto-a-salto 0
Encabezado de ruteo 43
Encabezado de fragmento 44
Carga de encapsulamiento
10
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 travs de una red se deben colocar en paquetes que
se puedan administrar y rastrear y consiste en ocultar los detalles de implementacin de un objeto, pero a la vez se provee una
interfaz pblica por medio de sus operaciones permitidas.
10

Encabezado de autenticacin 51
Encabezado de opciones del destino 60
No hay siguiente encabezado 59

Aplicaciones de red
ICMPv6
Dado que IPv6 es una versin ms reciente que IPv4, el protocolo ICMP fue mejorado de manera
significativa. IGMP tambin ha sido implementado dentro de ICMPv6. De propsito mltiple y
diseado para realizar funciones tales como detectar errores en la interpretacin de paquetes,
realizar diagnsticos, realizar funciones como descubrimiento de vecinos y detectar direcciones
IPv6 multicast. Los mensajes ICMPv6 estn 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 Parmetros

As mismo existen los mensajes informativos, los cuales proveen de mensajes de diagnstico,
mensajes para la administracin de grupos multicast y mensajes de descubrimiento de vecinos.
Como ejemplo se enlistan dos cdigos del tipo de diagnstico.
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 (tambin llamados registros de cudruple 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 diseando la
arquitectura IPv6. El RFC 3596 es el estndar propuesto para implementacin del modelo AAAA
dentro de IPv6.

Mecanismos de Transicin
Como premisa al diseo de IPv6, se especific que el nuevo protocolo deba coexistir con la
versin 4 del protocolo IP. Para ello, se desarrollaron junto con el mismo los mecanismos de
transicin. Los mecanismos de transicin se dividen en 3 grupos:
11

Doble pila
Traduccin
Tneles

Doble pila
Se trata de mantener en simultneo 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.

Traduccin
Este mecanismo de transicin realiza una "traduccin" similar a la que efecta el NAT, donde es
modificada la cabecera IPv4 a una cabecera IPv6.
El ms conocido dentro de este grupo es NAT-PT. Sin embargo, este tipo de mecanismos no es
de los ms recomendados.

Tneles
Cuando un paquete IPv6 tiene que ser transportado a travs de una red que slo es IPv4, pueden
utilizarse tneles para lograrlo. Un tnel 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.

Tneles IPv6 sobre IPv4
Los tneles proporcionan un mecanismo para utilizar la infraestructura montada bajo IPv4 mientras
avance la transicin hacia el pleno soporte de IPv6. Este mecanismo consiste en el
encapsulamiento de datagramas IPv6 en paquetes IPv4. Los extremos finales del tnel siempre
son los responsables de realizar la operacin de encapsulado y/ desencapsulado de paquetes.

Los tneles pueden ser utilizados de formas diferentes:
Router a router. Routers con doble pila (IPv6/IPv4) se conectan mediante una
infraestructura IPv4 y transmiten trfico IPv6. El tnel 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 (tambin de
doble pila), alcanzable mediante una infraestructura IPv4. El tnel 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
tnel comprende la ruta completa que siguen los paquetes.

Router a host. Routers de doble pila que se conectan a hosts tambin de doble pila. El
tnel comprende el ltimo segmento de la ruta.

Los tneles se clasifican segn el mecanismo por el que el nodo que realiza el encapsulado
determina la direccin del nodo extremo del tnel. 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 tnel es
un router intermedio que debe desencapsular el paquete IPv6 y reenviarlo a su destino final. En
este caso, el extremo final del tnel es distinto del destino del destino final del paquete, por lo que
la direccin en el paquete IPv6 no proporciona la direccin IPv4 del extremo final del tnel. La
direccin del extremo final del tnel ha de ser determinada a travs de informacin de
configuracin en el nodo que realiza el tnel. Es lo que se denomina tnel configurado,
describiendo aquel tipo de tnel cuyo extremo final es explcitamente configurado (Algunos autores
describen este tnel 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 tnel es el nodo destino del paquete, y por
tanto, la direccin IPv4 est contenida en la direccin IPv6. Este caso se denomina tnel
automtico.


Protocolos de doble pila
En general, el trmino doble pila se refiere a una duplicacin completa de todos los niveles de la
pila de protocolos de aplicaciones en la capa de red. Un ejemplo de duplicacin completa es un
sistema que ejecuta los protocolos OSI y TCP/IP.
Son mltiples 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 idntica. Por lo tanto, en IPv4 e IPv6 pueden ejecutarse los mismos protocolos de transporte,
TCP UDP y SCTP. Adems, 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, adems de
IPv4 en forma simultnea. Fuente: Gua de administracin del sistema: servicios IP de Sun Microsystems, Abril de 2009.

Metodologa para la transicin
Descripcin conceptual

Como parte del presente trabajo no se encontr consenso respecto al uso de una metodologa
generalmente aceptada para la transicin a IPv6. Varios organismos continan realizando foros de
discusin y fuerzas de tarea orientadas a desarrollar propuestas integrales para la transicin hacia IPv6.
Dado lo anterior resulta evidente que para realizar el proceso de transicin, se requieren soportar ambos
protocolos durante varios aos, y para ello, en esta seccin 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 adopcin desde varias perspectivas.

Mecanismos de tnel
La primera propuesta implica la adopcin de que ambos protocolos existirn de manera simultnea
en los clientes, por lo que el uso de tneles para transportar paquetes de datos de IPv6 sobre
redes IPv4 ser el primer modelo de adopcin del protocolo. Existen varios mecanismos para ello
segn se enlista a continuacin:

Tnel manual
Esta configuracin se aplica en aquellos casos donde el administrador de la red requiere mantener
un control absoluto del trfico por cada protocolo. Este mecanismo requiere mayor trabajo
administrativo pero incrementa el nivel de control sobre el avance del proyecto de transicin. El
uso de este mecanismo obliga emplear traductores de protocolo en el punto de salida de la red de
la organizacin
14


Tnel automtico
Este tipo de tnel facilita su tiempo de implementacin pero requiere contemplar los casos
extremos de trfico, por lo cual el uso no es recomendable fuera de redes cuyo nmero de
usuarios es muy limitado.

Tnel 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 an en aquellas redes que hayan adoptado la mayora de los clientes en IPv6,
ya que tiene un encabezado menor que otros tipos de tnel.

Tnel broker
Este es un servicio (tpicamente 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 adopcin temprana desde los
clientes como recurso para el final de la transicin.

Tnel Teredo
Este mecanismo permite el transporte de paquetes desde dispositivos de doble pila usando
mecanismos de relevadores y sistemas de traduccin de direcciones de IPv4 (NAT por sus siglas
en ingls). Este tipo de tnel ha estado implementado en varios sistemas operativos incluyendo los
de Microsoft, pero no es compatible con todos los mecanismos de traduccin existentes.
Consecuentemente a esta situacin de incompatibilidad, existe una variante simtrica de este tipo
de tnel, que emplea las siglas SYMTeredo que puede usarse en los casos de incompatibilidad
descritos en esta seccin.

Tnel BIS
Este tipo de tnel toma su nombre de las siglas en ingls Bump in the stack, permitiendo que
sistemas de cmputo que solo soporten IPv4 en su stack, pueden emplear un componente de
software que realiza las funciones de traduccin hacia IPv6, implicando desarrollo para cada
equipo que as lo requiere. Este tipo de tnel podra ser ltimo recurso en algunos casos.





15

Propuesta de Solucin
Descripcin de la propuesta

En el contexto del presente trabajo, mencionamos que ste se desarrollara desde una aproximacin de la
administracin de servicios de Tecnologa de Tecnologa y por tanto el enfoque de las siguientes
secciones se desarrollar acorde a la estrategia planteada.

Como hemos visto en el marco terico del presente trabajo, existen algunos mecanismos que permiten
una convivencia de ambos protocolos durante algn tiempo. Dado que no es objetivo del presente trabajo
identificar los aspectos de influencia que provoquen una rpida adopcin del protocolo IPv6, el enfoque de
la metodologa propuesta se resalta asumiendo que no existe, por ahora, una presin para concluir un
proyecto de transicin en un tiempo determinado, sin embargo, asumiremos que la una probable presin
de ndole econmico se dar a partir del agotamiento de direcciones pblicas en el Internet, y ante esto,
los gobiernos de algunos pases desarrollados (como Japn) empujarn la implantacin de la versin seis
del protocolo IP. As mismo, dado el grado de avance que hasta ahora se ha logrado en cuanto a la
adopcin de IPv6, deberemos tambin asumir que eventualmente los fabricantes de software y hardware
adoptarn el soporte del protocolo en cuestin en un tiempo determinado que permita a las organizaciones
realizar los planes correspondientes y acorde a los mecanismos presentes para adquisicin tecnologa.

Perspectiva del proyecto de transicin
Desde un punto de vista administrativo, para realizar un plan de transicin hacia la adopcin de
IPv6 deberamos comenzar con la definicin de un [proyecto]
11
, el cual, debe de incluir una fase de
iniciacin, una de planificacin, una de ejecucin y una de cierre. A manera de referencia, el
modelo planteado de resolucin se limita a la fase de planeacin. Lo anterior implica que, acorde al
contexto estratgico que la tecnologa tenga para la empresa, ser entonces menester de cada
organizacin liberar recursos para el proyecto de transicin hacia IPv6 (fase de iniciacin), el
control de recursos (fase de ejecucin), y el proceso para completar la transicin (fase de cierre).

Elementos del modelo de proyecto de transicin

Dentro de los elementos que se han identificado hasta ahora, se enlistan a continuacin los
elementos que conforman parte del alcance del plan de proyecto para la transicin, definiendo el
mnimo de los elementos que debern ser identificados en aquellas organizaciones que deseen
realizar un el proceso iniciacin del proyecto.

Infraestructura de telecomunicaciones

11
Project Management Body Of Knowledge, 4ta Edicin, Pgina 12, 2008
16

Dentro de este rubro, es evidente que aquellas organizaciones que se encuentren en la fase
temprana de iniciacin del proyecto, evaluarn las razones que los empujen a la realizacin de
este proyecto. Indistintamente de la razn que lo motive, en este rubro se refieren a los
componentes que debern 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 especificacin de la capa de
red del modelo OSI, y por tanto aquellos equipos que trabajen en esta capa debern ser
integrados dentro del plan de evaluacin. Dado que hemos referido un modelo de
transicin de coexistencia de los dos protocolos en forma simultnea, como parte de este
rubro debern ser evaluados los conmutadores de red local, los cuales reciben las
conexiones de los usuarios ya sea en forma almbrica como inalmbrica (puntos de
acceso). Estos conmutadores tradicionalmente proveen el soporte en las primeras dos
capas del modelo OSI y, en estricta teora, no deberan 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 transicin.

As mismo, en este rubro debern 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 transicin. As mismo la resolucin de nombres tambin sufri cambios y debe
ser evaluada la base instalada en la organizacin, as como una definicin formal del inicio
del soporte del protocolo en IPv6, como parte de la estrategia del resto de los
componentes que se enlistan en esta seccin.

Red de rea amplia (WAN)
En esta seccin debemos considerar que residen la mayora de los equipos que deben
estar integrados en el alcance del proyecto de transicin. 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 transicin. 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), tambin se incluyen convertidores de protocolos, puntos de acceso para
redes virtuales, servidores de cach, puntos de interconexin con redes de proveedores y
17

clientes, accesos remotos para asociados, servidores de contenido y el conjunto de
software de monitoreo y administracin 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 categora, previamente al resto de los elementos del proyecto
de transicin.

Servicios multimedia (voz, video, aplicaciones de tiempo real)
En este contexto, debemos considerar que en los reciente aos, son mltiples los
proveedores que han ido transformando el transporte de estos servicios, a travs del
protocolo TCP/IP, y por tanto resulta indispensable en el proceso de levantamiento de
informacin, 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 aos. 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 podran motivar una implantacin acelerada, sern aquellas
condiciones donde estos servicios estn integrados en redes privadas de gran magnitud,
debido a que, como referimos previamente, dentro de los beneficios de la versin seis del
protocolo IP, encontramos que hay varios diferenciadores en cuanto al manejo de la
calidad de servicio dentro de los parmetros de IPv6, as como un manejo transparente,
integro y con posibilidad de manejar transmisiones de gran tamao a lo largo de rutas de
redes distantes. Estos aspectos, son quizs algunas variables que deben ser consideradas
como parte del plan integral de transicin y que promuevan una transicin en plazos
relativamente cortos por los beneficios identificados acorde al contexto de la organizacin.

Aplicaciones empresariales/corporativas
En este rubro el proceso de inventario requiere contemplar dos escenarios. Para cada una de las
aplicaciones cuya produccin radica en servidores, tanto empresariales como servicios de
terceros, se requiere evaluar el plan de migracin, 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 debern soportar en forma nativa el
protocolo IPV6 para integrar su migracin en un ambiente controlado. As mismo, cada aplicacin
podr requerir de la modificacin 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 migracin de
estas aplicaciones en el futuro, de modo que se soporten debidamente. Si lo amerita la aplicacin,
tneles BIS debern desarrollarse para el soporte continuo inclusive pudieran ser necesarios
traductores de protocolo cuando el nmero 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 seccin.

Clientes/Usuarios finales
Un elemento que pudiera resultar relativamente fcil de implementar son los usuarios finales, los
cuales comprenden para una organizacin, un elemento que tradicionalmente se reemplaza en
tiempos relativamente cortos. Como parte de este escenario, el elemento de la planeacin de
versiones de sistema operativo y un inventario completo del parque instalado, resultan ser quizs,
los factores que faciliten o compliquen el plan de transicin. Como parte de un conjunto de mejores
prcticas, los administradores de redes de usuario pudieran caer en la tentacin de habilitar a los
usuarios finales de manera automtica, lo cual reduce el ciclo de implantacin, pero complica la
administracin. Debemos por tanto considerar que en funcin de las polticas existentes en la
organizacin, este rubro debe formar parte integral de los principios administrativos del rea de
tecnologas de informacin.

Aplicaciones integrales de administracin
En aquellas circunstancias donde una organizacin mantenga aplicaciones para administracin de
recursos informticos, un elemento que cobra relevancia es aquel que integra a este rubro, siendo
que al integrar plataformas nuevas tecnolgicas, cobra mayor relevancia mantener el mismo nivel
de administracin tras la transicin al nuevo protocolo. En este contexto, podemos decir que la
plataforma de monitoreo de red, es quizs la prctica que mida, de manera efectiva, que el
proceso de transicin ha sido efectuado acorde a las expectativas de servicio definidas por el
proyecto de transicin.

Respecto a los costos de implantacin del proyecto
Una vez efectuado el inventario correspondiente a los elementos que conforman el proyecto de
transicin a IPv6, es necesario que cada uno de ellos contemple las variables de los costos
derivados de equipo nuevo de cmputo y telecomunicaciones, las costos de administracin de dos
esquemas de red coexistiendo, el tiempo de afectacin en servicios por pruebas y los costos de
diferir la transicin hacia tiempos posteriores. En este contexto, un esquema de administracin 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 transicin.

El contexto tcnico de la organizacin
19

Uno de los aspectos que pueden alterar el diseo del plan de proyecto es el tiempo que se tome
en la aplicacin del soporte el protocolo IPv6 en la agenda de los grupos de gobierno de TI, grupo
de arquitectura tecnolgica o estndares corporativos. Dado que cada organizacin puede integrar
maneras diferentes de adopcin de tecnologa, este aspecto es sin duda uno que quizs implique
un factor que demore la adopcin de IPv6, pero que, una vez liberado, permitira una adopcin
controlada del protocolo.

Polticas
En este contexto, existe la posibilidad de que algunos ambientes de operacin mantengan polticas
estrictas para el manejo de los datos en lo que respecta al medio de transmisin, formato de los
paquetes, alternativas de trfico y uso de redes acorde a especificaciones del contexto de la
organizacin. Particularmente en esta seccin, es necesario identificar que acorde al cambio que
se anticipa por la introduccin de IPv6, ser necesario realizar reformas a las polticas, segn haya
sido identificado en el alcance del proyecto de transicin, probado en los distintos ambientes de
laboratorio y efectivamente integrado en los contratos de servicio de proveedores tales como sean
de servicio, de soporte tcnico, de administracin de la infraestructura tcnica, etc.

Dentro de este tenor, debe integrarse que como parte de los beneficios de la transicin a IPv6,
algunas caractersticas hacia el interior de la organizacin, en lo que respecta a la asignacin de
direcciones, rangos de crecimiento y uso de recursos del internet.

Algunas polticas externas que han sufrido cambios, tienen que ver con la manera como se
asignan direcciones pblicas en IPv6, y por tanto, estas han de tener repercusiones en la manera
como se realizan acuerdos de interconexin con empresas terceras como proveedores, socios de
negocio y alianzas estratgicas. El impacto de estos cambios debe ser evaluado como parte del
plan de proyecto de transicin.

Conclusiones

Como parte de la gestin de sistemas de informacin, el proyecto de transicin hacia IPv6, debe
contemplar un proceso de inventario de la tecnologa existente en una organizacin, la cual, hoy en da,
tiende a continuar creciendo en un mundo no solo globalizado, sino tambin completamente
interconectado. Por lo anterior el proceso para realizar una transicin ordenada, debe ser evaluado de
manera paulatina, en la medida que cada organizacin mantenga un ambiente controlado.

Dado que el contexto actual en el cual nos encontramos, an es posible la coexistencia del protocolo IPv4
con el IPv6, me resulta difcil creer que habr un presin en el corto plazo para acelerar los procesos de
20

adopcin de IPv6, sin embargo, en la agenda de los ejecutivos y el personal tcnico relacionados con las
tecnologas de informacin, resulta importante contemplar los elementos referidos a lo largo del trabajo, en
la agenda tecnolgica, 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 tecnologas
de cmputo y telecomunicaciones, debern acelerar y evidentemente promover la adopcin de este
protocolo.

La adopcin de IPv6 como tal, provee algunos elementos que permitirn a las organizaciones, proveer
servicios de manera ms segura y acorde a niveles de servicio esperados, pero slo se podrn obtener los
beneficios, si los grupos involucrados en la administracin de la tecnologa, los grupos que especifican los
estndares de trabajo y los grupos que gobiernan las especificaciones, logran ponerse de acuerdo en un
modelo acorde a las necesidades de cada organizacin.

Finalmente para los profesionales de las Tecnologas de Informacin 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 tcnica y/ de toma de decisiones.
















Acerca del autor

Csar Bentez, es Licenciado en Sistemas de computacin administrativa, graduado de la Universidad del
Valle de Mxico y actualmente cursa la maestra de gestin de tecnologas de informacin. Csar cuenta
con ms de veinte aos 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 administracin de la tecnologa, administracin de proyectos y servicio al cliente en
un entorno internacional que integra en especial a pases en todo el continente Americano.
21

Bibliografa

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 espaol
Portal de Transicin a IPv6 de Amrica Latina y el Caribe
En lnea <http://portalipv6.lacnic.net/>

Gua de los fundamentos para la direccin de proyectos (Gua del PMBOK) 4ta. Edicin
Project Management Institute, 2008

Redes globales de informacin con Internet y TCP/IP, 3ra. Edicin
Douglas E. Comer
Pearson, 1995





















22

RFCs Consultados como referencia en el IETF
En lnea <http://www.ietf.org/rfc/rfc1883.txt>

RFC Descriptcin
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