Diseno Simulacion Herramientas Almario 2012

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


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


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.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

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

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

http://cybertesis.uach.cl/tesis/uach/2006/bmfciv473m/doc/bmfciv473m.pdf

http://www.univalle.edu.co/~telecomunicaciones/trabajos_de_grado/anteproyectos/anteproyecto_TG-0417.pdf

http://www.univalle.edu.co/~telecomunicaciones/trabajos_de_grado/anteproyectos/anteproyecto_TG-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


Host 16 384 65 536

C


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


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


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


virtual

WIC-1T 1 puerto serie


3600s NM-1E 1 puerto Ethernet

NM-4E 4 puertos Ethernet

NM-1FE-TX 4 puertos Ethernet

NM-16ESW


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


puertos)

GT96100-FE 2 puertos integrados

NM-NAM


virtual

NM-IDS


virtual

WIC-1T 1 puerto 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


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)#ipv6 route 2001:db8:3::/64 2001:db8:2::2

!Se configura la

ruta y el

siguiente salto


!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 3

146

Router>enable



















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(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(config)#ipv6 router rip RIC

Router(config-rtr)#exit



Router(config-if)#ipv6 rip RIC enable

Router(config-if)#ipv6 address 2001:1:1:1::1/64



Router(config)#interface serial1/0




Router(config-if)#clock rate 64000



152

ROUTER 2

Router>enable




Router(config)#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





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)# clockrate 64000









158








Se deben crear las interfaces loopback necesarias, pues éstas simularán una red

conectada directamente.

R1(config)# interface loopback0






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



159



A continuación se debe asignar las interfaces a las áreas de OSPF.


R1(config-if)# ipv6 ospf 1 area 1

R1(config-if)# interface serial0/0








R2(config-if)# interface fastEthernet 0/0






R3(config-if)# interface fastEthernet 0/0


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)#interface Serial1/0

R1(config-if)# ipv6 enable



R1(config-if)# clock rate 64000







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)# address-family ipv6

R1(config-router)# neighbor FEC0::2:1 activate


R1(config-router)# exit-address-family

171


R1(config-rtr)# router-id 1.1.1.1

Router 2

R2#ipv6 unicast-routing

R2#ipv6 cef

R2(config)#interface Loopback0

















172










Router 3



R3(config)# interface Loopback0



R3(config)# interface Serial1/0










173





R3(config-if)# ipv6 address 2001:DB8:1:1::1/64




R3(config-router)# no bgp default ipv4-unicast


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 2001:DB8:1:1::2 activate


R3(config-router)# neighbor FEC0::1:1 next-hop-self


R3(config-router)# neighbor FEC0::2:1 next-hop-self




174

Router4



R4(config)# interface Loopback2000

R4(config-if)# ipv6 address EFFE:DB8:1:1::1/64



R4(config-if)# ipv6 address 2001:DB8:1:1::2/64






R4(config-router)# no bgp default ipv4-unicast


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)# neighbor 2001:DB8:1:1::1 activate

R4(config-router)# network EFFE:DB8:1:1::/64


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(config)#router rip

Router(config-router)#version 2

Router(config-router)#network 10.0.0.0

Router(config-router)#exit



Router(config)#exit



179

Router(config-if)#duplex auto

Router(config-if)#speed auto






















180

ROUTER 2

Router>enable








Router(config)#exit
















181











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


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


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: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


RL1 ::/0 red IPv6 a través de la interfaz LAN

196


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




198


anuncio vía BGP)

R1 ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual

6to4



C1 ::/0 a través de R1 / 2002:0102:0304:1::/64 a través de la interfaz

LAN


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







anuncio vía BGP)

R1 ::/0 a través del Relay 6to4 RL1 o RL2 utilizando la interfaz virtual

6to4

201




LAN


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(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)#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)#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(config-if)# clock rate 64000








205

ROUTER 3

Router>enable





Router(config-if)# ipv6 address 2001:db8:2::1












Router(config-if)#tunnel mode ipv6ip 6to4


Router(config-if)#ipv6 address 2002:0a02:0202::/128


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(config)# interface fastethernet 0/0













ROUTER 2

Router>enable





214




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)#ipv6 address 3ffe:b00:1:3::/64 eui-64

Router(config-if)#no ipv6 nd suppress-ra


Router(config-if)#tunnel mode ipv6ip isatap


Router(config)#ipv6 route 3ffe:b00:1:3::/64 3ffe:b00:1:2::1



ROUTER 3

Router>enable


215
















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


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(config-if)# ipv6 address 2001:db8:1:1::1/64



Router(config)#interface serial 1/0





227





Router(config-if)#ipv6 address 2001:db8:5:5::1/64


Router(config-if)#tunnel destination 192.0.2.1

Router(config-if)#tunnel mode gre ip



Router(config)#ipv6 route ::/0 2001:db8:5:5::2

ROUTER 2

Router>enable











228







ROUTER 3

Router>enable





Router(config-if)# ipv6 address 2001:db8:2:2::1/64










229



Router(config-if)#ipv6 address 2001:db8:5:5::2/64


Router(config-if)#tunnel destination 192.0.1.1

Router(config-if)#tunnel mode gre ip



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”.


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.


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.

http://www.masadelante.com/faq-www.htm

http://www.masadelante.com/faq-que-necesito.htm

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.

pdf

Servicio de Informacio y soporte IPv6: http://www.6sos.org

IPv6 para España: http://www.consulintel.es/pdf/ipv6_spain.pdf

Diseno Simulacion Herramientas Almario 2012

Documents

Transcript of Diseno Simulacion Herramientas Almario 2012