(ms) ipv4-‐ipv6
TRANSCRIPT
U N I V E R S I D A D V E R A C R U Z A N A
FACULTAD DE INGENIERÍA
REGIÓN VERACRUZ
P O S G R A D O
PROYECTO DE INTERVENCIÓN PROFESIONAL Modalidad Tesis
SIMULACIÓN DEL PROTOCOLO IPV6 EN SISTEMAS HETEROGÉNEOS
QUE PARA OBTENER EL GRADO DE: MAESTRIA EN INGENIERÍA APLICADA
PRESENTA: LIC. MIGUEL ANTONIO ORTIZ JUÁREZ
DIRECTOR DE TESIS: MTRO. CARLOS ARTURO CERÓN ÁLVAREZ
BOCA DEL RÍO, VERACRUZ JUNIO 2015
AGRADECIMIENTOS
A mis padres. Con la mayor gratitud por los esfuerzos realizados para que yo lograra
terminar mi carrera profesional siendo para mí la mejor herencia. A mi madre que
es el ser más maravilloso de todo el mundo. Gracias por el apoyo moral, tu cariño y
comprensión que desde niño me has brindado, por guiar mi camino y estar junto a
mí en los momentos más difíciles. A mi padre porque desde pequeño ha sido para
mí un gran hombre maravilloso al que siempre he admirado. Gracias por todo.
A mis hermanos y abuelo. Por el apoyo moral y el ánimo que siempre he recibido
de ustedes y con el cual he logrado culminar mi esfuerzo, terminando así mi
maestría.
Al Mtro. Carlos Arturo Cerón. Gracias por su asesoría en esta Tesis, por su apoyo
en este trabajo, ya que sin su ayuda no hubiera sido posible la realización.
A mis amigos y compañeros de la maestría que siempre estuvieron apoyando en
todo, en especial a mi amigo Antonio, que siempre fue el compañero de proyectos.
II
ÍNDICE
RESUMEN ............................................................................................................................ 1
CAPITULO 1. INTRODUCCIÓN .......................................................................................... 2
1.1 OBJETIVOS ........................................................................................................................... 5
1.1.1 OBJETIVO GENERAL .................................................................................................. 5
1.1.2 OBJETIVOS ESPECÍFICOS ........................................................................................ 5
1.2 JUSTIFICACIÓN ................................................................................................................... 5
1.3 ANTECEDENTES CIENTÍFICOS ....................................................................................... 6
1.4 FACTIBILIDAD DEL PROYECTO ...................................................................................... 7
1.5 PROBLEMÁTICA .................................................................................................................. 7
1.7 INFRAESTRUCTURA .......................................................................................................... 7
1.8 HIPÓTESIS ............................................................................................................................ 8
1.9 METODOLOGÍA ................................................................................................................... 8
1.10 CRONOGRAMA ................................................................................................................. 8
CAPÍTULO 2. MARCO TEORICO ....................................................................................... 9
2.1 PROTOCOLOS DE INTERNET IPV4 Y IPV6 ................................................................ 10
2.1.1 HISTORIA DE INTERNET Y PROTOCOLO TCP/IP ................................................. 10
2.2 PROTOCOLO TCP/IP ........................................................................................................ 13
2.3 PROTOCOLO DE INTERNET VERSIÓN 4 (IPV4) ........................................................ 14
2.4 PROTOCOLO DE INTERNET VERSIÓN 6 (IPV6) ........................................................ 16
CAPÍTULO 3. TIPOS DE MECANISMOS DE COMUNICACIÓN ENTRE IPV4 A IPV6 Y PTOCOLOCOS DE ENRUTAMIENTO .............................................................................. 19
3.1 MECANISMO DSTM .......................................................................................................... 20
3.2 MECANISMOS SIIT ........................................................................................................... 21
3.3 MECANISMOS NAT-PT .................................................................................................... 24
3.4 MECANISMOS BIS ............................................................................................................ 26
3.5 MECANISMOS TRT ........................................................................................................... 29
3.6 MECANISMOS SOCKS64 ................................................................................................ 32
3.7 MECANISMOS BIA ............................................................................................................ 34
3.8 PROTOCOLOS DE ENRUTAMIENTO ............................................................................ 35
III
3.8.1 PROTOCOLO DE ENRUTAMIENTO RIP .............................................................. 37
3.8.2 PROTOCOLO DE ENRUTAMIENTO IGRP ............................................................ 41
3.8.3 PROTOCOLO DE ENRUTAMIENTO EIGRP .......................................................... 43
3.8.4 PROTOCOLO DE ENRUTAMIENTO OSPF ........................................................... 48
3.8.5 PROTOCOLO DE ENRUTAMIENTO BGP ............................................................. 49
CAPÍTULO 4. MÉTODOS Y MECANISMOS DE INTEGRACION IPV6 ............................ 52
4.1 TIPOS DE MECANISMOS PARA LA TRANSICIÓN DE IPV4 A IPV6 ....................... 53
4.1.1 TÚNELES ESTÁTICOS 6IN4 .................................................................................... 55
4.1.2 TÚNELES ESTÁTICOS GRE ................................................................................... 56
4.1.3 TUNNEL BROKERS ................................................................................................... 58
4.1.4 6PE y 6VPE .................................................................................................................. 59
4.1.5 TÚNELES AUTOMÁTICOS 6TO4 ............................................................................ 61
4.1.6 TÚNELES 6RD ............................................................................................................ 63
4.1.7 TEREDO ....................................................................................................................... 64
4.2 NUEVAS TÉCNICAS DE TRANSICIÓN ......................................................................... 65
4.2.1 NAT444 ......................................................................................................................... 65
4.2.2 NAT64 Y DNS64 .......................................................................................................... 68
4.2.3 464XLAT ....................................................................................................................... 70
4.2.4 DS-LITE ........................................................................................................................ 72
4.2.5 MAP ............................................................................................................................... 73
4.2.6 CONTEMPLACIÓN SOBRE LAS NUEVAS TÉCNICAS DE TRANSICIÓN ....... 75
CAPÍTULO 5. SIMULACIÓN DE IPV4 EN SISTEMAS DE DIFERENTES INFRAESTRUCTURAS ..................................................................................................... 77
5.1 SIMULACIÓN DE UNA RED IPV4 RIP .......................................................................... 78
5.2 SIMULACIÓN DE UNA RED IPV6 OSPF ..................................................................... 85
5.3 SIMULACIÓN DE UNA RED IPV4 E IPV6 OSPF Y RIP ............................................ 92
5.4 RESULTADOS .................................................................................................................. 104
CAPÍTULO 6. CONCLUSIONES ..................................................................................... 118
TRABAJO FUTURO ................................................................................................................ 120
FUENTES DE INFORMACIÓN ........................................................................................ 124
GLOSARIO ...................................................................................................................... 128
IV
ÍNDICE DE FIGURAS
Figura 1 Arquitectura DSTM (Nordmark, 2005) ..................................................... 21
Figura 2 Esquema SIIT para redes IPv6 (Nordmark, 2005) ................................... 22
Figura 3 Esquema SIIT para redes “Dual Stack” (Nordmark, 2005) ...................... 23
Figura 4 Esquema NAT-PT (Nordmark, 2005) ....................................................... 25
Figura 5 Esquema del mecanismo BIS. (Tsuchiya, Higuchi, & Atarashi, 2006) ..... 27
Figura 6 Esquema del mecanismo TRT (Dunmore, 2005) ..................................... 31
Figura 7 Diagrama del mecanismo Socks. (Cisco, 2012) ...................................... 32
Figura 8 Esquema del proxy Socks64 (Cisco, 2012) ............................................. 33
Figura 9 Routers ejecutando el RIP (Cisco, 2005) ................................................. 44
Figura 10 Calculo de trayecto más adecuado (Cisco, 2005) ................................. 47
Figura 11 Túnel 6IN4(Moreiras, 2014) ................................................................... 56
Figura 12 Túnel GRE (Moreiras, 2014) .................................................................. 57
Figura 13 Túnel Broker (Moreiras, 2014) ............................................................... 59
Figura 14 6PE y 6VPE (Moreiras, 2014) ................................................................ 60
Figura 15 6IN4 (Moreiras, 2014) ............................................................................ 62
Figura 16 Túnel automático 6RD (Moreiras, 2014) ................................................ 64
Figura 17 NAT4444 (Moreiras, 2014) ..................................................................... 66
Figura 18 NAT64 y DNS64 (Moreiras, 2014) ......................................................... 69
Figura 19 464XLAT (Moreiras, 2014) ..................................................................... 71
Figura 20 DS-LITE (Moreiras, 2014) ...................................................................... 72
Figura 21 MAP-T (Moreiras, 2014) ......................................................................... 74
Figura 22 MAT-E (Moreiras, 2014) ......................................................................... 74
Figura 23 Red IPv4 con sus direcciones ................................................................ 78
Figura 24 Red IPv6 con sus direcciones ................................................................ 86
Figura 25 Red IPv4-IPv6 con sus diferentes direcciones ....................................... 93
Figura 26 Pings R1 ............................................................................................... 104
Figura 27 Pings R2 ............................................................................................... 105
Figura 28 Pings R3 ............................................................................................... 105
Figura 29 Pings R4 ............................................................................................... 106
V
Figura 30 Pings R5 ............................................................................................... 106
Figura 31 Velocidad de respuesta del R1 ............................................................ 107
Figura 32 Velocidad de respuesta del R2 ............................................................ 108
Figura 33 Velocidad de respuesta del R3 ............................................................ 108
Figura 34 Velocidad de respuesta del R4 ............................................................ 109
Figura 35 Velocidad de respuesta del R5 ............................................................ 109
Figura 36 Velocidad de respuesta promedio de IPv4 .......................................... 110
Figura 37 Velocidad de respuesta del R1 ............................................................ 111
Figura 38 16 Velocidad de respuesta del R2 ....................................................... 111
Figura 39 Velocidad de respuesta del R3 ............................................................ 112
Figura 40 Velocidad de respuesta del R4 ............................................................ 112
Figura 41 Velocidad de respuesta del R5 ............................................................ 113
Figura 42 Velocidad de respuesta promedio de IPv6 .......................................... 113
Figura 43 Velocidad de respuesta del R1 ............................................................ 114
Figura 44 Velocidad de respuesta del R2 ............................................................ 115
Figura 45 Velocidad de respuesta del R3 ............................................................ 115
Figura 46 Velocidad de respuesta del R4 ............................................................ 116
Figura 47 Velocidad de respuesta del R5 ............................................................ 116
Figura 48 Velocidad de respuesta promedio de IPv4 - IPv6 ................................ 117
VI
ÍNDICE DE TABLAS
Tabla 1 Direcciones IPv4 ....................................................................................... 79
Tabla 2 Direcciones IPv6 ....................................................................................... 86
Tabla 3 Direcciones IPv4 e IPv6 ............................................................................ 93
Tabla 4 Tiempos de respuesta de los routers IPv4 .............................................. 107
Tabla 5 Tiempos de respuesta de los routers IPv6 .............................................. 110
Tabla 6 Tiempos de respuesta de los routers IPv4 con IPv6 ............................... 114
1
RESUMEN La presente Tesis titulada “SIMULACIÓN DEL PROTOCOLO IPV6 EN SISTEMAS
HETEROGÉNEOS” da a conocer la simulación de IPv6 en sistemas compuestos
por hardware y software con características distintas entre sí, haciendo una
comunicación mediante medios comunes.
Así mismo también se hablara sobre el protocolo 4 (Internet Protocol versión
4, por sus siglas en ingles) el cual está llegando a su fin de direcciones y por lo
mismo ha sido diseñado y ya implementando en algunos sectores del país el
protocolo 6 (Internet Protocol versión 6, por sus siglas en ingles).
Para finalizar se dará una conclusión acerca del trabajo, y las líneas de
investigación futuras que se puedan llagar a realizar en base a este trabajo.
CAPITULO 1. INTRODUCCIÓN
3
Internet se ha convertido en un recurso crítico para el funcionamiento de más y más
instituciones de diversa índole. Lejos están ya los días, en que solo las empresas
relacionadas directamente con las tecnologías de la información, eran las únicas
para las cuales el acceso a Internet resultaba imprescindible para su operación.
Hoy en día instituciones desde micro comercios hasta las grandes empresas,
pasando por casas, escuelas, hospitales, entre otras, requieren conectividad global
ya sea para proveer o recibir servicios a través de Internet, para relacionarse con
sus proveedores e incluso para el buen funcionamiento cotidiano de estas. Esto
implica que una interrupción en el acceso a Internet supone un alto costo, por lo que
existe una fuerte demanda de mecanismos que brinden un alto nivel de tolerancia
a fallos en la conexión a Internet.
El protocolo de Internet define como se comunican los dispositivos a través
de las redes. La versión 4 de IP (IPv4), que actualmente es predominante, contiene
aproximadamente cuatro 4,300 millones de direcciones IP, las cuales ya no son
suficientes para estos tiempos, según la pagina de internet LACNIC (por sus siglas
en ingles Latin America & Caribbean Network Information Centre) el cual es el
encargado de la asignación de direcciones, anunció el 10 de junio de 2004, el
agotamiento del stock de direcciones IPv4 y expreso su preocupación por la demora
de operadores y gobiernos en desplegar el protocolo de internet IPv4 en dichas
regiones. LACNIC dio a conocer que se han alcanzado 4,194,302 direcciones IPv4
en su stock.
La versión 4 del protocolo IP, la que utilizamos ahora de forma mayoritaria,
fue aprobada en el año 1981 y está descrita en el documento RFC791. Treinta años
de vida en un mundo tan dinámico como este parece una barbaridad. Durante los
últimos años ha habido muchos falsos avisos de que IPv4 estaba llegando a su fin
pero ahora, finalmente, parece que esto ya es así. El 3 de febrero de 2011 IANA
(por sus siglas en ingles, Internet Assigned Numbers Authority) dio a conocer que
se asignaron a los diferentes comités regionales, los últimos bloques de direcciones
4
que quedaban. En este documento veremos algunas de las principales novedades
que aporta el nuevo protocolo, alguna forma de empezar a trabajar con él y una idea
del estado de implantación en nuestro país a mediados de 2011.
El motivo básico para crear un nuevo protocolo fue la falta de direcciones.
IPv4 tiene un espacio de direcciones de 32 bits, en cambio IPv6 ofrece un espacio
de 128 bits. IPv6 admite 340 sextillones de direcciones
(340.282.366.920.938.463.463.374.607.431.768.211.456), cerca de 6,7 x 1017
(670 mil billones) de direcciones por cada milímetro cuadrado de la superficie de la
Tierra. El reducido espacio de direcciones de IPv4, junto al hecho de falta de
coordinación para su asignación durante la década de los 80, sin ningún tipo de
optimización, dejando incluso espacios de direcciones discontinuos, generan en la
actualidad, dificultades no previstas en aquel momento.
El Protocolo de Internet versión 6 (IPv6) es una versión del protocolo de
Internet (IP), definida en el RFC 2460 y diseñada para reemplazar el IPv4 RFC 791,
que actualmente está implementado en la gran mayoría de dispositivos que acceden
a Internet. Diseñado por Steve Deering de Xerox PARC y Craig Mudge, IPv6 está
destinado a sustituir a IPv4, cuyo límite en el número de direcciones de red
admisibles está empezando a restringir el crecimiento de Internet y su uso,
especialmente en China, India, y otros países asiáticos densamente poblados. El
nuevo estándar mejorará el servicio globalmente;; por ejemplo, proporcionará a
futuras celdas telefónicas y dispositivos móviles sus direcciones propias y
permanentes. (Palet 2011)
A principios de 2010, quedaban menos del 10% de IP’s sin asignar. La IANA
(Internet Assigned Numbers Authority, por sus siglas en inglés) entregó el último
bloque de direcciones disponibles (33 millones) a la organización encargada de
asignar IPs en Asia, un mercado que está en auge y no tardará en consumirlas
todas. IPv4 posibilita 4.294.967.296 (232) direcciones de red diferentes, un número
inadecuado para dar una dirección a cada persona del planeta, y mucho menos a
5
cada vehículo, teléfono, PDA, etcétera. Otra vía para la popularización del protocolo
es la adopción de este por parte de instituciones. (Palet 2011)
En la pagina Internet Live Stats, mediante un estudio realizado en el 2014
llamado, Lista de países por el uso de Internet 2014. Se puede observar claramente
que China es el país con mas población cibernauta con una cantidad de usuarios
de 641,601,070;; seguida por Estados Unidos con 279,834,232 e India en tercer
lugar con 243,198,922;; México se posiciona en el lugar 11 con 50,923,060
cibernautas.
1.1 OBJETIVOS
1.1.1 OBJETIVO GENERAL
Simular el diseño de una red IPv4 migrando IPv6 mediante métodos y mecanismos
de integración.
1.1.2 OBJETIVOS ESPECÍFICOS
• Utilizar estrategias de migración de IPv4 a IPv6.
• Creación de estructuras para IPv6.
• Simulación de estructuras de red con IPv6.
1.2 JUSTIFICACIÓN
Últimamente la comunidad de cibernautas, así como también, las direcciones de
Internet van en aumento al grado de que esas direcciones hablando de IPv4 se
están terminando, ya que dicho protocolo usa 32 bits restringiendo de tal forma su
6
crecimiento. La migración a lo nuevo IPv6 estaría siendo algo forzoso en un futuro
no muy lejano debido al crecimiento poblacional en los dispositivos que se usan
para estar conectados a Internet. Dicho cambio no se puede realizar de un momento
para otro, es un proceso lento el cual requerirá de años para poder establecerse
IPv6 como el principal, por el momento IPv4 e IPv6 operan a la par mediante túneles
que permiten la comunicación, una con la otra.
De tal manera este trabajo, mediante la simulación de IPv6 se verá el
funcionamiento de dicho protocolo y se observara como implementar las nuevas
estructuras de red, de tal forma que ayude a migrar de una red a otra con mucha
más facilidad y sin problema alguno.
1.3 ANTECEDENTES CIENTÍFICOS
La Universidad Veracruzana a colaborado en el desarrollo de investigaciones
respecto a las redes y sus diferentes protocolos de internet, con el fin de saber mas
al respecto y las nuevas tendencias que se suscitan con el tiempo.
En base a lo anterior el Mtro. Carlos Arturo Cerón Álvarez en compañía de la
ya Ingeniero Abisadai Moreno José, egresada de la Facultad de Ingeniería de Boca
del Rio, comenzaron con el estudio de los protocolos IPv4 e IPv6, con el fin de que
entre ellos exista la interoperabilidad y la comunicación, todo esto mediante túneles
y protocolos de enrutamiento, capaces de realizar lo anterior.
Con dicho trabajo que se realizo anteriormente, se pretende que en este
nuevo proyecto se realice lo mismo ampliando el panorama, para implementar
mediante simulaciones, las conexión de IPv4 con IPv6 en diferentes sistemas
heterogéneos.
7
1.4 FACTIBILIDAD DEL PROYECTO
La Universidad Veracruzana a colaborado en el desarrollo de investigaciones
respecto a las redes y sus diferentes protocolos de internet, con el fin de saber mas
al respecto y las nuevas tendencias que se suscitan con el tiempo.
En base a lo anterior el Mtro. Carlos Arturo Cerón Álvarez en compañía de la
ya Ingeniero Abisadai Moreno José, egresada de la Facultad de Ingeniería de Boca
del Rio, comenzaron con el estudio de los protocolos IPv4 e IPv6, con el fin de que
entre ellos exista la interoperabilidad y la comunicación, todo esto mediante túneles
y protocolos de enrutamiento, capaces de realizar lo anterior.
Con dicho trabajo que se realizo anteriormente, se pretende que en este
nuevo proyecto se realice lo mismo ampliando el panorama, para implementar
mediante simulaciones, las conexión de IPv4 con IPv6 en diferentes sistemas
heterogéneos.
1.5 PROBLEMÁTICA
La problemática se centra en los métodos y/o mecanismos de transición de IPv4 a
IPv6 en sistemas heterogéneos, el cual con la limitación que ya se esta presentando
en cuando a las direcciones versión 4, ha surgido la versión 6 dando por
consiguiente una gama más amplia en direcciones IP.
1.7 INFRAESTRUCTURA
• Software de simulación con GNS3.
• Computadora.
• Routers modelo 7200 (IOS c7200-jk9s-mz. 124-13).
8
1.8 HIPÓTESIS
La implementación de un mecanismo de transición mediante la estrategia de
traducción permitirá la coexistencia entre los protocolos de internet versión 6 y
versión 4 en ambientes de enrutamiento multiprotocolo, mejorando tiempos de
respuesta.
1.9 METODOLOGÍA
La presente investigación es de carácter técnico practico, pues se pretende analizar
los protocolos de internet de versión 4 y 6, a través de simulaciones que se
realizaran con el software GNS3, con el fin de comparar las versiones de dichos
protocolos, verificando la operavilidad entre estos dos, así mismo comparando
tiempos y ver cual funciona mejor que el otro, siempre y cuando esten trabajando
en conjunto.
1.10 CRONOGRAMA
CRONOGRAMA
Actividad
Agosto Septiembre Octubre
Noviembre
Diciembre Enero Febrero Marzo
Abril Mayo Junio Julio
Agosto Septiembre Octubre
Noviembre
Diciembre Enero Febrero Marzo
Abril Mayo Junio Julio
1 Titulo y Asesor 2 Reuniones Con Asesor 3 Revisión Literaria 4 Análisis de la información 5 Simulación de Protocolos 6 Experimentación 7 Escritura de Tesis 8 Estructuración 9 Inicio de Tramites 10 Examen profesional
CAPÍTULO 2. MARCO TEORICO
10
2.1 PROTOCOLOS DE INTERNET IPV4 Y IPV6
En el presente capítulo se basa en los servicios estandarizados llamados Protocolos
de Internet en dos versiones, 4 y 6 se vera el direccionamiento usado por el IP y
explicaremos la división de las clases de direcciones del IP. Adicional detallamos un
aspecto del protocolo como TCP e IP brindan las fórmulas para transmisión de
mensajes, también se discutirán los estándares de comunicación,
independientemente de hardware de la red. (Chandan J., 2014)
2.1.1 HISTORIA DE INTERNET Y PROTOCOLO TCP/IP
En realidad Internet es un medio de comunicación que revoluciona el mundo tanto
de las telecomunicaciones como de los ordenadores o computadoras. Las bases
que permitieron su desarrollo o evolución, inicialmente desde el telégrafo hasta las
computadoras personales pasando por el teléfono y la radio2 . La cantidad de
información que maneja en la actualidad Internet es demasiado grande, siendo
utilizado como un recurso investigativo cuyo acceso de información mundial se lo
realiza en pocos segundos. Internet inicialmente fue ideada por J. C. R. Licklider,
que mediante oficios escritos en Agosto de 1962 en el Instituto Tecnológico de
Massachusetts (MIT), describía computadores que se conectaban entre sí, para
acceder a la toda la información entre las misma, también denominada por él como
una Red Galáctica (Galactic Network). Debido a estas ideas radicales Licklider fue
designado Director del Programa DARPA (Defense Advanced Research Projects
Agency). (IEEE, 2009)
El protocolo TCP/IP fue diseñado a finales de 1960 como el fundamento de
la red ARPANET, que conectaba las computadoras de oficinas gubernamentales y
universitarias. Funcionaba bajo el concepto de cliente servidor, lo que significa que
alguna computadora pide los servicios de otra computadora;; la primera es el cliente
y la segunda el servidor. (Ramírez 2012)
11
En 1961, Leonard Klienrock introduce el concepto de Conmutación de Paquetes
(Packet Switching, en inglés). La idea era que la comunicación entre ordenadores
fuese dividida en paquetes. Cada paquete debería contener la dirección de destino
y podría encontrar su propio camino a través de la red.
En octubre de 1962, Licklider fue nombrado jefe de la oficina de procesado
de información de la Agencia de Proyectos de Investigación Avanzada (Defense
Advanced Research Projects Agency o DARPA), y empezó a formar un grupo
informal dentro de DARPA del Departamento de Defensa de los Estados Unidos
para investigaciones sobre ordenadores más avanzadas. (IEEE, 2010)
Como parte del papel de la oficina de procesado de información, se instalaron
tres terminales de redes: una para la System Development Corporation en Santa
Mónica, otra para el Proyecto Genie en la Universidad de California (Berkeley) y otra
para el proyecto Multics en el Instituto Tecnológico de Massachusetts. La necesidad
de Licklider de redes se haría evidente por los problemas que esto causó.
Ya para el año 1969 la Agencia de Proyectos de Investigación Avanzada
(Defense Advanced Research Projects Agency o DARPA) del Ejército de los EEUU
desarrolla la ARPANET(Ureña Poirier & Rodríguez Martín, 2012). La finalidad
principal de esta red era la capacidad de resistir un ataque nuclear de la URSS para
lo que se pensó en una administración descentralizada. (IEEE, 2010)
De este modo, si algunos ordenadores eran destruidos, la red seguiría
funcionando. Aunque dicha red funcionaba bien, estaba sujeta a algunas caídas
periódicas del sistema. De este modo, la expansión a largo plazo de esta red podría
resultar difícil y costosa. Se inició entonces una búsqueda de un conjunto de
protocolos más fiables para la misma. Dicha búsqueda finalizó, a mediados de los
70, con el desarrollo de TCP/IP, es por esto, que se inicia la investigación en
desarrollar productos de redes de computadoras, y de la tecnología de
comunicación, denominada también como conmutación de paquetes, y finalmente
12
surge el protocolo TCP/IP. Entre los objetivos principales se encontraban los
siguientes:
• Protocolos Comunes: que permita el protocolo común la comunicación de
todas las redes para simplificación de los procesos.
• Interoperabilidad: que funcionen correctamente los equipos de distintos
fabricantes y de manera conjunta, permitiendo el desarrollo eficiente y
fomentando la competitividad entre los proveedores.
• Comunicaciones sólidas: que los protocolos aporten con conexiones fiables
y de alto rendimiento mediante redes de área extensa relativamente
primitivas disponibles en aquel momento.
• Facilidad de reconfiguración: que la red permita reconfigurarse, es decir,
facilidad para añadir o eliminar computadores sin sufrir interrupciones de
comunicaciones.
Tras varias investigaciones realizadas, se asigna roles al protocolo TCP/IP,
donde solamente IP se encargaría de enviar paquetes a través 21 de una red de
comunicaciones hacia su destino. Mientras que para controlar el flujo de información
o que lleguen los paquetes correctamente al destino se emplean los 2 protocolos,
el TCP y el UDP (User Datagram Protocol), en esencia son el mismo, aunque el
segundo no permite que todos los paquetes lleguen a su destino, solamente una
parte, es decir, no es confiable. Los grupos encargados para desarrollar el nuevo
protocolo se encontraban en las Universidades de Stanford y UCLA que incluía a la
empresa Bolt, Beraneck & Newman (BBN), cuya designación fue autorizada por la
DARPA. (Science Direct, 2013)
Según los expertos, la Internet como la conocemos, se enfrentará aun grave
problema en unos pocos años. Debido a su rápido crecimiento y las limitaciones en
13
su diseño, habrá un momento en que no hay direcciones más libres están
disponibles para conectar a nuevos huéspedes. En ese punto, no hay servidores
web más nuevas se pueden crear, sin más usuarios pueden inscribirse para las
cuentas de los ISP, y no máquinas más nuevas pueden ser configurados para
acceder a la web o participar en juegos en línea - algunas personas pueden llamar
a este un problema grave. (Ramírez, 2012)
2.2 PROTOCOLO TCP/IP
Una vez conocida la historia y de cómo se organiza INTERNET, procederemos a
describir los protocolos que permiten su funcionamiento universal,
independientemente de los computadores, sistemas operativos y/o redes que la
conforman. A continuación, definiremos los protocolos TCP/IP extraída de (Richard
Stevens, 2011): Las familias de protocolos TCP/IP permiten la comunicación entre
diferentes tipos de ordenadores con independencia del fabricante, red a la que se
encuentren conectados y sistema operativo utilizado. (Palet 2011)
El protocolo de Internet, es un protocolo que no se encuentra orientado a la
conexión para transmisión de información mediante una red de paquetes de datos
conmutados. Se encuentra localizado en la tercer capa del modelo ISO/OSI, el cual
permite entregar paquetes de datos desde un nodo de origen a otro nodo destino,
basado en la dirección escrita en cada paquete. (Palet 2011)
La mencionada capa de red de acuerdo al modelo TCP/IP, se emplea los
protocolos pertenecientes a la capa de transporte (TCP), permitiendo orientar los
datos hacia un destino específico, direccionando los datagrama generados en la
capa de red, pero sin poder comprobar la integridad del contenido. (Palet 2011)
Con lo descrito no se podía distinguir las versiones del IP, aunque con la llegada o
aparición de la versión 6, se empezó a diferenciar el IPv6 de la IPv4, ésta versión
cuenta con una longitud de 32 bits. Dicha longitud se escribe mediante la forma
14
dottedquad (a, b, c, d) que es representado por el número decimal en el intervalo de
0 a 255, es decir, que el rango se escribe desde 0.0.0.0 hasta 255.255.255.255, lo
que es una limitante en la actualidad ya que existe combinaciones del tipo 2 =
4.294.967.296 o sea 4 billones de direcciones. (Palet 2011)
Las clases ‘a’, ‘b’ y ‘c’ han sido divididas en partes fijas, dichas divisiones son
muy conocidas en el rango ya mencionado anteriormente. Adicionalmente, existen
direcciones del tipo ‘d’ y ‘e’, reservadas para procesos multicast y experimentales.
La dirección de clase ‘A’ tiene 8 y 24 bits, que permite identificar la red y los usuarios
respectivamente.
Una vez elegido el tamaño de direcciones IP y la división de cada dirección
dada en dos partes, primeramente el prefijo requiere suficientes bits para admitir la
concesión de la dirección de red única en Internet. (Carpenter, 2005)
Ahora, para el sufijo se necesitan demasiados bits para cada una de las
computadoras que se encuentran conectadas a la red cuyo sufijo es único No existe
la solución integral, ya que al agregar bits a una parte se los disminuía de la otra.
Finalmente, se puede decir, que un prefijo grande dirección a muchas redes, aunque
limita el tamaño de cada red;; mientras que el sufijo grande, indica a la red que puede
contar con muchas computadoras, reduciendo así la cantidad total de redes.
2.3 PROTOCOLO DE INTERNET VERSIÓN 4 (IPV4)
El protocolo de internet IP, es la parte fundamental sustentada por el sistema TCP/IP
y de todo el funcionamiento de INTERNET. (Palet 2011)
Según el modelo TCP/IP el protocolo de capa 3 permite direccionar los
datagramas en la capa de red, este encabezado se superpone al datagrama
manejado, es decir, las características de ruteo y transmisión.
15
La longitud que tiene el encabezado IP en la capa de red es de 170 bits, que
aproximadamente es 20 bytes, formada por diversos campos con distintos
significado. El encabezado de IPv4 se detalla a continuación. (Palet 2011)
A. Versión, nos indica el número de la versión del protocolo de internet (IP), es
decir, que para IPv4 el valor será 4.
B. Longitud de encabezado (IHL, Internet Header Length), describe la longitud
del encabezado en número de grupos de 32 bits cada uno de 4 bits.
C. Tipo de servicio, nos permite saber la importancia de los datos enviados,
condicionando la forma en que serán tratados en la transmisión de 8 bits.
D. Longitud total, nos indica la longitud completa en bytes del datagrama de 16
bits, incluyendo el encabezado y los datos. En la práctica el datagrama es
pequeño (16 bits) y teóricamente no será mayor a 65.535 bytes.
E. Identificación, utilizada para el ensamble de los fragmentos de un datagrama
de 16 bits.
F. Banderas, es un indicador empleado en la fragmentación de 3 bits.
G. Fragmentación, permite ensamblar los datagramas previamente
fragmentados, cuyo valor es de 64 bits (grupos de 8 bytes), inicializado en 0
para fragmento 1 de 16 bits.
H. Límite de existencia (TTL, Time to Live), es aquel número disminuido cada
vez que el paquete de datos (8 bits) pasa por un nodo de red, si el valor toma
un 0 indica que el paquete se descarta. Por cuestiones de seguridad
debemos evadir la 29 redundancia cíclica, empleado por razones de
seguridad siendo improbable que esto ocurra en una red bien diseñada.
16
I. Protocolo, es un número que se emplea para definir el protocolo
perteneciente al datagrama (8 bits), de tal manera que sea tratado
eficientemente cuando llegue a su destino.
J. Comprobación, permite verificar los datos que contienen al encabezado del
IP sean correctos, dicha eficiencia no se utiliza para evaluar los datos ya
incluidos, sino que los datos de usuario se comprueban posteriormente del
encabezado siguiente, correspondiente al nivel de capa de transporte (16
bits). Adicionalmente, si cambiamos la opción de encabezado, dicho campo
será calculado nuevamente.
K. Dirección fuente, es aquella que contiene la dirección del usuario en la que
envía el paquete de datos de 32 bits.
L. Dirección destino, es aquella dirección del usuario que recibe la información,
es decir, que los routers o Gateways (medios intermedios) conocen la
dirección para llegar correctamente el paquete de datos de 32 bits.
2.4 PROTOCOLO DE INTERNET VERSIÓN 6 (IPV6)
La historia de Ipv6 se inició en el año 1990, cuando se reveló que las direcciones
IPv4disponibles estaban disminuyendo aceleradamente. Según estudios realizados
por profesionales que indicaban que las IPv4 se agotarían alrededor del 2005.
Dichos estudios fueron muy cuestionados por toda la comunidad de Internet, y es
de ahí que iniciaron la búsqueda de posibles soluciones. Para ese entonces se
plantearon dos soluciones: (Palet, 2011)
Mínimo: Salvaguardar el protocoloIPv4, es decir, mantenerlo intacto, sólo se debe aumentarla longitud de la dirección. Esto es muy sencillo, lo que ocurriría es
tener menos suplicio en la fase de despliegue.
17
Máximo: Desplegar completamente la nueva versión del protocolo IPv6, cuyo enfoque permitiría incorporar nuevas características y mejoras en IPv4.
El primer conjunto de protocolos RFCs que rigen al IPv6, fue presentado
finalizando el año 1995, dicho protocolo se lo denomino RFC 1883: Protocolo de
Internet versión 6 (IPv6). Una vez que se tenía 32 disponible el RFC 1883 las
implementaciones fueron esperadas con entusiasmo, pero nunca ocurrieron.
(Deering, 2006)
Para ese entonces (década del año 1990) el auge significativo de Internet en
empresas causo incertidumbre entre ellas, donde tenían que resolver un complicado
problema de negocio, invertir en IPv6 que traería algunos beneficios a futuro, o
invertir en el despliegue de IPv4, ya que cualquiera de los dos protocolos (IPv6 e
IPv4) les representarían ganancias. Finalmente la mayoría de las empresas
decidieron escoger el retorno rápido y fácil de las inversiones y desarrollaron
productos basados en IPv4. (Taffernaberry, 2006)
Surgieron otros métodos para mantener el espacio de direcciones, el más
importante es el enrutamiento sin clase entre dominios (CIDR, Classless Inter-
Domain Routing), como consecuencia, los sitios recién conectados obtuvieron
significativamente menos direcciones que en años anteriores. El uso del CIDR
retraso la implementación de IPv6 ante los ojos de muchas personas, pero no en
todos. (Deering, 2006)
Aquellos sitios nuevos o en expansión desarrollaron métodos para limitar
este recurso, uno de estos enfoques ha sido la traducción de dirección de red (NAT,
Network Address Translation) que permitió utilizar a las redes de computadoras un
número cualquiera de direcciones privadas, y para luego convertirlas en públicas
cuando los paquetes dejaran el sitio y viceversa. NAT utiliza el mecanismo de
compartir direcciones públicas a través de hosts, así como otros mecanismos tales
como PPP (Point to Point Protocol) y DHCP (Dynamic Host Configuration Protocol)
18
proporcionan un medio para que hosts alquilen direcciones por un cierto período de
tiempo. (ScienceDirect, 2007)
CAPÍTULO 3. TIPOS DE MECANISMOS DE COMUNICACIÓN ENTRE IPV4 A IPV6 Y PTOCOLOCOS DE ENRUTAMIENTO
20
3.1 MECANISMO DSTM
DSTM por sus siglas en ingles “Dual StackTransitionMechanism”, es un mecanismo
que permite a nodos “dual stack” comunicarse con otras aplicaciones solamente
IPv4, aunque la pila IPv4 está habilitada pero debe configurarse para lograr dicha
comunicación. En consecuencia, un nodo IPv4 e IPv6 requieren direcciones IPv4,
la cual es solicitada al servidor DSTM, mientras que la comunicación entre el nodo
y servidor DSTM es a través de IPv6. (Nordmark, 2005)
En ausencia de encapsulamiento IPv4 en redes IPv6, la maquina “dual stack”
encapsula paquetes IPv4 dentro de paquetes IPv6 hasta el extremo del túnel, el
mismo que lo desencapsula y enviado a infraestructura IPv4. El encapsulamiento
se lo realiza virtualmente, para lo cual DSTM describe la arquitectura (ver figura 1)
siguiente:
• Servidor DSTM, encargada de asignar direcciones IPv4 a clientes que lo
soliciten.
• Router DSTM, se encarga de realizar la encapsulación y desencapsulación
de paquetes asegurando el envió de paquetes.
• Cliente DSTM, son capaces de configurar dinámicamente su pila IPv4 y son
capaces de establecer túneles IPv4 sobre IPv6.
21
Figura 1 Arquitectura DSTM (Nordmark, 2005)
El mecanismo DSTM se clasifica en:
• Ámbito de aplicación: dominio.
• RequisitosdeIPv4:ninguno.
• Requisitos de las direcciones IPv4: >=1 por sitio.
• RequisitosdeIPv6:extensionesparaDHCPv6.
• RequisitosdelasdireccionesIPv6:ninguno.
• Requisitos de máquinas: pila IPv4 e IPv6 con extensiones.
• Requisitos de routers: ninguno.
• Impacto del NAT: se comunican utilizando IPv4 aunque pueden ser
penalizadas por NATs que encuentren en el camino.
• Otros requisitos: infraestructura de encaminamiento de IPv4.
3.2 MECANISMOS SIIT
El mecanismo SIIT (Stateless IP/ICMP Translation Algorithm) se encarga
básicamente de traducir los paquetes a nivel de red entre los nodos IPv4 e IPv6,
dicha traducción se limita a la cabecera IP, es decir, que la traducción debe
22
realizarse para cada paquete. Adicional a las direcciones IPv6 el mecanismo SIIT
emplean direcciones IPv4 traducidas, haciendo uso de dos tipos de direcciones que
se describen a continuación: (Nordmark, 2005)
• Direcciones IPv4 mapeadas, del tipo “::ffff:a.b.c.d” que permiten identificar
una máquina IPv4.
• Direcciones IPv4 traducidas, del tipo “::ffff:0:a.b.c.d” que permiten identificar
una máquina IPv6.
En el método SIIT, el nodo IPv6 obtiene direcciones temporales IPv4 y sirve
como medio de enrutamiento para los paquetes. En consecuencia, las direcciones
para SIIT suelen ser de tres tipos: IPv4, IPv4-traducidas o IPv4-mapeadas. El
método SIIT no específica como obtiene direcciones temporales IPv4, y mucho
menos como se registre su DNS. La figura 2 se ilustra el método SIIT empleado
para la comunicación entre redes IPv6 (pequeñas) o hosts IPv6 y hosts IPv4.
Figura 2 Esquema SIIT para redes IPv6 (Nordmark, 2005)
La figura 3 muestra el método SIIT empleado para sitios que tienen
únicamente IPv6 en una red “Dual Stack”.
23
Figura 3 Esquema SIIT para redes “Dual Stack” (Nordmark, 2005)
Los ordenadores que no hagan uso de los traductores SIIT, deben de
modificar ciertos aspectos para implementar el protocolo IPv6, que son capaces de:
• Permitir la transmisión y recepción de paquetes IPv6 con direcciones
mapeadas IPv4.
• Determinar si las direcciones IPv4 traducidas, deben ser asignadas o
refrescadas.
• Asegurar que el mecanismo de selección de la dirección IPv4 traducidas solo
se utilizan conjuntamente con direcciones IPv4 mapeadas.
El mecanismo SIIT se clasifican en:
• Ámbito de aplicación: dominio.
• RequisitosdeIPv4:ninguno.
• Requisitos de las direcciones IPv4: 1 dirección temporal por cada máquina
IPv6.
24
• RequisitosdeIPv6:ninguno.
• Requisitos de las direcciones IPv6: direcciones IPv4 mapeadas y traducidas
que permitan identificar nodos IPv4 e IPv6.
• Requisitos de máquinas: pila IPv6.
• Requisitos de routers: ninguno.
• Impacto del NAT: son traducidos los paquetes más de una vez.
• Otros requisitos: algún mecanismo de asignación de direcciones como por
ejemplo “dual stack”.
3.3 MECANISMOS NAT-PT
El mecanismo NAP-PT (Network Address Translator – Protocol Translator) es aquel
que permite la comunicación entre nodos IPv6 e IPv4 (ambas son únicas y no
privadas). NAP-PT es similar al método NAT que se utiliza en IPv4 pero no es
idéntico, el mismo consiste en traducir una dirección IPv4 a otra dirección IPv4.
Mientras que los enrutadores NAT-PT pasan todos los paquetes de una misma
sesión.
En la figura 4 se puede mirar el esquema básico NAT-PT, donde los nodos A
y B tiene IPv6 (FADC:AC23::2345:1130 y FADC:AC23::2345:1131 respectivamente), el Nodo C tiene una dirección IPv4 (192.68.40.10) y el router
NAT-PT tiene asignado un grupo de direcciones de la subred 168.130.36/34.
(Nordmark, 2005)
25
Figura 4 Esquema NAT-PT (Nordmark, 2005)
El funcionamiento del mecanismo NAT-PT consiste en:
• Las direcciones IPv6 a IPv4definen direcciones falsas IPv6 empleando una
dirección IPv4 de destino y anteponiendo el prefijo NAT, para poder
establecer comunicaciones de datos se debe configurar en el NAT-PT con
un prefijo de 96 bits. En consecuencia, el NAT-PT examina los paquetes para
identificar
direcciones falsas, y finalmente traduciendo el paquete a IPv4.
• Las direcciones IPv4 a IPv6 funcionan como un NAT bidireccional, donde la
traducción es semejante al inciso a), generando un paquete IPv6 con
dirección origen, mientras que la dirección falsa IPv6 contiene internamente
una dirección IPv4 de tal manera se inicia la comunicación.
26
El mecanismo NAT-PT se clasifica en:
• Ámbito de aplicación: dominio.
• RequisitosdeIPv4:ninguno.
• Requisitos de las direcciones IPv4: >=1 por sitio.
• RequisitosdeIPv6:ninguno.
• RequisitosdelasdireccionesIPv6:ninguno.
• Requisitos de máquinas: pila IPv6.
• Requisitos de routers: ninguno, aunque el router puede ser NAT-PT.
• Impacto del NAT: requieren dos o más niveles de traducción.
• Otros requisitos: DNS dentro de una red IPv6.
3.4 MECANISMOS BIS
El mecanismo BIS (Bump in the Stack ) permite a hosts “Dual Stack” comunicarse
con hosts IPv6 utilizando aplicaciones IPv4. Puede resultar muy útil para aquellas
aplicaciones que no han migrado (por no tener el código fuente) a IPv6 para así
establecer comunicación entre hosts IPv6. En consecuencia, cuando las
aplicaciones IPv4 buscan comunicarse con aplicaciones IPv6, este realiza el mapeo
entre una dirección IPv6 y una dirección IPv4. (Tsuchiya, Higuchi, & Atarashi, 2006)
El mecanismo BIS se encarga de traducir aplicaciones IPV4 y redes situadas
por debajo de IPV6, en otras palabras, nos referimos al controlador de interfaz de
red. Básicamente el diseño del stack consta de una pila dual stack, en el cual añade
tres módulos, un traductor, un nombre de la extensión de la resolución y la dirección
de un mapeado, tal y como se muestra en la figura 5.
27
Figura 5 Esquema del mecanismo BIS. (Tsuchiya, Higuchi, & Atarashi, 2006)
El mecanismo BIS admite que hosts se conviertan en traductores autónomos,
para lo cual ya no es necesario un traductor externo. El mecanismo BIS está ubicado
en el área de seguridad del protocolo de internet (IP), y posteriormente encargado
de verificar datos que pasan entre TCP/IPv4 y una interface de red, además de
traducirlos a IPv6 y viceversa.
El mecanismo BIS permite la comunicación de hosts IPv4 al IPv6 pero no
existe comunicación IPv6 al IPv4. Imposible de enviar o recibir algún paquete IPv4
para la red, por lo que una aplicación IPv4 pretende comunicar con otra aplicación
IPv4 a través del BIS, el cual produce un error si no hay mecanismos de traducción
adicionales en algún lugar de la ruta de comunicación.
Al igual como ocurre con los mecanismos NAT-PT, SIIT y BPI no pueden
funcionar comunicaciones multicast, ni para aplicaciones que incorporen
direcciones IP en sus cargas. Una ALG (Aplicación Layer Gateway) es necesaria
para cualquier aplicación que tiene este comportamiento.
Por ejemplo, una máquina implementa el mecanismo BIS actuando como
originadora de la comunicación y a la vez como receptora. Se va a comentar paso
28
a paso cuando la aplicación IPv4 intenta enviar paquetes a una aplicación en una
máquina IPv6:
1. La aplicación IPv4 consulta al DNS si inicia o no la comunicación con el
extremos remoto.
2. Resuelve la consulta de tipo “AAAA” procesada por el módulo “resolver”, el
cual solicita al módulo de mapeo establecer la correspondencia entre
direcciones IPv6 (destino) e IPv4 disponibles.
3. El nombre de extensión resolver, crea un paquete de respuesta para la
aplicación de tipo A con la dirección IPv4 recién creada.
4. La aplicación detecta el destino como una dirección IPv4 y empieza el envió
de paquetes.
5. El traductor captura los paquetes IPv4 a través del mapeador logrando
convertir al IPv4 destino en IPv4 fuente.
6. El traductor envía el paquete IPv6 creado por el controlador de interfaz de
red.
7. El paquete llega hasta la dirección IPv6 destino, el mismo que se encarga de
enviar un paquete IPv6 hacia el nodo origen de la comunicación.
8. El paquete IPv6 llega hasta el nodo origen.
9. Finalmente se traduce el paquete IPv6 a través de la tabla de asignaciones
del mapeador, entregando el paquete IPv4 así construido a la aplicación final.
Cuando entra en funcionamiento el mecanismo BIS se comporta como un
receptor, dicha comunicación se explica paso a paso:
1. Un paquete IPv6 adquiere al nodo implementado por el mecanismo BIS.
2. La traducción obtiene el paquete y lo traduce, a través del módulo de mapeo
para conseguir la correspondencia entre las direcciones IPv6 (destino) e
IPv4.
3. La traducción entrega un paquete IPv4 creado en las aplicaciones IPv4.
4. Las aplicaciones IPv4 como respuesta envía un paquete IPv4 al nodo inicial
de la comunicación.
29
5. Para el presente paso hay que seguir los pasos del ejemplo anterior.
El mecanismo BIS se clasifica en:
• Ámbito de aplicación: host.
• Requisitos de IPv4: ninguno.
• Requisitos de las direcciones IPv4: espacio privado de direcciones por
maquina.
• RequisitosdeIPv6:ninguno.
• RequisitosdelasdireccionesIPv6:ninguno.
• Requisitos de hosts: doble pila más extensiones.
• Requisitos de routers: ninguno.
• Impacto del NAT: hay presencia de una NAT aunque no hay efecto en el
trafico IPv6 debido a que las direcciones IPv4 son usadas internamente.
• Otros requisitos: direcciones de una forma literal.
3.5 MECANISMOS TRT
El mecanismo TRT (Transport Relay Translator) especificado por el requisito
RFC3142, establece que los hosts IPv6 intercambien el trafico TCP o UDP con hosts
IPv4. Es decir, que permite comunicarse directamente entre aplicaciones IPv6 e
IPv4. A diferencia del mecanismo NAT-PT, el TRT actúa a nivel de la capa de
transporte, y a diferencia del BIS, actúa como una pasarela entre ambos protocolos,
estableciendo una conexión para IPv6 y otra para IPv4 permitiendo el reenvió de
paquetes entre ambas direcciones. (Hagino & Yamamoto, 2009)
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.El mecanismo TRT es
traducido y ejecutado en un nodo <<dual stack>> para así establecer la
comunicación con un host (cliente) o con el servidor. Al implementar una red IPv6
30
es necesario mantener el acceso a todos los recursos IPv4 de redes externas, tales
como servidores web IPv4 y es por este motivo que emplearemos el mecanismo de
pasarela de traducción a nivel de transporte (TRT).
El mecanismo TRT posee ciertas ventajas con respecto a los demás
mecanismos, como por ejemplo, no tienen problemas en traducción de cabeceras
IPv4/IPv6 y de fragmentación. Las desventajas del TRT son:
1. TRT soporta únicamente tráfico bidireccional.
2. TRT requiere de un sistema de almacenamiento de estado entre los nodos
IPv4 e IPv6 para poder comunicarse, similar a los sistemas NAT.
3. TRT requiere de un código especial para reenviar protocolos
incompatibles con NAT (NAT-unfriendly).
Las redes IPv6 e IPv4 son configuradas de tal manera que tanto los paquetes
IPv6 como IPv4 son enviados a direcciones cuyos prefijos de red especiales son
enrutados por un nodo remoto TRT. En la figura 6 TRT IPv6/IPv4permite interceptar
las sesiones de transporte mediante los nodos como punto final de destino de una
sesión IPv6 y envía hacia el nodo del servidor como una sesión IPv4, copiando así
todos los datos recibidos en cada sesión. (Dunmore, 2005)
31
Figura 6 Esquema del mecanismo TRT (Dunmore, 2005)
El mecanismo TRT se clasifica de la siguiente manera:
• Ámbito de aplicación: dominio.
• RequisitosdeIPv4:ninguno.
• Requisitos de las direcciones IPv4: 1 por sitio.
• RequisitosdeIPv6:ninguno.
• Requisitos de las direcciones IPv6: un prefijo para encaminar los paquetes
hacia el traductor.
• Requisitos de máquinas: ninguno.
• Requisitos de routers: ninguno, pero requiere de una máquina TRT.
• Impacto de lNAT: depende de la aplicación.
• Otros requisitos: servidor DNS para mapeo de direcciones IPv4 a
direcciones IPv6.
32
3.6 MECANISMOS SOCKS64
El mecanismo Socks64 se basa en el proxy SOCKS convencional, dicho mecanismo
está compuesto por una puerta de enlace SOCKS implementado como un host de
pila dual IPv4/IPv6 y un cliente de acogida implementado con un software llamado
SOCKS LIB entre las capas de aplicación y transporte (ver figura 7). Esto intercepta
las consultas DNS y responde con falsas direcciones IPv4, de modo que cuando el
cliente hace una llamada a la conexión API, donde LIB SOCKS sustituye la dirección
falsa original y envía el paquete, llamado SOCKS al proxy que realiza la actual
búsqueda de DNS.
Figura 7 Diagrama del mecanismo Socks. (Cisco, 2012)
Si el servidor DNS responde con un registro AAAA, el proxy abre un socket
IPv6, de lo contrario, se abre un socket IPv4. Definido en el RFC 3089, la solución
SOCKS64 es bidireccional, lo que permite anfitriones hosts IPv4 e IPv6 para iniciar
sesiones. Sin embargo, es necesario el uso de direcciones IPv4 publicas. (Cisco,
2012)
33
En la figura 8 se muestra la configuración del proxy SOCKS, el mismo que
se define como un mecanismo de reenvió de la capa de transporte, permitiendo
hosts con direcciones privadas o con acceso limitado a través de firewalls que
puedan tener libre acceso a los recursos de Internet. Un proxy SOCKS para IPv4
se aloja por lo general en una gran base dual con una dirección privada y otros
públicos. El recibe conexiones desde hosts internos por su interfaz IP privada y crea
conexiones con servidores en Internet a través de su interfaz publica. Del mismo
modo, un SOCKS64 proxy está alojado en un servidor de base dual con una
dirección IPv6 y otra dirección IPv4 publica. Se puede recibir por sus conexiones de
interfaz de IPv6 y redirigirlos por su interfaz IPv4 y viceversa.
Figura 8 Esquema del proxy Socks64 (Cisco, 2012)
34
Esta solución puede llegar a ser la ideal en caso de que el 'sitio' esté
utilizando ya SOCKS. Con un Gateway de tipo SOCKS64 se puede permitir conectar
a los clientes tanto a nodos IPv4 como IPv6, sin los típicos problemas asociados a
los túneles (fragmentación y limite de saltos).
El mecanismo Socks64 se clasifica en:
• Ámbito de aplicación: dominio.
• Requisitos de IPv4: ninguno.
• Requisitos de las direcciones IPv4: 1 por pasarela o servidor Socks.
• Requisitos de IPv6: >=1 por sitio.
• Requisitos de las direcciones IPv6: ninguno.
• Requisitos de máquinas: los clientes deben ser socksificados. • Requisitos de routers: ninguno.
• Impacto del NAT: operación conjunta entre servidores NAT y Socks. • Otros requisitos: servidor Socks emplea el “dual stack”.
3.7 MECANISMOS BIA
El mecanismo BIA (Bump in the API) es muy similar al mecanismo BIS, dicho
mecanismo agrega una API de traducción entre el API de socket y módulos
TPC/hosts IP pila dual, permitiendo aplicaciones de comunicación con anfitriones
IPv4 e IPv6, lo que refleja las funciones de la toma en socket IPv4 a IPv6 y viceversa.
El mecanismo BIA está descrito por el RFC 3338, en la cual tres módulos son
añadidos como se puede ver en la siguiente imagen. (Cisco, 2012)
El nombre de extensión de resolución (extensión name resolver), y las
direcciones de mapeo (address mapper) funcionan de la misma manera que el BIS.
La función de mapeo (function mapper), detecta las llamadas de las funciones del
socket IPv4 e invoca las funciones correspondientes del socket IPv6 y viceversa.
35
El BIA tiene dos ventajas sobre BIS: no dependen del controlador de interfaz
de red y no introducir una sobrecarga en la traducción de los encabezados del
paquete. Sin embargo, tampoco es compatible con la comunicación multicast.
El mecanismo Socks64 se clasifica en:
• Ámbito de aplicación: maquina.
• RequisitosdeIPv4:ninguno.
• Requisitos de las direcciones IPv4: espacio privado de direcciones por
maquina.
• RequisitosdeIPv6:ninguno.
• RequisitosdelasdireccionesIPv6:ninguno.
• Requisitos de maquinas: doble pila más extensiones.
• Requisitos de routers: ninguno.
• Impacto de lNAT: no resulta afectado por la presencia de NATs.
• Otros requisitos: aplicaciones que utilizan direcciones de una forma literal.
3.8 PROTOCOLOS DE ENRUTAMIENTO
Los protocolos de enrutamiento son un conjunto de reglas utilizadas por un router
para realizar la conexión con otro router, con el fin de compartir información de
enrutamiento. Dicha información se usa para construir y mantener las tablas de
enrutamiento. (Cisco, 2009)
Enrutamiento Estático. El principal problema que plantea mantener tablas de enrutamiento estáticas, además de tener que introducir manualmente en los routers
toda la información que contienen, es que el router no puede adaptarse por sí solo
a los cambios que puedan producirse en la topología de la red. Sin embargo, este
método de enrutamiento resulta ventajoso en las siguientes situaciones: (Cisco,
2009)
36
• Existe una sola conexión con un solo ISP. En lugar de conocer todas las rutas
globales, se utiliza una única ruta estática.
• Un cliente no desea intercambiar información de enrutamiento dinámico.
Enrutamiento Predeterminado. Es una ruta estática que se refiere a una conexión de salida o Gateway de “último recurso”. El tráfico hacia destinos
desconocidos por el router se envía a dicha conexión de salida. Es la forma más
fácil de enrutamiento para un dominio conectado a un único punto de salida. Esta
ruta se indica como la red de destino 0.0.0.0/0.0.0.0.
Enrutamiento Dinámico. Los protocolos de enrutamiento mantienen tablas de enrutamiento dinámicas por medio de mensajes de actualización del
enrutamiento, que contienen información acerca de los cambios sufridos en la red,
y que indican al software del router que actualice la tabla de enrutamiento en
consecuencia. Intentar utilizar el enrutamiento dinámico sobre situaciones que no lo
requieren es una pérdida de ancho de banda, esfuerzo, y en consecuencia de
dinero. (Cisco, 2009)
Al igual los protocolos de enrutamiento dinámico se clasifican en, vector
distancia y estado de enlace.
Vector distancia. Se basa en la cantidad de “número de saltos” en las redes, siendo en la cantidad de routers por los que pasará el paquete para llegar hasta su
destino, indicará que la red que tenga el menor número de saltos es la óptima.
Estado de enlace. Se centra en la métrica del retardo, el ancho de banda, la carga y la confiabilidad, de los distintos enlaces posibles para así, llegar a un
destino, en base a los conceptos del protocolo que prefiere para elegir una ruta
sobre otra. (Cisco, 2009)
37
Entre los protocolos de enrutamiento dinámicos se encuentran los siguientes:
RIP, IGRP, EIGRP, OSPF y BGP.
3.8.1 PROTOCOLO DE ENRUTAMIENTO RIP
RIP es un protocolo de enrutamiento vector-distancia que utiliza recuento enrutador
de saltos como métrica. RIP es un protocolo de enrutamiento con clase que no
admite VLSM o CIDR. (Cisco, 2009)
No hay un método para la autenticación de las actualizaciones de ruta. Un
router RIP envía una copia de su tabla de enrutamiento a sus vecinos cada 30
segundos. RIP utiliza horizonte dividido con envenenamiento en reversa;; Por lo
tanto, las actualizaciones de ruta se envían una interfaz con una métrica infinita para
las rutas aprendidas (recibida) desde la misma interfaz. (Cisco, 2009)
El estándar RIP se basa en el popular enrutada programa utilizado en los
sistemas UNIX desde 1980. La implementación de Cisco de RIP añade soporte para
el equilibrio de carga. RIP de equilibrio de carga de tráfico si hay varios caminos con
el mismo (el equilibrio de carga igual costo) métrica a un destino. También, RIP
envía actualizaciones desencadenadas cuando la métrica de una ruta cambia.
Actualizaciones desencadenadas pueden ayudar a la red converge más rápido en
lugar de esperar a la actualización periódica. RIP tiene una distancia administrativa
de 120. Capítulo 11, "Criterios de selección de enrutamiento de Protocolo", cubre la
distancia administrativa. (Cisco, 2009)
RIP resume los valores de red IP en los límites de la red. Un límite de la red se
produce en un router que tiene una o más interfaces que no participan en la red IP
especificada. La dirección IP asignada a la interfaz determina la participación. Clase
IP determina el valor de la red. La implementación de Cisco de RIP utiliza cuatro
temporizadores:
38
• Actualización
• Inválido
• Flush
• Holddown
RIP envía su tabla de enrutamiento completa a cabo todas las interfaces
configuradas. La mesa se envía periódicamente a medida que una emisión
(255.255.255.255) para todos los hosts.
Temporizador de actualización
El temporizador de actualización especifica la frecuencia de las
transmisiones periódicas. Por defecto, el temporizador de actualización se
establece en 30 segundos. Cada ruta tiene un valor de tiempo de espera asociado
con él. El tiempo de espera se restablecerá cada vez que el router recibe una
actualización de enrutamiento que contiene la ruta. (Cisco, 2009)
Temporizador no válido
Cuando el valor de tiempo de espera expira, la ruta se marca como
inalcanzable porque está marcado válido. El router marca la ruta inválida por el
establecimiento de la métrica a 16. La ruta se retiene en la tabla de enrutamiento.
Por defecto, el temporizador no válido es de 180 segundos, o seis actualizaciones
períodos (30 x 6 = 180). (Cisco, 2009)
Temporizador Flush
Una entrada de ruta marcada como no válida se retiene en la tabla de
enrutamiento hasta que expire el temporizador de lavado. Por defecto, el
temporizador ras es de 240 segundos, que es 60 segundos más largo que el
temporizador no válido. (Cisco, 2009)
39
Temporizador Holddown
Cisco implementa un contador de tiempo adicional para RIP, el temporizador
de espera. El temporizador de espera se estabilice rutas mediante el
establecimiento de un plazo fijado para el que se suprime la información de
enrutamiento con respecto a caminos diferentes. Después de la métrica de una ruta
cambia de entrada, el router no acepta versiones de la ruta hasta que expire el
temporizador de espera. Por defecto, el temporizador de espera es de 180
segundos. (Cisco, 2009)
Las características de RIPv1 son:
• Protocolo de vector-distancia.
• Utiliza el puerto UDP 520.
• Protocolo con clase (no hay soporte para VLSM o CIDR).
• Metric es el recuento hop router.
• Número máximo de saltos es 15;; rutas inalcanzables tienen una métrica de
16.
• Actualizaciones periódicas de ruta transmiten cada 30 segundos.
• 25 rutas por mensaje RIP.
• Implementa horizonte dividido con envenenamiento en reversa.
• Implementos activan actualizaciones.
• No hay soporte para la autenticación.
• La distancia administrativa para RIP es 120.
• Utilizado en redes pequeñas, planas o en el borde de las redes más grandes.
RIPv2 mejora sobre RIPv1 con la capacidad de utilizar VLSM, con el apoyo para la
autenticación de ruta, y con la multidifusión de cambios de ruta. RIPv2 soporta
CIDR. Todavía envía actualizaciones cada 30 segundos y conserva el límite de 15-
hop;; también utiliza actualizaciones desencadenadas. RIPv2 todavía utiliza el
puerto UDP 520;; el proceso de RIP es responsable de comprobar el número de
40
versión. Conserva las estrategias de prevención de bucle inverso veneno y contar
hasta el infinito. En los routers Cisco, RIPv2 tiene la misma distancia administrativa
como RIPv1, que es 120. Por último, RIPv2 utiliza la dirección 224.0.0.9 IP cuando
la multidifusión actualizaciones de ruta a otros enrutadores RIP. Al igual que en
RIPv1, RIPv2, por defecto, haga un resumen de redes IP en los límites de la red.
Puede desactivar auto resumen si es necesario. (Cisco, 2009)
Puede utilizar RIPv2 en pequeñas redes donde se requiere VLSM. También
trabaja en el borde de las redes más grandes.
Cosas a tener en cuenta en el diseño de una red con RIPv2 incluyen que
soporta VLSM dentro de las redes y CIDR para el resumen de la red a través de
redes adyacentes. RIPv2 permite el resumen de rutas en una red jerárquica. RIPv2
todavía está limitado a 16 saltos;; Por lo tanto, el diámetro de la red no puede superar
este límite. RIPv2 multi difunde su tabla de enrutamiento cada 30 segundos para la
multidifusión 224.0.0.9 dirección IP. (Cisco, 2012)
RIPv2 se limita generalmente a las redes con el acceso donde se puede
interactuar con los servidores que ejecutan enrutadas o con los routers Cisco no.
RIPv2 también aparece en el borde de Internet más grandes. RIPv2 proporciona,
además, para la autenticación ruta. Las características de RIPv2: (Cisco, 2009)
• Protocolo de vector-distancia.
• Utiliza el puerto UDP 520.
• Protocolo sin clase (apoyo a CIDR).
• Soporta VLSM.
• Metric es el recuento hop router.
• Número máximo de saltos es 15;; rutas infinitas (inalcanzables) tienen una
métrica de 16.
• Actualizaciones periódicas de ruta envían cada 30 segundos para 224.0.0.9
dirección de multidifusión.
41
• 25 rutas por mensaje RIP (24 si se utiliza la autenticación).
• Soporta autenticación.
• Implementa horizonte dividido con envenenamiento en reversa.
• Implementos activan actualizaciones.
• Máscara de subred incluida en entrada de ruta.
• La distancia administrativa para RIPv2 es 120.
• Utilizado en redes pequeñas, planas o en el borde de las redes más grandes.
3.8.2 PROTOCOLO DE ENRUTAMIENTO IGRP
Cisco Systems desarrolló el IGRP para superar las limitaciones de RIPv1. IGRP es
un protocolo de enrutamiento por vector distancia que considera un indicador
compuesto que, por defecto, utiliza el ancho de banda y el retardo como parámetros
en lugar de número de saltos. IGRP no se limita al límite 15-hop de RIP. IGRP tiene
un límite máximo de saltos de 100, por defecto, y puede ser configurado para
soportar un diámetro a la red de 255. (Cisco, 2005)
Con IGRP, routers suelen seleccionar caminos con un ancho de banda
mínimo de vínculos más grande sobre caminos con un número de saltos más
pequeño. Los enlaces no tienen un número de saltos. Son exactamente un salto.
IGRP es un protocolo con clase y no puede aplicar una mascara de subred
de tamaño variable o enrutamientos entre dominios sin clases. IGRP resume en los
límites de la red. Al igual que en RIP, IGRP implementa horizonte dividido con
envenenamiento en reversa, provocada actualizaciones y temporizadores de
espera para la estabilidad y la prevención de bucle. Otro beneficio de IGRP es que
puede equilibrar la carga a través de enlaces desigual coste. Como protocolo de
enrutamiento desarrollado por Cisco, IGRP sólo está disponible en los routers de
Cisco. (Cisco, 2005)
42
Por defecto, IGRP cargará equilibrio tráfico si hay varios caminos con igual
costo para el destino. IGRP hará balance de carga de costos desiguales si se ha
configurado con la varianza de comandos. Las características principales de este
protocolo, se enumeran a continuación:
• Ruteo estable en redes largas y complejas;; no realiza la ruta en los loops
que puedan ocurrir, estos son transcendidos.
• Rápida respuesta al cambio de topología de red.
• Gastos indirectos bajos. Lo que quiere decir que IGRP puede no usar más
ancho de banda de la que necesita.
• El tráfico de rutas puede ser paralela entre rutas, lo que equivale a una red
en la misma convivencia.
• Dependiendo de la tasa de error y el nivel de trafico, elige el mejor camino.
La implementación de IGRP puede ser usando el modelo TCP/IP para el
ruteo;; las asignaciones básicas son para implementar una variedad de protocolos.
La intención es usar IGRP para conectar redes extensas. Cuando asumimos que
una red está basada en esta tecnología, entendemos que, por defecto, los Gateway
actúan como paquetes en los switches. Cuando un sistema conectado a una red
quiere enviar paquetes a un sistema en una diferente red, se direcciona el paquete
al Gateway. Si el destino está sobre la red conectada al Gateway, este envía el
paquete a su destino. Si el destino está a mayor distancia de la red, el Gateway
seguirá el paquete hasta otro Gateway, que es el que llevará el paquete a su destino.
Usa tablas de ruteo para decidir a donde enviará los paquetes. La implementación
de IGRP es asignada básicamente a varios protocolos. Las características de IGRP
son: (Cisco, 2005)
• Protocolo de vector-distancia.
• Protocolo con clase (no hay soporte para CIDR).
• No hay soporte para mascara de subred de tamaño variable.
• Métrica compuesta utilizando el ancho de banda y el retardo por defecto.
43
• Puede incluir la carga y fiabilidad en la métrica.
• Actualizaciones de ruta envían cada 90 segundos.
• 104 rutas por mensaje IGRP.
• Número de saltos limitado a 100 por defecto, configurable a un máximo de
255.
• No hay soporte para la autenticación.
• Implementa horizonte dividido con envenenamiento en reversa.
• Implementos activan actualizaciones.
• De forma predeterminada, el equilibrio de carga igual costo. De equilibrio de
carga de costos desiguales con la varianza de comandos.
• La distancia administrativa es 100.
• Anteriormente utilizado en redes de gran tamaño;; sustituido ahora por
EIGRP.
3.8.3 PROTOCOLO DE ENRUTAMIENTO EIGRP
El Enhanced Interior Gateway Routing Protocol (EIGRP) es un protocolo de
Gateway interior apropiado para muchos tipos diferentes de topologías y
dispositivos. En una red correctamente diseñada, EIGRP escala de forma óptima y
ofrece tiempos de convergencia extremadamente rápidos con un mínimo tráfico de
red. Algunas de las varias ventajas de EIGRP son: (Cisco, 2005)
• El uso mínimo de los recursos de la red durante su funcionamiento normal;;
sólo se transmiten paquetes de saludo (hello) en una red estable.
• Cuando se produce un cambio, sólo se propagan los cambios en la tabla de
ruteo, y no toda la tabla;; con esto se consigue reducir la carga que el propio
protocolo de ruteo deposita en la red.
• Tempos de convergencia rápidos en la topología de la red (en determinadas
situaciones, la convergencia puede llegar a ser casi instantánea).
44
EIGRP es un protocolo de vector de distancia mejorado basado en el
Algoritmo de actualización difuso (DUAL) para calcular el trayecto más corto hasta
un destino dentro de la red.
Existen dos revisiones principales de EIGRP, las versiones 0 y 1. Las
versiones de Cisco IOS anteriores a la 10.3(11), 11.0(8) y 11.1(3) ejecutarán la
versión anterior de EIGRP;; es posible que algunas explicaciones contenidas en este
documento no se apliquen a dicha versión anterior. Se recomienda especialmente
usar la versión más reciente de EIGRP, ya que ésta incluye varias mejoras de
desempeño y estabilidad. (Cisco, 2005)
Un protocolo de vector de distancia habitual guarda la siguiente información
al calcular el mejor camino a un destino: la distancia (métrica total o distancia como,
por ejemplo, el recuento de saltos) y el vector (el siguiente salto o "next hop"). Por
ejemplo, todos los routers en la red de la figura 9 ejecutan el Routing Information
Protocol (RIP). El Router Two elige el trayecto a la Red A tras examinar el recuento
de saltos a través de cada trayecto disponible.
Figura 9 Routers ejecutando el RIP (Cisco, 2005)
Dado que el trayecto a través del Router Three contiene tres saltos, mientras
que el trayecto a través del Router One contiene dos, el Router Two elegirá el
45
trayecto a través del Router One y rechazará la información obtenida a través del
Router Three. Si el trayecto entre el Router One y la Red A deja de funcionar, el
Router Two perderá toda conectividad con este destino hasta que se agote el tiempo
de espera de la ruta de su tabla de ruteo (tres períodos de actualización
equivalentes a 90 segundos), y el Router Three anunciará nuevamente la ruta (lo
cual se produce cada 30 segundos en RIP). Sin tener en cuenta el tiempo de
retención, el Router 2 tardará entre 90 y 120 segundos para conmutar el trayecto
del Router One al Router Three. (Cisco, 2005)
El protocolo EIGRP, en lugar de depender de actualizaciones periódicas
completas para volver a converger, construye una tabla de topología a partir de cada
uno de los anuncios de su vecino (en lugar de rechazar los datos) y realiza la
convergencia ya sea buscando una ruta probable sin bucles en la tabla de topología
o, si no conoce otra ruta, consultando a sus vecinos. El Router Two guarda la
información que recibió de los Routers One y Three. Elige el trayecto a través del
Router One como su mejor trayecto (el sucesor) y el trayecto a través del Router
Three como un trayecto sin bucles (un sucesor factible). Cuando el trayecto a través
del Router One no esté disponible, el Router Two examinará su tabla de topología
y, al encontrar un sucesor factible, comenzará inmediatamente a usar el trayecto a
través del Router Three. A partir de esta breve explicación, es claro que EIGRP
debe proporcionar los siguientes elementos:
• Un sistema en el que se envían únicamente las actualizaciones necesarias
en un momento dado;; esto se consigue mediante el descubrimiento y
mantenimiento de vecinos.
• Es la manera de determinar qué trayectos ha aprendido un router como libres
de bucles
• Los proceso para eliminar rutas defectuosas de las tablas de topología de
todos los routers de la red
• El proceso de consulta a vecinos para encontrar rutas hacia destinos perdido
46
Para distribuir la información de ruteo por toda una red, EIGRP emplea
actualizaciones de ruteo graduales no periódicas. Es decir, EIGRP sólo envía
actualizaciones de ruteo relativas a trayectos modificados cuando se modifican
dichos trayectos.
El problema principal al enviar únicamente actualizaciones de ruteo es que
es posible que no sepa cuándo deja de estar disponible un trayecto a través de un
router vecino. No es posible agotar el tiempo de espera de las rutas con el objetivo
de recibir una nueva tabla de ruteo de sus vecinos. EIGRP se basa en las relaciones
de vecinos para propagar de un modo fiable las modificaciones de la tabla de ruteo
por toda la red;; dos routers pasan a ser vecinos cuando cada uno ve el paquete de
saludo del otro en una red común. (Cisco, 2005)
EIGRP envía paquetes de saludo cada 5 segundos en enlaces de ancho de
banda alto y cada 60 segundos en enlaces multipunto de ancho de banda bajo.
Saludo de 5 segundos: medios de difusión, como Ethernet, Token Ring y
FDDI. Enlaces seriales punto a punto, como PPP o circuitos dedicados HDLC,
subinterfaces punto a punto Frame Relay y subinterfaz punto a punto ATM. Circuitos
multipunto de ancho de banda alto (mayor que T1), como ISDN PRI y Frame Relay.
Saludo de 60 segundos: circuitos multipunto de ancho de banda T1 o más
lentos, como interfaces multipunto Frame Relay, interfaces multipunto ATM,
circuitos virtuales conmutados ATM o ISDN BRI.
A diferencia de RIP e IGRP, no se basa en la tabla de ruteo (o reenvío) del
router para mantener toda la información necesaria para funcionar. En cambio, crea
una segunda tabla, la tabla de topología, desde la cual instala rutas en la tabla de
ruteo. (Cisco, 2005)
47
La tabla de topología contiene la información necesaria para crear un
conjunto de distancias y vectores para cada red alcanzable, que incluye:
• El ancho de banda más bajo en el trayecto para este destino según informó
el vecino en sentido ascendente
• Retraso total
• Confiabilidad de trayecto
• Carga de trayecto
• Unidad de transmisión máxima (mtu) del trayecto mínimo
• Distancia factible
• Distancia informada
• Origen de la ruta (las rutas externas están marcadas)
EIGRP utiliza el ancho de banda mínimo en el trayecto hasta la red de destino
y el retraso total para calcular las métricas de ruteo. Si bien puede configurar otras
métricas, no es recomendable, ya que podría provocar bucles de ruteo en su red.
El ancho de banda y las métricas de retraso se determinan a partir de los valores
configurados en las interfaces de los routers que se encuentran en el trayecto hasta
la red de destino. En la figura 10 a continuación, el Router One está calculando el
trayecto más adecuado hasta la Red A.
Figura 10 Calculo de trayecto más adecuado (Cisco, 2005)
48
Empieza con dos anuncios para esta red: uno a través del Router Four con
un ancho de banda mínimo de 56 y un retraso total de 2.200, y el otro a través del
Router Three con un ancho de banda mínimo de 128 y un retraso de 1.200. El
Router One elige el trayecto de métrica más baja. (Cisco, 2005)
3.8.4 PROTOCOLO DE ENRUTAMIENTO OSPF El protocolo OSPF se desarrolló a partir de una necesidad en la comunidad de
Internet de introducir un Protocolo de Gateway interior (IGP) no propietario y de alta
funcionalidad para la familia de protocolos TCP/IP. La discusión sobre la creación
de un IGP común interoperable para Internet comenzó en 1988 y no se formalizó
hasta 1991. En aquel momento, el grupo de trabajo OSPF solicitó que OSPF se
considerara un avance para el estándar de Internet de borrador. (Cisco, 2005)
El protocolo OSPF se basa en tecnología de estado de enlace, la cual es una
desviación del algoritmo basado en el vector Bellman-Ford que se usa en los
protocolos tradicionales de enrutamiento de Internet, como por ejemplo, RIP. OSPF
ha introducido conceptos nuevos, por ejemplo, la autenticación de actualizaciones
de enrutamiento, máscaras de subred de longitud variable (VLSM), resumen de ruta,
etc. (Cisco, 2005)
En los siguientes capítulos, se tratará la terminología OSPF, el algoritmo y las
ventajas y desventajas del protocolo en el diseño de las complejas redes de gran
tamaño de hoy en día. Características de OSPF:
• Con OSPF, no hay limitación para el conteo de saltos.
• El uso inteligente de VLSM es de gran utilidad a la hora de realizar la
asignación de direcciones IP.
49
• OSPF utiliza la multidifusión IP para enviar actualizaciones de estado de
enlace. Esto garantiza un menor procesamiento en los routers que no están
a la escucha de paquetes OSPF. Además, las actualizaciones sólo se envían
en caso de cambios de enrutamiento y no de manera periódica. Esto
garantiza un mejor uso del ancho de banda.
• OSPF tiene mejor convergencia que RIP. Esto se debe a que los cambios en
el enrutamiento se propagan de forma instantánea y no periódica.
• OSPF permite un mejor balance de carga.
• OSPF permite una definición lógica de redes en las que los routers se pueden
dividir en áreas. De este modo, se limita la explosión de actualizaciones de
estado de enlace en toda la red, además de proporcionar un mecanismo para
agregar rutas y reducir la propagación innecesaria de información de subred.
• OSPF permite la autenticación de enrutamiento a través de distintos métodos
de autenticación de contraseñas.
• OSPF permite la transferencia y el etiquetado de rutas externas inyectadas
en un sistema autónomo. De este modo, se realiza un seguimiento de las
rutas externas inyectadas por protocolos exteriores como BGP.
3.8.5 PROTOCOLO DE ENRUTAMIENTO BGP
BGP (Border Gateway Protocol por sus siglas en ingles) es un protocolo mediante
el cual se intercambia información de encaminamiento entre sistemas autónomos.
Por ejemplo, los ISP registrados en Internet suelen componerse de varios sistemas
autónomos y para este caso es necesario un protocolo como BGP. (Telda, 2008)
50
El protocolo BGP utiliza el protocolo TCP para establecer una conexión
segura entre dos extremos BGP en el puerto 179. Una sesión TCP se establece
exactamente entre cada par para cada sesión del BGP. Ninguna información de
encaminamiento puede ser intercambiada hasta que se ha establecido la sesión
TCP. Esto implica la existencia previa de conectividad IP para cada par de extremos
BGP. Para dotarlo de mayor seguridad, se pueden usar firmas MD5 para verificar
cada segmento TCP. (Telda, 2008)
BGP es un protocolo de encaminamiento vectorial, porque almacena la
información de encaminamiento como combinación entre el destino y las
características de la ruta para alcanzar ese destino. El protocolo utiliza un proceso
de selección determinista de la ruta para seleccionar la mejor dentro de las múltiples
rutas factibles, usando las cualidades de la ruta como criterios. Las características
como por ejemplo el retardo, la utilización del enlace o el número de saltos no se
consideran dentro de este proceso. El proceso de selección de la ruta es la clave
para comprender y establecer las políticas del protocolo BGP y se analizarán más
adelante. (Telda 2008)
Al igual que la mayoría de los protocolos del tipo IGP, BGP envía solamente
una actualización completa del encaminamiento una vez que se establece una
sesión BGP, enviando posteriormente sólo cambios incrementales. BGP
únicamente recalcula la información de encaminamiento concerniente a estas
actualizaciones, no existiendo proceso que actualice toda su información de
encaminamiento como los cálculos del SPF en el OSPF o el IS-IS. Aunque la
convergencia IGP puede ser más rápida, un IGP no está preparado para soportar
el número de las rutas empleadas en el encaminamiento interdominio. Un IGP
también carece de las cualidades de ruta que el BGP lleva, y que son esenciales
para seleccionar la mejor ruta y construir políticas de encaminamiento. BGP es el
único protocolo adecuado para el uso entre sistemas autónomos, debido a la ayuda
inherente que las políticas sobre rutas proporcionan para el encaminamiento. Estas
políticas permiten que se acepte o rechace la información de cambio de
51
encaminamiento antes de que se utilice para tomar decisiones de envío. Esta
capacidad da a los operadores de red un alto grado de protección contra información
de encaminamiento que puede ser no deseada, y así controlar la información de
encaminamiento según sus necesidades particulares. (Telecommunications Policy,
2014)
Funcionamiento BGP
BGP usa TCP como el protocolo de transporte en el puerto 179. Dos routers
BGP forman una conexión TCP entre sí. Estos routers son routers pares, que
intercambian mensajes para abrir y confirmar los parámetros de conexión. (Cisco,
2008)
Los routers BGP intercambian información de accesibilidad de la red. Esta
información es, básicamente, una indicación de los trayectos completos que debe
tomar un router para alcanzar la red de destino. Los trayectos son números de AS
BGP. Esta información ayuda a crear un gráfico de los AS sin bucles. El gráfico
muestra también dónde deben aplicarse las políticas de enrutamiento para imponer
algunas restricciones en el comportamiento del enrutamiento. (Cisco, 2008)
Dos routers cualquiera que formen una conexión TCP para intercambiar
información de enrutamiento BGP son “pares” o “vecinos”. Los pares BGP
intercambian inicialmente las tablas completas de enrutamiento BGP. Tras este
intercambio, envían actualizaciones incrementales a medida que cambia la tabla de
enrutamiento. BGP conserva un número de versión de la tabla BGP. El número de
versión es el mismo para todos los pares BGP y se modifica cada vez que BGP
actualiza la tabla con los cambios en la información de enrutamiento. El envío de
paquetes de señal de mantenimiento garantiza que la conexión entre los pares BGP
se mantenga activa. Los paquetes de notificación se generan en respuesta a errores
o condiciones especiales. (Cisco, 2008)
CAPÍTULO 4. MÉTODOS Y MECANISMOS DE INTEGRACION IPV6
53
4.1 TIPOS DE MECANISMOS PARA LA TRANSICIÓN DE IPV4 A IPV6
Para la transición de IPv4 a IPv6, el primer punto a tener en cuenta es que la
dificultad de dicha transición, radica en el hecho de que ambos protocolos son
incompatibles entre sí. Esta incompatibilidad fue una decisión de proyecto. Durante
la década de 1990, en algún momento del proceso de creación de la nueva
generación del protocolo de Internet, se pensó en el desarrollo de un protocolo no
compatible que permitiría incorporar características importantes. Las ventajas
asociadas con estas características compensarían una potencial de mayor dificultad
en la transición. Con técnicas que ayudaban a conservar los recursos IPv4, tales
como CIDR (Classless Inter-Domain Routing), NAT (Network Address Translation)
y DHCP (Dynamic Host Configuration Protocol) y el uso de direccionamiento
privado, de tal forma se creyó que esta transición podría darse en el correr de
muchos años y se desarrollo una solución muy sencilla desde el punto de vista
técnico. (Moreiras 2014)
La solución planeada para la transición de IPv4 a IPv6 fue mediante el uso
de la doble pila. El protocolo IPv4 se seguiría usando normalmente hasta agotarse
las IP’s y, paulatinamente, en cada componente de Internet se iría desplegando
IPv6. De tal forma que esto tendría lugar a lo largo de una década, quizás dos.
Ciertamente, en algún punto antes del agotamiento de IPv4, el protocolo IPv6
estaría presente en todos los elementos de la red. Así, IPv4 se volvería innecesario
y poco después este protocolo seria un protocolo en el olvido. (Moreiras, 2014)
Aquí podemos adelantar que este plan no funcionó. Incluso considerando
este contexto original en el cual se pensaba que IPv6 se implementaría en toda
Internet mientras todavía hubiera suficientes direcciones IPv4 disponibles, de todos
modos seria necesario utilizar técnicas de transición auxiliares. Estas técnicas son
las que aquí se clasifican como tradicionales. Básicamente, estas técnicas
54
intentaban resolver un problema: interconectar redes IPv6 utilizando túneles sobre
una red que es predominantemente IPv4.
Es importante resaltar que la idea de que la transición de IPv4 a IPv6 seria
gradual y de que ambos protocolos convivirían en las redes por muchos años, como
se concibió en este contexto, que al día de hoy ha perdido validez. Se podría
argumentar que en realidad, IPv6 se viene implementado desde hace años y que
esta convivencia entre ambos protocolos ya lleva varias décadas. Sin embargo,
dicho argumento entra en duda, ya que en muchos aspectos el desarrollo de IPv6
todavía puede considerarse como algo no normal. Lo importante es comprender
que, hoy en día, la expectativa es que la transición de Internet a IPv6 se haga
rápidamente. (Moreiras, 2014)
El plan original era técnicamente sencillo y elegante, pero este plan fracasó
porque no se previeron las consecuencias administrativas y financieras de la
implementación de IPv6, pues se tenían que si no solo configurar los aparatos, se
tenían que comprar nuevos. Para la mayor parte de las corporaciones involucradas,
IPv6 se podía considerar una tecnología que solo traería beneficios a largo plazo,
por lo que su implementación no requería nuevas inversiones y recursos de forma
inmediata. Por otra parte, tampoco había problema en hacerlo aun lado por un
tiempo, hasta que el agotamiento de IPv4 fuera inminente. Así, la mayoría de las
empresas pospuso la implementación del nuevo protocolo hasta el punto donde se
pudo. Se llegó entonces al limite en que ya no era posible implementar IPv6 en toda
internet por el agotamiento de las direcciones IPv4.
La realidad actual es de que las direcciones libres de IPv4 o bien ya se
agotaron o bien están extremadamente próximas a agotarse. Sin embargo, en
términos generales, todavía no se ha implementado IPv6 en todo su esplendor. En
este nuevo emprendimiento, los proveedores de acceso necesitan conectar a los
usuarios usando IPv6, pero también deben proporcionarles una dirección IPv4,
utilizando alguna técnica de uso compartido. Proveer conectividad IPv4 es
55
importante para permitir la comunicación con aquellas partes de Internet que todavía
no han migrado a IPv6. Para resolver este desafío se desarrollaron nuevas
tecnologías. En este trabajo, a estas técnicas de transición se les denomina nuevas.
4.1.1 TÚNELES ESTÁTICOS 6IN4
Dentro de estos es posible encapsular paquetes IPv6 directamente dentro de
paquetes IPv4, en forma de payload. En este caso, en el campo de protocolo del
encabezado IPv4 se especifica el valor 41 (29 en hexadecimal). Este tipo de
encapsulamiento se describe en la RFC 4213 y se conoce como 6in4, o IPv6-in-
IPv4. Popularmente también se le suele llamar “Protocolo 41”. (Moreiras, 2014)
En sí, el encapsulamiento es muy simple pero, al encapsular un paquete IPv6
dentro de un paquete IPv4, es necesario considerar algunos temas de mayor
complejidad. Por ejemplo, podría no haber espacio suficiente para el paquete y
quizás haya que fragmentarlo, o devolver un mensaje de “packet too big” a quien lo
originó. También hay que convertir los errores ICMPv4 que ocurren a lo largo del
camino en errores ICMPv6. (Moreiras, 2014)
Los túneles 6in4 se pueden configurar manualmente. Esta configuración
básicamente consiste en definir las direcciones IPv4 de origen y destino utilizadas
en cada extremo del túnel.
Los túneles IPv6 estáticos se configuran manualmente y son útiles en
diferentes situaciones. Por ejemplo, se pueden utilizar para evitar un equipo o
enlace que no soporta IPv6 en una determinada red. También se pueden usar para
interconectar dos redes IPv6 por medio de la Internet IPv4. La figura 11 se ilustra el
uso de un túnel 6in4.
56
Figura 11 Túnel 6IN4(Moreiras, 2014)
Es importante resaltar que el encapsulamiento 6in4 también se puede utilizar
en otras técnicas que involucran túneles automáticos. Vale la pena decir que
también existe el encapsulamiento equivalente por inverso “4in6” y que este tipo de
encapsulamiento se utiliza en varias técnicas nuevas, las cuales se verán mas
adelante. En sí, todos los tipos de routers y sistemas operativos, soportan túneles
estáticos 6in4. (Moreiras, 2014)
4.1.2 TÚNELES ESTÁTICOS GRE
GRE (Generic Routing Encapsulation) es un tipo de encapsulamiento genérico
definido en la RFC 2784, luego actualizada por la RFC 2890. GRE tiene un
encabezado propio y puede transportar diferentes tipos de protocolos. También
puede ser transportado en varios tipos de protocolos.
57
Para encapsular paquetes IPv6 en IPv4, primero se agrega el encabezado
GRE. Luego se agrega el encabezado IPv4 y en el campo de protocolo se especifica
el valor 47 (2F en hexadecimal), indicando que se está transportando IPv4 como
payload de GRE.
El túnel GRE también se configura estáticamente, de manera muy semejante
a un túnel 6in4. Prácticamente todos los routers y sistemas operativos soportan esta
tecnología. Una ventaja del túnel GRE en relación con el 6in4 es que el primero
puede transportar diferentes protocolos simultáneamente, mientras que el segundo
solo transporta IPv6. Por ejemplo, con GRE se puede crear un túnel para transportar
simultáneamente IPv6 y CLNS, el protocolo usado por el ISIS. La desventaja
bastante obvia es que el overhead es mayor. La figura 12 ilustra el uso de un túnel
GRE. (Moreiras, 2014)
Figura 12 Túnel GRE (Moreiras, 2014)
58
El uso para estos túneles estáticos tanto 6in4 y GRE son muy similares.
Escoger entre ambos es simple. Si IPv6 es el único protocolo que se debe
transportar en el túnel, el encapsulamiento 6in4 es una mejor opción. Si es
necesario transportar otros protocolos, como por ejemplo CLNS (Servicio de red sin
conexión), entonces se debe utilizar GRE. (Moreiras, 2014)
4.1.3 TUNNEL BROKERS
Los Tunnel Brokers pueden ser considerados como proveedores de acceso IPv6
virtuales. Este mecanismo está documentado en la RFC 3053. Fue creado a
comienzos de la década del 2000, época en la que la oferta de conectividad IPv6
nativa era todavía muy pequeña, y su objetivo era ofrecer a todos los interesados
una alternativa de conexión estable y persistente, por medio de túneles.
Los Tunnel Brokers funcionan de la siguiente manera. Generalmente hay un
sitio web donde el interesado crea una cuenta y solicita el servicio. En algunos
casos, el proceso de aprobación es manual;; en otros, automático. Una vez aprobada
la prestación del servicio de túnel, el proveedor lo configura en un servidor de
túneles. Luego se envían las instrucciones para que el usuario pueda configurar su
extremo del túnel. El túnel queda establecido cuando el usuario lo configura
correctamente en su red y, a partir de ese momento, puede proveer conectividad
IPv6 sobre la Internet IPv4. (Moreiras, 2014)
Existen diferentes tecnologías que se pueden utilizar para establecer estos
túneles. Por ejemplo, encapsulamiento 6in4, encapsulamiento UDP, el protocolo
AYIYA (Anything on Anything), el TSP (Tunnel Setup Protocol, descrito en la RFC
5572). Esta tecnología se ilustra en la figura 13.
59
Figura 13 Túnel Broker (Moreiras, 2014)
Por el año 2013, aún existían diferentes opciones de Tunnel Brokers, algunos
tenían de objetivo, ofrecer conectividad a usuarios finales, locales y corporativos.
Utilizar un Tunnel Broker puede ser una opción para los operadores de red que
están comenzando a implementar el protocolo pero que todavía no cuentan con
transito IPv6 nativo en la localidad donde operan. Se recomienda utilizar este
mecanismo solo a modo de prueba, como parte del proceso de transición.
4.1.4 6PE y 6VPE
Actualmente, el uso de MPLS sobre IPv4 está bastante difundido en las redes. 6PE
y 6VPE son dos tecnologías que permiten implementar IPv6 sin alterar el núcleo
MPLS de la red. Además de la nueva configuración, solo es necesario actualizar el
software de los routers de borde, conocidos como PE (Provider Edge), si es que no
soportan esta funcionalidad. (Moreiras 2014)
60
Las técnicas 6PE y 6VPE se describen, respectivamente, en las RFC 4798 y
4659. La comunicación se logra utilizando LSP (Label Switch Paths) a través del
núcleo MPLS. Ambas técnicas utilizan MP-BGP (Multiprotocol BGP) sobre IPv4 para
intercambiar rutas IPv6. Los routers PE deben ser doble pila. Los routers del núcleo
MPLS no se dan cuenta que están transportando paquetes IPv6, dado que solo
consideran los encabezados MPLS.
En 6PE solamente se mantiene una tabla de enrutamiento, por lo que la
técnica es más adecuada para brindar el servicio de Internet. En 6VPE se pueden
mantener diferentes tablas de enrutamiento independientes, separadas
lógicamente. Por lo tanto, esta técnica es más apropiada para brindar servicios de
VPN (Virtual Private Network). La figura 14 ilustra ambas técnicas.
Figura 14 6PE y 6VPE (Moreiras, 2014)
61
4.1.5 TÚNELES AUTOMÁTICOS 6TO4
Esta técnica tiene tres elementos principales: los clientes 6to4, los routers 6to4 y los
relays 6to4. Los clientes son las computadoras conectadas a una red que utilizan
este tipo de túnel para obtener conectividad IPv6. Se trata de clientes IPv6
convencionales. Un router 6to4 es aquel que en la red del cliente actúa como
extremo del túnel y, por lo tanto, debe tener una dirección IPv4 válida. A partir de
allí, utilizando el prefijo 2002::/16 más los 32 bits de la dirección IPv4, se forma un
prefijo IPv6 /48 para ser utilizado en la red. El otro extremo del túnel lo proveen los
relays 6to4, que son routers con conectividad nativa IPv4 e IPv6. Muchas redes
ofrecen el servicio de relay 6to4 colaborativamente en Internet, utilizando para la
conectividad IPv4 la dirección anycast 192.88.99.1. En la Internet IPv6, estos relays
se anuncian como routers para el prefijo 2002::/16. El mecanismo 6to4 se describe
dentro de la RFC 3056. (Moreiras, 2014)
Los paquetes IPv6 se encapsulan utilizando 6in4. El router encuentra el relay
más cercano enviando el paquete a la dirección IPv4 anycast. El relay desencapsula
el paquete y lo envía a su destino en la Internet IPv6. El destino enruta la respuesta
al relay más próximo, que es el router para 2002::/16. Este encapsula nuevamente
el paquete y lo envía al router cuya dirección IPv4 forma parte de la dirección IPv6
de destino. (Moreiras, 2014)
Los túneles no son necesariamente simétricos, también se puede utilizar
direcciones unicast y configurar los routers manualmente para especificar relays
6to4. De todas maneras, desde el punto de vista del usuario es imposible controlar
el camino inverso. Para un proveedor de servicios o de contenido que opera en
doble pila podría ser ventajoso contar con un relay 6to4, no anunciado
públicamente, exclusivamente para responder a consultas provenientes de clientes
6to4 y así garantizar el encapsulamiento del paquete en su origen. Esta técnica se
ilustra en la figura 15.
62
Figura 15 6IN4 (Moreiras, 2014)
6to4 es afectado por diferentes problemas. Los relays son públicos y no hay
garantía de que ofrezcan un servicio de calidad. Tampoco de que no sufrirán
problemas de seguridad. Varios sistemas operativos soportan túneles automáticos
6to4, en particular, Windows XP, Windows Vista y Windows 7. En estos sistemas,
una vez que se obtiene una dirección IPv4 válida, la computadora pasa a actuar
como cliente y router 6to4, sin que sea necesaria ninguna intervención por parte del
usuario. En las redes empresariales generalmente esto no es deseable porque,
inadvertidamente, los túneles podrían saltear ciertas medidas de seguridad tales
63
como firewalls. Además, con estos túneles la conectividad con ciertos sitios y
servicios de Internet que ya operan en doble pila puede tener una calidad inferior a
la que puede lograrse con IPv4 o IPv6 nativos. Por lo tanto, en estas redes es
aconsejable bloquear el uso del “protocolo 41”, evitando así que los usuarios utilicen
túneles automáticos. También es aconsejable deshabilitar esta funcionalidad en los
sistemas operativos de las computadoras. 6to4 es una técnica de transición que
tuvo un papel histórico importante, pero que actualmente tiene poca utilidad.
4.1.6 TÚNELES 6RD
La técnica conocida como 6rd (IPv6 rapid deployment) es una extensión de 6to4
que resuelve los problemas de asimetría y de falta de control sobre los relays
utilizados. Así como 6PE y 6VPE permiten que un operador de red implemente IPv6
sin modificar su núcleo basado en MPLS IPv4, 6rd permite utilizar la infraestructura
de red de acceso IPv4 sin modificaciones para realizar una implementación rápida
de IPv6 hasta el usuario final. (Moreiras, 2014)
Esta técnica se describe en la RFC 5569. Tiene dos elementos principales:
el equipo local del cliente (CPE) 6rd y el relay 6rd. El CPE 6rd funciona de manera
similar a un router 6to4, pero el prefijo utilizado es el del bloque de direcciones del
proveedor de acceso. Normalmente se utiliza un prefijo de 32 bits, aunque también
se puede escoger otro largo de prefijo. El relay 6rd se aloja en la red del proveedor
y tiene conectividad nativa IPv6 e IPv4. El encapsulamiento es 6in4. Esta técnica se
ilustra en la figura 16. (Moreiras, 2014)
6rd no resuelve el problema de la escasez de direcciones IPv4, por lo que
esta técnica solo se puede utilizar cuando hay direcciones disponibles.
Teóricamente, seria posible utilizarla junto con algún tipo de mecanismo para
compartir direcciones IP en el proveedor, aunque esto no es para nada aconsejable
ya que complicaría excesivamente la red.
64
Figura 16 Túnel automático 6RD (Moreiras, 2014)
4.1.7 TEREDO
Teredo es un mecanismo bastante similar a 6to4. Este mecanismo se describe en
la RFC 4380 y se incluyó aquí para que los administradores de red sean conscientes
de los problemas relacionados con su uso. Actualmente es de poca utilidad práctica.
El prefijo utilizado para los clientes es 2001:0000::/32. Con Teredo se conecta
un único cliente, no toda una red. Para el encapsulamiento se utiliza UDP para que
los túneles funcionen también en redes con NAT. Además de relays similares a los
que se utilizan con 6to4, también existen servidores que ayudan a descubrir el tipo
de NAT utilizado por la red del usuario y a iniciar la comunicación. (Moreiras 2014)
Los problemas para las redes corporativas son similares a los que se
describieron para 6to4. Por ello es conveniente bloquear activamente el uso de esta
técnica, lo que se puede lograr deshabilitándola en los sistemas operativos o bien
bloqueando en la red el trafico de salida al puerto UDP 3544. (Moreiras 2014)
65
4.2 NUEVAS TÉCNICAS DE TRANSICIÓN
Los mecanismos que aquí se describen son los más apropiados para su utilización
por parte de los proveedores de acceso a Internet en un contexto donde el
agotamiento de IPv4 es ya una realidad. Permiten conectar a los usuarios con IPv6
nativo, ofreciéndoles también una conexión parcial a IPv4 por medio de algún
mecanismo que permita compartir estas direcciones en la red del proveedor. Aquí
describiremos NAT64 y DNS64, 464XLAT, MAP, DS-Lite y NAT444. (Moreiras
2014)
4.2.1 NAT444
Esta técnica también se conoce como CGNAT (Carrier Grade NAT). Cualquier
técnica que utilice traducción de direcciones en la red del proveedor de acceso
puede ser considerada una CGNAT. Consideramos que el nombre NAT444 es más
preciso y especifico y es por ello que se lo utiliza en este trabajo. (Moreiras 2014)
Se trata de la primera de las tecnologías descritas en esta sección que se
aplica al problema de conectar un usuario a Internet utilizando IPv6 e IPv4 cuando
ya no hay más direcciones IPv4 libres disponibles. Es importante tener en cuenta
que no por ello se debe considerar la más importante ni la más recomendada. En
muchos casos es justamente lo contrario. (Moreiras 2014)
Sin embargo, con fines didácticos, es importante presentarla en primer lugar
porque es la que a muchos les parece más familiar. Su componente básico es la
traducción NAT44, ampliamente utilizada hoy en día en las redes de los usuarios
finales. Luego se podrán discutir algunos problemas comunes a todas las demás
técnicas que involucran el uso compartido de direcciones, lo que facilitará la
comprensión de las demás. Además, es un hecho que muchos proveedores han
escogido esta técnica y que muchos fabricantes la han recomendado. Esto se da,
66
en algunos casos, por desconocimiento de las alternativas y por desconocimiento
de los problemas que son exclusivos del uso de la doble traducción stateful.
Figura 17 NAT4444 (Moreiras, 2014)
La figura 17 ilustra como funciona el NAT444. Se puede ver que este
mecanismo consiste en aplicar dos traducciones de direcciones y puertos de IPv4
a IPv4. Una de ellas se da en la red del usuario, algo muy común desde la década
de 1990, mientras que la novedad de esta técnica es que la segunda traducción se
da en el proveedor de acceso. Hay tres bloques de direcciones IPv4 involucrados:
las direcciones validas en Internet, las direcciones privadas utilizadas en la red del
usuario, y las direcciones privadas utilizadas en la red del proveedor. Nótese que
las direcciones utilizadas en la red del usuario son las que se definen en la RFC
1918 y son muy conocidas. La IANA reservó un nuevo bloque para su utilización
exclusiva en la red del proveedor con el objetivo de compartir direcciones, el bloque
100.64.0.0/10. Su uso se describe en la RFC 6598. (Moreiras, 2014)
El uso de NAT444 en la red del usuario es una necesidad que surgió en los
últimos años para preservar las direcciones IPv4 libres, pero que rompe la
conectividad extremo a extremo en Internet. Esta propiedad de la red, que permite
67
que cualquier dispositivo inicie la comunicación con cualquier otro, es uno de los
factores clave de su éxito. Es de gran importancia, principalmente para garantizar
la libre creación de nuevas aplicaciones y la innovación. Cuando se usa NAT, los
dispositivos que reciben direcciones privadas no pueden ser alcanzados
directamente por otros dispositivos en la Internet. (Moreiras, 2014)
Aunque la traducción rompe la conectividad de extremo a extremo, se han
desarrollado algunas soluciones paliativas para sortear esta dificultad en las redes
de los usuarios finales. El usuario puede configurar manualmente un mapeo de
puertos en el router. El software de la red privada puede utilizar uPNP, un protocolo
que permite el mapeo automático.
Para que en un escenario de uso compartido de direcciones IP la
identificación sea posible, es necesario que tanto el proveedor del servicio y del
contenido como el proveedor de acceso conserven un conjunto de datos
adicionales: los puertos de origen de las conexiones. Este problema es común tanto
para NAT444 como para las demás técnicas de uso compartido de direcciones IPv4.
Pero es más grave en el caso del NAT444, ya que este mecanismo no requiere que
el usuario tenga conectividad IPv6 y, por lo tanto, no garantiza que el trafico vaya
migrando a IPv6 a medida que los proveedores de servicios y contenidos pasan a
utilizar el nuevo protocolo.
El principal problema de la técnica NAT444 es justamente el no exigir la
implementación de IPv6. Las demás técnicas necesitan de IPv6 para funcionar. Esto
favorece la migración del trafico en la red del proveedor hacia el nuevo protocolo, a
medida que los contenidos, servicios y demás usuarios de Internet pasan a utilizarlo.
El uso aislado de NAT444 es, por lo tanto, una pésima idea. Primero, porque cambia
drásticamente la manera en la que funciona Internet, rompiendo principios que hasta
hoy fueron importantes para su éxito, como ser la simplicidad del núcleo de la red y
la conectividad extremo a extremo. Segundo, porque NAT444 es una solución
stateful, que tiene elevados costos computacionales y financieros. Si el trafico no
68
migra gradualmente a IPv6, para el proveedor, el costo de la inversión continuada
en la solución de NAT444 tiende a aumentar con el tiempo y, de hecho, tiende a
superar el costo de la migración a IPv6. El uso de NAT444 junto con la
implementación de IPv6 soluciona este problema, al menos parcialmente.
(Moreiras, 2014)
4.2.2 NAT64 Y DNS64
El mecanismo NAT64 se define en la RFC 6146. Es una técnica stateful para
traducción de paquetes y puertos IPv6 a IPv4. Permite, simultáneamente, el uso
compartido de direcciones IPv4. El DNS64 se define en la RFC 6147 y es una
técnica auxiliar de mapeo para nombres de dominio, que se utiliza en conjunto con
NAT64. (Moreiras, 2014)
Con NAT64 y DNS64 es posible que los usuarios reciban únicamente
direcciones IPv6 de parte del proveedor y que incluso así puedan acceder a
dispositivos IPv4 en Internet. Para el software de la computadora del usuario, parece
que todos los sitios y servicios en Internet fueran IPv6. Para el sitio o servicio en
Internet, es como que todas las conexiones se originasen en un usuario IPv4 con
una IP compartida. El mecanismo se ilustra en la siguiente figura 18.
Las direcciones IPv4 de Internet se mapean en prefijo IPv6 predefinido de
tamaño 96 en la red del proveedor de acceso. Se puede utilizar cualquier prefijo del
propio proveedor, aunque hay un bloque de direcciones reservado exclusivamente
para este fin: el 64:ff9b::/96. Este bloque se definió en la RFC 6052. Por ejemplo, la
dirección IPv4 203.0.113.1 en Internet se traduciría y mapearía a la dirección IPv6
64:ff9b::203.0.113.1 en la red del proveedor. (Moreiras 2014)
Es importante notar que el usuario está conectado de forma nativa a Internet
vía IPv6, por lo que puede acceder a los sitios y otros servicios IPv6 directamente,
sin necesidad de utilizar ninguna técnica de traducción. Cuando es necesario
69
acceder a algún recurso IPv4 en Internet, el primer paso que se realiza es una
consulta al DNS. DNS64 funciona como un recursivo común, pero en caso de que
el nombre consultado no tenga originalmente un registro, este registro se agrega a
la respuesta, utilizando la misma regla de mapeo de direcciones definida para la
traducción NAT64. Si la respuesta original llegase solamente con el registro, no
habría más nada que hacer, ya que en la red del usuario solo hay conectividad IPv6.
Figura 18 NAT64 y DNS64 (Moreiras, 2014)
La principal desventaja del uso de NAT64 y DNS64 es el hecho de que
todavía existen aplicaciones que simplemente no soportan IPv6. En el momento de
escribir este texto a mediados de 2013, estas aplicaciones eran pocas pero
significativas. Si la aplicación en sí, en la computadora o en el dispositivo del
usuario, no puede trabajar con IPv6, de nada sir- ve la traducción. Este problema
puede hacer inviable la implementación inmediata de esta técnica, aunque es
probable que deje de existir en un plazo relativamente corto. (Moreiras 2014)
Este mecanismo tiene una particularidad interesante que tal vez lo convierta
en la mejor opción en términos generales si consideramos la transición a IPv6 como
un todo. Es el único donde los usuarios utilizan solamente IPv6. Esto significa que,
una vez que los sitios u otros servicios de Internet pasen a usar IPv6 y tengan un
registro en sus nombres de dominio, el trafico migrará automáticamente a IPv6. No
70
es este el caso cuando se utiliza NAT444, donde IPv6 no es un requerimiento, y
tampoco es el caso para los demás mecanismos de transición.
El uso de NAT64 y DNS64 es de particular interés para los proveedores
móviles que trabajan en redes 3G. En este escenario, en algunos casos por
limitaciones de licencias, limitaciones de los equipos de red o de los Smartphones
de los usuarios, solo se consigue conectividad IPv4 o IPv6, no ambas
simultáneamente. En este caso, la tecnología es la mejor solución disponible para
ofrecer conectividad IPv6 a los usuarios, permitiendo a la vez que accedan a
recursos de Internet IPv4. (Moreiras 2014)
Además de soporte para IPv6, el uso de NAT64 y DNS64 no requiere ninguna
funcionalidad especial en el CPE ni en la terminal del usuario. Se trata de una
técnica bastante madura que ofrecen diversos fabricantes de equipos de red.
También hay soluciones basadas en software libre. Esta técnica se recomienda
principalmente para los proveedores de Internet móvil.
4.2.3 464XLAT
La técnica 464XLAT se encuentra documentada en el RFC 6877, con fines prácticos
y se puede considerar como un complemento del mecanismo NATg4 descrito en el
punto anterior, esta técnica consiste en una combinación del uso de traducción
stateful entre IPv6 e IPv4 en la red del proveedor. Dicha técnica se desarrollo por la
limitación que se presentaba con NAT64 y DNS64 en relación con las aplicaciones
que no soportan IPv6. Agregando una segunda traducción es posible brindar a los
usuarios una dirección IPv4 privada, de forma que funcionen incluso las
aplicaciones que no soportan IPv6. Esta técnica se muestra a continuación en la
figura 19, la traducción stateful en el proveedor recibe el nombre PLAT (Provide-
side-Translator). En la red del usuario, la traducción Stateless se conoce como
CLAT (Customer-side-Translator). (Moreiras 2014)
71
Figura 19 464XLAT (Moreiras, 2014)
En 464XLAT no se utiliza DNS64. El CLAT aprende el prefijo utilizado por el
PLAT por medio de técnicas heurísticas o mediante otro tipo de configuración.
Preferentemente, se debería utilizar un prefijo IPv6 /64 especifico para el mapeo 1:1
que se realiza para las direcciones IPv4 privadas en la red del usuario.
El uso de 464XLAT se recomienda para los proveedores de Internet móvil,
en especial para aquellos que pretenden implementar IPv6 a corto plazo, siempre
que NAT64 y DNS64 no sean viables debido a problemas con las aplicaciones. O
incluso como alternativa para que la utilicen solamente los usuarios para los cuales
el no funcionamiento de ciertas aplicaciones realmente significa un problema. La
técnica también se puede utilizar en otros casos. (Moreiras, 2014)
72
4.2.4 DS-LITE
La técnica DS-Lite (Dual Stack Lite) se describe en la RFC 6233. Resuelve el
problema de forma similar a 464XLAT, aunque utiliza un túnel que encapsula IPv4
en IPv6 y no una doble traducción entre protocolos. Por lo tanto, el usuario se
conecta vía IPv6 en forma nativa y también recibe una dirección IPv4 privada.
DS-Lite también es una clase de CGNAT, es decir, depende de NAT44
stateful en el proveedor de acceso. En esta técnica, el equipo responsable por el
CGNAT recibe el nombre de AFTR (Address Family Transition Router). En la red
del usuario, el CPE recibe el nombre de B4 (Basic Bridge BroadBand) y actúa como
un bridge para el IPv4, en la terminación del túnel. La figura 20 muestra esta técnica.
(Moreiras, 2014)
Figura 20 DS-LITE (Moreiras, 2014)
El túnel y el CPE están en función de B4 (bridge), el AFTR tiene un puerto
conectado directamente en la red del usuario. El mismo ofrece la función de NAT
directamente para los dispositivos. No hay una doble traducción como ocurre con
NAT444, sino solamente una única traducción stateful en la red del proveedor.
73
Se aplican las mismas consideraciones que hicimos para NAT64 y 464XLAT.
Para posibilitar la identificación de los accesos vía IPv4 es necesario llevar un
registro de los puertos de origen de los usuarios. La técnica también rompe la
conectividad extremo a extremo y, por ser stateful, tiene un costo computacional
alto para el proveedor.
Su uso se recomienda para los proveedores de acceso a Internet en general, para
quienes ya están sufriendo el efecto del agotamiento de las direcciones IPv4 y
necesitan realizar una implementación de IPv6 en el corto plazo. (Moreiras 2014)
4.2.5 MAP
Desde una perspectiva de usuario, la técnica MAP (Mapping of Addressing and Port)
es muy similar a DS-Lite o 464XLAT. El usuario está conectado nativamente vía
IPv6 y vía IPv4 utilizando una dirección IPv4 privada. (Moreiras 2014)
Existen dos versiones de esta técnica: MAP-T (Traducción), que utiliza una
doble traducción stateless entre IPv4 e IPv6 de forma similar a lo que hace
464XLAT, y MAP-E (Encapsulamiento), que utiliza un túnel para encapsular IPv4 en
IPv6 de forma similar a lo que se hace en DS-Lite. En MAP, el router responsable
por compartir las direcciones IP en el proveedor recibe el nombre de MAP Border
Relay. (Moreiras 2014)
En la red del usuario, el equipo local del cliente, recibe el nombre de MAP CE
(Equipo del Cliente). En las figuras 21 y 22 se ilustran ambas versiones, MAP-T y
MAP-E. (Moreiras 2014)
74
Figura 21 MAP-T (Moreiras, 2014)
Figura 22 MAT-E (Moreiras, 2014)
75
La diferencia entre MAP y las demás técnicas, es que MAP no utiliza NAT en
la red del proveedor de acceso. El uso compartido de las direcciones IPv4 se realiza
por medio de la técnica A+P (dirección mas puerto), descrita en la RFC 6346.
A+P es un tipo de repartición de dirección IPv4 de manera stateless. Una
misma dirección válida se atribuye a varios usuarios diferentes, pero cada usuario
solo puede utilizar un rango restringido de puertos. Con MAP, el CPE recibe una
dirección IPv4 válida junto con información sobre cual rango de puertos de origen
puede utilizar. Destacable decir que el mapeo de A+P es realizado por un algoritmo.
Esto significa que, desde el punto de vista computacional, es mucho más liviano
que NAT44. Para el proveedor, es potencialmente más barato y más escalable que
cualquier otra de las técnicas aquí presentadas. (Moreiras, 2014)
Otro punto clave a destacar es que el CPE recibe una dirección IPv4 válida.
Una dirección IPv4 con restricción de rango de puertos utilizables, pero válida. Esto
significa que las técnicas que actualmente se utilizan para evitar la rotura de la
conectividad extremo a extremo que ocasiona el uso de NAT44 en la red del usuario
también funcionarían con MAP, por lo que seria posible utilizar mapeo manual de
puertos, o mapeo automático vía uPnp o incluso STUN. Por todo lo anterior, MAP
es el mecanismo de transición que potencial- mente implica menos problemas
operativos, tanto para el proveedor de acceso como para los usuarios. En el
momento de escribir este texto a mediados de 2013, MAP todavía no se había
estandarizado en una RFC.
4.2.6 CONTEMPLACIÓN SOBRE LAS NUEVAS TÉCNICAS DE TRANSICIÓN
Es importante mencionar que, para los proveedores que aun no han tenido
agotamiento de IPv4, la doble pila con IPv4 e IPv6 nativos, continua siendo una
buena opción para la transición, siendo que en un escenario de agotamiento de
76
direcciones IPv4 a nivel mundial, algunos proveedores de acceso podrían no verse
afectados por tener muy poco crecimiento en su base de usuarios. En otros casos,
esto puede deberse por algunos tipos de servicios. Poniendo un ejemplo claro
desde el punto de vista del proveedor, podría tener una base de datos de usuarios
corporativos que crece muy lentamente y tora base de usuarios residenciales con
un crecimiento demasiado rápido. En dicho caso, se podría llevar a cabo una doble
pila, con IPv6 e IPv4 nativos, para la base de usuarios corporativos y escoger una
de las técnicas que vistas con anterioridad, para los usuarios residenciales.
(Moreiras, 2014)
Por otra parte, conviene también considerar que el uso de MAP, DS-Lite,
464XLAT o NAT64, tiene la ventaja de que toda la red de acceso del proveedor
pasa a ser solamente IPv6. Con esto se puede ayudar a reducir la carga de routers,
la cantidad de problemas y los costos operativos. Dicho lo anterior, se puede decir
que con esto, se inicia la desactivación y uso de IPv4 en las redes. De esta forma,
se puede estudiar la posibilidad de implementar técnicas incluso en situaciones en
la que el uso compartido de IPv4 no sea todavía absolutamente necesario.
(Moreiras, 2014)
CAPÍTULO 5. SIMULACIÓN DE IPV4 EN SISTEMAS DE DIFERENTES INFRAESTRUCTURAS
78
Se pretende realizar una simulación de una red IPv4 e IPv6 con el fin de que ambos
protocolos, se comuniquen entre si. Dicha conexión se realizara con routers Cisco
y usando protocolos de enrutamiento RIP y OSPF, de modo que las rutas se
propaguen mediante RIP y hacia OSPF y viceversa. El IOS Cisco a utilizar será, el
7200. Cabe mencionar que dichos routers estarán conectados mediante puerto
serial y que IPv4 trabajara mediante el protocolo RIP e IPv4 por medio de OSPF.
5.1 SIMULACIÓN DE UNA RED IPV4 RIP
Se llevara acabo la simulacion de IPv4 con protocolo RIP, en la cual estan definidas
las direcciones y en los mismos routers estan configuracion con un temporizador
con el fin de ayudar en el proceso de comunicación. Se muestra la topología a
utilizar en la figura 23.
Figura 23 Red IPv4 con sus direcciones
79
En la siguiente tabla, se muestra las direcciones que tendra cada routers mediante
comunicación serial.
ROUTER SERIAL IP ROUTER 1 Serial 1/0 172.16.1.1
Serial 1/1 172.16.2.1 ROUTER 2 Serial 1/0 172.16.1.2
Serial 1/1 172.16.3.2 ROUTER 3 Serial 1/0 172.16.2.3
Serial 1/1 172.16.3.3 Serial 1/2 172.16.4.3 Serial 1/3 172.16.5.3
ROUTER 4 Serial 1/0 172.16.4.4 Serial 1/1 172.16.6.4
ROUTER 5 Serial 1/0 172.16.5.5 Serial 1/1 172.16.6.5
Tabla 1 Direcciones IPv4
Mediante los siguientes comandos, se comenzara a configurar router por
router. Si el router no esta en modo privilegiado, comenzamos por teclear Enable,
como se muestra a continuacíon. Cuando hemos pasado el router a modo
privilegiado, el nombre del router ya no aparecera con el simbolo de mayor que, si
no tendra el simbolo de gato “#”. R>enable R#
Despues de eso se configurara la terminal, en este caso del router. Se hara
con el comando configure terminal. R#configure terminal
Una vez tecleado el comando anterior, se estara dentro del router en su modo
configuración, en el cual se configurara que puerto o interfaz de este se usara, asi
mismo tambien la direccion IP que tendra. Al finalizar de configurar todo lo anterior,
se tecleara el comando no shutdown y despues de este comando exit. Este ultimo
es para salir de la configuracion del router y estar solamente en modo privilegiado.
Todo esto, se hara en los routers que se tendran en dicha red.
80
CONFIGURACION DE ROUTERS
ROUTER R1 CONFIGURACION PARA EL SERIAL 0/0 R1>enable
R1 #configure terminal
R1 (config)# interface serial 0/0
R1 (config-if)#ip address 172.16.1.1 255.255.255.0
R1 (config-if)#no shutdown
R1 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/0 Router (config)# interface serial 1/0
Router (config-if)#ip address 172.16.2.1 255.255.255.0
Router (config-if)#no shutdown
Router (config-if)#exit
ROUTER R2 CONFIGURACION PARA EL SERIAL 0/0 R2>enable
R2 #configure terminal
R2 (config)# interface serial 0/0
R2 (config-if)#ip address 172.16.1.2 255.255.255.0
R2 (config-if)#no shutdown
R2 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/0 R2 (config)# interface serial 1/0
R2 (config-if)#ip address 172.16.3.2 255.255.255.0
R2 (config-if)#no shutdown
R2 (config-if)#exit
81
ROUTER R3 CONFIGURACION PARA EL SERIAL 0/0 R3>enable
R3 #configure terminal
R3 (config)# interface serial 0/0
R3 (config-if)#ip address 172.16.2.3 255.255.255.0
R3 (config-if)#no shutdown
R3 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/0 R3 (config)# interface serial 1/0
R3 (config-if)#ip address 172.16.3.3 255.255.255.0
R3 (config-if)#no shutdown
R3 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/2 R3>enable
R3 #configure terminal
R3 (config)# interface serial 1/2
R3 (config-if)#ip address 172.16.4.3 255.255.255.0
R3 (config-if)#no shutdown
R3 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/3 R3 (config)# interface serial 1/3
R3 (config-if)#ip address 172.16.5.3 255.255.255.0
R3 (config-if)#no shutdown
R3 (config-if)#exit
ROTUER R4 CONFIGURACION PARA EL SERIAL 0/0 R4>enable
R4 #configure terminal
R4 (config)# interface serial 0/0
82
R4 (config-if)#ip address 172.16.4.4 255.255.255.0
R4 (config-if)#no shutdown
R4 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/0 R4 (config)# interface serial 1/0
R4 (config-if)#ip address 172.16.6.4 255.255.255.0
R4 (config-if)#no shutdown
R4 (config-if)#exit
ROUTER R5 CONFIGURACION PARA EL SERIAL 0/0 R5>enable
R5 #configure terminal
R5 (config)# interface serial 0/0
R5 (config-if)#ip address 172.16.5.5 255.255.255.0
R5 (config-if)#no shutdown
R5 (config-if)#exit
CONFIGURACION PARA EL SERIAL 1/0 R5 (config)# interface serial 1/0
R5 (config-if)#ip address 172.16.6.5 255.255.255.0
R5 (config-if)#no shutdown
R5 (config-if)#exit
Despues de todo lo anterior, se progaran las redes usando el protocolo de
enrutamiento RIP. Las redes o direcciones se colocaran con el comando network,
siendo las redes que estan adyacentes al router;; es decir, son las que estan
directament conectadas. El comando no auto-summary se implementara para que
las redes se propaguen tal como fueron configuradas y que por tanto no sumarise.
Si dicho comando no se encuentra presente, dado que se trabaja con redes
172.16.0.0/16, en lugar de propagar la red 172.16.1.0/24, estaria propagando la red
172.16.0.0/16, y esto no se conveniente para nuestro estudio.
83
CONFIGURACIÓN DE ROUTERS CON RIP
Los routers quedaran configuracion de la siguiente manera, siempre y
cuando se este en modo privilegiado y en el area de la configuracion de la terminalo
router.
ROUTER R1 R1(config)# router rip
R1(config-router)#network 172.16.1.0
R1(config-router)#network 172.16.2.0
R1(config-router)#no auto-summary
R1(config-router)#exit
ROUTER R2 R2(config)# router rip
R2(config-router)#network 172.16.1.0
R2(config-router)#network 172.16.3.0
R2(config-router)#no auto-summary
R2(config-router)#exit
ROUTER R3 R3 (config)# router rip
R3 (config-router)#network 172.16.2.0
R3 (config-router)#network 172.16.3.0
R3 (config-router)#network 172.16.4.0
R3 (config-router)#network 172.16.5.0
R3 (config-router)#no auto-summary
R3(config-router)#exit
ROUTER R4 R4(config)# router rip
84
R4(config-router)#network 172.16.4.0
R4(config-router)#network 172.16.6.0
R4(config-router)#no auto-summary
R4(config-router)#exit
ROUTER R5 R5(config)# router rip
R5(config-router)#network 172.16.5.0
R5(config-router)#network 172.16.6.0
R5(config-router)#no auto-summary
R5(config-router)#exit
Se puede observar la tabla de rutas de los routers con el siguiente comando:
show ip route. De tal forma que apareceran todas las rutas de la topología. Las rutas
propagadas por el protocolo seran reconocidas por la letra R. De tal forma se puede
comprobar si hay conectividad haciendo ping. Por ejemplo, R1#ping 172.16.5.5.
CONFIGURACIÓN DE TEMPORIZADORES
La configuración de temporizadores es de vital importancia, dado que un
enlace falle, se puede hacer que el proceso de convergencia sea mas rápido. Para
ello se utilizaran los timers. Los cuales se configuraran de la siguiente manera. Se
describen como timer basic update invalid holddown flush, donde:
Update por defecto son 30 segundos, define la frecuencia en que se deben enviar las actualizaciones al router vecino. Invalid es por defecto de 180 segundos, corresponde al tiempo que una ruta se almacenara en la tabla de enrutamiento
hasta que se considere invalida. Tal contador se resetea cada vez que recibe una
actualización. Holddown es utilizado para prevenir bucles. Por defecto es de 180 segundos. Flush define el tiempo que le toma al router eliminar una ruta de su tabla de enrutamiento desde que se declaró como invalida.
85
ROUTER R1 R1(config)#router rip
R1(config-router)#timer basic 20 30 10 40
ROUTER R2 R2(config)#router rip
R3(config-router)#timer basic 20 30 10 40
ROUTER R3 R3(config)#router rip
R3(config-router)#timer basic 20 30 10 40
ROUTER R4 R4(config)#router rip
R4(config-router)#timer basic 20 30 10 40
ROUTER R5 R5(config)#router rip
R5(config-router)#timer basic 20 30 10 40
Con todo lo anterior queda la red IPv4 configurada con el protocolo RIP. Existiendo
comunicación entre todos los routers conectados a esta.
5.2 SIMULACIÓN DE UNA RED IPV6 OSPF
Luego de configurar la red IPv4 con RIP, se vera la implementacion de una red IPv6
con OSPF, al igual que lo anterior, se usaran routers cisco modelo 7200. Se les
asignara las direcciones IP para los routers, se les configurara los timers para que
el proceso de convergencia sea más rápido en caso de un enlace caido. Sera el
mismo esquema que el anterior, mostrado en la siguiente imagen, figura 24.
86
Figura 24 Red IPv6 con sus direcciones
En la siguiente tabla se muestra las direcciones IPv6 de cada router, todo esto
mediante conexión serial.
ROUTER SERIAL IP ROUTER 1 Serial 1/0 2001:db8:1::1
Serial 1/1 2001:db8:2::1 ROUTER 2 Serial 1/0 2001:db8:1::2
Serial 1/1 2001:db8:3::2 ROUTER 3 Serial 1/0 2001:db8:2::3
Serial 1/1 2001:db8:3::3 Serial 1/2 2001:db8:4::3 Serial 1/3 2001:db8:5::3
ROUTER 4 Serial 1/0 2001:db8:4::4 Serial 1/1 2001:db8:6::4
ROUTER 5 Serial 1/0 2001:db8:5::5 Serial 1/1 2001:db8:6::5
Tabla 2 Direcciones IPv6
87
Lo primero que se debe realizar en cada router, es habilitar el ruteo para IPv6,
todo esto se hace con el comando ipv6 unicast-routing. Una vez hecho lo anterior,
podemos empezar a configurar las interfaces con sus respectivas direcciones IP.
Hay que tener encuenta que el proceso OSPF para IPv6, se debe hacer a nivel de
interfaz. El comando utilizado es, ipv6 ospf (el identificador) area (el numero de
area), donde identificador es el nombre o numero, con el que se podra identificar el
proceso;; area, se define como el área a la que se asociara la red.
Antes que todo, es necesario tener un identificador (ID) de proceso con la
forma A.B.C.D, para configurarlo es necesario ingresar al proceso OSPF a nivel
global, tal como se muestra a continuación.
Router(config)#ipv6 unicast-routing
Router(config)#ipv6 router ospf PROCESO
Router(config-rtr)#router-id ID_PROCESO
Router(config-rtr)#exit
Para evitar problemas o confuciones, los routers-id se colocaran según el número
de router. A continuación la configuracion de cada router.
ROUTER R1 R1(config)#ipv6 unicast-routing
R1(config)# ipv6 router ospf 1
R1(config-rtr)#router-id 1.1.1.1
R1(config-rtr)#exit
R1(config)#interface serial 1/0
R1(config-if)#ipv6 address 2001:db8:1::1/64
R1(config-if)#ipv6 ospf 1 area 0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface serial 1/1
88
R1(config-if)#ipv6 address 2001:db8:2::1/64
R1(config-if)#ipv6 ospf 1 area 0
R1(config-if)#no shutdown
R1(config-if)#exit
ROUTER R2 R2(config)#ipv6 unicast-routing
R2(config)# ipv6 router ospf 2
R2(config-rtr)#router-id 2.2.2.2
R2(config-rtr)#exit
R2(config)#interface serial 1/0
R2(config-if)#ipv6 address 2001:db8:1::2/64
R2(config-if)#ipv6 ospf 2 area 0
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#interface serial 1/1
R2(config-if)#ipv6 address 2001:db8:3::2/64
R2(config-if)#ipv6 ospf 2 area 0
R2(config-if)#no shutdown
R2(config-if)#exit
ROUTER R3 R3(config)#ipv6 unicast-routing
R3(config)# ipv6 router ospf 3
R3(config-rtr)#router-id 3.3.3.3
R3(config-rtr)#exit
R3(config)#interface serial 1/0
R3(config-if)#ipv6 address 2001:db8:2::3/64
R3(config-if)#ipv6 ospf 3 area 0
R3(config-if)#no shutdown
R3(config-if)#exit
89
R3(config)#interface serial 1/1
R3(config-if)#ipv6 address 2001:db8:3::3/64
R3(config-if)# ipv6 ospf 3 area 0
R3(config-if)#no shutdown
R3(config-if)#exit
R3(config)#interface serial 1/2
R3(config-if)#ipv6 address 2001:db8:4::3/64
R3(config-if)# ipv6 ospf 3 area 1
R3(config-if)#no shutdown
R3(config-if)#exit
R3(config)#interface serial 1/3
R3(config-if)#ipv6 address 2001:db8:5::3/64
R3(config-if)# ipv6 ospf 3 area 1
R3(config-if)#no shutdown
R3(config-if)#exit
ROUTER R4 R4(config)#ipv6 unicast-routing
R4(config)#ipv6 router ospf 4
R4config-rtr)#router-id 4.4.4.4
R4(config-rtr)#exit
R4(config)#interface serial 1/0
R4(config-if)#ipv6 address 2001:db8:4::4/64
R4(config-if)#ipv6 ospf 4 area 1
R4(config-if)#no shutdown
R4(config-if)#exit
R4(config)#interface serial 1/1
R4(config-if)#ipv6 address 2001:db8:6::4/64
R4(config-if)#ipv6 ospf 4 area 1
R4(config-if)#no shutdown
R4(config-if)#exit
90
ROUTER R5 R5(config)#ipv6 unicast-routing
R5(config)#ipv6 router ospf 5
R5(config-rtr)#router-id 5.5.5.5
R5(config-rtr)#exit
R5(config)#interface serial 1/0
R5(config-if)#ipv6 address 2001:db8:5::5/64
R5(config-if)#ipv6 ospf 5 area 1
R5(config-if)#no shutdown
R5(config-if)#exit
R5(config)#interface serial 1/1
R5(config-if)#ipv6 address 2001:db8:6::5/64
R5(config-if)#ipv6 ospf 5 area 1
R5(config-if)#no shutdown
R5(config-if)#exit
COFIGURACIÓN DE TEMPORIZADORES
Al igual que en IPv4, los temporizadores se configuran a nivel interfaz, esto
se hace en todos los routers que participan en la red, dichos temporizadores deben
ser configurados igual en todos los routers, el dead-interval debe ser siempre el
doble que hello-interval.
ROUTER R1 R1(config)#interface serial 1/0
R1(config-if)#ipv6 ospf hello-interval 100
R1(config-if)#ipv6 ospf dead-interval 200
R1(config)#interface serial 1/1
R1(config-if)#ipv6 ospf hello-interval 100
R1(config-if)#ipv6 ospf dead-interval 200
91
ROUTER R2 R2(config)#interface serial 1/0
R2(config-if)#ipv6 ospf hello-interval 100
R2(config-if)#ipv6 ospf dead-interval 200
R2(config)#interface serial 1/1
R2(config-if)#ipv6 ospf hello-interval 100
R2(config-if)#ipv6 ospf dead-interval 200
ROUTER R3 R3(config)#interface serial 1/0
R3(config-if)#ipv6 ospf hello-interval 100
R3(config-if)#ipv6 ospf dead-interval 200
R3(config)#interface serial 1/1
R3(config-if)#ipv6 ospf hello-interval 100
R3(config-if)#ipv6 ospf dead-interval 200
R3(config)#interface serial 1/2
R3(config-if)#ipv6 ospf hello-interval 100
R3(config-if)#ipv6 ospf dead-interval 200
R3(config)#interface serial 1/3
R3(config-if)#ipv6 ospf hello-interval 100
R3(config-if)#ipv6 ospf dead-interval 200
ROUTER R4 R4(config)#interface serial 1/0
R4(config-if)#ipv6 ospf hello-interval 100
R4(config-if)#ipv6 ospf dead-interval 200
R4(config)#interface serial 1/1
R4(config-if)#ipv6 ospf hello-interval 100
R4(config-if)#ipv6 ospf dead-interval 200
92
ROUTER R5 R5(config)#interface serial 1/0
R5(config-if)#ipv6 ospf hello-interval 100
R5(config-if)#ipv6 ospf dead-interval 200
R5(config)#interface serial 1/1
R5(config-if)#ipv6 ospf hello-interval 100
R5(config-if)#ipv6 ospf dead-interval 200
Con lo realizado con anterioridad, se puede dar por terminada la
configuracion de una red IPv6 mediante el protocolo OSPF. Se puede observar con
el comando show ipv6 route, las rutas que tienen configuradas cada router, y se
puede hacer un ping desde cualquier router de la siguiente manera, ping
2001:db8:5::5, donde los ultimos dos digitos que son 5, se puede cambiar por
cualquier otro que numero con el cual se alla configurado alguno de los routers.
5.3 SIMULACIÓN DE UNA RED IPV4 E IPV6 OSPF Y RIP
Se creara una red IPv4 con IPv6 en donde los dos protocolos, se comuniquen entre
si y funcionen como 1 solo, independientemente de que uno tendra un tipo de IP y
el otro estara bajo otro tipo. Se usaran routers Cisco modelo 7200, y los protocolos
de enrutamiento RIP y OSPF de modo que las rutas que se propagan mediante RIP
se comuniquen con las OSPF y viceversa. IPv4 estara bajo el protocolo RIP y IPv6
estara mediante OSPF. En la siguiente tabla se muestra el direccionamiento, asi
mismo en la figura 25 podemos ver la red con sus diferentes direcciones.
93
ROUTER SERIAL IPV4 IPV6 R1 Serial 1/0 172.16.1.1 2001:db8:1::1
Serial 1/1 172.16.2.1 2001:db8:2::1 R2 Serial 1/0 172.16.1.2 2001:db8:1::2
Serial 1/1 172.16.3.2 2001:db8:3::2 R3 Serial 1/0 172.16.2.3 2001:db8:2::3
Serial 1/1 172.16.3.3 2001:db8:3::3 Serial 1/2 172.16.4.3 2001:db8:4::3 Serial 1/3 172.16.5.3 2001:db8:5::3
R4 Serial 1/0 172.16.4.4 2001:db8:4::4 Serial 1/1 172.16.6.4 2001:db8:6::4
R5 Serial 1/0 172.16.5.5 2001:db8:5::5 Serial 1/1 172.16.6.5 2001:db8:6::5 Tabla 3 Direcciones IPv4 e IPv6
Figura 25 Red IPv4-IPv6 con sus diferentes direcciones
Lo primero a realziar es configurar los routers con IPv4, todo esto se realizara
de la siguiente manera.
94
ROUTER R1 R1>enable
R1#configure terminal
R1(config)#interface serial 1/0
R1(config-if)#ip address 172.16.1.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface serial 1/1
R1(config-if)#ip address 172.16.2.1 255.255.255.0
R1(config-if)#no shutdown
R1(config-if)#exit
ROUTER R2 R2>enable
R2#configure terminal
R2(config)#interface serial 1/0
R2(config-if)#ip address 172.16.1.2 255.255.255.0
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#interface serial 1/1
R2(config-if)#ip address 172.16.3.2 255.255.255.0
R2(config-if)#no shutdown
R2(config-if)#exit
ROUTER R3 R3>enable
R3#configure terminal
R3(config)#interface serial 1/0
R3(config-if)#ip address 172.16.2.3 255.255.255.0
R3(config-if)#no shutdown
R3(config-if)#exit
95
R3(config)#interface serial 1/1
R3(config-if)#ip address 172.16.3.3 255.255.255.0
R3(config-if)#no shutdown
R3(config-if)#exit
R3(config)#interface serial 1/2
R3(config-if)#ip address 172.16.4.3 255.255.255.0
R3(config-if)#no shutdown
R3(config-if)#exit
R3(config)#interface serial 1/3
R3(config-if)#ip address 172.16.5.3 255.255.255.0
R3(config-if)#no shutdown
R3(config-if)#exit
ROUTER R4 R4>enable
R4#configure terminal
R4(config)#interface serial 1/0
R4(config-if)#ip address 172.16.4.4 255.255.255.0
R4(config-if)#no shutdown
R4(config-if)#exit
R4(config)#interface serial 1/1
R4(config-if)#ip address 172.16.6.4 255.255.255.0
R4(config-if)#no shutdown
R4(config-if)#exit
ROUTER R5 R5>enable
R5 #configure terminal
R5(config)#interface serial 1/0
R5(config-if)#ip address 172.16.5.5 255.255.255.0
R5(config-if)#no shutdown
96
R5(config-if)#exit
R5(config)#interface serial 1/1
R5(config-if)#ip address 172.16.6.5 255.255.255.0
R5(config-if)#no shutdown
R5(config-if)#exit
CONFIGURACIÓN DE PROTOCOLOS
Como se pudo observar en la figura, las redes 172.16.1.0/24, 172.16.2.0/24
y 172.16.3.0/24 se propagaran mediante el protocolo de enrutamiento RIP, mientras
que las redes 172.16.4.0/24, 172.16.5.0/24 y 172.16.6.0/24 se propagaran mediante
OSPF.
CONFIGURACIÓN RIP PARA R1, R2 Y R3 Y OSPF EN R3, R4 Y R5
ROUTER R1 R1(config)#router rip
R1(config-router)network 172.16.1.0
R1(config-router)network 172.16.2.0
R1(config-router)no auto-summary
R1(config-router)exit
ROUTER R2 R2(config)#router rip
R2(config-router)network 172.16.1.0
R2(config-router)network 172.16.3.0
R2(config-router)no auto-summary
R1(config-router)exit
ROUTER R3 R3(config)#router rip
97
R3 (config-router)network 172.16.2.0
R3 (config-router)network 172.16.3.0
R3 (config-router)no auto-summary
R1(config-router)exit
Se puede observar que solo se han agregado las redes 172.16.2.0 y
172.16.3.0 en el proceso RIP, dado que son las unicas que participaran en el
proceso RIP. Ahora se configurara OSPF en los routers.
ROUTER R3 R3(config)#router ospf 3
R3(config-router)#network 172.16.4.0 0.0.0.255 area 0
R3(config-router)#network 172.16.5.0 0.0.0.255 area 0
R3(config-router)#exit
Ahora solo se configuraran las redes 172.16.4.0 y 172.16.5.0, en el proceso OSPF,
siendo que son las únicas que participaran en el proceso OSPF.
ROUTER R4 R4(config)#router ospf 4
R4(config-router)#network 172.16.4.0 0.0.0.255 area 0
R4(config-router)#network 172.16.6.00.0.0.255 area 0
R4(config-router)#exit
ROUTER R5 R5(config)#router ospf 5
R5(config-router)network 172.16.5.0 0.0.0.255 area 0
R5(config-router)network 172.16.6.0 0.0.0.255 area 0
R5(config-router)exit
98
Despues de todo lo anterior, si se hace un show ip route en el router R1, se
podra observar que solo apareceran las redes que participan en el proceso RIP, de
igual manera si se hace lo mismo en R4 o R5, apareceran las redes que se enlazan
mediante OSPF. Lo siguiente es comunicar las redes OSPF a RIP y viceversa.
Dado que el router que hace la comunicación entre RIP y OSPF es el router
R3, es ahí donde se debe de hacer la redistribución de rutas, por tanto se hace lo
siguiente. Para redistribuir RIP en OSPF debemos hacerlo en el proceso de OSPF,
a continuación los comandos.
R3(config)#router ospf 3
R3(config-router)redistribute rip subnets metric 10
R3(config-router)exit
Con lo hecho anteriormente, se han propagado las rutas provenientes del
protocolo OSPF hacia RIP, de modo que si hace un show ip route en R1 y/o R2, nos
daremos cuenta que las rutas 172.16.4.0, 172.16.5.0 y 172.16.6.0 ya se han
propagado. Si se hace ping a todas partes, se podra ver que ya es alcanzable.
Es importante resaltar el uso de match, dado que esto nos dará 2 opciones,
si queremos internal o external. El uso internal significa que propagaremos solo
rutas de dicho protocolo, como en nuestro caso que propagaremoshacia RIP solo
rutas de nuestro proceso OSPF, el uso de external es usado si queremos propagar
no solo las rutas OSPF, si no también rutas que vienen siendo anunciadas por otros
protocolos ajenos a est, como puede ser igrp, bgp, entre otras.
Ahora se configuraran las direcciones IPv6, lo primero a realizar es habilitar
en cada router el ruteo de este, dicho ruteo se hace con el comando ipv6 unicast-
routing. Una vez realizado esto, se puede comenzar a configurar las interfaces con
sus respectivas direcciones IP. Hay que tener en cuenta que tanto el proceso RIP y
OSPF, se deben hacer a nivel de interfaz.
99
CONFIGURACIÓN RIP ROUTER R1 R1#configure terminal
R1(config)#ipv6 unicast-routing
R1(config)#interface serial 1/0
R1(config-if)#ipv6 address 2001:db8:1::1/64
R1(config-if)#ipv6 rip 1 enable
R1(config-if)#no shutdown
R1(config-if)#exit
R1(config)#interface serial 1/1
R1(config-if)#ipv6 address 2001:db8:2::1/64
R1(config-if)#ipv6 rip 1 enable
R1(config-if)#no shutdown
R1(config-if)#exit
ROUTER R2 R2#configure terminal
R2(config)#ipv6 unicast-routing
R2(config)#interface serial 1/0
R2(config-if)#ipv6 address 2001:db8:1::2/64
R2(config-if)#ipv6 rip 2 enable
R2(config-if)#no shutdown
R2(config-if)#exit
R2(config)#interface serial 1/1
R2(config-if)#ipv6 address 2001:db8:3::2/64
R2(config-if)#ipv6 rip 2 enable
R2(config-if)#no shutdown
R2(config-if)#exit
100
ROUTER R3 R3#configure terminal
R3 (config)# ipv6 unicast-routing
R3 (config)# interface serial 1/0
R3 (config-if)#ipv6 address 2001:db8:2::3/64
R3 (config-f)#ipv6 rip 3 enable
R3 (config-if)#no shutdown
R3 (config-if)#exit
R3(config)# interface serial 1/1
R3(config-if)#ipv6 address 2001:db8:3::3/64
R3(config-if)#ipv6 rip 3 enable
R3(config-if)#no shutdown
R3(config-if)#exit
Se puede observar que solo se han agregado las redes 2001:db8:2::/64 y
2001:db8:3::/64 en RIP, dado que son las únicas que participan en el proceso RIP.
Lo siguien a realizar es la configuración OSPF en las otras interfaces de R3. Antes
de poder agregar una red a OSPF en IPv6, es necesario ingresar el proceso OSPF
en modo de configuración global y agregamos un router-id. Las configuraciones por
router es como sigue.
ROUTER R3 R3#configure terminal
R3(config)#ipv6 unicast-routing
R3(config)#ipv6 router ospf 3
R3(config-rtr)#router-id 3.3.3.3
R3(config-rtr)#exit
R3(config)#interface serial 1/2
R3(config-if)#ipv6 address 2001:db8:4::3/64
R3(config-if)#ipv6 ospf 3 area 1
R3(config-if)#no shutdown
101
R3(config-if)#exit
R3(config)#interface serial 1/3
R3(config-if)#ipv6 address 2001:db8:5::3/64
R3(config-if)#ipv6 ospf 3 area 1
R3(config-if)#no shutdown
R3(config-if)#exit
Ahora solo se han agregado las redes 2001:db8:4::/64 y 2001:db8:5::/64 en OSPF,
dado que son las únicas que participaran en el proceso OSPF.
ROUTER R4 R4#configure terminal
R4(config)#ipv6 unicast-routing
R4(config)#ipv6 router ospf 4
R4(config-rtr)#router-id 4.4.4.4
R4(config-rtr)#exit
R4(config)#interface serial 1/0
R4(config-if)#ipv6 address 2001:db8:4::4/64
R4(config-if)#ipv6 ospf 4 area 1
R4(config-f)#no shutdown
R4(config-if)#exit
R4(config)#interface serial 1/1
R4(config-if)#ipv6 address 2001:db8:6::4/64
R4(config-if)#ipv6 ospf 4 area 1
R4(config-if)#no shutdown
R4(config-if)#exit
ROUTER R5 R5#configure terminal
R5(config)# ipv6 unicast-routing
R5(config)# ipv6 router ospf 5
102
R5(config-rtr)# router-id 5.5.5.5
R5(config-rtr)# exit
R5(config)# interface serial 1/0
R5(config-if)#ipv6 address 2001:db8:5::5/64
R5(config-if)# ipv6 ospf 5 area 1
R5(config-if)#no shutdown
R5(config-if)#exit
R5(config)# interface serial 1/1
R5(config-if)#ipv6 address 2001:db8:6::5/64
R5(config-if)# ipv6 ospf 5 area 1
R5(config-if)#no shutdown
R5(config-if)#exit
Una vez hecho todo lo anterior, podemos ver las tablas de rutas con el
comando show.ipv6 route. Al igual que IPv4 si se hace un show ipv6 route en los
routers R1 y/o R2, podemos observar que solo aparecen las redes que participan
en el proceso RIP, de igual forma que si hacemos lo anterior en los router R4 o/y
R5, veremos que solo aparecen las redes que son propagadas por OSPF. Lo
siguiente a realizar es comunicar las redes OSPF a RIP y asu vez OSPF a RIP.
REDISTRIBUCIÓN DE RIP-OSPF Y OSPF-RIP
Dado que el router que esta de comunicador entre RIP y OSPF es el router
R3, es en el que se debe hacer la redistribucion de rutas, para ello, se debe realizar
el proceso en OSPF.
R3#configure terminal
R3(config)#ipv6 router ospf 3
R3(config-rtr)#redistribute rip 3 metric 10 include-connected
R3(config-rtr)#exit
103
Despues de configurar lo anterior en el router 3, se han estrechado las rutas
provenientes del protocolo RIP hacia OSPF, de modo que si se hace un show ipv6
route en R4 y/o R5, se podra observar que las rutas 2001:db8:1::/64,
2001:db8:2::/64 y 2001:db8:3::/64, ya se han comunicado y ademas son rutas
externas al protocolo, esto se puede mirar en las tablas de rutas;; dichas rutas
aparecen con O E2, pero si se quiere hacer un ping , aun no son alcanzables, esto
debido a que se tiene la ruta de ida, mas no la de regreso y todo esto es a causa de
que aun no se ha configurado OSPF en RIP. Ahora para redistribuir OSPF en RIP,
se realiza lo siguiente, todo esto en el mimo router R3.
R3#configure terminal
R3(config)# ipv6 router rip 3
R3(config-rtr)redistribute ospf 3 match internal metric 10 include-connected
R3(config-rtr)exit
Mediante los realizado con anterioridad, las rutas del protocolo OSPF hacia
RIP se han comunicado, de modo que si se hace un ipv6 show route en los router
R1 y/o R2, se podra observar que las rutas 2001:db8:4::/64, 2001:db8:5::/64 y
2001:db8:6::/64, ya se han comunican. Si se hace ping de cualquier de los routers
hacia otro de estos, se vera que estos ya se comunican sin problema alguno. Es
importante decir que el uso de match, dado que esto maneja dos opciones, tanto
internal o external, el uso de internal es para propagar rutas de dicho protocolo,
como en el caso en el que estamos trabajando, en donde RIP se conecta con OSPF,
y con external, sirve para propagar no solo rutas OSPF, si no tambien rutas que
vienen siendo anunciadas por otros protocolos ajenos a este, como podria ser igpr,
bpg, entre otros.
104
5.4 RESULTADOS
Despues de llevarse acabo el experimento de simulacion tanto de IPv4 con RIP e
IPv6 con OSPF por separado cada 1 y luego en conjunto para comunicarse, se
obtuvieron los siguientes resultados.
Mediante el comando ping, se fue realizando la consulta de cuanto tarda un
paquete en enviarse a otro router. Los resultados fueron los siguientes. En las
siguientes imágenes se muestra los ping, realizados a los diferentes routers. Estas
pruebas se aplicaron tanto a la red IPv4, IPv6 e IPv4 con IPv6. Mediante 30
simulaciones realizadas se obtuvieron los siguientes resultados.
Figura 26 Pings R1
105
Figura 27 Pings R2
Figura 28 Pings R3
106
Figura 29 Pings R4
Figura 30 Pings R5
107
TIEMPO DE RESPUESTA R1 R2 R3 R4 R5
R1 Serial 1/0 -‐ 18 29 23 28 Serial 1/1 -‐ 22 14 21 26
R2 Serial 1/0 20 -‐ 19 17 31 Serial 1/1 21 -‐ 17 28 18
R3 Serial 1/0 20 29 -‐ 32 14 Serial 1/1 24 31 -‐ 23 20 Serial 1/3 13 23 -‐ 26 22 Serial 1/4 28 20 -‐ 29 14
R4 Serial 1/0 34 19 22 -‐ 31 Serial 1/1 32 27 29 -‐ 22
R5 Serial 1/0 28 30 22 28 -‐ Serial 1/1 37 29 24 22 -‐
PROMEDIO 25.7 24.8 22 24.9 22.6
Tabla 4 Tiempos de respuesta de los routers IPv4
Figura 31 Velocidad de respuesta del R1
0510152025303540
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R2 R3 R4 R5
20 21 20 2413
2834 32 28
37
VELOCIDAD DE RESPUESTA CON RESPECTO A R1 (MS) IPV4
108
Figura 32 Velocidad de respuesta del R2
Figura 33 Velocidad de respuesta del R3
05101520253035
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R3 R4 R5
18 2229 31
23 20 1927 30 29
VELOCIDAD DE RESPUESTA CON RESPECTO A R2 (MS) IPV4
051015202530
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R2 R4 R5
29
1419 17
2229
22 24
VELOCIDAD DE RESPUESTA CON RESPECTO A R3 (MS) IPV4
109
Figura 34 Velocidad de respuesta del R4
Figura 35 Velocidad de respuesta del R5
05101520253035
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R5
23 21 1728 32
23 26 29 2822
VELOCIDAD DE RESPUESTA CON RESPECTO A R4 (MS) IPV4
05101520253035
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R4
28 2631
18 1420 22
14
3122
VELOCIDAD DE RESPUESTA CON RESPECTO A R5 (MS) IPV4
110
Figura 36 Velocidad de respuesta promedio de IPv4
En la figura 5.12, se puede observar el promedio que existe en la velocidad
de comunicación entre los diferentes routers del esquema utilizado. A continuación
se hara el muestreo final para IPv6.
TIEMPO DE RESPUESTA R1 R2 R3 R4 R5 R1 Serial 1/0 -‐ 19 27 21 25
Serial 1/1 -‐ 22 21 24 30 R2 Serial 1/0 21 -‐ 24 29 27
Serial 1/1 17 -‐ 21 28 29 R3 Serial 1/0 20 24 -‐ 18 18
Serial 1/1 18 17 -‐ 19 27 Serial 1/3 13 20 -‐ 26 24 Serial 1/4 17 15 -‐ 27 14
R4 Serial 1/0 29 21 25 -‐ 31 Serial 1/1 27 24 18 -‐ 13
R5 Serial 1/0 26 28 18 31 -‐ Serial 1/1 24 29 18 25 -‐
PROMEDIO 21.2 21.9 21.5 24.8 23.8
Tabla 5 Tiempos de respuesta de los routers IPv6
20
21
22
23
24
25
26
1 2 3 4 5
25.724.8
22
24.9
22.6
PROMEDIO DE LOS 5 ROUTERS (MS) IPV4
111
Figura 37 Velocidad de respuesta del R1
Figura 38 16 Velocidad de respuesta del R2
051015202530
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R2 R3 R4 R5
21 17 20 1813 17
29 27 26 24
VELOCIDAD DE RESPUESTA CON RESPECTO A R1 (MS) IPV6
051015202530
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R3 R4 R5
19 22 2417 20
1521 24 28 29
VELOCIDAD DE RESPUESTA CON RESPECTO A R2 (MS) IPV6
112
Figura 39 Velocidad de respuesta del R3
Figura 40 Velocidad de respuesta del R4
051015202530
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R2 R4 R5
2721 24 21 25
18 18 18
VELOCIDAD DE RESPUESTA CON RESPECTO A R3 (MS) IPV6
05101520253035
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R5
21 2429 28
18 1926 27 31
25
VELOCIDAD DE RESPUESTA CON RESPECTO A R4 (MS) IPV6
113
Figura 41 Velocidad de respuesta del R5
Figura 42 Velocidad de respuesta promedio de IPv6
Ahora se hara el muestreo obtenido de la red de IPv4 RIP con IPv6 OSPF,
en la cual se puede observar claramente que hay mucho cambio tanto en la
velocidad de respuesta de IPv4 con RIP, pero aun con más velocidad se ve que
trabaja IPv6 con el protocolo OSPF.
05101520253035
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R4
2530 27 29
1827 24
14
31
13
VELOCIDAD DE RESPUESTA CON RESPECTO A R5 (MS) IPV6
19
20
21
22
23
24
25
1 2 3 4 5
21.221.9 21.5
24.823.8
PROMEDIO DE LOS 5 ROUTERS (MS) IPV6
114
TIEMPO DE RESPUESTA R1 R2 R3 R4 R5 R1 Serial 1/0 -‐ 18 16 16 16
Serial 1/1 -‐ 22 18 17 12 R2 Serial 1/0 17 -‐ 38 15 16
Serial 1/1 29 -‐ 17 17 12 R3 Serial 1/0 20 44 -‐ 20 14
Serial 1/1 30 21 -‐ 21 15 Serial 1/3 17 26 -‐ 19 15 Serial 1/4 25 26 -‐ 18 17
R4 Serial 1/0 22 24 26 -‐ 16 Serial 1/1 29 21 25 -‐ 19
R5 Serial 1/0 26 23 29 21 -‐ Serial 1/1 30 22 22 20 -‐
PROMEDIO 24.5 24.7 23.875 18.4 15.2
Tabla 6 Tiempos de respuesta de los routers IPv4 con IPv6
Figura 43 Velocidad de respuesta del R1
051015202530
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R2 R3 R4 R5
17
2920
30
1725 22
29 26 30
VELOCIDAD DE RESPUESTA CON RESPECTO A R1 (MS) IPV4-‐IPV6
115
Figura 44 Velocidad de respuesta del R2
Figura 45 Velocidad de respuesta del R3
051015202530354045
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R3 R4 R5
18 22
44
21 26 26 24 21 23 22
VELOCIDAD DE RESPUESTA CON RESPECTO A R2 (MS) IPV4-‐IPV6
0510152025303540
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
R1 R2 R4 R5
16 18
38
1726 25 29
22
VELOCIDAD DE RESPUESTA CON RESPECTO A R3 (MS) IPV4-‐IPV6
116
Figura 46 Velocidad de respuesta del R4
Figura 47 Velocidad de respuesta del R5
0
5
10
15
20
25
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R5
16 17 15 17 20 21 19 18 21 20
VELOCIDAD DE RESPUESTA CON RESPECTO A R4 (MS) IPV4-‐IPV6
0
5
10
15
20
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/0
Serial 1/1
Serial 1/3
Serial 1/4
Serial 1/0
Serial 1/1
R1 R2 R3 R4
1612
1612 14 15 15 17 16
19
VELOCIDAD DE RESPUESTA CON RESPECTO A R5 (MS) IPV4-‐IPV6
117
Figura 48 Velocidad de respuesta promedio de IPv4 - IPv6
0
5
10
15
20
25
1 2 3 4 5
24.5 24.7 23.87518.4
15.2
PROMEDIO DE LOS 5 ROUTERS (MS) IPV4-‐IPV6
CAPÍTULO 6. CONCLUSIONES
119
Las redes de computadoras en lo que respecta a internet, en la actualidad
desempeñan un importante papel en el área de las comunicaciones en la sociedad,
es por ello que se debe contar con una estructura robusta, la cual sea capas de ser
mejorada y soportar dicha infraestructura. Debido al crecimiento en demandas de
direcciones IP, por tanto dispositivo que necesita de una dirección para poder salir
al mundo digital, poco a poco se han venido agotando las direcciones IPv4 al grado
de que se ha creado un nuevo protocolo que vendrá a sustituir el actual, este
protocolo es IPv6, que como ya se menciono, es un protocolo con mayor cantidad
de direcciones. Por consiguiente se llevo un estudio de conectividad entre IPv4 con
IPv6 para así poder observar el comportamiento y el que si se pueden comunicar
dichos protocolos.
Con lo realizado con anterioridad se demostró que si pueden operar IPv4 e
IPv6 en conjunto. IPv6 esta a la vuelta de la esquina para operar en definitiva, pero
aun hay instituciones que operan bajo IPv4 y no se cambiaran de la noche a la
mañana, es por eso que se estudia la operabilidad entre ambos protocolos, con el
fin de que en estas, se comience la implementación de IPv6 sin dejar aun lado IPv4,
todo esto siendo posible comunicarse mediante los diferentes protocolos de
comunicación que existen para ellos.
Gracias al simulador de redes GNS3, se logro llevar acabo este estudio,
simulando bajo 5 routers que operaban dos de ellos bajo IPv4 con RIP y dos más
en IPv6 bajo OSPF, en donde había un quinto routeador que era el que hacia la
comunicación entre estos cuatro routers, todo esto se logro mediante el modelo de
traducción MAP. Otra cosa que se observo, fue que cuando ambos protocolos
operan entre sí, mediante el modelo de traducción MAP, IPv4 tiene menor eficiencia
que IPv6, pues IPv6 opero más rápido demostrando esto en las 30 pruebas que se
realizaron, todo esto con el fin de comprobar que los tiempos siempre fueran los
mismos y poder tomar datos con los cuales se grafico, y se vio lo explicado
anteriormente, cumpliendo así la hipótesis planteado en un inicio.
120
Con el protocolo IPv6 la red se comporto de manera más eficiente así como
rápida, más segura y fiable, lamentablemente la transición de IPv4 a IPv6 aun se ve
muy lejana, pues aun instituciones desconocen IPv6 y el mayor problema que
enfrentarían seria, el renovar equipos de comunicación (routers) que en este caso
no servirían, ya que son obsoletos y no pueden realizar la comunicación entre IPv4
e IPv6.
Mediante mecanismos de transición, hay una amplia gama de posibilidades
para experimentar con IPv6, tanto en movilidad, seguridad a nivel red, integración
con más dispositivos como Smartphones, tabletas, etcétera, así también como en
operabilidad y confiabilidad.
TRABAJO FUTURO
El diseño e implementación de una arquitectura de red, es un trabajo complejo y
extenso, estructurado en distintas fases que incluyen la definición del concepto,
requisitos, diseño, evaluación y rediseño, prototipos, optimización, implantación,
implementación y fabricación.
Esta tesis de maestría, debido a su amplitud del concepto tratado, basó sus
objetivos en la definición del concepto y sus requisitos, el diseño y la evaluación
previa de ciertas funciones, de una red IPv6, mediante los protocolos RIP para IPv4
OSPF en IPv6, por medio de un protocolo de traducción, en este caso MAP.
De tal forma, que con los nuevos estudios que se realizan en el aspecto del
nuevo protocolo de internet (IPv6), permitirían la realización de un prototipo, y la
optimización del diseño con el objeto de su especificación técnica o estandarizada
para lo nuevo como lo es IPv6 móvil. (García, 2014)
121
Recientemente han comenzado a aparecer diferentes tipos de dispositivos
de red, que permiten al usuario estar conectados a internet en cualquier lugar,
gracias a las tecnologías inalámbricas. No solamente PCs portátiles sino también
PDAs, consolas de juegos, e incluso recientemente teléfonos móviles celulares,
robots y muchos más que son difíciles de visionar en el presente.
Estos dispositivos comenzaran a cambiar el modelo de conectividad a
internet con el que se trabaja en el presente, actualmente cuando un usuario se
desplaza viajando por distintas redes, cada una de las nuevas rede visitadas por las
que pasa, proporciona una dirección IP diferente a la que poseía en la red anterior
de la que provenía, por lo que el usuario no puede mantener una sesión de
aplicación abierta durante el desplazamiento. Esto significa, que si el usuario tenia
una conversación con otro usuario mediante voz sobre IP (VoIP), dicha
conversación se corta en el momento en que el usuario móvil realiza el cambio de
red.
IETF (Por sus siglas en ingles, Internet Engineering Task Force), dicho grupo
de trabajo de ingeniería de internet, desarrollo un nuevo modelo de conectividad a
internet que soluciona los problemas mencionados anteriormente. A esta tecnología
se le conoce con el nombre de movilidad IP, la cual no es operativa sobre IPv4 por
diversos motivos pero gracias a IPv6 y sobre todo al protocolo de movilidad sobre
IPv6 (MIPv6), la puesta en práctica de un modelo de conectividad con soporte de
movilidad del usuario, parece más realista.
Dicho mecanismo corresponde al protocolo estandarizado por IETF y
funciona de una manera efectiva y eficiente. Sin embargo para que el despliegue de
MIPv6 a gran escala en un operador sea realizable, es necesario aún cierto trabajo
como el que se está realizando en proyectos, para abordar diferentes aspectos de
configuración de forma dinámica. En concreto el protocolo de movilidad sobre IPv6,
solo proporciona la definición de los agentes involucrados en el soporte de
movilidad, su funcionamiento y sus interacciones, lo cual es suficiente si pensamos
122
en un despliegue experimental o a baja escala en el que participen muy pocos
usuarios y donde la configuración de los agentes es mayormente predominante.
El modelo de conectividad a internet esta evolucionando rápidamente a
medida que empieza a aparecer nuevos dispositivos portátiles y el despliegue de
las redes de acceso se extienden cada vez más. El nuevo modelo basado en
movilidad de usuarios en redes IPv6 se irá implantando en próximos años, debido
a un diseño robusto y eficiente, que lo diferencia de su antecesor MIPv4. Sin
embargo aún existen algunos inconvenientes en la estandarización de MIPv6 que
necesitan ser abordados para ofrecer soluciones que permitan el despliegue a gran
escala de MIPv6.
Cabe destacar que en dispositivos móviles algo que día con día va cobrando
más terreno, es IPv6 en Robots. En un articulo escrito por la Escuela de Ingeniería
Eléctrica y Electrónica de la Universidad del Valle en Cali, Colombia;; se llevo acabo
una experimento de la teleoperación inalámbrica de un robot vía internet utilizando
IPv6 sobre una red de área personal en bluetooth, en la cual se diseño, construyo y
se realizaron pruebas, para manipular y visualizar un robot, Microbot Teachmover,
mediante conexión bluetooth con dirección IPv6, donde se manejaba el robot desde
diferentes escenarios, mediante un dispositivo móvil dentro de red del robot, que a
su vez se podía manipular desde un computador conectado a Internet con dirección
IPv6 y también en la misma red. (Universidad del Valle, 2010)
Dicho lo anterior, IPv6 se torna algo de actualidad y novedoso, pues con esto
se observa la conectividad que hay y existirá en los dispositivos móviles, tanto para
operar solo en IPv6 o también operar IPv4 con IPv6 .
Con el pasar de los días IPv6 se va implementando más y más en
instituciones de todo tipo, los usuarios móviles deben empezar a obtener beneficios
en el rendimiento, según los miembro de un panel en el “Consumer Electronics
Show” realizado en Las Vegas Estados Unidos en el año 2012. (GN, 2014)
123
Según el artículo de Computer World, los miembros del panel de expertos
dicen que una fuente de rendimiento mejorado haría que cada dispositivo conectado
a IPv6 (sea teléfono inteligente, teléfono, router, cámara de seguridad o de la
oficina) pueda comunicarse directamente entre sí a través de la Internet.
Los proveedores de servicios que utilizan IPv4, por el contrario, utilizan un
proceso llamado traducción de direcciones de red que "asigna direcciones
verdaderas únicas a los dispositivos de los suscriptores sólo temporalmente". La
carga administrativa de envío de paquetes de ida y vuelta para mantener la conexión
activa reduce el rendimiento y consume energía.
124
FUENTES DE INFORMACIÓN
Antonio M. Moreiras. (2014) IPV6 PARA OPERADORES DE RED, 1a Edición.
Buenos Aires, Argentina.
B. Carpenter, K. Moor, B. Fink, CONNECTING IPV6 ROUTING DOMAINS OVER
THE IPV4 INTERNET, IPJ, March 2005 Volume 3, Number 1.
Chandan J., P. P. (2014). Realisation of Link State Routing Protocol and Advance
Distance Vector in Different IP Schema. School of Electronics and Communication
Engineering.
CISCO, System. (10 de Agosto de 2005). An Introduction to IGRP. Recuperado el
11 de Febrero de 2015, de CISCO:
http://www.cisco.com/c/en/us/support/docs/ip/interior-gateway-routing-protocol-
igrp/26825-5.html
Cisco Systems, In. (2012). IPv6 anycast Dirección. Recuperado el 21 de Mayo de
2015, de CISCO:
http://www.cisco.com/c/en/us/td/docs/ios- xml/ios/ipv6/configuration/15-2s/ip6-15-
2s-book/ip6-anycast-add.html
CISCO, System. (10 de Junio de 2009). CCDA Self-Study: RIP, IGRP, and EIGRP
Characteristics and Design. Recuperado el 26 de Febrero de 2015, de CISCO:
http://www.ciscopress.com/articles/article.asp?p=102174&seqNum=4
CISCO, System. (10 de Junio de 2009). Estudios de casos de BGP. Recuperado el
26 de Febrero de 2015, de CISCO:
http://www.cisco.com/cisco/web/support/LA/7/76/76167_bgp-toc.html#intro
125
CISCO, System. (23 de Agosto de 2005). Introduction to EIGRP. Recuperado el 03
de Marzo de 2015, de CISCO:
http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior- gateway-routing-
protocol-eigrp/13669-1.html
Cisco System. (2012). IPv6 Unicast Routing. Recuperado el 19 de Marzo de 2015,
de CISCO: http://www.cisco.com/c/en/us/td/docs/ios- xml/ios/ipv6/configuration/15-
2s/ip6-15-2s-book/ip6-uni-routing.html
CISCO, System. (23 de Agosto de 2008). Guía de diseño de OSPF. Recuperado el
12 de Marzo de 2015, de CISCO:
http://www.cisco.com/cisco/web/support/LA/7/73/73214_1.html#topic1
CISCO, System. (23 de marzo de 2008). Guía de diseño de OSPF. Recuperado el
15 de Abril de 2015, de CISCO:
http://www.cisco.com/cisco/web/support/LA/7/73/73214_1.html#intro
C. Taffernaberry, A. Dantiacq Picolella, G. Mercado y A. Francisconi. CODAREC6:
AN IPv6 TEST BED, XII CACIC, Octubre 2006, Potrero de los Funes, San Luis.
Computer Communications. (2013). A study of traffic from the perspective of a large
pure IPv6 ISP. (L. Fuliang , A. Changqing, & Y. Jiahai, Edits.) ELSEIVER.
Deering, R. H. (2006). IPV6 Addressing Architecture. RFC 4291.
Dunmore, M. (2005). AN IPV6 DEPLOYMENT GUIDE EDITOR . 6net.
García, S. P. (20 de Agosto de 2014) Despegando con movilidad IPv6 (MIPv6)
Recuperado el 24 de Mayo de 2015, de Universidad de Murcia: http://www.ist-
enable.eu/open/enable_pu_paper_consulintel_despegando_con_MIPv6_AUI_v1_5
126
GNC, (14 de enero de 2013). IPv6 aumenta el rendimiento móvil, reclamaciones de
panel. Recuperado el 13 de Mayo de 2015, de GCN:
http://gcn.com/blogs/pulse/2013/01/ipv6-boosts-mobile-performance.aspx
IEEE. (2009). A New Worm Exploiting IPv6 and IPv4-IPv6 Dual-Stack Networks:
Experiment, Modeling, Simulation, and Defense. (L. Ting, G. Xiaohong, & Q. Yu,
Edits.) IEEE Network.
IEEE. (2010). IPv6 Addressing Architecture in IPv4 Network. (J. Gnana Jayanthi, &
S. Albert Rabara, Edits.) 2010 Second International Conference on Communication
Software and Networks.
K. Tsuchiya, H. Higuchi, Y. Atarashi, Dual Stack Hosts using the "Bump-In-the-
Stack" Technique, Febrero 2006.
J. Hagino, K. Yamamoto, An IPv6-to-IPv4 Transport Relay Translator, RFC 3142,
June 2001.
Martínez, J. P. (2008). TUTORIAL IPV6. CONSULTORES INTEGRALES DE
TELECOMUNICACIONES. IPV6 FORUM.
Nordmark, E.;; Gilligan, R. RFC 4213: Basic Transition Mechanisms for IPv6 Hosts
and Routers. 2005.
Science Direct. (2013). New IPv4/IPv6 transition solution for data center. (Q. Zhao,
& Y. Ma, Edits.) ELSEVIER.
ScienceDirect. (2007). An introduction to investigating IPv6 networks. (B. J. Nikkel,
Ed.) ELSEVIER.
127
T, J. P. (2008). TUTORIAL IPV6. CONSULTORES INTEGRALES DE
TELECOMUNICACIONES. IPV6 FORUM.
Teldat (2008). Protocolo BGP. Marzo. Doc. Dm763 Rev. 10.61
Telecommunications Policy. (2014). IPv4 to IPv6: Challenges, solutions, and
lessons. (L. L. Stanford, & S. Stephen, Edits.) ELSEVIER.
Universidad del Valle. (2010). Teleoperación inalámbrica de un robot vía internet
utilizando IPv6 sobre una red de área personal bluetooth. (G. F., Ed.) Cali, Colombia.
128
GLOSARIO
Back-to-back. En su forma básica, es una conexión directa de la salida de un dispositivo a la entrada de un dispositivo similar o relacionado. En redes de
telecomunicaciones, una conexión espalda a espalda puede realizarse por la
conexión de un transmisor directamente a un receptor sin dispositivos intermedios
de sincronización, control y adaptación de señales al medio. En algunos casos, la
salida de un dispositivo de recepción está también conectada a la entrada de un
dispositivo de transmisión para establecer una conexión bidireccional directa de
comunicación.
Broadcast. Comunicación en la que una sola transmisión es recibida por múltiples receptores, como ser la televisión o la radio por Internet, entre otros.
Cisco. Compañía que diseña y vende tecnología y servicios de red como: routers (enrutadores), switches (conmutadores), hubs, cortafuegos, productos de telefonía
IP, software de gestión de red como Cisco Works, equipos para Redes de Área de
Almacenamiento.
CLNS (Connectionless Network Service). Servicio desarrollado por la ISO que opera en la Capa de Red del Modelo OSI, para la transmisión de datos sin requerir
que sean establecidas conexiones en forma previa, en forma similar al protocolo
UDP.
Conmutación. Es la interconexión manual o automática necesaria para establecer la comunicación entre dos aparatos conectados a la red.
Cluster. Grupo de servidores, procesadores, dispositivos de almacenamiento y/o otros recursos que actúan como una sola entidad, compartiendo las funciones de
un solo sistema para habilitar alta disponibilidad y en algunos casos balanceo de
carga y procesamiento paralelo.
DHCP (Dynamic Host Configuration Protocol). Es un protocolo bajo el modelo cliente–servidor utilizado para la configuración automática de los parámetros
TCP/IP (dirección, mascara, Gateway por defecto, dominio, tiempo de concesión)
de nodos que se conectan a una red. En este esquema, un bloque (pool) de
direcciones IP es controlado por el servidor DHCP, generalmente en asignación
129
temporal, lo que define una administración dinámica de direcciones.
DNS (Domain Name System). Es un sistema que traduce nombres en términos fáciles de memorizar y encontrar por un usuario, a direcciones IP correspondientes
a sistemas en Internet.
Cisco fue fundada en 1984 por el matrimonio de Leonard Bosack y Sandra Lerner,
quienes trabajaban en el área de computación de la universidad de Stanford.
Host. Computadoras conectados a una red, que proveen y utilizan servicios de ella. Los usuarios deben utilizar anfitriones para tener acceso a la red.
LAN. Red de área local (del inglés local area network) es la interconexión de una o varias computadoras y periféricos. Multicast. Multicast hace su trabajo de transmisión de manera similar a como funcionan los canales de televisión o las estaciones de radio: El programa (archivo
de audio / video) se emite desde la estación hacia los transmisores (servidores
conectados a la red) quienes se encargan de distribuir la señal (el stream) a los
televidentes. Cuando el espectro de televidentes (usuarios, visitantes) se extiende,
se agregan repetidoras (servidores).
Nap. (Network Access Point - Punto de Acceso a la Red). Se refiere a los tres puntos de acceso a Internet en EE.UU.
Peer-to-peer. Es una forma especial de proceso cooperativo, en el que unas aplicaciones pueden establecer comunicación con otras.
Ping. Anillo abrazadera. Parte de la unidad de un disco flexible de 5.25" que empuja el disco hacia el eje. Por lo general el anillo abrazadera forma parte del cono de
centrado.
Proxy. Es un programa que realiza la tarea de encaminador, utilizado en redes locales, su función es similar a la de un router, pero es injustificable el gasto en
redes locales.
Router. Originalmente se identificaba con el término Gateway, sobre todo en referencia a la red Internet. En general, debe considerarse como el elemento
responsable de discernir cuál es el camino más adecuado para la transmisión de
mensajes en una red compleja que está soportando un tráfico intenso de datos.
130
Servidor. Genéricamente, dispositivo de un sistema que resuelve las peticiones de otros elementos del sistema, denominados clientes.
Sistema operativo. Es un software que actúa de interfaz entre los dispositivos de hardware y los programas usados por el usuario para manejar un computador. Es
responsable de gestionar, coordinar las actividades y llevar a cabo el intercambio
de los recursos y actúa como estación para las aplicaciones que se ejecutan en la
máquina.
SSH. (Secure Shell). Protocolo seguro y un conjunto de herramientas para reemplazar otras más comunes (inseguras). Fue diseñado desde el principio para
ofrecer un máximo de seguridad y permitir el acceso remoto a servidores de forma
segura.
Topología. La topología hace referencia a la forma de un red. La topología muestra cómo los diferentes nodos están conectados entre sí, y la forma de cómo se
comunican está determinada por la topología de la red. Las topologías pueden ser
físicas o lógicas.
Tranceroute. Utilizad que traza el camino que hace un paquete desde una computadora hasta un otra en internet (generalmente un servidor), mostrando el
tiempo que tarda en ir de un lado al otro y los saltos (hops) que da durante el camino.
WAN. (Wide Area Network - Red de Área Extensa). WAN es una red de computadoras de gran tamaño, generalmente dispersa en un área metropolitana, a
lo largo de un país o incluso a nivel planetario.
