RAE
TIPO DE DOCUMENTO: Trabajo realizado sobre las herramientas básicas para la
implementación de redes con soporte IPv6, con el fin de obtener el titulo de
Ingeniero Electronico.
TITULO: DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA
IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6
AUTOR: Ricardo Almario Zea
LUGAR: Bogota D.C.
FECHA: Enero 2012
PALABRAS CLAVES: IPv6, 6to4, ISATAP, TEREDO, Tunnel Broker, TSP, Dual-
Stack, RIPng, OSPFv3, MP-BGP, IS-IS.
DESCRIPCIÓN DEL TRABAJO: En este proyecto se estudia el funcionamiento
del protocolo IPv6, sus características y a su vez los mecanismos de transición
que ayudaran a acelerar el proceso de migración. Todos los diseños realizados
fueron simulados para que puedan ser debidamente evaluados.
LINEA DE INVESTIGACIÓN: Este trabajo se desarrolla en el marco de la Línea
institucional-tecnologías actuales y sociedad.
FUNTES CONSULTADAS: Migrating to IPv6. A practical Guide to Implementing
IPv6 in Mobile and Fixed Networks. Marc Blanchet. John Wiley & Sons, ltd. 2005.
Québec, Canada. Handbook of IPv4 to IPv6 transition. Metodologies for
institutional and corporate networks. John J. Amoss & Daniel Minolli. 2008.
Auerback publications. Taylor & Francis Group. Boca Raton, Fl. USA.
Understanding IPv6. Joseph davies. 2008. Microsoft Press. Redmond,
Washington. Configuring IPv6 for Cisco IOS. Deploy IPv6 on the Cisco IOS. Sam
Brown, Brian Browne, Neal Chen, Paul J. Fong. 2002. Syngress Publishing.
Rockland, MA USA. IPv6 para todos. Guía de uso y aplicación para diversos
entornos. Guillermo Cicileo, Roque Gagliano, otros.2009. Internet society, capítulo
Argentina.
CONTENIDOS: Durante el desarrollo de este proyecto se estudiará el protocolo
IPv6 y se experimentará sobre sus diversos tópicos, con el fin de poder brindar a
la comunidad universitaria las herramientas básicas necesarias para impulsar y
fomentar las adopción del protocolo IPv6 en diferentes entornos, explicando de
manera clara los pasos y requerimientos para configurar e implementar la nueva
versión del protocolo IP en el ámbito que sea necesario.
METODOLOGIA: El desarrollo de este proyecto tiene un enfoque empírico-
analítico el cual tiene un interés técnico, orientado a la interpretación y
transformación del mundo material. Proporciona además una estructura particular
a la metodología de investigación en tanto que orienta el trabajo a la contrastación
permanente de las aseveraciones teóricas con la verificación experimental, de
manera que los cálculos generados a través de modelos matemáticos y
simulaciones computacionales se deben retroalimentar con la experimentación, en
la búsqueda de información cada vez más confiable y práctica para la solución del
problema.
CONCLUSIONES: Este proyecto pretende ser un primer paso hacia el desarrollo
investigativo sobre el protocolo IPv6 en la Universidad San Buenaventura,
promoviendo y construyendo conocimiento, con el fin de abrir puertas a nuevos
productos, servicios y aplicaciones, que serán desarrollados en el futuro gracias a
todas la ventajas que este protocolo brinda.
DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA
IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6
RICARDO ALMARIO ZEA
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
BOGOTÁ
2011
DISEÑO Y SIMULACIÓN DE LAS HERRAMIENTAS BÁSICAS PARA LA
IMPLEMENTACIÓN DE REDES CON SOPORTE IPv6
RICARDO ALMARIO ZEA
Trabajo de grado para optar por el título de ingeniero electrónico
Director
Luis Carlos Gil Bernal
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA ELECTRÓNICA
BOGOTÁ
2011
CONTENIDO
Pág.
INTRODUCCIÓN
1. PLANTEAMIENTO DEL PROBLEMA 1
1.1 ANTECEDENTES 1
1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA 4
1.3 JUSTIFICACIÓN 5
1.4 OBJETIVOS DE LA INVESTIGACIÓN 6
1.4.1 Objetivo general 6
1.4.2 Objetivos específicos 6
1.5 ALCANCES Y LIMITACIONES DEL PROYECTO 6
2. METODOLOGÍA 8
3. LÍNEA DE INVESTIGACIÓN 9
4. MARCO TEÓRICO Y CONCEPTUAL 10
4.1 EL PROTOCOLO IPV4 Y SUS LIMITACIONES 10
4.1.1 Nacimiento del protocolo ipv4 y agotamiento 10
de direcciones
4.1.2 Soluciones al agotamiento de direcciones 13
4.2 INTRODUCCIÓN AL PROTOCOLO IPV6 15
4.2.1 Nacimiento del Protocolo IPv6 15
4.2.2 Descripción y características del Protocolo IPv6 17
4.2.3 IPV4 frente a IPV6 19
4.2.4 Estado de Adopción de IPv6 22
4.2.5 ¿Por qué no se despliega IPv6 con mayor rapidez? 25
4.3 EL PROTOCOLO IPv6 28
4.3.1 Cabecera IPv6 28
4.3.2 Cabeceras de Extensión 33
4.3.2.1 Cabecera de Opciones Salto a Salto 33
4.3.2.2 Cabecera de enrutamiento 35
4.3.2.3 Cabecera de Fragmentación 38
4.3.2.4 Cabecera Opciones de Destino 39
4.3.2.5 Cabecera de Autentificación 40
4.3.2.6 Cabecera de Carga de Seguridad Encapsulada 41
4.3.2.7 Cabecera siguiente valor 59 44
4.3.3 Consideraciones sobre el tamaño del paquete 44
4.3.4 Problemas de protocolo de capa superior 44
4.3.4.1 Sumas de Verificación de Capa Superior 45
4.3.4.2 Tiempo de Vida Máximo de un Paquete 46
4.3.4.3 Tamaño Máximo de la Carga Útil de Capa Superior 46
4.3.4.4 Respuesta a Paquetes que Llevan Cabeceras 47
de Enrutamiento
4.4 DIRECCIONAMIENTO IPV6 47
4.4.1 Tipos de Direcciones IPv6 49
4.4.1.1 Direcciones Unicast 49
4.4.1.2 Direcciones Multicast 52
4.4.1.3 Direcciones Anycast 53
4.4.2 Direcciones ipv6 para host y router 54
4.4.3 Direcciones únicas ULA (Unique Local Address) 55
4.4.4 Identificador de interfaz (IID) 56
4.4.5 Direcciones IPv4 e IPv6 equivalentes 58
4.4.6 Políticas de distribución y asignación 59
4.4.7 ¿Qué están haciendo los RIR y los ISP? 61
4.5 FUNCIONALIDADES DE IPv6 62
4.5.1 ICMPv6 (Internet Control Message Protocol) 62
4.5.2 Descubrimiento de Vecinos (Neighbor Discovery Protocol) 66
4.5.2.1 Descubrimiento de direcciones de capa de enlace 69
4.5.2.2 Descubrimiento de Routers y prefijos 69
4.5.2.3 Detección de direcciones duplicadas 70
4.5.2.4 Redireccionamiento 72
4.5.2.5 Autoconfiguración de direcciones stateless 72
4.5.3 DHCPv6 (Dynamic Host Configuration) 74
4.5.4 Path MTU Discovery 77
4.5.5 Jumbograms 78
4.5.6 Gestión del grupo Muticast 79
4.5.7 DNS (Domain Name System) 81
4.5.8 QoS (Quality Of Servise) 83
4.6 MOVILIDAD IPV6 85
4.7 SEGURIDAD EN IPv6 92
5. DESARROLLO INGENIERIL 97
5.1 INSTALACIÓN DE IPV6 97
5.1.1 Instalación de IPv6 en Windows XP/2003 97
5.1.2 Instalación IPv6 en Vista 98
5.1.3 Instalación IPv6 en Windows 7 100
5.1.4 Instalación IPv6 en Windows 2000 102
5.1.5 Comprobación de IPv6 – Windows 103
5.1.6 Configuración de IPv6 – Windows 104
5.2 SIMULADOR GNS3 107
5.2.1 Uso de GNS3 109
5.2.1.1 Emulación Router CISCO 109
5.2.1.2 Emulación de Switches Ethernet 115
5.2.1.3 Simulación de PC’s 118
5.2.1.4 Almacenamiento de topología 125
5.3 ENRUTAMIENTO IPv6 127
5.3.1 Consideraciones 127
5.3.2 ¿Cómo funciona el router? 130
5.3.3 Tabla de enrutamiento 132
5.3.4 Ruta por defecto 134
5.3.5 Enrutamiento Estático 135
5.3.5.1 Configuración de enrutamiento estático IPv6 135
5.3.6 Protocolos de Enrutamiento Interno 143
5.3.7 RIPng 143
5.3.7.1 Configuración RIPng 145
5.3.8 OSPFv3 (Open Shortes Path First Version 3) 149
5.3.8.1 Configuración OSPFV3 152
5.3.9 IS-IS (Intermediate System to Intermediate System) 156
5.3.10 Protocolo de enrutamiento externo 157
5.3.11 BGP (Border Gateway Protocol) 158
5.3.11.1 BGP Multiprotocolo 161
5.3.11.2 Tabla BGP 163
5.3.11.3 Configuración BGP 164
5.4 COEXISTENCIA Y TRANSICIÓN 170
5.4.1 Doble Pila 171
5.4.1.1 Configuración Dual-Stack (Doble Pila) 173
5.4.2 Técnicas de tunelizacion 177
5.4.3 Tunnel Broker 178
5.4.3.1 Túnel Broker con Hurricane Electric 178
5.4.3.2 Tunel Broker con GoGo6 183
5.4.4 Túnel 6to4 187
5.4.4.1 Configuración Tunel 6to4 198
5.4.5 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) 202
5.4.5.1 Configuración ISATAP 208
5.4.6 Teredo 212
5.4.7 GRE (Generic Routing Encapsulation) 219
5.4.7.1 Tunnel GNRE IPv6 221
5.4.8 Análisis comparativo entre las estrategias de transición 225
5.4.9 Técnicas de traducción 227
5.4.8.1 SIIT 227
5.4.8.2 BIS 227
5.4.8.3 BIA 228
5.4.8.4 TRT 228
6. CONCLUSIONES 230
7. RECOMENDACIONES 232
ANEXO A: Instalación y configuración de GNS3 en Windows XP 233
GLOSARIO 240
BIBLIOGRAFÍA 244
LISTA DE TABLAS
Pág.
Tabla 4.1: Clases de direcciones IPv4 12
Tabla 4.2: Diferencias entre IPv4 e IPv6 20
Tabla 4.3: Direcciones reservadas para Multicast 52
Tabla 4.4: Direcciones IPv4 equivalentes 58
Tabla 4.5: Mensajes de Error 63
Tabla 4.6: Mensajes de Información 64
Tabla 5.1 Tabla comparativa entre los simuladores usados 109
Tabla 5.2 Lista de adaptadores correspondientes a cada tipo
de plataforma 110
LISTA DE GRAFICAS
Pág.
Figura 4.1: Distribución Actual de Direcciones IPv6 24
Figura 4.2: Asignaciones de IPv6 de RIRs a ISPs (Septiembre 2010) 25
Figura 4.3: Cabecera IPv6 29
Figura 4.4: Cambio de Nombre en 4 Campos de la Cabecera 30
Figura 4.5: Cabecera de extensión 33
Figura 4.6: Cabecera de Opciones Salto a Salto 34
Figura 4.7: Cabecera de enrutamiento Genérica 36
Figura 4.8: Cabecera de enrutamiento Tipo 0 37
Figura 4.9: Cabecera de Fragmentación 39
Figura 4.10: Cabecera de Opciones de destino 40
Figura 4.11: Cabecera de Autenticación 41
Figura 4.12: Cabecera de Carga de Seguridad Encapsulada 42
Figura 4.13: Pseudo Cabecera TCP y UDP para IPv6 45
Figura 4.14: Descubrimiento de direcciones 69
Figura 4.15: Descubrimiento de Routers 70
Figura 4.16: Mensajes Binding 87
Figura 5.1: Instalación de IPv6 en Windows XP 98
Figura 5.2: Instalación Windows Vista 99
Figura 5.3: Instalación Windows 7 101
Figura 5.4: Índice correspondiente a cada Interfaz 104
Figura 5.5: Rutas configuradas en cada interfaz 107
Figura 5.6: ventana principal GNS3 112
Figura 5.7: Menú de opciones de un router 112
Figura: 5.8 Ventana de configuración del nodo 113
Figura: 5.9 Menú de opciones de un router 113
Figura 5.10: Menú de opciones de un router 114
Figura 5.11: Menú de opciones de un router 114
Figura 5.12: Menú de opciones de un router 114
Figura 5.13: Ventana principal GNS3 116
Figura 5.14: Menú de opciones de un switch 116
Figura 5.15: Ventana de configuración del nodo 117
Figura 5.16: Sección “settings” de la ventana de configuración del nodo 117
Figura 5.17 Comandos disponibles en VPC’s 119
Figura 5.18 configuración de los PC’s virtuales 119
Figura 5.19 Ventana de configuración nodo 120
Figura 5.20 Configuración de PCs virtuales 121
Figura 5.21 Configuración de PC’s virtuales 121
Figura 5.22 Tipos de enlaces disponibles 122
Figura 5.23 Interfaces disponibles en router 122
Figura 5.24 Ventana principal de GNS3 123
Figura 5.25 Menú de opciones de una nube 123
Figura 5.26 Ventana de configuración de nodo 124
Figura 5.27 ventana de cambio de nombres de host 125
Figura 5.28 Ventana de cambio de nombre de host 126
Figura 5.29 Comandos para guardar la configuración de routers 126
Figura 5.30 Ventana de almacenamiento configuraciones 126
Figura 5.31 Opciones de archivos 127
Figura 5.32 Ruteo estático IPv4 – Ipv6 138
Figura 5.33 Cabecera RIPng 145
Figura: 5.34 RIPng 146
Figura 5.35 Diagrama OPSFv3 150
Figura 5.36 Topología OSPFv3 152
Figura 5.37 Ejemplo topología BGP 159
Figura 5.38: BGP Multiprotocolo 165
Figura 5.39 Diagrama Dual Stack 172
Figura 5.40 Topología Dual Stack 174
Figura 5.41 Pagina Hurricane Electric 179
Figura 5.42 Registro Hurricane Electric 179
Figura 5.43 Registro completado 180
Figura 5.44 Creación del Túnel 180
Figura 5.45 Descripción del nuevo túnel creado 181
Figura 5.46 Detalles del túnel creado 181
Figura 5.47 Configuración del túnel en el Host 182
Figura 5.48: Pagina gogo6 183
Figura 5.49: Registro Gogo6 184
Figura 5.50: Verificación de solicitud por mail 184
Figura 5.51: Creación del perfil 185
Figura: 5.52 Descarga de un archivo setup 185
Figura: 5.53 Descarga de la aplicación para Windows 186
Figura: 5.54 Conexión al servidor Gogo6 186
Figura: 5.55 Prueba de conexión IPv6 187
Figura 5.56: Formato dirección 6to4 188
Figura 5.57: Comunicación entre clientes 6to4 que están en
redes diferentes 189
Figura 5.58: Comunicación cliente/router 6to4 con un servidor ipv6 191
Figura 5.59: Comunicación cliente 6to4 con un servidor ipv6 utilizando
solo un relay 6to4 (rutas de ida y vuelta iguales) 193
Figura 5.60: Comunicación cliente 6to4 con un servidor ipv6 utilizando
dos relays 6to4 diferentes (rutas de ida y vueltas diferentes) 196
Figura 5.61: Topología 6to4 198
Figura 5.62: Inicio ISATAP 203
Figura 5.63: Comunicación entre clientes ISATAP en la misma red 204
Figura 5.64: Comunicación entre clientes en redes diferentes 205
Figura 5.65: Comunicación entre clientes ISATAP y computadoras IPv6 207
Figura 5.66: Topología básica ISATAP 208
Figura 5.67: Formato de dirección teredo 213
Figura 5.68: Túnel Teredo 215
Figura 5.69: Comunicaciones a través de NAT tipo Cono 216
Figura 5.70: Comunicaciones a través de NAT restringido 218
Figura 5.71: Topología Tunnel GNRE IPv6 222
INTRODUCCIÓN
La versión 4 del protocolo de Internet (IPv4) proporciona los medios de
comunicación básicos dentro del conjunto de protocolos TCP/IP, siendo el
protagonista del desarrollo y la expansión de Internet en las últimas décadas. El
crecimiento masivo que ha sufrido Internet gracias a la diversificación en los
servicios que brinda y el incremento evidente en la cantidad de usuarios, ha
generado que el protocolo IPv4 deje al descubierto sus limitaciones. El protocolo
Ipv4 fue creado en la década de los 70’s como una forma de interconectar un
reducido número de redes, es decir nunca se pensó en que sería la base de una
red de millones de usuarios, desarrollando así el protocolo con un número
reducido de direcciones que junto a problemas de arquitectura han restringido y
limitado el desarrollo de nuevas aplicaciones y tecnologías en Internet.
Es por esto que se tuvo la necesidad de crear un nuevo protocolo, que añadiera
más y mejores características, por ejemplo, incrementar el número de direcciones
de Internet, incluir autenticación y encriptación de los datos para realizar
comunicaciones más seguras, etc. El 25 de Julio de 1994 Internet Engineering
Task Force (IETF), propuso un nuevo protocolo de comunicación en Internet,
llamado Internet de próxima generación (IPng) conocido años después como IPv6.
En Colombia el 3 de Diciembre de 2010 el MinTIC (Ministerio de Tecnologías de la
Información y las Comunicaciones) propició un evento denominado “Experiencias
internacionales en políticas para adopción del protocolo de interconectividad de
redes IPv6 aplicadas al caso colombiano”, en el cual se divulgo la creación de un
proyecto de resolución para la adopción de IPV6 en Colombia, en el que se
crearán políticas, regulaciones y objetivos para la completa apropiación del
protocolo IPv6.
A través del presente proyecto se plantea la idea de conocer en detalle el
funcionamiento del protocolo IPv6 y experimentar con él en la Universidad San
Buenaventura sede Bogotá, pues de acuerdo con el último reporte emitido por
LACNIC (Latin American and Caribbean Internet Addresses Center) el pasado 3
de Febrero del 2011, el stock central de direcciones IPv4 administrado por la IANA
(Internet Assigned Numbers Authority), ha quedado finalmente agotado, lo que
significa que los diferentes actores de Internet, tanto usuarios como ISPs (Internet
Service Providers) deberán comenzar a adoptar el protocolo IP versión 6 (IPv6).
Durante el desarrollo de este proyecto se estudiará el protocolo IPv6 y se
experimentará sobre sus diversos tópicos, con el fin de poder brindar a la
comunidad universitaria las herramientas básicas necesarias para impulsar y
fomentar las adopción del protocolo IPv6 en diferentes entornos, explicando de
manera clara los pasos y requerimientos para configurar e implementar la nueva
versión del protocolo IP en el ámbito que sea necesario. También se analizarán
las diferentes estrategias de transición IPv4/IPv6 para determinar cuáles son las
más convenientes y recomendables de utilizar. Todos los diseños desarrollados
serán simulados y podrán ser puestos a prueba antes de ser implementados.
1
1. PLANTEAMIENTO DEL PROBLEMA
1.1 ANTECEDENTES
A nivel internacional se han adelantando investigaciones con respecto a la
implementación de redes IPv6 para diferentes aplicaciones:
En la UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA en Chile se
desarrolló la investigación “Estudio e implementación de una red ipv6 en la
UTFSM”1. A través de este proyecto se diseñó e implementó correctamente una
red IPv6 operando en modalidad dual-stack, sobre la red institucional de la
UTFSM. La red permite conectar a las distintas unidades administrativas y
departamentos directamente a Internet mediante IPv6, sin necesidad de utilizar
túneles o traducción de protocolos.
Además, con el desarrollo de este trabajo los autores lograron comprobar que el
grado de desarrollo actual del protocolo IPv6 permite sin mayores contratiempos la
implementación de redes que funcionan únicamente sobre IPv6, ya que el soporte
IPv6 existente en los equipos de red, permite prescindir totalmente de IPv4 para la
totalidad de servicios que una red tradicionalmente ofrece, incluyendo funciones
avanzadas como MPLS, IPSec y Mobile IP, las cuales ya cuentan con soporte
oficial en redes IPv6.
El trabajo realizado demostró que es necesario hacer una revisión exhaustiva de
las alternativas al momento de actualizar o implementar una red IPv6. Se
descubrió que muchos fabricantes anuncian soporte IPv6 en sus productos, pero
en la realidad dicho soporte es parcial o se incluirá en futuras actualizaciones. En
1 Universidad Técnica Federico Santa María [Internet] [consultado 2 Julio de 2010] [Hora 11:28].
Disponible en
http://portalipv6.lacnic.net/files/documentos/ImplementacionIpv6_UTFSM_proyecto.pdf
2
dichos casos son útiles las iniciativas como el programa “IPv6 Ready” que
certifican el soporte IPv6 de equipos y programas, realizando una serie de pruebas
sobre ellos.
También en este trabajo se trato el tema de la seguridad en las redes IPv6. A
pesar del gran avance que se ha hecho en este tema en los últimos años, fue
posible constatar que aún existen problemas y vulnerabilidades importantes en las
redes IPv6. Los ataques presentados hacen necesario tomar las debidas
precauciones cuando se implementan redes IPv6 a gran escala. Se constató que
faltan soluciones para contrarrestar eficazmente las vulnerabilidades del protocolo
ICMPv6 (Internet Control Message Protocol version 6).
En la UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO2 se han estado
desarrollando investigaciones sobre IPv6 desde 1998, siendo la red de esta
universidad el primer nodo 6Bone (red IPv6 internacional de carácter
experimental) en México, lo cual se registró en junio de 1999. Posteriormente en
septiembre del mismo año, a partir de resultados de pruebas realizadas por su
propia trayectoria en telecomunicaciones e importancia académica, la Universidad
Nacional Autónoma de México fue aceptada como uno de los 100 backbones que
a la fecha operan en 6Bone, obteniendo un rango de direcciones tipo TLA (Top
Level Aggregation). Con este tipo de direcciones, la Universidad Nacional
Autónoma de México ha podido delegar bloques y configurar túneles a
instituciones en México y en el mundo, interesadas en realizar pruebas con IPv6,
lo que constituye un paso muy importante en el uso y desarrollo del nuevo
protocolo en el continente americano.
2 Universidad Nacional Autónoma de México [Internet] [consultado 10 Julio de 2010] [Hora 3:42].
Disponible en http://www.cu.ipv6tf.org/casos/IPv6_UNAM.pdf
3
En el ámbito educativo la UNIVERSIDAD AUSTRAL DE CHILE ha desarrollo un
trabajo llamado “Modelo de Tele-enseñanza utilizando protocolo IPv6”3,
exponiendo el desarrollo de una herramienta telemática de migración de IPv4 a
IPv6, la cual consiste en la actualización de librerías, pizarra virtual y un canal de
comunicación sobre el protocolo de Internet RTP (Real Time Transport Protocol),
para enviar en tiempo real la información al receptor. Además de abarcar la
interacción alumno-profesor, se pretende aportar al desarrollo de actividades
relacionadas con teleconferencia, motivando su aplicación en otras áreas.
Aprovechando la capacidad del protocolo IPv6 de brindar soportes para
dispositivos multimedia como audio conferencia, pizarra virtual, dispositivos
móviles, etc., en tiempo real, lograron la implementación de un prototipo que utiliza
tanto la comunicación entre profesor-alumno a través de un canal de texto, como
la pizarra virtual en un aula virtual con la incorporación de las TICs, utilizando IPv6
como protocolo de comunicación.
A nivel nacional se han adelantando investigaciones con respecto a la
implementación de redes IPv6 para diferentes aplicaciones:
En la UNIVERSIDAD DEL VALLE en Cali se desarrolló el proyecto “MANEJO A
TRAVÉS DE INTERNET DEL ROBOT “MICROBOT TEACHMOVER” USANDO
UN SISTEMA EMBEBIDO CON INTERFAZ BLUETOOTH Y EL PROTOCOLO
IPv6”4. Este proyecto trabaja la manipulación del robot “Microbot Teachmover” a
través de una aplicación de computador que permite la interacción con éste tanto
de una manera local como remota, así como también el manejo de dicho robot a
través de una aplicación desarrollada en un dispositivo móvil. El objetivo era la
utilización de los protocolos BNEP (Bluetooth Networking Encapsulation Protocol)
3 Universidad Austral de Chile [Internet] [consultado 13 Julio de 2010] [Hora 23:40]. Disponible en
http://cybertesis.uach.cl/tesis/uach/2006/bmfciv473m/doc/bmfciv473m.pdf
4 Universidad del Valle [Internet] [consultado 16 Julio de 2010] [Hora 21:15]. Disponible en
http://www.univalle.edu.co/~telecomunicaciones/trabajos_de_grado/anteproyectos/anteproyecto_T
G-0417.pdf
4
e IPv6 con el fin de tener una pila de protocolos que permitiera la interconexión de
varios dispositivos de forma inalámbrica bajo el protocolo IP, permitiendo llevar el
desarrollo existente sobre Bluetooth hacia la convergencia IP.
1.2 DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA
IPv4 ha demostrado con el paso del tiempo ser un protocolo de gran capacidad,
pues aunque en un principio IPv4 fue creado con la idea de interconectar redes
simples, ha sido capaz de soportar el crecimiento desmedido de Internet. Sin
embargo, en los últimos años han sobresalido diversos problemas existentes en
IPv4 asociados con el crecimiento de Internet, como la falta de seguridad y el
nacimiento de nuevas tecnologías y servicios que requieren conectividad IP.
El problema más evidente y reconocido del protocolo IPv4, es el agotamiento del
espacio de direcciones gracias al crecimiento exponencial de Internet y a los
ineficientes métodos de asignación de direcciones IP por clases, en los que se
asignaron grandes bloques de direcciones a organizaciones que solo requerían
unas pocas. Esto obligó a las organizaciones a utilizar el traductor de direcciones
de red NAT (Network Address Traslator), con el fin de asignar múltiples
direcciones privadas a una o varias direcciones IP públicas. Es por esto que se ha
impulsado la creación de nuevas tecnologías como el direccionamiento sin clase,
las direcciones CIDR (Classless Inter-Domain Routing) e IPv6.
Con el paso del tiempo también ha sido necesario introducir modificaciones y
protocolos complementarios a IPv4, pues el crecimiento en los requerimientos del
usuario que utiliza Internet hace necesarias nuevas capacidades, tales como la
seguridad, ya que servicios como el comercio electrónico, que ha tenido un gran
auge en los últimos años, exige a la red completa privacidad en la transferencia de
datos.
5
IPv6 es una manera potencial de reducir al mínimo los problemas presentes en el
protocolo IPv4. Es por esto que la Universidad San Buenaventura sede Bogotá,
dado su nivel tanto educativo como investigativo, tiene el deber de fomentar la
utilización del protocolo IPv6, aportando el conocimiento y la experiencia
necesaria, con el fin de capacitar personas que puedan promover la transición
hacia este protocolo a nivel nacional, impulsando así avances tecnológicos con el
propósito de generar aplicaciones innovadoras.
¿Cuál es la mejor forma realizar la transición de una red IPv4 a una red que
soporte IPv6?
1.3 JUSTIFICACIÓN
El nuevo protocolo IPv6, dispone de 340 billones de billones de billones de
direcciones, lo que hace que la cantidad de direcciones IPv4 parezca
insignificante. Con este mayor espacio de direcciones, IPv6 ofrece una variedad
de ventajas en términos de estabilidad y flexibilidad en la operación de las redes y
simplicidad en su administración. También es probable que la “era IPv6” genere
una nueva ola de innovación en la creación de aplicaciones y en oferta de
servicios. Pero es imposible deshabilitar todas las redes IPv4 y actualizarlas a
IPv6 al mismo tiempo. Es por esto que es necesario un proceso de migración, el
cual debe realizarse en forma gradual y progresiva.
Este proyecto pretende ser un primer paso hacia el desarrollo investigativo sobre
el protocolo IPv6 en la Universidad San Buenaventura, promoviendo y
construyendo conocimiento, con el fin de abrir puertas a nuevos productos,
servicios y aplicaciones, que serán desarrollados en el futuro gracias a todas la
ventajas que este protocolo brinda.
6
1.4 OBJETIVOS DE LA INVESTIGACIÓN
1.4.1. Objetivo General
Investigar y Simular el funcionamiento de las diferentes estrategias de transición
del protocolo IPv4 al protocolo IPv6 para las diferentes topologías típicas de red
posibles e implementarlas a nivel de laboratorio
1.4.2. Objetivos Específicos
Analizar el protocolo IPv6 en cuanto a sus objetivos, funcionamiento,
estructura, encabezados de capa de red y direccionamiento.
Realizar una descripción detallada y comparativa de los mecanismos de
migración y convivencia propuestos por la IETF como son: Pila (Dual-
Stack), Traducción de encabezados y Tunneling.
Implementar en el laboratorio diversos ejemplos de casos típicos.
Modelar, simular e implementar a nivel de laboratorio, los mecanismos de
migración en diversas topologías de red con el objetivo de comprender y
evaluar su comportamiento individual y poder compararlos entre sí,
mediante la medición de eventos generados, para determinar cuál es el
más adecuado dependiendo de la topología de red.
1.5 ALCANCES Y LIMITACIONES DEL PROYECTO
Este proyecto se realiza con la finalidad de conocer el funcionamiento del
protocolo IPv6, sus características y a su vez comprobar los mecanismos de
transición que ayudaran a acelerar el proceso de migración. Todos los diseños
que se realicen, será simulados para que puedan ser debidamente evaluados. El
7
objetivo de este proyecto no es la implementación de una red IPv6 en la
universidad; más bien el interés es brindar las pautas tanto teóricas como
prácticas necesarias para una futura transición.
Es importante aclarar que para las simulaciones de las redes diseñadas con base
en el nuevo protocolo IPv6, se depende del grado de desarrollo que tengan
actualmente tanto el protocolo como los simuladores de red.
También es necesario aclarar que para la realización de las implementaciones a
nivel de laboratorio y para la posible ejecución de algunas pruebas se requiere de
la completa colaboración del administrador de la red de la USB. En caso contrario
se tendrá limitaciones.
8
2. METODOLOGIA
El desarrollo de este proyecto tiene un enfoque empírico-analítico el cual tiene un
interés técnico, orientado a la interpretación y transformación del mundo material.
Proporciona además una estructura particular a la metodología de investigación
en tanto que orienta el trabajo a la contrastación permanente de las aseveraciones
teóricas con la verificación experimental, de manera que los cálculos generados a
través de modelos matemáticos y simulaciones computacionales se deben
retroalimentar con la experimentación, en la búsqueda de información cada vez
más confiable y práctica para la solución del problema.
9
3. LINEA DE INVESTIGACION DE USB / SUB-LINEA DE FACULTAD /
CAMPO TEMATICO DEL PROGRAMA
Línea institucional-tecnologías actuales y sociedad
La sociedad requiere de conocimientos técnicos y científicos de vanguardia que
ayuden a la solución de problemas o faciliten los procesos de mejoramiento de la
calidad de vida de las personas que pertenecen a un grupo social determinado.
Sub-Línea de Facultad-Sistemas de Información y Comunicación.
Con este proyecto se pretende conocer y utilizar correctamente los más modernos
protocolos y sistemas de información utilizados en las redes de comunicación, con
el fin de lograr mejoras tecnológicas que permitan desarrollar proyectos orientados
a satisfacer necesidades específicas, para así, atender los requerimientos del
sector empresarial o industrial en la implementación o mejoramiento de este tipo
de sistemas.
Campo Temático del Programa-Comunicaciones
El desarrollo de este proyecto está relacionado con los elementos capaces de
llevar o traer información a través del aire o de ductos específicos, de acuerdo con
las necesidades, capacidad y forma de la información que deben manejar los
usuarios.
10
4. MARCO TEORICO Y CONCEPTUAL
4.1 EL PROTOCOLO IPV4 Y SUS LIMITACIONES
4.1.1 Nacimiento del Protocolo IPv4 y Agotamiento de Direcciones
En 1966 el Departamento de Defensa (DoD - Department of Defense) del gobierno
de Estados Unidos, a través de su Agencia de Investigación de Proyectos
Avanzados (ARPA - Advanced Research Projects Agency), inició un proyecto para
interconectar las computadoras de los centros militares y de investigación. Este
sistema de comunicación y control distribuido con fines militares recibió el nombre
de ARPANET, su principal objetivo teórico era crear una arquitectura de red sólida
y robusta que, incluso en caso de falla de alguna estación, pudiera trabajar con las
computadoras y enlaces restantes. En 1969 se instalaron los primeros cuatro
nodos de la red en la Universidad de Los Ángeles (UCLA), la Universidad de
California en Santa Bárbara (UCSB), el Instituto de Investigaciones de Standford
(SRI) y la Universidad de Utah.
En sus inicios, ARPANET trabajaba con diferentes protocolos de comunicación,
siendo NCP (Network Control Protocol) el principal. El primero de enero 1983,
cuando la red ya contaba con 562 hosts, todas las máquinas de ARPANET
adoptaron como estándar los protocolos TCP/IP, permitiendo así el crecimiento
ordenado de la red y eliminando las restricciones que presentaban los protocolos
anteriores.
El protocolo IP tiene dos funciones básicas: la fragmentación, que permite enviar
paquetes mayores que el límite de tráfico establecido para un enlace dividiéndolos
en paquetes más pequeños, y el direccionamiento, que permite identificar el
destino y el origen de los paquetes con base en la dirección almacenada en el
encabezado del protocolo. La versión del protocolo IP que se utilizaba en aquella
época y continúa utilizándose en la actualidad es la versión 4 o IPv4. Esta versión
11
demostró ser muy robusta, de fácil implementación e interoperabilidad, sin
embargo el proyecto original no previó algunos aspectos tales como:
El crecimiento de las redes y el posible agotamiento de las direcciones IP
El crecimiento de la tabla de enrutamiento
Problemas relacionados con la seguridad de los datos transmitidos
Prioridad en la entrega de determinados tipos de paquetes
Las especificaciones de IPv4 reservan 32 bits para direccionamiento, permitiendo
generar más de 4 mil millones de direcciones diferentes. Inicialmente, estas
direcciones se dividieron en tres clases de tamaño fijo de la siguiente manera:
Clase A: Definía el bit más significativo como 0, utilizaba los 7 bits restantes
del primer octeto para identificar la red y los 24 bits restantes para identificar el
host. Estas redes utilizaban el rango de 1.0.0.0 a 126.0.0.0
Clase B: Definía los 2 bits más significativos como 10, utilizaba los 14 bits
siguientes para identificar la red y los 16 bits restantes para identificar el host.
Estas redes utilizaban el rango de 128.1.0.0 a 191.254.0.0
Clase C: Definía los 3 bits más significativos como 110, utilizaba los 21 bits
siguientes para identificar la red y los 8 bits restantes para identificar el host.
Estas redes utilizaban el rango de 192.0.1.0 a223.255.254.0
Aunque la intensión de esta división era flexibilizar la distribución de direcciones
abarcando redes de diferentes tamaños, este tipo de clasificación demostró ser
ineficiente. Así, la clase A atendía un número muy pequeño de redes pero
ocupaba la mitad de todas las direcciones disponibles. Para direccionar 300
dispositivos en una red era necesario obtener un bloque de direcciones clase B,
12
con lo cual se desperdiciaba prácticamente la totalidad de las 65 mil direcciones; y
las 256 direcciones clase C no satisfacían las necesidades de la gran mayoría de
las redes. La tabla 4.1 muestra la totalidad de redes y direcciones en cada clase.
Tabla 4.1: Clases de direcciones IPv4
CLASE FORMATO REDES HOSTS
A
7 Bits Redes, 24 Bits
Host 128 16 777 216
B
14 Bits Redes, 16 Bits
Host 16 384 65 536
C
21 Bits Redes, 8 Bits
Host 2 562 097 152 256
Otro factor que contribuyó al desperdicio de direcciones fue el hecho de que
decenas de rangos clase A fueron asignados íntegramente a grandes
organizaciones tales como IBM, AT&T, Xerox, HP, Apple, MIT, Ford, el
Departamento de Defensa de Estados Unidos, entre muchas otras, poniendo a
disposición de cada una de ellas 16 777 216 millones de direcciones.
En 1990 ya había 313.000 hosts conectados a la red y algunos estudios
comenzaban a hablar de un colapso provocado por la falta de direcciones. Otros
problemas tales como el crecimiento de la tabla de enrutamiento también se
agudizaban a medida que Internet evolucionaba.
Debido a la tasa de crecimiento de Internet y a la política de distribución de
direcciones, en mayo de 1992 ya se habían distribuido 38% de los rangos de
direcciones clase A, 43% de la clase B y 2% de la clase C. En esa época ya había
1.136.000 hosts conectados a la red.
13
En 1993, la creación del protocolo HTTP (Hypertext Transfer Protocol) y la
liberación de Internet por parte del Gobierno de Estados Unidos para su utilización
comercial produjeron un salto aun mayor en la tasa de crecimiento de la red, que
pasó de 2.056.000 de hosts en 1993 a más de 26.000.000 de hosts en 1997.
4.1.2 Soluciones al agotamiento de direcciones
Ante este escenario la IETF (Internet Engineering Task Force) comenzó a debatir
estrategias para resolver el tema del agotamiento de las direcciones IP y el
problema del crecimiento de la tabla de enrutamiento. Para ello, en noviembre de
1991 se formó el grupo de trabajo ROAD (ROuting and ADdressing), que para
solucionar estos problemas propuso la utilización de CIDR (Classless Inter-domain
Routing).
Las ideas básicas del CIDR eran poner fin al uso de clases de direcciones para
permitir la distribución de bloques de tamaño adecuado a las necesidades reales
de cada red y la agregación de rutas para reducir el tamaño de la tabla de
enrutamiento. Los bloques CIDR se identifican mediante prefijos de red. Por
ejemplo, en la dirección a.b.c.d/x, los x bits más significativos indican el prefijo de
red. Otra manera de indicar el prefijo es a través de máscaras, donde la máscara
255.0.0.0 indica un prefijo /8, 255.255.0.0 indica un /16, y así sucesivamente.
Otra solución, presentada por la IETF fue el protocolo DHCP (Dynamic Host
Configuration Protocol). A través del protocolo DHCP un host puede obtener una
dirección IP automáticamente y adquirir información adicional como por ejemplo la
máscara de subred, la dirección del router por defecto y la dirección del servidor
DNS local.
DHCP ha sido muy utilizado por los ISPs debido a que les permite asignar
direcciones IP temporarias a sus clientes conectados. De esta forma ya no es
14
necesario obtener una dirección para cada cliente, sino que basta con asignar
direcciones dinámicamente a través del servidor DHCP.
Este servidor tendrá una lista de direcciones IP disponibles: cada vez que un
nuevo cliente se conecte a la red le será asignada una de estas direcciones de
forma aleatoria, dirección que será devuelta en el momento en que el cliente se
desconecte.
NAT (Network Address Translation) fue otra técnica desarrollada para resolver el
problema del agotamiento de las direcciones IPv4. La idea básica es permitir que
varios hosts puedan salir a Internet utilizando una única dirección IP pública o a
través de un número pequeño de estas direcciones. Dentro de una red, cada
equipo recibe una dirección IP privada única que es utilizada para enrutar el tráfico
interno. Sin embargo, cuando un paquete debe ser enrutado fuera de la red, las
direcciones IP privadas se traducen a direcciones IP públicas globalmente únicas.
Para que este esquema sea posible se utilizan los tres rangos de direcciones IP
declarados como privados, siendo la única regla de utilización que ningún paquete
que contiene estas direcciones puede atravesar la Internet pública. Los tres
rangos reservados son los siguientes:
10.0.0.0 a 10.255.255.255 /8
172.16.0.0 a 172.31.255.255 /12
192.168.0.0 a 192.168.255.255 /16
El uso de NAT demostró ser eficiente en cuanto a la economía de direcciones IP,
además de presentar algunos otros aspectos positivos tales como facilitar la
numeración interna de las redes, ocultar la topología de las redes y solo permitir la
entrada de paquetes generados en respuesta a una solicitud de la red. No
15
obstante, el uso de NAT presenta inconvenientes que no compensan las ventajas
que ofrece.
NAT rompe con el modelo end-to-end de Internet ya que no permite conexiones
directas entre dos hosts, lo que dificulta el funcionamiento de una serie de
aplicaciones tales como P2P (Peer-to-Peer), VoIP (Voice Over IP) y VPN (Virtual
Private Network). Otro problema es la baja escalabilidad, ya que el número de
conexiones simultáneas es limitado y además requiere una gran capacidad de
procesamiento por parte del dispositivo traductor. El uso de NAT también
imposibilita rastrear el camino del paquete mediante herramientas como traceroute
y dificulta la utilización de algunas técnicas de seguridad como IPSec (Internet
Protocol Security). Además, su uso genera una falsa sensación de seguridad ya
que, a pesar de no permitir la entrada de paquetes no autorizados, NAT no realiza
ningún tipo de filtrado ni verificación de los paquetes que lo atraviesan.
Aunque estas soluciones han disminuido la demanda de direcciones IP, no han
sido suficientes para resolver los problemas derivados del crecimiento de Internet.
De hecho, estas medidas permitieron que hubiera más tiempo para desarrollar una
nueva versión del protocolo IP, una versión que se basara en los principios que
contribuyeron al éxito de IPv4 pero que también fuese capaz de superar las fallas
que se detectaron.
4.2 INTRODUCCIÓN AL PROTOCOLO IPV6
4.2.1 Nacimiento del Protocolo IPv6
En diciembre de 1993 la IETF formalizó las investigaciones sobre la nueva versión
del protocolo IP solicitando el envío de proyectos y propuestas para el nuevo
protocolo. Esta fue una de las primeras acciones del grupo de trabajo de la IETF
16
denominado Internet Protocol next generation (IPng). Los principales aspectos que
debían ser abordados al elaborar la siguiente versión del protocolo IP eran:
Escalabilidad
Seguridad
Configuración y Administración de Redes
Soporte para QoS
Movilidad
Políticas de Enrutamiento
Transición
Varios proyectos comenzaron a estudiar los efectos del crecimiento de Internet.
Entre estos se destacaron CNAT, IP Encaps, Nimrod y Simple CLNP. De estas
propuestas surgieron el TCP and UDP with Bigger Addresses (TUBA), que fue una
evolución de Simple CLNP, y el IP Address Encapsulation (IPAE), una evolución
de IP Encaps. Algunos meses después se presentaron los proyectos Paul’s
Internet Protocol (PIP), Simple Internet Protocol (SIP) y TP/IX.
Una nueva versión del protocolo SIP, que englobaba algunas funcionalidades de
IPAE fue presentada poco antes de agregarse al PIP, obteniéndose como
resultado el Simple Internet Protocol Plus (SIPP). En este mismo período TP/IX
pasó a llamarse Common Architecture for the Internet (CATNIP).
En enero de 1995, el IPng presentó un resumen de la evaluación de las tres
principales propuestas:
CATNIP – Fue concebido como un protocolo de convergencia para permitir
que cualquier protocolo de la capa de transporte se ejecutara sobre cualquier
protocolo de la capa de red, creando así un ambiente común entre los
protocolos de Internet, OSI y Novell.
17
TUBA – Proponía aumentar el espacio para direccionamiento IPv4 y volverlo
más jerárquico, intentando evitar la necesidad de modificar los protocolos de la
capa de transporte y aplicación. Pretendía una migración simple y a largo
plazo, basada en la actualización de los host y servidores DNS pero sin
necesidad de encapsulado o traducción de paquetes ni mapeo de direcciones
SIPP – Concebido para ser una etapa evolutiva del protocolo IPv4, sin cambios
radicales y conservando la interoperabilidad con la versión 4 del protocolo IP,
proveía una plataforma para nuevas funcionalidades de Internet, aumentaba el
espacio para direccionamiento de 32 bits a 64 bits, presentaba un mayor nivel
de jerarquía y estaba compuesto por un mecanismo que permitía “ampliar la
dirección” denominado cluster addresses. Ya tenía encabezados de extensión
y un campo flow para identificar el tipo de flujo de cada paquete.
Sin embargo, las tres propuestas también presentaban problemas significativos.
Finalmente, la recomendación para el nuevo Protocolo de Internet se basó en una
versión revisada del SIPP, que pasó a incorporar direcciones de 128 bits, junto
con los elementos de transición y autoconfiguración del TUBA, el direccionamiento
basado en CIDR y los encabezados de extensión. El protocolo CATNIP fue
descartado por ser considerado muy incompleto.
A raíz de esta definición, la nueva versión del Protocolo de Internet pasó
oficialmente a llamarse IPv6.
4.2.2 Descripción y características del Protocolo IPv6
Las especificaciones de IPv6 fueron inicialmente presentadas en diciembre de
1995 y reestructuradas en diciembre de 1998. Entre sus principales características
se destacan:
18
Mayor capacidad de direccionamiento: el espacio de direccionamiento
aumentó de 32 bits a 128 bits, permitiendo: niveles más específicos de
agregación de direcciones, identificar una cantidad mucho mayor de
dispositivos en la red e implementar mecanismos de autoconfiguración.
También se mejoró la escalabilidad del enrutamiento multicast mediante la
adición del campo "alcance" (o ámbito) en la dirección multicast. También se
definió un nuevo tipo de direcciones, las direcciones anycast.
Simplificación del formato del encabezado: con el objetivo de reducir el
costo de procesamiento de los paquetes en los routers, algunos campos del
encabezado IPv4 se eliminaron o se convirtieron en opcionales.
Soporte para encabezados de extensión: las opciones dejaron de formar
parte del encabezado base, permitiendo un enrutamiento más eficaz, límites
menos rigurosos en cuanto al tamaño y la cantidad de opciones y una mayor
flexibilidad para la introducción de nuevas opciones en el futuro.
Capacidad de identificar flujos de datos: se agregó un nuevo recurso que
permite identificar paquetes que pertenecen a determinados flujos de tráfico
que pueden requerir tratamientos especiales
Direccionamiento eficiente y jerárquico: IPv6 posee una estructura de
enrutamiento eficiente y jerárquica que permite a los routers principales que
trabajan en el Internet, poseer tablas de enrutamiento más pequeñas de
acuerdo con la infraestructura que tenga cada ISP.
Autoconfiguración: Las direcciones IPv6 pueden ser configuradas
manualmente o en forma automática, aún en ausencia de un router. Esto
debido a que si se desea, los hosts pueden autoconfigurarse con direcciones
de enlace-local (link-local addresses).
19
Soporte para autenticación y privacidad: se especificaron encabezados de
extensión capaces de proveer mecanismos de autenticación y garantizar la
integridad y confidencialidad de los datos transmitidos.
QoS: El tráfico es priorizado mediante el campo “clase de tráfico” (Traffic
Class). Además, un campo de la cabecera de los datagramas IPv6 permite a
los routers identificar y proporcionar un tratamiento especial a los paquetes que
pertenecen a un determinado flujo.
Interacción con nodos vecinos: Mediante un protocolo llamado Neighbor
Discovery (ND), IPv6 puede manejar una serie de mensajes que permiten la
interacción de nodos vecinos entre sí y de estos nodos con los routers
conectados a la red.
Extensibilidad: IPv6 puede ser fácilmente modificado, ya que añadiendo
extensiones a la cabecera IPv6 se puede obtener nuevas características para
el protocolo.
Además, IPv6 también modificó el tratamiento de la fragmentación de los paquetes
que pasó a ser realizada sólo en el origen, permitiendo el uso de conexiones
extremo a extremo, principio que se había roto en IPv4 debido al uso generalizado
de NAT. También aportó recursos para facilitar la configuración de redes.
4.2.3 IPV4 frente a IPV6
IPv6 mantiene varias de las funciones usadas en IPv4; en cambio, funciones que
eran usadas en muy pocas ocasiones o no eran usadas han sido eliminadas. Esto
permite añadirle a este nuevo protocolo nuevas características que provean
nuevas funcionalidades para la comunicación a través del Internet.
20
Las diferencias más importantes entre IPv4 e IPv6 se muestran en la Tabla 4.2 a
continuación:
Tabla 4.2: Diferencias entre IPv4 e IPv6
IPv4 IPV6
Las direcciones de origen y
destino tienen una longitud de 32
bits (4 bytes).
Las direcciones de origen y destino
tienen una longitud de 128 bits (16
bytes).
La implementación de IPSec es
opcional.
La implementación y soporte para
IPSec es obligatorio.
La cabecera del datagrama no
contiene mecanismos para la
identificación de flujo de paquete
para ofrecer QoS.
La Identificación de flujos de
paquete está presente en la
cabecera IPv6 usando el campo
"Flow Label", con lo cual se puede
ofrecer QoS.
La fragmentación involucra tanto al
host como a los routers, de modo
que este proceso produce retardos
en el rendimiento del router.
El proceso de fragmentación
solamente involucra a los hosts de
origen y destino.
No tiene ningún requisito para el
tamaño de un paquete de capa de
enlace y debe ser capaz de
reensamblar un paquete de 576
bytes.
La capa de enlace de soportar un
paquete de 1280 bytes de tamaño y
debe ser capaz de reensamblar un
paquete de 1500 bytes.
La cabecera incluye un checksum
para el control, de errores que
debe ser recalculado en cada
router.
La cabecera no incluye Checksum.
21
La cabecera incluye campos
llamados
opciones.
Todos los datos opcionales son
movidos a cabeceras de extensión.
ARP envía tramas broadcast para
realizar peticiones ARP de modo
que se pueda resolver una
dirección IPv4 en una dirección de
capa física.
Las tramas para solicitar peticiones
ARP son reemplazadas con
mensajes multicast
"Neighbor Discovery".
IGMP (Internet Group
Management Protocol) es usado
para manejar grupos de subredes
locales.
IGMP es reemplazado por MLD
(Multicast
Listener Discovery) que es un set de
mensajes que son intercambiados
por los routers para descubrir
direcciones multicast.
ICMP Router Discovery es usado
para
determinar la dirección IPv4 del
mejor
"gateway" y es opcional.
ICMPv4 es reemplazado por
mensajes ICMPv6 y es
necesariamente requerido.
Las direcciones de broadcast son
utilizadas para enviar tráfico a
todos los
nodos en una subred.
No existen direcciones IPv6 de
broadcast, en su lugar se emplean
direcciones multicast que permiten
comunicación con todos los nodos
del enlace.
Las direcciones deben ser
configuradas
manualmente o mediante DHCP.
La configuración de direcciones
puede ser manual, a través de
DHCP o mediante
autoconfiguración.
22
Usa recursos de registros de
direcciones
de host A para asignar nombres a
direcciones IP a través de DNS.
Usa registros AAAA para asignar
nombres a direcciones IPv6 a través
de DNS.
4.2.4 Estado de adopción de IPv6
El despliegue de IPv6 se inicio en el año 2002, momento en el cual ya se podía
considerar estandarizado en los aspectos básicos que prácticamente lo igualaban
a IPv4.
En ese momento, la mayoría de los fabricantes de Sistemas Operativos ofrecían
IPv6 en sus productos, al igual que los fabricantes de equipamiento de redes
(enrutadores fundamentalmente), con diferentes grados de madurez y soporte
técnico y/o comercial.
En ese mismo año se produjeron los primeros grandes despliegues en el mundo,
siendo el caso más relevante posiblemente el de NTT (en Japón), que no sólo
ofreció IPv6 en sus redes “intercontinentales”, sino que para poder lanzar los
servicios comerciales de IPTV, decidió que era más viable utilizar multicast
(multidifusión) IPv6, aún cuando hubiera que desplegarlo partiendo de cero, que
usar multicast IPv4.
La situación actual es que el 99% de los grandes carriers (los denominados “tier
1”), ofrecen IPv6, muchos de ellos desde hace varios años, en sus redes
intercontinentales y en muchos casos regionales, mientras que sólo algunos
proveedores de Internet nacionales (aunque es difícil de estimar, quizás un 20%
en todo el mundo), proporcionan el servicio y cuando lo proporcionan, muy pocos
lo ofrecen en la “última milla”, salvo para clientes corporativos.
23
Esto es debido fundamentalmente a que los CPEs (Customer Premises
Equipment), han sido los equipos con mayor demora en su introducción comercial,
y especialmente los de gama baja, que son los que habitualmente suministran los
ISPs a los clientes residenciales. Esta situación ha cambiado radicalmente en los
últimos dos años.
También existen numerosos ISPs realizando pilotos con diferentes números de
usuarios, algunos de ellos muy importantes, como Comcast y TMobile. Los
proveedores de contenidos dieron sus primeros pasos en el año 2.006,
anticipándose Google, que desde hace ya 3 años ofrece sus servicios con IPv6,
seguido FaceBook, Netflix, Yahoo, CNN y eBay entre otros.
Del mismo modo diversas prensas online, radios y TV por Internet, por supuesto
incluyendo YouTube, soportan IPv6. Del mismo modo, algunos proveedores de
“Content Delivery Networks” (CDNs o Redes Suministradoras de Contenidos), en
las que se basan grandes proveedores de contenidos, como Limelight Networks
ya ofrecen soporte de IPv6 y otros como Akamai, los han anunciado para los
próximos meses. Similar es el caso de grandes proveedores de servicios de
“hosting” y “housing”.
Por último, desde el punto de vista de servicios de infraestructura de la Red, el
otro servicio que es importante, DNS (Domain Name System, “Sistema de
Nombres de Dominio”), está preparado desde hace años en lo que se denomina la
Raíz (root), así como en la mayoría de los TLDs (Top Level Domains). Es decir, en
los dominios genéricos y en más del 65% de los dominios de países, con la
notable excepción (si nos fijamos en los ccTLDs de mayor número de dominios
registrados), de España (.es).
IANA, siguiendo indicaciones del IETF y de acuerdo con políticas globales, ha
entregado a los RIR’s (Registros Regionales de Internet), bloques IPv6 para su
24
distribución a los ISPs de la región. La última entrega de un prefijo /12 para cada
RIR, se produjo en el 2006 y se espera que esta entrega sea suficiente para
muchos años.
Figura 4.1: Distribución Actual de Direcciones IPv6
Fuente: www.lacnic.net
A su vez, los RIRs entregan a los ISPs bloques con una longitud de prefijo de 32
bits o menores, según la necesidad justificada por el ISP. Dado que los ISPs
entregan prefijos de 48 bits a los usuarios, con un bloque /32 un ISP puede
direccionar aproximadamente 65.535 clientes; con un /31 el doble y así
sucesivamente. Para facilitar la uniformidad de las estadísticas, estas se realizan
utilizando como base un prefijo /32.
Figura 4.2: Asignaciones de IPv6 de RIRs a ISPs (Septiembre 2010)
Fuente: www.lacnic.net
25
Otra cuestión muy importante es el aspecto de qué proporción del tráfico de
Internet utiliza IPv6. La problemática estriba en que, por cuestiones técnicas
inherentes al diseño del protocolo y su coexistencia con IPv4, cuando la última
milla de ambos extremos de una determinada comunicación no tiene IPv6
habilitado, que es la situación más habitual hoy en día, aunque los ISPs no estén
dando servicio IPv6, entran en funcionamiento los denominados mecanismos de
transición, algunos de los cuales son automáticos (o bien otros configurados por
los usuarios). Es por ello que ante la pregunta de cuánto tráfico IPv6 tienen en sus
redes los grandes carriers, que ya ofrecen servicio IPv6, la respuesta suele estar
entre el 3 y el 5%. Sin embargo, algunos estudios (6METER, RIPE55) demuestran
que si se mide el tráfico IPv6 encapsulado en IPv4 (el que se genera con los
mecanismos de transición), que por otro lado no es nada fácil de medir, hay
niveles de tráfico que llegan a superar el 35%. Este tráfico es fundamentalmente
peer‐to‐peer, pero con la disponibilidad de contenidos en IPv6 (ejemplo, YouTube),
también está creciendo de manera muy significativa el tráfico cliente-servidor.
4.2.5 ¿Por qué no se despliega IPv6 con mayor rapidez?
Se ha comentado que la infraestructura de las grandes redes está preparada, y
que ya se genera tráfico IPv6. Se debe añadir que dicho tráfico se incrementa
rápidamente, dado que todos los Sistemas Operativos tienen IPv6 activado por
defecto (con la excepción de RIM/BlackBerry) y por definición de los estándares,
cuando un servicio (ya sea cliente en caso de peer‐to‐peer o servidor en caso de
cliente‐servidor), está habilitado tanto con IPv4 como con IPv6, tiene preferencia
utilizar IPv6. Es decir, el tráfico IPv6 va ganando terreno paulatinamente al tráfico
IPv4, en teoría de una forma transparente para los usuarios, aún cuando los ISPs
no desplieguen IPv6.
Esto es posible porque los mecanismos de transición cumplen su función, sin
embargo, y especialmente los automáticos, no son perfectos y generan problemas
a los usuarios y a los proveedores de contenidos. Normalmente se generan
26
retardos, pérdida de calidad en los accesos a los contenidos, e incluso en
ocasiones la total imposibilidad de acceder a algunos contenidos.
Obviamente la solución no es desactivar IPv6, sino dar los pasos que hace años
ya debieran haberse dado, para que se despliegue IPv6 de una forma más rápida.
A mayor velocidad del despliegue de IPv6, menos problemas para los proveedores
de contenidos y usuarios.
El desconocimiento de IPv6 es precisamente el factor principal por el que no haya
sido desplegado con mayor celeridad. Habitualmente se tiene la percepción de
que desplegar IPv6 supone un coste muy importante y la realidad es que si se
planifica adecuadamente y con anticipación, no es el caso.
Concretando un poco más, dado que la mayoría de los equipos de las redes de
core de los ISPs y de las organizaciones públicas y privadas tienen antigüedades
inferiores a 4 o 5 años, es seguro que ya tienen soporte IPv6. En muchos casos es
tan sólo cuestión de activarlo y configurarlo. En algunos casos hace falta actualizar
el software (lo que puede requerir una licencia).
El mayor coste tiene que ver con la formación de los ingenieros que gestionan
dichas redes y el equipamiento. Recientemente se ha evaluado que se requiere
formar a unos 20 millones de ingenieros en todo el mundo en los próximos dos
años para una correcta transición a IPv6.
Como ya se ha indicado anteriormente, el otro coste importante es la necesidad de
reemplazar los CPEs (Customer Premises Equipment). La disponibilidad de los
mismos, con un adecuado soporte de IPv6, se ha demorado en comparación con
el resto de equipos de la red, precisamente porque los fabricantes no han sido
motivados por falta de demanda de los mismos por parte de los ISPs.
27
Sin embargo, en una primera fase, no es estrictamente necesario reemplazar los
CPEs, pues si los ISPs despliegan mecanismos de transición en lugar de que los
usuarios dependan de los mecanismos de transición automáticos, se alivian los
defectos que generan estos últimos. De hecho, se espera que la mayoría de los
ISPs suministren CPEs con IPv6 a los usuarios nuevos, pero que los equipos de
los suarios antiguos sean reemplazados con ocasión de otros cambios
tecnológicos (por ejemplo provisión de servicios de IPTV, mayores anchos de
banda, otras tecnologías de conexión a Internet, etc.).
Otro de los motivos aducidos para evitar la transición a IPv6 por parte de los ISPs
ha sido la falta de contenidos, lo cual ha cambiado rápidamente desde el momento
en que Google comenzó a ofrecer sus servicios con el nuevo protocolo y
obviamente ello impacta en la competencia que se ve obligada a reaccionar.
Además, los ISPs indican que no hay oportunidad de negocio, que IPv6 no es
atractivo desde el punto de vista económico. De nuevo se trata de una falsa
percepción por desconocimiento no solo de IPv6, sino de la inevitable situación de
agotamiento de IPv4.
Por último, no completar la transición a IPv6 a la mayor brevedad, implicaría la
necesidad de utilizar tecnologías de traducción en las redes de banda ancha, lo
que se ha dado en llamar “Carrier Grade NAT”, que supondría no sólo grandes
costes (en torno a un millón de dólares por cada dispositivo, sin que aún se haya
determinado cuantos miles de usuarios podrá atender), sino además perpetuar en
la red la existencia de NAT, dificultando el desarrollo de aplicaciones
extremo‐a‐extremo.
No moverse a IPv6 tiene graves consecuencias para los ISPs en cuanto a la
pérdida de negocio. Es obvio que algunos irán por delante y los rezagados
perderán cuota de mercado. Pero es más grave para la Sociedad de la
28
Información, pues los usuarios se ven abocados a una nueva brecha digital, algo
así como a una doble Internet en la que no se puede garantizar a todos los
ciudadanos el acceso a todos los contenidos de una forma adecuada y ni siquiera
que unos usuarios puedan conectarse con otros. Evitar esto es posible y sin
grandes inversiones.
4.3 EL PROTOCOLO IPv6
4.3.1 Cabecera IPv6
Se realizaron algunos cambios en el formato del encabezado base de IPv6
respecto al de IPv4 para volverlo más simple (solo ocho campos y un tamaño fijo
de 40 bytes), más flexible y más eficiente, previendo su extensión por medio de
encabezados adicionales que no necesitan ser procesados por todos los routers
intermedios. Estos cambios permiten que, incluso con un espacio de
direccionamiento de 128 bits, cuatro veces mayor que los 32 bits de IPv4, el
tamaño total del encabezado de IPv6 sea apenas dos veces mayor que el de la
versión anterior.
Los campos de la cabecera IPv6 pueden verse en la Figura 4.3.
29
Figura 4.3: Cabecera IPv6
Fuente: Migrating to IPv6
Entre los cambios realizados se destaca la eliminación de seis campos del
encabezado de IPv4 debido a que sus funciones ya no son necesarias o bien son
implementadas por los encabezados de extensión.
Las opciones adicionales ahora forman parte de los encabezados de extensión de
IPv6. Por lo tanto se pudieron eliminar los campos Opciones y Complementos. El
campo Tamaño del Encabezado también se eliminó, ya que el tamaño del
encabezado de IPv6 es fijo.
Los campos Identificación, Flags y Desplazamiento del Fragmento se eliminaron,
ya que los datos referentes a la fragmentación ahora se incluyen en un
encabezado de extensión apropiado. Para aumentar la velocidad de
procesamiento de los datagramas en los routers se eliminó el campo Suma de
Verificación, ya que éste cálculo es realizado por los protocolos de las capas
superiores.
30
También se cambió el nombre y la ubicación de los cuatro campos que se
muestran en la Figura 4.4. Estos cambios de posición se definieron para facilitar el
procesamiento de estos datos por parte de los routers.
Figura 4.4: Cambio de Nombre en 4 Campos de la Cabecera
También se agregó un nuevo campo, el Identificador de Flujo (Flow Label),
agregándole al protocolo IP otro mecanismo de soporte para QoS. Más adelante
se mostrará más detalles sobre este campo y cómo el protocolo IPv6 trata el tema
de QoS.
La siguiente lista describe el tamaño y la función de cada campo en la cabecera:
• Version (4 bits): Identifica la versión del protocolo IP utilizado. En el caso de
IPv6 el valor de este campo es 6.
• Traffic Class (8 bits): Identifica y diferencia los paquetes por clases de servicios
o prioridad. Este continúa ofreciendo las mismas funcionalidades y definiciones del
campo Tipo de Servicio de IPv4.
• Flow Label (20 bits): Identifica y diferencia paquetes del mismo flujo en la capa
de red. Este campo permite que el router identifique el tipo de flujo de cada
paquete, sin necesidad de verificar su aplicación.
31
• Payload Length (16 bits): Indica la longitud de los datos después de la
cabecera.
• Next Header (8 bits): Indica cual es la cabecera de extensión siguiente, si
existe, o el protocolo de capa superior (TCP o UDP). Reemplaza al campo
Protocol Type de IPv4.
• Hop Limit (8 bits): Indica la cantidad de routers por los que un paquete IPv6
puede pasar antes de ser descartado. Reemplaza al campo Time-to-Live (TTL) de
IPv4.
• Source Address (128 bits): Indica la dirección IP del emisor del paquete.
• Destination Address (128 bits): Indica la dirección del nodo destino del
paquete. (Nota: este campo puede no contener la dirección IPv6 del último destino
si está presente la cabecera de extensión Routing Header (encabezado de
extensión de enrutamiento).
A diferencia de lo que ocurre en IPv4 donde todos los datos opcionales se
incluyen en el encabezado base, en IPv6 estos datos se incluyen a través de
encabezados de extensión. Estos encabezados se encuentran entre el
encabezado base y los datos del datagrama, ademas no tienen una cantidad ni un
tamaño fijo. Si en un mismo paquete existen múltiples encabezados de extensión,
éstos serán agregados en serie formando una “cadena de encabezados”.
Las especificaciones de IPv6 definen seis encabezados de extensión: Hop-by-Hop
Options, Destination Options, Routing, Fragmentation, Authentication Header y
Encapsulating Security Payload.
32
En IPv6, el uso de encabezados de extensión busca aumentar la velocidad de
procesamiento en los routers, ya que el único encabezado de extensión procesado
en cada router es el Hop-by-Hop; los demás solo son tratados por el nodo
identificado en el campo Dirección de Destino del encabezado base. Además, se
pueden definir y utilizar nuevos encabezados de extensión sin tener que modificar
el encabezado base.
Un paquete IPv6 puede llevar cero, uno o más encabezados de extensión. Éstos
se encuentran a continuación del encabezado base IPv6 y son las siguientes:
Hop-by-Hop Options Header (encabezado de extensión de opciones salto a
salto)
Routing Header (encabezado de extensión de enrutamiento)
Fragmentation Header (encabezado de extensión de fragmentación)
Destination Options Header (encabezado de extensión de opciones de destino)
Authentication Header (encabezado de extensión de autenticación)
Encapsulating Security Payload Header (encabezado de extensión de
encapsulado para la seguridad de la carga útil)
Cada encabezado es identificado por el campo Next Header (siguiente
encabezado) del encabezado anterior. Con excepción de los encabezados Hop-
by-Hop Option y Routing Header, los cuales deben ser examinados y procesados
por cada nodo a lo largo del camino del paquete, los demás, solamente, son
procesados por el nodo destino, respetando estrictamente el orden en el que
aparecen en el paquete. Un nodo destino no puede recorrer las cabeceras de
extensión buscando un cabecera en particular.
La figura 4.5 muestra cómo se forman los paquetes cuando no tienen ninguna
cabecera de extensión y cómo se encadenan éstas cuando se tiene una o cuando
33
se tienen varias de estas cabeceras. Además se indica el valor del campo Next-
Header.
Figura 4.5 Cabecera de extensión
Fuente: usuarios.multimedia.es
Cuando existe más de una cabecera de extensión en un mismo paquete, las
cabeceras deben aparecer en el siguiente orden:
1. Hop-by-Hop
2. Routing
3. Fragment
4. Authentication
5. Encapsulating Security Payload
6. Destination Option
7. Upper-layer
4.3.2 Cabeceras de Extensión
4.3.2.1 Cabecera de Opciones Salto a Salto
La cabecera de Opciones Salto a Salto se utiliza para transportar información
opcional que debe ser examinada en todos los routers a lo largo de la ruta de
entrega de un paquete. Esta cabecera se identifica por tener un valor cero en el
campo Next Header (Cabecera Siguiente).
34
Esta cabecera está conformada tal como se muestra en la Figura 4.6 y el
significado de los campos es el siguiente:
Figura 4.6 Cabecera de Opciones Salto a Salto
Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue
inmediatamente a ésta.
Longitud de la Cabecera de extensión: Campo de 8 bits que específica la
longitud de la cabecera en unidades de 64 bits (8 octetos), no incluye los primeros
64 bits y es un valor entero y sin signo.
Opciones: Campo de longitud variable; la longitud de la cabecera completa es un
entero múltiplo de 64 bits.
Se especifican cuatro opciones salto a salto y son las siguientes:
1. Relleno 1.- Es utilizada para establecer un byte de relleno dentro de la zona de
opciones de una cabecera.
2. Relleno N.- Es utilizada para establecer N bytes de relleno dentro de la zona de
Opciones de una cabecera. Las opciones de Relleno 1 y Relleno N aseguran
que la cabecera tenga una longitud múltiplo de 64 bits.
35
3. Carga útil Jumbo.- Es utilizada para enviar paquetes con una carga útil mayor a
65.535 bytes. Con esta opción, IPv6 permite tamaños de paquete de hasta
4.000 millones de bytes. Esto hace posible la transmisión de paquetes de video
y mejora las capacidades disponibles sobre cualquier medio de transmisión.
4. Alerta al dispositivo de enrutamiento.- Informa al dispositivo de enrutamiento
sobre el contenido del paquete o incluye información de control.
Las dos opciones de relleno se utilizan cuando es necesario alinear opciones
consecutivas y rellenar la cabecera a una longitud múltiplo de 8 bytes.
4.3.2.2 Cabecera de enrutamiento
La cabecera de enrutamiento puede ser:
Cabecera de enrutamiento Genérica
Cabecera de enrutamiento Tipo 0
- Cabecera de enrutamiento genérica
Esta cabecera es utilizada por el emisor IP para establecer una lista de uno o más
nodos intermedios en el camino hacia el destino de un paquete. Cuando existe
cabecera de Enrutamiento, el campo de Siguiente cabecera de la cabecera básica
o de la cabecera de extensión anterior, tiene un valor igual a 43. La cabecera de
enrutamiento Genérica (ver Figura 4.7), tiene los siguientes campos:
36
Figura 4.7 Cabecera de enrutamiento Genérica
Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue
inmediatamente después de ésta.
Longitud Cabecera de Extensión: Campo de 8 bits que específica la longitud de
la cabecera de Enrutamiento en unidades de 64 bits. No incluye los primeros 64
bits, es un valor entero y sin signo.
Tipo de Enrutamiento: Campo de 8 bits que sirve para identificar una variante
particular de cabecera de Enrutamiento.
Segmento Restante: Campo de 8 bits que representa el número de nodos que
faltan por ser visitados antes de alcanzar el destino final. Es un valor entero y sin
signo.
Datos Específicos del Tipo: Campo de longitud variable o campo de datos.
Múltiplo entero de 64 bits.
Si en una cabecera de Enrutamiento el campo Tipo de enrutamiento tiene un
valor desconocido, se analiza el campo Segmento restante y se procede de la
siguiente manera:
Si el Segmento Restante es cero, se debe ignorar la cabecera de Enrutamiento
y se procesa la cabecera Siguiente.
37
Si el Segmento Restante es diferente de cero, se descarta el paquete y se
envía un mensaje ICMP a la Dirección Origen del paquete.
- Cabecera de enrutamiento Tipo 0
En la cabecera de Enrutamiento Tipo 0 no existen direcciones multienvío, esta
cabecera no se procesa hasta que el paquete llegue a la dirección destino de la
cabecera IPv6.
La cabecera de Enrutamiento Tipo 0 tiene los siguientes campos: (Figura 4.8)
Figura 4.8 Cabecera de enrutamiento Tipo 0
Cabecera Siguiente: Campo de selección de 8 bits que identifica el tipo de
cabecera que sigue inmediatamente a la cabecera de Enrutamiento.
Longitud de Cabecera de Extensión: Campo de 8 bits que especifica la longitud
de la Cabecera de Enrutamiento en unidades de 8 bytes, sin incluir los primeros 8
bytes, es un valor entero y sin signo.
38
Segmento Restante: Campo de 8 bits. En él se listan explícitamente el número
de nodos ubicados en el camino que aún deben ser visitados antes de alcanzar el
destino final; es un valor entero y sin signo.
Reservado: Campo reservado de 32 bits. Para la transmisión se inicia en cero y
es ignorado en la recepción.
Dirección [1…n]: Campo de 128 bits. Es un vector de direcciones numerados
desde 1 hasta n.
4.3.2.3 Cabecera de Fragmentación
La cabecera de Fragmentación en IPv6 es utilizada sólo por el nodo origen. Un
paquete es fragmentado si tiene una longitud mayor que la longitud del MTU
(Maximum Transfer Unit). Para conocer la longitud del MTU el nodo origen utiliza
un algoritmo de obtención de ruta. En caso de que el nodo no ejecute dicho
algoritmo de obtención de la ruta, el origen debe limitar todos los paquetes a 1.280
bytes que es la mínima longitud del MTU utilizada por las redes. Una cabecera de
Fragmentación se reconoce porque el valor de la cabecera Siguiente es 44.
La cabecera de Fragmentación tiene los siguientes campos: (Figura 4.9).
Cabecera Siguiente: Es un campo de selección de 8 bits que identifica el tipo de
cabecera inicial de la parte que puede ser fragmentada en el paquete de origen.
Reservado: Es un campo de 8 bits. Para la transmisión se inicia en cero y es
ignorado en la recepción.
39
Desplazamiento del Fragmento (Fragment Offset): Indica la posición del
fragmento en unidades de 64 bits dentro de un datagrama. Es un campo de 13 bits
cuyo valor es entero y sin signo.
Res: Campo reservado de 2 bits. Para la transmisión se inicia en cero y es
ignorado en la recepción.
Bandera M: Es un campo de 1 bit; si el bit es igual a 1 significa que existen más
fragmentos y si el bit es igual a cero significa que es el último fragmento.
Identificación: Es un campo de 32 bits que contiene un número entero que
identifica al datagrama. Si un datagrama es fragmentado, cada fragmento tendrá
el mismo identificador. El nodo origen asume un contador de 32 bits que se
incrementa cada vez que un paquete debe fragmentarse.
Figura 4.9 Cabecera de Fragmentación
4.3.2.4 Cabecera Opciones de Destino
La cabecera Opciones de Destino es utilizada para llevar información opcional que
requiere ser analizada solamente por el nodo o los nodos de destino del paquete.
La cabecera Opciones de Destino se reconoce porque el campo de Cabecera
Siguiente, en la cabecera inmediatamente precedente, tiene un valor de 60.
40
Los campos de la cabecera de Opciones de Destino son los siguientes: (Figura
4.10)
Figura 4.10 Cabecera de Opciones de destino
Cabecera Siguiente: Campo de 8 bits que identifica el tipo de cabecera que sigue
inmediatamente a la cabecera Opciones de Destino.
Longitud de Cabecera Extendida: Campo de 8 bits que especifica la longitud de
la cabecera en unidades de 64 bits. No incluye los primeros 64 bits, es un valor
entero y sin signo.
Opciones: Campo de longitud variable. La longitud de la cabecera completa es un
entero múltiplo de 64 bits que contiene una o más opciones codificadas TLV.
4.3.2.5 Cabecera de Autentificación
La cabecera de Autentificación se usa para permitir que el destino de un mensaje
pueda verificar que el mensaje proviene realmente de la dirección de origen
especificada en la cabecera del paquete y no de un impostor. Los campos de la
cabecera de Autentificación (Figura 4.11), se describen a continuación:
Cabecera Siguiente: Es un campo de 8 bits que identifica el tipo de cabecera que
sigue inmediatamente a ésta.
41
Longitud de Datos de Autentificación: Campo de 8 bits. Específica la longitud
del campo de Datos de Autentificación en múltiplos de 64 bits.
Reservado: Campo de 8 bits para uso en el futuro. Para la transmisión se inicia
en cero y es ignorado en la recepción.
Índice de Parámetros de Seguridad: Campo de 32 bits; si es combinado con la
dirección de origen, identifica el tipo de seguridad determinado en el receptor o los
receptores.
Datos de Autentificación: Campo variable que contiene el Campo de verificación
de Integridad (ICV) para este paquete. El ICV puede incluir un campo implícito,
este relleno se incluye para asegurar que la longitud de la cabecera de
Autentificación sea un múltiplo de 32 bits para IPv4 o 64 bits para IPv6.
Figura 4.11 Cabecera de Autenticación
4.3.2.6 Cabecera de Carga de Seguridad Encapsulada
La cabecera de Carga de Seguridad Encapsulada (ESP) está diseñada para
proporcionar un conjunto de servicios de seguridad en IPv4 e IPv6. La cabecera
de ESP puede ser aplicada sola o en combinación con la Cabecera de
42
Autentificación. Se utiliza para proporcionar confidencialidad, autentificación del
origen de los datos, integridad sin conexión y confidencialidad limitada al flujo de
tráfico. La cabecera ESP se inserta antes de la cabecera IP y después de la
cabecera de protocolo de capa superior en modo transporte o después de una
cabecera IP encapsulada en modo túnel.
La cabecera de Carga de Seguridad Encapsulada (Figura 4.12), está conformada
por los siguientes campos:
Figura 4.12 Cabecera de Carga de Seguridad Encapsulada
Índice de Parámetros de Seguridad (SPI): El tamaño del Campo es 32 bits.
Conjuntamente con la dirección de destino IP y con el protocolo de seguridad
(ESP) identifican a la Asociación de Seguridad para este datagrama. El conjunto
de valores de SPI está en el rango de 1 a 255 reservado por la IANA para usos
futuros. El valor de SPI cero está reservado para usarse localmente.
Número de sucesión: Campo de 32 bits sin signo que inicia en cero y se
incrementa con cada datagrama enviado; debe estar siempre presente. El emisor
debe transmitir siempre este campo pero el receptor no necesita actuar sobre él.
43
Datos de Carga Útil: Campo de longitud variable que contiene los datos descritos
por el campo cabecera Siguiente; es obligatorio y su longitud es un número entero
de bytes.
Relleno: Campo de longitud variable. El emisor puede agregar de 0 a 255 bytes
de relleno para asegurar que los bits que se encriptarán sean múltiplo del tamaño
del bloque del algoritmo y para que los datos de autentificación estén alineados en
un límite de 4 bytes.
Longitud de Relleno: Este campo de 8 bits indica el número de bytes de relleno
precedentes a este campo; el rango de valores válidos es de 0 a 255 bytes.
Cabecera Siguiente: Campo de 8 bits que indica el tipo de datos contenidos en el
campo Datos de la Carga Útil.
Datos de Autentificación: Campo de longitud variable que contiene el Valor de
Comprobación de Integridad (ICV), calculado sobre el paquete ESP menos los
datos de Autentificación. La necesidad para asegurar una confidencialidad
completa del datagrama original se puede dar con el encapsulado. El último
campo de un paquete que no se encripta, es siempre la cabecera de
confidencialidad en caso de existir dicha cabecera. La cabecera de
confidencialidad puede funcionar:
Entre estaciones
Entre una estación y un Firewall
Entre dos Firewall
44
4.3.2.7 Cabecera siguiente valor 59
En una cabecera IPv6 o en cualquier otra cabecera de extensión, si el campo
cabecera Siguiente tiene un valor de 59 significa que no hay nada más después
de esa cabecera. En una cabecera IPv6 cuyo campo Cabecera Siguiente tiene un
valor de 59 y el campo Longitud de la Carga Útil indica que hay más octetos de los
que debe haber en toda la cabecera, estos octetos deben ignorarse.
4.3.3 Consideraciones sobre el tamaño del paquete
IPv6 necesita que una MTU tenga una longitud de 1.280 bytes o más para cada
enlace en la Internet. Los nodos IPv6 deben implementar el Descubrimiento de la
MTU de la Ruta, para saber qué rutas tienen MTUs mayores a 1.280 bytes. Si se
quiere omitir esto, se deben enviar paquetes de tamaño menor a 1.280 bytes. Si
se desea enviar paquetes más grandes que lo indicado por la MTU, se utiliza la
fragmentación del paquete original y su respectivo reensamblaje en el destino.
Cuando un paquete IPv6 se envía a un destino IPv4, el nodo IPv6 puede recibir un
mensaje ICMP indicando que el paquete es muy grande. En este caso el nodo
IPv6 no tiene la necesidad de ajustar los paquetes a 1.280 bytes; el problema es
resuelto si se incluye una cabecera de Fragmentación para que el nodo IPv4
obtenga un valor de Identificación para ser usado en los fragmentos IPv4
resultantes.
4.3.4 Problemas de protocolo de capa superior
Los siguientes son problemas que pueden presentarse con los protocolos de capa
superior tales como TCP o UDP:
45
4.3.4.1 Sumas de Verificación de Capa Superior
Los protocolos de capa superior que incluyen las direcciones IP en su cálculo de
suma de verificación deben modificarse cuando se va a utilizar IPv6. En la figura
4.13 se presenta una pseudo cabecera TCP y UDP para IPv6 cuyos campos son
los siguientes:
Figura 4.13 Pseudo Cabecera TCP y UDP para IPv6
Dirección Origen: Es la dirección desde donde se está enviando el datagrama;
esta dirección se incluirá en el último componente de la cabecera de Enrutamiento
y en el campo Dirección Destino de la cabecera IPv6 en el receptor o en los
receptores.
Dirección destino: Si el datagrama IPv6 contiene una cabecera de Enrutamiento,
la dirección de destino utilizada en la pseudo cabecera es la del destino final.
Longitud del Paquete de Capa Superior: Es la longitud de la cabecera de capa
superior junto con los datos.
Cero: Es un campo de 24 bits que no está siendo utilizado y debe ser cero.
46
Cabecera siguiente: Este campo identifica el protocolo de capa superior. Por
ejemplo, es 6 para el protocolo TCP y 17 para el protocolo UDP.
Si los datagramas UDP son originados por un nodo IPv6, la suma de verificación
UDP no es opcional, es decir, siempre que se origine un paquete UDP, un nodo
IPv6 debe calcular una suma de verificación UDP sobre el datagrama y la pseudo
cabecera. Si ese cálculo produce un resultado igual a cero, debe cambiarse al
hexadecimal FFFF para su colocación en la cabecera UDP. Los receptores IPv6
deben descartar los datagramas UDP que contengan una suma de verificación
cero y deben registrar el error.
ICMPv6 proporciona la información de error o control entre nodos. El cálculo de la
suma de verificación UDP está incluido en el protocolo ICMPv6; con esto se
protege al ICMP de una mala entrega o de daños en los campos de la cabecera
IPv6. El campo Cabecera Siguiente en la pseudo cabecera para el ICMP contiene
el valor 58, que identifica a ICMPv6.
4.3.4.2 Tiempo de Vida Máximo de un Paquete
Cualquier protocolo de capa superior que depende de la capa de Internet para
limitar el Tiempo de Vida de un datagrama, debe actualizarse para proporcionar
sus propios mecanismos de detección y descarte de paquetes obsoletos. IPv6 no
necesariamente debe cumplir con el Tiempo de Vida máximo de un datagrama.
4.3.4.3 Tamaño Máximo de la Carga Útil de Capa Superior
Al calcular el tamaño máximo de la carga útil disponible para los datos de capa
superior, un protocolo de capa superior debe tener en cuenta el tamaño más
grande de la cabecera IPv6 respecto a la cabecera IPv4.
47
4.3.4.4 Respuesta a Paquetes que Llevan Cabeceras de Enrutamiento
Cuando un protocolo de capa superior envía uno o más datagramas en
contestación a un datagrama recibido que incluía una cabecera de Enrutamiento,
sólo se permiten los siguientes tipos de datagramas de respuesta:
Datagramas de respuesta que no llevan cabeceras de Enrutamiento.
Datagramas de respuesta que llevan cabeceras de Enrutamiento en las que
no se ha invertido la cabecera de Enrutamiento del datagrama recibido.
Datagramas de respuesta que llevan cabeceras de Enrutamiento en las
que se ha invertido la cabecera de Enrutamiento del datagrama recibido, si
y sólo si, la integridad y autenticidad de la Dirección Origen y de la
cabecera de Enrutamiento del paquete recibido han sido verificadas por el
nodo que contesta.
4.4 DIRECCIONAMIENTO IPV6
Una dirección IPv6 tiene una longitud de 128 bits divididos en bloques de 16 bits
donde cada bloque es representado por 4 dígitos hexadecimales, a diferencia de
IPv4 en donde los grupos de 8 bits eran representados por dígitos decimales.
Cada bloque de 4 dígitos hexadecimales, es separado por el signo “:” mientras
que en Ipv4 la separación de los bloques se la realiza con el signo “.”. Existen
reglas que pueden ser aplicadas a las direcciones IPv6 con el objetivo de resumir
un poco la sintaxis de las direcciones. Por ejemplo una dirección IPv6 válida
2001:0000:1234:0000:0000:C1C0:ABCD:0876 puede aceptar las siguientes
simplificaciones:
48
Las letras pueden ser mayúsculas o minúsculas y la dirección se puede
escribir como 2001:0000:1234:0000:0000:c1c0:abcd:0876
Los “ceros” consecutivos son opcionales y se pueden representar en la
dirección como 2001:0:1234:0:0:c1c0:abcd:876
Los campos con “ceros” sucesivos pueden ser reemplazados por “::” y la
dirección puede tomar la forma 2001:0:1234::c1c0:abcd:876. Pero,
cualquier dirección que tenga más de una vez la representación “::” será
una dirección inválida ya que solamente se puede usar esa representación
una sola vez.
Otra representación importante es la de los prefijos de red. En las direcciones IPv6
continúa escribiéndose del mismo modo que en IPv4, utilizando la notación CIDR.
Esta notación se representa con la forma “dirección-IPv6/tamaño del prefijo”,
donde “tamaño del prefijo” es un valor decimal que especifica la cantidad de bits
contiguos a la izquierda de la dirección que comprenden el prefijo. En el ejemplo
de prefijo de subred presentado a continuación, de los 128 bits de la dirección, 64
bits se utilizan para identificar la subred y 32 bits para representar el prefijo global.
Prefijo 2001:db8:3003:2::/64
Prefijo global 2001:db8::/32
Esta representación también permite agregar las direcciones en forma jerárquica,
identificando la topología de la red a través de parámetros tales como ubicación
geográfica, proveedor de acceso, identificación de la red, división de la subred,
etc.
En cuanto a la representación de las direcciones IPv6 en las URL (Uniform
Resource Locators), éstas ahora se representan entre corchetes. Esto evitará
49
ambigüedades en caso que sea necesario indicar el número de un puerto junto
con la URL. Ver los siguientes ejemplos:
http://[2001:12ff:0:4::22]/index.html
http://[2001:12ff:0:4::22]:8080
4.4.1 Tipos de Direcciones IPv6
Existen 3 tipos de direcciones IPv6: unicast, multicast y anycast.
4.4.1.1 Direcciones Unicast
Identifica una interfaz única en el ámbito de direcciones. Los paquetes que son
dirigidos a una dirección unicast son entregados a una interfaz única.
Para dar cabida a los sistemas de balanceo de carga, la norma RFC 2373 permite
a múltiples interfaces utilizar la misma dirección, siempre y cuando aparezcan
como una sola interfaz para la implementación de IPv6 en el host. Existen
diferentes tipos de direcciones unicast tales como: globales unicast, link-local,
direcciones especiales, direcciones compatibles.
- Direcciones globales
Las direcciones unicast globales en IPv6 son equivalentes a las direcciones
públicas en IPv4. Estas direcciones son enrutables y accesibles a nivel global
sobre la porción de IPv6 en Internet.
Su estructura fue proyectada para utilizar los 64 bits más hacia la izquierda de la
dirección para identificar la red y los 64 bits más hacia la derecha para identificar
la interfaz. Por lo tanto, excepto en ciertos casos específicos, todas las subredes
50
en IPv6 tienen el mismo tamaño de prefijo, 64 bits (/64), lo que permite tener 264 =
18.446.744.073.709.551.616 dispositivos por subred.
Actualmente para la atribución de direcciones está reservado el rango 2000::/3
(001), que corresponde a las direcciones de 2000:: a 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.
Esto representa el 13% del total de direcciones posibles con IPv6, lo que permite
crear 2(64−3) = 2.305.843.009.213.693.952 (2,3x1018) subredes (/64) diferentes o
2(48−3) = 35.184.372.088.832 (3,5x1013) redes /48.
Estas direcciones están diseñadas para ser fácilmente agregadas o sumarizadas
con el fin de producir una estructura eficiente de enrutamiento.
- Direcciones link-local (de enlace local)
Son usadas por los nodos que se comunican con los nodos vecinos que se
encuentran en el mismo enlace; por ejemplo, en un único enlace IPv6 sin router.
Las direcciones link-local (de enlace local) se utilizan para la comunicación entre
los hosts dentro del enlace.
Las direcciones link-local siempre comienzan con FE80 y terminan con los 64 bits
del identificador de interfaz. El prefijo para las direcciones link-local es siempre
FE80::/64.
Los 64 bits reservados para la identificación de la interfaz se configuran utilizando
el formato IEEE EUI-64 (Extended Unique Identifier). Vale la pena destacar que
los routers no deben encaminar paquetes cuyo origen o destino sea una dirección
link-local hacia otros enlaces.
51
- Direcciones IPv6 especiales
Existen dos tipos de direcciones especiales que son usadas en IPv6 y son las
direcciones no especificadas y las direcciones de loopback.
Las direcciones no especificadas (0:0:0:0:0:0:0:0 ó ::) son usadas para identificar
la ausencia de una dirección. Esta dirección es típicamente usada como dirección
de origen cuando no ha sido aún determinada la dirección. Esta dirección nunca
se asigna a una interfaz ni es usada como dirección de destino.
La dirección de loopback (0:0:0:0:0:0:0:1 ó ::1) es usada para identificar una
interfaz de bucle de prueba, habilitando a un nodo para que pueda enviarse
paquetes a sí mismo.
Una Dirección mapeada IPv4 es representada mediante 0:0:0:0:0:FFFF:w.x.y.z o
::FFFF:w.x.y.z. Se utiliza para mapear una dirección IPv4 en una dirección IPv6 de
128 bits, donde w.x.y.z representa los 32 bits de la dirección IPv4, utilizando
dígitos decimales. Se aplica en técnicas de transición para que se comuniquen
nodos IPv6 e IPv4. Por ejemplo ::FFFF:192.168.100.1.
- Direcciones compatibles
Sirven para ayudar en la migración de IPv4 a IPv6, para la coexistencia de ambas
direcciones. Entre estas se tiene: direcciones IPv4 compatibles, direcciones
6over4, direcciones 6to4 y direcciones ISATAP.
Las direcciones IPv4 compatibles son usadas por nodos IPv6/IPv4 que se
comunican con nodos IPv6 a través de una infraestructura IPv6 pública. Las
direcciones 6to4 son usadas para representar a un host en el mecanismo de
entunelamiento (tunneling) conocido como 6to4 el cual, junto con otros
mecanismos de migración, será descrito posteriormente.
52
4.4.1.2 Direcciones Multicast
Las direcciones multicast habilitan el uso eficiente del ancho de banda de la red al
enviar un mínimo número de datagramas al número máximo de nodos. En un
enlace local, un datagrama multicast es enviado a un ilimitado número de nodos.
Un prefijo especial (en IPv4 es 224.0.0.0/8) identifica a un datagrama multicast
IPv6 y una dirección específica dentro del prefijo identifica a cada grupo de nodos.
La Tabla 4.3 indica las direcciones IPv6 que son reservadas para multicast.
Tabla 4.3 Direcciones reservadas para Multicast
Dirección Alcance Descripción
FF01::1 Interfaz
Todas las interfaces en un nodo (all-
nodes)
FF01::2 Interfaz
Todos los routers en un nodo (all-
routers)
FF02::1 Enlace
Todos los nodos del enlace (all-
nodes)
FF02::2 Enlace
Todos los routers del enlace (all-
routers)
FF02::5 Enlace Routers OSFP
FF02::6 Enlace Routers OSPF designados
FF02::9 Enlace Routers RIP
FF02::D Enlace Routers PIM
FF02::1:2 Enlace Agentes DHCP
FF02::1:FFXX:XXXX Enlace Solicited-node
FF05::2 Site Todos los routers en un site
FF05::1:3 Site Servidores DHCP en un site
FF05::1:4 Site Agentes DHCP en un site
FF0X::101 Variado NTP (Network Time Protocol)
53
Las direcciones multicast no pueden ser usadas como direcciones de origen o
como destinos intermediarios. Las direcciones multicast tienen una estructura
especial para identificar las banderas, su ámbito de aplicación y a qué grupo
multicast pertenece.
4.4.1.3 Direcciones Anycast
Una dirección IPv6 anycast se utiliza para identificar un grupo de interfaces,
aunque con la propiedad de que un paquete enviado a una dirección anycast es
encaminado solamente a la interfaz del grupo más próxima al origen del paquete.
Las direcciones anycast se atribuyen a partir del rango de direcciones unicast y no
hay diferencias sintácticas entre las mismas. Por lo tanto, una dirección unicast
atribuida a más de una interfaz se transforma en una dirección anycast,
debiéndose en este caso configurar explícitamente los nodos para que sepan que
les ha sido atribuida una dirección anycast. Por otra parte, esta dirección se debe
configurar en los routers como una entrada independiente (prefijo /128 – host
route).
Este esquema de direccionamiento se puede utilizar para descubrir servicios en la
red, como por ejemplo servidores DNS y proxies HTTP, garantizando la
redundancia de estos servicios. También se puede utilizar para realizar balanceo
de carga en situaciones en las que múltiples hosts o routers proveen el mismo
servicio, para localizar routers que provean acceso a una determinada subred o
para localizar los Agentes de Origen en redes con soporte para movilidad IPv6.
Todos los routers deben soportar la dirección anycast Subnet-Router. Este tipo de
direcciones están formadas por el prefijo de la subred y el IID (Identificador de
interfaz) completado con ceros (por ejemplo: 2001:db8:cafe:dad0::/64). Un
paquete enviado a la dirección Subnet-Router será entregada al router más
próximo al origen dentro de la misma subred.
54
También se definió una dirección anycast para ser utilizada en el soporte para
movilidad IPv6. Este tipo de direcciones están formadas por el prefijo de la subred
seguido por el IID dfff:ffff:ffff:fffe (por ejemplo: 2001:db8::dfff:ffff:ffff:fffe). Son
utilizadas por el Nodo Móvil cuando éste necesita localizar un Agente Origen en su
Red Original.
4.4.2 Direcciones ipv6 para host y router
Por lo general, a un elemento de red que cuenta con una sola interfaz de red se le
puede asignar tan solo una dirección IPv4. Sin embargo, a una interfaz que usa
IPv6 se le puede asignar múltiples direcciones. Los tipos de direcciones unicast
que pueden ser asignadas a una interfaz de un host o router que usa IPv6 son las
siguientes:
Una dirección link-local (enlace local) por cada interfaz
Una dirección unicast adicional (que puede ser site-local o dirección global) por
cada interfaz.
La dirección de loopback (::1) para la interfaz de bucle de prueba.
Todos los nodos se pueden identificar a través de cualquiera de sus direcciones
de interfaz y por lo tanto se hace necesario elegir entre sus múltiples direcciones
cuáles se utilizarán como direcciones de origen y destino al establecer una
conexión.
Para resolver este tema se definieron dos algoritmos, uno para seleccionar la
dirección de origen y otro para seleccionar la de destino. Estos algoritmos, que
deben ser implementados por todos los nodos IPv6, especifican el
comportamiento por defecto de dichos nodos, pero no anulan las decisiones
tomadas por las aplicaciones o protocolos de la capa superior.
55
Entre las reglas más importantes se destacan las siguientes:
• Pares de direcciones origen-destino del mismo alcance o tipo tienen
preferencia
• El menor alcance para la dirección de destino tiene preferencia (se utiliza el
menor alcance posible)
• Las direcciones cuyo tiempo de vida no ha expirado tienen preferencia sobre
las direcciones con tiempo de vida expirado
• No se pueden utilizar las direcciones de las técnicas de transición (ISATAP,
6to4, etc.), si hay una dirección IPv6 nativa disponible
• Si todos los criterios son similares, los pares de direcciones con el mayor
prefijo común tendrán preferencia
• Para las direcciones de origen, las direcciones globales tendrán preferencia
sobre las direcciones temporarias
• En un Nodo Móvil, la Dirección de Origen tiene preferencia sobre una Dirección
Remota.
Estas reglas deben ser utilizadas cuando no hay ninguna otra especificación. Las
especificaciones también permiten configurar políticas que puedan reemplazar
estas preferencias estándares por combinaciones de direcciones de origen y
destino.
4.4.3 Direcciones únicas ULA (Unique Local Address)
Es una dirección con grandes probabilidades de ser globalmente única pero
utilizada solamente para comunicaciones locales, generalmente dentro de un
mismo enlace o conjunto de enlaces. Una dirección ULA no debe ser enrutable en
la Internet global.
56
Una dirección ULA, creada utilizado un ID global distribuido pseudo-
aleatoriamente, está formada por las siguientes partes:
Prefijo: FC00::/7.
Flag Local (L): si el valor es 1 (FD) el prefijo es atribuido localmente. Si el valor es
0 (FC), el prefijo debe ser atribuido por una organización central (aun por
determinar).
Identificador global: identificador de 40 bits usado para crear un prefijo
globalmente único.
Identificador de la interfaz: identificador de la interfaz de 64 bits.
De este modo, la estructura de una dirección ULA es FDUU:UUUU:UUUU:<ID de
la subred>:<ID de la interfaz> donde U son los bits del identificador único,
generado aleatoriamente por un algoritmo específico.
Su utilización permite que cualquier enlace posea un prefijo /48 privado y
globalmente único. Por lo tanto, en el caso que se interconecten dos redes (por
ejemplo de dos empresas diferentes), es probable que no haya conflicto de
direcciones ni necesidad de renumerar la interfaz. Además, la dirección ULA es
independiente del proveedor, pudiendo ser utilizada en la comunicación dentro del
enlace aunque no haya conexión a Internet. Otra ventaja es que su prefijo se
puede bloquear fácilmente y si accidentalmente una dirección ULA se anuncia
fuera del enlace ya sea a través de un router o vía DNS, no habrá conflicto con
otras direcciones.
4.4.4 Identificador de interfaz (IID)
Los identificadores de interfaz (IID), utilizados para distinguir las interfaces dentro
de un enlace, deben ser únicos dentro del mismo prefijo de subred. El mismo IID
57
se puede usar en múltiples interfaces de un único nodo, pero éstas deben estar
asociadas a subredes diferentes.
Normalmente se utiliza un IID de 64 bits, el cual se puede obtener de diferentes
maneras:
Se puede configurar manualmente, a partir del mecanismo de autoconfiguración
stateless de IPv6, a partir de servidores DHCPv6 (stateful), o se pueden formar a
partir de una clave pública (CGA: Dirección Criptográficamente Generada).
Estos métodos se describirán detalladamente en este curso. Aunque pueden ser
generados aleatoriamente y de forma temporaria, se recomienda construir el IID
con base en la dirección MAC de la interfaz, en el formato EUI-64.
Un IID basado en el formato EUI-64 se genera de la siguiente manera:
Si la interfaz tiene una dirección MAC de 64 bits (estándar EUI-64), solo debe
complementar el séptimo bit más a la izquierda (llamado bit U/L– universal/Local)
de la dirección MAC, es decir, si es 1 se debe cambiar a 0 y si es 0 se debe
cambiar a 1. Si la interfaz utiliza una dirección MAC de 48 bits (estándar IEEE
802), primero se agregan los dígitos hexadecimales FF-FE entre el tercero y el
cuarto byte de la dirección MAC (para transformar al estándar EUI-64) y luego se
complementa el bit U/L. Por ejemplo:
– Si la dirección MAC de la interfaz es:
48-1E-C9-21-85-0C
– se agregan los dígitos FF-FE en el medio de la dirección:
48-1E-C9-FF-FE-21-85-0C
– se complementa el bit U/L:
48 = 01001000
58
01001000 → 01001010
01001010 = 4A
– IID = 4A-1E-C9-FF-FE-21-85-0C
Una dirección link local atribuida a esta interfaz sería
FE80::4A1E:C9FF:FE21:850C.
4.4.5 Direcciones IPv4 e IPv6 equivalentes
Para resumir la relación entre el direccionamiento IPv4 y el direccionamiento IPv6
la Tabla 4.4 muestra los conceptos de direccionamiento IPv4 y sus equivalentes
en IPv6.
Tabla 4.4 Direcciones IPv4 equivalentes
Direcciones IPv4 Direcciones IPv6
Internet address classes No es aplicable en IPv6
Direcciones Multicast
(224.0.0.0/4)
Dirección multicast IPv6
(FF00::/8)
Dirección de Broadcast No es aplicable en IPv6
La dirección no
especificada es 0.0.0.0
La dirección no
especificada es ::
La dirección de Loopback
es 127.0.0.1
La dirección de Loopback
es ::1
Direcciones IP públicas Direcciones unicast
globales
Dirección IP privada
(10.0.0.0/8, 172.16.0.0/12
y 192.168.0.0/16)
Direcciones Site-local
FEC0::/48 (Desaprobada en
RFC3879)
59
La representación de las
direcciones se realiza con
notación decimal.
La representación de las
direcciones se la realiza con
notación hexadecimal con
supresión de los ceros.
La máscara de subred se
representa con notación
decimal con puntos o
longitud del prefijo.
Los bits de red se
representan solo con la
longitud del prefijo.
4.4.6 Políticas de distribución y asignación
En la jerarquía de las políticas de atribución, distribución y asignación de
direcciones, cada RIR (Regional Internet Registry) recibe de la IANA (Internet
Assigned Numbers Authority) un bloque /12 IPv6.
El bloque 2800::/12 corresponde al espacio reservado para que LACNIC realice
distribuciones en América Latina y el Caribe.
La mínima distribución para un ISP es un bloque /32, aunque se pueden realizar
distribuciones mayores si se justifica la utilización. Un aspecto importante a
destacar es que, a diferencia de lo que ocurre en IPv4, en IPv6 la utilización se
mide considerando el número de bloques de direcciones asignados a usuarios
finales, no el número de direcciones asignadas a usuarios finales.
En relación con la distribución y asignación de direcciones a usuarios finales, la
RFC 3177 recomienda seguir un enfoque conocido como one size fits all, el cual
tiene las siguientes características:
• En general se recomienda el uso de redes /48 para todos los tipos de usuarios,
sin importar si son residenciales o empresas pequeñas o grandes;
60
• Las empresas muy grandes pueden recibir un /47, prefijos un poco menores o
múltiplos de un /48;
• Se recomienda el uso de redes /64 cuando exista la certeza de que se requiere
una única subred, por ejemplo para usuarios 3G;
• Se puede utilizar una red /128 cuando exista la certeza absoluta de que
solamente se conectará una interfaz. Por ejemplo: conexiones PPPoE (Point-
to-Point Protocol over Ethernet).
El enfoque one size fits all tiene algunas ventajas:
• Facilita la renumeración de la red en caso de cambio de proveedor (cambio de
prefijo)
• Permite ampliar la red sin necesidad de solicitar más direcciones al proveedor
• Facilita el mapeo entre la dirección global y la dirección Unique Local (ULA
fc00:xyzw:klmn::/48)
• Ya hay redes que utilizan prefijos /48 6to4;
• Permite mantener reglas únicas para zonas inversas de diferentes prefijos;
• Facilita la administración;
• Hay quienes creen que desperdicia demasiadas direcciones y que podría
generar problemas dentro de algunas décadas.
Un enfoque más conservador, opuesto a one size fits all, recomienda no delegar
bloques /48 a todos los tipos de usuarios, asignando bloques /56 a los usuarios
residenciales y SOHOs (Small Office/Home Office). Esto reduce el consumo total
de direcciones de 6 a 7 bits.
Además, un /32 permite apenas 65.536 prefijos /48, que en el caso de los grandes
proveedores no sería suficiente para satisfacer toda su demanda.
61
4.4.7 ¿Qué están haciendo los RIR y los ISP?
Los RIR aplican dos políticas diferentes en cuanto a las recomendaciones de uso
para los ISP y el criterio para la distribución de bloques de direcciones adicionales.
Los RIR LACNIC y AFRINIC siguen la recomendación one size fits all y sugieren
que los proveedores de sus regiones también los sigan. También evalúan las
solicitudes de bloques adicionales por parte de los ISP de acuerdo con ese
enfoque, es decir, basándose en la cantidad de bloques /48 asignados por los ISP.
En cambio los RIR APNIC, ARIN y RIPE siguen un enfoque más conservador,
utilizando la cantidad de bloques /56 asignados por los proveedores como base
para evaluar las solicitudes de bloques adicionales.
En todos los casos la medida utilizada para la evaluación es el HD-Ratio (Host-
Density ratio). El HD-Ratio es un modo de medir el uso del espacio de
direccionamiento, ya que su valor está relacionado con el porcentaje de uso. Para
calcular el HD-Ratio se utiliza la siguiente fórmula:
Todos los RIR utilizan como valor Threshold (umbral) HD-Ratio = 0,94, solo que
LACNIC y AFRINIC lo aplican a la utilización de bloques /48 mientras que APNIC,
ARIN y RIPE a la utilización de bloques /56.
62
4.5 FUNCIONALIDADES DE IPv6
4.5.1 ICMPv6 (Internet Control Message Protocol)
Definido en la RFC 4443 para ser utilizado con IPv6, ICMPv6 es una versión
actualizada del ICMP (Internet Control Message Protocol) que se utiliza con IPv4.
Aunque tiene las mismas funciones que ICMPv4 (como por ejemplo informar
errores en el procesamiento de paquetes y reenviar mensajes sobre el estado o
las características de la red), esta nueva versión del ICMP no es compatible con
su predecesor y ahora presenta un mayor número de mensajes y funcionalidades.
Ahora ICMPv6 es responsable de realizar las funciones del protocolo ARP
(Address Resolution Protocol), que mapea direcciones IP a direcciones de capa
dos en IPv4 y de IGMP (Internet Group Management Protocol), que gestiona los
miembros de los grupos multicast en IPv4.
El valor del campo Siguiente Encabezado (que indica la presencia del protocolo
ICMPv6) es 58 y en todos los nodos se debe implementar soporte para este
protocolo.
En un paquete IPv6, el ICMPv6 se coloca inmediatamente después del
encabezado base de IPv6 y de los encabezados de extensión (si los hubiera).
ICMPv6, es un protocolo clave en la arquitectura IPv6 ya que, además de
gestionar los grupos multicast, a través del protocolo MLD (Multicast Listener
Discovery) y de la resolución de direcciones de capa dos, sus mensajes son
esenciales para el funcionamiento del protocolo de Descubrimiento de Vecinos
(Neighbor Discovery), responsable de localizar routers vecinos en la red, detectar
cambios de dirección en el enlace, detectar direcciones duplicadas, etc.
63
El encabezado de todos los mensajes ICMPv6 tienen la misma estructura y está
compuesto por cuatro campos:
Tipo: Especifica el tipo de mensaje, lo que determinará el formato del cuerpo del
mensaje. Su tamaño es de ocho bits;
Código: Ofrece algunos datos adicionales para determinados tipos de mensajes.
Su tamaño también es de ocho bits;
Suma de Verificación: Se utiliza para detectar datos corruptos en el encabezado
ICMPv6 y en parte del encabezado IPv6. Su tamaño es de 16 bits;
Datos: Presenta información de diagnóstico y error según el tipo de mensaje. Para
ayudar en la resolución de problemas, los mensajes de error incluyen en este
campo el paquete que invocó el mensaje, ya que el tamaño total del paquete
ICMPv6 no debe exceder la mínima MTU de IPv6, que es de 1280 bytes.
Los mensajes ICMPv6 se dividen en dos clases, cada una de ellas compuesta por
diferentes tipos de mensajes, de acuerdo con las tablas 4.5 y 4.6:
Tabla 4.5 Mensajes de Error
Tipo Nombre Descripción
1 Destination
Unreachable
Indica fallas en la entrega del
paquete (como dirección o puerto
desconocido) o problemas en la
comunicación.
2 Packet Too Big
Indica que el tamaño del paquete
es mayor que la Indica que el
tamaño del paquete es mayor que
la enlace.
3 Time Exceeded Indica que el Límite de
Direccionamiento o el tiempo
64
Indica que el Límite de
Direccionamiento o el tiempo
4 Parameter Problem
Indica un error en alguno de los
campos encabezado IPv6 o que el
tipo indicado en el campo
encabezado IPv6 o que el tipo
indicado en el campo
100-101 Uso experimental
102-126 No utilizados
127 Reservado para la expansión de
mensajes de error ICMPv6
Tabla 4.6 Mensaje de información
Tipo Nombre Descripción
128 Echo Request Utilizados por el comando ping.
129 Echo Reply
130 Multicast Listener Query
Utilizados en la gestión de grupos
multicast. 131
Multicast Listener
Report
132 Multicast Listener Done
133 Router Solicitation
Utilizados con el protocolo de
Descubrimiento de vecinos
134 Router Advertisement
135 Neighbor Solicitation
136 Neighbor Advertisement
137 Redirect Message
138 Router Renumbering
Utilizado en el mecanismo de
redireccionamiento direccionamiento(
65
Renumbering) de routers.
139
ICMP Node Information
Query
Utilizados para descubrir datos sobre
nombres y direcciones, actualmente
están limitados a herramientas de
diagnóstico, depuración y gestión de
redes. 140
ICMP Node Information
Response
141
Inverse ND Solicitation
Message Utilizados en una extensión del protocolo
de Descubrimiento de Vecinos.
142
Inverse ND
Advertisement Message
143
Version 2 Multicast
Listener Report
Utilizado en la gestión de grupos
multicast.
144
HA Address Discovery
Req. Message
Utilizados en el mecanismo de Movilidad
IPv6. 145
HA Address Discovery
Reply Message
146 Mobile Prefix Solicitation
147
Mobile Prefix
Advertisement
148
Certification Path
Solicitation Message Utilizados por el protocolo SEND.
149
Cert. Path
Advertisement Message
150
Utilizado experimentalmente con
protocolos de movilidad como Seamoby .
151
Multicast Router
Advertisement Utilizados por el mecanismo Multicast
Router Discovery
152
Multicast Router
Solicitation
66
153
Multicast Router
Termination
154 FMIPv6 Messages
Utilizado por el protocolo de movilidad
Fast Handovers
200-201 Uso experimental
255
Reservado para la expansión de
mensajes de error ICMPv6
4.5.2 Descubrimiento de Vecinos (Neighbor Discovery Protocol)
Definido por la RFC4861, el protocolo de Descubrimiento de Vecinos agiliza
algunos procesos de configuración de red con respecto a IPv4 combinando las
funciones de protocolos como ARP, ICMP Router Discovery y ICMP Redirect y
además agrega nuevos métodos que no existían en la versión anterior del
protocolo IP.
El protocolo de Descubrimiento de Vecinos de IPv6 es utilizado por los hosts y
routers para los siguientes propósitos:
Determinar la dirección MAC de los nodos de la red
Encontrar routers vecinos
Determinar prefijos y otros datos de configuración de la red
Detectar direcciones duplicadas
Determinar la accesibilidad de los routers
Redireccionamiento de paquetes
Autoconfiguración de direcciones
Los mensajes Neighbor Discovery se configuran con un Límite de
Direccionamiento de 255 para asegurar que los mensajes recibidos tengan su
67
origen en un nodo del mismo enlace, descartando los mensajes que tengan
valores diferentes.
Neighbor Discovery utiliza cinco mensajes ICMPv6:
Router Solicitation (ICMPv6 tipo 133): Utilizado por los hosts para solicitar a
los routers mensajes de Router Advertisements inmediatamente. Normalmente
se envía a la dirección multicast FF02::2 (all-routers on link)
Router Advertisement (ICMPv6 tipo 134): Se envía periódicamente o en
respuesta a un Router Solicitation y es utilizado por los routers para anunciar
su presencia en un enlace. Los mensajes periódicos se envían a la dirección
multicast FF02::1 (all nodes on link), mientras que los solicitados se envían
directamente a la dirección del solicitante. Un RA (Router Advertisement)
transporta información referente a la configuración de la red, por ejemplo:
El valor por defecto del enlace para el campo Límite de Direccionamiento
Un flag que especifica si se debe utilizar autoconfiguración stateless o
stateful
Otro flag que especifica si los nodos deben utilizar configuraciones stateful
para obtener otros datos acerca de la red
En las redes que soportan movilidad IPv6 se utiliza un tercer flag para
indicar si el router es un Agente de Origen
Por cuánto tiempo (en segundos) el router será considerado el router por
defecto del enlace. Si no es el router por defecto este valor será cero;
El tiempo que un host supone que los vecinos son alcanzables luego de
recibir una confirmación de accesibilidad
El intervalo entre el envío de mensajes Neighbor Solicitation.
68
Neighbor Solicitation (ICMPv6 tipo 135): Mensaje multicast enviado por un
nodo para determinar la dirección MAC y la accesibilidad de un vecino y
detectar la existencia de direcciones duplicadas. Este mensaje tiene un campo
para indicar la dirección de origen del mensaje
Neighbor Advertisement (ICMPv6 tipo 136): Se envía como respuesta a un
Neighbor Solicitation, pero también se puede enviar para anunciar el cambio de
alguna dirección dentro del enlace. Este mensaje tiene tres flags:
El primero indica si quien está enviando el mensaje es un router;
El segundo indica si el mensaje es una respuesta a un NS;
El tercero indica si la información que transporta el mensaje es una
actualización de la dirección de alguno de los nodos de la red.
Redirect (ICMPv6 tipo 137): Utilizado por los routers para informar al host el
mejor router para encaminar el paquete a su destino. Este mensaje contiene
información como la dirección del router que se considera el mejor salto y la
dirección del nodo que está siendo redireccionado.
Estos mensajes pueden tener o no opciones:
Source link-layer address: Contiene la dirección MAC del remitente del
paquete. Se utiliza en los mensajes NS, RS y RA
Target link-layer address: Contiene la dirección MAC del destino del
paquete. Se utiliza en los mensajes NA y Redirect
Prefix information: Proporciona a los hosts los prefijos del enlace y los
prefijos para autoconfiguración de direcciones. Se utiliza en los mensajes
RA
Redirected header: Contiene todo el paquete que está siendo
redireccionado o parte del mismo. Se utiliza en los mensajes Redirect
69
MTU: Indica el valor de la MTU del enlace. Se utiliza en los mensajes RA.
4.5.2.1 Descubrimiento de direcciones de capa de enlace
Esta funcionalidad se utiliza para determinar la dirección MAC de los vecinos del
mismo enlace: un host envía un mensaje NS a la dirección multicast solicited node
del vecino informando su dirección MAC.
Figura 4.14 Descubrimiento de direcciones
Fuente: packetlife.net
Al recibir el mensaje, el vecino responde enviando un mensaje NA informando su
dirección MAC. En IPv6, esta característica del protocolo de Descubrimiento de
Vecinos reemplaza al protocolo ARP de IPv4 y en lugar de utilizar una dirección
broadcast, utiliza la dirección multicast solicited-node como dirección de destino.
4.5.2.2 Descubrimiento de Routers y prefijos
Esta funcionalidad del protocolo de Descubrimiento de Vecinos se utiliza para
localizar routers vecinos dentro del mismo enlace, así como para aprender prefijos
y parámetros relacionados con la autoconfiguración de direcciones.
70
Esta información se envía desde un router local, a través de mensajes RA
encaminados a la dirección multicast all-nodes.
En IPv4 el mapeo de las direcciones de la red local se realiza a través de
mensajes ARP Request.
Figura 4.15: Descubrimiento de Routers
Fuente: packetlife.net
4.5.2.3 Detección de direcciones duplicadas
La Detección de Direcciones Duplicadas es el procedimiento que utilizan los nodos
para verificar la unicidad de las direcciones en un enlace y se debe realizar antes
de atribuir cualquier dirección unicast a una interfaz, sin importar si éstas se
obtienen mediante autoconfiguración stateless, DHCPv6 o configuración manual.
Este mecanismo consiste en el envío de un mensaje NS por parte del host con su
propia dirección en el campo target address. Si como respuesta se recibe un
mensaje NA, esto indica que la dirección ya está siendo utilizada y que el proceso
de configuración debe ser interrumpido.
71
En IPv4 los nodos utilizan mensajes ARP Request y el método llamado gratuitous
ARP para detectar direcciones unicast duplicadas dentro del mismo enlace
definiendo los campos Source Protocol Address y Target Protocol Address, del
encabezado del mensaje ARP Request, con la dirección IPv4 que está siendo
verificada.
Este mecanismo se utiliza en comunicaciones host-a-host, host-a-router y router-
a-host para rastrear la accesibilidad de los nodos a lo largo del camino.
Un nodo considera que un vecino es accesible si recientemente ha recibido
confirmación de la entrega de algún paquete a dicho vecino. Esta confirmación se
puede dar de dos maneras diferentes: una respuesta a un mensaje del protocolo
de Descubrimiento de Vecinos o algún proceso de capa de transporte que indique
que se estableció una conexión.
Este proceso solo se ejecuta cuando se envían paquetes a una dirección unicast;
no se utiliza cuando se envían paquetes a direcciones multicast.
Para realizar el seguimiento de los estados de un vecino el nodo IPv6 utiliza dos
tablas principales:
Neighbor Cache – Mantiene una lista de vecinos locales a los cuales se envió
tráfico recientemente, almacenando sus direcciones IP, información sobre la
dirección MAC y un flag que indica si el vecino es un router o un host. También
informa si todavía hay paquetes en cola esperando ser enviados, la
accesibilidad de los vecinos y la próxima vez que está programado un evento
de detección de vecinos inaccesibles. Esta tabla es comparable a la tabla ARP
de IPv4.
72
Destination Cache – Mantiene información sobre destinos a los cuales se
envió tráfico recientemente (tanto destinos locales como remotos) y se
actualiza con información recibida a través de mensajes Redirect. El Neighbor
Cache se puede considerar como un subconjunto de la información del
Destination Cache.
4.5.2.4 Redireccionamiento
Los routers envían mensajes Redirect para redireccionar un host automáticamente
a un router más apropiado o informar al host qué destino se encuentra en el
mismo enlace. Este mecanismo es igual al que existe en IPv4.
4.5.2.5 Autoconfiguración de direcciones stateless
El mecanismo de autoconfiguración stateless, definido en la RFC 4862, permite
atribuir direcciones IPv6 a las interfaces sin necesidad de realizar configuraciones
manuales y sin utilizar servidores adicionales (DHCP), apenas realizando una
configuración mínima de los routers.
Para generar una dirección IP un host utiliza una combinación de datos locales,
como la dirección MAC de la interfaz o un valor aleatorio para generar el IID, e
información recibida de los routers, como múltiples prefijos. Si no hay routers
presentes, el host solo genera la dirección link local con el prefijo FE80::.
Los routers solo usan este mecanismo para generar direcciones link-local. Sus
direcciones globales se deben configurar de otra manera.
El mecanismo de autoconfiguración de direcciones se ejecuta respetando los
siguientes pasos:
73
Se genera una dirección link-local agregando el prefijo FE80::/64 al
identificador de la interfaz
Esta dirección pasa a formar parte de los grupos multicast solicited-node y all-
nodes
Se realiza la verificación de la unicidad de la dirección link-local generada
Si otro nodo del enlace ya está utilizando la misma dirección el proceso de
autoconfiguración se interrumpe y es necesario realizar una configuración
manual.
Si la dirección se considera única y válida ésta será automáticamente
inicializada para la interfaz.
El host envía un mensaje Router Solicitation al grupo multicast all-routers
Todos los routers del enlace responden con un mensaje Router Advertisement
informando: los routers por defecto; un valor predefinido para el campo Límite
de Direccionamiento; la MTU del enlace; la lista de prefijos de la red, para los
cuales también se generarán direcciones automáticamente.
Una dirección IPv6 puede asumir diferentes estados:
Dirección en tentativa – Dirección que aun no ha sido atribuida. Es el estado
previo a la atribución, mientras se realiza el proceso DAD. No se puede utilizar
en las comunicaciones del nodo, sino solamente para los mensajes
relacionados con el Descubrimiento de Vecinos
Dirección preferida – Dirección atribuida a la interfaz que puede ser utilizada
sin restricciones hasta que expire su tiempo de vida
Dirección desaprobada – Dirección cuyo tiempo de vida ha expirado. Se puede
utilizar para continuar las comunicaciones abiertas por la misma, pero no para
iniciar nuevas comunicaciones
Dirección válida – Término utilizado para designar tanto a las direcciones
preferidas como a las direcciones desaprobadas
74
Dirección inválida – Dirección que no se puede atribuir a una interfaz. Una
dirección se vuelve inválida cuando expira su tiempo de vida.
4.5.3 DHCPv6 (Dynamic Host Configuration)
El Dynamic Host Configuration Protocol (DHCP) es un protocolo de
autoconfiguración stateful que se utiliza para distribuir dinámicamente direcciones
IP en una red a partir de un servidor DHCP, permitiendo un mayor control de la
atribución de direcciones a los host.
Definido en la RFC 3315, el protocolo DHCPv6 es una alternativa al mecanismo
de autoconfiguración stateless de IPv6 que se puede utilizar cuando no hay
routers en la red o cuando su uso es indicado en los mensajes RA. Este
mecanismo puede proveer direcciones IPv6 y diferentes parámetros de la red,
como por ejemplo direcciones de servidores DNS (Domain Name System), NTP
(Network Time Protocol), SIP (Session Initiaton Protocol), etc.
En DHCPv6 el intercambio de mensajes entre cliente y servidor se realiza usando
el protocolo UDP. Los clientes utilizan una dirección link-local para transmitir o
recibir mensajes DHCP, mientras que los servidores utilizan una dirección
multicast reservada (FF02::1:2 o FF05::1:3) para recibir mensajes de los clientes.
Cuando el cliente necesita enviar un mensaje a un servidor que está fuera de su
subred se utiliza un Relay DHCP.
El uso de DHCPv6 permite un mayor control de la atribución de direcciones ya que
además de proporcionar opciones de configuración de red, permite definir políticas
para la distribución de direcciones y atribuir direcciones a los hosts que no se
derivan de la dirección MAC.
75
En una red IPv6 se puede combinar el uso de autoconfiguración stateless con
servidores DHCP. En este escenario es posible, por ejemplo, utilizar
autoconfiguración stateless para atribuir direcciones a los hosts y servidores
DHCPv6 para proveer información de configuración adicional, como por ejemplo la
dirección de los servidores DNS.
Los protocolos DHCPv6 y DHCPv4 son independientes, de modo que en una red
con doble pila se debe ejecutar un servicio para cada protocolo. En el caso de
DHCPv4 es necesario configurar en el cliente si éste utilizará DHCP, mientras que
la utilización de DHCPv6 se indica a través de las opciones de los mensajes RA.
Muchas veces el direccionamiento de una red se basa en los prefijos atribuidos
por los ISP. Si se cambia de proveedor es necesario renumerar todas las
direcciones de la red.
En IPv6 el proceso de redireccionamiento de los host se puede realizar de manera
relativamente sencilla. A través de los mecanismos del protocolo de
Descubrimiento de Vecinos el router puede anunciar un nuevo prefijo a todos los
hosts del enlace. También es posible utilizar servidores DHCPv6. Para tratar la
configuración y reconfiguración de prefijos en los routers tan fácilmente como en
los hosts, en la RFC 2894 se definió el protocolo Router Renumbering.
El mecanismo Router Renumbering utiliza mensajes ICMPv6 de tipo 138, los
cuales se envían a los routers a través de la dirección multicast all-routers, y
contienen las instrucciones para actualizar sus prefijos.
Los mensajes Router Renumbering están formados por los siguientes campos:
Tipo - 138 (decimal)
Código - 0 para mensajes de comando
1 para mensajes de resultado
76
255 para poner en cero el número secuencial
- Suma de Verificación
Verifica la integridad de los mensajes ICMPv6 y de parte del encabezado IPv6
Número secuencial – Identifica las operaciones
Número de segmento – Enumera diferentes mensajes RR válidos que tienen el
mismo número secuencial.
Flags
T: Indica si la configuración del router debe ser modificada o si se trata de una
prueba
R: Indica si se debe enviar un mensaje de resultado;
A: Indica si el comando se debe aplicar a todas las interfaces,
independientemente de su estado
S: Indica que el comando se debe aplicar a todas las interfaces,
independientemente de la subred a la cual pertenezcan
P: Indica que el mensaje de resultado contiene el informe completo del
procesamiento del mensaje de comando, o que el mensaje de comando fue
tratado previamente (y no se trata de una prueba) y que el router no lo está
procesando nuevamente.
Retraso máximo – Especifica el tiempo máximo, en milisegundos, que un
router debe retrasar el envío de cualquier respuesta a un mensaje de
comando.
Los mensajes de comando están formados por secuencias de operaciones,
Match-Prefix y Use-Prefix. Match-Prefix indica cuál prefijo debe ser modificado,
mientras que Use-Prefix indica el nuevo prefijo. Las operaciones pueden ser ADD,
CHANGE o SET-GLOBAL, que indican, respectivamente, que el router debe
agregar los prefijos indicados en Use-Prefix al conjunto de prefijos configurados,
eliminar el prefijo indicado en Match-Prefix (si es que existen) y cambiarlos por los
77
prefijos contenidos en Use-Prefix; o reemplazar todos los prefijos de alcance
global por los prefijos de Use-Prefix. Si el conjunto Use-Prefix es un conjunto
vacío, la operación ADD no realiza ninguna adición y las otras dos operaciones
simplemente borran el contenido indicado.
Los routers también envían mensajes de resultados que contienen un Match
Report para cada prefijo igual a los enviados en el mensaje de comando.
4.5.4 Path MTU Discovery
Dependiendo de los protocolos de enrutamiento cada enlace de la red puede tener
un valor de MTU diferente, es decir una limitación diferente respecto del tamaño
máximo de paquete que puede atravesarlo. Para poder encaminar paquetes
mayores que la MTU del enlace, éstos se deben fragmentar en paquetes menores
que serán ensamblados al llegar a su destino.
En la transmisión de paquetes IPv4 cada router a lo largo del camino puede
fragmentar los paquetes si éstos son mayores que la MTU del siguiente enlace.
Dependiendo del diseño de la red, un paquete IPv4 puede ser fragmentado más
de una vez durante su trayecto y ensamblado nuevamente en el destino final.
En IPv6 la fragmentación de los paquetes se realiza solamente en el origen, no
estando permitida en los routers intermedios. Este proceso tiene por objeto reducir
el overhead del cálculo de los encabezados modificados en los routers
intermedios.
Para ello en el inicio del proceso de fragmentación se utiliza el protocolo Path MTU
Discovery, descrito en la RFC 1981, que descubre de forma dinámica cuál es el
tamaño máximo de paquete permitido, identificando previamente las MTU de cada
enlace en el camino hasta el destino. Todos los nodos IPv6 deben soportar el
78
protocolo PMTUD (Path MTU Discovery). No obstante, las implementaciones
mínimas de IPv6 pueden omitir este soporte, utilizando 1280 bytes como máximo
tamaño de paquete.
El proceso Path MTU Discovery comienza suponiendo que la MTU de todo el
camino es igual a la MTU del primer salto. Si el tamaño de los paquetes enviados
es mayor que el que soporta alguno de los routers a lo largo del camino, éste lo
descartará y devolverá un mensaje ICMPv6 packet too big, que junto con el
mensaje de error devuelve el valor de la MTU del enlace siguiente. Luego de
recibir este mensaje el nodo de origen reduce el tamaño de los paquetes de
acuerdo con la MTU indicada en el mensaje packet too big.
Este procedimiento finaliza cuando el tamaño del paquete es igual o menor que la
MTU del camino, por lo que estas iteraciones (intercambio de mensajes y
reducción del tamaño de los paquetes) pueden ocurrir varias veces hasta
encontrar la menor MTU. Si el paquete es enviado a un grupo multicast el tamaño
será la menor PMTU (Path MTU) de todo el conjunto de destinos.
PMTUD puede parecer imperfecto desde un punto de vista teórico, ya que el
enrutamiento de los paquetes es dinámico y cada paquete puede ser entregado a
través de una ruta diferente. Sin embargo, estos cambios no son tan frecuentes y
si el valor de la MTU disminuye debido a un cambio de ruta el origen recibirá el
mensaje de error y reducirá el valor de la Path MTU.
4.5.5 Jumbograms
La RFC 2675 define una opción de encabezado de extensión Hop-By-Hop llamada
Jumbo Payload. Esta opción permite enviar paquetes IPv6 con cargas útiles con
una longitud comprendida entre 65.536 y 4.294.967.295 bytes, conocidos como
jumbograms.
79
Al enviar jumbograms, el encabezado IPv6 indicará un valor nulo (cero) en los
campos Tamaño de Datos y Siguiente Encabezado. Este último indicará que las
opciones del encabezado de extensión Hop-By-Hop deben ser procesadas por los
nodos, donde se indican los tamaños de los paquetes jumbograms.
El encabezado UDP tiene un campo de 16 bits llamado Tamaño que indica el
tamaño del encabezado UDP más el tamaño de los datos y no permite el envío de
paquetes de más de 65.536 bytes. No obstante, es posible enviar jumbograms
definiendo el campo Tamaño como cero y permitiendo que el receptor determine
el tamaño real del paquete UDP a partir del tamaño del paquete IPv6.
En los paquetes TCP las opciones Maximum Segment Size (MSS), que al iniciar
la conexión negocia el tamaño máximo de paquete TCP a ser enviado, y Urgent
Pointer, que indica el desplazamiento (offset) de bytes a partir del número de
secuencia en que se encuentran los datos de alta prioridad, tampoco pueden
referenciar paquetes mayores que 65.535 bytes. Así que para enviar jumbograms
es necesario establecer el valor de MSS igual a 65.535, valor que el receptor del
paquete tratará como infinito. La solución es similar para Urgent Pointer: se puede
establecer un valor de Urgent Pointer igual a 65.535, indicando que apunta más
allá del final de este paquete.
4.5.6 Gestión del grupo Muticast
Como se dijo antes, multicast es una técnica que permite direccionar múltiples
nodos como un grupo, posibilitando el envío de paquetes a todos los nodos que lo
componen a partir de una única dirección que los identifica.
Los miembros de un grupo multicast son dinámicos y los nodos pueden entrar y
salir de un grupo en cualquier momento. No existen limitaciones respecto del
tamaño de un grupo multicast.
80
La gestión de los grupos multicast en IPv6 es realizada por el Multicast Listener
Discovery (MLD) definido en la RFC 2710. Este protocolo es responsable de
informar a los routers multicast locales el interés de los nodos en formar parte o
salir de un determinado grupo multicast.
En IPv4 este trabajo es realizado por el protocolo Internet Group Management
Protocol (IGMPv2).
MLD utiliza tres tipos de mensajes ICMPv6:
Multicast Listener Query (Tipo 130) – Hay dos subtipos de mensajes Query.
Los mensajes General Query son utilizados por los routers para verificar
periódicamente los miembros del grupo, solicitando a todos los nodos
multicast que informen todos los grupos de los cuales forman parte. Los
mensajes Multicast-Address-Specific Query son utilizados por los routers
para descubrir si existen nodos que forman parte de determinado grupo.
Multicast Listener Report (Tipo 131) – Un nodo envía mensajes Report no
solicitados cuando éste comienza a formar parte de un grupo multicast.
También son generados en respuesta a mensajes Query.
Multicast Listener Done (Tipo 132) – Enviados por los nodos cuando
abandonan determinado grupo.
Estos mensajes son enviados con una dirección de origen link-local y con valor 1
en el campo Límite de Direccionamiento, garantizando que permanezcan en la red
local. Si el paquete tiene un encabezado Hop-by-Hop, el flag Router Alert estará
marcado; de este modo los routers no descartarán el paquete aunque la dirección
del grupo multicast en cuestión no esté siendo escuchada por los mismos.
En la RFC3810 se definió una nueva versión del protocolo MLD, denominada
MLDv2. Equivalente a IGMPv3, además de incorporar las funcionalidades de
81
gestión de grupos de MLD, esta nueva versión introduce el soporte para filtrado de
origen, lo que permite que un nodo especifique si no desea recibir paquetes de un
determinado origen o que informe su interés por recibir paquetes solo de
determinadas direcciones. Por defecto, los miembros de un grupo reciben
paquetes de todos los miembros de este grupo.
Otro mecanismo importante para el funcionamiento de los grupos multicast es el
Multicast Router Discovery (MRD). MRD fue definido en la RFC 4286 y es utilizado
para descubrir routers multicast en la red. Utiliza tres mensajes ICMPv6:
Multicast Router Advertisement (Tipo 151) – Este mensaje es enviado por
los routers para anunciar que está habilitado el enrutamiento IP multicast.
Se envía desde la dirección link-local del router a la dirección multicast all-
snoopers (FF02::6A)
Multicast Router Solicitation (Tipo 152) – Los dispositivos envían este
mensaje a los routers multicast para solicitar mensajes Multicast Router
Advertisement. Se envía desde la dirección link-local del dispositivo a la
dirección multicast allrouters (FF02::2)
Multicast Router Termination (Tipo 153) – Los routers envían este mensaje
para anunciar que sus interfaces ya no están encaminando paquetes IP
multicast. Se envía desde la dirección link-local del router a la dirección
multicast all-snoopers (FF02::6A).
Todos los mensajes MRD también se envían con un Límite de Direccionamiento
igual a 1 y con la opción Router Alert.
4.5.7 DNS (Domain Name System)
El protocolo Domain Name System (DNS) es una inmensa base de datos
distribuida que se utiliza para resolver nombres de dominio en direcciones IP y
82
viceversa. Posee una arquitectura jerárquica en la cual los datos están dispuestos
en forma de árbol invertido, distribuidos eficientemente en un sistema
descentralizado y con caché.
En la RFC 3596 se definieron algunos cambios para permitir que el DNS trabaje
con la versión 6 del protocolo IP. Se creó un nuevo registro para almacenar las
direcciones IPv6 de 128 bits, el AAAA o quad-A. Su función es traducir nombres a
direcciones IPv6, equivalente al registro A que se utiliza en IPv4. Si un host tiene
más de una dirección IPv6, éste tendrá un quad-A para cada dirección.
Los registros se representan de la siguiente manera:
Ejemplo: www.ipv6ejemplo.co IN A 200.160.4.22
IN AAAA 2001:12ff:0:4::22
Para la resolución inversa se agregó el registro PTR ip6.arpa, responsable de
traducir direcciones IPv6 a nombres. En su representación no se permite omitir la
secuencia de ceros y el bit menos significativo se coloca más a la izquierda, como
se puede observar en el siguiente ejemplo:
22.4.160.200.in-addr.arpa PTR www.ipv6ejemplo.co
2.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.0.0.0.0.f.f.2.1.1.0.0.2.ip6.arpa
PTR www.ipv6ejemplo.co.
Los otros tipos de registro DNS no sufrieron modificaciones, salvo que fueron
adaptados para soportar el nuevo tamaño de las direcciones.
La RFC 2874 introdujo los registros A6 y DNAME a fin de facilitar la renumeración
de redes, donde cada nameserver solamente tiene una parte de la dirección IPv6.
83
Inicialmente el dominio de resolución inversa, definido en la RFC 1886, era ip6.int,
pero hubo manifestaciones contrarias a su utilización debido a que .int significa
"internacional" y por lo tanto no debe ser empleado para fines administrativos en
Internet. Los registros A6 y DNAME quedaron obsoletos por el desudo y el
dominio .int fue reemplazado por el dominio .arpa, respectivamente en las RFC
3363 y 3152.
Deben observarse dos aspectos del soporte para IPv6 del DNS. El primero es que
un servidor DNS debe ser capaz de almacenar registros quad-A para direcciones
IPv6. El segundo es que un servidor DNS es capaz de transportar consultas y
respuestas a través de conexiones IPv6.
Es decir, la base de datos de un servidor DNS puede almacenar tanto registros
IPv6 como IPv4, independientemente de la versión de IP en que opera dicho
servidor.
Por lo tanto, un servidor que solamente tiene conexión IPv4 puede responder tanto
consultas AAAA como A. Sin embargo, las informaciones obtenidas en la consulta
vía IPv6 deben ser iguales a las obtenidas en la consulta IPv4.
4.5.8 QoS (Quality Of Servise)
Al principio, el protocolo IP trata todos los paquetes de la misma manera, sin
ninguna preferencia a la hora de encaminarlos. Esto puede tener diferentes
consecuencias para el desempeño de una aplicación, ya que en la actualidad
muchas de estas aplicaciones tales como voz y video sobre IP, requieren
transmisión y reproducción prácticamente en tiempo real y su calidad se puede
reducir debido a la pérdida de paquetes, entrega fuera de orden, retraso o
variación de la señal. Estos problemas pueden ocurrir debido a la forma en que el
tráfico llega a los routers y es manipulado por los mismos, ya que como provienen
84
de diferentes interfaces y redes el router procesa los paquetes en el orden en que
se reciben.
El concepto de QoS (Quality of Service), se utiliza para los protocolos cuya función
es proporcionar la transmisión de determinados tráficos con prioridad y garantía de
calidad. Actualmente existen dos arquitecturas principales: Differentiated Services
(DiffServ) e Integrated Services (IntServ). Ambas utilizan políticas de tráfico y se
pueden combinar para permitir QoS en redes LAN o WAN.
DiffServ trabaja por medio de clases, agregando y priorizando paquetes con
requisitos de QoS similares.
Los paquetes DiffServ se identifican por los ocho bits de los campos Tipo de
Servicio en IPv4 y Clase de Tráfico en IPv6, con el fin de identificar y distinguir las
diferentes clases o prioridades de paquetes que requieren QoS.
Ambos campos tienen las mismas definiciones y las prioridades atribuidas a cada
tipo de paquete se pueden definir tanto en el origen como en los routers y también
pueden ser redefinidas por los routers intermedios a lo largo del camino. En los
paquetes que no requieren QoS el campo Clase de Tráfico tiene valor 0 (cero).
En comparación con IntServ, DiffServ no exige ninguna identificación ni gestión de
los flujos y en general es más utilizado en las redes debido a su facilidad de
implementación.
El modelo IntServ se basa en la reserva de recursos por flujo y su utilización
normalmente está asociada al Protocolo de Reserva de Recursos (RSVP). El
protocolo RSVP se utiliza para reservar recursos a lo largo del camino de un flujo
que requiere QoS desde la fuente hasta el destino.
85
En IPv6, para identificar los flujos que requieren QoS se utilizan los 20 bits del
campo Identificador de Flujo que se completan con valores aleatorios
comprendidos entre 00001 y FFFFF. Los paquetes que no pertenecen a un flujo
deben completar el campo Identificador de Flujo con ceros. Los hosts y routers
que no tienen soporte para las funciones de este campo deben completarlo con
ceros cuando envían un paquete, no modificarlo cuando encaminan un paquete o
ignorarlo cuando reciben un paquete. Los paquetes de un mismo flujo deben tener
la misma dirección de origen y destino y el mismo valor en el campo Identificador
de Flujo.
RSVP utiliza algunos elementos del protocolo IPv6, como por ejemplo el campo
Identificador de Flujo y el encabezado de extensión Hop-by-Hop. Los paquetes
RSVP se envían con el mismo valor en el campo Identificador de Flujo junto con
el encabezado de extensión Hop-By-Hop, usado para transportar un mensaje
Router Alert que le indica a cada router en el camino del tráfico QoS que el
paquete IP debe ser procesado.
4.6 MOVILIDAD IPV6
El soporte para movilidad permite que un dispositivo móvil se desplace de una red
a otra sin necesidad de cambiar su dirección IP de origen, haciendo que el
movimiento entre redes sea invisible para los protocolos de las capas superiores.
Por lo tanto, todos los paquetes enviados a este nodo móvil continuarán siendo
encaminados al mismo usando la dirección de origen.
Existen algunos componentes clave para el funcionamiento del soporte para
movilidad IPv6:
Nodo móvil – Dispositivo que puede cambiar de una red a otra sin dejar de
recibir paquetes a través de su Dirección de Origen.
Red de origen – Red que atribuye la Dirección de Origen al Nodo Móvil.
86
Agente de Origen – Router ubicado en la Red de Origen y que mantiene la
asociación entre la Dirección de Origen y la Dirección Remota del Nodo
Móvil.
Dirección de origen – Dirección global unicast atribuida por la Red de
Origen al Nodo Móvil. Se utiliza como dirección permanente hacia la cual se
encaminan los paquetes.
Red remota – Cualquier red diferente a la de Red de Origen en la cual se
encuentra el Nodo Móvil.
Dirección remota – Dirección global unicast atribuida al Nodo Móvil por la
Red remota.
Nodo corresponsal – Nodo que se comunica con un Nodo Móvil. Puede
ser móvil o estacionario.
El Nodo Móvil tiene una Dirección de Origen fija, que le es atribuida por su Red de
Origen. Esta dirección se mantiene aunque no se desplace de su Red de Origen.
Al ingresar en una Red Remota el Nodo Móvil recibe una o más Direcciones
Remotas a través de los mecanismos de autoconfiguración, que consisten en un
prefijo válido en la Red Remota. Para asegurar que se reciban los paquetes IPv6
destinados a su Dirección de Origen, el nodo realiza una asociación entre la
Dirección de Origen y la Dirección Remota, registrando su nueva dirección en el
Agente de Origen mediante el envío de un mensaje Binding Updates. Como
respuesta a este mensaje el router de la Red de Origen envía un mensaje Binding
Acknowledgement.
Esta asociación de direcciones también se puede realizar directamente con el
Nodo corresponsal a fin de optimizar la comunicación. Para detectar que regresó a
su red el Nodo Móvil utiliza el proceso de Descubrimiento de Vecinos Inaccesibles
para determinar si su router por defecto está activo. En caso de ubicar un nuevo
router por defecto, éste generará una nueva dirección basada en el prefijo
87
anunciado en el mensaje RA. Sin embargo, el hecho de encontrar un nuevo router
por defecto no necesariamente significa que se encuentra en una nueva red;
puede que simplemente se trate de una renumeración de la red o del agregado de
un nuevo router. Por lo tanto, antes de asociar las direcciones con el Agente de
Origen y con los Nodos Corresponsales, el Nodo Móvil intentará ubicar
nuevamente su router por defecto y comparará si el intervalo entre el envío de
mensajes RA no solicitados es el mismo que está configurado en su Red Original.
Cuando el Nodo Móvil regresa a su Red de Origen envía un mensaje Binding
Updates para informarle su retorno al Agente de Origen y avisarle que ya no es
necesario que reencamine los paquetes. (Ver Figura 4.16)
Figura 4.16 Mensajes Binding
Fuente: ipreference.com
Las comunicaciones entre los nodos móviles y los nodos corresponsales pueden
producirse de dos maneras diferentes: túneles bidireccionales y optimización de
ruta.
En el caso de los túneles bidireccionales, los paquetes que el Nodo Corresponsal
envía a la Dirección Original del Nodo Móvil son interceptados por el Agente de
Origen, que los encamina, a través de un túnel hacia el Nodo Móvil utilizando la
Dirección Remota. Luego el Nodo Móvil responde al Agente de Origen, a través
del túnel, que reenvía el paquete al Nodo Corresponsal. En este caso no es
88
necesario que el Nodo Corresponsal tenga soporte para movilidad IPv6 ni que el
Nodo Móvil esté registrado en el Nodo Corresponsal.
En el modo Optimización de Ruta la comunicación entre el Nodo Móvil y el Nodo
Corresponsal ocurre de manera directa, sin necesitad de utilizar el Agente de
Origen. Para que esta comunicación ocurra el Nodo Móvil registra su Dirección
Remota en el Nodo Corresponsal que asocia las Direcciones de Origen y Remota
del Nodo Móvil.
El intercambio de mensajes entre ambos nodos funciona de la siguiente manera:
El Nodo Corresponsal envía paquetes con el campo Dirección de Destino del
encabezado base, completado con la Dirección Remota del Nodo Móvil. El
encabezado base es seguido por el encabezado de extensión Routing Tipo 2,
que transporta la Dirección de Origen del Nodo Móvil
Al recibir el paquete el Nodo Móvil procesa el encabezado Routing e inserta la
Dirección de Origen del encabezado Routing en el campo Dirección de Destino
del encabezado base. Las capas superiores continúan procesando el paquete
normalmente
Los paquetes enviados por el Nodo Móvil tienen el campo Dirección de Origen
del encabezado base completado con la Dirección Remota. El encabezado
base está seguido por el encabezado de extensión Destination Options, que
transporta en la opción Home Address la Dirección de Origen del Nodo Móvil.
Al recibir el paquete el Nodo Corresponsal inserta la Dirección de Origen del
encabezado Destination Options en el campo Dirección de Origen del
encabezado base. Las capas superiores continúan procesando el paquete
normalmente.
Para optimizar el funcionamiento de este servicio, a la especificación de IPv6 se
agregó un nuevo encabezado de extensión, el encabezado Mobility.
89
El encabezado de extensión Mobility se identifica por el valor 135 en el campo
Siguiente Encabezado. Es utilizado por el Nodo Móvil, por el Agente Remoto y por
el Nodo Corresponsal en el intercambio de mensajes relacionados con la creación
y gestión de asociaciones de direcciones.
Este encabezado tiene los siguientes campos:
Protocolo de datos – Corresponde al campo Siguiente Encabezado. En la
actualidad solo se utiliza el valor 59, en formato decimal, lo que indica que no
hay encabezado siguiente
Tamaño del encabezado de extensión – Contiene el tamaño del encabezado
Mobility en unidades de 8 bytes. El tamaño de este encabezado debe ser
siempre múltiplo de 8
Tipo de Mensaje Mobility – Indica el tipo de mensaje enviado
Suma de Verificación – Verifica la integridad del encabezado Mobility
Datos – Su formato y tamaño dependen del tipo de mensaje Mobility que está
siendo enviado.
Los siguientes son los tipos de mensajes Mobility más utilizados:
Binding Refresh Request (Tipo 0) – Enviado por el Nodo Corresponsal para
solicitarle al Nodo Móvil la actualización de la asociación de direcciones.
Binding Update (Tipo 5) – Enviado por el Nodo Móvil para notificar una nueva
Dirección Remota al Agente de Origen o al Nodo Corresponsal.
Binding Ack (Tipo 6) – Enviado para confirmar la recepción de un mensaje
Binding Update
Binding Error (Tipo 7) – Enviado por el Nodo Corresponsal para informar
errores.
90
También se crearon cuatro nuevos mensajes ICMPv6 que se utilizan en la
configuración de prefijos en la Red de Origen y en el descubrimiento de Agentes
de Origen.
El par de mensajes Home Agent Address Discovery Request y Home Agent
Address Discovery Reply se utilizan para descubrir dinámicamente un Agente de
Origen en su red. Esto evita la necesidad de realizar configuraciones manuales y
problemas en caso de renumeración del Agente de Origen.
El Nodo Móvil envía un mensaje Discovery Request a la dirección anycast del
Agente de Origen en su red. El campo Dirección de Origen del encabezado base
lleva la Dirección Remota del Nodo Móvil. El Agente de Origen responde enviando
un mensaje Discovery Reply. Los mensajes Discovery Request y Reply se
identifican por los valores 150 y 151, respectivamente, en el campo Siguiente
Encabezado.
Ya el mensaje Mobile Prefix Solicitation es enviado por el Nodo Móvil al Agente de
Origen para determinar cambios en la configuración del prefijo en la red. El Agente
Remoto responde enviando un mensaje Mobile Prefix Advertisement. En base a
esta respuesta el Nodo Móvil puede configurar su Dirección de Origen. Los
mensajes Mobile Prefix Solicitation y Advertisement se identifican,
respectivamente, en el campo Siguiente Encabezado por los valores 152 y 153.
También se introdujeron algunas modificaciones en el Protocolo de
Descubrimiento de Vecinos. A los mensajes RA se agregó el flag H, que permite
que un router anuncie si actúa como Agente de Origen en la red. Basándose en
este anuncio, un Nodo Móvil crea una lista de Agentes de Origen de su red.
91
Así y todo, para mantener esta lista actualizada el Nodo Móvil debe conocer las
direcciones global unicast de los routers, pero los mensajes RA traen solamente la
dirección link-local.
Para resolver este problema se agregó un nuevo flag a la opción Prefix
Information, el flag R. Cuando este flag está marcada indica que la opción Prefix
Information no contiene un prefijo pero sí la dirección global unicast del router.
También se crearon dos nuevas opciones para el protocolo, Advertisement Interval
y Home Agent Information. La primera indica el intervalo entre mensajes RA no
solicitados, información que es utilizada por el algoritmo de detección de cambio
de red. De acuerdo con las especificaciones del Protocolo de Descubrimiento de
Vecinos el intervalo mínimo entre el envío de estos mensajes debe ser de tres
segundos. Sin embargo, para asegurar que el Nodo Móvil detecte el cambio de
red y aprenda la información sobre la nueva red lo más rápidamente posible, los
routers con soporte para movilidad IPv6 se pueden configurar con un intervalo de
tiempo menor para el anuncio de mensajes RA.
La opción Home Agent Information se utiliza para indicar el nivel de preferencia de
asociación de cada Agente de Origen.
Las principales diferencias entre el soporte para movilidad de IPv6 y de IPv4 se
pueden resumir en los siguientes puntos:
Ya no es necesario implementar routers especiales que actúen como agentes
remotos
En lugar de formar parte de un conjunto de extensiones opcionales, la
optimización de la ruta está incorporada en el protocolo
La autoconfiguración stateless facilita la atribución de Direcciones Remotas
92
Aprovecha los beneficios del protocolo IPv6 tales como el protocolo de
Descubrimiento de Vecinos, los mensajes ICMPv6 y los encabezados de
extensión.
El uso del protocolo de Descubrimiento de Vecinos en lugar de ARP permite
que el proceso de intercepción de los paquetes destinados al nodo móvil no
dependa de la capa de enlace, lo que simplifica el protocolo y aumenta su
eficiencia
La búsqueda por agentes de origen que realizaba el nodo móvil pasó a ser
realizada utilizando anycast. De esta forma el nodo móvil solo recibirá la
respuesta de un único agente de origen. Con IPv4 se utiliza broadcast, lo que
implica una respuesta separada para cada agente de origen existente.
4.7 SEGURIDAD EN IPv6
Destinado principalmente a interconectar redes de investigación académicas, el
proyecto original de IPv4 no presentaba ninguna gran preocupación con respecto
a la seguridad de la información transmitida. Sin embargo, la creciente importancia
de Internet para las transacciones entre empresas y consumidores llevó a exigir
mayores niveles de seguridad, como por ejemplo identificación de usuarios y
encriptación de los datos, haciendo que fuera necesario agregar al protocolo
original nuevos mecanismos que garantizaran estos servicios. No obstante, las
soluciones adoptadas son habitualmente específicas para cada aplicación.
Este hecho es bastante claro en la Internet actual. Hay quienes sostienen que
para resolver este problema debería haber una nueva Internet, proyectada desde
cero (enfoque clean slate).
Al proyectar IPv6 se abordaron algunos aspectos de la seguridad, pero sus
implementaciones aun no están maduras. A pesar de tener más de diez años, no
93
hay buena experiencia en su uso. Las mejores prácticas continúan siendo
tomadas de IPv4, por lo que no siempre funcionan bien.
En IPv6 la seguridad fue una preocupación desde el inicio, por lo que en el
protocolo se implementaron varias herramientas de seguridad
Antes de entrar en detalle sobre las herramientas vamos a pensar un poco acerca
de la estrategia de despliegue de IPv6.
Podemos pensar en varios ejemplos históricos de despliegues de nuevas
tecnologías en que no se tuvieron en cuenta desde el inicio los aspectos de
seguridad, como cuando surgieron los routers inalámbricos. Podemos mencionar
varios ejemplos de la vida diaria de proyectos de última hora, demostraciones para
clientes, que terminan por convertirse en sistemas en producción y presentan
diferentes vulnerabilidades.
Lo ideal es que el despliegue de IPv6 se realice de una manera planificada y
organizada, tomando en cuenta la seguridad desde el primer momento.
Es interesante observar cuántos sistemas son capaces de ejecutar IPv6 y que
muchos de ellos vienen con el protocolo habilitado por defecto. La lista incluye
sistemas operativos, teléfonos celulares y equipos de red, entre otros.
IPv6 ofrece diferentes herramientas tanto para defensa como para ataque:
Defensa:
– IPsec
– SEND
– Crypto-Generated Address
– Unique Local Addresses
94
– Privacy Addresses
Ataque:
– Túnel automático
– Descubrimiento de vecinos y autoconfiguración
– Modelo end-to-end
– Novedad / Complejidad
– Falta de políticas, capacitación y herramientas.
Es necesario:
– Preocuparse por la seguridad y considerar la seguridad de los equipos desde el
inicio.
– Obtener equipos certificados
– Educación / Capacitación
– Actualizar las herramientas y procesos de seguridad
– Desarrollar prácticas de programación adecuadas (y seguras) para IPv6
– Buscar auditores / equipos de prueba que conozcan IPv6
IPSec fue desarrollado para IPv4 y es poco lo que cambia con IPv6. No obstante,
el soporte pasa a ser obligatorio y no hay NAT para entorpecer el funcionamiento.
IPSec se puede utilizar de dos maneras diferentes: modo transporte o modo túnel.
En modo transporte, ambos extremos de la comunicación requieren soporte IPSec
para que entre ellos la comunicación sea segura.
A diferencia de lo que ocurre en modo transporte, en modo túnel (también
conocido como VPN) IPSec se implementa en dispositivos propios (por ejemplo,
concentradores VPN) entre los que la comunicación IPSec se realiza
encapsulando todos los paquetes IP de los respectivos extremos.
95
Cabe destacar que en el caso de una comunicación en modo transporte se
mantiene el encabezado del paquete IP original. En modo túnel éste se codifica y
se crea un nuevo encabezado que hace posible la comunicación entre el
dispositivo emisor y el dispositivo receptor (del túnel).
Transporte - Protege solo los protocolos de las capas superiores, ya que el
encabezado de seguridad aparece inmediatamente después del encabezado
IP y antes de los encabezados de los protocolos de las capas superiores
Túnel - Protege todo el paquete IP, encapsulándolo dentro de otro paquete IP y
dejando visible solo el encabezado IP externo.
Muchas implementaciones de pila IPv6 todavía no soportan IPSec en forma
integral. Por lo tanto, éste se está usando sin soporte criptográfico. Pero aunque
se esté utilizando, en las redes IP todavía preocupan varios temas de seguridad.
No obstante lo anterior, IPv6 potencialmente puede mejorar la seguridad en
Internet.
• DoS: En IPv6 no existen direcciones broadcast
– Evita ataques mediante el envío de paquetes ICMP a la dirección
broadcast.
• Las especificaciones de IPv6 prohíben la generación de paquetes ICMPv6 en
respuesta a mensajes enviados a direcciones globales multicast (excepto
mensajes packet too big).
– Muchos sistemas operativos siguen la especificación
– Todavía hay cierta incertidumbre sobre el riesgo que pueden crear los
paquetes ICMPv6 que se originan en direcciones multicast globales.
A continuación se nombraran algunas recomendaciones para mejorar la seguridad
en IPv6:
96
Implementar extensiones de privacidad solo en las comunicaciones externas.
Cuidado con el uso indiscriminado, puede dificultar las auditorías internas.
Las direcciones de uso interno se deben filtrar en los routers de borde. Las
direcciones multicast como FF02::1 (all-nodes on link), FF05::2 (all-routers on
link) y FF05::5 (all DHCPv6 servers) se pueden transformar en nuevos vectores
de ataque.
Filtrar el ingreso de paquetes con direcciones de origen multicast.
No usar direcciones obvias
Filtrar servicios innecesarios en el firewall.
Filtrar mensajes ICMPv6 no esenciales
Filtrar direcciones bogon.
En IPv6 este filtrado es diferente al que se realiza en IPv4.
En IPv4 se bloquean los rangos no asignados (son pocos).
En IPv6 es al revés. Es más fácil liberar solo los rangos asignados.
Bloquear fragmentos de paquetes IPv6 con destino a equipos de red.
Descartar paquetes de tamaño menor a 1280 bytes (excepto el último).
Los mecanismos de seguridad de BGP y de IS-IS no cambian.
Con OSPFv3 y RIPng se debe utilizar IPSec.
Limitar el número de saltos para proteger dispositivos de red.
Utilizar IPSec siempre que sea necesario.
97
5. DESARROLLO INGENIERIL
5.1 INSTALACIÓN DE IPV6
La mayor parte de los sistemas operativos, desde el año 2001 aproximadamente,
tienen algún tipo de soporte de IPv6. En algunos casos, inicialmente no se trataba
de un soporte comercial, sino de versiones de prueba, aunque se incorporaban a
sistemas operativos de producción. Tal es el caso del soporte de IPv6 en Windows
2000, e incluso en la primera versión de Windows XP antes del lanzamiento del
denominado Service Pack 1 (SP1).
Cada vez es más frecuente que diversas plataformas o sistemas operativos, no
solo incorporen IPv6, sino que además éste sea activado por defecto por el
fabricante, sin requerir intervención alguna por parte del usuario.
Lo expuesto es válido no solo para sistemas operativos de computadores de
sobremesa y portátiles, sino también para otros dispositivos que utilizan los
mismos sistemas operativos, o versiones reducidas de los mismos, por ejemplo
teléfonos celulares, agendas electrónicas, plataformas de juegos, etc. Es cierto,
lógicamente, que en algunos casos, dichas versiones reducidas de los sistemas
operativos, no incorporan todas las funcionalidades del sistema operativo original,
y por tanto, se podría dar el caso de no poder acceder a todos las funciones que
se mostrarán para la configuración y prueba de IPv6.
5.1.1 Instalación de IPv6 en Windows XP/2003
En realidad se podría decir que IPv6 ya está instalado tanto en Windows XP como
en Windows Server 2003 y por tanto, más que de instalación, se habla de
activación.
98
Existen dos procedimientos para habilitar IPv6 en estas dos plataformas:
En una ventana DOS ejecutar: ipv6 install. Tras unos segundos, un
mensaje de confirmación indicara la correcta instalación.
A través del entorno gráfico o panel de control, llegar hasta Conexiones de
red, seleccionar la red de área local o red inalámbrica, Propiedades con el
pulsador derecho del ratón y a continuación pulsar sobre instalar, protocolo
y seleccionar Microsoft TCP/IP version 6. (Ver Figura 5.1).
Figura 5.1: Instalación de IPv6 en Windows XP
5.1.2 Instalación IPv6 en Vista
Desde el lanzamiento de Windows Vista, este sistema operativo incluye soporte de
IPv6 instalado y habilitado por defecto. Por lo tanto, no es necesario hacer ninguna
configuración adicional. En caso de que se hubiera desactivado, se podría utilizar
99
el procedimiento con netsh o entorno gráfico indicado para Windows XP/2003.(Ver
Figura 5.2).
Téngase en cuenta que para usar netsh, se requiere una ventana de DOS
explícitamente abierta con permisos de administración.
Figura 5.2: Instalación en Windows Vista
En comparación con XP/2003, IPv6 en Vista tiene funcionalidades adicionales,
como por ejemplo:
Soporte completo IPsec
MLDv2 (Multicast Listener Discovery Version 2)
LLMNR (Link-Local Multicast Name Resolution)
No requiere un servidor DNS. Los nodos IPv6 en un segmento piden el
nombre a una dirección IPv6 multicast en forma similar al funcionamiento
de NetBIOS.
Soporte de direcciones IPv6 en URLs
IPv6 Control Protocol (IPV6CP - RFC5072)
IPv6 sobre PPP
DHCPv6, en el cliente y el servidor
100
Identificador de Interfaz aleatorio por defecto (RFC3041)
Teredo soporta NATs simétricos
Activo por defecto. Solo se utiliza si la aplicación requiere soporte IPv6 y no
está disponible de forma nativa.
Se puede comprobar que está instalado por medio de comandos, o con el entorno
gráfico de forma similar a lo indicado para el caso de XP:
5.1.3 Instalación IPv6 en Windows 7
Igual que en el caso de Vista/2008, Windows 7 incorpora IPv6 instalado y
habilitado por defecto. Igualmente, en caso de que se hubiera desactivado, se
podría utilizar el procedimiento con netsh o entorno gráfico indicado para Windows
XP/2003.
En este caso también se debe tener en cuenta que para usar netsh, se requiere
una ventana de DOS explícitamente abierta con permisos de administración.
Las características de esta versión se pueden resumir en:
• Soporte IPv6 similar al de Vista y Server 2008
IPsec, MLDv2, LLMNR, IPv6 en URLs, IPV6CP, IPv6 sobre PPP,
DHCPv6, Teredo.
Cambia: Identificador de Interfaz aleatorio por defecto (RFC3041)
No usa EUI-64 por defecto para el identificador de interfaz en las
direcciones autoconfiguradas.
• Nuevas mejoras
IP-HTTPS (IP over Secure HTTP)
Permite a los hosts atravesar un servidor proxy o firewall y
conectarse a redes privadas por medio de IPv6 dentro de un túnel
101
HTTPS. HTTPS no provee seguridad a los datos, es necesario usar
IPsec para dar seguridad a una conexión IP-HTTPS.
• DirectAcces
Permite a los usuarios conectarse de manera transparente a la red
corporativa sin establecer específicamente una conexión VPN. También
permite al administrador de red seguir en contacto con los host móviles
fuera de la oficina y poder hacer actualizaciones y dar soporte a dichos
equipos. Es una arquitectura en la que un cliente IPv6 se comunica con
un servidor IPv6 en la red corporativa. También se puede usar
conexiones desde Internet IPv4 empleando 6to4, Teredo e ISATAP.
También se puede usar IP-HTTPS. DirectAccess usa túneles IPsec para
proveer seguridad a la autenticación y al acceso a recursos.
El cliente puede ser un Windows 7 o Server 2008. El servidor puede ser
un Server 2008
Igual que en el caso de Vista, se puede comprobar que está instalado, mediante el
entorno gráfico (Ver figura 5.3):
Figura 5.3 Instalación Windows 7
102
5.1.4 Instalación de IPv6 en Windows 2000
El método más fiable para la instalación de la pila IPv6 para Windows 2000,
requiere primero descargar el código correspondiente a la pila IPv6, dado que a
diferencia de los sistemas operativos hasta ahora mencionados, en este caso no
está preinstalado por el fabricante.
Como se ha indicado antes, Windows 2000 IPv6 no está soportado por Microsoft,
dado que se trataba de una versión de desarrollo.
Por lo tanto, en primer lugar, se debe descargar “Microsoft IPv6 Technology
Preview for Windows 2000”:
• tpipv6-001205-SP2-IE6 para SP1 y SP2
• tpipv6-001205-SP3-IE6 para SP3
• tpipv6-001205-SP4-IE6 para SP4
Una vez realizada la descarga, el procedimiento de instalación es el siguiente:
• Entrar en el sistema como usuario con privilegios locales de administrador
• Extraer los ficheros de IPv6 Technology Preview, por ejemplo en C:\IPv6Kit.
• Seguir el procedimiento de SPn & IE6 fixed.txt para cambiar el
fichero/setup/hotfix.ini.
• Ejecutar Setup.exe o hotfix.exe.
• Desde el escritorio de Windows 2000, clic en Inicio, luego Configuración y
luego Conexiones de Red. Alternativamente, hacer clic con el botón
derecho en Mis Sitios de Red, luego clic en Propiedades, hacer clic con el
botón derecho en conexiones basadas en Ethernet para las que se desea
añadir el protocolo IPv6 y luego clic en Propiedades. Normalmente, esta
conexión se denomina Conexión de Área Local.
• Clic en Install.
103
• En el cuadro de diálogo Seleccionar Tipo de Componente de Red, hacer
clic en Protocolo y luego clic en Añadir.
• En el cuadro de diálogo Seleccionar Protocolo de Red, hacer clic en
Microsoft IPv6 Protocol y luego clic en Aceptar
• Clic en Cerrar para cerrar el cuadro de diálogo de las Propiedades de la
Conexión de Área Local.
5.1.5 Comprobación de IPv6 – Windows
Una vez se ha instalado IPv6, en función de las diferentes plataformas, se tiene
una o varias opciones para verificar que dicha instalación ha sido realizada
correctamente e incluso si se tiene conectividad tanto en la red local como con
otras redes IPv6.
Además de visualizar si la pila IPv6 ha sido instalada a través del entorno gráfico,
como se ha indicado anteriormente, se puede utilizar el comando ipconfig o ipv6 if
(“Ipv6 if” no está disponible en las últimas versiones de Windows).
El comando ipconfig facilitará la información de configuración IPv6 de las
diferentes interfaces al igual que de IPv4, mientras que ipv6 if sólo muestra
información relativa a IPv6.
Una prueba adicional es comprobar que se puede alcanzar la propia interfaz,
mediante el comando ping/ping6 a la dirección Loopback ::1 (ping6 puede estar
disponible dependiendo de la versión específica de cada sistema operativo).
El paso siguiente sería, comprobar que hay conectividad con la red local. Esto sólo
es posible si hay otras máquinas con IPv6 correctamente configurada en dicha red
local (y la configuración de los cortafuegos permite usar el comando ping). El uso
104
sería equivalente al ejemplo anterior, pero utilizando la dirección de enlace local (o
una dirección global, si existiera), de la máquina a la que se desea hacer ping.
Un paso adicional, sería el uso de una herramienta que muestre los saltos entre
los diferentes puntos de la red, desde la maquina propia hasta la máquina destino,
lo que se denomina un traceroute (traza de la ruta). Para ello se usa el comando
tracert o tracert6 (según la versión/plataforma).
5.1.6 Configuración de IPv6 – Windows
Antes de realizar cualquier configuración es necesario saber qué índice le
corresponde a la interfaz en donde se va a realizar la configuración. Para lograr
esto se escribe el siguiente comando:
netsh interface ipv6 show interface
El índice asignado a la interfaz es visible al costado izquierdo. (Ver figura 5.4).
Figura 5.4 Índice correspondiente a cada Interfaz
Por diversos motivos, puede requerirse configurar manualmente una dirección
IPv6. Para ello se usa el comando netsh con el formato siguiente:
105
netsh interface ipv6 add address [interface=]<cadena (nombre de interfaz o
índice)> [address=]<dirección IPv6>[/<entero>] [[type=]unicast|anycast]
[[validlifetime=]<entero >|infinite] [[preferredlifetime=]<entero>|infinite]
[[store=]active|persistent]
Ejemplo:
netsh interface ipv6 add address 5 2001:db8::2 type=unicast validlifetime=infinite
preferredlifetime=10m store=active
Igualmente, se puede revisar la configuración con netsh (asumiendo que es la
interfaz numero 5)
netsh interface ipv6 show address 5
Una vez configurada una dirección manualmente, se puede modificar con:
netsh interface ipv6 set address [interface=]<cadena> [address=]<dirección
IPv6>[[type=]unicast|anycast] [[validlifetime=]<entero>|infinite]
[[preferredlifetime=]<entero
>|infinite] [[store=]active|persistent]
Ejemplo:
netsh interface ipv6 set address 5 2001:db8::2 preferredlifetime=infinite
Y finalmente, dicha dirección puede ser eliminada con:
netsh interface ipv6 delete address [interface=]<cadena> [address=]<dirección
IPv6>[[store=]active|persistent]
106
Ejemplo:
netsh interface ipv6 delete address 5 2001:db8::2 store=persistent
Igualmente, se puede dar el caso en que sea necesario agregar una ruta estática,
y de forma similar, se utiliza:
netsh interface ipv6 add route add route [prefix=]<dirección IPv6>/<entero>
[interface=]<cadena> [[nexthop=]<dirección IPv6>] [[siteprefixlength=]<entero>]
[[metric=]<entero>] [[publish=]no|yes|immortal] [[validlifetime=]<entero>|infinite]
[[pre ferredlifetime=]<entero>|infinite] [[store=]active|persistent]
Ejemplo:
netsh interface ipv6 add route 2002::/16 5 fe80::200:87ff:fe28:a0e0
store=persistent
Donde, fe80::200:87ff:fe28:a0e0 es la puerta de enlace que se desea configurar
para la ruta 2002::/16.
Para borrar dicha ruta puede emplearse:
netsh interface ipv6 delete route [prefix=]<dirección IPv6>/<entero>
[interface=]<cadena> [[nexthop=]<dirección IPv6>] [[store=]active|persistent]
Ejemplo:
netsh interface ipv6 delete route 2002::/16 5 fe80::200:87ff:fe28:a0e0
store=persistent
Además se pueden visualizar las rutas con el siguiente comando (Ver figura 5.5):
netsh interface ipv6 show route [[level=]normal|verbose] [[store=]active|persistent]
107
Figura 5.5 Rutas configuradas en cada interfaz
5.2 SIMULADOR GNS3
Durante el desarrollo de este proyecto se realizarán varias configuraciones tanto
en router como en host, por lo que se hace necesario el uso de simuladores para
tener la posibilidad de realizar las prácticas propuestas sin el requerimiento de
contar con un Laboratorio de Redes especializado.
Actualmente existen diversos simuladores de red como: OMNeT++, Packet Tracer,
Boson Net Simulator y GNS3 solo por nombrar algunos. Sin embargo el objetivo
es utilizar un simulador que proporcione la robustez necesaria y que dé soporte al
protocolo IPv6.
Realizando diferentes pruebas con distintos simuladores, se ha encontrado que el
simulador que más se ajusta a las necesidades de este proyecto es GNS3.
GNS3 es un simulador grafico de redes que permite diseñar fácilmente topologías
de red y luego ejecutar simulaciones en él. Hasta este momento GNS3 soporta el
IOS de routers, ATM/Frame Relay/switchs Ethernet y PIX firewalls.
108
Además este simulador permite extender una red propia, conectándola a la
topología virtual. Para realizar esto, GNS3 está basado en Dynamips, PEMU
(incluyendo el encapsulador) y en parte en Dynagen. Fue desarrollado en python a
través de PyQt la interfaz grafica (GUI) confeccionada con la poderosa librería Qt,
famosa por su uso en el proyecto KDE. GNS3 también utiliza la tecnología SVG
(Scalable Vector Graphics) para proveer símbolos de alta calidad para el diseño
de las topologías de red.
Las capacidades más importantes que se pueden resaltar de GNS3 y que han
servido como punto de partida para tomar la decisión de estudiar más a fondo este
simulador son las siguientes:
Se encuentra disponible de forma gratuita en la red.
Es fácil de instalar ya que todos los programas que necesita para funcionar se
encuentran en un solo paquete de instalación.
Está en constante actualización y periódicamente se puede encontrar
versiones de la aplicación más robustas y con nuevas funcionalidades.
Permite la conexión Telnet a la consola de un router virtual, de forma fácil
directamente desde la interfaz gráfica.
Alternativamente también permite trabajar directamente desde consola de
gestión de Dynagen.
Permite la comunicación entre redes virtuales y redes del mundo real.
Es apropiado para simular redes de grandes tamaños ya que permite que un
cliente GNS3 pueda correr en una máquina diferente a la que contiene al
emulador Dynamips, repartiendo el procesamiento entre diferentes PCs.
Puede capturar los paquetes que pasan por enlaces virtuales y escribir los
resultados de la captura en archivos que pueden ser interpretados por
aplicaciones como Wireshark o tcpdumps.
Los foros de Internet evidencian que es una aplicación ampliamente utilizada.
109
A continuación se encuentra una tabla comparativa con los distintos simuladores
con los que se experimentaron previamente a la elección del simulador GNS3.
Tabla 5.1 Tabla comparativa entre los simuladores usados
Static Routing
RIPng OSPF
v3 IS-IS IPv6
M-BGP
DUALSTACK
6to4 ISATAP GRE
(IPv6) Facilidad
de uso
PACKET TRACER x x x x
ROUTER SIM x x x x
BOSON NET SIMULATOR x x x x x
OMNET++ x x x x x x x x x
GNS3 x x x x x x x x x x
Omnet++ es una potente herramienta, eficiente, enfocada al area académica,
desarrollada para modelar y simular eventos discretos en redes de
comunicaciones. Sin embargo, “un modelo de simulación en OMNET++ consiste
de una serie de modulos que se comunican a través del paso de mensajes y en el
que los modulos activos son módulos simples y cuya implementación es através
de la programación en C++ empleando la librería de simulación” dificultando la
implementación de los protocolos de enrutamiento y técnicas de transición. Por el
contrario, GNS3 permite centralizar su uso, en el sistema operativo de los routers
en los cuales se trabaja, en este caso CISCO lo cual simplifica y reduce el trabajo
necesario para implementar cada simulación.
5.2.1 Uso de GNS3
A continuación se tratará de explicar claramente cómo hacer uso de GNS3,
detallando los pasos que hay que seguir para la emulación de las diferentes
plataformas CISCO soportadas. Así mismo se describirán los diferentes métodos
existentes para la simulación de PCs y se explicará cómo usar los switches
110
Ethernet. De igual manera se mostrará cómo realizar los procesos básicos de
GNS3, como por ejemplo la creación de enlaces, la interconexión de redes reales
con virtuales, la captura de datos, la operación en modo hipervisor o el
almacenamiento de la topología.
5.2.1.1 Emulación Router CISCO
Como ya se ha indicado anteriormente, para emular routers CISCO reales se
necesita una imagen del IOS CISCO perteneciente al router que contiene las
características que se desea “clonar”. La imagen del IOS CISCO debe ser
buscada por cuenta de cada persona o puede ser solicitada directamente a
CISCO si se es cliente. La imagen debe soportar el protocolo IPv6.
En este sentido, el emulador habilitará un número de ranuras o “slots”
dependiendo del tipo de plataforma que se emula y en cada una de esas ranuras
se podrán colocar solo ciertos tipos de adaptadores de interfaces. Por lo tanto, si
se quiere añadir “capacidades de hardware” en el router virtual, se debe
seleccionar el tipo de adaptador de red que éste puede soportar en la
configuración del router virtual. Ver Tabla 5.1 para más detalle.
Tabla 5.2 Lista de adaptadores correspondientes a cada tipo de plataforma
Adaptadores de Interfaces Disponibles
Routers Nombre Descripción
1700s WIC-1T 1 puerto serie
WIC-2T 2 puertos serie
WIC-1ENET 1 puerto Ethernet
2600s NM-1E 1 puerto Ethernet
NM-4E 4 puertos Ethernet
NM-1FE-TX 1 puerto FastEthernet
111
NM-16ESW
Módulo de switch Ethernet (16
puertos)
NM-NAM
Conecta el router virtual a un PC
virtual
NM-IDS
Conecta el router virtual a un PC
virtual
WIC-1T 1 puerto serie
WIC-2T 2 puertos serie
3600s NM-1E 1 puerto Ethernet
NM-4E 4 puertos Ethernet
NM-1FE-TX 4 puertos Ethernet
NM-16ESW
Módulo de switch Ethernet (16
puertos)
NM-4T 4 puertos serie
Leopard-2FE
Puerto automático FastEthernet
en slot 0
3700s NM-1FE-TX (FastEthernet,
1 port) 1 puerto FastEthernet
NM-4T 4 puertos serie
NM-16ESW
Módulo de switch Ethernet (16
puertos)
GT96100-FE 2 puertos integrados
NM-NAM
Conecta el router virtual a un PC
virtual
NM-IDS
Conecta el router virtual a un PC
virtual
WIC-1T 1 puerto serie
WIC-2T 2 puertos serie
7200s C7200-IO-FE Solo puerto FastEthernet en slot
112
0
C7200-IO-2FE 2 puertos FastEthernet en slot 0
C7200-IO-GE-E
Sólo Puerto GigabitEthernet en
slot 0
PA-FE-TX 1 puerto FastEthernet
PA-2FE-TX 2 puertos FastEthernet
PA-4E 4 puertos Ethernet
PA-8E 8 puertos Ethernet
PA-4T+ 4 puertos serie
PA-8T 8 puertos serie
PA-A1 Puerto ATM
PA-POS-OC3 Puerto POS
PA-GE 1 puerto GigabitEthernet
Los pasos a seguir para la emulación y configuración de un router en GNS3 son
los siguientes:
1) En el grupo de plataformas hacer clic sobre el router que se quiere emular y
arrastrar hasta el área de construcción de topologías. Ver figura 5.6.
Figura: 5.6 ventana principal GNS3
113
2) Hacer clic derecho sobre el router y después elegir “configure”, tal como se
muestra en la Figura 5.7.
Figura 5.7 Menú de opciones de un router
3) Hacer clic en el nombre del router, después en la pestaña “slots” y finalmente
elegir las interfaces que se desea instalae en el dispositivo haciendo clic en de
cada slot. Guardar los cambios cliqueando en “OK”. Ver figura 5.8
Figura 5.8 Ventana de configuración del nodo
114
4) Encender el router con un clic derecho y eligiendo “start”, como se muesra en la
Figura 5.9. Notar que ahora en el resumen de la topología ubicado a la derecha de
la pantalla, el indicador del router se encuentra de color verde.
Figura 5.9 Encendido del router mediante la opción Start
5) Calcular el valor de IDLEPC para la imagen de IOS utilizada con un clic derecho
en el router y eligiendo “Idle PC” del menú desplegado (ver Figura 5.10).
Figura 5.10 Cálculo de IDLEPC para la imagen del IOS
6) Tras unos instantes se apreciará una ventana como la de la Figura 5.11, hacer
clic en para ver todos los posibles valores de IDLE PC calculados, los mejores
son los que tiene un * a la izquierda, elegir uno de ellos y hacer clic en “apply”.
Figura 5.11 Selección de IDLE PC para la imagen del router
115
7) Finamente hacer clic derecho sobre el router y elegir “console” para obtener una
ventana de Telnet con la consola del router que se está emulando (ver Figura
5.12).
Figura 5.12 Selección de la opción de consola para administración del router
5.2.1.2 Emulación de Switches Ethernet
GNS3 posee integrada la capacidad de emulación de switches simples Ethernet
con funcionalidades básicas como la creación de VLANs o el funcionamiento del
trunking 802.1q. Por defecto, un switch emulado con GNS3 tiene 8 puertos Access
configurados en la VLAN1 pero se puede añadir hasta 10.000 puertos, pudiendo
ser cada uno de ellos un puerto de acceso o uno troncal.
116
En este sentido, si se desea trabajar con switches que poseen más
funcionalidades, GNS3 puede emular una tarjeta “EtherSwitch” que puede ser
soportada sólo por determinadas plataformas CISCO. La tarjeta “EtherSwitch” que
emula Dynamips es “NM-16ESW” además puede ser incluida en casi todas las
plataformas disponibles en GNS3. Las principales capacidades de esta tarjeta son:
Interfaces Ethernet Layer 2
Interfaces Switch Virtual (SVI)
Protocolo VLAN Trunk
EtherChannel
Protocolo Spanning Tree
Protocolo Cisco Discovery
Switched Port Analyzer (SPAN)
Calidad de Servicio
IP Multicast
Storm-Control
Seguridad de Puertos
Stacking
Control de flujo.
Cabe resaltar que una tarjeta “NM-16ESW” no puede soportar todos los comandos
existentes en un switch Ethernet, por lo que para su uso se recomienda consultar
los manuales existentes en CISCO.
La emulación y configuración de un switch Ethernet usando GNS3 se hace de la
siguiente manera:
117
1) Hacer clic en el “Ethernet Switch” situado en la parte izquierda de la
ventana principal y arrastrar hasta el área de construcción de topologías
(ver Figura 5.13).
Figura 5.13 Ventana principal GNS3
2) Hacer clic derecho sobre el ícono del switch y elegir “configure”, como se
muestra en la Figura 5.14.
Figura 5.14 Selección de la opción “configure” de un switch
3) En ventana de la figura 5.15, hacer clic sobre el nombre del dispositivo y borrar
la configuración inicial del switch Ethernet seleccionando cada puerto y haciendo
clic en “Delete”.
Figura 5.15 Ventana de configuración del switch
118
4) Configurar los nuevos puertos ingresando los parámetros de la sección
“Settings” y hacer clic en “Add” (Ver Figura 5.16). Finalmente guardar los cambios
haciendo clic en “OK”.
Figura 5.16 Sección “settings” de la ventana de configuración del switch
5) Crear enlaces entre los diferentes dispositivos disponibles y cualquiera de las
interfaces del switch que se acaban de añadir.
5.2.1.3 Simulación de PC’s
119
GNS3 permite, además de los equipos de red, la incorporación de PCs en las
topologías creadas, lo que facilita la comprobación y el estudio de las redes
simuladas. Las formas existentes de simulación de PCs en GNS3 son las
siguientes:
- Usando Virtual PC
Esta primera forma de simulación de PCs se realiza utilizando un programa
llamado “Virtual Pc Simulator” ó VPC que usa puertos UDP para la comunicación
entre el simulador y cada uno de los PCs simulados. VPC es un programa que
corre tanto en Windows como en Linux y que se puede descargar desde Internet
de forma gratuita.
Las ventajas de usar VPC es que su uso es simple y que no usa grandes
cantidades de memoria ni ciclos de CPU para su funcionamiento; por otro lado,
tiene la desventaja de que tiene funcionalidad limitada, ya que solo permite el uso
de comandos como “ping” y “traceroute”; además sólo soporta un máximo de
nueve (09) PCs simulados simultáneamente.
Los pasos a seguir para la simulación de PCs utilizando este método son:
1) Descargar e instalar el programa “Virtual Pc Simulator” desde
http://wiki.freecode.com.cn/doku.php?id=wiki:vpcs.
2) Escribir el carácter “?” para observar los comandos disponibles, como puede
verse en la Figura 5.17 y “show” para ver la configuración de red actual de los PCs
simulados. Para introducir comandos en un detreminado PC, este se puede
seleccionar escribiendo su número de identificación correspondiente (del 1 al 9)
como se muestra en la Figura 5.18.
120
Figura 5.17 Comandos disponibles en VPC’s
3) Se puede configurar los datos de cada PC IPv4 ingresando el comando “ip”
seguido de la dirección IP (192.168.0.2), la puerta de enlace por defecto del PC
(192.168.0.1), la máscara de subred (24) y Enter. En el caso de IPv6 se asigna de
igual forma, sin embargo no es necesario introducir la puerta de enlace por
defecto. Si se desea configurar otro PC se debe escribir el número
correspondiente al PC y luego presionar “Enter”.
Figura 5.18 Configuración de los PC’s virtuales
4) Para incluir los PCs en la topología se debe seleccionar el ícono
correspondiente a una “nube” (cloud) y arrastrarlo al área de construcción de
topologías. Luego dando clic derecho sobre la nube se puede seleccionar la
121
opción de cambiar el símbolo (Change symbol) seleccionar Computer, dar clic en
Apply y luego en OK. Se puede arrastrar tantas nubes como PCs se quiera
integrar al simulador.
5) Para configurar los PCs, hacer clic derecho en cada uno de ellos y elegir
“configure”. Hacer clic en C0 debajo de “clouds” y elegir la pestaña llamada “NIO
UDP”. Ver figura 5.19.
Figura 5.19 Selección de la pestaña NIO UDP para la configuración del PC
6) Configurar los parámetros “Local port”, “Remote host” y “Remote port” debajo
de “Settings” con los datos mostrados en la figura 5.21 que corresponden a los
puertos asignados por VPC para un PC virtual. Hacer clic en “Add” y finalmente en
“OK”.
Figura 5.20 Ventana para la configuración de PCs virtuales
122
6) Repetir los pasos 5 y 6 en cada una de las otras nubes añadidas pero asignar
valores correlativos a los mostrados anteriormente, tanto para el puerto local como
para el remoto.
Figura 5.21 Configuración de PC’s virtuales
- Creación de Enlaces
En GNS3 los enlaces son usados para unir dos dispositivos de red de la topología
creada. Estos pueden ser GigaEthernet, ATM, POS, FastEthernet, Ethernet o
Serie y su tipo depende de los adaptadores de interfaz que tengan los dos
dispositivos a los que une.
Para simular un enlace se siguen los siguientes pasos:
1) Hacer clic en el ícono situado en la parte superior de la ventana principal de
GNS3 y elegir “Manual” para que se asigne el tipo de enlace automáticamente.
Las diferentes opciones de enlaces disponibles se pueden ver en la Figura 5.22.
Figura 5.22 Tipos de enlaces disponibles para interconectar dispositivos
123
2) Hacer clic sobre el dispositivo que se va a conectar. Como ajemplo, asumiendo
que los dispositivos a interconectar son dos routers, al hacer clic sobre el ícono
correspondiente a uno de ellos, aparecerá un cuadro con todas las interfaces
disponibles (indicador en rojo). Se elige una de ellas y se repite el proceso para el
router del otro extremo del enlace. Ver figura 5.23. Este proceso se puede repetir
para todas las conexiones que se desee realizar.
Figura 5.23 Interfaces disponibles en router
3) Cuando el enlace ha sido establecido, se debe hacer clic sobre el ícono
para deshabilitar el proceso de creación de enlaces.
- Usando un PC real
En este caso usaremos la capacidad que tiene el simulador de poder conectar
dispositivos reales a una topología simulada. Se debe arrastrar una nube hacia el
área de construcción de topologías, asignarle a ésta cualquier adaptador real de
red, detectado en el PC donde se encuentra el simulador, crear un enlace virtual
que la conecte con el resto de la topología y finalmente otro físico entre el
simulador y el PC externo.
A continuación se describe el procedimiento en forma más detallada:
1) Hacer clic en la nube y arrastrarla hasta el área de construcción de topologías,
tal como se muestra en la Figura 5.24.
124
Figura 5.24 Ventana principal de GNS3
2) Hacer clic derecho sobre la nube y elegir “configure” para abrir una ventana de
configuración.
Figura 5.25 Selección de la opción Configure.
3) Hacer clic sobre el nombre de la nube, elegir la pestaña “NIO Ethernet” y hacer
clic en la caja que esta inmediatamente debajo de “Generic Ethernet NIO” para
observar todos los adaptadores de red reconocidos por el simulador. Seleccionar
el que se quiere usar para conectar el dispositivo externo y añadirlo a la topología
haciendo clic en “Add”. Finalmente aceptar los cambios con un clic en “OK”. Ver
figura 5.26.
125
Figura 5.26 Selección del adaptador de red
4) En el otro extremo del enlace (extremo externo), se debe configurar la dirección
IP necesaria para la conexión. Si el equipo externo es un PC se requiere
configurar una dirección IP en su adaptador de red que se va a usar. Por otro lado,
si se trata de un router, se debe configurar la dirección IP desde la consola del
equipo en la interfaz que se conectará al simulador. Se debe elegir direcciones IP
que mantengan concordancia con la topología que se va a simular.
5) Realizar una conexión física entre el adaptador de red que ha sido elegido
anteriormente en el simulador y el correspondiente al equipo externo.
6) Crear un enlace virtual, como se explico anteriormente, entre un router virtual y
la nube creada.
5.2.1.4 Almacenamiento de la topología
126
GNS3 permite el almacenamiento de la topología y de la configuración efectuada
en los routers emulados, en archivos diferentes; la topología se guarda en forma
de texto en un archivo .net que es interpretado por Dynagen y mostrado
gráficamente por GNS3, mientras que las configuraciones de los routers emulados
se guardan en archivos .cfg, los cuales al ser abiertos con un editor de texto,
muestran los comandos introducidos en el router de la misma forma que se
pueden encontrar en un router real.
El almacenamiento se realiza de la siguiente forma:
1) Al iniciar el programa GNS3 aparecerá una ventana como la mostrada en la
figura 5.27. En ella se debe habilitar el almacenamiento de las NVRAMs, de los
archivos adicionales (logfiles y bootfiles) y de los archivos de configuración de
todos los routers; además se requiere asignar un nombre al proyecto. Luego se
hace clic en “OK”.
Figura 5.27 Habilitación del almacenamiento.
2) Para completar la habilitación del almacenamiento se debe realizar en los
routers de la topología corriente, el proceso de salvar las configuraciones
realizadas. Para explicar el proceso se toma como ejemplo un router que ha sido
127
arrastrado al área de creación de topologías. Para darle un nombre al router se da
clic derecho sobre el ícono correspondiente y se elige la opción “Change the
hostname”. A continuación se escribe el nuevo nombre del dispositivo y se
selecciona “OK”, en la ventana que se muestra en la Figura 5.28.
Figura 5.28 Ventana para el cambio de nombre de host
3) Para guardar los cambios de configuración realizados en el router se emplea el
comando wr, el cual salva en la NVRAM los datos que se encuentran en la RAM.
En la Figura 5.29 se puede observar los comandos mencionados.
Figura 5.29 Comandos para guardar la configuración de routers
4) Al hacer clic sobre el ícono de la barra principal de GNS3 aparecerá una
ventana como la de la Figura 5.30. Allí se debe elegir “Extracting to a directory”
para guardar los archivos de configuración de todos los routers existentes en la
topología. Luego se hace clic en “Ok”, se busca la ubicación de la carpeta
simulación_config y se acepta el destino.
Figura 5.30 Ventana de almacenamiento configuraciones
128
Cabe resaltar que en la figura 5.30 existe la opción “Importing from a directory” la
cual permite recuperar las configuraciones almacenadas de los routers, así como
también, importar configuraciones de routers de otras topologías a la topología
corriente siempre y cuando ambos routers tengan el mismo Hostname.
6) Seguidamente se puede comprobar que en la carpeta simulación_config se ha
creado un archivo llamado Barcelona.cfg (para el ejemplo), que contiene la
configuración del router. No olvidar escribir el comando wr antes de volver a
extraer la configuración.
7) Para guardar la topología corriente, las conexiones y el escenario se debe dar
clic en “File” y elegir “Save”, tal como se ve en la figura 5.31.
Figura 5.31 Opciones de archivos
129
5.2.2 SIMULACIONES
Durante el desarrollo de este proyecto se simularon los distintos protocolos de
enrutamiento, así como las diversas técnicas de transición para diferentes tipos de
topologías. El objetivo de la simulación en cada caso fue la verificación del
funcionamiento de los protocolos y las estrategias de transición y convivencia, lo
cual se realizó de la siguiente manera:
1. En primera instancia se realizó el diseño de una topología específica para
cada uno de los esceneraios de acuerdo con el tipo de estrategia y de
protocolo que se simulara.
2. Para cada topología se realizó un esquema de direccionamiento y
enrutamiento adecuado para la simulación, usando segmentos IPv4 e IPv6
según la necesidad.
3. En cada caso se configuraron los enrutadores usando los comandos
propios de los sistemas operativos de routers cisco.
4. Posteriormente se verificó la comunicación extremo a extremo por medio
del envío y recepción de mensajes ICMP usando la herramienta PING
(Packet Internet Groper), la cual va a permitir diagnosticar el estado,
velocidad y calidad de una red.
5. Finalmente se realizaron pruebas usando la herramienta TRACERT para
verificar los saltos que realiza cada paquete de un extremo a otro.
Para cada escenario se explica, en los numerales a continuación, el protocolo de
enrutamiento y cada técnica de transición expresando sus características y su
completo funcionamiento, luego se expone la topología de red para su simulación
e implementación a nivel de laboratorio.
A continuación de este proceso se muestra la forma en que debe ser programado
cada componente de red, mostrando paso a paso la configuración necesaria para
130
completar y llevar a cabo el protocolo de enrutamiento o la técnica de transición
que se esté implementando (scripts de configuración).
Como resultado de las simulaciones se constató que todas ellas fueron exitosas,
lo cual significa que al enviar los paquetes ICMP mediante el uso del PING, la
máquina destino envía una confirmación de la recepción de los paquetes con
tiempos de respuesta y porcentajes de pérdida óptimos. Dado que todas las
pruebas fueron similares, los resultados fueron exitosos, y la respuesta (tanto en el
simulador como en el ambiente real) es prácticamente igual en cada caso (con
excepción de las direcciones IP de la máquina origen y de la máquina destino) se
obvió incluir en cada caso la impresión de la pantalla del resultado. No obstante se
presenta a continuación el resultado de una de ellas.
La sintaxis utilizada para el comando Ping es la siguiente:
En Windows: C:\> ping <dirección IP>
En un router Cisco llamado R1: R1# ping <dirección IP>
131
Cuando es exitosa una prueba la cantidad de paquetes enviados es la misma
cantidad que los recibidos. Esta prueba certifica que existe comunicacion entre los
nodos examinados.
En cuanto a las pruebas realizadas con el TRACERT los resultados obtenidos
fueron igualmente exitosos. En cada caso se observaron los saltos realizados por
los paquetes entre los dos extremos. A continuación se muestra el comando
usado y el resultado logrado.
En un router Cisco llamado R1: R1# traceroute <dirección IP >
TRACERT es una herramienta que permite visualizar el número de saltos que
debe realizar un paquete, hasta llegar a su destino final. Cada salto representa un
router por el cual se pasa para acceder al destino final.
132
5.3 ENRUTAMIENTO IPv6
5.3.1 Consideraciones generales
IPv4 e IPv6 son protocolos de la Capa de Red, de manera que ésta es la única
capa directamente afectada por la implementación de IPv6 y por lo tanto no se
tendría necesidad de modificar el funcionamiento de las demás.
Sin embargo, es necesario comprender que se trata de dos Capas de Red
distintas e independientes. Esto implica algunas consideraciones importantes:
Cómo actuar en lo relacionado con la planificación y la estructuración de las
redes:
Migrar toda la estructura a doble pila; migrar solo las áreas críticas;
mantener dos estructuras diferentes, una IPv4 y otra IPv6; etc.
En las redes con doble pila, algunas configuraciones deben ser duplicadas,
como por ejemplo la correspondiente al DNS, al firewall y a los protocolos
de enrutamiento.
Para el soporte y resolución de problemas será necesario determinar si las
fallas se encuentran en la conexión de la red IPv4 o de la red IPv6;
Los nuevos equipos y aplicaciones deben soportar las funcionalidades de los
dos protocolos.
La Capa de Red está asociada principalmente a dos características:
Identificación – Debe garantizar que cada dispositivo de la red sea
identificado de manera unívoca, sin posibilidad de error. En otras palabras, la
133
dirección IP debe ser única a nivel mundial. Utilizando el comando host en las
plataformas UNIX, o nslookup en las plataformas Windows, se puede por
ejemplo, verificar la identificación de un servicio. En las redes con doble pila los
nodos se identifican por las dos direcciones.
Localización – Indica cómo llegar al destino, decidiendo el encaminamiento de
los paquetes con base en el direccionamiento; ocurre de la misma manera
tanto en IPv4 como en IPv6. Podemos verificar esta funcionalidad utilizando
comandos como mtr -4 y -6, o traceroute (traceroute6), o tracert (tracert6).
Estos comandos muestran la identificación y la localización de un nodo.
La unión de estas dos características en la Capa de Red resulta en una semántica
sobrecargada. Esto se evidencia en aspectos tales como la agregación de rutas,
agravando el problema del crecimiento de la tabla de enrutamiento global. Una
forma de impedir esto consiste en separar las funciones de localización e
identificación.
Existe un grupo de trabajo en la IETF que está discutiendo una forma de separar
esas dos funciones (identificación y localización). LISP (Locator/Identifier
Separation Protocol) es un protocolo sencillo que busca separar las direcciones IP
en Endpoint Identifiers (EIDs) y Routing Locators (RLOCs). Esto no exige ningún
cambio en las pilas de los host ni grandes cambios en la infraestructura existente,
pudiendo ser implementado en un número relativamente pequeño de routers.
Sus principales elementos son los siguientes:
Endpoint ID (EID): Un identificador de 32 bits (para IPv4) o 128 bits (para IPv6)
que se utiliza en los campos de dirección de origen y de destino del primer
encabezado (más interno) de un paquete. El host obtiene un EID de destino de
la misma manera en que hoy obtiene una dirección de destino, por ejemplo a
134
través de una consulta de DNS. El EID de origen también se obtiene a través
de los mecanismos ya existentes usados para definir la dirección local de un
host.
Routing Locator (RLOC): Dirección IPv4 o IPv6 de un ETR (Egress Tunnel
Router). Los RLOC se numeran a partir de un bloque topológicamente
agregado y son atribuidos a una red en cada punto en que hay conexión a la
Internet global
Ingress Tunnel Router (ITR): Router de entrada del túnel que recibe un
paquete IP (más precisamente, un paquete IP que no contiene un encabezado
LISP). Este trata la dirección de destino de ese paquete como un EID y realiza
un mapeo entre el EID y el RLOC. A continuación el ITR agrega un
encabezado “IP externa” que contiene uno de sus RLOC globalmente
enrutables en el campo de dirección de origen y un RLOC – resultado del
mapeo – en el campo de dirección de destino.
Egress Tunnel Router (ETR): Router de salida del túnel que recibe un paquete
IP donde la dirección de destino del encabezado, “IP externa”, es uno de sus
RLOC. El router retira el encabezado externo y encamina el paquete con base
en el siguiente encabezado IP encontrado.
La definición del prefijo IP es una definición importante. El recurso que asigna el
Registro.co a los AS es un bloque IP que representa un grupo de direcciones IP.
Un bloque no es un elemento enrutable; lo que es enrutable es el prefijo. Lo que sí
es posible, por ejemplo, es crear un prefijo IPv6 /32 igual al bloque /32 recibido del
Registro.co y anunciar dicho prefijo en la tabla de rutas. Pero a partir del bloque
recibido también se pueden crear prefijos /33, /34, /48 etc.
El prefijo representa el número de bits de una dirección que identifica la red. A
pesar de ser solo una nomenclatura, esta definición es importante a la hora de
135
enviar información para activar sesiones de tránsito con otros operadores y en la
detección de problemas de conectividad.
5.3.2 ¿Cómo funciona el router?
También es importante comprender el funcionamiento básico de un router y saber
de qué manera procesa los paquetes recibidos y toma las decisiones de
encaminamiento. Consideremos el siguiente ejemplo:
El router recibe una trama Ethernet a través de su interfaz de red y verifica la
información del Ethertype que indica que el protocolo de capa superior
transportado es IPv6.
Se procesa el encabezado IPv6 y se analiza la dirección de destino.
El router busca en la tabla de enrutamiento unicast (RIB - Router Information
Base) si existe alguna entrada para la red de destino.
Visualización de la RIB IPv6:
Cisco/Quagga → show ipv6 route
Juniper → show route table inet6
Visualización de la RIB IPv4:
Cisco/Quagga → show ip route
Juniper → show route
Longest Match - Busca la entrada más específica. Ejemplo:
La IP de destino es 2001:0DB8:0010:0010::0010 y el router tiene la
siguiente información en su tabla de rutas:
o 2001:DB8::/32 vía interfaz A
o 2001:DB8::/40 vía interfaz B
o 2001:DB8:10::/48 vía interfaz C
Los tres prefijos engloban la dirección de destino, pero el router siempre
preferirá el más específico, en este caso el /48.
136
Una vez identificado el prefijo más específico, el router decrementa el Hop-
Limit, arma la trama Ethernet de acuerdo con la interfaz y envía el paquete.
Los valores de esta tabla son números enteros comprendidos entre 0 y 255
asociados a cada ruta; cuanto menor es su valor más confiable es la ruta; Los
valores se asignan evaluando si la ruta está conectada directamente, si fue
aprendida a través del protocolo de enrutamiento externo o interno, etc. Estos
valores solo tienen significado local, no pueden ser anunciados por los protocolos
de enrutamiento y, si fuera necesario, pueden ser modificados para priorizar un
determinado protocolo.
En caso que en la tabla de preferencias también se encuentre el mismo valor, hay
equipos e implementaciones que por defecto realizan el balanceo de carga.
5.3.3 Tabla de enrutamiento
El proceso de selección de rutas es idéntico en IPv4 e IPv6, pero las tablas de
rutas son independientes. Por lo tanto existe una RIB (Router Information Base)
para IPv4 y otra para IPv6.
Para optimizar el envío de paquetes hay mecanismos que agregan solo las
mejoras rutas a otra tabla, la tabla de encaminamiento (FIB - Forwarding
Information Base). Un ejemplo de este mecanismo es el CEF (Cisco Express
Forwarding) de Cisco.
La FIB se crea a partir de la RIB y al igual que la RIB también está duplicada si la
red está configurada con doble pila. Es así que hay más información para
almacenar y procesar. En los routers que tienen arquitectura distribuida el proceso
de selección de rutas y el encaminamiento de los paquetes son funciones
diferentes.
137
Ejemplo:
Routers 7600 de Cisco: La RIB reside en el módulo de enrutamiento central y
la FIB en las placas de las interfaces.
Routers Juniper de la serie M: El Router Engine es responsable por la RIB,
mientras que la FIB también reside en las placas de las interfaces (Packet
Forwarding Engine - PFE).
El mecanismo de enrutamiento es el que permite el encaminamiento de paquetes
de datos entre dos dispositivos cualquiera conectados a Internet.
Para actualizar la información que utilizan los routers para encontrar el mejor
camino disponible en el encaminamiento de los paquetes hasta su destino, se
utilizan los protocolos de enrutamiento. Son las informaciones recibidas por los
protocolos de enrutamiento las que "alimentan" la RIB, la cual a su vez "alimenta
la FIB.
Estos protocolos se dividen en dos grupos:
Protocolos de Gateway Interno (IGP: Interior Gateway Protocol) - Protocolos
que distribuyen la información de los routers dentro de los Sistemas Autónomos.
Dentro de estos protocolos se puede mencionar como ejemplo: OSPF, IS-IS y
RIP.
Protocolos de Gateway Externo (EGP: Exterior Gateway Protocol) -
Protocolos que distribuyen la información entre Sistemas Autónomos. Como
ejemplo se puede mencionar el protocolo BGP-4.
Si el router recibe un paquete cuya dirección de destino no esté explícitamente
listada en la tabla de rutas, éste utilizará su ruta por defecto.
138
Naturalmente, los servidores y estaciones de trabajo necesitan una ruta por
defecto. Estos dispositivos no son equipos de red; solo conocen las redes
directamente conectadas a sus interfaces. Para llegar a un destino que no esté
directamente conectado deberán usar la ruta por defecto.
5.3.4 Ruta por defecto
Entre los operadores existe un concepto que delimita una región de Internet sin
ruta por defecto, la DFZ (Default Free Zone).
Un AS (Sistema Autónomo) que tiene la tabla completa no necesita tener ruta por
defecto, ya que la tabla completa muestra las entradas de red de todo el mundo.
Este modelo es bueno y funcional, pero puede acarrear algunos problemas. Los
routers deben procesar información del mundo entero en tiempo real; también
pueden surgir problemas de escalabilidad futura.
El uso de una ruta por defecto por parte de los routers que tienen tabla completa
puede ocasionar algunos problemas.
Como ejemplo, imagine la siguiente situación: una red ha sido comprometida por
un malware. La máquina contaminada “barrerá” Internet intentando contaminar
otras máquinas, incluso IPs que no están asignadas y que no están en la tabla
completa; Si hay ruta por defecto, su router va a encaminar ese tráfico no válido
hacia adelante; Este es uno de los motivos para utilizar DFZ. Una sugerencia para
solucionar este problema es crear una ruta por defecto y apuntar hacia Null0 o
DevNull. También hay que deshabilitar el envío de mensajes 'ICMP unreachable':
ya que cuando un router descarta un paquete envía un mensaje 'ICMP
unreachable' pero si el destino no es válido no es necesario avisar al origen, esto
solo consumirá CPU innecesariamente.
139
La ruta por defecto en IPv4 es 0.0.0.0/0 y en IPv6 es ::/0.
5.3.5 Enrutamiento Estático
El enrutamiento estático parte de una configuración manual realizada por el
administrador, siendo éste el que decide cuál va a ser la ruta más adecuada para
los paquetes de datos de acuerdo con la topología y con las características de la
red. Esta ruta va a permanecer inalterable durante el proceso de enrutamiento
hasta que el administrador la vuelva a cambiar de una manera manual.
Generalmente se utiliza este tipo de enrutamiento cuando se tiene un alto
conocimiento de la red y cuando la misma no es muy compleja.
El administrador de la red debe llenar manualmente la tabla de enrutamiento del
enrutador, siendo ésta la base del enrutamiento estático. Hay que destacar que si
hay cambios en la red, es el administrador quien debe hacer los cambios en las
rutas, ya que en este caso los enrutadores no toman decisiones, también hay que
destacar que mientras más grande y compleja sea la red, más tiempo de
administración va a requerir.
5.3.5.1 Configuración de enrutamiento estático IPv6
Antes de configurar el router con una ruta IPv6 estática es necesario habilitar el
reenvió de paquetes IPv6 utilizando el comando IPv6 unicast-routing en el router
desde la configuración global.
Router> enable
Router# Conmfigure terminal
Router(config)# ipv6 unicast-routing
140
Existen diferentes formas de configurar una ruta estática, entre las cuales se
encuentran:
- Rutas estáticas directamente conectadas
En las rutas directamente conectadas, solo se especifica la interfaz de salida. El
destino se supone que es conectado directamente a esta interfaz, por lo que el
destino del paquete se utiliza como la dirección del siguiente salto.
Ejemplo:
Ipv6 route 2001:db8::/32 ethernet1/0
En el ejemplo se especifica que todos los destinos con prefijo de la dirección
2001:db8::/32 son directamente accesibles a través de la interfaz Ethernet 1/0.
- Rutas estáticas recursivas
En la ruta estática recursiva, solo se especifica el siguiente salto. La interfaz de
salida se deriva del siguiente salto.
Ejemplo:
Ipv6 route 2001:db8::/32 2001:db8:3000:1
Este ejemplo especifica que todos los destinos con prefijo 2001:DB8::/32 son
accesibles a través del host con dirección 200:DB8:3000:1. Una ruta estática
recursiva es válida sólo cuando se resuelve el siguiente salto especificado, ya sea
directa o indirectamente, a una interfaz de salida de IPv6 válida, siempre que la
ruta no se auto-redirija.
- Rutas estáticas completamente especificadas
141
En una ruta estática completamente especificada, se define tanto la interfaz de
salida como el siguiente salto. Esta forma de ruta estática se utiliza cuando la
interfaz es un acceso multi-uno y es necesario identificar explícitamente el
siguiente salto. El siguiente salto debe estar directamente conectado a la interfaz
de salida especificada.
Ejemplo:
Ipv6 route 2001:db8::/32 ethernet 1/0 2001:db8:3000::1
- Rutas estáticas flotantes
Son rutas estáticas que se utilizan para copias de seguridad de las rutas
dinámicas a través de los protocolos de enrutamiento. Una ruta estática flotante se
configura con una mayor distancia administrativa que el enrutamiento dinámico.
Como resultado, las rutas dinámicas aprendidas a través del protocolo de
enrutamiento siempre tienen preferencia. Por lo tanto las rutas flotantes son
utilizadas únicamente cuando las rutas dinámicas se pierdan.
Ejemplo:
Ipv6 route 2001:db8:/32 ethernet 1/0 2001:db8:3000:1 210
Topología básica para Enrutamiento Estático
En la Figura 5.32 se presenta la topología propuesta para la simulación de este
esrutamiento y a continuación se describe la configuración de cada router.
142
Figura 5.32 Enrutamiento estático IPv4 – Ipv6
ENRUTAMIENTO ESTATICO IPV4 - IPV6
ROUTER 1
Router>enable !Ingresa al modo EXEC Privilegiado
Router#configure terminal !Configura la terminal
manualmente desde la
terminal de consola
Router(config)#ipv6 unicast-routing !Habilita el
ruteo para IPv6
Router(config)#interface fastethernet0/0 !Entra al modo de
configuración de
la interfaz
143
Router(config-if)#ip address 10.9.0.1 255.255.0.0 !Asigna una
dirección y una
mascara de sub-
red IPv4
Router(config-if)#ipv6 enable !Habilita IPv6 en la
interfaz y genera
automaticamente la
direccion link-local con
EUI-64
Router(config-if)#ipv6 address 2001:db8:1::1/64 !Asigna una
dirección IPv6 a
la interfaz.
Router(config-if)#no shutdown !Inicia la interfaz
desactivada
Router(config-if)#exit !Regresa al modo anterior
Router(config)#interface fastethernet0/1 !Entra al modo de
configuración de
la interfaz
Router(config-if)#ip address 10.10.0.1 255.255.0.0 !Asigna
una dirección y
una mascara de
sub-red IPv4
Router(config-if)#ipv6 enable !Habilita IPv6 en la
interfaz y genera
144
automaticamnte la
direccion link-local
con EUI-64
Router(config-if)#ipv6 address 2001:db8:2::1/64 !Asigna una
dirección IPv6 a
la interfaz
Router(config-if)#no shutdown !Inicia la interfaz
desactivada
Router(config-if)#exit !Regresa al modo anterior
Router(config)#ip route 10.11.0.0 255.255.0.0 10.10.0.2
!Se configura la
ruta y el
siguiente salto
Router(config)#ip route 10.12.0.0 255.255.0.0 10.10.0.2
Router(config)#ipv6 route 2001:db8:3::/64 2001:db8:2::2
!Se configura la
ruta y el
siguiente salto
Router(config)#ipv6 route 2001:db8:4::/64 2001:db8:2::2
!Se configura la
ruta y el
siguiente salto
145
ROUTER 2
Router>enable
Router#configure terminal
Router(config)#ipv6 unicast-routing
Router(config)#interface fastethernet0/0
Router(config-if)#ip address 10.10.0.2 255.255.0.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 address 2001:db8:2::2/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface fastethernet0/1
Router(config-if)#ip address 10.11.0.1 255.255.0.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 address 2001:db8:3::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#ip route 10.9.0.0 255.255.0.0 10.10.0.1
Router(config)#ip route 10.12.0.0 255.255.0.0 10.11.0.2
Router(config)#ipv6 route 2001:db8:1::/64 2001:db8:2::1
Router(config)#ipv6 route 2001:db8:4::/64 2001:db8:3::2
ROUTER 3
146
Router>enable
Router#configure terminal
Router(config)#ipv6 unicast-routing
Router(config)#interface fastethernet0/0
Router(config-if)#ip address 10.12.0.1 255.255.0.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 address 2001:db8:4::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface fastethernet0/1
Router(config-if)#ip address 10.11.0.2 255.255.0.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 address 2001:db8:3::2/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#ip route 10.9.0.0 255.255.0.0 10.11.0.1
Router(config)#ip route 10.10.0.0 255.255.0.0 10.11.0.1
Router(config)#ipv6 route 2001:db8:1::/64 2001:db8:3::1
Router(config)#ipv6 route 2001:db8:4::/64 2001:db8:3::1
Para la verificación de las rutas estáticas y su operación se utiliza el siguiente
comando:
Router# show ipv6 static
147
5.3.6 Protocolos de Enrutamiento Interno
Hoy en día hay dos opciones principales para trabajar con enrutamiento interno,
OSPF (Open Shortest Path First) e IS-IS (Intermediate System To Intermediate
System). Estos dos protocolos son de tipo Link-State, es decir, consideran la
información de estado del enlace y envían actualizaciones en forma optimizada
solo cuando se producen cambios de estado en los enlaces. También permiten
trabajar con estructura jerárquica separando la red por regiones. Esto es un punto
fundamental para IPv6.
Otra opción es el protocolo RIP (Routing Information Protocol). Éste es un
protocolo de tipo Vector de Distancia (Bellman-Ford), de fácil implementación y de
funcionamiento sencillo, pero presenta algunas limitaciones como el hecho de
enviar su tabla de estados periódicamente sin importar si hay o no cambios en la
red.
Es importante que el protocolo de enrutamiento interno se habilite solamente en
las interfaces donde sea necesario. Aunque parezca obvio, hay quienes lo
configuran equivocadamente haciendo que los routers queden intentando
establecer relaciones de vecindad con otros AS (Autonomous System).
5.3.7 RIPng
Para tratar el enrutamiento interno IPv6 se definió una nueva versión del protocolo
RIP, el Routing Information Protocol next generation (RIPng). Esta versión se basa
en el protocolo RIPv2 que se utiliza en las redes IPv4, pero es específica para
redes IPv6.
Entre los principales cambios se destacan los siguientes:
• Soporte para el nuevo formato de direcciones;
• Utiliza la dirección multicast FF02::9 (All RIP Routers) como destino;
148
• La dirección del salto siguiente debe ser una dirección link local.
En un ambiente con doble pila (IPv4+IPv6) es necesario utilizar una instancia de
RIP para IPv4 y una de RIPng para el enrutamiento IPv6.
A pesar de ser nuevo, el protocolo RIPng todavía tiene las mismas limitaciones
que las versiones anteriores utilizadas con IPv4, entre ellas:
• El diámetro máximo de la red es de 15 saltos;
• Para determinar el mejor camino utiliza solamente la distancia;
• Loops de enrutamiento y conteo al infinito.
La tabla de rutas contiene la siguiente información:
• Prefijo de destino
• Métrica
• Siguiente salto
• Identificación de la ruta (route tag)
• Cambio de ruta
• Tiempo hasta que la ruta expira (por defecto 180 segundos)
• Tiempo hasta el garbage collection (por defecto 120 segundos)
Las tablas de rutas se pueden actualizar de tres maneras diferentes: a través del
envío automático de datos cada 30 segundos, cuando se detecta algún cambio en
la topología de la red enviando solo la línea afectada por el cambio y cuando se
recibe un mensaje de tipo Request (solicitud).
El encabezado de los mensajes RIPng es muy sencillo (Ver Figura 5.33) y está
formado por los siguientes campos:
149
Figura 5.33 Cabecera RIPng
Fuente: h2c.com
• Comando (command) – Indica si el mensaje es de tipo Request o Response;
• Versión (version) – Indica la versión del protocolo que actualmente es 1.
Estos campos van seguidos por las entradas de la tabla de rutas (Route Table
Entry – RTE) que contienen la siguiente información:
• Prefijo IPv6 (128 bits);
• Identificación de la ruta (16 bits);
• Tamaño del prefijo (8 bits);
• Métrica (8 bits).
A diferencia de lo que ocurre en RIPv2, la dirección del siguiente salto aparece
solo una vez, seguida por todas las entradas que deben utilizarla.
5.3.7.1 Configuración RIPng
Antes de configurar el router para ejecutar RIP IPv6, es necesario habilitar el
enrutamiento IPv6 con el comando ipv6 unicast-routing en el modo de
150
configuración global y habilitar el proceso en cada router como se muestra a
continuación:
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# ipv6 router rip nombredeproceso
Para permitir un proceso de enrutamiento RIP IPv6 en una interfaz es necesario
introducir el siguiente comando en la interfaz donde será habilitado el proceso:
Router(config-if)# ipv6 rip nombredeproceso enable
Donde Proceso puede ser cualquier nombre que se le quiera dar. En la figura 5.34
se muestra la topología propuesta para la simulación del enrutameinto con el
protocolo RIP. A continuación se incluye la correspondiente configuración de cada
router.
Figura: 5.34 RIPng
151
CONFIGURACION RIPng
ROUTER 1
Router>enable
Router#configure terminal
Router(config)#ipv6 unicast-routing
Router(config)#ipv6 router rip RIC
Router(config-rtr)#exit
Router(config)#interface fastethernet0/0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:1:1:1::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface serial1/0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:4:4:4::1/64
Router(config-if)#clock rate 64000
Router(config-if)#no shutdown
Router(config-if)#exit
152
ROUTER 2
Router>enable
Router#configure terminal
Router(config)#ipv6 unicast-routing
Router(config)#ipv6 router rip RIC
Router(config)#exit
Router(config)#interface fastethernet0/0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:300:300:300::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface serial1/0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:4:4:4::2/64
Router(config-if)#clock rate 64000
Router(config-if)#no shutdown
Router(config-if)#exit
Para verificar la configuración y operación de RIP para IPv6, se utilizan los
siguientes comandos:
Para ver la información sobre los actuales procesos de RIP IPv6:
153
Router#show ipv6 rip nombredeproceso database
Para mostrar el contenido actual de la tabla de enrutamiento:
Router#show ipv6 route rip
5.3.8 OSPFv3 (Open Shortest Path First Version 3)
OSPF es un protocolo de tipo link-state mediante el cual, a través del proceso de
flooding (inundación), los routers envían anuncios de estado del enlace (LSA: Link
State Advertisements) describiendo su estado actual a lo largo del AS (Sistema
Autónomo). El flooding consiste en el envío de un LSA por todas las interfaces de
salida del router, de modo que todos los routers que reciben un LSA también lo
envían por todas sus interfaces. De este modo, el conjunto de los LSAs de todos
los routers forma una base de datos del estado de los enlaces. Cada router que
participa del AS tiene una base de datos idéntica. Con la información de esta base
de datos, el router, a través del protocolo OSPF, construye un mapa de la red que
será utilizado para determinar un árbol de caminos más cortos dentro de toda la
subred, teniendo al propio nodo como raíz. Utiliza el algoritmo de Dijkstra para
escoger el mejor camino y permite agrupar los routers en áreas.
OSPF se puede configurar para trabajar de forma jerárquica, dividiendo los routers
de un AS en diferentes áreas (ver Figura 5.35). A cada una de estas áreas se
atribuye un identificador único (Área-ID) de 32 bits y todos los routers de una
misma área mantienen una base de datos de estado separada, de modo que la
topología de un área se desconoce fuera de la misma, reduciendo así la cantidad
de tráfico de enrutamiento entre las partes del AS. El área backbone es la
responsable de distribuir la información de enrutamiento entre las áreas
nonbackbone y se identifica mediante el ID 0 (ó 0.0.0.0). En los AS en los cuales
no hay esta división, generalmente el área backbone es la única que se configura.
154
A pesar de que está basado en la versión de OSPFv2 que se utiliza en las redes
IPv4, OSPFv3 es un protocolo específico para IPv6. Por lo tanto, en las redes con
doble pila es necesario utilizar OSPFv2 para realizar el enrutamiento IPv4 y
OSPFv3 para realizar el enrutamiento IPv6.
Figura 5.35 Diagrama OPSFv3
Fuente: ipv6.br
Los routers OSPF se pueden clasificar de la siguiente manera:
• Internal Router (IR) – Routers que solo se relacionan con vecinos OSPF de una
misma área.
• Area Border Router (ABR) – Routers que conectan una o más áreas al
backbone. Estos poseen múltiples copias de las bases de datos de estado, una
para cada área y son responsables de condensar la información de estas áreas y
enviarla al backbone.
• Backbone Router (BR) – Routers que pertenecen al área backbone. Un ABR es
siempre un BR, ya que todas sus áreas están directamente conectadas al
155
backbone o conectadas vía un virtual link - túnel que conecta un área al backbone
pasando a través de otra área
• Autonomous System Border Router (ASBR) – Routers que intercambian
información de enrutamiento con routers de otro AS y distribuyen las rutas
recibidas dentro su propio AS.
OSPFv3 todavía incluye algunas características de OSPFv2 como las siguientes:
• Tipos básicos de paquetes: Hello, DBD, LSR, LSU, LSA.
• Mecanismos para descubrimiento de vecinos y formación de adyacencias .
• Tipos de interfaces: point-to-point, broadcast, NBMA, point-to-multipoint y
enlaces virtuales.
• Lista de estados y eventos de las interfaces.
• Algoritmo de selección del Designated Router y del Backup Designated Router.
• Envío y edad de las LSAs.
• AREA_ID y ROUTER_ID continúan siendo de 32 bits.
Entre las principales diferencias entre OSPFv2 y OSPFv3 se destacan las
siguientes:
• OSPFv3 funciona por enlace y no por subred.
• Se eliminó la información de direccionamiento
• Se agregó limitación de alcance para flooding
• Soporte explícito para múltiples instancias en cada enlace
• Uso de direcciones link-local
• Cambios en la autenticación
• Cambios en el formato del paquete
• Cambios en el formato del encabezado LSA
• Tratamiento de tipos de LSA desconocidos
156
• Soporte para áreas Stub/NSSA
• Identificación de vecinos mediante Router IDs
• Utiliza direcciones multicast (AllSPFRouters FF02::5 y AllDRouters FF02::6)
5.3.8.1 Configuración OSPFV3
Antes de empezar a configurar OSPFv3 es necesario:
Planificar y crear una estrategia de red para OSPFv3, definiendo la cantidad de
áreas y backbone.
Habilitar ipv6 unicast-routing
Habilitar IPv6 en cada interfaz
Figura 5.36 Topología para la simulación de OSPFv3
La figura 5.36 muestra la topología usada para la simulación del enrutamiento
utilizando el protocolo OSPFv3.
157
El primer paso en la configuración básica es permitir el enrutamiento IPv6 unicast:
R1(config)# ipv6 unicast-routing
R1(config)# ipv6 cef
R2(config)# ipv6 unicast-routing
R2(config)# ipv6 cef
R3(config)# ipv6 unicast-routing
R3(config)# ipv6 cef
A continuación se debe asignar direcciones IPv6 a las interfaces necesarias en
cada router.
R1(config-if)# interface serial 1/1
R1(config-if)# ipv6 address FEC0::13:1/112
R1(config-if)# no shutdown
R1(config)# interface serial 1/0
R1(config-if)# ipv6 address FEC0::12:1/112
R1(config-if)# clockrate 64000
R1(config-if)# no shutdown
R2(config)# interface serial 1/0
R2(config-if)# ipv6 address FEC0::12:2/112
R2(config-if)# no shutdown
R2(config)# interface serial 1/1
R2(config-if)# ipv6 address FEC0::23:2/112
R2(config-if)# no shutdown
R3(config)# interface serial 1/0
158
R3(config-if)# ipv6 address FEC0::13:3/112
R3(config-if)# clockrate 64000
R3(config-if)# no shutdown
R3(config)# interface serial 1/1
R3(config-if)# ipv6 address FEC0::23:3/112
R3(config-if)# clockrate 64000
R3(config-if)# no shutdown
Se deben crear las interfaces loopback necesarias, pues éstas simularán una red
conectada directamente.
R1(config)# interface loopback0
R1(config-if)# ipv6 address FEC0::1:1/112
R2(config)# interface loopback0
R2(config-if)# ipv6 address FEC0::2:1/112
R3(config)# interface loopback0
R3(config-if)# ipv6 address FEC0::3:1/112
Aunque OSPFv3 utiliza exclusivamente direcciones IPv6, todavía utiliza 32 bits
para el ID del proceso para el router. Puesto que no existe ninguna dirección IPv4
en las interfaces, se definirá manualmente el ID del router.
R1(config)# ipv6 router ospf 1
R1(config-rtr)# router id 1.1.1.1
R2(config)# ipv6 router ospf 1
R2(config-rtr)# router id 2.2.2.2
159
R3(config)# ipv6 router ospf 1
R3(config-rtr)# router id 3.3.3.3
A continuación se debe asignar las interfaces a las áreas de OSPF.
R1(config)# interface loopback0
R1(config-if)# ipv6 ospf 1 area 1
R1(config-if)# interface serial0/0
R1(config-if)# ipv6 ospf 1 area 4
R1(config-if)# interface serial0/1
R1(config-if)# ipv6 ospf 1 area 4
R2(config)# interface loopback0
R2(config-if)# ipv6 ospf 1 area 2
R2(config-if)# interface serial0/0
R2(config-if)# ipv6 ospf 1 area 4
R2(config-if)# interface fastEthernet 0/0
R2(config-if)# ipv6 ospf 1 area 4
R3(config)# interface loopback0
R3(config-if)# ipv6 ospf 1 area 3
R3(config-if)# interface serial0/0
R3(config-if)# ipv6 ospf 1 area 4
R3(config-if)# interface fastEthernet 0/0
R3(config-if)# ipv6 ospf 1 area 4
160
Si todo está configurado correctamente, todos los routers deben tener
accesibilidad completa a través de IPv6. Se puede inspeccionar la información de
cada vecino con el siguiente comando:
Router# ipv6 show ospf neighbor
Del mismo modo, se puede inspeccionar la tabla de enrutamiento IPv6 para
verificar que se han recibido todas las rutas OSPF:
Router# route show ipv6
Para mostrar la información de enrutamiento OSPF en cada interface se usa el
siguiente comando:
Router# show ipv6 ospf interface
Por último para obtener la información general sobre el proceso de enrutamiento
OPSFv3 se utiliza:
Router# show ipv6 ospf
5.3.9 IS-IS (Intermediate System to Intermediate System)
Al igual que OSFP, Intermediate System to Intermediate System (IS-IS) es un
protocolo IGP de tipo link-state, que utiliza el algoritmo de Dijkistra para calcular
las rutas.
IS-IS fue originalmente desarrollado para funcionar sobre protocolos CLNS
(Servicio No Orientado a Conexión), pero la versión Integrated IS-IS permite
enrutar tanto paquetes de red IP como OSI. Para ello se utiliza un identificador de
protocolo, el NLPID (Network Level Protocol ID) para informar qué protocolo de
red está siendo utilizado.
161
Al igual que OSPF, IS-IS también permite trabajar la red de manera jerárquica,
actuando con los routers en dos niveles, L1 (Stub) y L2 (Backbone), además de
los routers que integran esas áreas, L2/L1.
Para tratar el enrutamiento IPv6 no se definió una nueva versión del IS-IS sino que
solo se agregaron nuevas funcionalidades a la versión ya existente.
Se agregaron dos nuevas TLVs (Type-Length-Values):
• IPv6 Reachability (type 236) – Transporta información de las redes accesibles
• IPv6 Interface Address (type 232) – Indica las direcciones IP de la interfaz que
está transmitiendo el paquete.
También se agregó un nuevo identificador de la capa de red.
• IPv6 NLPID – Su valor es 142.
El proceso de establecimiento de vecindades no cambia.
5.3.10 Protocolo de enrutamiento externo
En la actualidad el protocolo de enrutamiento externo por defecto es Border
Gateway Protocol versión 4 (BGP-4). Se trata de un protocolo de tipo path vector,
en el cual los routers BGP intercambian información de enrutamiento entre AS ’s
vecinos diseñando un grafico de conectividad entre los mismos.
162
5.3.11 BGP (Border Gateway Protocol)
BGP es un protocolo extremamente simple basado en sesiones TCP escuchando
en el puerto 179. Para intercambiar información y mantener el estado de la
conexión TCP se utilizan cuatro tipos de mensajes BGP:
Open – Enviado por los dos vecinos luego del establecimiento de la conexión
TCP. Lleva la información necesaria para el establecimiento de la sesión BGP
(ASN, versión de BGP, etc.)
Update – Usado para transferir la información de enrutamiento entre los
vecinos BGP, la cual se utilizará para construir el grafo que describe la relación
entre varios ASs
Keepalive – Se envían frecuentemente para evitar que la conexión TCP expire;
Notification – Se envía cuando se detecta un error, cerrando la conexión BGP
inmediatamente después de su envío.
Se puede establecer dos tipos de conexión BGP (ver Figura 5.37):
externa (eBGP) – conexión entre dos AS vecinos;
interna (iBGP) – conexión entre routers dentro de un mismo AS. Establecer el
iBGP es muy importante para mantener una visión consistente de las rutas
externas en todos los routers de un AS.
163
Figura 5.37 Ejemplo de topología BGP
Fuente: ipv6.br
El funcionamiento de BGP se puede representar mediante una Máquina de
Estados Finitos. Para quienes no están familiarizados con el protocolo BGP, al
verificarse que el estado de una conexión está “Active” o “Established”, se puede
tener la falsa impresión de que la conexión está “activa” o “establecida”, pero en
general, en BGP, cuando hay “palabras” representando el estado, significa que la
sesión BGP todavía no está bien. La sesión estará efectivamente establecida
cuando se observe el número de prefijos que se está recibiendo del vecino. Esos
nombres representan estados intermedios de la sesión BGP. Identificar esos
estados ayuda en el análisis y resolución de problemas.
A pesar de que la RFC sobre BGP recomienda algunos puntos, el criterio de
selección entre diferentes atributos BGP puede variar de implementación a
implementación. Sin embargo, la mayor parte de las implementaciones sigue los
mismos estándares.
Los atributos BGP se pueden dividir en dos grandes categorías:
164
• Bien conocidos (Well-known) – Son atributos definidos en la especificación
original del protocolo BGP. Estos se subdividen en otras dos categorías:
– Obligatorios (Mandatory) – Siempre deben estar presentes en los
mensajes tipo UPDATE y deben ser obligatoriamente reconocidos por todas
las implementaciones del protocolo
– Discrecional (Discretionary) – No deben obligatoriamente estar presentes
en todos los mensajes UPDATE.
• Opcionales (Optional) – No son obligatoriamente soportados por todas las
implementaciones de BGP. Estos se subdividen en otras dos categorías:
– Transitivos (Transitive) – Deben ser retransmitidos en los mensajes
UPDATE
– No Transitivos (Non-transitive) – No deben ser retransmitidos.
La RFC sobre BGP contiene los siguientes atributos:
• ORIGIN – Es bien conocido y obligatorio, Indica si el camino fue aprendido vía
IGP o EGP
• AS_PATH - Es bien conocido y obligatorio. Indica el camino para llegar a un
destino, listando los ASN por los cuales se debe pasar
• NEXT_HOP – Es bien conocido y obligatorio. Indica la dirección IP de la interfaz
del siguiente router
• MULTI_EXIT_DISC – Es opcional y no transitivo. Indica a los vecinos BGP
externos cuál es el mejor camino para una determinada ruta del propio AS,
165
influenciándolos, así como cuál camino se debe seguir en caso de que el AS
posea diferentes puntos de entrada.
• LOCAL_PREF – Es bien conocido y discrecional. Indica un camino de salida
preferencial para una determinada ruta destinada a una red externa al AS.
• ATOMIC_AGGREGATE – Es bien conocido y discrecional. Indica si caminos
más específicos se agregaron en menos específicos.
• AGGREGATOR - Es opcional y transitivo. Indica el ASN del último router que
formó una ruta agregada, seguido por su propio ASN y dirección IP.
Al decidir la mejor ruta, los atributos se consideran si se conoce el camino, si hay
conectividad, si es accesible o si está disponible el next hop (siguiente salto). Pero
la forma de selección puede variar dependiendo de la implementación.
Un atributo que vale la pena destacar es el atributo LOCAL_PREFERENCE. Éste
es un atributo extremadamente poderoso para influenciar el tráfico de salida. Su
valor es válido para todo el AS, siendo retransmitido solamente en las sesiones
iBGP.
5.3.11.1 BGP Multiprotocolo
Se definieron extensiones para BGP-4 con la intención de habilitarlo para que
transporte información de enrutamiento de múltiples protocolos de Capa de Red
tales como IPv6, IPX, L3VPN, etc. Para realizar el enrutamiento externo IPv6, es
fundamental el soporte para MP-BGP, ya que no existe una versión específica de
BGP para tratar esta tarea.
166
Para que BGP pueda trabajar con la información de enrutamiento de diversos
protocolos se introdujeron dos nuevos atributos:
• Multiprotocol Reachable NLRI (MP_REACH_NLRI): Transporta el conjunto de
destinos alcanzables junto con la información del next-hop
• Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI): Transporta el conjunto
de destinos inalcanzables.
Estos atributos son opcionales y no transitivos; en caso que un router BGP no
soporte MBGP, debe ignorar esta información y no transferirla a sus vecinos.
Estos atributos llevan la siguiente información:
MP_REACH_NLRI
• Address Family Identifier (2 bytes) – Identifica el protocolo de red a ser
soportado
• Subsequent Address Family Identifier (1 byte) – Identifica el protocolo de
red a ser soportado
• Length of Next Hop Network Address (1 byte) – Valor que expresa la
longitud del campo Network Address of Next Hop, medida en bytes
• Network Address of Next Hop (variable) – Contiene la dirección del
siguiente salto
• Reserved (1 byte) – Reservado
• Network Layer Reachability Information (variable) – Lista la información de
las rutas accesibles.
MP_UNREACH_NLRI
• Address Family Identifier (2 bytes) – Identifica el protocolo de red a ser
soportado
167
• Subsequent Address Family Identifier (1 byte) – Identifica el protocolo de
red a ser soportado
• Withdrawn Routes (variable) – Lista la información de las rutas
inaccesibles.
5.3.11.2 Tabla BGP
La información sobre las rutas de Internet se encuentra en la tabla BGP. En los
routers de borde, los cuales se ocupan de la comunicación entre ASs. Esta
información se replica hacia la RIB y la FIB, IPv4 e IPv6.
La tabla global IPv4 hoy tiene aproximadamente 300.000 entradas. La tabla IPv6
tiene aproximadamente 2.500 entradas. La duplicidad de esta información en las
arquitecturas distribuidas implica la necesidad de contar con más espacio para
almacenamiento, más memoria y más capacidad de procesamiento, tanto en el
módulo central como en las placas de las interfaces.
Esto también implica otro aspecto importante, la necesidad de establecer un plan
de direccionamiento jerárquico para minimizar la tabla de rutas y optimizar el
enrutamiento, evitando el anuncio de rutas innecesarias y desagregadas.
Los AS también pueden controlar los anuncios que reciben de sus vecinos BGP.
Por ejemplo, es posible limitar el tamaño de los prefijos recibidos entre /20 y /24
IPv4, y entre /32 y /48 IPv6.
Sin embargo, se pueden anunciar hasta 31 prefijos IPv4 (considerando anuncios
entre un /20 y un /24) y 131.071 prefijos IPv6 (considerando anuncios entre un /32
y un /48), de este modo hay quienes también controlan la cantidad de prefijos que
reciben de sus vecinos BGP a través de comandos como maximum-prefix (Cisco)
168
y maximumprefixes (Juniper). Prestar atención a este tema es muy importante en
las redes IPv4, pero en las redes IPv6 es fundamental.
5.3.11.3 Configuración BGP
BGP utiliza un ID (Identificador) para cada router BGP, permitiendo identificar a
sus vecinos. El ID de cada router BGP tiene un valor de 32-bits que a menudo es
representado por una dirección IPv4. Por defecto, el software IOS de Cisco
establece el ID de router igual a la dirección IPv4 de la interfaz loopback en el
router. Si no hay interfaz de bucle configurado en el router, el software elige la
dirección IPv4 más alta configurada para una interfaz física del router. Al
configurar BGP en un router que sólo está habilitado para IPv6 (el router no tiene
una dirección IPv4), es necesario configurar manualmente el ID de router BGP. El
ID de router BGP utiliza una sintaxis de la dirección IPv4 este debe ser único en el
BGP del router.
Para configurar un proceso de enrutamiento BGP y entrar en modo de
configuración del router se utiliza el siguiente comando en el modo de
congiguración global:
Router(config)# router bgp numerodeproceso
Después es necesario desactivar las direcciones IPv4 para el proceso de
enrutamiento BGP definido en el paso anterior.
Router(config-router)#no bgp default ipv4-unicast
Para definir el ID del router se utiliza:
Router(config-router)#bgp router-id direccion32bits
169
Por defecto, los vecinos que se definen mediante el comando remote-as solo
pueden ser prefijos IPv4. Para el intercambio de otros tipos de prefijos como los
prefijos IPv6, los vecinos deben ser activados en el modo de configuración
address-family ipv6, como se muestra a continuación.
Router(config-router)# neighbor direccionipv6 remote-as procesobgp
Router(config-router)# address-family ipv6
Router(config-router-af)# neighbor direccionipv6 activate
Figura 5.38: BGP Multiprotocolo
En la Figura 5.38 puede verse la topología empleada para la simulación del
enrutamiento con el protocolo BGP. A continuación se relacionan las
configuraciones realizadas en cada router.
Router 1
R1#ipv6 unicast-routing
170
R1#ipv6 cef
R1(config)#interface Loopback0
R1(config-if)# ipv6 address FEC0::1:1/112
R1(config-if)# ipv6 ospf 1 area 0
R1(config)#interface Serial1/0
R1(config-if)# ipv6 enable
R1(config-if)# ipv6 address FEC0::12:1/112
R1(config-if)# ipv6 ospf 1 area 0
R1(config-if)# clock rate 64000
R1(config-if)# no shutdown
R1(config)#interface Serial1/1
R1(config-if)# ipv6 enable
R1(config-if)# ipv6 address FEC0::13:1/112
R1(config-if)# ipv6 ospf 1 area 0
R1(config-if)# no shutdown
R1(config)#router bgp 1
R1(config-router)# bgp router-id 1.1.1.1
R1(config-router)# bgp log-neighbor-changes
R1(config-router)# neighbor FEC0::2:1 remote-as 1
R1(config-router)# neighbor FEC0::2:1 update-source Loopback0
R1(config-router)# neighbor FEC0::3:1 remote-as 1
R1(config-router)# neighbor FEC0::3:1 update-source Loopback0
R1(config-router)# address-family ipv6
R1(config-router)# neighbor FEC0::2:1 activate
R1(config-router)# neighbor FEC0::3:1 activate
R1(config-router)# exit-address-family
171
R1(config)# ipv6 router ospf 1
R1(config-rtr)# router-id 1.1.1.1
Router 2
R2#ipv6 unicast-routing
R2#ipv6 cef
R2(config)#interface Loopback0
R2(config-if)# ipv6 address FEC0::2:1/112
R2(config-if)# ipv6 ospf 1 area 0
R2(config)#interface Serial1/0
R2(config-if)# ipv6 enable
R2(config-if)# ipv6 address FEC0::12:2/112
R2(config-if)# ipv6 ospf 1 area 0
R2(config-if)# no shutdown
R2(config)#interface Serial1/1
R2(config-if)# ipv6 enable
R2(config-if)# ipv6 address FEC0::23:2/112
R2(config-if)# ipv6 ospf 1 area 0
R2(config-if)# no shutdown
R2(config)#router bgp 1
R2(config-router)# bgp router-id 2.2.2.2
R2(config-router)# bgp log-neighbor-changes
R2(config-router)# neighbor FEC0::1:1 remote-as 1
172
R2(config-router)# neighbor FEC0::1:1 update-source Loopback0
R2(config-router)# neighbor FEC0::3:1 remote-as 1
R2(config-router)# neighbor FEC0::3:1 update-source Loopback0
R2(config-router)# address-family ipv6
R2(config-router)# neighbor FEC0::1:1 activate
R2(config-router)# neighbor FEC0::3:1 activate
R2(config-router)# exit-address-family
R2(config)# ipv6 router ospf 1
R2(config-rtr)# router-id 2.2.2.2
Router 3
R3(config)# ipv6 unicast-routing
R3(config)# ipv6 cef
R3(config)# interface Loopback0
R3(config-if)# ipv6 address FEC0::3:1/112
R3(config-if)# ipv6 ospf 1 area 0
R3(config)# interface Serial1/0
R3(config-if)# ipv6 enable
R3(config-if)# ipv6 address FEC0::13:3/112
R3(config-if)# ipv6 ospf 1 area 0
R3(config-if)# clock rate 64000
R3(config-if)# no shutdown
R3(config)# interface Serial1/1
R3(config-if)# ipv6 enable
R3(config-if)# ipv6 address FEC0::23:3/112
R3(config-if)# ipv6 ospf 1 area 0
173
R3(config-if)# clock rate 64000
R3(config-if)# no shutdown
R3(config)# interface Serial1/2
R3(config-if)# ipv6 enable
R3(config-if)# ipv6 address 2001:DB8:1:1::1/64
R3(config-if)# no shutdown
R3(config)#router bgp 1
R3(config-router)# bgp router-id 3.3.3.3
R3(config-router)# no bgp default ipv4-unicast
R3(config-router)# bgp log-neighbor-changes
R3(config-router)# neighbor 2001:DB8:1:1::2 remote-as 2
R3(config-router)# neighbor 2001:DB8:1:1::2 ebgp-multihop 8
R3(config-router)# neighbor FEC0::1:1 remote-as 1
R3(config-router)# neighbor FEC0::1:1 update-source Loopback0
R3(config-router)# neighbor FEC0::2:1 remote-as 1
R3(config-router)# neighbor FEC0::2:1 update-source Loopback0
R3(config-router)# address-family ipv6
R3(config-router)# neighbor 2001:DB8:1:1::2 activate
R3(config-router)# neighbor FEC0::1:1 activate
R3(config-router)# neighbor FEC0::1:1 next-hop-self
R3(config-router)# neighbor FEC0::2:1 activate
R3(config-router)# neighbor FEC0::2:1 next-hop-self
R3(config-router)# exit-address-family
R3(config)# ipv6 router ospf 1
R3(config-rtr)# router-id 3.3.3.3
174
Router4
R4(config)# ipv6 unicast-routing
R4(config)# ipv6 cef
R4(config)# interface Loopback2000
R4(config-if)# ipv6 address EFFE:DB8:1:1::1/64
R4(config)# interface Serial1/0
R4(config-if)# ipv6 enable
R4(config-if)# ipv6 address 2001:DB8:1:1::2/64
R4(config-if)# ipv6 ospf 1 area 0
R4(config-if)# clock rate 64000
R4(config-if)# no shutdown
R4(config)#router bgp 2
R4(config-router)# bgp router-id 4.4.4.4
R4(config-router)# no bgp default ipv4-unicast
R4(config-router)# bgp log-neighbor-changes
R4(config-router)# neighbor 2001:DB8:1:1::1 remote-as 1
R4(config-router)# neighbor 2001:DB8:1:1::1 ebgp-multihop 8
R4(config-router)# address-family ipv6
R4(config-router)# neighbor 2001:DB8:1:1::1 activate
R4(config-router)# network EFFE:DB8:1:1::/64
R4(config-router)# exit-address-family
R4(config)#ipv6 route ::/0 serial 1/0
175
5.4 TRANSICIÓN Y COEXISTENCIA
Para que la transición entre ambos protocolos se produzca de forma gradual y sin
mayores impactos sobre el funcionamiento de las redes es necesario que exista
un período de coexistencia entre los protocolos IPv4 e IPv6.
Con el objetivo de facilitar el proceso de transición entre las dos versiones del
Protocolo de Internet se han desarrollado algunas técnicas para que toda la base
de redes instaladas sobre IPv4 se mantenga compatible con IPv6, ya que en este
primer momento de coexistencia de los dos protocolos la compatibilidad es
fundamental para el éxito de la transición a IPv6.
Cada una de estas técnicas tiene características específicas y se puede utilizar
individualmente o junto con otras técnicas para adecuarse a las necesidades de
cada situación, ya sea una migración a IPv6 que se realiza paso a paso,
comenzando por un único host o subred, o incluso toda una red corporativa.
Estos mecanismos de transición se pueden clasificar en las siguientes categorías:
Doble pila: Provee soporte a ambos protocolos en el mismo dispositivo;
Tunelización: Permite el tráfico de paquetes IPv6 sobre estructuras de red
IPv4; y
Traducción: Permite la comunicación entre nodos que solo soportan IPv6 y
nodos que solo soportan IPv4.
Como el período de coexistencia de los dos protocolos puede durar
indefinidamente, la implementación de métodos que permitan la interoperabilidad
entre IPv4 e IPv6 garantizará una migración segura hacia el nuevo protocolo a
través de la realización de pruebas que permitan conocer las opciones que
ofrecen dichos mecanismos y además podrían evitar que en el futuro surjan "islas"
de comunicación aisladas.
176
5.4.1 Doble Pila
En esta fase inicial de implementación de IPv6 todavía no es aconsejable tener
nodos que solamente soporten esta versión del protocolo IP, ya que muchos
servicios y dispositivos de red continúan trabajando solamente sobre IPv4. Por
este motivo, una posibilidad consiste en implementar el método conocido como
doble pila.
El uso de este método permite que los hosts y routers estén equipados con pilas
para ambos protocolos y tengan la capacidad de enviar y recibir ambos tipos de
paquetes, IPv4 e IPv6. Así, en la comunicación con un nodo IPv6 un nodo doble
pila (o nodo IPv6/IPv4) se comportará como un nodo solo IPv6, mientras que en la
comunicación con un nodo IPv4 se comportará como un nodo solo IPv4. La Figura
5.39 representa el concepto de doble pila.
Figura 5.39 Concepto de la doble pila
Fuente:lacnic.com
Cada nodo IPv6/IPv4 se configura con ambas direcciones, utilizando mecanismos
IPv4 (por ejemplo DHCP) para adquirir su dirección IPv4 y mecanismos del
protocolo IPv6 (por ejemplo autoconfiguración y/o DHCPv6) para adquirir su
dirección IPv6.
177
Este método de transición puede facilitar la gestión de la implementación de IPv6,
ya que permite implementar IPv6 en forma gradual, configurando pequeñas
secciones del entorno de red cada vez. Además, si en el futuro se dejara de
utilizar IPv4, bastaría con deshabilitar la pila IPv4 de cada nodo.
Al implementar la técnica de doble pila es necesario considerar algunos aspectos.
Se debe analizar la necesidad de realizar cambios en la infraestructura de red,
como por ejemplo la estructuración del servicio de DNS y la configuración de los
protocolos de enrutamiento y los firewalls.
Con respecto al DNS, es necesario que éste esté habilitado para resolver nombres
y direcciones de ambos protocolos. En el caso de IPv6, es necesario que
responda a consultas de registros tipo AAAA (quad-A), que almacenan direcciones
en formato IPv6.
En una red IPv6/IPv4 la configuración del enrutamiento IPv6 normalmente es
independiente de la configuración del enrutamiento IPv4. Esto implica que si antes
de la implementación de la pila doble la red solo utilizaba el protocolo de
enrutamiento interno OSPFv2 (que solo soporta IPv4), será necesario migrar a un
protocolo de enrutamiento que soporte tanto IPv6 como IPv4, como por ejemplo
IS-IS, o forzar la ejecución de un IS-IS o OSPFv3 en paralelo con el OSPFv2.
La forma en que se realiza el filtrado de paquetes que atraviesan la red puede
depender de la plataforma que se esté usando.
5.4.1.1 Configuración Dual-Stack (Doble Pila)
La Figura 5.40 muestra la topología usada para la simulación de la doble pila.
178
Figura 5.40 Topología Doble Pila (Dual Stack)
A continuación se relacionan los comandos necesarios en cada uno de los routers
de la topología propuesta:
ROUTER 1
Router>enable
Router#configure terminal
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 10.0.0.0
Router(config-router)#exit
Router(config)#ipv6 unicast-routing
Router(config)#ipv6 router rip RIC
Router(config)#exit
Router(config)#interface fastethernet0/0
Router(config-if)#ip address 10.100.100.1 255.255.255.0
179
Router(config-if)#duplex auto
Router(config-if)#speed auto
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface fastethernet0/1
Router(config-if)#ip address 10.200.200.1 255.255.255.0
Router(config-if)#duplex auto
Router(config-if)#speed auto
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:1:1:1::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface serial1/0
Router(config-if)#ip address 10.5.5.1 255.255.255.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:4:4:4::1/64
Router(config-if)#clock rate 64000
Router(config-if)#no shutdown
Router(config-if)#exit
180
ROUTER 2
Router>enable
Router#configure terminal
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 10.0.0.0
Router(config-router)#exit
Router(config)#ipv6 unicast-routing
Router(config)#ipv6 router rip RIC
Router(config)#exit
Router(config)#interface fastethernet0/0
Router(config-if)#duplex auto
Router(config-if)#speed auto
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:300:300:300::1/64
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface fastethernet0/1
Router(config-if)#ip address 10.255.255.1 255.255.255.0
Router(config-if)#duplex auto
Router(config-if)#speed auto
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:2:2:2::1/64
181
Router(config-if)#no shutdown
Router(config-if)#exit
Router(config)#interface serial1/0
Router(config-if)#ip address 10.5.5.2 255.255.255.0
Router(config-if)#ipv6 enable
Router(config-if)#ipv6 rip RIC enable
Router(config-if)#ipv6 address 2001:4:4:4::2/64
Router(config-if)#clock rate 64000
Router(config-if)#no shutdown
Router(config-if)#exit
5.4.2 Técnicas de tunelización
La técnica de creación de túneles – tunelización – permite transmitir paquetes IPv6
a través de la infraestructura IPv4 existente sin necesidad de realizar ningún
cambio en los mecanismos de enrutamiento, encapsulando el contenido del
paquete IPv6 en un paquete IPv4.
Estas técnicas, descritas en la RFC 4213, han sido las más utilizadas en la fase
inicial del despliegue de IPv6 por ser fáciles de aplicar en entornos de prueba en
los cuales las redes no están estructuradas para ofrecer tráfico IPv6 nativo.
Hay diferentes técnicas de tunelización disponibles: Los escenarios en los que se
pueden aplicar, las dificultades de implementación y la diferencia de rendimiento
varían significativamente entre los diferentes modelos, por lo que es necesario
realizar un análisis detallado de cada uno de ellos.
Las principales técnicas de tunelización son las siguientes:
182
• Túneles Estáticos
• Tunnel Broker
• 6to4
• ISATAP
• Teredo
• GRE
5.4.3 Tunnel Broker
Descrita en la RFC 3053, esta técnica permite que hosts IPv6/IPv4 aislados en
una red IPv4 accedan a redes IPv6. Su funcionamiento es bastante sencillo.
Primero es necesario registrarse en un proveedor de acceso Tunnel Broker y
descargar un software o script de configuración. La conexión del túnel se
establece solicitando el servicio al Servidor Web del proveedor, quien luego de
una autenticación verifica qué tipo de conexión está utilizando el cliente (IPv4
pública o NAT) y le asigna una dirección IPv6. A partir de ese momento el cliente
puede acceder a cualquier host IPv6 en Internet.
5.4.3.1 Túnel Broker con Hurricane Electric
Hurricane Electric es un proveedor de conectividad estructurante (backbone) a
escala global, especializado en IPv6 que opera actualmente el backbone más
grande de IPv6 en el mundo, medido por el número de redes conectadas.
Procedimiento
1. Dirigirse al sitio de Hurricane Electric www.tunnelbroker.net. La figura 5.41
muestra la interfaz presentada por esta página web. Para crear un túnel es
necesario registrarse (Click en "Register" para ir a la página de registro).
183
Figura 5.41 Pagina Hurricane Electric
2. En el formulario de registro, es necesario llenar los datos y selecciona el botón
de "Register" como muestra la figura 5.42.
Figura 5.42 Registro en Hurricane Electric
3. Una vez se complete el registro se regresa a la página principal, donde
aparecerá la opción de "Create Regular Tunnel" en el menú del lado izquierdo. Se
debe seleccionar esta opción (ver registro completo y opción para crear el túnel en la
figura 5.43).
184
Figura 5.43 Registro completado
1. 4. En la página de creación de un nuevo túnel, es necesario colocar la
dirección IPv4 en el cuadro de texto disponible. Esta IP debe ser pública
(En caso de que se quiera saber la dirección IP, la página la muestra en
"You are viewing from"). En la misma página se debe selecciona el servidor
de destino, el de Miami es una buena opción para alguien que está en
Colombia (todos funcionan). La Figura 5.44 muestra esta selección. Para
finalizar se hace clic en el botón de "Create Tunnel" que se encuentra al
final de la página.
Figura 5.44 Creación del Túnel
185
5. Ahora el nuevo túnel aparece en la página principal (en la figura 5.45 es el
segundo túnel abajo). Se puede seleccionar para ver los detalles.
Figura 5.45 Descripción del nuevo túnel creado
6. En la página de detalles se puede ver toda la información relacionada con el túnel
para su configuración (Figura 5.46). Para saber específicamente como configurar el
computador es necesario seleccionar la pestaña de "Example Configurations"
Figura 5.46 Detalles del túnel creado
186
7. En "Example Configurations" se selecciona el sistema operativo para que se
muestren los comandos necesarios para la configuración en el host. La imagen de
la Figura 5.47 muestra la configuración para un equipo con Windows 7.
Figura 5.47 Configuración del túnel en el Host
Los comandos son los siguientes (Las direcciones depende de cada host):
netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel 196.29.202.41 209.51.161.58
netsh interface ipv6 add address IP6Tunnel 2001:470:4:87f::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:470:4:87f::1
Una vez realizada la configuración del túnel, puede empezarse a hacer uso de él
realizando conexiones con páginas web IPv6.
Problemas que pueden presentarse:
Si el túnel no funciona puede ser por una de las siguientes razones:
187
1.- Uso de una dirección IP privada. El host configurado debe ser alcanzable
desde Internet. Si se está detrás de un router casero lo más probable es que no se
esté utilizando una dirección pública y esto puede ser el problema.
2.- Existencia de firewalls en la red. El tunnel broker encapsula paquetes IPv6
dentro de paquetes IPv4. Este tipo de paquetes podrían ser bloqueados por
algunos firewalls de computadores personales. Es necesario permitir que el
protocolo 41 pase por el firewall; una solución puede ser desactivar el firewall de
Windows, temporalmente.
5.4.3.2 Tunel Broker con GoGo6
Este proveedor proporciona uno de los métodos más fáciles para implementar
IPv6.
Proceso:
1. Ir a la página gogonet.gogo6.com e ingresar en “Sing Up” si aun no se tiene
una cuenta de usuario (ver figura 5.48).
Figura 5.48: Pagina gogo6
2. Ingresar los datos solicitados y dar clic en “Sing UP” (Figura 5.49).
188
Figura 5.49: Registro Gogo6
3. El sistema envía un correo electrónico a quien se está registrando. Se debe
verificar y seguir los pasos especificados en el e-mail (Figura 5.50).
Figura 5.50: Invitación a verificar el mail
4. Con los datos del e-mail se debe crear el perfil con la información solicitada,
como lo muestra la Figura 5.51.
189
Figura 5.51: Creación del perfil
5. Descargar el archivo de setup como se muestra en la Figura 5.52.
Figura: 5.52 Descarga de archivo setup
6. Se debe descargar la aplicación que se ajuste al sistema operativo en el
cual se va a instalar según se ve en la Figura 5.53.
190
Figura: 5.53 Selección del sistema operativo
7. Instalar y abrir el acceso gogoc-gui, en el cual se debe dar click en
“conectar” en cómo se muestra en la figura 5.54.
Figura: 5.54 Conexión al servidor Gogo6
191
Para saber si se está conectado con soporte IPv6 se recomienda entrar en la
siguiente página: http://www.6deploy.eu/ y comprobar la conexión como se
muestra en la Figura 5.55.
Figura: 5.55 Prueba de conexión IPv6
5.4.4 Túnel 6to4
Definida en la RFC 3056, la técnica de tunelización automática 6to4 permite la
interconexión punto-a-punto entre routers, subredes o computadoras IPv6 a través
de la red IPv4, proporcionando una dirección IPv6 única que se forma a partir de
direcciones IPv4 públicas.
Este direccionamiento 6to4 utiliza el prefijo de dirección global
2002:wwxx:yyzz::/48, donde wwxx:yyzz es la dirección IPv4 pública del cliente
convertida a formato hexadecimal (ver formato en la Figura 5.56).
• Cliente/Router 6to4: Cliente que tiene una dirección IPv4 pública y conectividad
directa 6to4, es decir, que tiene una interfaz virtual 6to4 por la cual accede
directamente a la Internet IPv6 sin necesidad de utilizar un router 6to4. Solo
requiere de un Relay 6to4.
• Router 6to4: Router que soporta 6to4, permitiendo que los clientes que no
soportan este tipo de direcciones accedan a otros hosts 6to4 IPv6 a través del
192
mismo. En el caso de los accesos a la Internet IPv6, éste direcciona el tráfico
hasta el Relay Router más cercano, el cual encaminará el paquete hacia la red
IPv6.
• Relay 6to4: Router con soporte para 6to4 y que también tiene conexión nativa
a la Internet IPv6. De este modo puede enrutar y comunicarse con la red IPv6
nativa, con la red IPv4 y con la red 6to4.
• Cliente 6to4: Equipo de red o computadora que solo tiene dirección IPv6 en
formato 6to4, pero que no tiene una interfaz virtual 6to4. Por lo tanto, necesita
de un router 6to4 para realizar la comunicación con otras redes IPv6 y 6to4.
Figura 5.56: Formato de una dirección 6to4
Fuente: Migrating to IPv6
El formato de la dirección 6to4 consta de los siguientes campos:
- El prefijo 6to4 siempre es 2002, de acuerdo con la definición de la IANA.
- El siguiente campo es la dirección IPv4 pública del cliente. Se crea de
acuerdo con el siguiente ejemplo:
Dirección IPv4: 200.192.180.002
Primero se convierte cada número decimal a formato hexadecimal:
200=C8
192=C0
180=B4
002=02
Así la dirección se convierte en C8C0:B402
193
- El ID de la subred se puede usar para segmentar la red 6to4 asociada a la
dirección IPv4 pública en varias subredes (216 subredes con 264 direcciones
cada una); puede utilizar, por ejemplo, 0, 1, 2, 3, 4...
- El ID de la interfaz puede ser igual al segundo campo (IPv4 convertido a
formato hexadecimal) en el caso de la configuración automática de
Windows Vista y Server 2008, o bien 1, 2, 3, 4.., en el caso de configuración
manual o de Linux y BSD. Como la longitud de este campo es de 64 bits se
puede tener hasta 264 direcciones por cada subred.
Acontinuacion se presentaran las diferentes situaciones posibles en las redes
6to4, explicando paso a paso la ruta de inicio a fin.
- COMUNICACIÓN ENTRE CLIENTES 6TO4 QUE ESTAN EN REDES
DIFERENTES
Figura 5.57: Comunicación entre clientes 6to4 que están en redes
diferentes
Fuente: ipv6.br
194
Equipo Ruta
C1 ::/0 a través de R1
2002:0102:0304:1::/64 a través de la interfaz LAN
R1 ::/0 a través del Relay 6to4 utilizando la interfaz virtual 6to4
2002::/16 a través de la interfaz virtual 6to4
2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN
R2 ::/0 a través de R2
2002:0102:0305:1:/64 hacia la red local a través de la interfaz LAN
C2 ::/0 a través del Relay 6to4 utilizando la interfaz virtual 6to4
2002::/16 a través de la interfaz virtual 6to4
2002:0102:0305:1:/64 hacia la red local a través de la interfaz LAN
1- Analizando la tabla de enrutamiento se observa que el paquete se envía a
través de la red local IPv6 hacia el router R1 utilizando la ruta ::/0
2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN. R1 verifica su
tabla de enrutamiento y descubre que debe enviar el paquete hacia su interfaz
virtual 6to4 (ruta a la red 2002::/16). En esta interfaz el paquete IPv6 se encapsula
en un paquete IPv4 (protocolo tipo 41) que se direcciona hacia el router R2
(dirección extraída de la dirección IPv6 del destinatario del paquete original)
3- El paquete IPv6 encapsulado en IPv4 es recibido por R2 a través de su interfaz
IPv4 o WAN.
Como el paquete es de tipo 41, éste es encaminado a la interfaz 6to4, que lo
desencapsula. Al consultar su tabla de enrutamiento R2 descubre que el paquete
195
está destinado a su red local 2002:0102:0305:1::/64, por lo que encamina el
paquete IPv6 a la computadora C2 a través de su red local.
En los pasos siguientes (4, 5 y 6), el sistema de comunicación es el mismo, ya que
lo único que cambia es la dirección de encaminamiento del paquete.
- COMUNICACIÓN CLENTE/ROUTER 6TO4 CON UN SERVIDOR IPV6
Figura 5.58: Comunicación cliente/router 6to4 con un servidor ipv6
Fuente: ipv6.br
Equipo Ruta
HR1 ::/0 a través de la interfaz virtual 6to4
2002::/16 a través de la interfaz virtual 6to4
RL1 ::/0 red IPv6 a través de la interfaz LAN
196
2002::/16 a través de la interfaz virtual 6to4
S1 Ruta por defecto a través de R1
R1 2002::/16 a través del Relay RL1 (ruta descubierta a través del
anuncio vía BGP)
1- HR1 envía un paquete IPv6 al servidor S1. A través de la tabla de enrutamiento
el paquete es direccionado a la interfaz virtual 6to4. Ésta encapsula el paquete
IPv6 en un paquete IPv4 (protocolo 41) y coloca como destino la dirección del
Relay, la cual se puede especificar manualmente o descubrir automáticamente
encaminando el paquete a la dirección anycast 192.88.99.1
2- El Relay RL1 recibe el paquete encapsulado a través de su dirección IPv4 o
anycast; como el protocolo del paquete es 41, RL1 desencapsula el paquete IPv6
y, a través de su tabla de enrutamiento descubre que el paquete debe ser enviado
a S1 a través de su interfaz LAN en la red IPv6.
3- Una vez recibido el paquete, S1 responde utilizando su ruta por defecto a través
del router 1 de su red. El router R1 recibe vía BGP la ruta hacia la red 2002::/16 y
encamina el paquete al Relay RL1
4- RL1 recibe el paquete y observa que está destinado a la red 6to4, por lo que
encamina el paquete a la interfaz virtual 6to4, que lo encapsula en un paquete
IPv4 (protocolo 41) y, a través de la dirección IPv4 implícita en la dirección IPv6
del destinatario, el paquete es encaminado a HR1. HR1 recibe el paquete en su
interfaz IPv4, ve que se está utilizando el protocolo 41 y desencapsula el paquete
IPv6 a través de la interfaz virtual 6to4.
197
- COMUNICACÓN CLIENTE 6TO4 CON UN SERVIDOR IPV6
UTILIZANDO SOLO UN RELAY 6TO4 (RUTAS DE IDA Y VUELTA
IGUALES).
Figura 5.59: Comunicación cliente 6to4 con un servidor ipv6 utilizando solo
un relay 6to4 (rutas de ida y vuelta iguales)
Fuente: ipv6.br
Equipo Ruta
RL1 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la
interfaz virtual 6to4
RL2 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la
interfaz virtual 6to4
S1 Ruta por defecto a través de R2
198
R2 2002::/16 a través del Relay RL1 (ruta descubierta a través del
anuncio vía BGP)
R1 ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual
6to4
2002::/16 a través de la interfaz virtual 6to4
2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN
C1 ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz
LAN
C2 ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz
LAN
1- De acuerdo con la tabla de enrutamiento, el paquete se envía a través de la red
local IPv6 hacia el router R1 utilizando la ruta ::/0
2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN que verifica su
tabla de enrutamiento y descubre que el paquete debe ser encaminado a la
interfaz virtual 6to4 (ruta para la red 2002::/16). En esta interfaz el paquete IPv6 se
encapsula en un paquete IPv4 (protocolo tipo 41) y se envía al Relay RL1 o RL2
(el Relay 6to4 puede ser definido manualmente en el router 6to4 o
automáticamente utilizando la dirección anycast 192.88.99.1). Supongamos que el
paquete se envía al Relay RL1
3- RL1 recibe el paquete 6to4 a través de su interfaz IPv4 y, como el paquete
utiliza el protocolo 41, lo encamina a la interfaz virtual, la cual desencapsula el
paquete IPv6 y verifica en la tabla de enrutamiento que debe enviarlo por la
interfaz LAN a través del router R2, que simplemente reenvía el paquete IPv6 al
servidor S1.
199
4- S1 responde enviando otro paquete IPv6 con destino al Cliente C1 utilizando su
ruta por defecto que apunta hacia el router R2. R2 recibe el paquete a través de la
ruta recibida vía BGP y sabe que debe enviarlo al relay más próximo, que en este
caso es RL1.
5- RL1 recibe el paquete IPv6 y verifica que el destino es la red 6to4 (2002::/16).
Siendo así, de acuerdo con su tabla de enrutamiento el paquete es encaminado a
la interfaz virtual 6to4, que lo empaqueta en un paquete IPv4 (protocolo 41) y lo
envía a la dirección IPv4 implícita en la dirección IPv6 del destinatario del paquete
6- El router R1 recibe el paquete a través de su dirección IPv4 y, como el paquete
está utilizando el protocolo 41, éste es encaminado a la interfaz virtual 6to4, que lo
desencapsula y verifica la dirección de destino. De acuerdo con su tabla de
enrutamiento ésta envía el paquete IPv6 a través de su interfaz LAN al Cliente
6to4 C1.
- COMUNICACIÓN CLIENTE 6TO4 CON UN SERVIDOR IPV6
UTILIZANDO DOS RELAYS 6TO4 DIFERENTES (RUTAS DE IDA Y
VUELTAS DIFERENTES).
200
Figura 5.60: Comunicación cliente 6to4 con un servidor ipv6 utilizando dos
relays 6to4 diferentes (rutas de ida y vueltas diferentes)
Fuente: ipv6.br
Equipo Ruta
RL1 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la
interfaz virtual 6to4
RL2 ::/0 red IPv6 a través de la interfaz LAN / 2002::/16 a través de la
interfaz virtual 6to4
S2 Ruta por defecto a través de R3
R3 2002::/16 a través del Relay RL2 (ruta descubierta a través del
anuncio vía BGP)
R1 ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual
6to4
201
2002::/16 a través de la interfaz virtual 6to4
2002:0102:0304:1/64 hacia la red local a través de la interfaz LAN
C1 ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz
LAN
C2 ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz
LAN
1- De acuerdo con la tabla de enrutamiento, el paquete se envía a través de la red
local IPv6 hacia el router R1 utilizando la ruta ::/0.
2- El paquete IPv6 es recibido por R1 a través de la interfaz LAN, que verifica su
tabla de enrutamiento y descubre que el paquete debe ser enviado a la interfaz
virtual 6to4 (ruta para la red 2002::/16). En esta interfaz el paquete IPv6 se
encapsula en un paquete IPv4 (protocolo tipo 41) y se envía al Relay RL1 o RL2
(el Relay 6to4 puede ser definido manualmente en el router 6to4 o
automáticamente utilizando la dirección anycast 192.88.99.1). Supongamos que el
paquete se envía al Relay RL1.
3- RL1 recibe el paquete 6to4 a través de su interfaz IPv4, ve que el paquete
utiliza el protocolo 41 y lo encamina a la interfaz virtual. Ésta desencapsula el
paquete IPv6 y verifica en su tabla de enrutamiento que debe enviarlo por la
interfaz LAN a través del router R3, que simplemente reenvía el paquete IPv6 al
servidor S2.
4- S2 responde enviando otro paquete IPv6 con destino al Cliente C2 utilizando su
ruta por defecto que apunta hacia el router R3. R3 recibe el paquete a través de la
ruta recibida vía BGP, y sabe que debe enviarlo al relay más próximo, que es RL2.
202
5- RL2 recibe el paquete IPv6 y verifica que el destino es la red 6to4 (2002::/16).
Siendo así, de acuerdo con su tabla de enrutamiento encamina el paquete a la
interfaz virtual 6to4, que lo empaqueta en un paquete IPv4 (protocolo 41) y lo
envía a la dirección IPv4 implícita en la dirección IPv6 del destinatario del paquete
6- El router R1 recibe el paquete a través de su dirección IPv4, verifica que el
paquete está utilizando el protocolo 41 y lo encamina a la interfaz virtual 6to4. Ésta
lo desencapsula y verifica la dirección de destino. De acuerdo con su tabla de
enrutamiento y la dirección de destino, el paquete IPv6 es enviado a través de su
interfaz LAN al Cliente 6to4 C2.
5.4.4.1 Configuración de un Tunel 6to4
La Figura 5.61 muestra la topología utilizada para la implementación del túnel
6to4. A continuación se incluyen los comandos que se deben introducir en cada
router para lograr la simulación de este túnel.
Figura 5.61: Topología 6to4
203
ROUTER 1
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet0/0
Router(config-if)# ipv6 enable
Router(config-if)# ipv6 address 2001:db8:1::1/64
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface serial1/0
Router(config-if)# ip address 10.1.1.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 10.1.1.0
Router(config-router)#exit
Router(config)#interface tunnel0
Router(config-if)#tunnel mode ipv6ip 6to4
Router(config-if)#tunnel source 10.1.1.1
Router(config-if)#ipv6 address 2002:0a01:0101::/128
Router(config-if)# exit
Router(config)#ipv6 route 2002::/16 tunnel0
204
Router(config)#ipv6 route 2001:db8:2::/64 2002:0a02:0202::
Router(config)#exit
ROUTER 2
Router>enable
Router#configure terminal
Router(config)# interface serial1/0
Router(config-if)# ip address 10.1.1.2 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface serial1/1
Router(config-if)# ip address 10.2.2.1 255.255.255.0
Router(config-if)# clock rate 64000
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 10.1.1.0
Router(config-router)#network 10.2.2.0
Router(config-router)#exit
205
ROUTER 3
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet0/0
Router(config-if)# ipv6 enable
Router(config-if)# ipv6 address 2001:db8:2::1
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface serial1/0
Router(config-if)# ip address 10.2.2.2 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 10.2.2.0
Router(config-router)#exit
Router(config)#interface tunnel0
Router(config-if)#tunnel mode ipv6ip 6to4
Router(config-if)#tunnel source 10.2.2.2
Router(config-if)#ipv6 address 2002:0a02:0202::/128
Router(config-if)#exit
Router(config)#ipv6 route 2002::/16 tunnel0
206
Router(config)#ipv6 route 2001:db8:1::/64 2002:0a01:0101::
Router(config)#exit
5.4.5 ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
La técnica de transición Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP), definida en la RFC 5214 se basa en túneles IPv6 creados
automáticamente dentro de la red IPv4 y en direcciones IPv6 asociadas a esos
clientes de acuerdo con el prefijo especificado en el router ISATAP y la dirección
IPv4 del cliente. Para crear estos túneles se utilizan las especificaciones de la
sección 3 de la RFC 4213, que trata la tunelización a través del protocolo IPv4 tipo
41 o 6in4.
A continuación se muestra un emjemplo de equivalencia entre direcciones
IPv4/IPv6.
Dirección IPv4 Dirección IPv6/ISATAP
250.140.80.1 2001:10fe:0:8003:200:5efe:250.140.80.1
fe80::200:5efe:250.140.80.1
192.168.50.1 2001:10fe:0:8003:0:5efe:192.168.50.1
fe80:0:5efe:250.140.80.1
207
Figura 5.62: Inicio ISATAP
Fuente: ipv6.br
- INICIO.
1- En este paso el cliente intenta determinar la dirección IPv4 del router, si la
dirección IPv4 todavía no está determinada en su configuración. En el caso de
Windows, por defecto intenta resolver el nombre ISATAP.
2- El servidor de DNS regresa la IPv4 del router ISATAP (si corresponde).
3- El cliente envía un mensaje Router Solicitation (RS) encapsulado en IPv4 al
router ISATAP.
4- El router ISATAP responde con un mensaje Router Advertisement (RA)
encapsulado en IPv4, con eso el cliente ya puede configurar sus direcciones
IPv6/ISATAP.
208
- COMUNICACIÓN ENTRE CLIENTES ISATAP EN LA MISMA RED
Figura 5.63: Comunicación entre clientes ISATAP en la misma red
Fuente: ipv6.br
1- C2 solicita la resolución DNS del nombre del router ISATAP (si fuera necesario).
2- C2 recibe IPv4 del router ISATAP (si fuera necesario).
3- El cliente envía un mensaje Router Solicitation (RS) encapsulado en IPv4 al
router ISATAP.
4- El router ISATAP responde con un mensaje Router Advertisement (RA)
encapsulado en IPv4, con eso el cliente ya puede configurar sus direcciones
Ipv6/ISATAP.
Los procesos 1 a 4 también son ejecutados por C1;
5- El cliente ISATAP C2 envía un paquete IPv6 encapsulado en IPv4 utilizando el
protocolo 41 a través de la red IPv4 con destino a la dirección IPv4 de C1.
209
6- El cliente ISATAP C1 recibe el paquete IPv4 y desencapsula el paquete IPv6,
luego de lo cual éste responde con otro paquete IPv6 encapsulado en IPv4
utilizando el protocolo 41 a través de la red IPv4 con destino a la dirección IPv4 del
cliente C2.
- COMUNICACIÓN ENTRE CLIENTES ISATAP EN REDES DIFERENTES
Figura 5.64: Comunicación entre clientes en redes diferentes
Fuente: ipv6.br
1. El cliente ISATAP C1 desea enviar un paquete IPv6 al cliente C2. A través de
su tabla de enrutamiento descubre que debe enviarlo utilizando la interfaz virtual
ISATAP, por lo que el paquete se encapsula en IPv4 (protocolo 41) y se envía a la
dirección IPv4 del router R1.
2. El router R1 recibe el paquete a través de su interfaz IPv4 pero, como el
paquete IPv6 está encapsulado utilizando el protocolo 41, éste lo desencapsula
(utilizando la interfaz virtual ISATAP) y verifica la dirección IPv6 del destino.
Después de esto descubre que la ruta hacia el destino es a través de la red IPv6,
por lo que el paquete desencapsulado (IPv6 nativo) se encamina al router R2.
210
3. El router R2 recibe el paquete IPv6 en su interfaz IPv6 pero al verificar la
dirección de destino descubre que es para el cliente C2 que está en su subred
ISATAP, por lo que envía el paquete a través de esta interfaz, que encapsula
nuevamente el paquete IPv6 en un paquete IPv4 y lo envía a C2 (con base en la
dirección IPv4 implícita en IPv6). El cliente ISATAP C1 recibe el paquete IPv4 y
desencapsula el paquete IPv6 (a través de la interfaz virtual ISATAP).
4. El cliente ISATAP C2 desea responder al cliente C1, por lo que verifica su tabla
de rutas y concluye que debe enviar el paquete a través de la interfaz virtual
ISATAP, por lo que el paquete IPv6 es encapsulado en IPv4 y encaminado al
router R2.
5. El router R2 recibe el paquete a través de su interfaz IPv4 pero, como el
paquete está utilizando el protocolo 41, éste desencapsula el paquete IPv6 y luego
de verificar en su tabla de enrutamiento lo encamina a través de su interfaz IPv6.
6. El router R1 recibe el paquete IPv6 pero verificando en su tabla de enrutamiento
descubre que el paquete debe ser enviado a través de su interfaz virtual ISATAP,
la cual encapsula el paquete IPv6 en IPv4 utilizando el protocolo 41 y lo encamina
a la dirección IPv4 de C1.
C1 recibe el paquete pero, como el paquete fue encapsulado utilizando el
protocolo 41, éste extrae el paquete IPv6 enviado por C2 y lo recibe.
211
- COMUNICACIÓN ENTRE CLIENTES ISATAP Y COMPUTADORAS IPV6
Figura 5.65: Comunicación entre clientes ISATAP y computadoras IPv6
Fuente: ipv6.br
1. El cliente ISATAP desea enviar un paquete IPv6 al servidor IPv6. A través de su
tabla de enrutamiento descubre que debe enviarlo utilizando la interfaz virtual
ISATAP, por lo que el paquete se encapsula en IPv4 (protocolo 41) y se envía a la
dirección IPv4 del router ISATAP.
2. El router ISATAP recibe el paquete a través de su interfaz IPv4 pero, como el
paquete IPv6 está encapsulado utilizando el protocolo 41, éste lo desencapsula
(utilizando la interfaz virtual ISATAP) y verifica la dirección IPv6 del destino.
Después de esto descubre que la ruta hacia el destino es a través de la red IPv6,
por lo que el paquete desencapsulado (IPv6 nativo) se encamina al router IPv6. El
servidor recibe el paquete IPv6 destinado al mismo.
3- El servidor IPv6 desea responder al cliente ISATAP, por lo que verificando su
tabla de enrutamiento descubre que debe enviarlo a través de su ruta por defecto,
que es a través de la red IPv6.
212
4- Como la ruta para la red del cliente ISATAP es a través del router ISATAP, el
paquete es encaminado al mismo a través de su interfaz IPv6. Verificando en su
tabla de enrutamiento el router descubre que debe enviar el paquete a través de
su interfaz virtual ISATAP, por lo que el paquete es encapsulado en IPv4 y
encaminado al cliente ISATAP a través de la red IPv4. El cliente recibe el paquete
IPv4 pero, como está utilizando protocolo 41, desencapsula y recibe el paquete
IPv6.
5.4.5.1 Configuración ISATAP
La Figura 5.66 muestra la topología para la implementación del túnel ISATAP.
Figura 5.66: Topología básica ISATAP
La siguiente es la relación de comandos que deben ser introducidos en los routers
de la topología de la Figura 5.66 para la implementación del túnel ISATAP.
213
ROUTER 1
Router>enable
Router#configure terminal
Router(config)# interface fastethernet 0/0
Router(config-if)# ip address 192.0.2.2 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface fastethernet 0/1
Router(config-if)# ip address 192.0.3.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 192.0.2.0
Router(config-router)#network 192.0.3.0
Router(config-router)#exit
ROUTER 2
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet 0/0
Router(config-if)# ip address 192.0.3.2 255.255.255.0
214
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface fastethernet 0/1
Router(config)# ipv6 enable
Router(config-if)# ipv6 address 3ffe:b00:1:2::2/64
Router(config-if)# ipv6 rip RIC enable
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 192.0.3.0
Router(config-router)#exit
Router(config)#interface tunnel0
Router(config-if)#ipv6 address 3ffe:b00:1:3::/64 eui-64
Router(config-if)#no ipv6 nd suppress-ra
Router(config-if)#tunnel source 192.0.3.2
Router(config-if)#tunnel mode ipv6ip isatap
Router(config-if)# exit
Router(config)#ipv6 route 3ffe:b00:1:3::/64 3ffe:b00:1:2::1
Router(config)#ipv6 router rip RIC
Router(config-rtr)#exit
ROUTER 3
Router>enable
Router#configure terminal
215
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet 0/0
Router(config)# ipv6 enable
Router(config-if)# ipv6 address 3ffe:b00:1:1::2/64
Router(config-if)# ipv6 rip RIC enable
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# interface fastethernet 0/1
Router(config)# ipv6 enable
Router(config-if)# ipv6 address 3ffe:b00:1:2::1/64
Router(config-if)# ipv6 rip RIC enable
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#ipv6 router rip RIC
Router(config-rtr)#exit
Router(config)#ipv6 route 3ffe:b00:1:3::/64 3ffe:b00:1:2::2
EN WINDOWS
c> netsh interface ipv6 isatap set router 192.0.3.1
c> netsh interface ipv6 set interface 2 forwarding=enabled advertise=enabled
c> netsh interface ipv6 set route 3ffe:b00:1:3::/64 2 publish=yes
216
5.4.6 Túnel Teredo
La técnica de tunelización automática Teredo, definida en la RFC 4380, permite
que los nodos ubicados detrás de NAT (Network Address Translation) obtengan
conectividad IPv6 utilizando el protocolo UDP.
La conexión se realiza a través de un Servidor Teredo que la inicializa y determina
el tipo de NAT usado por el cliente. Luego, si el host de destino tiene IPv6 nativo,
se utiliza un Relay Teredo para crear una interfaz entre el Cliente y el host de
destino. El Relay utilizado será siempre el que esté más próximo al host de
destino, no el más próximo al cliente.
Esta técnica no es demasiado eficiente debido al overhead y la complejidad de su
funcionamiento, pero cuando el host está detrás de NAT es una de las únicas
opciones disponibles.
Por defecto, Windows Vista ya viene con Teredo instalado y activado, mientras
que en Windows XP, 2003 y 2008 solo vienen instalados. En FreeBSD y Linux ni
siquiera viene instalado.
Para facilitar la comprensión del funcionamiento de este tipo de túnel, en el
siguiente cuadro presentamos un resumen de los cuatro tipos de NAT existentes:
NAT de Cono - Todas las solicitudes originadas en una misma dirección y puerto
internos son mapeadas a un mismo puerto de NAT. Por lo tanto solo es necesario
conocer la dirección pública del NAT y el puerto asociado a un nodo interno para
que un nodo externo establezca una comunicación sin importar su dirección o
puerto, pudiendo así enviar arbitrariamente paquetes al nodo interno. También se
conoce como NAT Estático.
217
NAT de Cono Restringido - Todas las solicitudes originadas en una misma
dirección y puerto internos son mapeadas a un mismo puerto de NAT. Sin
embargo, el acceso externo solo se permite en respuesta a solicitudes realizadas
previamente, porque la dirección del nodo externo, que está respondiendo a la
solicitud, debe ser la misma utilizada como dirección de destino de la solicitud.
También se conoce como NAT Dinámico.
NAT de Cono Restringido por Puerto - Tiene las mismas características de
mapeo que el NAT de Cono restringido, pero la restricción para la comunicación
también considera el puerto del nodo externo. Así, un nodo externo solo podrá
establecer una comunicación con un nodo interno si éste último le ha enviado
previamente un paquete a través del mismo puerto y dirección.
NAT Simétrico - Además de tener las mismas restricciones que el NAT tipo Cono
Restringido por Puerto, cada solicitud realizada desde una dirección y puerto
internos a una dirección y puerto externos es mapeada únicamente en el NAT. Es
decir, si la misma dirección interna envía una solicitud, con el mismo puerto, pero
para una dirección de destino diferente, en el NAT se creará un mapeo diferente.
Este tipo de NAT también se conoce como NAT Masquerade o NAT Stateful.
Figura 5.67: Formato de dirección teredo
Fuente: Migrating to IPv6
Con base en los mensajes RA recibidos de los Servidores, el cliente construye su
dirección IPv6 (ver formato de esta dirección en la Figura 5.67), utilizando el
siguiente estándar:
218
Los bits 0 a 31 son el prefijo de Teredo recibido del Servidor a través de los
mensajes RA. Por defecto es 2001:0000
Los bits 32 a 63 son la dirección IPv4 primaria del Servidor Teredo que envió el
primer mensaje RA
Los bits 64 a 79 se utilizan para definir algunos flags. Generalmente solo se
utiliza el bit más significativo, y éste se marca como 1 si el Cliente está detrás
de NAT tipo Cono. En caso contrario se marca como 0. Solo Windows Vista y
Windows Server 2008 utilizan los 16 bits que siguen el formato "CRAAAAUG
AAAAAAAA", donde "C" sigue siendo el flag Cono; el bit R está reservado para
uso futuro; el bit U define el flag Universal/Local (el valor por defecto es 0); el
bit G define el flag Individual/Group (el valor por defecto 0); y los 12 bits “A” son
determinados aleatoriamente por el Cliente para introducir una protección
adicional contra los ataques de barrido.
Los bits 80 a 95 son el puerto UDP de salida del NAT recibido en los mensajes
RA y enmascarado mediante la inversión de todos sus bits. Este
enmascaramiento es necesario porque algunos NAT buscan puertos locales
dentro de los paquetes y los reemplazan por el puerto público o viceversa.
Los bits 96 a 127 son la dirección IPv4 pública del Servidor NAT, enmascarado
a través de la inversión de todos sus bits. Este enmascaramiento es necesario
porque algunos NAT buscan direcciones IP locales dentro de los paquetes y
las reemplazan por la dirección pública o viceversa.
219
Figura 5.68: Túnel Teredo
Fuente: ipv6.br
1- Se envía un mensaje Router Solicitation (RS) al servidor Teredo 1 (servidor
primario) con el flag de NAT tipo Cono activado; el servidor Teredo 1 responde con
un mensaje Router Advertisement (RA). Como el mensaje RS tenía activado el
flag Cono, el servidor Teredo 1 envía el mensaje RA utilizando una dirección IPv4
alternativa. Con eso el cliente podrá determinar si el NAT que está utilizando es
tipo Cono, si recibe el mensaje RA.
2- Si no se recibe el mensaje RA del paso anterior, el cliente Teredo envía otro
mensaje RS, pero ahora con el flag Cono desactivado. El servidor Teredo 1
responde nuevamente con un mensaje RA pero, como el flag Cono del mensaje
RS está desactivado, responde utilizando la misma dirección IPv4 que recibió en
el mensaje RS. Si ahora el cliente recibe el mensaje RA, entonces concluye que
está usando NAT tipo restringido.
3- Para tener la certeza de que el cliente Teredo no está utilizando un NAT de tipo
simétrico, éste envía otro mensaje RS, esta vez al servidor secundario Teredo 2,
que responde con un mensaje tipo RA. Cuando el cliente recibe el mensaje RA del
servidor Teredo 2 compara la dirección y el puerto UDP de origen contenidos en el
mensaje RA recibido de los dos servidores; si son diferentes el cliente concluye
que está utilizando NAT tipo simétrico, el cual no es compatible con Teredo.
220
- COMUNICACIÓN A TRAVÉS DE NAT TIPO CONO
La figura 5.69 muestra los pasos que se siguen para lograr la comunicación a
través de un túnel Teredo cuando se debe atravesar un NAT tipo Cono. A
continuación se describen dichos pasos:
Figura 5.69: Comunicaciones a través de NAT tipo Cono
Fuente: ipv6.br
1- Para iniciar la comunicación el cliente Teredo primero debe determinar la
dirección IPv4 y el puerto UDP del Relay Teredo que esté más próximo al host
IPv6; para ello envía un mensaje ICMPv6 echo request al host IPv6 a través de su
servidor Teredo.
2- El servidor Teredo recibe el mensaje ICMPv6 echo request y lo encamina al
host IPv6 a través de la red IPv6.
3- El host IPv6 responde al cliente Teredo con un mensaje ICMPv6 Echo Reply
que es enrutado a través del Relay Teredo más próximo al mismo.
221
4- Luego el Relay Teredo encapsula el mensaje ICMPv6 Echo Reply y lo envía
directamente al cliente Teredo. Como el NAT utilizado por el cliente es tipo Cono,
el paquete enviado por el Relay Teredo es encaminado al cliente Teredo.
5- Como el paquete que devuelve el Relay Teredo contiene una dirección IPv4 y el
número de puerto UDP utilizado por el mismo, el cliente Teredo extrae esta
información del paquete. Después un paquete inicial es encapsulado y enviado
directamente por el cliente Teredo a la dirección IPv4 y puerto UDP del Relay
Teredo.
6- El Relay Teredo recibe este paquete, elimina el encabezado IPv4 y UDP y lo
encamina al host IPv6. Luego toda la comunicación entre el cliente Teredo y el
host IPv6 se realiza a través del relay Teredo con este mismo método.
- COMUNICACIONES A TRAVES DE NAT RESTRINGIDO
La figura 5.70 muestra los pasos que se siguen para lograr la comunicación a
través de un túnel Teredo cuando se debe atravesar un NAT restringido. A
continuación se describen los pasos correspondientes:
222
Figura 5.70: Comunicaciones a través de NAT restringido
Fuente: ipv6.br
1- Para iniciar la comunicación primero el cliente Teredo debe determinar la
dirección IPv4 y el puerto UDP del Relay Teredo que esté más próximo al host
IPv6; para ello envía un mensaje ICMPv6 echo request al host IPv6 a través de su
servidor Teredo
2- El servidor Teredo recibe el mensaje ICMPv6 echo request y lo encamina al
host IPv6 a través de la red IPv6
3- El host IPv6 responde al cliente Teredo con un mensaje ICMPv6 Echo Reply
que es enrutado a través del Relay Teredo más próximo al mismo
4- A través del paquete recibido el Relay Teredo descubre que el cliente Teredo
está utilizando un NAT tipo restringido, por lo que, si el Relay Teredo envía el
paquete ICMPv6 directamente al cliente Teredo, éste será descartado por el NAT
debido a que no hay mapeo predefinido para el tráfico entre el cliente y el Relay
Teredo; por lo tanto, el Relay Teredo envía un paquete “bubble” al cliente Teredo a
través del Servidor Teredo utilizando la red IPv4
223
5- El servidor Teredo recibe el paquete “bubble” del Relay Teredo y lo encamina al
cliente Teredo, pero en el indicador de origen coloca la IPv4 y el puerto UDP del
Relay Teredo. Como ya había un mapeo de tráfico entre el servidor Teredo y el
Cliente Teredo, el paquete pasa por el NAT y es entregado al Cliente Teredo
6- El Cliente Teredo extrae del paquete “bubble” recibido la IPv4 y el puerto UDP
del Relay Teredo más próximo al host IPv6, y el Cliente Teredo envía un paquete
“Bubble” al Relay Teredo para que se cree un mapeo de conexión entre ellos en el
NAT
7- En base al contenido del paquete “bubble” recibido, el Relay Teredo puede
determinar que éste corresponde al paquete ICMPv6 Echo Reply que está en la
cola a transmitir y que el paso a través del NAT restringido ya está abierto, por lo
que encamina el paquete ICMPv6 Echo Reply al cliente Teredo
8- Una vez recibido el paquete ICMPv6, se envía un paquete inicial del Cliente
Teredo al host
IPv6 a través del Relay Teredo más próximo al mismo
9- El relay Teredo quita los encabezados IPv4 y UDP del paquete y lo encamina a
través de la red IPv6 al host IPv6. Después de esto los paquetes subsiguientes se
envían a través del Relay Teredo.
5.4.7 GRE (Generic Routing Encapsulation)
GRE (Generic Routing Encapsulation) es un túnel estático entre dos hosts
desarrollado originalmente por Cisco con el objetivo de encapsular diferentes tipos
de protocolos, como por ejemplo IPv6 e IS-IS (ver la lista completa de protocolos
soportados en http://www.iana.org/assignments/ethernet-numbers). Este tipo de
encapsulamiento es soportado por la mayoría de los sistemas operativos y routers
224
y consiste en un enlace punto-a-punto. La principal desventaja del túnel GRE es la
configuración manual que, dependiendo de la cantidad de túneles, implicará un
gran esfuerzo en términos de su mantenimiento y administración.
El funcionamiento de este tipo de túnel es muy simple y consiste en tomar los
paquetes originales, agregar el encabezado GRE y enviarlos a la IP de destino (la
dirección de destino está especificada en el encabezado GRE); cuando el paquete
encapsulado llega al otro extremo del túnel (IP de destino) se quita el encabezado
GRE y queda solo el paquete original, el cual se encamina normalmente a su
destinatario.
Los campos más importantes del encabezado GRE son los siguientes:
- C (Checksum): Si es 1, indica que el campo Checksum existe y que hay
información válida en el mismo y en el campo Offset
- R (Routing): Si es 1, indica que el campo Enrutamiento existe y que hay
información de enrutamiento válida en el mismo y en el campo Offset
- K (Key): Si es 1, indica que el campo Clave existe y está siendo utilizado
- S (Sequence): Si es 1, indica que el campo Número de Secuencia existe y está
siendo utilizado
- Versión Generalmente se completa con 0
- Protocolo: Se completa con el código del protocolo que está siendo transportado,
de acuerdo con los tipos de paquetes ethernet
(http://www.iana.org/assignments/ethernet-numbers)
225
- Offset: Indica la posición donde inicia el campo de enrutamiento;
- Checksum: Contiene el checksum IP (complemento a 1) del encabezado GRE y
del paquete que está siendo transportado
- Clave (Key): Contiene un número de 32 bits que es introducido por el
encapsulador. Es utilizado por el destinatario para identificar el remitente del
paquete
- Número de secuencia (Sequence number): Contiene un número entero de 32 bits
que es introducido por el remitente del paquete. Es utilizado por el destinatario
para secuenciar los paquetes recibidos
- Enrutamiento (Routing): Contiene una lista de entradas de enrutamiento, pero
generalmente no se utiliza.
5.4.7.1 Implementación de un Túnel GNRE IPv6
La Figura 5.71 presenta la topología implementada para la realización de un túnel
GNRE IPv6. Se incluye a continuación las configuraciones necesarias en cada
router de la topología:
226
Figura 5.71: Topología Tunnel GNRE IPv6
ROUTER 1
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet0/0
Router(config-if)# ipv6 enable
Router(config-if)# ipv6 address 2001:db8:1:1::1/64
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#interface serial 1/0
Router(config-if)# ip address 192.0.1.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
227
Router(config-router)#version 2
Router(config-router)#network 192.0.1.0
Router(config-router)#exit
Router(config)#interface tunnel0
Router(config-if)#ipv6 address 2001:db8:5:5::1/64
Router(config-if)#tunnel source 192.0.1.1
Router(config-if)#tunnel destination 192.0.2.1
Router(config-if)#tunnel mode gre ip
Router(config-if)#no shutdown
Router(config-if)# exit
Router(config)#ipv6 route ::/0 2001:db8:5:5::2
ROUTER 2
Router>enable
Router#configure terminal
Router(config)#interface serial 1/0
Router(config-if)# ip address 192.0.1.2 255.255.255.0
Router(config-if)# clock rate 64000
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#interface serial1/1
Router(config-if)# ip address 192.0.2.2 255.255.255.0
Router(config-if)# clock rate 64000
Router(config-if)# no shutdown
228
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 192.0.1.0
Router(config-router)#network 192.0.2.0
Router(config-router)#exit
ROUTER 3
Router>enable
Router#configure terminal
Router(config)# ipv6 unicast-routing
Router(config)# interface fastethernet0/0
Router(config-if)# ipv6 enable
Router(config-if)# ipv6 address 2001:db8:2:2::1/64
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#interface serial 1/0
Router(config-if)# ip address 192.0.2.1 255.255.255.0
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)#router rip
Router(config-router)#version 2
Router(config-router)#network 192.0.2.0
229
Router(config-router)#exit
Router(config)#interface tunnel0
Router(config-if)#ipv6 address 2001:db8:5:5::2/64
Router(config-if)#tunnel source 192.0.2.1
Router(config-if)#tunnel destination 192.0.1.1
Router(config-if)#tunnel mode gre ip
Router(config-if)#no shutdown
Router(config-if)# exit
Router(config)#ipv6 route ::/0 2001:db8:5:5::1
5.4.8 Analisis comparativo entre las estrategias de transición
La solución más fácil y la más recomendable es la implementación de Dual-Stack,
pues permite que cualquier topología de red trabaje con ambos protocolos.
Actualmente el ruteo Dual-Stack es una estrategia muy utilizada en el desarrollo
de infraestructuras de red que manejan aplicaciones que trabajan con protocolos
IPv4 e IPv6. Sin embargo, existen ciertas limitaciones para el uso de esta
alternativa; a más de la obvia necesidad de actualizar todos los routers de una red
se suman problemas como que todos los routers requieren la definición de un
doble esquema de direccionamiento, además se necesita una doble
administración de los protocolos de ruteo, y por último, que los routers deben ser
configurados con suficiente memoria para almacenar las tablas de ruteo de ambos
protocolos.
Cuando los routers no pueden implementar IPv6, se debe implementar túneles
IPv6 en IPv4.
230
Los túneles estáticos tales como el túnel manual corriente y GRE (Generic Route
Encapsulation), tiene el inconveniente de que no son prácticos cuando la cantidad
de túneles a implementar es grande o cuando las direcciones IP son cambiantes.
Respecto a los túneles automáticos puede concluirse lo siguiente:
Túnel 6to4. Tiene la ventaja de que de forma automática asigna espacio de
direcciones IPv6, pero no puede atravesar NATs. Solo se implementa en routers
de borde. Se recomienda su uso en redes pequeñas o redes de hogar donde no
existe NAT y no es aplicable en empresas ni para grandes redes.
Túnel ISATAP. Es adecuado para redes de empresas pero no para ISPs ni para
redes de hogar. Además, este mecanismo no funciona cuando existen NATs en el
camino entre dos nodos ISATAP.
TSP Tunnel broker. Tiene la ventaja de atravesar cualquier tipo de NAT y es la
única posibilidad de acceso a la Internet IPv6 de nodos de doble pila que se
encuentren tras routers que por su tecnología no pueden ser habilitados para IPv6,
pero para su implementación se requiere de la presencia externa de Agentes y de
servidores de túnel. Este túnel puede tener inconvenientes para su funcionamiento
si las protecciones (firewalls) de las redes impiden el paso de los mensajes
correspondientes a este protocolo.
Túnel Teredo. Permite a los nodos establecer túneles IPv6 sobre IPv4 a través de
NATs empleando encapsulamiento IPv6 en UDP-IPv4, aunque su uso está
restringido cuando existen NATs simétricos en la red. Para la implementación de
este túnel de requiere de un servidor Teredo (Teredo server) y de un repetidor o
relé Teredo (Teredo relay), pero se sabe que hay disponibles muchos repetidores
Teredo bien dispersos en la Internet IPv4 y en la Internet Ipv6.
231
5.4.9 Técnicas de traducción
Las técnicas de traducción permiten un enrutamiento transparente en la
comunicación entre nodos que solamente soportan una versión del protocolo IP o
que utilizan doble pila. Estos mecanismos pueden actuar de diferentes formas y en
distintas capas, traduciendo encabezados IPv4 a encabezados IPv6 y viceversa,
realizando conversiones de direcciones de APIs de programación, o actuando en
el intercambio de tráfico TCP o UDP.
5.4.9.1 SIIT
SIIT (Stateless IP/ICMP Translation Algorithm) - Definido en la RFC 2765, SIIT es
un mecanismo de traducción stateless de encabezados IP/ICMP que permite la
comunicación entre nodos que solo soportan IPv6 y nodos que solo soportan IPv4.
Utiliza un traductor ubicado en la capa de red de la pila, el cual convierte campos
específicos de los encabezados de paquetes IPv6 en encabezados de paquetes
IPv4 y viceversa. Para realizar este proceso el traductor necesita una dirección
IPv4-mapeada en IPv6, en el formato 0::FFFF:a.b.c.d, que identifica el destino
IPv4 y una dirección IPv4-traducida en formato 0::FFFF:0:a.b.c.d, para identificar
el nodo IPv6.
Cuando el paquete llega al SIIT, el encabezado se traduce, la dirección se
convierte a IPv4 y se encamina al nodo de destino.
5.4.9.2 BIS
BIS (Bump in the Stack) - Este método permite la comunicación de aplicaciones
IPv4 con nodos IPv6. Definida en la RFC 2767, BIS funciona entre la capa de
aplicación y la capa de red, agregando a la pila IPv4 tres módulos: translator, que
traduce los encabezados IPv4 enviados a encabezados IPv6 y los encabezados
IPv6 recibidos a encabezados IPv4; extension name resolver, que actúa en las
232
DNS queries realizadas por IPv4, de modo que, si el servidor de DNS devuelve un
registro AAAA, el resolver pide al address mapper que asigne una dirección IPv4
correspondiente a la dirección IPv6; y address mapper, que posee una cierta
cantidad de direcciones IPv4 para asociar a direcciones IPv6 cuando el translator
recibe un paquete IPv6.
Como las direcciones IPv4 no se transmiten en la red, éstas pueden ser
direcciones privadas. Este método solo permite la comunicación de aplicaciones
IPv4 con hosts IPv6 y no lo contrario y además no funciona en comunicaciones
multicast.
5.4.9.3 BIA
BIA (Bump in the API) - Similar al BIS, este mecanismo agrega una API de
traducción entre el socket API y los módulos TPC/IP de los hosts de doble pila,
permitiendo la comunicación entre aplicaciones IPv4 y hosts IPv6, traduciendo las
funciones del socket IPv4 en funciones del socket IPv6 y viceversa. De acuerdo
con los descrito en la RFC 3338, se agregaron tres módulos, extension name
resolver y address mapper, que funcionan de la misma manera que en BIS, y
function mapper, que detecta las llamadas de las funciones del socket IPv4 e
invoca las funciones correspondientes del socket IPv6 y viceversa. BIA tiene dos
ventajas respecto a BIS: no depende del driver de la interfaz de red y no introduce
overhead en la traducción de los encabezados de los paquetes. Sin embargo,
tampoco soporta comunicaciones multicast.
5.4.9.4 TRT
TRT (Transport Relay Translator) - Actuando como un traductor de capa de
transporte, este mecanismo permite la comunicación entre hosts solo IPv6 y hosts
solo IPv4 a través de tráfico TCP/UDP. Sin necesidad de instalar ningún tipo de
233
software, TRT corre en equipos con doble pila que se deben insertar en un punto
intermedio dentro de la red. En la comunicación de un host IPv6 con un host IPv4,
de acuerdo con la definición de la RFC 3142, a la dirección IPv4 de destino se le
agrega un prefijo IPv6 falso. Cuando un paquete con este falso prefijo atraviesa el
TRT, dicho paquete es interceptado y enviado al host IPv4 de destino en un
paquete TCP o UDP. En la traducción TCP y UDP el checksum solo se debe
recalcular en el caso de las conexiones TCP, el estado del socket sobre el cual el
host está conectado debe ser mantenido, retirándolo cuando la comunicación haya
finalizado. Para que el mecanismo funcione de forma bidireccional es necesario
agregar un bloque de direcciones IPv4 públicas y usar un servidor DNS-ALG para
mapear las direcciones IPv4 a IPv6.
234
6. CONCLUSIONES
Con base en el estudio y análisis realizado alrededor del protocolo IPv6 y
en las implementaciones y simulaciones desarrolladas, se puede concluir
que el protocolo IPv6 ha logrado ya un alto grado de madurez, lo cual
permite su implantación sin ningún traumatismo en cualquier tipo de red y
su coexistencia con el protocolo IPv4.
Para iniciar la implementación de estrategias de transición, ya sea en forma
simulada, implementada en laboratorio o realizada directamente en una red
real, se requiere del estudio previo y completo de los fundamentos del
protocolo IPv6. Esto facilita la comprensión de la documentación disponible
y lleva a la implementación correcta y eficiente del proceso de transición.
La solución más fácil de implementar y más completa es la estrategia de la
doble pila, pues ésta permite que las redes trabajen con ambos protocolos
a la vez. Sin embargo, la implementación completa de éste mecanismo solo
es posible cuando todos los routers de la red poseen la capacidad
necesaria para poder correr una versión del sistema operativo que incluya
el protocolo IPv6. Cuando los routers no pueden implementar IPv6 se debe
recurrir a la utilización de túneles.
Las diversas estrategias de transición implementadas (pila dual y
entunelamiento), de forma individual no proveen una solución completa al
realizar la implantación del protocolo IPv6 en una red que no soporte los
dos protocolos. Por lo tanto, es necesario combinarlas entre sí para lograr
los objetivos en forma más eficiente.
235
La utilización de un tipo particular de túnel dentro de los diversos tipos que
existen, depende en general del tamaño de la red, del número de túneles a
implementar, de si la numeración de la red es fija, de si los nodos que se
van a actualizar al protocolo IPv6 se encuentran detrás de un dispositivos
NAT y del tipo de NAT a ser atravesado.
Algunas estrategias de transición como los túneles automáticos Teredo y
TSP tunnel broker, no pueden ser simuladas ni implementadas en el
laboratorio, por cuanto se requiere de servidores, agentes y repetidores
externos especiales que normalmente no están presentes en un simulador,
sino que se encuentran dispersos en la Internet. En este caso se requiere
de la realización de una implementación en una red real.
236
7. RECOMENDACIONES
Incrementar la presencia de la industria y la comunidad académica
colombiana en proyectos relacionados con IPv6.
Incrementar las actividades de investigación en la comunidad académica.
Incrementar la difusión y formación en IPv6 en la comunidad académica por
medio de capacitaciones tanto teoricas como practicas.
Promover la implementación de redes, sercivios y aplicaciones IPv6 en la
red de la Universidad de San Buenaventura.
Desarrollar futuras investigaciones en torno a protocolos como: IPsec,
MobileIPv6 y QoS (calidad de servicio).
237
ANEXO A
INSTALACION Y CONFIGURACIÓN DE GNS3 EN WINDOWS XP
El primer paso para la instalación es descargar el archivo, GNS3-0.6-win32-all-
inone.exe (ocupa aproximadamente 8MB), que se encuentra en la página web
http://www.gns3.net/download. El archivo anterior contendrá la versión binaria de
los siguientes programas:
Dynamips 0.2.8 – Dynagen 0.11.0: Ambos programas son la base para el
funcionamiento de GNS3.
Pemu 0.2.3: Es un emulador de firewalls PIX de Cisco basado en QEMU que no
es más que una máquina emuladora y virtualizadora de código libre.
WinPcap 4.0.2: Permite la comunicación de redes virtuales con redes reales, ya
que se encarga de detectar las interfaces reales del PC de trabajo para que el
simulador pueda asignarlas como extremo de un enlace hacia un router virtual.
Instalar GNS3
En esta sección, una vez se haya dado doble clic al archivo que acaba de
descargar, los sucesivos cuadros de diálogo lo guiarán durante el proceso de
instalación de forma habitual.
La mayoría de los valores que aparecen por defecto son los que aceptaremos en
la instalación, a no ser que se desee cambiar el directorio donde se instalará el
simulador GNS3.
Los pasos para la instalación son:
238
1) Dar doble clic al archivo de instalación descargado anteriormente. Nos
aparecerá una ventana como la que se muestra en la figura Anexo 1.1. Hacer clic
en “Next”.
2) Aceptar la licencia haciendo clic en el botón “I Agree” como se observa en la
figura Anexo 1.1
Figura Anexo A.1 Proceso de Instalación GNS3
3) Indicar el nombre del directorio de inicio de GNS3. Seguidamente hacer clic en
“Next”. Ver figura Anexo 1.2
4) Aceptar todos los componentes que se instalarán por defecto. Hacer clic en
“Next”. Ver figura Anexo 1.2
Figura Anexo A.2 Proceso de instalación GNS3
239
5) En la figura Anexo 1.3, Indicar la ubicación del directorio donde se instalará al
simulador. Seguidamente hacer clic en “install”.
6) Antes de concluir la instalación de GNS3, aparecerá la ventana que da inicio a
la instalación de WinPcap como se muestra en la figura Anexo 1.3. Hacer clic en
“Next”.
Figura Anexo A.3 Proceso de Instalación GNS3
7) Aceptar la licencia de WinPcap haciendo clic en “I Agree”. Ver figura Anexo 1.3.
8) Después de la instalación de WinPcap, se retomará la instalación de GNS3 y
cuando ésta termine aparecerá una ventana como en la figura Anexo 1.3. Hacer
clic en “Finish” para terminar la instalación.
Figura Anexo A.4 Proceso de Instalación GNS3
240
9) Tras la finalización de la instalación, podemos ejecutar la aplicación desde
“Programas” en el menú de “Inicio” o haciendo doble click en el icono
correspondiente del escritorio, y aparecerá la pantalla de la Figura Anexo 1.4.
Figura Anexo A.5 Ventana de GNS3 en Windows
10) Al momento de ejecutar el programa aparecerá una ventana como la que se
muestra en la figura Anexo 1.5, la cual podemos obviar ya que su función es
reemplazada siguiendo los pasos de los 2 siguientes apartados.
Figura A.6 Complemento de instalación de GNS3
241
Carga de los CISCO IOS
El siguiente paso es la carga de la imagen IOS que usarán los routers virtuales de
nuestra topología, para lo cual realizaremos los siguientes pasos:
1) Ejecutar la aplicación y seleccionar “IOS images and hypervisors” en el menú
Edit, como se muestra en la figura Anexo 1.6
Figura Anexo A.7 Carga de CISCO IOS en GNS3
2) En la ventana que aparece, hacer un clic sobre para buscar la ubicación de
la imagen IOS en el PC. Ver la figura Anexo 1.7
Figura Anexo A.8 Ubicación de CISCO en GNS3
3) Seguidamente elegiremos la plataforma y el modelo que corresponde con la
imagen IOS que usaremos para simular.
242
Figura Anexo A.9 Selección de CISCO en GNS3
4) Finalmente guardamos los cambios haciendo clic en “Save”. Notar que el valor
de IDLE-PC se encuentra vacío por el momento.
Figura Anexo A.10 Almacenamiento de CISCO en GNS3
Comprobar el path hacia Dynamips
Una vez instalado GNS3 es importante comprobar si el simulador ha podido
reconocer de forma eficaz el path donde se encuentra instalado Dynamips para
que pueda usarlo correctamente. Los pasos para realizar esta tarea son los
siguientes:
1) En la aplicación, seleccionar la opción “Preferences” del menú Edit, como se
muestra en la figura Anexo 1.10
243
Figura A.11 Inicio de Comprobación de Path de Dynamips
2) En la ventana que aparece hacer un clic sobre “Dynamips” para obtener la
pestaña donde se muestra la ubicación de Dynamips. Comprobar que el path que
se muestran es correcto haciendo clic en si obtenemos algún error buscar
la verdadera ubicación Dynamips haciendo clic sobre . No olvidar comprobar
que se encuentren habilitadas las funciones de Ghostios, Sparsemem y MMAP.
Figura Anexo A.12 Comprobación de path de Dynamips
3) Hacer clic en “Apply” para guardar los datos.
244
GLOSARIO
IETF (Internet Engineering Task Force): Es una organización internacional
abierta de normalización, que tiene como objetivos el contribuir a la ingeniería
de Internet, actuando en diversas áreas, como transporte, encaminamiento,
seguridad.
LACNIC (Latin American and Caribbean Internet Addresses Center): Es una
organización que administra las Direcciones IP versión 4 y versión 6, Números de
Sistemas Autónomos, DNS Reverso, y otros recursos de red para la región.
IANA (Internet Assigned Numbers Authority): Es la entidad que supervisa la
asignación global de direcciones IP, sistemas autónomos, servidores raíz de
nombres de dominio DNS y otros recursos relativos a los protocolos de Internet.
DUAL-STACK: Estos nodos tienen la habilidad de enviar y recibir paquetes IPv6 e
IPv4.
MPLS (Multiprotocol Label Switching): Es un mecanismo de transporte de datos
estándar creado por la IETF y definido en el RFC 3031. Opera entre la capa de
enlace de datos y la capa de red del modelo OSI. Fue diseñado para unificar el
servicio de transporte de datos para las redes basadas en circuitos y las basadas
en paquetes. Puede ser utilizado para transportar diferentes tipos de tráfico,
incluyendo tráfico de voz y de paquetes IP.
IPSec: Es un conjunto de protocolos cuya función es asegurar las comunicaciones
sobre el Protocolo de Internet (IP) autenticando o cifrando cada paquete IP en un
flujo de datos. IPsec también incluye protocolos para el establecimiento de claves
de cifrado
245
MobileIP: Es un protocolo estándar creado por la Internet Engineering Task Force
(IETF) y diseñado para permitir a los usuarios de dispositivos móviles moverse de
una red a otra manteniendo permanentemente su dirección IP. El protocolo IP
Móvil se describe en la IETF RFC 3344.
6BONE: La red 6bone era una red IPv6 de carácter experimental creada para
ayudar a los vendedores y usuarios a participar en la evolución y transición a IPv6.
Su enfoque original fue la prueba de estándares e implementaciones. Su objetivo
principal era la realización de pruebas de procedimientos inter-operacionales y
transicionales.
BACKBONE: Se refiere a las principales conexiones troncales de Internet. Está
compuesta de un gran número de routers comerciales, gubernamentales,
universitarios y otros de gran capacidad interconectados que llevan los datos a
través de países, continentes y océanos del mundo mediante mangueras de fibra
óptica.
RTP: son las siglas de Real-time Transport Protocol (Protocolo de Transporte de
Tiempo real). Es un protocolo de nivel de sesión utilizado para la transmisión de
información en tiempo real, como por ejemplo audio y vídeo en una video-
conferencia.
TIC: Las tecnologías de la información y la comunicación (TIC o NTIC para
Nuevas Tecnologías de la Información y de la Comunicación o IT para
«Information Technology») agrupan los elementos y las técnicas utilizadas en el
tratamiento y la transmisión de las informaciones, principalmente de informática,
Internet y telecomunicaciones
BNEP: BNEP (Bluetooth Networking Encapsulation Protocol, Protocolo de
Encapsulamiento de Red Bluetooth) es usado para transportar, de manera
246
inalámbrica, paquetes de control y de datos para ofrecer capacidad de
conectividad a redes en dispositivos Bluetooth. BNEP provee capacidades que
son similares a las brindadas por Ethernet (EthernetII/DIX Framing /IEEE 802.3).
ICMPv6 (Internet Control Message Protocol version 6): es una nueva versión
de ICMP y es una parte importante de la arquitectura IPv6 que debe estar
completamente soportada por todas las implementaciones y nodos IPv6.
CIDR (Classless Inter-Domain Routing): Se introdujo en 1993 por IETF y
representa la última mejora en el modo como se interpretan las direcciones IP. Su
introducción permitió una mayor flexibilidad al dividir rangos de direcciones IP en
redes separadas.
DoD (Departament of defence): Es el ministerio del gobierno de Estados
Unidos encargado de las fuerzas militares del país.
TCP/IP (Protocolo de control de Trasmisión/Protocolo de Internet): describe
un conjunto de guías generales de diseño e implementación de protocolos de red
específicos para permitir que una computadora pueda comunicarse en una red.
Host: Un host o anfitrión es un ordenador que funciona como el punto de inicio y
final de las transferencias de datos.
Unicast: Es el envío de información desde un único emisor a un único receptor.
Multicast: Es el envío de la información en una red a múltiples destinos
simultáneamente.
LoopBack: Es una interfaz de red virtual
247
HTTP (Hypertext Transfer Protocol): Es el método más común de intercambio
de información en la world wide web (WWW), el método mediante el cual se
transfieren las páginas web a un ordenador.
NAT (Network Address Traslation): Es un mecanismo utilizado
por enrutadores IP para intercambiar paquetes entre dos redes que se asignan
mutuamente direcciones incompatibles.
IPTV (Internet Protocol Television): Sistemas de distribución por subscripción de
señales de televisión o vídeo usando conexiones de banda ancha sobre
el protocolo IP.
248
BIBLIOGRAFÍA
Migrating to IPv6. A practical Guide to Implementing IPv6 in Mobile and
Fixed Networks. Marc Blanchet. John Wiley & Sons, ltd. 2005. Québec,
Canada.
Handbook of IPv4 to IPv6 transition. Metodologies for institutional and
corporate networks. John J. Amoss & Daniel Minolli. 2008. Auerback
publications. Taylor & Francis Group. Boca Raton, Fl. USA.
Understanding IPv6. Joseph davies. 2008. Microsoft Press. Redmond,
Washington.
Configuring IPv6 for Cisco IOS. Deploy IPv6 on the Cisco IOS. Sam Brown,
Brian Browne, Neal Chen, Paul J. Fong. 2002. Syngress Publishing.
Rockland, MA USA
IPv6 para todos. Guía de uso y aplicación para diversos entornos. Guillermo
Cicileo, Roque Gagliano, otros.2009. Internet society, capítulo Argentina.
Fundamentos de Routing. Eduardo Callado Cabeza. 2009. Formato On-
Line.
Redes Cisco CCNP a Fondo. Guia de estudio para profesionales. Ernesto
Ariganello & Enrique Sevilla Barrietos. 2010. Alfaomega Ra-Ma.
Páginas WEB
Latin American And Caribean Internet Address Registry: http://lacnic.net
Programa de certificación IPv6: http://www.ipv6redy.com
Foro sobre IPv6: http://www.ipv6forum.com
249
Grupo de trabajo y proyecto de IPv6 en la Universidad Nacional Autonoma
de Mexico: http://www.ipv6unam.mx
Internet Engineering Task Force: http://www.ieft.org
Información actualizada sobre RFCs y Draft:
http://wiki-gtipv6.reuna.cl/wiki/index.php/DOCUMENTOS
Graphical Network Simulator: http://www.gns3.net
Proyecto Final de Carrera, Lisset Díaz Cervante:
http://upcommons.upc.edu/pfc/bitstream/2099.1/9989/1/PFC_Lisset_D%C3
%ADaz.pdf
Reporte de estado direcciones IPv4: http://www.potaroo.net/tools/ipv4/
IPv6 Deployment and Support: http://www.6deploy.eu
Apostilla “Curso IPv6 Básico” de NIC.br: http://curso.ipv6.br
The IPv6 Protal: http://www.ipv6tf.org
Compañia de IPv6: http://www.consulintel.es
Soporte técnico de Microsoft sobre IPv6:
http://msdn.microsoft.com/en-us/library/aa450042.aspx
Tunnel Teredo en Linux: http://www.remlab.net/miredo/
Configuración Cisco en IPv4 e IPv6: http://www.cisco.com
CCIE en español: http://ccie-en-espanol.blogspot.com/
Task Force Norte America: http://www.nav6tf.org/
Soporte especifico para IPv6: http://www.6diss.org
Tunel Ipv6 over IPv4: http://wiki.nil.com/IPv6_over_IPv4_tunneling
Task Force Colombia: http://www.co.ipv6tf.org/
The ABC of IP version 6: http://www.cu.ipv6tf.org/pdf/abcipv6.pdf
Transicion de redes:
http://www.6sos.org/pdf/la_transicion_de_las_redes_academicas:rediris_v2.
Servicio de Informacio y soporte IPv6: http://www.6sos.org
IPv6 para España: http://www.consulintel.es/pdf/ipv6_spain.pdf
Top Related