estrategia de migraciÓn de ipv4 a ipv6 para...
TRANSCRIPT
ESTRATEGIA DE MIGRACIÓN DE IPv4 A IPv6 PARA LAS PYMES EN
COLOMBIA
HÉCTOR FABIO ARIAS PULGARÍN
COD. 10032846
UNIVERSIDAD CATÓLICA DE PEREIRA
PROGRAMA INGENIERÍA DE SISTEMAS Y TELECOMUNIICACIONES
PEREIRA
2011
ESTRATEGIA DE MIGRACIÓN DE IPv4 A IPv6 PARA LAS PYMES EN
COLOMBIA
HÉCTOR FABIO ARIAS PULGARÍN
COD.10032846
Trabajo de grado para optar por el título de
Ingeniero de Sistemas y Telecomunicaciones
Asesor
LUIS ALEJANDRO FLETSCHER BOCANEGRA
Ing. En Electrónica y Telecomunicaciones
MSc. En Ingeniería
UNIVERSIDAD CATÓLICA DE PEREIRA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍAS
PEREIRA
2011
AUTORIZACIÓN
Yo, HECTOR FABIO ARIAS PULGARIN mayor de edad, vecino de Pereira, identificado con la Cédula de Ciudadanía N° 10032846 de Pereira actuando en nombre propio, en mi calidad de autor del trabajo de grado, denominado: ESTRATEGIA DE MIGRACION DE IPv4 A IPv6 PARA LAS PYMES EN COLOMBIA.
Presentado como requisito para optar el título de INGENIERO DE SISTEMAS Y TELECOMUNICACIONES, en el año 2011, hago entrega del ejemplar respectivo y de sus anexos de ser el caso, en formato digital o electrónico (CD-ROM) y autorizo a LA UNIVERSIDAD CATÓLICA DE PEREIRA, para que en los términos establecidos en la Ley 23 de 1982, Ley 44 de 1993, Decisión Andina 351 de 1993, Decreto 460 de 1995 y demás normas sobre la materia, utilice y use en todas sus formas, los derechos patrimoniales de reproducción, comunicación pública, transformación y distribución (alquiler, préstamo público e importación) y los demás derechos comprendidos en aquellos, que me corresponden como creador de la obra objeto del presente documento. También autorizo a que dicha obra sea incluida en bases de datos. Esta autorización la hago siempre que mediante la correspondiente cita bibliográfica se le de crédito a mi trabajo como autor.
Con todo, en mi condición de autor me reservo los derechos morales de la obra antes citada con arreglo al artículo 30 de la Ley 23 de 1982. PARÁGRAFO: La presente autorización se hace extensiva no sólo a las facultades y derechos de uso sobre la obra en formato o soporte material, sino también para formato virtual, electrónico, digital, óptico, usos en red, internet, extranet, intranet, etc., y en general para cualquier formato conocido o por conocer.
EL AUTOR - ESTUDIANTES, manifiesta que la obra objeto de la presente autorización es original y la realizó sin violar o usurpar derechos de autor de terceros, por lo tanto la obra es de su exclusiva autoría y tiene la titularidad sobre la misma. PARÁGRAFO: En caso de presentarse cualquier reclamación o acción por parte de un tercero en cuanto a los derechos de autor sobre la obra en cuestión, EL ESTUDIANTE - AUTOR, asumirá toda la responsabilidad, y saldrá en defensa de los derechos aquí autorizados; para todos los efectos la Universidad actúa como un tercero de buena fe.
HECTOR FABIO ARIAS PULGARIN CC.10.032.846
Pereira, Noviembre 22 de 2011
DEDICATORIA
A DIOS, quien ha estado a mi lado en todo momento, dándome las fuerzas
necesarias para continuar luchando día tras día y salir adelante, rompiendo todas
las barreras que se presenten.
A mi querida madre MARIA LUCIELA, a quien le agradezco lo que soy, pues ha
sido quien me ha brindado enseñanzas que me han permitido crecer más como
persona íntegra y además quien me ha ayudado en mi formación académica,
quien depositó su entera confianza en cada reto que se me presentaba sin dudar
ni un solo instante de mis capacidades.
A mi querida tía NORMA RUTH y abuela CARMEN, quienes han sido para mí
como unas segundas madres, han estado conmigo desde mi niñez brindándome
mucho amor y ayudando en mi crecimiento como persona.
A mis hermanos OLMEDO y OSLANDER, quienes han estado acompañándome
en mi formación personal y académica.
HÉCTOR FABIO
AGRADECIMIENTOS
A DIOS, por iluminarme y ser la guía suprema, dándome fuerzas para atravesar
obstáculos que se presentaran durante la carrera.
A mis Seres Queridos, por la confianza, esfuerzo, dedicación y la perseverancia
que me brindaron, para poder lograr las metas.
Al asesor Luis Alejandro Fletscher, por orientarme y guiarme durante el proceso
educativo y culminación del proyecto.
A mis compañeros que estuvieron en el mismo proceso de formación académica.
Cada uno de ellos aportó en mi crecimiento personal y académico.
A todas las personas que estuvieron involucradas de una manera directa o
indirecta con la realización de mi Proyecto de Grado, por alentarme siempre y
aconsejarme para que el proceso culminara exitosamente.
CONTENIDO
Pág.
INTRODUCCIÓN ................................................................................................... 20
1.DEFINICIÓN DEL PROBLEMA .......................................................................... 22
1.1OBJETIVO GENERAL ...................................................................................... 23
1.2OBJETIVOS ESPECÍFICOS ............................................................................. 23
2.GENERALIDADES DE DIRECCIONAMIENTO .................................................. 24
2.1 CONTEXTUALIZACIÓN DE IP ........................................................................ 24
2.1.1 Direcciones IPv4 públicas ............................................................................. 24
2.1.2 Direcciones IPv4 privadas ............................................................................. 25
2.1.3 Direcciones reservadas ................................................................................. 25
2.2 TRADUCCIÓN DE DIRECCIÓN DE RED (NAT) ............................................. 28
2.2.1 Problemas de NAT ........................................................................................ 28
2.3 IP MULTICAST ................................................................................................ 29
3.CONTEXTUALIZACIÓN DEL DIRECCIONAMIENTO IPV6 ............................... 30
3.1 IPV6….............................................................................................................. 30
3.1.1 Características principales de IPV6 con respecto a IPV4 ............................ 31
3.1.2 Datagramas de encabezado IPV4 e IPV6 ................................................... 34
3.1.3 Encabezados de extensión- .......................................................................... 40
3.1.3.1 Orden de los encabezados de extensión (opcional) ................................ 41
3.1.3.1.1 Hop-by-Hop Options Header ................................................................... 43
3.1.3.1.2 Destination Options Header .................................................................... 43
3.1.3.1.3 Routing Header ....................................................................................... 44
3.1.3.1.4 Fragment Header .................................................................................... 47
3.1.3.1.5 Authentication Header ............................................................................ 49
3.1.3.1.6 Encapsulating Security Payload Header ................................................ 51
3.1.3.1.7 Destination Options Header .................................................................... 52
3.1.4 Representación del direccionamiento IPV6 .................................................. 54
3.1.5 Nomenclatura de prefijos ............................................................................. 56
3.1.6 Arquitectura de direccionamiento en IPV6 .................................................. 57
3.1.6.1 Unicast ....................................................................................................... 57
3.1.6.1.1 Direcciones de enlace local (link-local) ................................................... 59
3.1.6.1.2 Direcciones de sitio local- ....................................................................... 60
3.1.6.1.3 Direcciones de enrutamiento global (Global Address)- ........................... 61
3.1.6.2 Identificador de interfaz– (EUI-64) ............................................................. 62
3.1.6.3 Direcciones reservadas .............................................................................. 64
3.1.6.3.1 La dirección no especificada ................................................................... 64
3.1.6.3.2 Dirección Loopback ó dirección de bucle invertido. ............................... 64
3.1.6.4 Anycast ...................................................................................................... 65
3.1.6.5 Multicast .................................................................................................... 66
4. ESTRATEGIAS DE MIGRACIÓN ...................................................................... 72
4.1 DUAL STACK (PILA DUAL) ............................................................................. 73
4.2 CONFIGURED TUNNELS ............................................................................... 74
4.2.1 Tunnel Broker ............................................................................................... 75
4.2.2 Tunnel 6to4 ................................................................................................... 77
4.2.3 Tunnel ISATAP ............................................................................................. 79
4.2.4 Tunnel 6over4. ............................................................................................. 81
4.2.5 Tunnel Teredo ............................................................................................... 81
4.2.6 Dual Stack Transition Mechanism (DSTM) ................................................... 84
4.3 MÉTODOS DE TRASLACIÓN ......................................................................... 88
4.3.1 SIIT, NAT-PT and NAPT-PT ......................................................................... 89
4.3.2 Transport Relay Translator (TRT) ................................................................. 90
4.3.3 Bump in the Stack ......................................................................................... 93
4.3.4 Bump in the API ............................................................................................ 96
4.3.5 SOCK ............................................................................................................ 98
5. CONFIGURACIÓN DE ESTRATEGIAS DE MIGRACIÓN ................................. 99
5.1 CONFIGURACIÓN: MÉTODO DE TUNNELS ................................................. 99
5.1.1 Túnel manual Cisco IOS ............................................................................... 99
5.1.2 6to4 ............................................................................................................. 101
5.1.2.1 Cisco IOS (as Client and Relay)............................................................... 101
5.1.2.1.1 Configuración del cliente: ...................................................................... 101
5.1.2.1.2 Configuración como un relay 6to4:........................................................ 102
5.1.3 ISATAP ....................................................................................................... 102
5.1.3.1 Cisco IOS Platform (As Router/Server). ................................................... 103
6. ETAPAS DE PROCESO DE MIGRACIÓN PARA LAS PYMES. ..................... 104
6.1 PROYECTO DE TRANSICIÓN ...................................................................... 105
6.1.1 Elementos del modelo de proyecto de transición. ....................................... 105
6.1.1.1 Planificación y definición de la estrategia. Incluya la necesidad de la
inversión............................................................................................................... 105
6.1.1.2 ¿Cómo está su red?, ¿Cuáles son sus servicio?, ¿Cuál es la mejor forma
de migración? ...................................................................................................... 106
6.1.1.2.1 Redes de área local .............................................................................. 106
6.1.1.2.2 Red de área amplia (WAN) ................................................................... 107
6.1.1.2.3 Servicios multimedia (voz, video, aplicaciones de tiempo real). ........... 108
6.1.1.2.4 Aplicaciones empresariales/corporativas .............................................. 109
6.1.1.2.5 Clientes/Usuarios finales ....................................................................... 109
6.1.1.2.6 Aplicaciones integrales de administración ............................................ 110
6.1.1.2.7 Políticas ................................................................................................ 110
6.1.1.3 Defina los equipos, servicios, soportes, y capacitación. .......................... 111
6.1.1.4 Integre sin interrupciones o vulnerabilidades. Defina paso por paso. ...... 111
6.1.1.5 Gerencia, resuelva. Repare. Reemplace, siempre manteniendo la red
estable. ................................................................................................................ 112
6.1.1.6 Adapte la red y los servicios de acuerdo a los requisitos de la Pyme. ..... 112
CONCLUSIONES ................................................................................................ 113
BIBLIOGRAFÍA .................................................................................................... 115
ANEXO 1. RFC´s para IPV6 .............................................................................. 119
LISTA DE TABLAS
Pág.
Tabla 1: Entidades delegan, administran y distribuyen las direcciones IP ............. 26
Tabla 2: Descripción de los campos del Datagrama de encabezado IPV4 e IPV6
........................................................................................................................ 40
Tabla 3: Orden de los encabezados de extensión ................................................. 42
Tabla 4 : Hop-by-hop Options ................................................................................ 53
Tabla 5 : Destination Options ................................................................................. 53
Tabla 6: Direcciones Multicast Reservadas ........................................................... 66
Tabla 7: Posibilidades campo Scope ..................................................................... 69
Tabla 8: Técnicas de Túneles ................................................................................ 74
Tabla 9: Estructura de las direcciones Teredo ....................................................... 82
Tabla 10: Mecanismos de traslación de protocolos ............................................... 88
Tabla 11: Etapas de proceso de migración para las Pymes ................................ 104
LISTA DE FIGURAS
Pág.
Figura 1: Datagrama de encabezado IPV4 ............................................................ 35
Figura 2: Datagrama de encabezado IPV6 ............................................................ 36
Figura 3: Header Chaining Examples .................................................................... 41
Figura 4: Cabecera de enrutamiento durante transporte de datagramas .............. 46
Figura 5: Proceso de fragmentación para un paquete IPV6 ................................ 49
Figura 6: Alcance de direcciones Unicast en IPV6 ................................................ 58
Figura 7: Estructura de dirección IPv6 enlace local. ............................................. 59
Figura 8: Estructura de dirección IPv6 para enrutamiento de uso local. ............... 60
Figura 9: Estructura de dirección IPv6 para enrutamiento global. ......................... 61
Figura 10: Conversión dirección MAC de 48 bits a 64 bits. (Identificador de
Interfaz). .......................................................................................................... 63
Figura 11: Estructura de una dirección Multicast IPV6. ......................................... 67
Figura 12: Estructura de direcciones IPV6 Multicast (Prefijo Basado en direcciones
Unicast). .......................................................................................................... 68
Figura 13: Estructura de una dirección Multicast en IPV6 - incorporado (RP) ...... 69
Figura 14: Funcionamiento Pila-Dual ..................................................................... 73
Figura 15: Funcionamiento de Tunnel Broker ........................................................ 76
Figura 16: Funcionamiento del Tunnel 6to4 ........................................................... 78
Figura 17: Funcionamiento de Tunnel ISATAP ..................................................... 80
Figura 18: Funcionamiento Tunnel Teredo ............................................................ 83
Figura 19: Funcionamiento DSTM ......................................................................... 85
Figura 20: Funcionamiento Translation (NAT-PT) ................................................. 89
Figura 21: Funcionamiento Transport Relay Translator ......................................... 92
Figura 22: The BIS Protocol Stack ......................................................................... 94
Figura 23: The BIA Protocol Stack ......................................................................... 96
LISTA DE ANEXOS
Pág.
ANEXO 1. RFC´s para IPV6 .............................................................................. 119
GLOSARIO
“Ámbito (Scope): Para las direcciones IPV6, el ámbito es la porción de la red a la
que se supone que se va propagar el tráfico.
BIT: Acrónimo de Binary digit. (Dígito binario). Un bit es un dígito del sistema de
Numeración binaria. Mientras que en nuestro sistema de numeración decimal se
usan diez dígitos, en el binario se usan solo dos dígitos, el 0 y el 1. Un bit o dígito
binario puede representar uno de esos dos valores, 0 ó 1.
Datagrama: Conjunto estructurado de bytes que forma la unidad básica de
comunicación del protocolo.
Dirección: Identificador asignado a nivel de la capa de red a un interfaz o conjunto
de interfaces que puede ser empleado como campo de origen o destino en
datagramas IPV6.
Dirección MAC: Es un identificador de 48 bits (3 bloques hexadecimales) que
corresponde de forma única a una tarjeta o dispositivo de red. Se conoce también
como dirección física, y es única para cada dispositivo. Está determinada y
configurada por el IEEE (los últimos 24 bits) y el fabricante (los primeros 24 bits)
utilizando el Organizationally Unique Identifier.
Dominio: Un dominio es la parte de una URL (dirección de una página o recurso
en internet) por la que se identifica al servidor en el que se aloja.
Estado del enlace: Tecnología de protocolo de ruteo, que intercambia
información de rutas, que consta de los prefijos de las redes conectadas a un
router y su costo asociado. La información del estado del enlace se anuncia en el
arranque, así como cuando se detectan cambios en la topología de red.
Flujo: Una serie de datagramas intercambiados entre una fuente y un destino que
requieren un tratamiento especial en los routers intermedios, y definidos por una
dirección IP origen y destino específico, así como por una etiqueta de flujo con un
valor distinto a 0.
Fragmentación: Proceso por el que se divide la carga de un datagrama IPV6 en
fragmentos por la máquina emisora, de modo que todos los fragmentos tienen una
MTU apropiada al camino a seguir hasta el destino.
Gateway: Equipo encargado de proporcionar los servicios a un host.
Interfaz: Una representación de un nexo físico o lógico de un nodo a un enlace.
Un ejemplo de un interfaz físico es una interfaz de red. Un ejemplo de un interfaz
lógico es un interfaz de un túnel.
MTU: Unidad máxima de trasferencia (Maximum Trasfer Unit - MTU), expresa el
tamaño en bytes del datagrama más grande que puede pasar por una capa de un
protocolo de comunicaciones.
NODO: Espacio real en el que confluyen parte de las conexiones de otros
espacios reales o abstractos que comparten sus mismas características y que a su
vez también son nodos. Todos estos nodos se interrelacionan entre sí de una
manera no jerárquica y conforman lo que en términos sociológicos o matemáticos
le llamamos red.
Paquete: Unidad fundamental de trasporte de información en todas las redes de
cómputo. Un paquete está generalmente compuesto de tres elementos: Una
cabecera (header) que contiene generalmente la información necesaria para
trasladar el paquete desde el emisor hasta el receptor, el área de datos (payload)
que contiene los datos que se desean trasladar, y la cola (trailer), que
comúnmente incluye código de detección de errores.
RFC (Request For Comments): Documento de especificaciones que se expone
públicamente para su discusión.
Socket: Tupla compuesta por una dirección IP y un número de puerto.
Tabla de ruteo: Conjunto de rutas empleadas para determinar la dirección e
interfaz del siguiente nodo en el tráfico IPV6 enviado por un equipo o
reencaminado por un router.
Tunneling: Encapsulado de un protocolo IPV6 dentro de un protocolo IPV4 o
viceversa.
Router: Es un dispositivo hardware o software de interconexión de redes de
computadoras que opera en la capa tres (nivel de red) del modelo OSI. Este
dispositivo interconecta segmentos de red o redes enteras.”1
16SOS.Glosario IPV6: Eduardo Jacob Taquet, Alex Muñoz Mateos, Fidel Liberal Malaina.2004.pag
38. Fuente: http://www.6sos.org/documentos/glosario-IPv6-v1-2.pdf
RESUMEN
RESUMEN ABSTRACT
En Colombia son pocas las PYMES
que se encuentran trabajando hoy en
día sobre IPv6, unas porque no han
visto la necesidad de la migración de
IPv4 a IPv6 y otras porque temen
este cambio debido a que no
cuentan con personal capacitado.
Es por eso que el proyecto busca
construir el soporte documental que
permita a los administradores de
redes de las diferentes PYMES de
Colombia, analizar los aspectos
teóricos y técnicos asociados a la
migración hacia el nuevo protocolo
de internet, aportando además, un
estudio y análisis acerca de la
nueva nomenclatura del protocolo
“IPV6”, con el fin de garantizar un
manejo adecuado a la información
de las organizaciones.
Palabras Claves: datagramas, IPV4,
IPV6, fragmento, encabezado,
dirección, estrategia, pila dual,
túneles, traducción.
In Colombia there are few PYMES
that are working today on IPv6, some
because they have not seen the need
for migration from IPv4 to IPv6 and
others because they fear this change
because they do not have trained
personnel.
That's why the project seeks to build
the supporting documentation that
allows network administrators of the
various SMEs in Colombia, to analyze
the theoretical and technical aspects
associated with the migration to the
new Internet protocol, also providing a
study and analysis on of the new
nomenclature protocol "IPv6" in order
to ensure proper handling of
information in organizations.
Keywords: datagrams, IPV4, IPV6,
fragment, header, address, strategy,
dual stack, tunnel, translations.
20
INTRODUCCIÓN
“En los últimos años, el gobierno, la academia y el sector privado, particularmente
el financiero, han dirigido sus estrategias de apoyo y promoción de sus servicios
hacia el sector de las micro, pequeñas y medianas empresas (MiPyMEs), al darse
cuenta que es en este sector empresarial donde se puede tener el pivote para
alcanzar un acelerado crecimiento de nuestra economía y aunque siempre se
habían considerado importantes, hoy han llegado a ser imprescindibles al
proyectarse como una de las mejores opciones para lograr la plena reactivación
de nuestra economía, aún con todas sus falencias como es la falta de gestión
organizacional, financiera, comercial, administrativa y tecnológica “2.
En la parte tecnológica, los creadores de IPv4, a inicios de los 70 a pesar de
disponer de un espacio de direcciones de 32 bits, es decir cuatro mil millones de
direcciones (4.294.967.296) no era posible asimilar, el gran éxito que el protocolo
iba a brindar y que iba a ser utilizado no sólo en computadores, sino también en
diferentes dispositivos de manos libres que pudiesen manejar una conexión a
internet.
“Podemos recordar algunas ´famosas frases` que nos ayudaron a entender hasta
qué punto, los precursores de la revolución tecnológica llegaron a plasmar
afirmaciones erróneas.
“Pienso que el mercado mundial de ordenadores puede ser de cinco
unidades”, Thomas Watson, Presidente de IBM en 1943.
2 http://www.usergioarboleda.edu.co/civilizar/Pyme_Situacion_Colombia.htm
21
“640 Kbps De memoria han de ser suficientes para cualquier usuario”, Bill
Gates, Presidente de Microsoft desde 1975.
“32 bits proporcionan un espacio de direccionamiento suficiente para
Internet”, Dr. Vinton Cerf, Padre de Internet, 1977”3.
En 1.994 se presentó un primer proyecto para solucionar el problema del posible
agotamiento de las direcciones IP existentes, siendo en 1.995 cuando se define
este proyecto definitivamente como IPv6 y se establece la primera especificación.
IPv6 (Internet Protocol Versión 6) es el último nivel del Internet Protocol (IP) y
ahora forma parte del soporte IP en muchos productos tales como los sistemas
operativos de computadoras, teléfonos, televisión y radio, sistemas de seguridad,
tele-vigilancia, control, entre otros. Es un protocolo de 128bits, lo que hace que
algunos cálculos sitúen el número de conexiones posibles en aproximadamente 34
trillones.
Las PYMES en Colombia no cuentan con un protocolo que sea de ayuda para los
administradores de redes, donde encuentren una información sólida y coherente,
que los induzca a buscar una solución más rápida y más efectiva, para lograr la
migración de IPv4 a IPv6, basados en un estudio y análisis acerca de la nueva
nomenclatura del protocolo “IPV6” y especificaciones en seguridad en las redes,
con el fin de garantizar un manejo óptimo a la información de las organizaciones.
3 Tomado de http://www.6sos.org/documentos/6SOS_Tutorial_IPv6_v4_0.pdf
22
1. DEFINICIÓN DEL PROBLEMA
Existe una gran problemática en las organizaciones con el agotamiento de
direcciones IPv4, por causa, entre otras cosas, del desperdicio que existe de las
mismas, o a la gran cantidad de usuarios que ahora recurren a Internet, que ha
aumentado de forma considerable, ya que no sólo los computadores se conectan
a Internet, sino también otros objetos tecnológicos como las PDA, los celulares,
consolas, entre otros.
Las organizaciones, en particular las PYMES de Colombia, conocen la necesidad
de la migración de IPv4 a IPv6, pero el más grande problema es que se
desconoce cómo es realmente el procedimiento en la nueva nomenclatura,
compatibilidad con los protocolos de conexión y los procedimientos que se deben
llevar a cabo para no descuidar la parte de seguridad en la información o tener el
inconveniente de ser desconectados. Es por ésto, que algunas empresas se
privan de dar el paso a nuevos cambios en tecnologías, siendo la causa principal
la falta de personal experto que pueda llevar a cabo una migración no traumática
entre ambos protocolos.
23
1.1 OBJETIVO GENERAL
Plantear un marco de referencia que permita a las PYMES de Colombia, la
migración del protocolo IPv4 a IPv6, aportando la conceptualización asociada, así
como las estrategias y mecanismos para hacer viable dicha migración.
1.2 OBJETIVOS ESPECÍFICOS
Conocer las causas que llevaron a cambiar el sistema de direccionamiento
IPV4 por IPV6.
Definir las principales diferencias entre el Protocolo de Internet versión 4 y
el Protocolo de Internet versión 6.
Interpretar el funcionamiento que posee IPv6 y las nuevas funciones que
ayudarán a las Pymes de Colombia en el manejo de las redes de
información.
Identificar los mecanismos de migración que ayudarán a las Pymes en
Colombia para la transición de IPV4 a IPV6.
24
2. GENERALIDADES DE DIRECCIONAMIENTO
2.1 CONTEXTUALIZACIÓN DE IP
“Una dirección IP es un identificador de cada host dentro de su red de datos”4, se
caracteriza por ser única, ya que no sería algo lógico que dentro de una misma
ciudad existieran varios números telefónicos con un mismo código o dígito de
marcación y con un mismo propietario. Las direcciones IP se caracterizan por
conformarse en dos partes: Una de ellas, identifica a la red y la otra identifica a la
máquina dentro de la red, teniendo en cuenta que todas las máquinas que
pertenecen a la misma red requieren de un mismo número de Red el cual debe
ser además único en internet.
Se clasifican en:
2.1.1 Direcciones IPv4 públicas
Las direcciones IPV4 públicas son aquellos espacios que se encuentran
disponibles para internet, son únicas ya que no se puede manejar una misma
dirección IP para darles conectividad a varios equipos, este tipo de
direccionamiento es manipulado por los Proveedor de Servicios de Internet (ISP)
para permitir brindar conectividad a usuarios.
4 IntroduccionDireccionesIP.pdf. Microsoft Word-direccionesIP.doc.2004.pag 7.
Fuente: http://www.educa.madrid.org/cms_tools/files/a8dae6a3-c890-4d13-a8fc5e928c9a98ec/ IntroduccionDireccionesIP.pdf
25
2.1.2 Direcciones IPv4 privadas
Las direcciones IPV4 son aquellos tipos de direcciones que han sido reservadas
para la administración de redes privadas, se caracterizan porque manejan un
direccionamiento que no permite el acceso a la red pública. Algunos rangos en el
direccionamiento IPV4 fueron reservados para la operación de este tipo de redes.
Manejan algo en común a las redes públicas que son únicas e irrepetibles, para
permitir la conectividad de los diferentes dispositivos que se encuentren dentro de
la red.
2.1.3 Direcciones reservadas
Las direcciones reservadas son grupos de direcciones que han quedado para un
uso específico. Las más importantes son las siguientes:
0.0.0.0 (o la dirección .0 de cualquier subred). Esta es la dirección para
referirse a la red.
255.255.255.255 (o la dirección .255 de cualquier subred). Esta es la
dirección de broadcast. Equivale a todos los terminales de la red.
127.X.X.X Este es el rango de ip’s de loopback. Son para referirnos a
nosotros mismos (nuestra máquina). También llamadas de diagnóstico.
127.0.0.1 (o localhost) Es un caso particular del anterior. Es la más
usada para referirnos a nuestra máquina de manera local.
IPV4 inicialmente sólo se pensó que permitiría dar conexión a equipos de
cómputo, pues en la década de los años 80 internet no estaba extendido más allá
de los ambientes científicos, universitarios y gubernamentales, pero debido a los
avances tecnológicos que se están dando en nuestro futuro se requiere que cada
26
equipo que desee compartir información cuente con una dirección ip que le
permita una conexión permanente a internet para así contar con acceso inmediato
a la información.
En estos momentos la IANA (Internet Assigned Numbers Authority), siendo la
entidad que supervisa mundialmente la asignación del direccionamiento IPV4
realizó entrega de los últimos 7 bloques conformado cada uno por 16.777.216
direcciones, a los cinco RIR (Regional Internet Registry); pues éstas son las
entidades que atienden y administran la delegación y distribución de las
direcciones IP (Versión 4 -Versión 6), en todo el mundo, segmentado para estos
propósitos en cinco regiones: LACNIC (América Latina y el Caribe), ARIN
(América del Norte), RIPE NCC (Europa, Oriente Medio y Asia central), APNIC
(Asia y Pacífico) y AFriNIC (África).
Tabla 1: Entidades que delegan, administran y distribuyen las direcciones IP
Fuente: http://lacnic.net/sp/politicas/manual2.html
27
“La última voz de alarma la levantó el Registro de Direcciones de Internet para
América Latina y el Caribe (Lacnic), en un comunicado emitido en junio de este
año donde se informó que en la actualidad quedan disponibles menos del 18% del
total, proyectando que para el año 2011 el stock de IPv4 estaría totalmente
agotado.”5
El agotamiento de direccionamiento IPv4 se originó debido al crecimiento de
usuarios, aplicaciones, servicios y dispositivos que requieren de una dirección IP
que les permita estar conectados para el compartimiento de información. Otra de
las posibles causas para que esto ocurriera fue la asignación que se dio en los
comienzos, pues no se tenían en cuenta los tipos de necesidades que las
organizaciones requerían o la existencia de éstas, pues asignaron amplios
bloques de direcciones IP a empresas individuales y organizaciones.
Desafortunadamente, el control estricto de asignación de direcciones IP que existe
en la actualidad no siempre estuvo presente y supondría un gran esfuerzo realizar
el seguimiento de qué direcciones no se utilizan. Actualmente, la ICANN tendría la
posibilidad de reclamar estos rangos y volver a expedir las direcciones a otras
personas. Sin embargo, puede suponer mucho tiempo y dinero volver a numerar
una red y probablemente muchas organizaciones se opondrían, hasta el punto de
emprender acciones legales.
Con la intención de resolver el agotamiento en el direccionamiento se
desarrollaron algunos mecanismos o estrategias que han permitido extender la
vida de IPv4 tales como:
5 Fuente: http://www.dcc.uchile.cl/sites/default/files/DCC-Inside/FCFM%2040_ Se%20agotan%20 direcciones%20IP.pdf
28
2.2 TRADUCCIÓN DE DIRECCIÓN DE RED (NAT)
“Es un mecanismo que permite la traducción de direcciones privadas en públicas y
viceversa. Accede a que una red tenga conexión con otra, siendo éstas de
diferentes rangos de direccionamiento IP para el envío o recibo de paquetes”6.
Para que una red privada tenga acceso a internet, se debe realizar por medio de
un dispositivo ubicado en la frontera de las dos redes, que tenga configurado NAT
para la traducción de direcciones.
Este dispositivo NAT cambia y traduce la dirección origen en cada paquete de
salida y el puerto de origen para que sea único. Estas traducciones de dirección se
almacenan en una tabla, para recordar qué dirección y puerto le corresponde a
cada dispositivo cliente y así saber dónde deben regresar los paquetes de
respuesta.
Ésto ayuda a garantizar la seguridad, ya que cada petición saliente o entrante
debe pasar por un proceso de traducción que ofrece la oportunidad de verificar y
autenticar la solicitud. NAT también se conserva en el número de direcciones IP
globales que una empresa necesita y permite a la empresa utilizar una única
dirección IP en su comunicación con el mundo.
2.2.1 Problemas de NAT
“Este mecanismo no puede utilizarse en terminales móviles y además,
muchas aplicaciones son incapaces de ser utilizadas mediante este tipo de
6 http://www.buenastareas.com/ensayos/Traductor-De-Direcci%C3%B3n-De-Red-Nat/2113453.html
29
direcciones, especialmente las relacionadas con la autenticación y la
seguridad de las comunicaciones.
Las tablas NAT son de gran tamaño, provocando que exista un bajo
rendimiento en la red, debido a la saturación que éstas le pueden generar.
Aumenta la probabilidad de pérdida de direcciones, debido a que se
manejan tablas de enrutamiento muy extensas.
Hace difícil el funcionamiento de ciertas aplicaciones, como las que
requieren de mayor velocidad, por ejemplo video-conferencia y video-
juegos.
Esconde la identidad de hosts que se encuentren dentro de la red, evitando
que los administradores cuenten con información propia”7.
2.3 IP MULTICAST
Multicast IP es una tecnología de ancho de banda de conservación que reduce el
tráfico de manera simultánea a la entrega de un único flujo de información a miles
de potenciales beneficiarios de las empresas y hogares. IP Multicast proporciona
el tráfico de aplicaciones de origen a múltiples receptores sin cargar la fuente o los
receptores durante el uso de un mínimo de ancho de banda de red. Paquetes de
multidifusión se replican en la red en el punto donde los caminos divergen por los
routers, lo que resulta en la prestación más eficiente de datos a múltiples
receptores. De acuerdo con la Internet Assigned Numbers Authority (IANA), su
directriz RFC3171 específica que las direcciones 224.0.0.0 a 239.255.255.255 se
designan como direcciones de multidifusión.
7 http://technet.microsoft.com/es-es/library/cc739126(WS.10).aspx
30
3. CONTEXTUALIZACIÓN DEL DIRECCIONAMIENTO IPV6
3.1 IPV6
“El protocolo de Internet versión 6 [RFC2460], es una tecnología que entrará poco
a poco a reemplazar a la versión 4, su desarrollo contribuye en la búsqueda de
soluciones a las problemáticas existentes en IPV4, está fue diseñada como la
evolución del IPv4 presentando características de seguridad y mejor
funcionamiento.”8
Desde inicios del protocolo de Internet se han podido realizar algunos desarrollos
que permitieron un mejor desempeño de éste, así actualmente se encuentra en
funcionamiento la versión 4. Este protocolo cuenta con un espacio de direcciones
de 32 bits, es decir (4.294.967.296), siendo esta cantidad muy limitada, pues con
el transcurso del tiempo se ha visto aún más la necesidad del aprovechamiento
del protocolo, pues las empresas que generan nuevos avances tecnológicos,
ofrecen día a día a usuarios públicos o privados nuevos tipos de productos y
servicios a través de la internet.
Debido a la falta de direccionamiento IP, se desarrolló IPV6, que a inicios de su
creación se llamó como: IPng (Protocolo de Internet de Nueva Generación), que
promete dar solución a los problemas del direccionamiento, dándole un
8 http://repositorio.utpl.edu.ec/bitstream/123456789/3735/1/004x679.pdf
31
mejoramiento en capacidad del envío de la información, la seguridad, la facilidad y
el rendimiento en los equipos.
“La nueva versión del protocolo usa direcciones de 128 bits lo cual equivale a
tener 2^128 = 340.283.366.920.938.463.463.374.607.431.768.211.456 direcciones
IP, que es representado en formato hexadecimal, esta cantidad de nuevas
direcciones, podrán ser utilizadas por miles de millones de usuarios que requieran
servicios en las diferentes plataformas que necesitan las direcciones IP como, las
páginas Web, los dispositivos móviles como teléfonos celulares, PDA´s,
dispositivos de consumo, vehículos, nuevas tecnologías de acceso como xDSL.
De esta manera esta versión del protocolo permite solucionar el grave problema
de direccionamiento que hoy en día se debe enfrentar con la versión 4.”9
3.1.1 Características principales de IPV6 con respecto a IPV4
“Como se ha comentado, IPv6 fue diseñado como una evolución natural a IPv4.
Es decir, todo lo que funcionaba perfectamente en IPv4 se ha mantenido, lo que
no funcionaba se ha eliminado, y se ha tratado de añadir nuevas funciones
manteniendo la compatibilidad entre ambos protocolos” 10 . Las características
principales de IPv6 son
Capacidades de Direccionamiento Extendida
“IPv6 incrementa el tamaño de dirección IP de 32 bits a 128 bits, para dar soporte
a más niveles de direccionamiento jerárquico, un número mucho mayor de nodos
direccionables, y una autoconfiguración más simple de direcciones. La
9 http://es.scribd.com/doc/44342778/Tdg-Ipv4-Ipv6-18n0v
10
http://www.ramonmillan.com/tutoriales/ipv6_parte1.php
32
escalabilidad del enrutamiento multienvío se mejora agregando un campo "ámbito"
a las direcciones multienvío. Y se define un nuevo tipo de dirección llamada
"anycast", usada para enviar un paquete a cualquiera de un grupo de nodos.
Simplificación del Formato de Cabecera
Se realizaron algunas modificaciones en el formato de la cabecera de IPV4,
siendo para IPV6 más simple, pues posee menor cantidad de campos, sus
estructuras y contenidos han sido mejorados; optimizando los recursos que utiliza,
pues se han eliminado algunos campos repetitivos que ya se representaban
anticuados, incrementando algunas características para hacer frente a las nuevas
necesidades de las redes actuales, como comunicación en tiempo real y
seguridad.
Soporte Mejorado para las Extensiones y Opciones
Los cambios en la manera en que se codifican las opciones de la cabecera IP
permiten un reenvío más eficiente, límites menos rigurosos en la longitud de
opciones y mayor flexibilidad para introducir nuevas opciones en el futuro.
Capacidad de Etiquetado de Flujo
Una nueva capacidad se agrega para permitir el etiquetado de paquetes que
pertenecen a "flujos" de tráfico particulares para lo cual el remitente solicita
tratamiento especial, como la calidad de servicio no estándar o el servicio en
"tiempo real".
33
Capacidades de Autenticación y Privacidad
Extensiones para utilizar autenticación, integridad de los datos, y (opcional)
confidencialidad de los datos, se especifican para el IPv6.”11
Características de movilidad.
“IPV6 permite que la comunicación pueda llevarse a acabo en cualquier momento
y lugar con un óptimo grado de operabilidad, así como de forma trasparente al
usuario, permitiéndole realizar su propia gestión y control. Cuestiones de gran
importancia si queremos disfrutar de servicios multimedia en los terminales
móviles de última generación (VozIP y Video). Protocolos como MPI (Mobile IP) o
HMIP (Hierarchical MIP) posibilitan la implantación y explotación real de estos
servicios.
Autoconfiguración de los nodos.
La autoconfiguración de direcciones es más simple. Especialmente en direcciones
Globales Unicast, los 64 bits superiores son asignados por un mensaje desde el
router (Router Advertisement) y los 64 bits más bajos son asignados con la
dirección MAC (en formato EUI-64). En este caso, el largo del prefijo de la subred
es 64, por lo que no hay que preocuparse más por la máscara de red. Además el
largo del prefijo no depende del número de hosts por lo tanto la asignación es más
simple.
11 http://www.rfc-es.org/rfc/rfc2460-es.txt.
34
Calidad de servicio y clases de servicios.
Capacidad de una red para sostener un comportamiento adecuado del tráfico que
transita por ella, cumpliendo con parámetros relevantes para el usuario final.” IPv6
fue diseñado con soporte extendido a QoS. En el encabezamiento se han incluido
dos campos relacionados a QoS, éstos son: Clase de tráfico e Identificador de
Flujo.
Multihoming.
Es la facilidad que se da a las empresas o instituciones que desean realizar el
cambio de un proveedor a otro por algún motivo, no necesitaría cambiar de
dirección, ni la realización de una nueva configuración de los equipos de
comunicación. Es decir cumple con la facilidad de realizar el cambio de ISP´s
(Proveedor de Servicios de Internet)”12.
3.1.2 Datagramas de encabezado IPV4 e IPV6
En la figura 1 se ilustra el encabezado de IPv4, que se encuentra conformado por
12 campos en su cabecera, éste será modificado en la nueva versión IPV6; pues
uno de los motivos fundamentales que llevan a que estos campos (Tipo de
servicio, indicadores, identificación y control de errores) sean eliminado, es por la
redundancia de bits en algunos de éstos, manejando la misma información de
diversas formas.
12 http://repositorio.utpl.edu.ec/bitstream/123456789/3735/1/004x679.pdf
35
El tamaño máximo de un datagrama es de 65536 bytes. Sin embargo, este valor
nunca es alcanzado porque las redes no tienen suficiente capacidad para enviar
paquetes tan grandes. Además, las redes en Internet utilizan diferentes
tecnologías por lo tanto el tamaño máximo de un datagrama varía según el tipo de
red.
Campos que mantienen su nombre IPV4 en IPV6
Campos que se eliminarán en IPV6
Campos que cambian de nombre y Posición en IPV6
Campo nuevo en IPV6
bits 4 8 16 20 32
Figura 1: Datagrama de encabezado IPV4
Fuente: http://docipv62009.blogspot.com/
En la Figura 2, IPV6 (RFC 2460), muestran un enfoque diferente donde la longitud
de la cabecera básica es de 40 bytes, siendo el doble que en el caso de IPV4,
pero con grandes ventajas, pues se ha simplificado el formato a tan solo 8 campos
y con un tamaño constante, permitiendo reducir el tiempo de procesamiento en
Versión Cabecera TOS Longitud Total
Identificación Indicador Desplazamiento de Fragmentación
TTL
Protocolo Checksum
Dirección Fuente de 32 bits
Dirección Destino de 32 bits
Opciones
36
routers y conmutadores, incluso mediante hardware, generando una mayor
facilidad en el procesamiento de los paquetes.
Además se ha introducido el concepto de flujo, consiguiendo que los routers, fuera
de encaminar, puedan conmutar algunos de los paquetes que procesan.
Por otro lado, se ha mejorado el mecanismo de codificación de los campos
optativos en la cabecera, dando una mayor flexibilidad para la introducción de
nuevas opciones futuras. Finalmente, IPv6 ha mejorado las capacidades de
autentificación y privacidad de los datos transmitidos. De esta forma, en IPv6 una
cabecera de autentificación garantiza que un paquete procede del origen que
realmente se indica, mientras que en IPv4 el paquete podría venir de un origen
distinto al indicado en la cabecera. Es decir, todo lo que funcionaba perfectamente
en IPv4 se ha mantenido, lo que no funcionaba se ha eliminado, y se ha tratado de
añadir nuevas funciones manteniendo la compatibilidad entre ambos protocolos
como se describe en la tabla 2.
bits 4 12 16 24 32
Versión Clase de Trafico Etiqueta de Flujo
Longitud de la Carga Útil Siguiente Cabecera
Limite de Salto
Dirección de Fuente de 128 bits
Dirección de Destino de 128 bits
Figura 2: Datagrama de encabezado IPV6
Fuente: http://mundopc.net/ipv6-la-proxima-generacion-de-internet/
37
Campo
Descripción Encabezado IPV6
Versión (“Version”)
(4bits) Indica la versión del protocolo IP, en
este caso su valor es igual a 6. El tener este
campo al comienzo del paquete, facilita una
rápida identificación de la versión IP y el
paso de ese paquete al protocolo de proceso
apropiado: IPV4 o IPV6.
Campo Renombrado
Tipo de servicio (TOS):
IPV4
Clase de tráfico (“Traffic
Class”): IPV6
(8 bits) Incluye información que permite a los
“routers” clasificar el tipo de tráfico al que el
paquete pertenece, aplicando distintas
políticas de enrutamiento según sea el caso.
Realiza la misma función que el campo
“Type of Service” de IPv4.
Nuevo Campo en IPV6
Etiqueta de flujo
(20 bits) Identifica a un flujo determinado de
paquetes, permitiendo a los “routers”
identificar rápidamente paquetes que deben
ser tratados de la misma manera, como
38
(“Flow Label”)
aquellos con una calidad de servicio de no
default o de tiempo real. También simplifica
el proceso de ruteo, manteniendo el rastro de
a dónde va el flujo fuente/destino y hacer una
búsqueda en las tablas.
Campo Renombrado
Longitud total: IPV4
Longitud de la carga útil
(“Payload Length”): IPV6
(16 bits) Indica el tamaño de la carga útil del
paquete. Las cabeceras adicionales son
consideradas parte de la carga para este
cálculo.
El campo Payload Length es similar al
campo longitud total de IPv4, excepto que
las 2 medidas operan. Payload Lengh
(IPV6) mide los datos después del
encabezado, mientras Total Length (IPv4)
mide los datos y el encabezado.
Campo Renombrado
Protocolo: IPV4
(8 bits) identifica el encabezado
inmediatamente siguiente de IPV6. Tiene dos
funciones,
Determinar:
39
Options; IPV4
Siguiente Cabecera
(“Next Header”): IPV6
la cabecera de extensión
siguiente.
Identificar el protocolo de capa
superior a la que el datagrama
debe pasar.
Este campo utiliza los mismos valores de
Protocol en IPV4.
Campo Renombrado
Tiempo de vida: IPV4
Límite de saltos
(“Hop Limit”): IPV6
(8 bits) Indica el máximo número de saltos que
puede realizar el paquete. Este valor es
disminuido en uno por cada nodo que reenvía el
paquete. Si el valor llega a cero, el paquete es
descartado, y un mensaje ICMP se envía al
remitente. Este campo es similar al campo Time-
to_Live (TTL) encontrado en IPV4, con una
excepción clave. El campo Hop Limit (IPV6)
mide el máximo de saltos que puede ocurrir
mientras el paquete es enviado por varios
nodos. El campo TTL en IPV4 puede ser medido
en saltos o segundos. Nótese que en Hop Limit
usado en IPv6, la base del tiempo no está
disponible más.
40
Dirección de fuente
(“Source Destination
Address”)
(128 bits) indica la dirección origen del
emisor del paquete. El formato de este
campo es definido más ampliamente en el
RFC 2373.
Dirección de destino
(“Source Destination
Address”):
(128 bits) Indica la dirección de destino final
del paquete.
Tabla 2: Descripción de los campos del Datagrama de encabezado IPV4 e IPV6
Fuente: Elaboración del autor
3.1.3 Encabezados de extensión13-14
El diseño de IPv6 simplifica el encabezado que se venía manejando en IPV4. Los
diseñadores le brindaron otro enfoque en lugar de colocar campos opcionales al
final de datagrama como se venía haciendo en IPV4, siendo éstos remplazados
para IPV6 como cabeceras de extensión que permiten añadirse únicamente si se
requiere, es decir, si es necesario fragmentar el datagrama, el encabezado de la
fragmentación es puesto en él.
13 http://www.normes-internet.com/normes.php?rfc=rfc2460&lang=es
14 RFC 2460-Protocolo de Internet, versión 6(IPV6).Diciembre 1998
41
La Figura 3 ilustra algunos ejemplos de encadenamiento de cabecera. El primer
datagrama es evidente IPv6 y TCP, el segundo contiene una cabecera de
extensión simple (ruta) y la cadena de datagrama tercero incluye dos cabeceras
de extensión (de enrutamiento y fragmento).
a) Plain datagram (no extension headers)
IPV6 Header Next=6(TCP)
TCP segment
b) Datagram containing Routing header
IPV6 Header
Next=43(Routing)
Routing Header
Next=6(Routing)
TCP segment
c) Datagram containing Routing and Frament headers
IPV6 Header
Next=43(Routing)
Routing Header
Next=44(Routing)
Fragment Header
Next=6(TCP)
TCP
segment
Figura 3: Header Chaining Examples
Fuente: http://tools.ietf.org/html/rfc2460
3.1.3.1 Orden de los encabezados de extensión (opcional)15
La tabla 3 muestra los encabezados de extensión de IPv6 (RFC 2460) que deben
admitir todos los nodos de IPv6.
15 http://dmrodriguez.50megs.com/IPV6/IPV6_7.html
42
Value
(Decimal)
Extensión Header
0 Hop- by- hop option
60 Destination Options Header
43 Routing Header
44 Fragment Header
51 Authentication Header (AH)
50 Encapsulating Security Payload Header.
60 Destination Option
Protocolos
6 TCP
8 EGP
9 IGP
17 UDP
46 RSVP
47 GRE
58 ICMP
Tabla 3: Orden de los encabezados de extensión
Fuente: http://dmrodriguez.50megs.com/IPV6/IPV6_7.html
43
3.1.3.1.1 Hop-by-Hop Options Header
El encabezado Hop-by-Hop Options sirve para llevar información opcional que
debe ser examinada por cada nodo a lo largo de una ruta de la entrega del
paquete.
Consta de un formato que contiene tres campos:
Next Header (encabezado siguiente): Tiene como finalidad identificar el
encabezado que da paso o continuidad a la opción hop-by-hop. Utiliza los
mismos valores que en el campo Protocol que se maneja en IPv4, además
contiene 8 bits de longitud.
Header Extension Length (Longitud de extensión de encabezado): Es el
número de bloques de 8 bytes del encabezado de extensión Hop-by-Hop
Options, sin incluir los 8 primeros bytes. Contiene un tamaño de 8 bits de
longitud.
Options (Opciones): Es un entero múltiplo de 8 octetos de largo. Una opción es
un encabezado dentro del encabezado de opciones de hop-by-hop que
describe una característica específica de la entrega del paquete o proporciona
relleno. Cada opción se codifica en el formato tipo-longitud-valor (TLV), que se
utiliza comúnmente en los protocolos TCP/IP. El tipo de opción identifica a la
opción y determina el tipo de tratamiento por parte del nodo de procesamiento.
La longitud de la opción identifica su longitud
3.1.3.1.2 Destination Options Header
La cabecera Opciones de destino se utiliza para llevar información opcional que
necesita ser analizada por el (los) nodo(s) del destino del paquete(s). La cabecera
44
Opciones de Destino se identifica mediante el valor de 60 en el campo Next
Header del encabezado procedente, y su formato contiene los siguientes campos:
Next Header (encabezado siguiente): Tiene como finalidad identificar el
encabezado que da paso o continuidad a la opción de destino de cabecera.
Utiliza los mismos valores que en el campo Protocol que se maneja en
IPv4, [RFC-1700], Además contiene 8 bits de longitud.
Header Extension Length (Longitud de extensión de encabezado): Es el
tamaño del encabezado de extensión Options Header, al momento de ser
medido es dividido en bloques de 8 octetos, sin incluir los 8 primeros bytes,
su tamaño en longitud es de 8 bits.
Options (Opciones): Es un entero múltiplo de 8 octetos de largo. Cada
opción se codifica en el formato tipo-longitud-valor (TLV), que se utiliza
comúnmente en los protocolos TCP/IP. El tipo de opción identifica a la
opción y determina el tipo de tratamiento por parte del nodo de
procesamiento. La longitud de la opción identifica su longitud.
El encabezado Destination Options se utiliza de dos maneras:
Si hay un encabezado Routing (Enrutamiento), especifica opciones de
entrega o de proceso en cada destino intermedio.
Especifica opciones de entrega o de proceso en el destino final.
3.1.3.1.3 Routing Header
IPv6 utiliza el encabezado de extensión Routing para definir una ruta de origen,
una lista de destinos intermedios para que el paquete viaje por su ruta de acceso
45
al destino final. El encabezado Routing se identifica mediante el valor 43 en el
campo Next Header (Encabezado siguiente) del encabezado anterior.
Su formato contiene los siguientes campos:
Next Header (encabezado siguiente): Se define del mismo modo que en el
encabezado de extensión Hop-by-Hop Options, pues identifica el
encabezado que continúa inmediatamente al encabezado routing.
Header Extension Length (Longuitud de extensión de encabezado): Se
define del mismo modo que en el encabezado de extensión Hop-by-Hop
Options, mide la longitud del encabezado routing en unidades de tamaño
de 8 bytes, teniendo en cuenta que los 8 primeros bytes no son tenidos en
cuenta.
Routing Type (Tipo de enrutamiento): Contiene una longitud de 8 bits, el
RFC2460 define una variante simple, el encabezado Routing Type 0. Los
datos específicos del tipo de enrutamiento son una lista de direcciones de
destinos intermedios que serán visitadas durante la ruta del paquete.
Cuando el paquete IPv6 llega a un destino intermedio, se procesa el
encabezado Routing y la dirección del siguiente destino intermedio (según
el valor del campo Segments Left) se convierte en la dirección de destino
del encabezado de IPv6.
Segments Left (Segmentos que quedan): Contiene una longitud de 8 bits,
indica el numéro de nodos que quedan, es decir, el número de nodos
intermedios explícitamente listados que todavía séran visitados antes de
alcanzar el destino final.
La figura 4, contiene el número de elementos de la secuencia. Cuando se entrega
a la dirección de destino (en realidad el primer puesto de control) el router
46
encuentra el servicio de enrutamiento encabezado y se da cuenta que es sólo una
estación intermedia.
Por lo tanto, los swaps de la dirección en el destino Dirección y la dirección
enésima desde atrás de la secuencia de cabecera de enrutamiento (donde N es el
actual valor de los Segments Left). Segments Left es que disminuyó en un 1 y
datagrama se envía a los nuevos destinos (que es el próximo punto de control).
Este procedimiento se ejecuta en cada punto de control. Como se puede ver el
encabezado de Segments Left en realidad separa las direcciones que ya han
pasado y las direcciones que se visitarán en la secuencia del punto de control.
Cuando el destinatario ve que Segmentos Left contiene cero, se sabe que este es
el destino final de los datagramas, el datagrama será procesado y se pasa al
protocolo de capa superior.
S X Y Z D
IPV6
source: S
IPV6
source: S
IPV6
source: S
IPV6
source: S
Destination:X
Destination: Y
Destination: Z
Destination: D
Routing
Seg. left: 3
Routing
Seg. left: 2
Routing
Seg. left: 1
Routing
Seg. left: 0
Address[1]:Y Address[1]: Y
Address[1]: X
Address[1]: X
Address[2]:Z Address[2]: Z
Address[2]: Y
Address[2]: Y
Address[3]:D Address[3]: D
Address[3]: D
Address[3]: Z
Figura 4: Cabecera de enrutamiento durante transporte de datagramas
Fuente: http://www.networkdictionary.com/Networking/Routing-Header.php
47
3.1.3.1.4 Fragment Header16
El encabezado Fragment es usado por una fuente IPV6 para trasmitir paquetes
que son más grandes de los que cabrían en la unidad máxima de trasmisión
(MTU). Si el datagrama IPv6 es más largo que el MTU, los datos deben dividirse y
se inserta en el conjunto de datagramas IPv6 más pequeños, llamados
fragmentos. La presencia del encabezado Fragment es identificada por un valor
de 44 en el campo Next Header del encabezado procedente.
Estos fragmentos son transportados de forma individual y acoplados por el
receptor para crear el datagrama original. Esta es la fragmentación. El nodo
receptor recoge los fragmentos y utiliza valores de identificación para el grupo de
los correspondientes fragmentos, gracias a la particularidad de ser capaz de
darles el orden correcto. Cuando los datos se encuentran completos y no existen
fragmentos más a la izquierda, se encuentra en capacidad de reconstruir el
datagrama original. El encabezado Fragment contiene 6 campos:
El campo Next Header tiene 8 bits de largo e identifica el encabezado que
continúa inmediatamente al header Fragment.
El campo Reserved tiene 8 bits de largo, y está reservado para uso futuro.
Este campo es inicializado en cero para la transmisión e ignorado en la
recepción.
El campo Fragment Offset es un entero sin signo de 13 bits que mide la
compensación, en unidades de 8 octetos, de los datos que continúan este
16 Darwing Lamarck Santono Yunes.IPV6:Nueva Generación Protocolo de Internet.2004.pag 172
Fuente: http://www.lac.ipv6tf.org/docs/tutoriales/IPv6-LACTF.pdf
48
encabezado, relativo al comienzo de la parte fragmentable del paquete
original.
El campo reservado tiene 2 bits de largo, y está reservado para uso futuro.
Este campo es inicializado en cero para la trasmisión e ignorado en la
recepción.
La bandera M es de 1 bit de longitud y determina si más fragmentos vienen
(M=1) o si éste es el último fragmento (M=0).
La identificación es única para cada datagrama original. Se utiliza para
detectar los fragmentos del mismo datagrama (sosteniendo los mismos
valores de identificación), este campo es generado por el nodo fuente, y
contiene un tamaño de 32 bits de largo.
La figura 5, muestra el proceso que se lleva al fragmentar un paquete IPV6, éste
se divide inicialmente en una parte que se puede fragmentar y otra parte que no
se puede fragmentar:
Para un paquete IPV6, en la parte que no se puede fragmentar, éste tiene
la característica que el paquete original debe ser procesado por cada nodo
intermedio entre el nodo de fragmentación u origen y el destino. Esta parte
consta del encabezado de IPv6, el encabezado Hop-by-Hop Options
(Opciones de salto a salto), el encabezado Destination Options (Opciones
de destino) para destinos intermedios y el encabezado Routing.
Para un paquete IPV6,en la parte que se puede fragmentar sólo debe
procesarse en el nodo de destino final, se encuentra constituida de un
encabezado Authentication, el encabezado Encapsulating Security Payload
(Carga de seguridad de encapsulación), el encabezado Destination Options
para el destino final y la unidad PDU de nivel superior.
49
Parte no Fragmentable
Parte Fragmentable
Paquete Ipv6 original
Fragmentos
Parte no Fragmentable
Encabezado de Fragmento
Ultimo fragmento
Figura 5: Proceso de fragmentación para un paquete IPV6
Fuente: http://dmrodriguez.50megs.com/IPV6/IPV6_7.html
3.1.3.1.5 Authentication Header 17
Permite la autenticación de los datos, efectuando una comprobación del nodo que
realiza el envío del paquete, además aprueba que los datos no sean modificados y
sean íntegros durante el envío. El encabezado Authentication, que se describe en
RFC 2402, forma parte de la arquitectura de seguridad para el Protocolo Internet
definida en RFC 2401.
17 RFC2402 Authentication Header Noviembre 1998
Parte no Fragmentable
Encabezado de fragmento
Fragmento 1
Parte no Fragmentable
Encabezado de Fragmento
Fragmento 2
50
El encabezado Authentication contiene 6 campos:
El campo Next Header Identifica el encabezado que continúa
inmediatamente al encabezado Authentification. Posee 8 Bits de largo.
El campo Payload Length (Longitud del encabezado), tiene 8 bits de
longitud y provee la longitud del encabezado Authentication en palabras de
32 bits, menos 2 (los primeros 8 octetos del encabezado Authentication no
son contados). El valor mínimo es 1, que consiste en el valor de
Authentification de 96 bits (3 palabras de 32 bits), menos el valor 2 (3-2=1).
Este mínimo es solo usado en el caso de un algoritmo de autenticación
“nulo”, empleado para procesos de depuración.
El campo Reserved está reservado para usos futuros. Es inicializado en
cero para la trasmisión.
El campo Security Parameters Index (SPI o Índice de parámetros de
seguridad) identifica una asociación de seguridad (SA) IP (IPSec, IP
Security) específica. La asociación de seguridad, como se define en el
RFC 2401, es una conexión simple y lógica que es creada para propósitos
de seguridad. SA puede comprimir muchos parámetros, incluyendo el
algoritmo Authentication, claves del algoritmo de authentication y otros.
Según RFC 2402, el valor de SPI = 0 puede ser usado para propósitos
locales, de implementación específicas. Otros valores, en el rango de 1 –
255, son reservados para uso futuro por la Internet Assigned Numbers
Authority (IANA).
El campo Sequence Number (Número de secuencia) proporciona
protección contra la reproducción, tanto el contador el contador del que
envía como el que recibe son inicializados en cero cuando una asociación
de seguridad es establecida. Contiene un número de 32 bits.
51
Authentication Data (Datos de autenticación) que contiene un valor de
comprobación de integridad (ICV, Integrity Check Value). ICV proporciona
autenticación de datos e integridad. Es un campo de longitud variable, pero
debe ser múltiplo integral de 32 bits.
3.1.3.1.6 Encapsulating Security Payload Header 18
El encabezado Encapsulating Security Payload (ESP) (RFC 2406), proporciona
servicios de autenticación de origen de datos, provee confidencialidad, integridad
sin conexión, un servicio anti-“replay” y confidencialidad de flujo limitado de tráfico
para la carga encapsulada.
El encabezado ESP contiene 7 campos:
Security Parameters Index (SPI o Índice de parámetros de seguridad) es un
campo obligatorio, que identifica la asociación de seguridad para este
datagrama, relativo a la dirección IP destino en el encabezado IP con el que
este encabezado de seguridad es asociado, y relativo al protocolo de
seguridad empleado.
El campo Next Header tiene 8 bits de largo e identifica el encabezado que
inmediatamente continúa al encabezado ESP.
El campo Sequence Number (Número de secuencia) proporciona
protección contra la reproducción. El contador del que envía y el contador
del que recibe son inicializados en cero cuando una asociación de
seguridad es establecida.
18 RFC2406.IP Encapsulation Security Protocol (ESP). Noviembre 1998
52
El campo Payload Date es de longitud variable que contiene datos descritos
por el campo Next Header, es un campo obligatorio.
El campo Padding (Relleno), puede opcionalmente contener 0 – 255
octetos de información de relleno, como requerimiento por la
implementación de seguridad.
El campo Padding Length (Longitud de relleno) indica el número de octetos
de relleno (0 - 255).
El campo Authentication Data (Datos de autenticación) es de longitud
variable, contiene el valor de comprobación de integridad (ICV) calculado
sobre el paquete ESP menos los de autenticación de datos. El campo
Authentication Date es opcional, y es incluido sólo si esa asociación de
seguridad ha seleccionado servicio de autenticación.
3.1.3.1.7 Destination Options Header
Proporciona información adicional relacionada con el datagrama o sus
procesamientos. Están separados en dos grupos: Las opciones dedicadas a cada
nodo de reenvío del datagrama (opciones hop-by-hop), y las opciones destinadas
a la acogida destino único (destino opciones).
En la Tabla 4 se muestran las opciones de Hop-by-hop (si existe), se colocan al
comienzo de la extensión de la cadena de cabeceras, porque son importantes
para cada nodo de reenvío del datagrama.
La Tabla 5 muestra la ubicación de opciones de destino, éstas se dividen en dos
tipos: Opciones dedicadas a la meta final (que se encuentran en el extremo de la
extensión de la cadena de cabeceras) y las opciones asignadas al siguiente host
53
especificado por cabecera de enrutamiento (que se encuentra justo antes de la
cabecera de enrutamiento).
Value
Meaning
0
Pad1
1
PadN
5
Router alert
194
Jumbo payload
Tabla 4 : Hop-by-hop Options
Fuente: http://www.secdev.org/projects/scapy/files/scapy6.py
Value
Meaning
0
Pad1
1
PadN
201
Home Address
Tabla 5 : Destination Options
Fuente: http://www.secdev.org/projects/scapy/files/scapy6.py
54
El significado de cada opción es el siguiente:
PadN Pad1 (Relleno): Ellos no tienen ningún contenido, simplemente
alinean el contenido siguiente a la posición adecuada.
Alerta de Router (Router alert): Brinda asesoramiento al router en el
contenido que puede ser importante.
Carga útil Jumbo (Jumbo payload): Permite el transporte de datagramas
que excedan el máximo de 64 KB. La opción hop-by-hop pide un
tratamiento especial que es necesario para procesar estos jumbogramas.
Domicilio (Home Address): Es una parte del apoyo a la movilidad. Contiene
la dirección de viaje del nodo móvil.
3.1.4 Representación del direccionamiento IPV619
Las direcciones IPv6 tienen una forma diferente de representarse a las IPv4, a continuación se relacionan éstas:
Forma hexadecimal: Una dirección IPV6 válida es representada por
valores hexadecimales, los cuales se dividen en ocho piezas de 16 bits de
dirección.
x : x : x : x : x : x : x : x
19 http://www.normes-internet.com/normes.php?rfc=rfc2373&lang=es
55
Forma comprimida: Existen reglas que pueden ser aplicadas a las
direcciones IPV6 con el objetivo de resumir un poco la sintaxis de las
direcciones.
2001:0000:0000: 1234:0000:A1A0:ABEF:0816
Puede aceptar lo siguiente:
Las letras pueden ser mayúsculas o minúsculas y las dirección se puede
escribir como:
2001:0000:0000:1234:0000:a1a0:abef:0816
Los “ceros” consecutivos son opcionales y se pueden representar en la
dirección como:
2001:0:0: 1234:0:a1a0:ABEF:0816
Los campos sucesivos de “ceros” pueden ser reemplazados por “::” y la
dirección puede tomar la forma :
2001::1234:0:A1A0:ABEF:816
Pero, cualquier dirección que tenga más de una vez la representación “::”
será una dirección inválida ya que solamente se puede usar esa
representación una sola vez.
56
Forma mixta. Esta forma combina las direcciones IPv4 e IPv6. Una forma
alternativa que a veces es más conveniente cuando se trata de un entorno
mixto de nodos IPv4 e IPv6.
x: x: x: x: x: x: dddd, donde las 'x' son los valores hexadecimales de las
seis partes de 16 bits de orden superior de la dirección, y las 'd' son los
valores decimales de las cuatro piezas de orden inferior de 8 bits de la
dirección (representación estándar IPv4). Ejemplos:
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0: FFFF: 129.144.52.38
o en forma comprimida:
:: 13.1.68.3
:: FFFF: 129.144.52.38.
3.1.5 Nomenclatura de prefijos
La representación de los prefijos IPv6 se realiza del siguiente modo:
dirección-IPv6 /longitud-del-prefijo, donde
dirección-IPv6 = una dirección IPv6 en cualquiera de las notaciones válida.
longitud-del-prefijo = valor decimal indicando cuántos bits contiguos de la
parte izquierda de la dirección componen el prefijo.
57
Ejemplo: Una representación legal de los 60 bits de prefijo es:
12AB00000000CD3 (hexadecimal):
12AB: 0000:0000: CD30: 0000:0000:0000:0000 / 60
12AB:: CD30: 0:0:0:0 / 60
12AB: 0:0: CD30:: / 60
3.1.6 Arquitectura de direccionamiento en IPV6 20
3.1.6.1 Unicast
Es una dirección para una sola interface. Un paquete enviado a una dirección
unicast es entregado sólo a la interfaz identificada con dicha dirección.
Cada dirección IPV6 pertenece a un ámbito, que es un área dentro de la cual ésta
puede ser utilizada como un identificador único de una o varias interfaces.
En el caso de las direcciones unicast se podrían reflejar en ámbitos de diferentes
tipos como se muestra en la figura 6.
20RFC4291IP Version 6 Addressing Architecture Febrero 2006
58
Figura 6: Alcance de direcciones Unicast en IPV6
Fuente: https://proyectos.i-nis.com.ar/projects/4/wiki/IPv6
DIRECCIONES SITIO LOCAL
DIRECCION DE ENLACE LOCAL
DIRECCIONES GLOBALES
MISMO NODO O LOOPBACK
Permite la comunicación con origen y destino en un mismo nodo IPV6
Identifica todos los dispositivos dentro de un dominio cualquiera de nivel 2.
Identifica todos los dispositivos ubicados en un dominio administrativo, que normalmente contiene múltiples enlaces distintos.
Identifica a todos los dispositivos que pueden alcanzarse a través de internet.
59
3.1.6.1.1 Direcciones de enlace local (link-local)21
En IPV6 las direcciones de enlace local han sido diseñadas para direccionar un
mismo enlace para propósitos de autoconfiguración (mediante identificadores de
interfaz), descubrimiento del vecindario, o situaciones en las que no hay routers.
Por tanto, los routers no pueden retransmitir ningún paquete con direcciones
fuente o destino que sean locales de enlace (su ámbito está limitado a la red
local).
10bits 54 bits 64 bits
1111111010 0 Interface ID (EUI-64)
Figura 7: Estructura de dirección IPv6 enlace local.
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
Como se muestra en la figura 7, la estructura de las direcciones unicast de enlace
local se encuentra conformada por 10 bits que identifican el prefijo, los siguientes
54 bits después de este campo deberán estar en ceros y por ultimo hay un campo
que consta de 64 bits el cual se configura con la dirección MAC de cada máquina
con el fin de que no se vaya a repetir ninguna dirección en la red.
21 RFC3513,Protocolo de Internet versión 6 (IPv6) Abordar Arquitectura, abril 2003
FE80::/10 = FE80:0:0:0:/10
60
3.1.6.1.2 Direcciones de sitio local22-23
Las direcciones locales de sitio se definen en el RFC4193, éstas permiten
Identificar interfaces en un mismo ‘sitio’ local u organización, sin la necesidad de
un prefijo global. Se configuran mediante un identificador de subred de 16 bits, los
routers no deben trasmitir fuera del sitio ningún paquete cuya dirección fuente o
destino sea “local destino” (su ámbito está limitado a la red local o de la
organización).
Han sido desaprobadas en el RFC 3879, debido a que, pese a quedar definidas
teóricamente, en la práctica su definición es ambigua, lo que supone un problema
tanto para los desarrolladores de aplicaciones como para los routers. Aunque
hayan sido desaprobadas, esto no ha impedido su uso, por lo menos hasta que se
haya estandarizado el cambio y éstas hayan sido reemplazadas. Se encuentran
conformadas por un formato que se muestra en la figura 8.
fec0::/10
10bits 54 bits 64 bits
1111111011 ID Subred Interface ID (EUI-64)
Figura 8: Estructura de dirección IPv6 para enrutamiento de uso local.
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
22 RFC 4193 Unique local direcciones IPv6 Unicast, Octubre 2005
23 RFC3879 Obsoleto sitio de las direcciones locales , Septiembre 2004
61
3.1.6.1.3 Direcciones de enrutamiento global (Global Address)24-25
El prefijo de enrutamiento global ha sido diseñado para ser estructurado
jerárquicamente por los RIR's (Regional Internet Registries) y los ISP's (Internet
Service provider), pues son las direcciones utilizadas para el tráfico IPV6. Se
encuentran conformadas por un formato que se ilustra en la Figura 9.
2001: ó 3ffe
3bits
45 bits 16 bits 64 bits
001 Prefijo Ruteable global ID Subred Interface ID (EUI-64)
Provider site Host
Figura 9: Estructura de dirección IPv6 para enrutamiento global.
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
El prefijo 001 es asignado a un rango de direcciones Unicast globales agregables,
éste además incluye 4 campos que permiten establecer los niveles de
identificación.
24 RFC 3587 Direccion de enrutamientos globales, Agosto 2003
25 RFC2450 Proyecto de TLA y NLA reglas de asignación, Diciembre 1998
62
Para asignar este prefijo se utiliza la tabla de niveles de identificador de
agregación (TLA) que contiene el más alto nivel de información sobre direcciones
de enrutamiento y su tamaño es de 13 bits, lo cual limita el número del más alto
nivel de rutas a 8192. La propuesta para la asignación de TLA está documentada
en RFC 2450.
El campo Reserved, que tiene 8 bits de longitud, está provisto para permitir
la expansión más amplia de campos TLA o NLA.
El campo próximo nivel de identificador de agregación (NLA), es usado por
las organizaciones para crear una jerarquía de direccionamiento e
identificar sites, su tamaño es de 24 bits.
El identificador de la subred. El extremo de la red puede ser dividido en
subredes. Esta parte de la dirección sirve para identificar las subredes
individuales.
3.1.6.2 Identificador de interfaz– (EUI-64)
Los identificadores de interfaz en las direcciones IPV6 unicast se utilizan para
identificar interfaces en un determinado enlace. Se encuentra definido en el RFC
3513.
Para las direcciones unicast en IPV6 las “Interface ID” deben de ser de 64 bits,
por lo que, para convertir una dirección de enlace IEEE 802 48-bit MAC se
requiere de la conversión de la dirección MAC en una versión modificada EUI-64,
que está relacionada con el séptimo bit del identificador de 64 bits. Este bit
63
distingue identificadores globales (en todo el mundo unicast). El valor de este bit
se invierte en las direcciones IPv6. El valor 0 de este bit indica una identificación
local, mientras que un valor de 1 indica una identificación global. Además se
inserta el valor entre el tercero y cuarto byte de la dirección MAC para alcanzar los
64 bits necesarios. Por ejemplo, la dirección MAC 00:8 C: a0: c2: 71:35 se
convierte a la interfaz 028c ID: a0ff: FEC2: 7135 (la conversión se ilustra en la
Figura 10).
0 0 : 8 C : A 0 : C 2 : 7 1 : 3 5
0000 0000 1000 1100 1010 0000 1100 0010 0111 0001 0011 0101
0000
Invertir 7mo Bit
0000
0010
1000
1100
1010
0000
1111
1111
1111
1110
1100
0010
0111
0001
0011
0101
EUI-64
0 2 8 C : A 0 F F : F E C 2 : 7 1 3 5
Figura 10: Conversión dirección MAC de 48 bits a 64 bits. (Identificador de Interfaz).
Fuente: http://generalidadesipv6.blogspot.com/2009_11_01_archive.html
0010
Insertar cadena FFFE
64
3.1.6.3 Direcciones reservadas26
3.1.6.3.1 La dirección no especificada
La dirección 0:0:0:0:0:0:0:0 toma como nombre dirección no especificada, de
forma abreviada se representa “0::0” o “::”. Nunca debe ser asignada a ningún
nodo, pues indica la ausencia de una dirección. Un ejemplo de uso de esta
dirección es en el campo dirección origen de un paquete IPv6 enviado por un host
durante su proceso de inicialización, antes de que haya obtenido su propia
dirección.
La dirección de no especificada no puede ser usada como dirección origen para
paquetes salientes, y un paquete con la dirección no especificada como destino
nunca puede ser enviado fuera del nodo ni debe ser encaminado por los routers.
3.1.6.3.2 Dirección Loopback ó dirección de bucle invertido.
La dirección unicast 0:0:0:0:0:0:0:1, se define como dirección loopback, ésta
puede ser utilizada por un nodo destino para el envío de un paquete IPV6 a sí
mismo.
La dirección loopback no debe ser utilizada como fuente de la dirección en
Paquetes IPv6 que se envían fuera de un solo nodo. Un paquete IPv6 con una
dirección de destino de loopback nunca debe ser enviado fuera de un solo nodo y
nunca debe ser remitido por un router IPv6.
26Belén Aldecoa Sánchez del Río Luis Alberto Ramón Surutusa. Redes de Banda Ancha IPV6.pag
53.
Fuente: http://es.scribd.com/doc/51187582/6/Direcciones-Unicast
65
3.1.6.4 Anycast27
Una dirección anycast es un identificador que se asigna a múltiples interfaces
(típicamente pertenecen a diferentes nodos). Un paquete enviado a una dirección
Anycast es entregado en una (cualquiera) de las interfaces identificadas con dicha
dirección (la más próxima, de acuerdo a las medidas de distancia del protocolo de
encaminamiento). Nos permite crear, por ejemplo ámbitos de redundancia, de
forma que varias máquinas puedan ocuparse del mismo tráfico según una
secuencia determinada (por el routing) si la primera “cae”.
Una dirección anycast es difícil de distinguir. No hay un rango de espacio dedicado
a este tipo de direcciones, pues ocupan el mismo rango de direcciones Unicast. La
configuración local es responsable de identificación de las direcciones de difusión
ilimitada.
El uso de este tipo de direcciones es brindar una identificación a un conjunto de
routers que pertenecen a una organización que proporciona los servicios de
internet, o para identificar un conjunto de routers conectados a una red particular.
Las direcciones Anycast no deben de ser utilizadas como una dirección de origen
de un paquete IPV6, son rangos que son asignados por el administrador de la red
o proveedor de servicios, para uso exclusivo de identificación de los router y no
para asignación de los host.
27 http://www.normes-internet.com/normes.php?rfc=rfc4291&lang=es
66
3.1.6.5 Multicast 28
Se define en el RFC 3513, este tipo de direcciones cumple como un Identificador
para un conjunto de interfaces (por lo general pertenecientes a diferentes nodos).
Un paquete enviado a una dirección multicast es entregada a todas las interfaces
identificadas por dicha dirección. La misión de este tipo de paquetes es evidente:
aplicaciones de retrasmisión múltiple (Broadcast), teniendo en cuenta que para
IPV6 no existen direcciones de Broadcast, las funciones son realizadas por
direcciones multicast. En la Tabla 6 se ilustra el número de direcciones Multicast
Reservadas y nunca serán asignadas a ningún grupo.
Direcciones Multicast Reservadas
FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
Tabla 6: Direcciones Multicast Reservadas
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
28 RFC3513,Protocolo de Internet versión 6 (IPv6) Abordar Arquitectura, abril 2003
67
Las direcciones Multicast en IPV6 se identifican por el prefijo ff00:: / 8. Así que
cada dirección de multidifusión se inicia con "ff", que los hace fáciles de distinguir.
El octeto siguiente a la inicial obligatoria “ff” contiene cuatro banderas y un valor de
4 bits que define el alcance de multidifusión, como se muestra en la figura 11.
128 Bits
8 Bits 4 Bits 4 Bits 112 Bits
FF Flags Scope Group ID
11111111
X R P T
0 0 0
0= Permanente
1= Temporal
Figura 11: Estructura de una dirección Multicast IPV6.
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
El campo flags contiene cuatro flags (banderas) de 1 bit. Los 3 bits de las
banderas más significativas están reservados para uso futuro y son inicializados
en cero. La bandera T como se describe en el RFC 3513, indica si la dirección de
multicast es permanente (valor 0) o transitoria (valor 1).
En el caso de las direcciones transitorias (valor 1), éstas se clasifican en:
Direcciones generales transitorias: Son las direcciones con todas las
banderas a 0, pero el T bit con valor 1. Este tipo de direcciones se pueden
utilizar para sesiones de pruebas.
68
Prefijo basado en direcciones Unicast para IPV6: Ver en la figura 12. Se
caracterizan por tener las dos primaras banderas en cero y la bandera P y T
se definen en 1. El RFC 3306 [RFC3306]29 define una manera de obtener
direcciones de este tipo.
FF Flags Scope res Plen Prefix Group(ID)
8 4 4 8 8 64 32 bits
X R P T
0 0 1 1
Figura 12: Estructura de direcciones IPV6 Multicast (Prefijo Basado en direcciones Unicast).
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
Direcciones incorporadas (Punto de encuentro (RP)): El RFC 3656
[RFC3656]30 define una manera de integrar RP (Rendezvous Point). El
problema se reduce con la asignación de direcciones de RP incorporado
porque no puede haber una colisión sólo entre las direcciones derivadas del
mismo RP. Ver en la figura 13.
29 RFC 3306 Unicast-Prefijo basado en direcciones IPv6 Multicast, agosto 2002
30 RFC3656 Rendezvous Point, Diciembre 2003
69
FF Flags scope res Rpad plen Prefix Group ID
8 4 4 4 4 8 64 32bits
X R P T
0 1 1 1
Figura 13: Estructura de una dirección Multicast en IPV6 - incorporado (RP)
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
El campo de posibilidades hace que sea posible controlar el alcance de la emisión
deseada con mucha facilidad. Ésto fue hecho en IPv4 con el valor TTL. El campo
de alcance tiene un impacto importante en el proceso de asignación, ya que
tiene que ser especificado para cada asignación. Ver tabla 7.
Scope o alcance Significado
0 Reservado
1 Alcance de Nodo local
2 Alcance de link local
3 Sin Asignar
4 Administración de ámbito local
5 Alcance local del sitio
6 Sin Asignar
7 Sin Asignar
8 Alcance de organización local
9 Sin Asignar
A Sin Asignar
B Sin Asignar
C Sin Asignar
D Sin Asignar
E Alcance Global
F Reservado
Tabla 7: Posibilidades campo Scope
Fuente: http://www.normes-internet.com/normes.php?rfc=rfc3513&lang=es
70
Los restantes 112 bits de la dirección de multidifusión mantienen la identificación
del grupo. Si en el bit T-bandera conjunto, el identificador es válido dentro de su
ámbito de aplicación solamente, esto significa que el mismo identificador puede
utilizarse fuera el alcance o de diferente alcance para hacer frente a otro grupo. Si
la dirección no es transitoria, la dirección es independiente del ámbito de
aplicación. Su significado sigue siendo el mismo y el alcance sólo limita la
propagación del subgrupo de participantes. Definiciones adicionales de la
estructura exterior del grupo de multidifusión ID se proporcionan en [ RFC3306 ].
Por ejemplo, el grupo (permanente) identificador 101 (hexadecimal) se ha
asignado a todos los servidores NTP. Si alguien envía un datagrama dirigido a
este grupo, el alcance de las direcciones tendran el siguiente significado:
FF01:: 101 - todos los servidores NTP en la misma interfaz
FF02:: 101 - todos los servidores NTP en el mismo enlace
ff0e:: 101 - todos los servidores NTP en toda la Internet
El alcance es un principio innovador que ofrece un mecanismo para restringir la
distribución de multidifusión. El tiempo de vida de datagrama (TTL) se utiliza en
IPv4 para resolver el mismo problema. La parte correspondiente de la dirección
que define el ámbito de la red, en la distribución no podrá ser superior - los
datagramas no pueden cruzar el límite de sus ámbito de aplicación. Por ejemplo,
puede estar seguro de que los datagramas dirigida ff02: nunca saldrá de la red
física a la que se han enviado.
Algunas direcciones de multidifusión son reservadas, tiene significado predefinido.
Otras son simplemente prohibidas, al igual que las direcciones que contengan
todos los grupos de identificador cero y una bandera de T en cero. El RFC 3513
define el significado de algunas direcciones de multidifusión, de hecho
71
sustituciones de las emisiones anteriores. Éstas permiten el envío de paquetes a
todos los nodos o routers dentro de un ámbito determinado.
FF01:: 1 - todos los nodos en la misma interfaz
FF02:: 1 - todos los nodos en el mismo enlace (capa 2 de red)
FF01:: 2 - todos los routers en lala misma interfaz
FF02:: 2 - todos los routers en el mismo enlace
FF05:: 2 - todos los routers en el mismo sitio
Otro tipo de dirección multicast, es de nodo solicitado, ésta facilita la consulta
eficaz de los nodos de la red durante la resolución de direcciones. IPv6 utiliza el
mensaje de solicitud de vecino para efectuar la resolución de direcciones. Sin
embargo, en lugar de utilizar la dirección para todos los nodos de ámbito local del
vínculo como destino del mensaje de solicitud de vecino, que afectaría a todos los
nodos IPv6 del vínculo local, se utiliza la dirección de multidifusión de nodo
solicitado. La dirección de multidifusión de nodo solicitado consta del prefijo
FF02::1:FF00:0/104 y los últimos 24 bits de la dirección IPv6 que se esté
resolviendo.
El resultado de utilizar la dirección de multidifusión de nodo solicitado es que la
resolución de direcciones, que suele producirse en un vínculo, no necesita utilizar
un mecanismo que afecte a todos los nodos de la red. De hecho, son muy pocos
los nodos que se ven afectados durante la resolución de direcciones. En la
práctica, debido a la relación entre la dirección MAC de Ethernet, el Id. de interfaz
IPv6 y la dirección de nodo solicitado, ésta actúa como una dirección de
pseudounidifusión para lograr una resolución de direcciones muy eficaz.
72
4. ESTRATEGIAS DE MIGRACIÓN
La transición de IPv4 a IPv6 no es sencilla, por lo cual se debe realizar de forma
gradual ya que la coexistencia entre el protocolo actual y la versión IPV6 es un
hecho, y tarde o temprano se tiene que producir un cambio de direcciones de 32 a
128 bits sin afectar a los servicios que se prestan en la actualidad.
El primer paso hacia la transición es la instalación de equipos y aplicaciones que
tengan capacidad para procesar los paquetes generados por ambos protocolos,
por lo que este proceso debe ir acompañado por un mecanismo que
conjuntamente con los DNS (Domain Name System), transformen los dominios
actuales en direcciones de 128 bits, a su vez se debe diseñar una política
encaminada a guiar a los nuevos usuarios hacia el protocolo IP versión 6.
Hoy en día existen algunos mecanismos que permiten la coexistencia y la
migración progresiva tanto de las redes como de los equipos de usuario. En
general, los mecanismos de transición se clasifican en tres grupos:
Dual Stack (Pila dual)
Túneles
Traducción
73
4.1 DUAL STACK (PILA DUAL)31
Es una de las técnicas más utilizadas en la migración de IPV4 a IPV6, ya que
puede emplearse en diferentes puntos de la red: equipos clientes, servidores y
routers. Como se ilustra en la figura 14.
No habrá comunicación entre IPv4 e IPv6; sin que las aplicaciones soporten
ambos modos. El desafío con dual stack es que todos los equipos de la red han de
contar con la suficiente potencia de proceso y memoria, para gestionar dos pilas
IP diferentes. Además, gestionar dos pilas IP supone un doble gasto en gestión y
soporte, lo que incrementa los costes de TI.
Figura 14: Funcionamiento Pila-Dual
Fuente: http://www.6deploy.org/workshops/20101011_santa_cruz_bolivia/DIA4-1-
Consulintel_IPv6_ES_Mecanismos_Transicion.pdf
31 RFC2893 Mecanismos de transición para hosts y router IPv6 ,Agosto 2000
74
4.2 CONFIGURED TUNNELS32
Esta es una técnica que se define en el RFC 2893, encapsula las comunicaciones
de uno de los protocolos sobre el otro, estableciendo para ello un túnel de
comunicación (similar a una VPN). Para ello necesitaremos contar con dual stack
en cada uno de los puntos del túnel. Los routers involucrados en este método han
de ser capaces de mapear las direcciones del contrario. Este tipo de túneles point
to point necesitan ser configurados manualmente, para el control de las rutas del
túnel, y para reducir el alto nivel de ataques al servicio. En la tabla 8 se muestra
las diferentes técnicas de túneles.
Técnicas de Túneles
Tunnel Broker Tunnel 6to4 Tunnel ISATAP Tunnel 6over4 Tunnel Teredo Dual Stack Transition Mechanism (DSTM)
Tabla 8: Técnicas de Túneles
Fuente: Elaboración del autor
32 RFC 2893 - Mecanismos de transición para hosts y router IPv6. Agosto 2000
75
Se debe tener en cuenta que los túneles IPV6 en IPV4 pueden ser utilizados por el
protocolo de enrutamiento OSPFv3, porque IS-IS se basa en la capa 2, mientras
los túneles IPV6 en IPV4 están totalmente en capa 3. La dificultad de ingeniería de
este método hace que su desarrollo a gran escala sea de una complejidad
extrema, y hará que para la mayoría de las organizaciones, se deba recurrir al
soporte de ingenieros expertos ya sean internos o externos.
4.2.1 Tunnel Broker33
En lugar de configurar manualmente cada extremo del túnel es posible el uso de
scripts ejecutables en su lugar. Esta alternativa "automática" se llama un "Tunnel
Broker" y se presenta en el RFC 3053.
Al igual que los túneles configurados manualmente, el Tunnel Broker es útil donde
un usuario tiene una gran cantidad de dual stack dentro una red IPv4.
La idea básica de un Tunnel Broker es permitir al usuario conectarse a un servidor
web, opcionalmente permite entrar en algunos detalles de autenticación, y recibir
de vuelta un pequeño script para ejecutar y establecer un túnel IPv6 en IPv4 al
servidor de Tunnel Broker.como se ilustra en la figura 15.
El proveedor del servicio del Tunnel Broker debe ofrecer un servidor web
disponible a través de IPv4 o un router de dual-stack capaz de aceptar comandos
33 RFC 3053-Ipv6 Tunnel Broker. Enero 2001
76
automatizados de configuración para crear nuevos túneles a los extremos de
cliente. Es posible que ambas funciones puedan servir desde una sola máquina.
Figura 15: Funcionamiento de Tunnel Broker
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
Un túnel broker se puede implementar de muchas maneras y no está limitado a
túneles IPv6 en IPv4. También pueden ser utilizados los túneles GRE o Capa 2.
El requisito para el servicio es que necesita mantener el seguimiento de los
túneles creados y a quien pertenecen. Lo ideal es que deban tener alguna
autenticación para permitir el acceso al servicio, pero en la práctica la
implementación no se requiere.
77
El servicio de Tunnel Broker es generalmente fácil de usar para el cliente, pero
hay algunas preocupaciones acerca de la implementación de sistemas de
servidores, por ejemplo, en la seguridad de acceso, y en la reasignación de los
túneles donde los clientes dan uso dinámico de direcciones IPv4.
Un Tunnel Broker es una ayuda importante de transición, que permite un fácil
uso de acceder a la red IPv6. Los proveedores de túneles pueden ser
desplegados por sitios locales (universidades, empresas) o por las redes
nacionales. Si no hay ningún Tunnel Broker disponible para un participante
nacional, brokers remotos se puede utilizar, pero reducirá probablemente la
eficiencia de los túneles.
4.2.2 Tunnel 6to434
El mecanismo de transición conocido como Túnel 6to4 [RFC3056] es una forma
automática de permitir la comunicación de router a router por medio del túnel,
facilitando a los dominios aislados en IPv6 comunicarse con otros dominios IPv6
con una configuración mínima. La IANA asignó el prefijo IPv6 2002:: / 16 para
designar un sitio donde participar. Al sitio de IPv6 se le asignará un prefijo de
2002: V4ADDR::/ 48, donde V4ADDR es el rango dirección única en IPv4,
configurada en la interfaz del router de salida apropiada al dominio (vea la Figura
16).
34 RFC 3056 - Conexión de Dominios IPv6 a través de nubes IPv4. Febrero 2001
78
Figura 16: Funcionamiento del Tunnel 6to4
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
Este prefijo tiene exactamente el mismo formato que los prefijos normales / 48 y
por lo tanto permite un dominio IPv6 para utilizarlo como cualquier otro prefijo
válido / 48, en el escenario donde los dominios 6to4 desean comunicarse con
otros dominios 6to4.
Los extremos del túnel son determinados por el valor del prefijo de enrutamiento
global de la dirección IPv6 de destino contenida en el paquete IPv6 que se
transmite e incluye la dirección IPv4. En este escenario, un número arbitrario de
dominios 6to4 se puede comunicar sin necesidad de configurar el túnel, además
los routers 6to4 no necesitan ejecutar ningún protocolo de enrutamiento externo
en IPV6, como sucede en el caso del enrutamiento IPV4 externo que realiza la
tarea.
79
Cuando los dominios 6to4 desean comunicarse con los dominios que no
pertenecen al 6to4, la situación es un poco más compleja. En este caso, la
conectividad entre los dominios se realiza a través de un enrutador de
retransmisión, que es esencialmente un router que tiene al menos una interfaz
6to4 lógica y al menos un interfaz nativo IPv6. A diferencia del escenario anterior,
IPv6 de enrutamiento externo debe ser utilizado. El enrutador de retransmisión
anuncia la 6to4 2002: / con prefijo 16 en el dominio de enrutamiento IPv6 nativo.
Además, el enrutador de retransmisión puede anunciar las rutas IPv6 nativa dentro
de su conexión 6to4.
El mecanismo 6to4 es utilizado generalmente para routers IPv6, ubicado en un
sitio fronterizo con conectividad externa IPv4 para establecer conectividad
automática a Internet IPv6, además otros métodos (ISATAP o la creación de redes
nativas IPv6 si está disponible) se pueden emplear dentro del sitio.
4.2.3 Tunnel ISATAP35
Una alternativa a 6over4 es ISATAP (Intra-Site Protocolo de direccionamiento
automático de túnel). ISATAP también usa el sitio infraestructura IPv4 como un
vínculo virtual, pero no utiliza IPv4 multicast, por lo que el enlace es NBMA (non-
broadcast multiple Access). Véase en la figura 17.
ISATAP, como 6over4, crea un identificador de interfaz basado en la dirección
IPv4. ISATAP es compatible con una configuración automática o manual de
direcciones, pero la dirección IPv4 de la interfaz se integrará como los últimos 32
35 RFC 4214 - Intra Site automático túnel abordar Protocol (ISATAP). Octubre 2005
80
bits de las direcciones IPv6. Al igual que 6over4, la dirección IPv4 sólo necesita
ser única en la red en la que el servicio se despliega.
Figura 17: Funcionamiento de Tunnel ISATAP
Fuente: http://technet.microsoft.com/en-us/library/bb727021.aspx
Por lo general, multicast se utiliza para las operaciones de descubrimiento de
vecinos, resolución de la dirección y enrutamiento de direcciones. Desde la
dirección IPv4 se constituye la dirección IPv6 y la resolución de la dirección es
eficiente. Para trabajar solicitudes en el router anfitrión se debe haber aprendido
las direcciones IPv4 de enrutadores ISATAP(a través de DHCP, DNS, etc), luego
se omitirán respuestas ante la solicitud de un host..
ISATAP se ha implementado en algunas plataformas como Windows XP y el IOS,
aunque se ha retirado de USAGI Linux, los autores consideran que si bien tienen
81
una aplicabilidad en algunos sitios, en otros se presenta una falencia debido a que
no cumple con las especificaciones requeridas para el aplicativo.
4.2.4 Tunnel 6over436.
6over4 se define en el RFC 2529. Interconecta hosts IPv6 aislados en un sitio a
través de IPv6 en IPv4 sin encapsulación explícita de túneles. Utiliza las
direcciones IPv4 como identificadores de interfaz y crea un enlace virtual usando
un grupo de multidifusión IPv4 con ámbito de organización local. El método 6over4
ha caído en desuso debido a una serie de razones, incluyendo la falta general de
IPv4 multicast en las redes de ISP.
Ha habido un pequeño número de implementaciones, incluyendo los de 3Com y
Cisco, pero prácticamente no son adoptados. Por tanto, no se considera 6over4 en
detalle, pues el método es obsoleto y por lo tanto no sería recomendado su uso.
4.2.5 Tunnel Teredo37
El mecanismo de transición Teredo, es una forma de túnel automático destinado a
proporcionar conectividad IPv6 con direcciones IPv4 que se encuentran detrás de
un NAT [RFC1613]. Se trata de un mecanismo de túnel automático que
proporciona conectividad IPv6, cuando un host de dual-stack se localiza detrás de
un NAT, para encapsular paquetes IPv6 en IPv4 el usuario se basa en el Protocolo
de Datagramas de Mensajes (UDP).
36 RFC 2529 - Transmisión de paquetes IPv6 sobre IPv4. Marzo 1999
37 RFC 4380 - Teredo: Tunneling IPv6 sobre UDP. Febrero 2006
82
Como se ilustra en la Figura 18, el servicio Teredo emplea dos componentes, un
servidor Teredo y un relay Teredo, con el fin de proporcionar conectividad IPv6
Teredo para clientes ubicados detrás de un NAT. A diferencia de otros
mecanismos de túneles, Teredo encapsula los paquetes IPv6 en UDP (en lugar de
directamente sobre IPv4). El puerto UDP (3544) es utilizado por el servidor
Teredo para escuchar las peticiones de los clientes Teredo.
Las direcciones Teredo tienen la siguiente estructura:
32 bits 32 bits 16 bits 16 bits 32 bits
Teredo Prefix
IPV4 Address of Teredo
Server
Flags Mapped Client UDP Port
Mapped Client IPv4 Address
Tabla 9: Estructura de las direcciones Teredo
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
Tanto el "Mapped Client UDP Port" y el "Mapped Client IPV4 Address" son
confusos, cada bit de la dirección y el número de puerto están de modo inverso,
pues las reglas de las direcciones IPv6 especifican que todas las direcciones
unicast e identificadores de interfaz requieren ser de 64 bits, excepto aquellos que
comienzan con el valor binario 000. Por lo tanto el campo flags ha de ser
codificado para cumplir con este requisito.
El servidor Teredo escucha las peticiones de los clientes Teredo, respondiendo
con una dirección IPv6 para su uso. El servidor Teredo reenvía los paquetes IPv4-
IPv6 encapsulados enviados desde el Teredo client o el Teredo relay. El servidor
también envía paquetes IPv6 recibidos desde el Teredo relay, que están
destinados para un cliente Teredo, a la correspondiente dirección IPv4 y el puerto
83
UDP del cliente. El relay Teredo actúa como un router IPv6 y reenvía los paquetes
destinados a los clientes del servidor, además permite la accesibilidad del servicio
Teredo a la red IPv6.
Figura 18: Funcionamiento Tunnel Teredo
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
Al analizar el formato de dirección Teredo IPv6 se evidencia que la especificación
de Teredo hace poco uso del espacio de direcciones IPv6 con respecto a la
asignación de los prefijos de enrutamiento. Es por esto que el relay Teredo debe
anunciar la accesibilidad del servicio para el resto de la red IPv6. El prefijo de 32
bits es común para todos los servidores Teredo, por lo que el relay debe anunciar
prefijos IPv6 que consten del prefijo Teredo más la dirección IPv4 del servidor
84
Teredo. Esto significa que los prefijos de enrutamiento para los diferentes
servidores Teredo se deben asignar en la red IPv6. En teoría, esto podría
significar la asignación de un prefijo de enrutamiento en la red IPv6 para cada sitio
donde se utiliza NAT en IPv4.
Como tal, el servicio Teredo sólo debe utilizarse como un "último recurso" donde la
conectividad directa IPv6 o la unión de enrutar 6to4 con la NAT no es posible.
Además, el método Teredo es muy complejo y no puede garantizar el trabajo en
todos los NATs. Debido a la variación en la implementación de NAT.
4.2.6 Dual Stack Transition Mechanism (DSTM)
DSTM (mecanismo de transición de doble pila) es una solución de túnel para las
redes IPv6. El tráfico IPV4 es tunelizado sobre el dominio IPv6 hasta que alcance
una puerta de entrada IPv6/IPv4, que está a cargo del paquete de encapsulación,
desencapsulación y del transporte entre los dominios IPV6 e IPV4. La solución
propuesta por DSTM es transparente a cualquier tipo de aplicación de IPv4 y
permite el uso de la capa 3 de seguridad.
Por lo general, un esquema de túnel necesita de una dirección IPv4 para cada
host que se desee conectar a internet IPV4. DSTM reduce esta restricción
asignando dinámicamente direcciones sólo por la duración de la comunicación,
haciendo esto posible a través de varios host que compartan la misma dirección
en una larga escala de tiempo.
85
DSTM puede llevarse a cabo si una infraestructura de red sólo es compatible con
IPv6, pero algunos de los nodos de la red tienen la capacidad de dual-stack.
DSTM consiste en tres componentes:
Un servidor DSTM.
Una puerta de entrada DSTM o TEP (punto final del túnel).
Un host dual-stack (llamado un "cliente DSTM") que desee comunicarse
con IPv4.
Para mantener la simplicidad, hemos decidido presentar el servidor y la puerta de
entrada como un equipo diferente, pero en las implementaciones reales, estas dos
funcionalidades están localizadas en el mismo equipo.
Figura 19: Funcionamiento DSTM
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p.
86
Siempre y cuando las comunicaciones puedan tener lugar en IPv6 nativa, ninguna
de las capacidades de DSTM se requiere. Esto se aplica a protocolos como HTTP
o SMTP, donde el uso de ALG (nivel de aplicación Puertas de enlace) es
preferible. Cuando un nodo DSTM detecta la necesidad de una dirección IPv4 por
consulta de DNS que resulta de una dirección de destino IPV4 o una aplicación
que genera un socket IPV4, el proceso DSTM se pone en marcha.
Cuando el primer paquete IPv4 es enviado, el cliente pide al servidor DSTM
obtener una dirección (en el paso 1 Figura 19).Estos protocolos (DHCPv6, TSP,
RPC) han sido propuestos para realizar eficientemente esta tarea.
Después de una petición de dirección, el servidor solicita a la puerta de entrada
DSTM agregar un punto final del túnel (TEP) para la solicitud DSTM del cliente. El
servidor es el encargado de controlar la asignación de direcciones IPv4/IPv6 para
realizar un mapa en la puerta de entrada DSTM. Las versiones iniciales de DSTM
consideran que la entrada sería construir su tabla de mapa IPv6/IPv4 dinámica
mediante la observación de cabeceras de los paquetes, pero este método ya está
obsoleto, debido a problemas de seguridad.
Si el punto final para el nuevo túnel se ha creado con éxito, siguiendo el mensaje
de respuesta de la puerta de enlace, el servidor DSTM responde al host con la
siguiente información (paso 2):
La dirección IPV4 asignada
Periodo en que fue asignada la dirección.
La dirección IPv4 e IPV6 del TEP
87
Esta información es utilizada por el cliente para configurar un túnel IPv4-sobre-
IPv6 hacia el DSTM puerta de enlace (paso 3). En este punto, el cliente DSTM
tiene conectividad IPv4 y obtiene una dirección global IPv4, que será capaz de
conectarse a cualquier host IPV4 externo.
En DSTM, el período de asignación se puede configurar con base a la
disponibilidad de la dirección. Los clientes necesitan solicitar la renovación antes
de que la asignación del tiempo expire. Dependiendo de la política local y el
comportamiento del cliente, el servidor DSTM puede aceptar o rechazar la
ampliación de la asignación. En funcionamiento normal, las solicitudes de
renovación de la asignación se envían periódicamente hasta que la dirección ya
no es necesaria por el cliente. Siempre y cuando la asignación de direcciones se
extienda, el servidor DSTM no está obligado a actualizar mapeo IPv4/IPv6 de la
tabla en la puerta de enlace. Sin embargo, cuando expira la asignación, el
gateway debe ser informado con el fin de actualizar sus tablas, y para permitir a
otros clientes reutilizar el TEP para la liberación de direcciones IPv4.
La puerta de entrada DSTM está a cargo del reenvío de paquetes entre el dominio
IPV6 y redes IPv4. Se lleva a cabo la encapsulación o desencapsulación de
paquetes usando una tabla de mapeo IPV4 e IPV6. Para éxito la comunicación
bidireccional, es muy importante permitir el reenvío de IPv4 en la entrada y para
asegurarse de que, para cualquier paquete IPv4 que vienen del exterior, el camino
hacia el cliente DSTM apunta a la TEP.
DSTM permite a los nodos de doble pila obtener una dirección IPv4 y ofrecer una
ruta por defecto (a través de un túnel IPv4 en IPv6) a una pasarela IPv4. Cualquier
aplicación IPv4 sólo se puede ejecutar a través de una red IPv6, sólo si este
esquema es utilizado y, si DSTM está configurado para asignar direcciones IPv4
mundiales.
88
4.3 MÉTODOS DE TRASLACIÓN
Los métodos de traducción son los encargan de traducir las cabeceras de
datagramas IPV6 a IPV4 y viceversa. La tecnología de traducción es utilizada
cuando un único host IPV6 necesita comunicarse con otro o viceversa. Este
método de migración es la única solución en IPV6 que permite eliminar
definitivamente el direccionamiento IPV4 de los nodos de red.
Las técnicas de traducción de protocolos se describen en los RFCs 2765 y 2766.
Mecanismos de Traslación de protocolos
Network Address Translation-Protocol
Translation (NAT-PT)(RFC 2766)
Transport Relay Translator (TCP-UDP Relay)(RFC
3142)
Bump-in-the-Stack (BIS)(RFC 2767)
El Bump en el API (BIA) [RFC3338]
SOCK-BasedGateway (RFC 3089)
Tabla 10: Mecanismos de traslación de protocolos
Fuente: Elaboración del autor
89
4.3.1 SIIT, NAT-PT and NAPT-PT38
Figura 20: Funcionamiento Translation (NAT-PT)
Fuente: http://www.ipv6-
tf.com.pt/documentos/geral/cisco/ipv6_NatPTforIPv6_Mai2003.pdf
Network Address Translation with Protocol Translation (NAT-PT), se define en el
RFC 2766, como un servicio que se puede utilizar para traducir los datos enviados
entre nodos con direcciones IP heterogéneas. NAT-PT traduce un datagrama
IPv4, en la medida de lo posible, como un equivalente semántico de datagrama
IPv6, o viceversa. Para que este servicio funcione, tiene que estar en el punto de
interconexión entre la red IPv4 e IPv6. (Véase en la figura 20).
Al igual que la existencia del NAT en IPV4 se traducen por lo general direcciones
IPv4 privadas y direcciones globalmente enrutables. El NAT hace parte del NAT-
PT que se traduce desde una Dirección IPv4 a una dirección IPv6, o viceversa, así
como de una dirección IPv4 privada a una dirección global de IPv6. La parte de PT
38 RFC 2766 – NAT-PT. Febrero 2000
90
de la NAT-PT se encarga de la interpretación y la traducción de la equivalente
semántica de encabezados IP, ya sea de IPv4 a IPv6 o IPv6 a IPv4. Al igual que
NAT, NAT-PT también utiliza un conjunto de direcciones, que se asigna
dinámicamente a los datagramas traducidos.
El RFC2766 especifica un servicio llamado Network Address Port Translation -
Traducción de paquetes (NAPT-PT). Este servicio permite que los nodos IPv6 se
comuniquen de forma transparente con una sola dirección IPv4. NAPT-PT
mantiene un conjunto de números de puerto, que se asigna dinámicamente a los
sockets que se encuentra en el lado del receptor del nodo NAPT-PT.
Para el IETF NAT-PT es inaplicable actualmente, pero puede ser modificado a un
formato más aceptable. Debe ser visto como un método de transición de último
recurso.
4.3.2 Transport Relay Translator (TRT)39
El traductor de relay de transporte (TRT) [RFC3142] permite sólo hots IPv6 para
intercambio de tráfico (TCP o UDP) con hots IPv4. Ninguna modificación de los
host es necesaria, el sistema TRT puede ser muy fácil de instalar en las redes con
capacidades de IPv6.
Un traductor de relay de transporte que se ejecuta en un nodo de dual-stack
puede utilizar un protocolo sólo en la comunicación con el cliente o en aplicación
del servidor. En el ajuste del relay es capaz de traducir en la capa de transporte
todos los datos enviados entre el cliente y aplicación de servidor. Para TCP tal
39RFC3142-Transport Relay Translator.Junio 2001
91
traducción incluye volver a calcular la suma de comprobación, manteniendo la
información necesaria sobre el estado que está conectado a la toma de socket de
cliente servidor y eliminar este estado cuando el cliente termina su comunicación.
Con la suma de comprobación UDP es obligatorio cuando se utiliza IPv6, pero no
cuando se utiliza IPv4. UDP es un protocolo no orientado a conexión y, en teoría,
es imposible para un relay conocer cuales datagramas pertenecen a la misma
sesión .La implementación del relevo UDP típicamente asumirá que un datagrama
UDP que sigue otro con el mismo recurso y destino dentro de un mismo intervalo
de tiempo pertenece a la misma sesión.
El sistema TRT puede trabajar con la mayoría de las aplicaciones comunes de
Internet: HTTP, SMTP, SSH, etc. La operación de mecanismo de transición es
relativamente simple: El host IPv6 utiliza un DNS-ALG como su servidor de
nombres para resolver sus consultas DNS. El host IPv6, cuando pregunta a su
servidor de nombre por la dirección IPV6 (registro AAAA) de un solo host IPv4,
recibirá una dirección IPV6 (registro AAAA) de la DNS-ALG, que fue construido
especialmente de la dirección IPv4 (Un registro A), en lugar de un mensaje de
error con la respuesta que ninguna dirección IPv6 puede encontrar
correspondiente a la consulta. Las direcciones de construcción consisten en un
prefijo de red especial asociado con un relay de transporte y un ID del host (los 64
bits inferiores) que incorpora la dirección IPv4 del host remoto.
La red está configurada de tal manera que los paquetes destinados a direcciones
con el prefijo de red especiales sean enrutados al nodo remoto TRT. El TRT
intercepta sesiones de transporte y actúa a través del nodo como punto final de
destino de una sesión de IPv6 y actúa hacia el nodo de servidor como el recurso
para una sesión de IPv4, copiando todos los datos que recibe de cada
sesión(Véase en la figura 21).
92
Figura 21: Funcionamiento Transport Relay Translator
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
Existen ventajas y desventajas en el empleo de los mecanismos de TRT. Las
ventajas incluyen:
No hay ningún problema con los paquetes ICMP (Protocolo de Mensajes de
Control de Internet). Si cualquier error ocurre en cualquier parte de las
conexiones TRT, el paquete ICMP/ICMPv6 es enviado de vuelta al servidor
de retransmisión de TRT, donde el error pueden ser manejado con cuidado
o reportado hacia el otro extremo de la conexión.
No es necesario modificar la pila IPv6 del host inicial, ni la aplicación para el
soporte de su reinstalación.
Es relativamente fácil de configurar.
Puede ser suficiente con tener sólo un servidor de transmisión de TRT para
todo el sitio, y este router debe tener una sola dirección global IPV4.
93
Las desventajas Incluyen:
Puede haber problemas con las aplicaciones que utilizan direcciones IP
integradas (por ejemplo, FTP, H.323). La TRT relay tiene que ser lo
suficientemente inteligente como para mirar dentro de los paquetes si dicha
aplicación necesita soporte. En este caso, el servidor de transmisión de
TRT se convierte en una especie de aplicación proxy.
Es aprobado sólo para tráfico unicast TCP / IP, sin embargo, es
teóricamente posible llevar a cabo la implementación con soporte multicast.
El servidor de transmisión de TRT puede generar un problema de seguridad
importante, ya que puede ser utilizado como un salto intermedio para llegar
a los servidores IPv4. La comunidad que se beneficia de un servidor de
trasmisión TRT tiene que ser cuidadosamente controlada por el filtrado de
paquetes o las listas de control de acceso. Para reducir el problema de
direcciones de sitios locales se podrían utilizar entradas de paquetes IPV6.
TRT requiere una configuración especial del servidor DNS para funcionar.
Debido a la naturaleza del servicio de relay de TCP / UDP, no se
recomienda el uso de TRT para protocolos que utilizan la autenticación
basada en dirección IP de origen (por ejemplo, rsh / rlogin).
4.3.3 Bump in the Stack40
El Bump in the stack (BIS), se define en el [RFC2767] .Es un mecanismo de
traducción similar a tomar el enfoque de NAT-PT con SIIT. El BIS es una interfaz
40 RFC2767.Bump in the Stack Febrero 2000
94
de traducción entre las aplicaciones IPV4 y las redes situadas por debajo de IPV6
(es decir, el controlador de interfaz de red). El diseño de la stack se basa en una
pila dual-stack, con la adición de tres módulos, un traductor, un nombre de la
extensión de la resolución y la dirección de un mapper, como se muestra en la
figura 22.
Figura 22: The BIS Protocol Stack
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. pág. 442.
El traductor reescribe la salida de las cabeceras IPv4 a IPv6 e ingresan cabeceras
IPv6 a IPv4 si aplica. Se utiliza el algoritmo de traducción de cabecera definidos
en SIIT. El nombre de extensión de resolución actúa como el de DNS-ALG en el
95
mecanismo de NAT-PT. Se realizan consultas de DSN IPv4 y se crean otras
consultas que resuelvan los registros IPV4 e IPV6, enviando de regreso el registro
IPV4 a la aplicación de solicitud IPV4, si sólo los registros IPV6 son devueltos, el
solicitante pide al mapper de direcciones para asignar una dirección IPv4
correspondiente a la dirección IPv6. La dirección mapper mantiene un grupo de
direcciones IPv4 y las asociaciones entre las direcciones IPv4 e IPv6. También se
asigna una dirección cuando el traductor recibe un paquete de la red IPv6 para
que no muestre la dirección de origen. Debido a que las direcciones IPv4 no son
en realidad transmitidas en la red, por esto no tienen que ser únicas globalmente,
pero un conjunto de direcciones privadas si pueden ser usadas.
El mecanismo de BIS puede ser útil durante las etapas iniciales de la transición de
IPv4 a IPV6 cuando las aplicaciones IPv4 permanecen sin modificarse dentro de
los dominios IPV6, sin embargo, el BIS se limita en sus capacidades de traducción
y es por esto que no es muy utilizado. Se permite la comunicación de host IPv4 al
IPv6 pero no viceversa. No se envía o recibe ningún paquete IPV4 para la red, por
lo tanto una aplicación IPv4 intenta la comunicación con otra aplicación IPV4
utilizando BIS, se producirá un error si no existen mecanismos de traducción
adicionales en algún lugar de la ruta de comunicación. Al igual que con NAT-PT,
SIIT y BPI no van a funcionar las comunicaciones multicast, ni aplicaciones que
incorporan las direcciones IP en sus cargas. Una ALG (Application Layer
Gateway) es necesaria para cualquier aplicación que tiene este comportamiento.
96
4.3.4 Bump in the API41
El Bump in the API (BIA) [RFC3338] es un mecanismo de traducción similar al
BIS, sin embargo en lugar de traducir las cabeceras IPv4 e IPv6; BIA inserta un
traductor API entre el socket API y los módulos TCP / IP de la pila host.
Figura 23: The BIA Protocol Stack
Fuente: European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. Pág. 442
Por lo tanto, las funciones IPv4 socket API se traducen en las funciones socket
API IPV6 y viceversa. De esta manera, la traducción IPv4/IPv6 puede lograrse sin
la sobrecarga de traducir cada paquete de cabecera. Al igual que BIS, BIA se basa
en la adición de tres módulos: El sistema de resolución de nombres de archivo, la
41 RFC3338 Bump in the API Octubre 2002
97
función asignador y direcciones de mapper. Tanto la extensión de resolución de
nombres y los módulos de mapeo de direcciones funcionan exactamente de la
misma forma que los módulos correspondientes en el BIS. La función del mapper
es situar las llamadas de IPV4 socket a las llamadas IPv6 socket y viceversa.
Mapper hace esto interceptando la función de llamadas IPV4 socket API y
pidiendo las correspondientes funciones de llamadas IPV6 socket API en su lugar.
Esta función de llamadas socket IPv6 se usan para comunicarse con el par IPV6 y
son transparentes para la aplicación IPv4 que invocó la función de llamadas
original IPv4 socket.
Por lo tanto, las funciones IPv4 socket API se traducen en las funciones socket
API IPV6 y viceversa. De esta manera, la traducción IPv4/IPv6 puede lograrse sin
la sobrecarga de traducir cada paquete de cabecera. Al igual que BIS, BIA se basa
en la adición de tres módulos: el sistema de resolución de nombre de archivo, la
función asignador y direcciones de mapper. Tanto la extensión de resolución de
nombres y los módulos de mapeo de direcciones funcionan exactamente de la
misma forma que los módulos correspondientes en el BIS. La función mapper es
trazar las llamadas de IPV4 socket a las llamadas IPv6 socket y viceversa.
Mapper hace esto interceptando la función de llamadas IPV4 socket API y
pidiendo correspondientes funciones de llamadas IPV6 socket API en su lugar.
Esta función de llamadas socket IPv6 se usan para comunicarse con el par IPV6 y
son transparentes para la aplicación IPv4 que invocó la función de llamadas
original IPv4 socket.
El mecanismo de BIA está diseñado para sistemas que tienen una pila IPv6, pero
que contienen aplicaciones que no ha sido actualizadas a IPv6. Por lo tanto, BIA
puede ser útil en las primeras etapas de la transición, cuando hay muchas
aplicaciones IPV4 sin modificar dentro de los dominios IPV6. BIA permite la
comunicación de host IPv4 a IPv6, pero no especifica el caso inverso. Sin
98
embargo, podría ser fácilmente extendido para atender la comunicación de host de
IPv6 a IPv4 (esto también es aplicable a BIS). La ventaja que tiene BIA sobre BIS
es que es independiente del controlador de interfaz de red y no introduce el
encabezado de cada paquete de traducción. Sin embargo, BIA presenta
limitaciones similares a las del BIS. No tiene soporte de comunicación multicast sin
alguna funcionalidad adicional a la del módulo mapper y no se emplea para
aplicaciones que incorporan direcciones IP en sus cargas. El método BIA es, al
igual que el método de BIS, no muy utilizado.
4.3.5 SOCK42
SOCK [RFC3089] es otro ejemplo de un relay de transporte, pero por lo general es
conocido como un proxy "protocolo para entornos cliente / servidor”. SOCK es una
Puerta de Enlace (Gateway) entre dos redes que permite que ciertas aplicaciones
se comuniquen con sus contrapartes en la otra red, en este caso desde una red
IPv4 a una IPv6 o viceversa.
Cuando un cliente quiere conectarse a un servidor de aplicaciones por primera
vez, establece una conexión a un servidor proxy pre-configurado utilizando un
protocolo de proxy especial. El cliente solicita al proxy acerca de la dirección IP y
el número del puerto del servidor de aplicaciones con que se desean comunicar.
El servidor proxy actualmente es responsable de establecer una conexión con el
servidor de aplicaciones. Tan pronto como esta conexión es establecida y se
ejecuta el paquete de relay del proxy entre el cliente y el servidor de aplicaciones
se oculta la conexión actual.
42 RFC3089 SOCK Abril 2001
99
5. CONFIGURACIÓN DE ESTRATEGIAS DE MIGRACIÓN43
5.1 CONFIGURACIÓN: MÉTODO DE TUNNELS
“El método que más se recomienda es el uso de túneles, en especial para la
interconexión de redes pequeñas con redes grandes. Los tipos de túneles que
generalmente se deben usar son: túneles estáticos, túneles 6to4 y túneles
ISATAP. ”44
5.1.1 Túnel manual Cisco IOS
La configuración manual de un túnel IPV6 en IPV4 en una plataforma de cisco
IOS: se crea la interfaz con un simple cambio de configuración al modo de escribir.
En el modo de configuración se puede crear la interfaz.
Nota: el túnel puede ser cualquier número entre 0 y 65.000. Para configurar la
interfaz con una dirección IPV6 se debe tener en cuenta dos posibilidades
43 European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin Dunmore, September 2005.
Páginas 442. 44
David Núñez. Capítulo 3.2009, paginas 16.
100
O
La primera posibilidad se traducirá en la interfaz que se configura con la dirección
exacta que se tiene especificada. Teniendo en cuenta que la longitud de la subred
se puede establecer con 128 bits. Utilizando la segunda posibilidad, seria
especificando un prefijo que puede ser de hasta 64 bits de longitud. La dirección
de la interfaz de IPv6 será configurado con incluye (por ejemplo) y la dirección
MAC de los equipos en el identificador de interfaz se especifica en la norma EUI-
64.
La fuente del túnel se puede especificar con el nombre de la fuente de IPv4 o
directamente indicando la dirección IPv4 del extremo del túnel local, por ejemplo:
o
El destino del Túnel es creado por:
101
Finalmente hay que configurar el modo de túnel para “IPV6IP” para especificar el
encapsulamiento y decapsulamiento correcto.
Con la “ipv6 route” es un comando que puede configurar rutas de las interfaces de
túnel al igual que con cualquier interfaz.
5.1.2 6to4
5.1.2.1 Cisco IOS (as Client and Relay)
Un router Cisco ejecutando una versión de IOS que incluye soporte 6to4 puede
convertirse en un cliente de 6to4, si sólo tiene conectividad IPv4 o, si el router ya
tiene conectividad IPv6 global, convertido en un 6to4 relay.
5.1.2.1.1 Configuración del cliente:
Para configurar un router Cisco como cliente 6to4 es bastante fácil y se puede
realizar mediante la creación de un túnel de la siguiente manera.
102
Es obligatorio establecer la siguiente ruta.
5.1.2.1.2 Configuración como un relay 6to4:
Si el túnel y el router se configura como se ha descrito anteriormente, el cual
también tiene conectividad exterior con el resto de la Internet IPv6, este router de
forma automática funciona como un relé 6to4 y puede por lo tanto proporcionar
conectividad con el exterior a todos los hosts conectados a él por 6to4.
5.1.3 ISATAP
Para usar ISATAP dentro de un sitio, será necesario uno o más hosts IPv6 que
apoyen ISATAP y también un router de dual stack que lo refuercen. Diferentes
implementaciones del mecanismo se deben acoplar para que de esta manera las
plataformas host y router se puedan mezclar según se requiera.
103
5.1.3.1 Cisco IOS Platform (As Router/Server).
Para la configuración de un router Cisco como servidor ISATAP, se debe definir
una interfaz de túnel de la siguiente manera:
Si un cliente de ISATAP es creado para conocer acerca del router Cisco, será
capaz de configurar automáticamente su interfaz con el prefijo anterior.
104
6. ETAPAS DE PROCESO DE MIGRACIÓN PARA LAS PYMES.
La tabla 11 resume todos los elementos, capas y aspectos que deben ser tenidos
en consideración por los profesionales de TI para las Pymes, cuando se planea
hacer la implementación de IPv6.
Las Pymes en general deben pensar en IPv6 como un proceso cíclico, que alinee
todos los aspectos ligados a la infraestructura, procesos y servicios existentes:
Tabla 11: Etapas de proceso de migración para las Pymes
Fuente: http://staging.la.logicalis.com/pdf/IPv6.pdf
105
6.1 PROYECTO DE TRANSICIÓN45
Al momento de realizar un plan de transición hacia la adopción de IPv6 se debe
pensar en un proyecto, el cual, debe 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 cada Pyme, será
entonces necesidad 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).
6.1.1 Elementos del modelo de proyecto de transición.
Al iniciar con el modelo de proyecto de transición de IPV4 a IPV6, se definen un
conjunto de elementos que deberían ser identificados y que conforman el alcance
del plan de proyecto, pues es de gran ayuda para aquellas organizaciones que se
encuentren en la fase temprana de inicialización del proceso de migración.
6.1.1.1 Planificación y definición de la estrategia. Incluida la necesidad de inversión.
Las empresas deben adaptar e implementar tecnologías que cuenten con
características que le permitan la migración de IPV4 a IPV6 para obtener el
máximo beneficio en el funcionamiento de la red.
45 César Benítez Jiménez .Transición de IPv4 a IPv6 bajo un enfoque de la gestión de las
Tecnologías de Información. Agosto de 2009.22 p. Fuente:http://www.tlalpan.uvmnet.edu/oiid/download/Transici%C3%B3n%20sistema%20Gesti%C3%B3n_04_PO-ISC_PIT_E.pdf
106
Dentro de la planificación y definición de la estrategia se incluyen aspectos
importantes como plantear una red que se ajuste a las exigencias de
rendimiento, seguridad y escalabilidad de la pyme. Estas características hacen
referencia a las necesidades puntuales del estado de la red en toda su
arquitectura.
Para los elementos que conforman el proyecto de transición a IPV6, es necesario
que cada uno de ellos contemple las variables procedentes de equipos nuevos de
cómputo, telecomunicación, y administración de riesgos que reflejen los estados
financieros que se deben tener como parte del plan del proyecto de transición.
6.1.1.2 ¿Cómo está su red?, ¿Cuáles son sus servicios?, ¿Cuál es la mejor forma de migración?
Se define un conjunto de elementos que deben ser identificados y que permiten
asimilar el alcance del plan de proyecto, pues es de gran ayuda para la Pyme
contar con una información veraz, que le ayudará en la implantación de nuevas
tecnologías.
6.1.1.2.1 Redes de área local
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 se ha 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 (switch), 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
107
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.
6.1.1.2.2 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 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
108
necesario integrar con prioridad los equipos de esta categoría, previamente al
resto de los elementos del proyecto de transición.
6.1.1.2.3 Servicios multimedia (voz, video, aplicaciones de tiempo real).
En este contexto, debemos considerar que en los años recientes, 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 representa 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 generar una implantación acelerada, serían 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, íntegro 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.
109
6.1.1.2.4 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 ésto se hace necesario
realizar un inventario de todas las aplicaciones. Adicionalmente, en aquellos casos
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
adecuadamente.
6.1.1.2.5 Clientes/Usuarios finales
Un elemento que podría ser asumido como fácil de implementar son los usuarios
finales, que comprenden para una organización un componente 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.
110
6.1.1.2.6 Aplicaciones integrales de administración
En aquellas circunstancias donde la Pyme 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.
6.1.1.2.7 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 contexto, debe integrarse 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.
111
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, éstas 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.
6.1.1.3 Defina los equipos, servicios, soporte y capacitación.
Es de gran importancia para el personal encargado de la adquisición de nuevas
tecnologías, revisar el plan de trabajo IPV6 de cada proveedor o fabricante, y el
plazo establecido para dar cumplimiento al nivel de preparación en los servicios y
el desempeño de los equipos de comunicación que le permiten a la Pyme llevar la
migración de una forma más segura.
Es de vital importancia revisar la línea de productos del fabricante, debido a que
puede estar ofreciendo servicios que no cumplen con las especificaciones técnicas
y certificaciones que necesita IPV6 para su funcionamiento. Incrementando en las
Pymes los gastos de migración al adquirir tecnología obsoleta que dará solución
al problema por un corto periodo de tiempo; además las empresas que acceden a
estos servicios deben contar con personal que facilite la administración eficiente
de los equipos.
6.1.1.4 Integre sin interrupciones o vulnerabilidades. Defina paso por paso.
Es conveniente identificar las soluciones que se puedan necesitar y que faciliten
la transición sin necesidad de recurrir a actualizaciones costosas y de alto riesgo
que requieran una sustitución completa de toda la infraestructura.
112
Las pymes deben contar con un plan de contingencia que les permita mantener la
estabilidad en la prestación de los servicios al momento de reestructurar los
equipos, evitando que se encuentre en un estado de vulnerabilidad.
6.1.1.5 Gerencia, resuelva. Repare. Reemplace, siempre manteniendo la red estable.
Para llevar a cabo exitosamente la transformación de la migración de IPV4 a IPV6,
se debe fragmentar el proceso para que no genere alteraciones que afecten la
prestación del servicio. La gerencia consiste básicamente en asumir el liderazgo
de una organización, unificar criterios y trabajar conjuntamente para la
consecución de objetivos élites que le permitan obtener el crecimiento
corporativo.
Para asumir una posición crítica frente a una problemática que se presenta al
interior de la pyme, se analizan las causas que la conciben y las soluciones que
pueden representar mayor favorabilidad para la organización. Éstas deben estar
fundamentadas en los acontecimientos que ameriten decisiones provisionales
(reparaciones) o drásticas (reemplazo).
6.1.1.6 Adapte la red y los servicios de acuerdo a los requisitos de la Pyme.
Las pymes acceden a nuevas tecnologías para mejorar la competitividad y tener
los servicios oportunamente al generar un impacto positivo al interior de la
organización. También acopla la red de acuerdo a sus exigencias, teniendo en
cuenta la tecnología disponible y la capacidad de adquirir un paquete que le
proporcione bienestar, al mismo tiempo que le permite hacer un uso racional de
sus recursos.
113
CONCLUSIONES
La mayoría de las redes en las Pymes de Colombia, durante el proceso de
migración del protocolo de Internet de IPV4 a IPV6 estará acompañada por el
método de transición Dual Stack por un periodo de largo tiempo, pues es una de
las estrategias que maneja una mayor simplicidad al momento de la adaptación de
la nueva tecnología y permite estabilizar el funcionamiento de la red.
Las direcciones IP que se manejan en la versión 4, se encuentran conformadas
por 32 bits. Para IPV6 las direcciones están compuestas por 128 bits, permitiendo
soportar más niveles de direccionamiento jerárquico que permiten al internet
seguir creciendo, un mayor número de nodos direccionables y la simplificación de
autoconfiguración de las direcciones. Además ayuda a mejorar la calidad de
servicio,el manejo de la seguridad, ya que esta característica es nativa dentro del
protocolo.
El protocolo de Internet versión 6 posee compatibilidad con su anterior versión
IPV4 de 32 bits, lo que le permite coexistir en la misma red. Las implementaciones
de este nuevo protocolo empiezan a estar disponibles, y gracias a su
compatibilidad permiten a los administradores de redes y directores de sistemas ir
realizando las mejoras necesarias en sus equipos de forma temporal, teniendo en
cuenta sus posibilidades y sin importar el tiempo empleado.
Con IPv6 se tiene mayor velocidad en el procesamiento de paquetes en los
routers dado que éstos no realizan fragmentación a cada salto, sólo los nodos de
114
origen son los encargados de realizar fragmentación, por tanto se elimina el
tiempo que tomaba este proceso con IPv4 en cada salto.
IPv6 permite manejar múltiples direcciones por interfaz de dispositivo haciendo la
ruta simple y eficiente. En el caso de Ipv4, las direcciones tienen muy poca o
ninguna conexión con los caminos de enrutamiento, por lo tanto los enrutadores
deben mantener enormes tablas de caminos de enrutamiento, mientras que en
Ipv6 los enrutadores mantienen pequeñas tablas de prefijos que permiten que la
fuente envíe los paquetes al destino correcto.
115
BIBLIOGRAFÍA
6SOS.Glosario IPV6: Eduardo Jacob Taquet, Alex Muñoz Mateos, Fidel
Liberal Malaina.2004.pag 38.
Fuente: http://www.6sos.org/documentos/glosario-IPv6-v1-2.pdf
Belén Aldecoa Sánchez del Río Luis Alberto Ramón Surutusa. Redes de
Banda Ancha IPV6.pag 53.
Fuente: http://es.scribd.com/doc/51187582/6/Direcciones-Unicast
César Benítez Jiménez .Transición de IPv4 a IPv6 bajo un enfoque de la
gestión de las Tecnologías de Información. Agosto de 2009.22 p.
Fuente:http://www.tlalpan.uvmnet.edu/oiid/download/Transici%C3%B3n%20
sistema%20Gesti%C3%B3n_04_PO-ISC_PIT_E.pdf
Darwing Lamarck Santono Yunes.IPV6:Nueva Generación Protocolo de
Internet.2004.pag 172
Fuente: http://www.lac.ipv6tf.org/docs/tutoriales/IPv6-LACTF.pdf
David Núñez. Capítulo 3.2009, paginas 16.
European IST. 6 Net: An IPV6 Deployment Guide. Europa: Martin
Dunmore, September 2005. 442p
116
F. Templin, T. Gleeson, M. Talwar, D. Thaler, “Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP)”, IETF Internet Draft draft-ietf-ngtrans-isatap-
24.txt (work in progress), January 2005.
IntroduccionDireccionesIP.pdf. Microsoft Word-direccionesIP.doc.2004.7p.
Fuente: http://www.educa.madrid.org/cms_tools/files/a8dae6a3-c890-4d13-
a8fc5e928c9a98ec/ IntroduccionDireccionesIP.pdf
J. Hagino, K. Yamamoto, “An IPv6-to-IPv4 Transport Relay Translator”,
IETF Request for Comments 3142, June 2001
J. Bound, “Dual Stack IPv6 Dominant Transition Mechanism (DSTM)”, IETF
Internet Draft draft-bound-dstm-exp-03.txt (work in progress), June 2005.
Reddy, J. Bound, “Stack Transition Mechanism (DSTM) Options for
DHCPv6”, IETF Internet Draft draft-reddy-dhcpv6-opt-dstm-exp-00.txt (work
in progress), April 2005.
RFC2402- Authentication Header Noviembre 1998
RFC3338-Bump in the API Octubre 2002
RFC2767-Bump in the Stack Febrero 2000
RFC 3056 - Conexión de Dominios IPv6 a través de nubes IPv4. Febrero
2001
117
RFC 3587-Dirección de enrutamientos globales, Agosto 2003
RFC 4214 - Intra Site automático túnel abordar Protocol (ISATAP). Octubre
2005
RFC2406-IP Encapsulation Security Protocol (ESP). Noviembre 1998
RFC 3053 - Ipv6 Tunnel Broker. Enero 2001
RFC4291-IP Version 6 Addressing Architecture Febrero 2006
RFC2893 - Mecanismos de transición para hosts y router IPv6. Agosto 2000
RFC2893- Mecanismos de transición para hosts y router IPv6 ,Agosto 2000
RFC 2766 – NAT-PT. Febrero 2000
RFC3879- Obsoleto sitio de las direcciones locales , Septiembre 2004
RFC3513-Protocolo de Internet versión 6 (IPv6) Aborda Arquitectura,Abril
2003
RFC2450- Proyecto de TLA y NLA reglas de asignación, Diciembre 1998
RFC 2460-Protocolo de Internet, versión 6(IPV6).Diciembre 1998
RFC3656-Rendezvous Point, Diciembre 2003
118
RFC3089- SOCK Abril 2001
RFC 4380 - Teredo: Tunneling IPv6 sobre UDP. Febrero 2006
RFC3142-Transport Relay Translator.Junio 2001
RFC 2529 - Transmisión de paquetes IPv6 sobre IPv4. Marzo 1999
RFC3306-Unicast-Prefijo basado en direcciones IPv6 Multicast,Agosto 2002
RFC3306-Unicast-Prefijo basado en direcciones IPv6 Multicast,Agosto 2002
RFC 4193- Unique local direcciones IPv6 Unicast, Octubre 2005
R. Hinden, S. Deering, “IP Version 6 Addressing Architecture”, IETF
Request for Comments 2373, July 1998.
S. Routhier, “Management Information Base for the Internet Protocol (IP)”,
IETF Internet Draft draft-ietf-ipv6-rfc2011-update-10.txt, May 2004.
S. Lee, M. Shin, Y. Kim, E. Nordmark, A. Durand, “Dual Stack Hosts Using
‘Bump in the API’ (BIA)”, IETF Request for Comments 3338, October 2002.
119
ANEXO 1. RFC´s para IPV6
120
121