INSTITUTO POLITÉCNICO NACIONALtesis.ipn.mx/jspui/bitstream/123456789/13174/1/TS IPv6.pdf · 2017-06-12 · Un agradecimiento muy especial a mi mujer, Patricia Polo por apoyarme siempre,

INSTITUTO POLITÉCNICO NACIONAL

ESCUELA SUPERIOR DE INGENIERÍA

MECÁNICA Y ELÉCTRICA

ESTUDIO COMPARATIVO, DE IPv4 e IPv6

T E S I S

PARA OBTENER EL TÍTULO DE

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

P R E S E N T A

HERNÁNDEZ HERNÁNDEZ LUIS ÁNGEL

MUÑOZ IBARRA ERICK RODRIGO

PÉREZ GARFIAS HORACIO

ASESORES:

ING. CRUZ MARTÍNEZ FERNANDO

ING. ROMERO ZUÑIGA MARÍA ISABEL

MÉXICO, D. F. JUNIO 2014

Instituto Politécnico Nacional ESIME

ii

Agradecimientos

Hernández Hernández Luis Ángel.

Me gustaría que estas líneas sirvan para expresar mi más sincero agradecimiento a todas las personas

que estuvieron detrás de todo esto y gracias a su apoyo hoy puedo lograr este objetivo en mi vida

En especial un sincero y profundo agradecimiento a mis padres por haber hecho posible todo esto, ya

que gracias a su apoyo incondicional, comprensión y dedicación a mi persona, han logrado que yo

cumpla este gran logro, uno de los más importantes que tendré en mi vida.

También extiendo un agradecimiento a nuestro asesor el profesor Fernando Cruz Martínez por las

asesorías, enseñanzas y por todo el tiempo que dedicó para la elaboración de este documento y por la

confianza que depositó en nosotros durante todo este tiempo en la elaboración de este proyecto.

Y por último y no menos importante agradezco a mis compañeros de tesis por todo su apoyo y amistad,

ya que significo mucho para lograr esto, espero que todo esto sea el principio de algo mucho mejor en

nuestras vidas social, personal y laboral.

A todos muchas Gracias.

Muñoz Ibarra Erick Rodrigo.

Agradezco a mis padres David Muñoz y Sofía Ibarra, por haberme dado la vida, por su apoyo en todo

sentido, por el gran esfuerzo y los sacrificios que hacían día con día para que yo tuviera la oportunidad

de llegar hasta donde estoy.

Un agradecimiento muy especial a mi mujer, Patricia Polo por apoyarme siempre, por todos sus

consejos, por acompañarme en esas desveladas de estudio, por estar conmigo a pesar de las

adversidades y sobre todo por darme a mi hija Briseida que es la alegría de mi vida.

A todos mis amigos por su compañía y los buenos momentos que pasamos juntos, en especial a los

que participaron en la elaboración de este proyecto.


iii

Dedicatoria

Dedico el presente trabajo a mi preciosa hija Briseida, quien es mi inspiración y mi fortaleza, una

sonrisa suya ilumina mi mundo y me da las fuerzas necesarias para luchar y conseguir mis metas,

siempre serás el motor que me impulse a seguir adelante.

Pérez Garfias Horacio.

Quiero agradecer y dedicarles profundamente éste logro a mis padres, Georgina Garfias y Horacio

Pérez, ya que sin ellos no hubiera sido posible que lo obtuviera, gracias por todo su apoyo y paciencia

hacia mí, que en algún momento fue difícil para ustedes poder lidiar con mi rebeldía pero lograron

hacerme entender el valor de estudio. Gracias por todo, los amo mucho!

A mis hermanos Georgina y Ricardo, por apoyarme en las situaciones malas y buenas pero sobre todo

por no dejarme caer es esos momentos tan difíciles de nuestras vidas, muchas gracias y los quiero

muchísimo!

A toda la familia, Garfias y Sánchez, a mis abuelos, tíos, primos y sobrinos que pertenecen a esta

increíble familia por recibir su gran apoyo, ánimos y consejos, no quisiera dejar a nadie fuera pero

somos muchísimos!

A mis compañeros de tesis, ya que fue muy difícil el camino para llegar pero al fin lo logramos, gracias

por todo chavos y espero que la amistad perdure por siempre.

A nuestro asesor de tesis, Fernando, por la paciencia y confianza que nos otorgó en las difíciles

situaciones por las que pasamos para terminar este gran logro. Gracias por su apoyo Ingeniero.

Y un agradecimiento muy especial hacia mi padre Horacio, que gracias a sus enseñanzas tengo la

posibilidad de competir en un mundo diferente, superarme a mí mismo y saber que lo puedo lograr.

Gracias por tu amor, cariño, valores, tiempo, consejos, regaños, gracias por ser mi papá. En donde

quieres que estés, este logro va por ti. Te amo. GRACIAS POR SIEMPRE.


iv

Índice

Introducción

Capítulo 1. Antecedentes………………………………………………………………………… 10

1.1 El Agotamiento de las direcciones IPv4………………………………………………………. 12

1.2 Situación actual global de IPv6……………………………………………………………...... 15

1.3 Situación en Latino América………………………………………………………………….. 23

1.4 Situación en México…………………………………………………………………………… 27

1.5 Características de IPv6 y mejoras respecto a IPv4…………………………………………..... 30

1.6 Consecuencias al no desplegar IPv6…………………………………………………………… 34

Capítulo 2 Marco teórico, detalles técnicos de IPv6…………………………………………… 35

2.1 Encabezado del paquete IPv6………………………………………………………………..... 35

2.2 Direccionamiento IPv6………………………………………………………………………… 40

2.2.1 Prefijo de direcciones IPv6…………………………………………………………. 40

2.2.2 Tipos de direcciones en IPv6……………………………………………………….. 42

2.2.2.1 Direcciones Unicast………………………………………………………. 43

2.2.2.2 Direcciones Multicast…………………………………………………….. 47

2.2.2.3 Direcciones Anycast……………………………………………………… 50

2.2.3 Subnetting en IPv6………………………………………………………………….. 51

2.3 Mecanismos para asignar direccionamiento IPv6 en hosts……………………………………. 56

2.3.1 Autoconfiguración sin estado……………………………………………………….. 56

2.3.2 DHCP sin estado (Stateless)………………………………………………………… 60

2.3.3 DHCP con estado (Stateful)…………………………………………………………. 60

2.4 Enrutamiento IPv6……………………………………………………………………………... 61

2.4.1 Enrutamiento estático IPv6 ……………………………………………………......... 61

2.4.2 Enrutamiento dinámico IPv6………………………………………………………... 62

2.4.2.1 Routing Information Protocol Next Generation (RIPng)…………………. 63

2.4.2.2 Open Shortest Path First para IPv6 (OSPFv3)…………………………….. 64

2.4.2.3 Integrated System to Integrated System (IS-IS) ………………………….. 65

2.4.2.4 Border Gateway Protocol para IPv6 (BGPv6)…………………………….. 65

2.5 Mecanismos de transición……………………………………………………………………… 66


v

2.5.1 Doble Pila…………………………………………………………………………… 66

2.5.2 Túneles………………………………………………………………………………. 68

2.5.3 Traducción…………………………………………………………………………... 74

Capítulo 3. Diseño de una red de área local con direccionamiento IPv6……………………… 75

3.1 Topología física………………………………………………………………………………... 75

3.2 Topología Lógica…………………………………………………………………………….... 78

3.2.1 Direccionamiento IPv4…………………………………………………………….. 78

3.2.2 Direccionamiento IPv6…………………………………………………………....... 82

3.2.2.1 Implementación de direccionamiento IPv6 en dispositivos intermediarios.. 83

3.2.2.2 Implementación de direccionamiento IPv6 en dispositivos finales…........... 84

3.2.2.3 Enrutamiento IPv6……………………………………………………......... 84

Capítulo 4 Simulación de la red………………………………………………………………... 87

4.1 Configuración de la red……………………………………………………………………….. 87

4.1.1 Configuración del equipo principal (Core)…………………………………………. 87

4.1.2 Configuración de equipos de distribución (Edificios)……………………………… 89

4.1.3 Configuración de los equipos de acceso (Host)…………………………………….. 92

4.1.4 Configuración de Hosts…………………………………………………………....... 95

4.2 Configuración de servicios en la red…………………………………………………………... 97

4.2.1 Servidor DNS………………………………………………………………………... 97

4.2.2 Servidor de MAIL…………………………………………………………………… 99

4.3 Verificación de conectividad…………………………………………………………………... 102

4.4 Detección y Solución de errores……………………………………………………………….. 105

4.5 Memoria Técnica………………………………………………………………………………. 105

Conclusiones………………………………………………………………………………………

108

Bibliografía………………………………………………………………………………………..

109

Anexos…………………………………………………………………………………………….

110

Glosario……………………………………………………………………………………………

120


vi

Objetivo

Desarrollar por medio de un simulador las características de redes con direccionamiento IPv4 e IPv6,

mostrando las ventajas que se tienen con IPv6, en capacidad de direccionamiento en redes.


vii

Justificación

La disponibilidad de direcciones IPv4 está agotándose, en Febrero del 2011 la IANA agotó su rango de

direcciones IPv4 disponibles para la asignación a Registros Regionales de Internet (RIRs), y en los

siguientes meses se espera el agotamiento de direcciones dentro de los RIRs con mayor demanda, por

lo cual el único protocolo que podría ser asignado en el futuro serán rangos de direcciones IPv6, y las

instituciones que ya lo manejen y que tengan una red IPv6 en funcionamiento, así como aplicaciones

ya trabajando en este protocolo tendrán una ventaja competitiva. En el futuro próximo el tener una red

IPv6 dejará de ser una ventaja y se convertirá en un requisito para poder competir en el mercado. Por

tal motivo se tiene la necesidad de estudiar, fomentar y practicar con el nuevo protocolo de Internet,

para empezar a desarrollar nuevos proyectos que impulsen la innovación de la red.


viii

Introducción

IPv6 ha sido el nombre con el que se ha bautizado a la nueva versión del protocolo Internet (IP). Se

trata de la definición de un nuevo protocolo de red destinado a sustituir a la actual versión IP, la cuatro.

¿Por qué se necesita un nuevo protocolo de red? La respuesta es muy simple, cuando IPv4 fue

estandarizado, hace unos quince años, nadie podía imaginar que se convertiría en lo que es hoy: una

arquitectura de amplitud mundial, con un número de usuarios superior al centenar de millones y que

crece de forma exponencial.

Aquella primera Internet fundada, sobre todo, con fines experimentales, científicos, técnicos y, por

supuesto, con objetivos militares, no se parece en nada a la actual. El interés de hacer esta transición es

el simple hecho que en el mundo ya no hay más direcciones IPv4 disponibles, causando un

estancamiento en la expansión e innovación de la red de internet, con el protocolo IPv6 se busca

ampliar la red pero sobre todo mejorar la calidad.

Esta nueva versión del Protocolo de internet sustituirá progresivamente a IPv4, ya que brinda mejores

características, entre las que destacan: espacio de direcciones prácticamente infinito, posibilidad de

autoconfiguración de hosts, eficaz soporte para seguridad, computación móvil, calidad de servicio,

transporte de tráfico multimedia en tiempo real y aplicaciones Anycast y Multicast y por supuesto la

posibilidad de transición gradual de IPv4 a IPv6, etc.

El presente trabajo describe de forma técnica y detallada el protocolo IPv6 y brinda los elementos

necesarios para implantar una red con el nuevo protocolo sin tener que dejar a un lado a su antecesor

IPv4, puesto que hay que mantener todas las infraestructuras que actualmente funcionan con este.

El objetivo principal de este proyecto es implantar una red utilizando los protocolos IPv4 e IPv6 en una

misma red, llamada “Red de doble pila”, así como mostrar el uso de un túnel para hacer una transición

de IPv4 a IPv6.

En el marco teórico se explica la historia que ha tenido el protocolo IP en las redes, también se

considera una reseña de la pila de protocolos TCP/IP para conocer más sobre su desarrollo y su modelo

a capas, abarca información estadística acerca del despliegue que ha tenido IPv6 en el mundo desde sus

inicios hasta la actualidad y se describen las principales mejoras respecto a IPv4.

El capítulo dos se profundiza la información técnica sobre el protocolo IPv6, explicando la forma en la

cual trabaja, se describen los campos del encabezado, la estructura y los tipos de direcciones que

maneja y las diferentes opciones para lograr una transición a IPv6.


ix

En el capítulo tres se realiza una propuesta de una red, tomando como base el modelo de diseño de

redes en capas de Cisco, que igual es recomendado por muchos otros fabricantes. Se propone el

direccionamiento IPv6 de la red y se eligen dispositivos de redes genéricos que cumplan ciertas

características para ser integrados en cada punto de la red jerárquica propuesta.

En el capítulo 4 se muestra la simulación de la red de doble pila, mostrando los procesos de

configuración de cada equipo como de las aplicaciones, además de resaltar la conexión entre nodos, y

finalmente distintos consejos para administrar este tipo de LAN para evitar fallos.


10

Capítulo 1. Antecedentes

Internet está basado en un conjunto de protocolos de red que permite la transmisión de datos entre

computadoras. Este conjunto de protocolos está definido en el modelo TCP/IP, en referencia a los dos

protocolos más importantes que la componen: Protocolo de Control de Transmisión (TCP) y Protocolo

de Internet (IP), que fueron dos de los primeros en definirse, y que son los más utilizados de la familia.

Existen tantos protocolos en este conjunto que llegan a ser más de 1000 diferentes, entre ellos se

encuentra el popular HTTP (HyperText Transfer Protocol ), que es el que se utiliza para acceder a las

páginas web, además de otros como el ARP (Address Resolution Protocol) para la resolución de

direcciones, el FTP (File Transfer Protocol) para transferencia de archivos, y el SMTP (Simple Mail

Transfer Protocol) y el POP (Post Office Protocol) para correo electrónico, TELNET para acceder a

equipos remotos, entre otros.

Este documento se centra únicamente en el Protocolo de Internet (Internet Protocol, IP), su función

principal es el direccionamiento lógico de cada equipo conectado a la red y establecer la conectividad

bidireccional entre origen y destino en una comunicación. (Para más información acerca del

funcionamiento de Internet y los modelos de red, ver anexo 1).

Desde sus inicios, Internet está basado en la versión 4 de dicho protocolo “IPv4”. Este protocolo se

diseñó prácticamente como un experimento sin pensar en un despliegue ni siquiera cercano al actual,

utilizando direcciones de 32 bits, con lo cual permite direccionar de forma única un máximo de 232

dispositivos.

Una gran parte de este espacio de direcciones está destinado por El Grupo de Trabajo de ingeniería en

Internet (Internet Engineering Task Force, IETF, la organización responsable de la estandarización de

los protocolos de Internet), para diversos servicios, como funciones de la red (Multicast o

Multidifusión) y direcciones privadas (validas solo en el interior de las redes, pero no en internet y que

pueden ser utilizadas repetidamente por múltiples organizaciones).

En 1992, IETF se percató de la necesidad de ampliar el número de direcciones IPv4, teniendo en

cuenta el inesperado crecimiento de internet, dado que el número de direcciones disponibles no

permitían siquiera una única dirección para cada habitante del planeta de aquel momento, y mucho

menos direccionar varios dispositivos por cada uno de nosotros.


11

Para Diciembre de 1998 el IETF público su RFC1 2460 “Internet Protocol, Version 6 IPv6

Specification”, y tiempo después a Autoridad para la asignación de números de Internet (Internet

Assigned Numbers Authority, IANA) anuncio el agotamiento de direcciones IPv4 e insistió a los

usuarios a realizar una transición de IPv4 por la versión más reciente de IP en su versión 6 conocida

también como Internet de nueva generación.

Desde esa fecha no se ha conseguido en estos quince años un despliegue realmente masivo de IPv6,

pese a los grandes avances que se han logrado en tecnología de telecomunicaciones tales como la

masificación de los medios inalámbricos y los equipos móviles, aunado al descenso de los precios de

dispositivos de conexión y el aumento del rendimiento de microchips, lo cual hecho que sea totalmente

factible implementar nuevos y mejores protocolos de comunicaciones como es el caso de IPv6.

Como solución inmediata y transitoria para permitir el continuo crecimiento de Internet, se crea el

mecanismo NAT (Network Address Translation o Traducción de Direcciones de Red) que en definitiva

permite que cada red conectada a Internet bien sea un usuario residencial o una organización de

cualquier tipo, utilice una única dirección IPv4 pública en su punto de conexión a Internet y un número

determinado y limitado de direcciones privadas en la parte interna de dicha red. Para ello es necesario

realizar una traducción de esas múltiples direcciones internas a la única dirección IPv4 pública

disponible, lo que conlleva a la pérdida del paquete básico de Internet, la conectividad extremo-a-

extremo, con grandes consecuencias para el desarrollo de la red.

La idea de seguir utilizando NAT como único mecanismo ante el agotamiento de direcciones IPv4 se

ha ido desvaneciendo, en la medida que se ha ido viendo la enorme cantidad de dispositivos que

necesitarán, en mediano plazo, sus propias direcciones IP para conectarse a Internet. Aún en el caso de

una utilización más óptima de las direcciones IPv4, las más de 4 mil millones de direcciones que el

protocolo IPv4 permite, no serán suficientes. NAT ha permitido, hasta el momento el crecimiento de

Internet, pero conlleva la pérdida de conectividad extremo-a-extremo (cliente a cliente), haciendo más

complejo y costoso el desarrollo de dichos servicios y aplicaciones y por tanto impidiendo la

innovación en la Red. Internet ya no solo se trata de conectar algunas computadoras, sino cientos,

miles o millones de aparatos de todo tipo, incluso no manejados por personas, sino por otras máquinas.

El nuevo protocolo IPv6 utiliza direcciones de 128 bits diferencia de 32 que emplea IPv4, y por tanto

permite un total de 2128direcciones únicas, aproximadamente 340 billones de billones de billones

(sextillones) de direcciones, lo que hace que la cantidad de direcciones de IPv4 parezca insignificante.

1Los RFC (Request For Coments o Peticiones de comentarios) son documentos de especificación muy detallada y sin ambigüedades de protocolos, procedimientos y/o ev entos definidos para Internet y publicados por el IETF.


12

Con este mayor espacio de direcciones se restablece el paradigma de la conectividad extremo-a-

extremo y al mismo tiempo ofrece una variedad de ventajas en términos de estabilidad, flexibilidad y

simplicidad en la administración de las redes. También es probable que la era IPv6 genere una nueva

ola de innovación en las aplicaciones y las ofertas de servicios ya que, termina con la necesidad de

direcciones compartidas.

IPv6 se está implementando lentamente en redes y coexistirá con IPv4 por muchos años en esta

transición. Si bien el trabajo técnico relacionado con el protocolo, en gran medida se ha completado, lo

que resta mayoritariamente en el despliegue en las redes de los proveedores de servicios de internet

(ISPs).

1.1 El Agotamiento de las direcciones IPv4

En los inicios de Internet, se utilizaron métodos de distribución poco eficientes, como la asignación por

clases, mediante los cuales se asignaron grandes bloques de direcciones a cualquier persona o entidad

que las solicitaba sin mayores justificaciones, esto ha generado que actualmente muchas

organizaciones posean un gran número de direcciones que no se encuentran utilizadas.

En recientes años, la distribución del espacio de direcciones IP se mejoró y sigue el esquema jerárquico

descrito en el RFC 2050. La responsabilidad de la administración del espacio de direcciones de IP está

distribuida globalmente de acuerdo con la estructura jerárquica que se muestra en la Figura 1.1.

Figura 1.1. Estructura jerárquica para la asignación de direccionamiento IP


13

Registro de Internet Regional (RIR)

Los Registros Regionales de Internet (RIRs) son establecidos y autorizados por las comunidades

regionales respectivas, y reconocidos por el IANA para servir y representar grandes regiones

geográficas. El rol principal de los RIRs es administrar y distribuir los recursos de Internet dentro de

las respectivas regiones. Existen cinco RIRs los cuales son:

ARIN: American Registry for Internet Numbers, para Norte América.

RIPE NCC: Réseaux IP Europens Network Cordination Centre, para Europa, Medio Oriente y

Asia Central.

APNIC:Asia-Pacific Network Information Centre, para Asia y la Región del Pacifico.

LACNIC: Latin American and Caribbean Network Information Centre, para América Latina

y el Caribe.

AfriNIC: African Network Information Centre, para África.

Registro de Internet Nacional (NIR)

Un Registro de Internet Nacional (NIR) distribuye, principalmente, los recursos de Internet a sus

miembros o constituyentes, los cuáles generalmente son LIRs

Registro de Internet Local (LIR)

Registro de Internet Local (LIR) es un IR que a su vez asigna recursos de Internet a usuarios de los

servicios de red que éste provee. Los LIRs son generalmente ISPs, cuyos clientes son principalmente

usuarios finales y posiblemente otros ISPs.

Proveedor de Servicios de Internet (ISP)

Un Proveedor de Servicios de Internet asigna principalmente espacio de direcciones IP a los usuarios

finales de los servicios de red que éste provee. Sus clientes pueden ser otros ISPs. Los ISPs no tienen

restricciones geográficas como lo tienen los NIRs.

Sitio Final o Usuario Final (EU)

Un sitio final es definido como un usuario final (suscriptor) que tiene una relación de negocios o legal

(misma o entidades asociadas) con un proveedor de servicios Internet que involucra:

Al proveedor de servicios asignando un espacio de direcciones al usuario final


14

Al proveedor de servicios otorgando un servicio de tránsito para el usuario final hacia

otros sitios

Al proveedor de servicios transportando el tráfico del usuario final

Al proveedor de servicios anunciando un prefijo de ruta agregado que contiene el rango

asignado por LACNIC al usuario final

En el RFC 2050 se decide que las direcciones sean repartidas en bloques de 8 bits (los 8 bits

superiores de las direcciones IPv4 y permiten 2(32-8) =16777216 direcciones), transferidos a cada uno

de los RIRs, desde el almacenamiento central en IANA, para la gestión regional, según se vallan

agotando los recursos de cada una de dichas regiones. Estos bloques, siguiendo la nomenclatura

técnica, se denominan prefijos /8, y utilizables en internet existen 220.

Figura 1.2 Distribución Geográfica de los RIRs

Para el 31 de Enero de 2011 IANA asignó a APNIC los dos últimos bloques de direcciones IP v4 que

aún permanecían disponibles. Tras esta última entrega, IANA ha activado el protocolo que otorga a

cada registro regional uno de los cinco bloques finales reservados para la "fase de agotamiento", en

esta fase se le asigna automáticamente a cada uno de los cinco registros regionales, uno de los últimos

cinco bloques reservados especialmente. A partir de ese momento los registros regionales ya no pueden

solicitar nuevas direcciones IPv4.

Los siguientes en agotar sus reservas serán ARIN y RIPE. Durante algo más de tiempo tendrán

direcciones IPv4, AfriNIC y LACNIC, principalmente por el menor ritmo con el que consumen sus

propias reservas.


15

La figura 1.2 muestra la repartición total de los 256 bloques /8 de direcciones IPv4 que existen, notara

que existen muchos bloques “Legacy”, esto se debe a que fueron asignados en los primeros años de

Internet cuando se manejaba el modelo “Con Clase” (Classful) en el que asignaron amplios bloques a

empresas individuales y otras organizaciones sin pedir justificación de su uso y al pasar al modelo

“Sin Clase” (ClassLess) quedaron desperdiciados o de difícil asignación.

Figura 1.3 Repartición total de bloques IPv4

1.2 Situación actual global de IPv6

El despliegue real de IPv6 se inició en el año 2002, momento en el cual ya se podía considerar

estandarizado en los aspectos básicos que prácticamente lo equiparaban 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.

La situación actual es que el 99% de los grandes ISPs (los denominados Tier 12) ofrecen IPv6, muchos

de ellos desde hace varios años, en sus redes intercontinentales y en muchos casos regionales, mientras

2 Un ISP nivel 1 o Tier 1 se caracterizan por que tienen cobertura internacional, son capaces de transmitir una cantidad muy elevada de datos, están conectados directamente a otros Tier 1 y conectan un gran número de ISPs de niv el 2, ejemplos de estos son: AOL, AT&T, Verizon Busisness, NTT, Sprint, Telefónica Global Solutions.


16

que solo algunos proveedores de Internet nacionales proporcionan el servicio IPv6, y cuando lo hacen,

muy pocos lo ofrecen en la última milla3, salvo para clientes corporativos.

Esto es debido a que fundamentalmente los CPEs (Customer Premises Equipment), enrutador situado

en las instalaciones del cliente, han sido los equipos con mayor demora en su introducción comercial, y

especialmente los de gama baja, los que habitualmente suministran los ISP a los clientes residenciales.

Esta situación ha cambiado radicalmente en los últimos años.

Hoy en día, la mayoría de las instituciones ya sean gubernamentales, de comercio, educación y

proveedores de servicio en todo el mundo tienen sus redes preparadas para la transición pero hace falta

la planeación y capacitación de la parte técnica para atreverse a realizar el despliegue del nuevo

protocolo. Los RIRs tienen cada vez más solicitudes de bloques IPv6 pero los ISPs tienen un lento

avance en este ámbito ya que es tarea de estos ofrecer conectividad IPv6 en la última milla para los

usuarios residenciales y así masificar el uso de este protocolo.

La repartición de direcciones IPv6 también está regida por las indicaciones del IETF, en este caso,

IANA entregó a los RIRs bloques para su distribución a los ISPs de la región, la última entrega de un

bloque /12 para cada RIR se produjo en 2006 como se muestra en la figura 1.4 y se espera que esta

entrega sea suficiente para muchos años, se puede notar IANA aún se tiene reservado la mayoría de

espacio de direccionamiento IPv6 para futuros requerimientos.

Figura 1.4 Distribución actual de bloques IPv6

3La última milla es definida en las telecomunicaciones como el tramo final de una línea de comunicación, ya sea telefónica o un cable óptico, que da el serv icio al usuario


17

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

finales, con un bloque /32, un ISP puede direccionar aproximadamente 65,535 clientes otorgándoles

subredes de prefijo /48, con un /31 el doble de clientes y así sucesivamente. Para facilitar la

uniformidad de las estadísticas, estas se realizan utilizando como base bloques /32.

En las siguientes imágenes se muestran datos estadísticos obtenidos en el año 2013 del despliegue de

IPv6 en el mundo.

La figura 1.5 muestra una gráfica que indica la distribución de la cantidad de bloques IPv6 expresados

en prefijos /32 ya asignados por la IANA a los RIRs. Se observa que las regiones de Europa

(RIPENCC) y Asia (APNIC) son las que más asignaciones de direcciones IPv6 han tenido, (gráfica

actualizada hasta el 25 de Enero de 2014).

Figura 1.5 Distribución de asignaciones de bloques IPv6 de IANA a los RIRs


18

La figura 1.6 muestra la gráfica de la cantidad de asignaciones IPv6 que han realizado los RIRs a los

LIRs e ISPs por año. Se observa que la verdadera demanda por direcciones IPv6 empieza desde el año

2008 y se incrementa considerablemente en los años 2011,2012 y 2013, siendo la región de Europa

quien lleva la ventaja en asignación de bloques IPv6.4

Figura 1.6 Distribución de asignaciones de bloques IPv6 de los RIRa los LIRs e ISPs por año

La figura 1.7 muestra la cantidad de asignaciones IPv6 totales hechas por cada RIR desde Junio de

1999 hasta Septiembre de 2013, se observa que la región de Europa es la que más asignaciones de

bloques IPv6 ha hecho a sus ISPs, seguida por la región de Asia.

Figura 1.7 Distribución total de asignaciones de bloques IPv6 de los RIRs

4Datos estadísticos tomados del reporte de recursos numéricos de internet de la Asociación de Recursos Numéricos NRO (Numer Resource Organization)


19

La figura 1.8 muestra la gráfica de cuantas asignaciones IPv6 han sido realizadas por los RIRs a

usuarios finales por año, como se había mencionado antes, los RIR no solo brindan direccionamiento

IP a los ISPs, sino también asignan bloques a usuarios finales siempre y cuando estos cumplan ciertos

requerimientos, en esta gráfica se observa que en la región de Norteámerica, los usuarios finales son

pioneros en solicitar bloques de direcciones IPv6 a ARIN.

Figura 1.8 Distribución de asignaciones de bloques IPv6 de los RIRs a usuarios finales por año

La figura 1.9 muestra la cantidad de asignaciones IPv6 totales hechas por cada RIR a usuarios finales

desde Junio de 1999 hasta Septiembre de 2013, en esta gráfica se observa que usuarios finales en la

región de Nortámerica tienen la mayor cantidad de asignaciones IPv6 comparado con las demás

regiones.

Figura 1.9 Distribución de asignaciones de bloques IPv6 de los RIRs a usuarios finales


20

Prefijos IPv6 Asignados Prefijos IPv6 Anunciados

La figura 1.10 muestra el porcentaje de miembros con ambos IPv4 e IPv6 en cada RIR, el caso ideal de

esta gráfica sería que el 100% de los miembros tuvieran, tanto asignaciones IPv4 como IPv6 lo que

haría la transición más fácil.

Figura 1.10 Porcentaje de miembros con asignaciones IPv4 e IPv6

La figura 1.11 muestra los países con mayor número de asignaciones de bloques IPv6 (actualizado al

25 de Enero de 2014), se observan dos columnas, la primera muestra la cantidad de bloques asignados

y la segunda muestra cuántas de estas asignaciones están anunciadas en Internet, por ejemplo Estados

Unidos tiene un total de 3452 asignaciones de las cuales solo 4833 están anunciados en Internet.

Figura 1.11 Países con mayor cantidad de asignaciones IPv6


21

La figura 1.12 muestra el porcentaje de usuarios que accede a Google a través de IPv6, se observa que

casi el 3% de peticiones que llegan a Google son a través de IPv6 y la tendencia de tráfico del nuevo

protocolo va en aumento de manera considerable.

Figura 1.12 Porcentaje de peticiones a Google desde IPv6 vs IPv4

La figura 1.13 muestra los diez principales operadores de red que ya ofrecen conectividad a través de

IPv6 y en qué porcentaje de sus redes está desplegado, actualizado al 16 de Enero de 20145

Figura 1.13 principales operadores de red en el mundo con despliegue IPv6

5 Información estadística extraída del sitio World IPv6 Launch www.worldipv6launch.org/measurements.


22

La figura 1.14 muestra el porcentaje de páginas de internet alcanzables con IPv6 según el “Top 1000

“Websites” de Alexa, es decir, que sitios Web ya están listos para recibir peticiones desde redes IPv6

(actualizado al 24 de Enero de 2014), se observa que solo el 13.10% de los sitios soportan el nuevo

protocolo.

Figura 1.14 principales páginas de Internet alcanzables con IPv6

En general, los hechos más relevantes respecto al despliegue de IPv6 en el mundo sucedieron en 2011,

las siguientes líneas describen lo que sucedió en ese año.

En febrero, la Internet Assigned Numbers Authority entregó los últimos bloques de espacio de

direcciones IPv4 a los registros de Internet regionales.

En marzo, Microsoft destinó 7,5 millones de dólares a la compra de alrededor de 600,000

direcciones IPv4 de Nortel, tras la suspensión de pagos y el desguace de esta compañía.

En abril, el registro regional de Asia, APNIC, agota prácticamente todas las direcciones IPv4

que tenía en reserva para operadores de redes de nueva creación. En ese mismo mes el Consejo

de Ministros de España aprueba un plan para fomentar la implantación del protocolo IPv6 en

ese país, tanto a nivel público como en el sector privado. Se decidió que el Ministerio de

Industria sea la primera administración española en la que se realice la migración.

En junio, más de mil Websites, incluidos los de Google, Yahoo y Facebook y los de

operadores como Telefónica, participaron en un exitoso ensayo de 24 horas sobre IPv6

llamado World IPv6 Day.

En diciembre, Google publicó el plan de migración a IPv6 puesto en marcha por la compañía

para adaptar al nuevo IP toda su red interna.


23

Durante todo el segundo semestre de 2011 se sucedieron anuncios de los fabricantes de

equipos de redes sobre sus planes de actualización y el lanzamiento de servicios para ayudar a

sus clientes a afrontar la migración. Igualmente los operadores dieron a conocer sus proyectos

de actualización.

1.3 Situación en Latino América

El año 2012 fue un año muy importante en relación con el despliegue de IPv6 en América Latina y el

Caribe. Es así que en ese año la cantidad de miembros en LACNIC con asignaciones de IPv6 más que

duplicó a la cantidad con que finalizó el año 2011, siendo que entonces se contaba con un 24,73% de

los asociados con IPv6 y en el 2012 este indicador alcanzó el 51,92% de la membresía. No solo se

duplicó la cantidad de asociados con IPv6, sino que también más de la mitad de los asociados de

LACNIC cuentan ahora con asignaciones de bloques IPv6.6

La distribución de recursos IPv6 realizadas en el año 2012 fue liderada por Brasil con un 56.23%,

seguido por Argentina con un 13%.(figura 1.15).

Figura 1.15 Asignaciones de IPv6 por país realizadas en 2012

Sin embargo cuando se expresa estas cifras en equivalente a cantidad de /32 asignados en la región, la

gráfica cambia siendo Argentina quien ocupa el primer lugar con 69,8% desplazando a Brasil al

segundo lugar con un 14,6%, seguido por México y Venezuela juntos en el tercer lugar con un 5%

(figura 1.16) .Esto se debe a que puntualmente en Argentina se han realizado asignaciones mayores a

/32 durante este año.

6Datos estadísticos tomados del reporte anual 2012 de LACNIC


24

En el 2012 se asignaron 4.606/32 mientras que en el 2011 se asignaron 967/32.

Figura 1.16 Distribución de asignaciones IPv6 medidas en /32

La gráfica siguiente muestra la evolución de la asignación de todos los recursos (IPv4, IPv6, ASN) por

año.

Figura 1.17 Evolución de las asignaciones de todos los recursos. (IPv4, IPv6, ASN)

En números totales, el crecimiento de la asignación de recursos en 2012 en comparación con el año

anterior es como sigue:

60,77% para asignaciones de ASNs,7

9,97% para asignaciones de bloques de direcciones IPv4 y

24,30% para asignaciones de bloques de direcciones IPv6.

7 Un ASN (Autonomous System Number), es un numero asociado a un grupo de redes de direcciones IP que son gestionadas por uno o más operadores de red que poseen una clara y sola política de ruteo.


25

Las asignaciones de IPv4 crecieron cerca de un 10% con relación al 2011, lo que pudiera indicar una

pequeña aceleración en la terminación de la reserva de IPv4 de LACNIC prevista para mediados del

2014.

Figura 1.18 Asignaciones IPv4 2011 vs. 2012

El trabajo de LACNIC en la promoción de la adopción de IPv6 en la región, ya sea a través de talleres

para técnicos y tomadores de decisiones como a través de la difusión de materiales y la sensibilización

sobre la importancia del tema, se visualiza en el gran crecimiento de asignaciones IPv6 (figura 1.19).

Figura 1.19 Cantidad de asignaciones IPv6 por años

En el mes de octubre del año 2013, América Latina y el Caribe alcanzaron las 2,00 asignaciones de

bloques IPv6, Brasil lidera el ranking de los países con mayor cantidad de asignaciones, seguida de

Argentina, Colombia, México, Chile, Costa Rica, Ecuador, en ese orden, según los registros técnicos

de LACNIC.


26

Finalmente, LACNIC en su sitio Web, nos ofrece las estadísticas con actualizaciones diarias de la

cantidad de asignaciones IPv6.

La gráfica de la figura 1.20 muestra la asignación de bloques IPv6 hechas por LACNIC desde el año

2010 hasta el 26 de Enero de 2014.

Figura 1.20 Asignación de Bloques IPv6 hasta el 26 de Enero de 2014

La gráfica de la figura 1.21 muestra la distribución de asignaciones IPv6 hechas por LACNIC a los

distintos países de Latino América y Caribe. Se puede observar que hasta la fecha van 6681 bloques

repartidos expresados en /32.

Figura 1.21 Distribución de asignaciones por país hasta el 26 de Enero de 2014


27

1.4 Situación en México

Según las estadísticas mostradas en el sitio Web de Erick Vynke, un ingeniero de Cisco, México tiene

tan solo 70 asignaciones IPv6, las cuales se muestran en la tabla 1.1 y se lee de la siguiente forma.

Tabla 1.1. Asignaciones IPv6 en México

Descripcion Color Contador, Porcentaje

Prefijo No anunciado en las tablas BGP RED 53, (39.6 %)

Prefijo Anunciado en las tablas BGP pero bajo un prefijo

agregado con el de un ISP.ORANGE 12, (9 %)

Prefijo Anunciado en las tablas BGP GREEN 69, (51.5 %)

Trafico de este prefijo Ha sido v isto en Internet 11, (8.2 %)

Prefix DescriptionFirst/Last

announcement

2001:448::/32 Universidad Nacional Autonoma de Mexico, UNAM 08/06/2003

2001:1200::/32 Protel I-Next, S.A. de C.V. 03/05/2003

2001:1208::/32 Uninet S.A. de C.V. 08/06/2003

2001:1210::/32 Universidad de Guadalajara 06/10/2004

2001:1218::/32 Universidad Nacional Autonoma de Mexico 17/12/2005

2001:1220::/32 Instituto Tecnológico y de Estudios Superiores de Monterrey

2001:1228::/32 Corporación Universitaria para el Desarrollo de Internet A.C. 21/06/2006

2001:122c::/32 Corporación Universitaria para el Desarrollo de Internet A.C.

2001:1230::/32 Fondo de Informacion y Documentacion para la Industria INFOTEC 21/07/2012

2001:1238::/32 Maxcom Telecomunicaciones, S.A.B. de C.V. 01/11/2011

2001:1240::/32 Micronet de Mexico, S.A. de C.V. 28/10/2010

2001:1248::/32 Alestra, S. de R.L. de C.V.

2001:1250::/32 NIC México, S.C. 19/02/2009

2001:1258::/32 NIC México, S.C. 14/01/2009

2001:1260::/32 Axtel, S.A.B. de C. V. 30/06/2011

2001:1268::/32 Axtel, S.A.B. de C. V.

2001:1270::/32 Sixsigma Networks Mexico, S.A. de C.V.

2001:1278::/32 Operbes, S.A. de C.V. 27/05/2011

2001:13a8::/32 Universidad Autónoma del Estado de Hidalgo

2001:13c7:7000::/48 NIC México, S.C.

2001:13c7:7014::/46

2001:13c7:7014::/48 NIC México, S.C.

2801:c0::/32 Universidad Autonoma del Estado de Baja California

2801:c4::/48 Universidad Autonoma De Ciudad Juarez

2801:c4:10::/48 Instituto Jalisciense de Tecnologias de la Informacion A.C.

2801:c4:20::/48 Instituto Nacional de Astrofisica, Optica y Electronica

2801:c4:30::/48 Universidad de Guanajuato

2801:c4:40::/48 Universidad Autonoma de Guerrero 01/10/2013

2801:c4:50::/48 Universidad Autonoma de Guadalajara, A.C.

2801:c4:60::/48 Instituto Politecnico Nacional

2801:c4:b1::/48 Home Interiors de Mexico S. de R.L. de C.V.

2801:d0::/32 Universidad Autonoma de San Luis Potosi


28

Tabla 1.1. Asignaciones IPv6 en México

2801:f0::/48 BANCO DE MEXICO

2801:f0:16::/48 Universidad Autonoma de Queretaro

2801:f0:20::/48 Centros Culturales de Mexico, AC 13/01/2012

2801:f0:28::/48 Instituto Nacional de Ecologia

2806::/28 Axtel, S.A.B. de C.V. 23/07/2013

2806:200::/32 Pegaso PCS, S.A. de C.V. 06/11/2013

2806:200:5::/48 06/11/2013

2806:220::/32 GSAT COMUNICACIONES SA DE CV 05/04/2012

2806:230::/32 Telev ision Internacional, S.A. de C.V. 06/12/2013

2806:238::/48 Uninet S.A. de C.V.

2806:238:10::/48 Universidad Autonoma de Campeche

2806:239::/32 Consorcio para el Intercambio de Trafico de Internet A. C.

2806:240::/32 Megacable Comunicaciones de Mexico, S.A. de C.V. 12/01/2012

2806:250::/32 Cablemas Telecomunicaciones SA de CV 02/10/2013

2806:260::/32 Mega Cable, S.A. de C.V.

2806:270::/32 Triara.com, S.A. de C.V.

2806:280::/32 Gigacable de Aguascalientes, S.A. de C.V.

2806:290::/32 Telefonos del Noroeste, S.A. de C.V.

2806:2a0::/32 Cablevisión, S.A. de C.V.

2806:2b0::/32 Maxcom Telecomunicaciones, S.A.B. de C.V. 19/09/2012

2806:2c0::/32 Uninet S.A. de C.V.

2806:2d0::/32 Grupo Telecom de Monterrey

2806:2d1::/32 El Asturiano



2806:2e0::/32 BTU Comunicacion SA de CV

2806:2f0::/32 Iusacell PCS de Mexico, S.A. de C.V.

2806:300::/32 COMPUTADORAS Y SERVICIOS ESPECIALES SA DE CV

2806:310::/32 Cablevision Red, S.A de C.V.

2806:340::/32 GRUPO GOR, S.A. DE C.V.

2806:350::/32 Redes y Comunicaciones de Michoacan S.A. de C.V. 16/06/2013

2806:360::/32 TV Rey de Occidente, S.A. de C.V.

2806:370::/32 RadioMovil Dipsa, S.A. de C.V.

2806:1000::/24 Uninet S.A. de C.V. 12/05/2011

2a01:ce90::/29 Orange Business Serv ices Internet 04/03/2012


29

En la figura 1.22 se muestra una gráfica comparativa de las asignaciones de IPv6 en México, Estados

Unidos y Brasil, nótese la deficiencia de asignaciones en la que se encuentra México

Figura 1.23, gráfica comparativa de asignaciones IPv6

Por su parte, NIC México (organización encargada de asignar y registrar direcciones IP y ASNs para

México), nos brinda los siguientes datos, actualizados hasta abril de 2013.

Diez carriers anuncian recursos IPv6 en internet.

Un carrier está en pruebas de IPv6 con usuarios finales.

Dos carriers ya pueden entregar enlaces dedicados de IPv6:

o Axtel

o Uninet

Siete carriers ya soportan IPv6 de forma nativa en sus redes, lo que potencialmente

proporcionara conectividad a más del 95% del mercado, falta la última milla para facilitar

el despliegue.


30

Respecto a las peticiones del Sistema de nombres de Dominio (DNS)

El tráfico de peticiones de DNS bajo transporte IPv6 representa aproximadamente el 0.8% del

tráfico total de DNS de NIC México.

Alrededor del 20% del tráfico total de DNS de NIC México proviene de México.

Las peticiones sobre IPv6 provienen principalmente de Europa y USA.

Analizando las estadísticas del despliegue de IPv6 en México, se nota que estamos muy desfasados

respecto a otros países incluso en América Latina, ya que aunque algunos ISP el servicio ya esté

disponible, solo los clientes corporativos pueden solicitar su activación, además se trata de un servicio

que no es muy publicitado y del cual los agentes comerciales suelen incluso desconocer todo tipo de

detalles.

Aún falta mucho camino por recorrer, lo más importante es la capacitación, formación y difusión

acerca de nuevo protocolo, para empezar con la transición, además es importante presionar a los ISPs

para que brinden conectividad IPv6 a los usuarios finales, las universidades deben usar y enseñar IPv6,

ya que no existe otra solución más que la transición, no hay tiempo para otra medida. Esto es algo que

no admite discusión bajo ningún punto de vista, ni técnico ni económico y así lo han confirmado

gobiernos y organizaciones de todo tipo y en todo el mundo.

1.5 Características de IPv6 y mejoras respecto a IPv4

La primer característica que se nota simple vista del protocolo IPv6, es sin duda el mayor espacio de

direccionamiento, pero los desarrolladores del protocolo de internet de nueva generación estudiaron

todos las desventajas de su antecesor IPv4 y lo resolvieron en IPv6, incluso agregaron nuevas

características no disponibles en IPv4 las cuales se describen a continuación.

Jerarquía de direcciones – Agregación de prefijos de red

Un espacio mayor de direcciones de IPv6 permite mayores distribuciones de direcciones a las

organizaciones y a los proveedores de servicios de Internet. Al tener una gran disponibilidad de

direcciones se posibilita el uso de un solo prefijo grande para toda la red de una organización y, por

ende, el ISP puede sumar las rutas (agregar) de todos los prefijos de sus clientes en un solo prefijo y

anunciarlo al Internet IPv6.


31

Cuando un usuario final cambia su proveedor de IPv6, el cual le proveía de direccionamiento IPv6,

entonces también debe cambiar su prefijo de IPv6 para preservar su agregación global. Al mismo

tiempo, el cambiar de proveedor implica una re numeración de la red.

Modos de configuración de IPv6

Autoconfiguración, definida en el RFC 2462 y también es conocida como Configuración Automática

de Dirección Sin Estado IPv6. Esta funcionalidad permite que un enrutador IPv6 envíe, a través del

enlace local, la información de red a las computadoras y que ellas puedan configurarse correctamente.

La información enviada es el prefijo de IPv6 del enlace local y la ruta por defecto del mismo protocolo.

Mediante este mecanismo cada computadora y servidor de IPv6 añade su dirección de capa de enlace

(dirección MAC) en el formato EUI-64 al prefijo de IPv6 de Unicast global único anunciado en la

subred.

Configuración mediante servidor. Las computadoras que utilizan IPv6 pueden obtener sus parámetros

y direcciones de configuración de un servidor de DHCP versión 6. Este modo es llamado

Configuración de Direcciones con Estado IPv6.

Renumeración.

El proceso de renumeración de IPv6 fue diseñado para ser transparente entre los proveedores de IPv6

Unicast y los usuarios finales. Esto se logra con el mecanismo de autoconfiguración que permite una

renumeración sencilla a las computadoras con sólo enviarles el nuevo prefijo IPv6 Unicast para la red.

Una desventaja de este mecanismo es la pérdida de las sesiones TCP y UDP que ocurren entre las

computadoras y los servidores al momento exacto de la transición. Esto es algo que también ocurre

actualmente con IPv4.

Multicasting

La difusión del Protocolo de Resolución de Dirección (Address Resolution Protocol, ARP) de IPv4

afecta la eficiencia de la red. Esta situación no ha sido incluida en IPv6, y en su lugar se utiliza la

Multidisusión (Multicasting) la cual funciona de la siguiente manera:

Se crea un grupo Multicast, formado por conjunto de interfaces de red.

Si se está interesado en que cierta computadora reciba los paquetes de difusión del grupo se

agrega una interfaz de red, de esa forma se envía un paquete Multicast al grupo X.


32

Ese paquete sólo llegará a aquellas computadoras que tengan su interfaz incluida en el grupo

MulticastX. Con ello se permite tener niveles de eficiencia de red superiores a los presentados

en IPv4, lo cual se verá traducido en la disminución de los ciclos de procesamiento de CPU de

las computadoras en la red local al no procesar paquetes de difusión que no van dirigidos a

ellos y de la misma manera se estará eliminando el problema de las tormentas de paquetes de

difusión de IPv4.

Encabezado eficiente

El nuevo encabezado de IPv6 es más sencillo que el de IPv4. Del encabezado de IPv4 se removieron 6

campos: Longitud de encabezado, Identificación, Banderas, Desplazamiento por fragmentación, Suma

de verificación de encabezado, Opciones y Relleno. Al pasar de un encabezado de IPv4 con longitud

variable a IPv6 con menos campos y longitud fija se obtiene una reducción en los ciclos de CPU de los

enrutadores al momento de enviar los paquetes de IPv6. Lo anterior conlleva un mejor desempeño de la

red.

Etiqueta de flujo

Dentro del encabezado de IPv6 existe un nuevo campo llamado Etiqueta de Flujo, éste es usado por el

nodo fuente para solicitar un manejo especial de secuencias específicas de paquetes. La etiqueta está

dirigida al procesamiento de la estación destino, no para los enrutadores, y es de gran utilidad para

aplicaciones como videoconferencias y voz sobre protocolo de Internet (VoIP). Asimismo agrupa

todas aquellas que requieren un tratamiento especial de Calidad de Servicio (Quality of Service, QoS)

en los enrutadores de la trayectoria.

Extensiones de encabezado

La utilización del campo Opciones en el encabezado de IPv4 presenta desventajas a la transmisión de

los paquetes y a la eficiencia de la red. En lo que respecta a la variación del tamaño del encabezado es

debido a que tiene campos opcionales. En el segundo caso todos los enrutadores que procesan el

paquete deben computar el encabezado con su campo de longitud variable lo que introduce retardos y

gasto de la capacidad del CPU en ciclos de procesamiento que son innecesarios.

Para resolver la situación anterior, IPv6 sustituye el campo Opciones al final del encabezado por las

Extensiones de Encabezado, formando un encadenamiento de encabezados enlazados por un campo

llamado Siguiente Encabezado. Se presenta un campo Siguiente Encabezado dentro de cada Extensión


33

de Encabezado usado por IPv6. Este diseño con extensiones permite una mejor eficiencia en el

procesamiento de los paquetes, ya que asegura que los enrutadores y nodos computan los encabezados

dirigidos a ellos a lo largo de la trayectoria.

Movilidad

Debido a que la movilidad es una característica importante y deseable por las compañías proveedoras y

los consumidores finales el Protocolo de Internet Móvil (Mobile IP) esta capacidad está disponible

tanto en IPv4 como en IPv6. Cabe destacar que en este último la movilidad se construyó dentro del

protocolo en lugar de ser una nueva función agregada como en IPv4. Ello implica que cualquier nodo

IPv6 puede usar una IP Móvil tanto como lo requiera. IPv6 Móvil utiliza dos Extensiones de

Encabezado: un Encabezado de Enrutamiento para el registro y un Encabezado de Destino para entrega

del datagrama entre los nodos móviles y sus nodos fijos correspondientes.

Seguridad

El protocolo IPSec estandarizado por el IETF provee las funciones de:

Limitar el acceso a sólo aquellos autorizados.

Certifica la autenticación de la persona que envía los datos.

Encripta los datos transmitidos a través de la red.

Asegura la integridad de los datos.

Invalida la repetición de sesiones, para evitar que no sean repetidas por usuarios maliciosos.

Los protocolos que respaldan el funcionamiento de IPSec son: la Autenticación de Encabezado

(Autentication Header, AH) y la Carga de Seguridad Encapsulada (Encapsulated Security Payload,

ESP). Al estar incluidos en cada implementación de IPv6 se provee mayor seguridad ya que IPSec está

presente en todos los nodos de la red.


34

1.6 Consecuencias al no desplegar IPv6

Muchas organizaciones ya lo están desplegando y puede darse el caso de que algunos ISPs comiencen

a conectar usuarios, solo con IPv6, habiendo servicios de Internet que solo estén disponibles en IPv4,

haciendo muy difícil la comunicación entre ambos.

Aquellos servicios que no sean visibles en IPv6 (cualquier página web, banca electrónica, comercio

electrónico, etc.) se diluyen en la red y dejara de ser visible en una parte del mundo cada vez mayor.

Es probable que algunos ISPs se caigan, porque no fueron capaces de prepararse a tiempo para soportar

el nuevo protocolo y por lo tanto sean incapaces de ofrecer servicios a los nuevos usuarios.

Se dificulta la mejora de nuevas aplicaciones cliente-cliente como VoIP y video conferencia, debido a

que la traducción de direcciones evita la comunicación entre pares.

Para aprovechar aún más las pocas direcciones IPv4, se puede optar por seguir utilizando NAT, y es

probable que haya usuarios que en lugar de tener un NAT entre ellos e Internet, lleguen a tener varios

niveles de NAT, nuevos tipos de traducciones podrían evitar que funcionaran correctamente algunas

aplicaciones.

En general existen múltiples de posibilidades que pueden afectar a las redes si no se está preparado

para en nuevo protocolo de Internet, aun así la transición es inminente, no hay otra forma que Internet

siga creciendo si no se implementa IPv6.


35

Capítulo 2 Marco teórico, detalles técnicos de IPv6

2.1 Encabezado del paquete IPv6

Para analizar el encabezado del protocolo de IPv6 es necesario también recordar el encabezado de su

antecesor IPv4 porque ayudará a entender la evolución y las mejoras que ofrece IPv6.

El encabezado de IPv6, descrito en la RFC 2460, elimina o hace opcionales varios campos del

encabezado de IPv4, consiguiendo un encabezado de tamaño fijo y más simple, con el fin de reducir el

tiempo de procesamiento de los paquetes manejados y limitar el coste en ancho de banda del

encabezado de IPv6.

El encabezado de IPv4, mostrado en la Figura 2.1 tiene una longitud variable mínima de 20 octetos. El

bit más significativo se numera por 0 a la izquierda, y el menos significativo se numera por 31 a la

derecha. La forma de transmitir los diferentes bytes, sigue el orden de izquierda a derecha y de arriba

hacia abajo.

Figura 2.1 Encabezado del paquete IPv4

El encabezado IPv4 consiste de los siguientes campos:

Versión (Version, 4 bits): Es el número de versión de IP, es decir cuatro.

Longitud del encabezado (Header Length, 4 bits): Especifica la longitud total del encabezado

en palabras de 32 bits. El valor mínimo y más común es de 5(5x32bits=20bytes), siendo la

longitud del encabezado mínima. Puesto que el campo es de 4 bits, se limita la longitud total

del encabezado a 60 bytes.

Dirección de destino

Dirección de origen

ProtocoloSuma de comprobación

(Encabezado)Tiempo de vida (TTL)

DesplazamientoIdentificador

Datos

Opciones Relleno

Longitud totalVersiónLongitud

Encabezado

Tipo de serv icio

000 E C F 00

0D

F

M

F


36

Tipo de servicio (Type of Service, 8 bits): Indica la calidad de servicio solicitada por el

paquete IP. ToS se encuentra descrito en la RFC 791. La RFC 1583 describe “ToS Application

Routing”. El campo ToS ha sido redefinido como DSCP (Differentiated Services Code Point)

que consta de los 6 primeros bits y dos sin establecer.

Longitud total (Total Length, 6 bits): Especifica el tamaño total del paquete, incluyendo el

encabezado y los datos, en bytes.

Identificador (Identifier, 16 bits): Es un número único asignado por el dispositivo que envía el

paquete, con el fin de que el destinatario pueda re ensamblar un paquete fragmentado por los

nodos intermedios. La fragmentación es necesaria porque no todas las redes físicas tienen la

misma longitud de trama máxima, por lo cual en muchos casos es necesario que los nodos

intermedios dividan el datagrama en varios fragmentos. Cada uno de estos fragmentos podrá

seguir rutas distintas al resto y, de perderse alguno de los fragmentos, el origen deberá

retransmitir el paquete completo.

Banderas (Flags, 3 bits): Es un campo para el control de la fragmentación y contiene los

valores 0, DF y MF.

o 0. Reservado, no se utiliza.

o DF (Dont Fragments), si es 0 significa que puede haber fragmentación, y si es 1,

significa que no puede haber fragmentación.

o MF (More Fragments), si es 0 indica que es el último fragmento, y si es 1, indica que

aún hay más fragmentos.

Desplazamiento del fragmento (Fragment Offset, 13 bits): Es utilizado en los paquetes que

han sido fragmentados, para posibilitar el re ensamblado total del paquete. Su valor indica el

número de bloques de 8 bytes (sin contabilizar los bytes del encabezado) que estaban

contenidos en los fragmentos previos. En el primer fragmento, o en un único fragmento, este

valor es siempre 0.

Tiempo de vida (TTL, 8 bits). Contiene el tiempo máximo que un paquete puede permanecer

en una red. Cada enrutador por el que pasa el paquete decrementa en uno el valor de este

campo, siendo 1 el valor mínimo, si el valor llega a 0, el paquete es descartado. Esto garantiza

que los paquetes no viajan a través de una red haciendo bucles, incluso si las tablas de

encaminamiento son erróneas.

Protocolo (Protocol, 8 bits): Indica al protocolo de nivel superior al que IP deberá pasar los

datos del paquete. Entre algunos de los valores que puede tomar este campo tenemos:

o 1: ICMP (Internet Control Message Protocol)

o 2: IGMP (Internet Group Management Protocol)


37

o 3: GGP (Gateway-to-Gateway)

o 4: IP (IP in IP encapsulation)

o 5: ST (Stream)

o 6: TCP (Transmission Control Protocol)

o 7: CBT (Core Based Trees)

o 8: EGP (Exterior Gateway Protocol)

o 9: IGP (Interior Gateway Protocol)

o 10: BBN-RCC-MON (BBN RCC Monitoring)

o 17: UDP (User Datagram Protocol)

Suma de comprobación del encabezado (Header Cheksum, 16 bits): Es un campo para

controlar los errores únicamente en el encabezado IP. Si el Checksum del encabezado no

concuerda se descarta el paquete.

Dirección origen (Source Address, 32 bits): Es la dirección del origen del paquete.

Dirección destino (Destination Address, 32 bits): Es la dirección del destino del paquete.

Opciones (Options, hasta 40 bytes): No son requeridas en todos los paquetes.

Relleno (Pay, variable). Si se utiliza esta opción, el datagrama rellena con octetos todo a ceros

“0” hasta el siguiente límite de 32 bits.

Datos. (Data, variable). Son los datos contenidos en el paquete.

El encabezado de IPv6, mostrado en la Figura 2.2 tiene una longitud fija de 40octetos, consistiendo en

los siguientes campos:

Figura 2.2 Encabezado del paquete IPv6

Versión (Version, 4 bits): Es el número de versión de IP, es decir seis.

Clase de tráfico (Traffic Class, 8 bits): Este campo es igual al campo Type of Service del

encabezado IPv4 y cuya función es permitir marcar los paquetes con diferentes clases de

servicio. Su operación es igual a la del campo ToS de IPv4.

Datos

Dirección de destino (16 Octetos)

Dirección de origen (16 Octetos)

Encabezado

siguiente

Limite de

saltosLongitud de carga útil

Etiqueta de flujoVersión Prioridad


38

Etiqueta del flujo (Flow Label, 20 bits): El estándar IPv6 define un flujo como una secuencia

de paquetes enviados desde un origen específico a un destino específico. Un flujo se identifica

únicamente por la combinación de una dirección fuente y una etiqueta de 20 bits. De este

modo, la fuente asigna la misma etiqueta a todos los paquetes que forman parte del mismo

flujo, este campo se utiliza para permitir la implementación de funciones de calidad de

servicio, su uso viene descrito en el RFC 1809.

Longitud del paquete (Payload Length, 16 bits): contiene sólo el tamaño de la carga útil, sin

tener en cuenta la longitud del encabezado. Para paquetes en los que el tamaño de datos es

superior a 65.536, este campo vale 0 y se utiliza la opción de jumbograma de la extensión

"salto a salto".

Siguiente encabezado (Next header, 8 bits): tiene una función similar a la del campo

protocolo (protocol) en el paquete IPv4: simplemente identifica el encabezado siguiente (en el

mismo datagrama IPv6). Puede ser un protocolo de una capa superior (ICMP, UDP, TCP, etc.)

o una extensión.

Límite de saltos (Hop Limit, 8 bits): Reemplaza el campo TTL, Su valor de 8 bits disminuye

con cada nodo que reenvía el paquete. Si este valor llega a 0 cuando el paquete IPv6 pasa por

un enrutador, se rechazará y se enviará un mensaje de error ICMPv6. Esto se utiliza para evitar

que los datagramas circulen indefinidamente. Tiene la misma función que el campo Tiempo de

vida en IPv4, es decir, contiene un valor que representa la cantidad de saltos y que disminuye

con cada paso por un enrutador. En teoría, en IPv4, hay una noción del tiempo en segundos,

pero ningún enrutador la utiliza. Por lo tanto, se ha cambiado el nombre para que refleje su

verdadero uso.

Dirección origen (Source Address, 128 bits): Es la dirección del origen del paquete.

Dirección destino (Destination Address, 128 bits): Es la dirección del destino del paquete.

Como se puede observar, de todos los campos del encabezado de IPv4 se ha pasado a solo ocho

campos en IPv6. El motivo fundamental por el que estos campos (longitud del encabezado,

Identificación, banderas, desplazamiento de fragmento, comprobación del encabezado y opciones) son

eliminados, es la innecesaria redundancia; en IPv4 se está facilitando la misma información de diversas

formas, como es el caso del campo de control de errores, pues otros mecanismos de encapsulado de

capas inferiores, por ejemplo Ethernet, ya realizan esta función. El campo de desplazamiento de

fragmentación de IPv4 ha sido eliminado, porque los paquetes ya no son fragmentados en los nodos

intermedios, en IPv6 es un proceso que se produce extremo a extremo. El único campo realmente

nuevo en IPv6 es la etiqueta de flujo. La información opcional a la estrictamente necesaria para


39

encaminar los paquetes de datos, es codificada en encabezados adicionales que pueden ubicarse entre

el encabezado IPv6 y los encabezados de niveles superiores, como por ejemplo el encabezado

TCP/UDP. En la actualidad, hay un pequeño número de tales encabezados de extensión (opciones de

salto por salto, encaminamiento extendido, fragmentación y re ensamblado, opciones del destino,

autentificación, y encapsulación) estando cada una identificada por un valor distinto del valor del

campo siguiente encabezado. Cada paquete IPv6 puede llevar cero, una, o más encabezados de

extensión, cada una identificada por el valor del campo siguiente encabezado del encabezado que la

precede. Los encabezados de extensión deben de ser procesados en orden, ya que el contenido y

semántica de cada una de ellas indican si se debe o no procesar el siguiente encabezado.

De esta forma, los encabezados de extensión no son examinados o procesados por los nodos

intermedios, sólo cuando lleguen al nodo que venga identificado por el campo de dirección de destino

del encabezado IPv6. La única excepción es el encabezado de opciones de salto por salto, que lleva

información que debe ser procesada y examinada en todos los nodos por los que pasa el paquete,

incluyendo los nodos origen y destino. El encabezado de opciones de salto por salto, cuando esté

presente, debe seguir inmediatamente al encabezado IPv6. Su presencia se indica por el valor 0 en el

campo de siguiente encabezado del encabezado IPv6.

Cada encabezado de extensión tiene una longitud múltiplo entero de 8 octetos, con el fin de mantener

el alineamiento de 8 octetos en los encabezados siguientes. La razón de que los distintos campos del

encabezado estén alineados a 64 bits, es que la nueva generación de procesadores de 64 bits puedan

procesar dichos campos más eficientemente.

Resumiendo, las principales mejoras que ofrece el encabezado IPv6 son:

Encabezado de tamaño fijo, de 40 bytes.

Eliminación de campos redundantes en el encabezado, haciendo un total de 8.

Encabezados básicos y de extensión alineadas a un múltiplo entero de 64 bits.

Procesamiento eficiente de las opciones, sólo en destino y cuando éstas se presentan.

Fragmentación procesada en el origen y el destino de los paquetes, no en los enrutadores.


40

2.2 Direccionamiento IPv6

Las direcciones IPv6 están formadas por 128 bits que se asignan a interfaces y no a nodos. En IPv6 un

nodo o host es cualquier dispositivo que implemente el protocolo IPv6, esto incluye a las computadoras

y dispositivos de enrutamiento, los nodos pueden tener múltiples interfaces y por tanto múltiples

direcciones.

En IPv6 se ha definido una nueva notación para escribir las direcciones, comprende 8 grupos de 4

números hexadecimales separados por dos puntos, los dígitos hexadecimales no son sensibles a

mayúsculas/minúsculas, por ejemplo.

2340:1111:aaaa:0001:1234:5678:9abc:1234

Se pude simplificar la escritura de una dirección IPv6 de la siguiente manera: en el caso de que haya

grupos contiguos de 16 bits todos cero se pondrá doble dos puntos, además el primer cero de un grupo

puede descartarse. Por ejemplo.

2001:0db8:85a3:0000:0000:8a2e:0370:7334 dirección no simplificada

2001:db8:85a3:0:0:8a2e:0370:7334 omitiendo ceros iniciales

2001:db8:85a3::8a2e:370:7334 omitiendo ceros iniciales y abreviando grupos

. de ceros

La sustitución con puntos puede realizarse únicamente una vez en la dirección. En caso contrario, se

obtendría una representación ambigua. Si pueden hacerse varias sustituciones, se debe hacer la de

mayor número de grupos; si el número de grupos es igual, se debe hacer la situada más a la izquierda.

2.2.1 Prefijo de direcciones IPv6

A diferencia de las direcciones en IPv4, las direcciones de IPv6 usan el prefijo para su agrupamiento

dentro de la red, algo similar a la máscara de red o en el apartado CIDR (Classless Inter-Domain

Routing) en IPv4.


41

2001:0db8:0:7:ffff:ffff:ffff:ffff

Las direcciones IPv6 se agrupan mediante el valor binario de la dirección. Este agrupamiento se lleva a

cabo con los prefijos. Los prefijos representan a todas aquellas direcciones que empiezan con la misma

serie de bits, y hasta determinada longitud representada por un /xx.

Por ejemplo, el prefijo:

3b51:5c00::/32

Contiene todas las direcciones que comienzan en:

3b51:5c00:0:0:0:0:0:0

Y terminan en:

3b51:5c00:ffff:ffff:ffff:ffff:ffff:ffff

Es decir, los 32 primeros bits son idénticos representado hexadecimalmente como 3b51:5c00, y el resto

puede variar.

Puesto que cada dígito hexadecimal agrupa 4 bits, es muy recomendable el usar prefijos cuya longitud

sea múltiplo de 4, como por ejemplo 32/, /48, /52, /56 así sucesivamente.

Pero nada impide que se usen prefijos con longitudes que no sean múltiplo de 4, lo que hay que tener

en cuenta es que la finalización del prefijo estará dentro de un dígito hexadecimal recordando que un

dígito hexadecimal realmente es una serie de 4 bits.

Por ejemplo: El prefijo

2001:0db8::/61

Contiene las direcciones que comienzan en

2001:0db8:0:0:0:0:0:0

y terminan en:


42

2.2.2 Tipos de direcciones en IPv6

A nivel general, podemos clasificar las direcciones IPv6 en tres grandes categorías:

Direcciones Unicast

Direcciones Multicast

Direcciones Anycast

Las direcciones Unicast, al igual que en IPv4, son las más comunes y utilizadas. Estas son asignadas

a una interfaz permitiendo la comunicación directa entre dos nodos de la red, esta técnica de

comunicación es conocida como uno a uno (one-to-one). La figura 2.3 muestra es un ejemplo de la

estructura de una dirección Unicast IPv6.

2001:0db8:4a6d:0055:0000:0000:4c2f:5b2b/64

Figura 2.3. Estructura de dirección IPv6 Unicast

Posteriormente se verá la estructura de las direcciones, que patrón deben de seguir para que se

identifique como una dirección Unicast en IPv6.

Las direcciones Multicast permiten identificar múltiples interfaces o nodos en una red. Con este tipo de

direcciones podemos comunicarnos con múltiples nodos de manera simultánea. Esta técnica de

comunicación es conocida como uno a muchos (one-to-many). La figura 2.4 es un ejemplo de la

estructura de una dirección Multicast IPv6.

ff02:0:0:0:0:0:0:9

Figura 2.4. Estructura de dirección IPv6 Multicast

Las direcciones Anycast son un nuevo tipo de dirección en IPv6. Al igual que una dirección Multicast,

una dirección Anycast identifica múltiples interfaces, sin embargo, mientras que los paquetes de

Multicast son aceptados por varios equipos, los paquetes Anycast sólo se entregan a la interfaz o nodo

que este más cercano. La figura 2.5 es un ejemplo de la estructura de una dirección Anycast IPv6.

2002:0db8:6301::/128

Figura 2.5. Estructura de dirección IPv6 Anycast


43

Mientras que las direcciones broadcast a diferencia de IPv4, el protocolo IPv6 no hace uso de ellas.

Las direcciones broadcast son utilizadas para la comunicación de un nodo con todos los nodos dentro

de un segmento de red. Este tipo de dirección fue eliminado en las características del protocolo IPv6.

Unicast, Multicast y Anycast son las tres grandes categorías de direcciones en el protocolo IPv6, a

continuación se describen características más detalladas de cada dirección.

2.2.2.1 Direcciones Unicast.

Los tipos de direcciones IPv6 que existen dentro de las direcciones Unicast son:

Link-local

Site-Local (obsoleta)

Unique-Local

Global

Las direcciones link-local son el equivalente a las direcciones IP privadas en IPv4. Estas son asignadas

a una interface de manera automática a partir del momento que se activa el protocolo IPv6 en un nodo.

El prefijo de estas direcciones es fe80::/10 y estas direcciones no pueden ser enrutadas a través de los

enrutadores fuera del segmento local.

El propósito principal es proporcionar direccionamiento IP automático a los nodos en caso que no

exista un servidor de configuración dinámica de host (Dynamic Host Configuration Protocol, DHCP).

Una dirección IPv6 link-local comienza con el prefijo fe80::/10 (los primeros 10 bits), luego los bits

del 11 hasta 64 (los siguientes 54 bits) se configuran con valores de ceros (0000). De esta manera se

forma la porción de red representada por los primeros 64bits.La porción de nodo o identificador de

interfaz (interface ID), que son los últimos 64 bits, se forma con el formato EUI-64.

Extended Unique Identifier 64 (EUI-64), permite a un host asignar un identificador de interfaz de 64

bits, El formato EUI-64 se obtiene a través de la dirección MAC de 48 bits. La dirección MAC se

separa primero en dos grupos de 24-bits, uno de los cuales es el OUI (Organizationally Unique

Identifier) y el otro es el NIC (Network Interface Card), luego se inserta el valor 0xFFFE entre estos

dos grupos de 24-bits a la dirección. La figura 2.6 muestra cómo se genera el identificador de interfaz a

través de este formato.

http://es.wikipedia.org/wiki/Host


44

Figura 2.6 Generación de formato EUI-64

A partir del séptimo bit de la dirección de izquierda a derecha, el valor debe ser invertido, si es 0 se

invierte a 1 y si es 1 se invierte 0, esto para conocer de qué forma será administrada ya sea local o

globalmente.

Una vez que lo anterior se lleva a cabo, tenemos una dirección de formato EUI-64 completamente

funcional como se observa en la figura 2.7 y 2.8.

Figura 2.7. Formato EUI-64

Figura 2.8. Formato de una Dirección Unicast Link-local

Las direcciones Site-local son también el equivalente a las direcciones IP privadas en IPv4. A

diferencias de las direcciones Link-Local, estas pueden ser enrutadas fuera del segmento local, es decir,

podemos enviar paquetes entre diferentes segmentos de la red pero no hacia el Internet.

00 21 B5 6E 10

Dirección MAC 48 bits

00 21 2F B5 6E 10FF FE

EUI 64 bits

2F

OUI NIC

00 21 2F B5 6E 10FF FE

02 21 2F B5 6E 10FF FE

0000 0000

0000 0010

Formato EUI completamente funcional

FE80:0000:0000:0000:0000:0000:0000:0000/10

54 bits

64 bits10 bits

1111 1110 10 Formato EUI-64


45

En las direcciones Site-local, los primeros 10 bits se establecen con los valores 1111111011, por lo

tanto, el prefijo de estás direcciones tendrá un valor en hexadecimal de fec0 :: /10.

Los siguientes 54 bits están compuestos por el ID de red. Los últimos 64 bits son el identificador de la

interfaz o nodo, y estos se configuran de la misma forma que las direcciones Link-Local, tomando 48

bits de la dirección MAC y luego agregando 16 bits con los valores 0xFFFE aunque este tipo de

direcciones están consideradas como obsoletas. La figura 2.9 es un ejemplo de una dirección de Site-

local.

Figura 2.9. Dirección Unicast Site-Local.

Las direcciones Unicast Unique-local son similares a lo que en IPv4 corresponde a las direcciones

privadas (10.0.0.0/8, 172.16.0.0/16 y 192.168.0.0/24). Estas direcciones reemplazaron a las Site-local.

Una de las principales ventajas es que se evitará en gran medida la repetición en el uso de redes, ya que

es demasiado cotidiano diseñar redes IPv4 con direcciones privadas las cuales se repiten varias veces

(10.0 ó 172.16 ó 192.168.1) en sitios diferentes que luego se deberán interconectar.

La solución a este problema no fue dejar el tema al azar, no dejar que el administrador elija lo que

quiera, sino que se definen condiciones para que se genere el número de bits elegidos aleatoriamente.

Y además se han reservado para esto 40 bits, un número muy grande. Es como seleccionar un número

entre un sorteo que tiene 1.099.511.627.776 posibilidades, la probabilidad de acertar es casi imposible.

El prefijo reservado por IANA, para estas direcciones son 8 bits (1111 1101), si lo pasamos a

hexadecimal, por lo tanto el prefijo de estas direcciones IP tendrá un valor de fd00::/8.

Para generar los 40 bits aleatorios hay una serie de especificaciones que se deben cumplir para generar

por medio del “Local IPv6 Range Generator” y todavía restan 16 bit para subdividir las redes en

subredes. Hay que aclarar que estas direcciones son para uso privado, por lo tanto no son enrutables en

FEC0:0000:0000:0000:0000:0000:0000:0000/10

54 bits

64 bits10 bits

1111 1110 11 Formato EUI-64

ID red

https://www.ultratools.com/tools/rangeGeneratorResult?globalId=&subnetId=


46

Internet, aunque por supuesto las podemos enrutar dentro de cada red. La figura 2.10 es un ejemplo de

una dirección Unicast-Unique-local.

Figura 2.10 Dirección Unicast-Unique-local

Las direcciones Globales son el equivalente de las direcciones IP públicas en IPv4. Estas direcciones

pueden ser enrutadas a través de Internet. Los primeros tres bits están compuestos por los

valores 001 por lo tanto, el prefijo de estás direcciones IP tendrá un valor en hexadecimal de 2000 con

una máscara /3. (2000::/3)

Lo anterior significa que los primeros tres bits dentro de una dirección Global Unicast deben de ser

siempre 001 y la máscara de /3 significa que sólo pueden hacerse variaciones después de los primeros

tres bits dentro del primer octeto para establecer el prefijo Global de Enrutamiento (Global Routing

Prefix).

El Prefijo Global de Enrutamiento consiste en un número de bits que se pueden subdividir de acuerdo a

las necesidades de los Registros de Internet y proveedores de Internet, a fin de reflejar la topología de

la Internet en su conjunto. A partir de estos primeros 3 bits es que comienza la jerarquización de la

asignación de las direcciones IP a nivel global.

Los posibles prefijos que podrían ser utilizados para presentar direcciones IP del tipo Global Unicast

serían:

2000 (0010) – dirección válida Global Unicast

3000 (0011) – dirección válida Global Unicast

4000 (0100) – dirección inválida Global Unicast (a partir de aquí cambia la estructura de 001en

los primeros 3 bits)

5000 (0101) – dirección inválida Global Unicast

Los primeros 64 bits de un total de 128 bits, los tres bits primeros representan el Prefijo Global. Los

siguientes 45 bits identifican la red asignada a las organizaciones y los siguientes 16 bits representan la

FD00:0000:0000:0000:0000:0000:0000:0000/8

40 bits 64 bits

8 bits

1111 1101

ID Interfaz

ID Subred

ID Global

aleatorio

16 bits


47

subred (Subnet ID) en caso de realizarse una subdivisión de la red (Subnetting). La figura 2.11 y 2.12

son ejemplos de la estructura de una dirección Unicast-global.

Figura 2.11. Estructura dirección Unicast Global

Una dirección IPv6 Global Unicast soporta 216 subredes posibles para un total de 65,535. Cada subred

soporta 264 nodos posibles para un total de 18446744073709551616.

Figura 2.12 Ejemplo Dirección Unicast Global

SI no hay subdivisión de la red (Subnetting), entonces, los primeros 64 bits representa la red y los

demás 64 bits los nodos.

2.2.2.2 Direcciones Multicast.

El tráfico de Multicast se envía a una sola dirección, pero se procesa por múltiples nodos, los hosts que

escuchan una dirección de Multicast específica forman parte de un grupo Multicast, que reciben y

procesan el tráfico enviado a la dirección del grupo.

La pertenencia a grupos es dinámica, lo que permite a los hosts unirse al grupo o abandonarlo en

cualquier momento. Los grupos no están limitados por el tamaño y los miembros pueden ser de varios

segmentos de red (enlaces o subredes).

001 Prefijo Global de Enrutamiento ID Subred ID Interfaz

3 bits 45 bits 16 bits 64 bits

001 3 bits Asignado por IANA

Prefijo Global de Enrutamiento 45 bits Asignado a Top-Lev e ISPs

ID Subred 16 bits Asignado a ISPs y Organizaciones

ID Interfaz 64 bits Deriv ado de direccióon MAC

2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b

ID red

ID InterfazRed de la empresa

(Site Prefix)

011


48

Un host puede enviar tráfico a una dirección de grupo sin pertenecer al grupo, para unirse a un grupo,

un host envía un mensaje de pertenencia al grupo. Los enrutadores de Multicast sondean

periódicamente la condición de miembro.

Cada grupo Multicast se identifica con una dirección IPv6 Multicast. Todos los miembros del grupo

que escuchan y reciben mensajes IPv6 enviados a la dirección del grupo comparten la dirección de

grupo.

Las direcciones IPv6 Multicast están reservadas, asignadas y registradas en IANA. Estas direcciones

IPv6 Multicast tienen el prefijo de formato 1111 1111 (ff:: /8). La figura 2.13 muestra la estructura de

una dirección IPv6 Multicast.

Figura 2.13. Estructura general de una dirección Multicast

11111111: identifica la dirección como dirección Multicast.

Banderas : cuatro indicadores 0,0,0,T. Los dos primeros deben ser cero.

Los valores de T pueden ser:

T = 0; Dirección Multicast que no se asigna en función del prefijo de red.

T =1; Dirección Multicast que se asigna en función del prefijo de red.

Scope : Permite limitar los alcances del mensaje Multicast con los valores de la tabla 2.1

Tabla 2.1. Valores que pude tomar el campo Scope en una dirección Multicast IPv6

Prefijo Banderas Scope ID del Grupo

8 bits 4 bits 4 bits (80 + 32) bits

1111 1111

0 No Asignado 8 Ámbito local de

1 Ámbito local de nodo 9 No Asignado

2 Ámbito local de enlace A No Asignado

3 No Asignado B No Asignado

4 No Asignado C No Asignado

5 Ámbito local de sitio D No Asignado

6 No Asignado E Ámbito Global

7 No Asignado F Reservado


49

ID del grupo: identificador del grupo de multidifusión, ya sea permanente o dinámico. La

tabla 2.2 muestra algunas de las direcciones IPv6 Multicast reservadas.

Tabla 2.2 Direcciones Multicast reservadas

Mensajes Multicast Listener Discovery (MLD)

Multicast Listener Discovery (MLD) permite administrar la pertenencia del grupo de Multicast de

subred para IPv6. MLD es una serie de tres mensajes del Protocolo de Mensajes de Control de Internet

para IPv6 (ICMPv6) que sustituye al Protocolo de administración de grupos de Internet (IGMP) que se

utiliza para IPv4, MLD utiliza ICMP (no IGMP), para enviar los mensajes, los cuales se muestran en la

tabla 2.3.

Tabla 2.3 Tipos de mensajes MLD

IPv6 dirección de

multicastDescripción

FF02::1 La dirección de todos los nodos utilizados para llegar a todos los nodos en el mismo vínculo.

FF02::2La dirección para todos los enrutadores utilizados para llegar a todos los enrutadores en el mismo

enlace.

FF02::4All-Distance Vector Multicast Routing Protocol (DVMRP) utilizado para llegar a todos los enrutadores

de multicast DVMRP en el mismo enlace.

FF02::5 Dirección de enrutadores (OSPF) usado para llegar a todos los enrutadores OSPF en el mismo enlace.

FF02::6Todas las direcciones designadas de los enrutadores OSPF utilizado para llegar a todos los

enrutadores OSPF designados en el mismo enlace.

FF02:::FFXX:XXXX

La dirección de nodo solicitado utilizada en el proceso de resolución de direcciones para resolver la

dirección IPv6 de un nodo local de enlace a su dirección de capa de enlace. Los últimos 24 bits

( XX: XXXX ) de la dirección de nodo solicitado son los últimos 24 bits de una dirección IPv6 unicast.

MLD tipo de

mensajeDescripción

Multicast Listener

Query

Enviado por un enrutador multicast para sondear un segmento de red para los miembros del

grupo. Las consultas pueden ser de carácter general, solicitando la pertenencia a grupos de todos

los grupos, o pueden solicitar la pertenencia al grupo para un grupo específico.

Multicast Listener

Report

Enviado por un anfitrión cuando se une a un grupo de multicast, o en respuesta a un MLD Multicast

Listener Query enviado por un enruteador.

Multicast Listener

Done

Enviado por un anfitrión cuando sale un grupo de acogida y es el último miembro de ese grupo en

el segmento de red.


50

Protocol Independent Multicast (PIM)

PIM es un protocolo de enrutamiento y se puede aprovechar en los dispositivos que utilizan los

protocolos de enrutamiento Unicast para rellenar la tabla de enrutamiento Unicast, incluyendo Open

Shortest Path First (OSPF), Border Gateway Protocol (BGP), y rutas estáticas. PIM utiliza esta

información de enrutamiento de Unicast para realizar la función de reenvío de Multicast. PIM aunque

es un protocolo de Multicast en realidad utiliza la tabla de enrutamiento Unicast para realizar la

función de comprobación del RPF en lugar de la creación de una tabla de enrutamiento Multicast

completamente independiente. A diferencia de otros protocolos de enrutamiento, PIM no envía ni

recibe actualizaciones de enrutamiento entre enrutadores.

El RPF es una forma de evitar los bucles por inundación de PIM, que consiste en, que antes de reenviar

por inundación un paquete el enrutador realiza la siguiente comprobación:

1. Analiza la interfaz de entrada del paquete y su dirección de origen (Unicast)

2. Consulta en la tabla de rutas la interfaz de la ruta óptima hacia la dirección de origen

3. Si la interfaz de entrada coincide con la de la ruta óptima, el paquete es aceptado y

redistribuido por inundación.

4. En caso contrario el paquete se descarta ya que probablemente se trata de un duplicado

Hay tres modos de reenvío de PIM:

PIM Dense Mode (PIM-DM)

PIM Sparse Mode (PIM-SM)

Bidirectional PIM (Bidir-PIM)

2.2.2.3 Direcciones Anycast

Las direcciones Anycast son asignadas del espacio de direcciones Unicast, utilizando cualquiera de los

formatos definidos para direcciones Unicast. De esta forma, las direcciones Anycast no se pueden

distinguir sintácticamente de las Unicast. Cuando una dirección Unicast es asignada a más de una

interface esta se convierte en una dirección Anycast y los nodos donde esta dirección es asignada, debe

configurarse explícitamente para que sepan que es una dirección Anycast.

Uno de los usos que plantean las direcciones Anycast es identificar un conjunto de enrutadores

pertenecientes a una organización que ofrece servicios de internet. Tales direcciones pueden ser

http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html#wp1009074




51

utilizadas como direcciones intermedias en un encabezado de enrutamiento IPv6, logrando que un

paquete sea entregado a un proveedor de servicios o a una secuencia de proveedores de servicios. Otro

uso es identificar un conjunto de enrutadores conectados a una subred en particular, o el conjunto de

enrutadores que proveen la entrada a un dominio de enrutamiento en particular.

Figura 2.14. Estructura de una dirección Anycast

El prefijo de subred en una dirección Anycast es el prefijo que identifica un enlace específico. Esta

dirección Anycast es sintácticamente igual a una dirección Unicast para una interface en el enlace con

el ID de interface puesto en cero.

Tal y como se ha indicado antes, las direcciones Anycast tienen el mismo rango de direcciones que las

Unicast.

Figura 2.15. Ejemplo de una dirección Anycast

2.2.3 Subnetting en IPv6

Las Subredes con IPv6 no son drásticamente diferentes de las subredes con IPv4, sólo se deben tomar

en cuenta las siguientes indicaciones:

Cada carácter de una dirección IPv6 representa 4 bits (un nibble).Un 0xf es un 1111 en binario,

es fácil volver a caer en un hábito IPv4 y olvidar que 0x11 es en realidad 0001 0001 en binario.

Cada conjunto de IPv6 representa 16 bits (4 caracteres en 4 bits cada uno).Teniendo esto en

mente se pueden crear subredes más fácilmente.

Nada cambia a binarios, es fácil perderse con tantos dígitos binarios, pero la matemática es lo

mismo que en IPv4.

Prefijo de Subred 0000 0000 .....

N bits 128 - N bits

2002:0db8:6301:0000:0000:0000:0000.0000/128

128 bits

Dirección del nodo


52

Lo recomendado por el IETF es recibir al menos un prefijo /48 de un ISP. Esto indica que se

tienen 280 bits para manipular (dirección de 128 bits - 48 bits que no se pueden cambiar = 80

bits para usar). Más bits que la totalidad del espacio de direcciones IPv4.

La asignación de un prefijo mínimo recomendado para un nodo es un /64, con tantas

direcciones en IPv6 no hay la misma necesidad de la conservación de direcciones como la hay

en IPv4. Se puede asignar un /64 a un enlace punto a punto y no habrá problemas alguno.

Tener un prefijo /48 asignado por el ISP y utilizar el prefijo /64 en cada nodo de la red, se

obtiene bloque de dígitos hexadecimales o 16 bits, que se utilizarán para las subredes. Un

bloque puede no sonar como muchos bits pero 16 bits es la mitad de la totalidad del espacio de

direcciones IPv4.

Con el fin de permitir la agregación de la ruta adecuada y el resumen debe definir IDs de

emplazamiento que se pueden utilizar en cada lugar (ya sea una oficina, centro de datos o

región geográfica), aquí es donde se define al menos un ID del sitio y, posiblemente, un ID de

sub-sitio.

Por ejemplo, Si un proveedor de servicios de internet asigna el prefijo 2001:db8:1234:0000::/48, como

se ha mencionado, tenemos el "0000" de manipular para el sitio, sub-sitio e identificaciones de subred,

para descomponerlo depende en gran medida de las necesidades de la organización.

Opción A. 4 Sitios, 4 sub-sitios en cada sitio, 4096 subredes en cada sub-sitio, los primeros

dos bits para el sitio, los dos bits siguientes para el sub-sitio, próximos tres cuartetos para

subredes 212.

Figura 2.16. Estructura opción A

2001:0db8:1234:0000::/64

0000 0000 0000 0000

Hex

Sitio

Sub-Sitio Subred


53

Opción B. 6 sitios, 16 sub-sitios en cada sitio, 256 subredes en cada sub-sitio, El primer

cuarteto para el sitio, el segundo para el sub-sitio y los dos últimos de la subred.

Figura 2.17. Estructura opción B

Opción C.16 lugares para sitio, 256 sub-sitios en cada sitio, 16 subredes para cada sub-sitio, El

primer cuarteto para el sitio, el segundo y el tercero para el sub-sitio y ultimo cuarteto para la

subred.

Figura 2.18.Estructura opción C

A continuación se hace el ejemplo de un caso. Una empresa con oficinas y centros de datos en

México, como parte de su planificación a largo plazo han solicitado una dirección IPv6 y se les

asigno una dirección 2001:0db8:abcd::/48. Ahora tienen que asignar esta dirección a través de su

empresa. La empresa tiene sucursales en la mayoría de México, así que han decidido utilizar la opción

B, que da 16 sitios, 16 sub-sitios y 256 subredes por sitio.

Han decidido que un “sitio” será una región geográfica del país y un sub-sitio será una ciudad dentro

de la región geográfica, las direcciones de los sitios que están implementando IPv6 son:

2001:0db8:1234:0000::/64

0000 0000 0000 0000

Hex

Sitio

Sub-Sitio Subred

2001:0db8:1234:0000::/64

0000 0000 0000 0000

Hex

Sitio

Sub-Sitio Subred


54

Nuevo León (Sitio 9)

Guadalajara (Sitio 5)

Querétaro (sitio 8)

Puebla (Sitio 3)

Baja California Norte (Sitio 2)

Cd de México (Sitio 1)

Se puede asignar un sitio para cada región, recordando que son solo 16 sitios posibles de acuerdo a la

opción que se eligió:

Figura 2.19. Sitios asignados

Estos son con prefijo /52, porque se tienen 48 bits del proveedor y luego se usa el próximo 4 para

elegir el sitio.

Sitio 0 - 2001:0db8:abcd:0000::/52 --- Primer Sitio

Sitio 1 - 2001:0db8:abcd:1000::/52

Sitio 2 - 2001:0db8:abcd:2000::/52

Sitio 3 - 2001:0db8:abcd:3000::/52

...

Sitio 8 - 2001:0db8:abcd:8000::/52

Sitio 9 - 2001:0db8:abcd:9000::/52

...

Sitio 15 - 2001:0db8:abcd:f000::/52 --- Último Sitio

Sitio 1 (Cd de México)

Cuauhtémoc - 2001:0db8:abcd:1000::/56 --- Primer Sub-Sitio

Uso futuro - 2001:0db8:abcd:1100::/56

...

Uso futuro - 2001:0db8:abcd:1f 00::/56 --- Último Sub-Sitio

Sitio 2 (Baja California Norte)

Tijuana - 2001:0db8:abcd:2000::/56 --- Primer Sub-Sitio

...

Uso futuro - 2001:0db8:abcd:2f00::/56 --- Último Sub-Sitio

Sitio 3 (Puebla)

Uso futuro - 2001:0db8:abcd:3000::/56 -- Primer Sub-Sitio

...

Atlixco - 2001:0db8:abcd:3f00::/56 -- Último Sub-Sitio


55

Figura 2.20. Sub-sitios de cada uno de los Sitios

Al igual que el sitio, el sub-sitio utiliza 4 bits más, moviendo la longitud de prefijo de un /52 a /56.

Ahora se pueden seleccionar las subredes para seleccionar la ubicación de los elementos, se usará el

sitio de Atlixco como ejemplo:

Figura 2.21. Selección de Subredes

Se están definiendo los últimos dos cuartetos para la subred por lo que la máscara se mueve de /56

hasta un prefijo de subred /64. Las subredes de Atlixco pueden usar 2001:1db8:abcd:3f00:: y

2001:1db8:abcd:3fff:: para direcciones de subred.

Cada subred ofrece 264 direcciones, ya que todavía se tienen 64 bits para su uso, por ejemplo, dentro

de la Red de área local virtual (VLAN) utilizada solo para servidores de correo todas las direcciones de

nodo comenzaran con 2001:1db8:abcd:3f0d:: y los últimos 64 bits serán el identificador de interfaz

establecido por la regle EUI-64 o por el administrador de red mediante un servidor DHCP.

Sitio 8 (Querétaro)

Querétaro - 2001:0db8:abcd:8000::/56 -- Primer Sub-Sitio

...

Uso futuro - 2001:0db8:abcd:8f00::/56 -- Último Sub-Sitio

Sitio 9 (Nuev o León)

Monterrey - 2001:0db8:abcd:9000::/56 -- Primer Sub-Sitio

...

Uso futuro - 2001:0db8:abcd:9f00::/56 -- Último Sub-Sitio

Firewall exterior - 2001:0db8:abcd:3f00::/64

Serv idores de Web - 2001:0db8:abcd:3f01::/64

Serv idores de bases de datos - 2001:0db8:abcd:302::/64

....

Serv idores de Correo - 2001:0db8:abcd:3f0d::/64

....

Gestión - 2001:0db8:abcd:3fee::/64


56

Figura 2.22. Direcciones de nodo.

Figura 2.23. Topología de red para el ejemplo de subnetting

Como se puede ver el subneting IPv6 no es igual al de IPv4 ya que en IPv6 no hay problemas de

direccionamiento en el que se tienen que aprovechar al máximo todas las direcciones, ya que IPv6 el

espacio de direcciones no es problema.

2.3 Mecanismos para asignar direccionamiento IPv6 en hosts.

2.3.1 Autoconfiguración sin estado

La autoconfiguración de direcciones sin estado (Stateless Address Auto-Configuration, SLAAC) hace

uso del protocolo denominado “Neighbor Discovery” o protocolo de descubrimiento de vecinos el cual

a su vez se encuentra especificado dentro del protocolo ICMPv6.

Gateway de correo : 2001:0db8:abcd:3f0d::1/64

Mail01 : 2001:0db8:abcd:3f0d:0000:0000:0000:0002 / 64

Mail02 : 2001:0db8:abcd:3f0d::ab00/64

Mail03 : 2001:0db8:abcd:3f0d:abcd: EF12::1/64

mail01mail03

mail02

2001:0db8:1234:3f0d::2/64 2001:0db8:1234:3f0d:abcd:ef12::1/64

2001:0db8:1234:3f0d::ab00/64

Mail

Gateway

2001:0db8:1234:3f0d::1/64


57

Internet Control Message Protocol para IPv6 (ICMPv6)

Este protocolo de capa 3 tiene el mismo objetivo que ICMPv4, ser el protocolo de control de IPv6, con

el cual es posible verificar sí un host determinado se encuentra en línea, si un servicio está disponible o

no es alcanzable, el actual “throughput” y velocidad de los medios involucrados el ruteo que están

tomando nuestros paquetes y como un elemento nuevo en IPv6 el permite la auto-configuración de los

nodos además de otras cosas.

El cuerpo del encabezado de ICMPv6 es extremadamente sencillo aunque el cuerpo (los datos) varía

fuertemente. La figura 2.24 marca el formato de dicho encabezado:

Tipo Código Cheksum

Cuerpo del mensaje

8 16 24

Figura 2.24. Formato del encabezado ICMPv6

Los diferentes tipos de mensajes que genera ICMPv6 se pueden apreciar en el RFC 246 y la tabla 2.4

muestra solo unos cuantos de estos “tipos” con sus respectivos códigos. Se puede apreciar que la

mayor parte de estos mensajes poseen contrapartes en IPv4, para este tema los mensajes de interés para

la autoconfiguración sin estado son los de tipo 133 a 137.

Tipo Código

Valor Significado Valor Significado

1 Destination Unreachable

0 No route to destination

1 Communication with destination administratively prohibited

2 Beyondscope of source address

3 Address unreachable

4 Port unreachable

5 Source address failed ingress/egress policy

6 Reject route to destination

7 Error in source Routing Header

2 Packet Too Big 0

3 Time Exceeded 0 Hop limit exceeded in transit

1 Fragment reassembly time exceeded

4 Parameter Problem

0 Erroneous header field type encountered

1 Unrecognized Next Header type encountered

2 Unrecognized IPv6 option encountered

100 Priv ate experimentation

101 Priv ate experimentation

127 Reserv ed for expansion of


58

ICMPv 6 error messages

128 Echo Request 0

129 Echo Reply 0

133 Router Solicitation (NDP) 0

134 Router Adv ertisement (NDP) 0

135 Neighbor Solicitation (NDP) 0

136 Neighbor Adv ertisement (NDP) 0

137 Redirect Message (NDP) 0

Tabla 2.4. Diferentes tipos de mensajes ICMPv6

Neighbor Discovery Protocol (NDP)

Su función es permitir la configuración de un nodo de forma automática mediante lo denominado

“stateless”, detectar su Gateway y configurarlo así como validar la existencia de vecinos locales. Viene

a sustituir el hibrido de ARP, ICMP Router Discovery (RDISC) e ICMP Redirect de IPv4.

Este protocolo hace un uso intensivo de tres direcciones de IPv6 las cuales son:

Dirección invalida ( :: )

Dirección Multicast de alcance local a todo los nodos (FF::01)

Una dirección Multicast de alcance local denominada SNMA (Solicited Node Multicast

Address) que utiliza los 24 bits más bajos de la MAC del nodo.

NDP consiste primordialmente en cuatro mensajes ICMv6 los cuales son:

Mensaje de solicitud de vecino (Neighbor Solicitation Message, NS)

Mensaje de anuncio de vecino (Neighbor Avertisement Message, NA)

Mensaje de solicitud de enrutador (Router Solicitation Message, RS)

Mensaje de anuncio de enrutador (Router Advertisement Messaje, RA)

El primer par se maneja entre nodos cuando se están asignando direcciones y cuando se desea

establecer una comunicación con un nodo local. El segundo grupo es el que permite que el nodo

conozca que direcciones de otros alcances debe de configurar (si sus prefijos son de 64 bits) y registra

al Gateway.

Los resultados de SLAAC se describen en los siguientes seis pasos.

1. Habilitar interfaz (primera vez)


59

2. Auto-Configuración de la dirección local (FE80::/10) y su respectivo “Duplicated Address

Detection” (DAD).

3. Envió del mensaje “Router Discovery” .

4. (Opcional) Si un enrutador respondió el mensaje del paso 2 entonces tomar de su respuesta los

prefijos de las direcciones globales correspondientes y generar SLAAC en cada una de ellas

(Solo direcciones con prefijo de 64).

5. (Opcional) Envío de mensaje “Default Router Neighbor Discovery” (Request).

6. (Opcional) Espera de captura y toma de información de “Default Router Neighbor Discovery”

(Reply).

7. Por cada dirección global que se tenga, realizar un DAD

Lo que diferencia cada mensaje en cada paso serán los campos de direcciones y los datos del mensaje ICMP. La tabla 2.5muestra un resumen de tales pasos.

Proceso Mensaje D. Origen D. Destino Características Adicionales

1** DAD

Neighbor Solicitation

:: FF02::1:FF [TentL]

El campo target posee la dirección Unicast

(FE80::/10) tentat iva.

Si aparece ste mensaje significa que la

dirección tentat iva ya esta tomada.

2

Router Discov ery

Router Solicitation FE80:: [Tentativa] FF02::1:FF [TentL]

Si la dirección origen es la invalida entonces

no hay “Source-Link Address”. Este mansaje

dispara el mensaje del paso 3 (si ex isten

enrutadores en el enlace local).

3 Global Prefix

Router Adv ertisement

FF80:: [Asignada] FF02::2

La diferencia entre un mensaje de ste t ipo

automático de un solicitado NDP es el

dest ino, si se ut ilza la dirección All-Nodes es

el primer caso. En este punto se asignan

direcciones tentat ivas de las direcciones

globales.

4

Neighbor Discov ery (Request)

Neighbor Solicitation

FE80:: [Asignado] FF02:1:FF [RoutL] El campo Link-Layer Address contendrá la

MAC Address del nodo origen. Este paso

solo ocurre si ex iste un router.

5

Neighbor Discov ery

(Reply)

Neighbor Adv ertisement

FE80:: [Asignado] FE80:: [RoutL]

6

Global DAD

Neighbor

Solicitation :: FF02::1:FF [TentL

El campo target posee la dirección Unicast

(2000::/10) tentat iva. Este paso se repite

para cada dirección global.

* Todas la direcciones (origen y dest ino) t iene un prefijo de 128

** Primero se carga a una dirección local tentat iva, se deja pasar un t iempo aleatorio y entonces se envía el primer mensaje

Tabla 2.5. Pasos para la adquisición de una dirección IPv6 por medio de SLAAC


60

2.3.2 DHCP sin estado (Stateless)

Existe una extensión al protocolo DHCPv6 que le permite entregar configuración a los hosts sin

mantener información de su estado. Este mecanismo es útil para que los hosts obtengan información

adicional a la dirección IP, como puede ser una lista de servidores DNS, sin que necesite reservar

ningún recurso en el servidor. Para que este mecanismo funcione los hosts deben adquirir una dirección

IP por otra vía, típicamente a través del mecanismo de auto configuración sin estado SLAAC,

mencionado anteriormente.

2.3.3 DHCP con estado (Statefull)

Los conceptos básicos del esquema cliente-servidor del DHCPv6 son muy parecidos a los de DHCP

para IPv4. La figura 2.25 muestra un esquema representativo para este proceso.

Figura 2.25 esquema del funcionamiento de DHCPv 6

Si existe un enrutador en la red, este manda un mensaje de RA con los bits “O” o “M”

establecidos.

Si el bit “O” está habilitado, pero no así el “M” los hosts podrán solicitar del servidor

DHCPv6 otros parámetros de configuración como servidores DNS, SIP, NTP, etc, y

utilizar el proceso de autoconfiguración para establecer los parámetros de la red, este

mecanismo se conoce como “configuración sin estado usando DHCPv6”, porque el

servidor DHCPv6 no necesita llevar un control de las direcciones IP de la red.

Cliente DHCPv6 Servidor DHCPv6

Enrutador del enlace

local

RA con bits “O” y/o

“M” establecidos

Reply

Request

Advertise

Solicit

1

2

3

4

5


61

Si el bit “M” está habilitado, los hosts pueden solicitar direcciones manejadas por el

servidor DHCPv6, este se considera el mecanismo de “configuración con estado

utilizando DHCPv6”.

Si un host necesita localizar un servidor DHCPv6 envía un mensaje DHCPv6 “solicit” a la

dirección Multicast de todos los agentes de reenvió y servidores DHCPv6 de enlace

(FF02::1:2).

Los agentes y servidores DHCPv6 envían a la dirección Multicast de todos los hosts (FF02::1)

mensajes DHCPv6 “advertise” anunciando su funcionalidad como servidor DHCPv6.

Los host interesados en recibir la configuración de un servidor DHCPv6 envían un mensaje

“request” al servidor seleccionado.

El servidor DHCPv6 le envía al host solicitante los parámetros de configuración solicitados.

2.4 Enrutamiento IPv6

El enrutamiento es el proceso de reenviar paquetes entre segmentos de red conectados. En las redes

basadas en IPv6, el enrutamiento es la parte de IPv6 que proporciona capacidades de reenvío entre

hosts que se encuentran en segmentos independientes que pertenecen a otras redes basadas en IPv6.

Cada paquete entrante o saliente se denomina paquete IPv6. Un paquete IPv6 contiene la dirección de

origen del host que realiza el envío y la dirección de destino del host receptor. A diferencia de las

direcciones de nivel de enlace, las direcciones IPv6 del encabezado IPv6 no suelen cambiar cuando el

paquete se transmite por una red IPv6.

2.4.1 Enrutamiento estático IPv6

Una red IP de rutas estáticas no emplea protocolos de enrutamiento como RIP, OSPF, IS-IS, etc. para

comunicar información de enrutamiento entre enrutadores. Toda la información de enrutamiento se

almacena en una tabla de rutas estáticas en cada enrutador. Es necesario asegurarse de que cada

enrutador tenga las rutas adecuadas en su tabla de modo que pueda intercambiar tráfico entre dos

extremos de la red IP.

Las desventajas del enrutamiento estático son:

No existe tolerancia a errores.


62

Si un enrutador o un enlace dejan de funcionar, los enrutadores no detectan el error ni informan a otros

enrutadores. Aunque esto supone un problema para las grandes redes corporativas, en una oficina

pequeña (con dos enrutadores y tres redes basadas en enlaces LAN) no se interrumpe con la frecuencia

suficiente como para justificar la implementación de una topología de varias rutas de acceso y un

protocolo de enrutamiento.

Sobrecarga administrativa.

Si se agrega una nueva red o se quita, las rutas a esa nueva red deben agregarse o quitarse de forma

manual. Si se agrega un nuevo enrutador, debe configurarse correctamente para las rutas de la red.

Las rutas estáticas se pueden agregan manualmente. Una vez completada la configuración, se pueden

usar los comandos “ping” y “tracert” para probar la conectividad entre equipos host de modo que se

comprueben todas las rutas de enrutamiento.

2.4.2 Enrutamiento dinámico IPv6

Los protocolos de enrutamiento se usan para facilitar el intercambio de información de enrutamiento

entre los enrutadores. Estos protocolos permiten a los enrutadores compartir información en forma

dinámica sobre redes remotas y agregar esta información automáticamente en sus propias tablas de

enrutamiento.

Los protocolos de enrutamiento dinámico determinan el mejor camino hacia cada red, que luego se

agrega a la tabla de enrutamiento. Uno de los principales beneficios de usar un protocolo de

enrutamiento dinámico es que los enrutadores intercambian información de enrutamiento cuando se

produce un cambio de topología. Este intercambio permite a los enrutadores obtener automáticamente

información sobre nuevas redes y también encontrar rutas alternativas cuando se produce una falla de

enlace en la red actual.

En comparación con el enrutamiento estático, los protocolos de enrutamiento dinámico requieren

menos sobrecarga administrativa. Sin embargo, el costo de usar protocolos de enrutamiento dinámico

es dedicar parte de los recursos del enrutador para la operación del protocolo.


63

Los Protocolos de Enrutamiento se dividen en dos grupos, protocolos internos y protocolos externos.

1. Internal Gateway Protocol (IGP), que distribuyen la información de los enrutadores dentro de

Sistemas Autónomos.

En IPv4: RIP, OSPF, IS-IS.

En IPv6: RIPng, OSPFv3, IS-IS.

2. External Gateway Protocol (EGP), que distribuyen la información entre Sistemas Autónomos.

En IPv4:BGP-4.

En IPv6:BGPv6

2.4.2.1 Routing Information Protocol Next Generation (RIPng)

RIP es un protocolo de enrutamiento dinámico IGP que normalmente se utiliza en una red de tamaño

mediano. La versión para IPv6 llamada RIPng (RIP next generation), es una versión mejorada de

RIPv2 la cual tiene las mismas características como el utilizar el algoritmo de Bellman-Ford para el

vector distancia, cada 30 segundos hace una actualización de su tabla de enrutamiento, tiene métricas

fijas y su alcance son 15 saltos.

Los cambios que sufre RIP para IPv6 se describen a continuación:

Rutas publicadas. RIPng publica las rutas IPv6 en una manera compuesta por el prefijo IPv6, la

longitud y la métrica.

Siguiente salto. La dirección del siguiente salto es la dirección IPv6 de enlace-local de la

interface del enrutador que está publicando el prefijo.

Protocolo de transporte. IPv6 utiliza UDP como protocolo de transporte para los datagramas

RIP. Otro cambio es que el puerto que utiliza para UDP es el 521 en lugar del 520 como lo

hacía RIP y RIPv2.

Dirección origen IPv6. La actualización de la dirección origen IPv6 es la dirección enlace-local

de la interface que lo origina.

Dirección destino IPv6. La actualización RIP de la dirección destino IPv6 es FF02::9, la cual

es una dirección Multicast que es escuchada únicamente por enrutadores con RIPng

configurado.

Límite de saltos. Los paquetes IPv6 de actualizaciones RIP tienen un límite de saltos

configurado de 255.


64

Entradas enrutamiento. La entrada de enrutamiento IPv6 está separada de la entrada de

enrutamiento IPv4 que se utiliza para RIPv1 o RIPv2. La ruta por defecto es anunciada como

“::/0”.

Autenticación. En IPv4 las dos versiones de RIP tenían su autenticación específica, en RIPng

la autenticación está basada en IPsec.

2.4.2.2 Open Shortest Path First para IPv6 (OSPFv3)

El OSPF que se utiliza para IPv6 es conocido como OSPFv3, el cual comparte los mismos

fundamentos que OSPFv2 que se utiliza para IPv4.

Varios cambios fueron introducidos para que OSPFv3 pudiera soportar el nuevo protocolo enrutado

IPv6, tales como:

LSAs de la red y del enrutador. Estos LSAs (Link State Advertisements o anuncios de estado

del enlace) sólo tienen información de la topología de la red.

Nueva LSA Intra-Area-Prefijo. Este anuncio lleva la dirección IPv6 y los prefijos.

Direcciones en LSA. Estas son descritas como prefijos con una longitud de prefijo.

Identificador del enrutador. Todavía cuenta con 32 bits, pero ahora define si cuenta con

direcciones IPv4 o IPv6. Este es usado en DR (enrutadores designados), BDR (enrutadores

designados de respaldo) y LSAs.

Siguiente salto. La dirección del siguiente salto es la dirección IPv6 enlace-local de la interface

del enrutador que está haciendo el anuncio.

Nueva LSA de enlace-local. Este anuncio lleva la dirección enlace-local de la interface del

enrutador, el prefijo del enlace y las opciones.

OSPF corre ahora en un enlace completo y no sólo en una subred como sucedía en IPv4.

La dirección IPv6 origen de los paquetes OSPF es la dirección enlace-local de la interface del

enrutador que origina el paquete.

Todos los enrutadores OSPF envían paquetes Hello y escuchan la dirección Multicast FF02::5.

Los enrutadores designados y el de backup DR envían y escuchan la dirección Multicast

FF02::6.

El límite de saltos de los paquetes OSPF es igual a 1.

La autenticación de OSPF está basada en IPsec al igual que RIPng.


65

2.4.2.3 Integrated System to Integrated System (IS-IS)

IS-IS (Intermediate System to Intermediate System) es un protocolo IGP de enrutamiento dinámico de

estado de enlace que fue diseñado como un protocolo de enrutamiento independiente. IS-IS fue

fácilmente adaptado para IPv6 únicamente añadiendo un pocos valores-tipo-longitud (TLV). Dado a

que no hubo cambios de mayor magnitud en el protocolo IS-IS propiamente, no se tuvo que hacer una

nueva versión del protocolo para soportar IPv6.

Debido a que IS-IS utiliza una encapsulación de capa 2, no es necesaria una dirección IP en el paquete.

La implementación de IS-IS es considerada más fácil que la de OSPFv3.

Algunos de los pequeños cambios que sufrió IS-IS para poder soportar IPv6 se detallan a continuación:

Un nuevo TLV tipo 236 de IPv6 alcanzable, el cual no es más que un aviso de ruta IPv6 el cual

contiene el prefijo IPv6, la longitud del prefijo, la métrica e información adicional.

Un nuevo TLV de dirección IPv6 de la interface (tipo=232), el cual para paquetes Hello es la

dirección enlace-local del enrutador.

Un IPv6 NLPID (Network Layer Protocol Identifier) con valor 142, el cual es enviado por los

enrutadores para anunciar el soporte del enrutamiento IPv6 para IS-IS.

La base de datos de IS-IS de la topología de la red IPv4 y de la topología de red IPv6 deben de ser

idénticas en un escenario integral de IS-IS, pero al igual que con OSPFv3, las bases de datos pueden

ser diferentes, para cada topología de red, utilizando el concepto de “buques en la noche”.

2.4.2.4 Border Gateway Protocol para IPv6 (BGPv6)

BGP es un protocolo utilizado para intercambiar rutas entre distintos dominios administrativos

llamados sistemas autónomos (AS), Cuando BGP es usado entre distintos proveedores para

intercambiar rutas se le llama BGP externo (eBGP). Cuando es usado dentro de un sistema autónomo

se le llama BGP interno (iBGP).

El BGP Multiprotocolo (MBGP) es una versión extendida de BGP creada para soportar múltiples

protocolos de red o familias de direcciones. Una nueva familia de direcciones en MBGP es definida

para IPv6 (RFC2545). Esta versión de BGP que soporta IPv6 fue llamada BGP4+ (RFC 4271).


66

Algunos de los cambios realizados sobre MBGP para poder soportar IPv6, se listan a continuación:

Como siguiente salto en MBGP para IPv6, se puede configurar una dirección IPv6 ya sea

global o de sitio.

Con lo que respecta a NLRI (Network Layer Reachability Information) la ruta anunciada, es

expresada como un prefijo IPv6 con su respectiva longitud.

Se cuenta con una nueva dirección de familia para identificar las rutas IPv6.

2.5 Mecanismos de transición

Aun cuando el espacio de direcciones IPv4 avanza rápidamente hacia el agotamiento de las

direcciones, el protocolo original de internet seguirá vigente por años e incluso décadas, existiendo

redes IPv4 que coexistirán con los despliegues IPv6.

Pese a que ambos protocolos son incompatibles entre sí, para poder permitir la coexistencia de IPv6

con IPv4 y la compatibilidad con las redes actuales, el Grupo de Trabajo de Transición a IPng de la

IETF ha diseñado herramientas, protocolos y mecanismos que pueden ser utilizados para permitir una

transición de redes IPv4 hacia IPv6. Las estrategias diseñadas se dividen en tres clases:

Doble Pila

Túneles

Traducción

2.5.1 Doble Pila

Cuando una red se configura como doble pila, cada dispositivo de la red está configurada tanto con una

dirección IPv4 y una dirección IPv6, la idea es que una vez que en todos los dispositivos se ha

implementado IPv6, se amortizará la parte IPv4 de la red. Este método es común para las empresas que

buscan convertir poco a poco sus dispositivos actuales de IPv4 a IPv6. Estas empresas pueden

configurar su infraestructura de enrutamiento para soportar IPv4 e IPv6, pero traer a sus otros

dispositivos de red a través de IPv6 a un ritmo más lento.

Cuando las dos pilas son utilizadas en los nodos conectados a las redes en los cuales ambos protocolos

están habilitados simultáneamente, el modo de pila dual provee a los nodos la flexibilidad para


67

establecer sesiones extremo a extremo sobre IPv4 o IPv6.Cuando un dispositivo tiene capacidades de

doble pila, entonces tiene acceso tecnologías a IPv4 e IPv6 disponibles. Se puede utilizar tanto de estas

tecnologías para conectarse a servidores remotos y destinos en paralelo.

Cuando un cliente desea conectarse a un servidor (www.xxxx.com), el cliente emite dos peticiones

DNS en paralelo: una solicitud de direcciones IPv4, y una solicitud para direcciones IPv6. Después de

recibir las respuestas, la selección para IPv6 se inclina hacia la doble pila, en un estado de transición

en una red IPv6, por lo tanto prefiere IPv6 sobre IPv4 por diseño.

Cuando un cliente recibe una respuesta que incluye tanto una dirección IPv4 y la dirección IPv6 a

continuación, la dirección IPv6 es la dirección preferida. Si, por cualquier razón, el uso de esa

dirección no fue exitosa, se utilizará una dirección alternativa, potencialmente, una dirección IPv4

válida para conectarse.

Es posible que un dispositivo de doble pila quiera conectarse a un dispositivo de sólo IPv4 o IPv6

solamente. El protocolo seleccionado, IPv4 o IPv6 se basa en las direcciones IP recibidas dentro de una

respuesta DNS. Si el servidor DNS devuelve sólo las direcciones IPv4, a continuación, se utiliza IPv4,

si el servidor DNS devuelve sólo las direcciones IPv6 entonces IPv6 se utiliza.

Figura 2.26. Esquema de una red de doble pila

Cliente IPv4Cliente IPv6

Cliente IPv4/IPv6

IPv4/IPv6

Dual Stack

IPv4IPv6

www.xxx.com

Servidor DNS


68

2.5.2 Túneles

Son técnicas para establecer túneles punto a punto que permiten el tráfico de paquetes IPv6 sobre

estructuras de red IPv4, o al inverso. Permiten transmitir paquetes IPv6 a través de la infraestructura

IPv4 existente, sin la necesidad de realizar cambios a los mecanismos de enrutamiento, encapsulando

el contenido del paquete IPv6 en un paquete IPv4.

Los túneles pueden ser clasificados de la siguiente forma:

Tunelización enrutador-a-enrutador. EnrutadoresIPv6/IPv4, conectados por una red IPv4, que

pueden intercambiar paquetes IPv6 entre sí, completando el segmento del camino entre dos hosts IPv6.

6to4 es una de las técnicas más difundidas (aunque tiene asociadas problemáticas técnicas que afectan

la continuidad de las comunicaciones) entre hosts IPv6 a través de una infraestructura IPv4,

proveyendo una dirección IPv6 única, formada por el prefijo de la dirección global

2002:wwxx:yyzz::/48, donde wwxx:yyzz es la dirección pública del host en hexadecimal. 6to4 es

recomendada por la RFC 3056 (Connection of IPv6 Domainsvia IPv4 Clouds) como mecanismo de

tunelización automática.

Figura 2.27. Tunelización enrutador-a-enrutador

Tunelización host-a-enrutador y enrutador-a-host. En el caso Host-a-Ruteador, hosts IPv6/IPv4

envían paquetes IPv6 a un enrutador IPv6/IPv4 intermediario en una red IPv4, conectando el primer

segmento del camino entre dos hosts. Para el camino inverso, enrutadores IPv6/IPv4 envían paquetes

IPv6 al destino final IPv6/IPv4, conectando el último segmento del camino entre dos hosts. ISATAP es

una técnica que posibilita la creación de túneles que conectan hosts a enrutadores a través de una red

IPv4. La dirección IPv6 asignada a los hosts y enrutadores es basada en un prefijo Unicast de 64 bits,

que puede ser link-local, un prefijo 6to4, o un prefijo global asignado por un proveedor.

Red IPv4

Red IPv6 Red IPv6

Enrutador

IPv4/IPv6Enrutador

IPv4/IPv6

SiSi SiSi

http://www.ipv6.cl/pagina/la-problematica-asociada-6to4-y-alternativas-para-traduccion-de-direcciones

http://tools.ietf.org/html/rfc3056


69

Figura 2.28. Tunelización host-a-enrutador

Figura 2.29. Tunelización enrutador-a-host

Tunelización host-a-host. Hosts IPv6/IPv4, conectados por una red IPv4, intercambian paquetes IPv6

entre sí, conectando todo el camino entre los dos hosts.

Figura 2.30. Tunelización host-a-host

Túnel 6to4

6to4 es un protocolo de configuración automática de túnel (autotunneling) junto con una estructura de

direccionamiento. La dirección IPv6 de un host 6to4 alcanzable comienza con el prefijo de IPv6

2002::/ 16. La arquitectura de la dirección incrusta una dirección IPv4 de 32 bits del host extremo en

los próximos 32 bits. De esta manera la dirección IPv6 lleva la dirección IPv4 "equivalente" a la

dirección IPv6.

Red IPv6

Red IPv4

Red IPv6

Enrutador

IPv4/IPv6Enrutador

IPv6

Host

IPv6Host

IPv4/IPv6

SiSi SiSi

Red IPv6

Red IPv4

Red IPv6

Enrutador

IPv4/IPv6Enrutador

IPv6

Host

IPv6Host

IPv4/IPv6

SiSi SiSi

SiSiSiSi

Red IPv4 Red IPv4Red IPv4Enrutador

IPv4Enrutador

IPv4Anfitrión

IPv6/IPv6Anfitrión

IPv4/IPv6


70

Figura 2.31. Dirección IPv6 de un host 6to4

Para enviar un paquete IPv6, el host local necesita primero un túnel a través de la red IPv4 local. Para

realizar este túnel, el host local encapsula el paquete IPv6 en un encabezado exterior de paquetes

IPv4. El protocolo IP utilizado no es el TCP ni UDP, sino un número de protocolo IP reservado para

los paquetes IPv6.

El paquete IPv4 está dirigido a un relay de IPv4 a IPv6. Para evitar la configuración manual de cada

cliente, todos estos relays comparten la misma dirección Anycast 192.88.99.1. Estos relays tiran el

encabezado exterior de paquetes IPv4 fuera del paquete y envían el paquete IPv6 en la red IPv6. El

destino IPv6 trata el paquete de forma normal, y genera un paquete de respuesta sin el proceso especial.

Figura 2.32. Esquema de un Túnel 6to4

10110001 00001001 10101000 10000011

0010000 00000010 10110001 00001001 10101000 10000011

Dirección Global Unica IPv4

177.9.168.131

Prefijo 6to4

2002::/16

2002:B109:A883::/16

Isla B doble pila

Isla A doble pila

Internet IPv6

Internet IPv4

Enrutador 6to4 Enrutador

6to4

6to4relay

6to4relay

Túnel 6to4

Servidor IPv6

Servidor IPv6


71

Túnel 6in4 y Túnel Broker.

Un túnel 6in4 es un protocolo de configuración manual, este túnel se considera se considera un enlace

punto a punto desde el punto de vista de IPv6, las direcciones IPv6 de ambos extremos del túnel son

del mismo prefijo. Todas las conexiones IPv6 del nodo final siempre pasan por el enrutador que está en

el extremo final del túnel. Los túneles 6in4 pueden construirse desde nodos finales situados detrás de

NAT.

Para facilitar la asignación de direcciones y creación de túneles 6in4 se ha desarrollado el concepto de

Tunel Broker (TB), el cual es un intermediario al que el usuario final se conecta, normalmente con una

interfaz Web, el usuario solicita al TB la creación de un túnel y este le asigna una dirección IPv6 y le

proporciona instrucciones para crear el túnel en el lado del usuario, el TB también configura el

enrutador que representa el extremo final del túnel para el usuario.

Internet IPv4

Router servidor de túneles

Internet IPv6

Interfaz Web

Cliente

Túnel 6in4

2001:db8:40:2a0a::82/126

2001:db8:40:2a0a::81/126

Figura 2.33. Esquema de un Túnel 6in4


72

Intra-Site Automatic Tunneling Addressing Protocol (ISATAP)

ISATAP define un método para generar una dirección IPv6 local a partir de una dirección IPv4, y un

mecanismo para realizar el protocolo de descubrimiento de vecinos (Neighbor Discovery Protocol)

sobre IPv4.

Generación de la dirección local (Link-local). Cualquier máquina que desee participar en ISATAP

sobre una red IPv4 puede establecer una interfaz de red IPv6 virtual. La dirección local se determina

mediante la concatenación de fe80:0000:0000:0000:0000:5efe: con los 32 bits de la dirección IPv4

(expresado en notación hexadecimal).

Por ejemplo, el host 192.0.2.143 utilizaría fe80:0000:0000:0000:0000:5efe:c000:028f como su

dirección IPv6 local (192.0.2.143 es c000028f en la notación hexadecimal). La notación simplificada

sería fe80::5efe:c000:28f.

Descubrimiento de vecinos . Como ISATAP utiliza IPv4 como un nivel de enlace sin capacidad de

Multicast/broadcast (al contrario que Ethernet), el ICMPv6 Neighbor Discovery no se puede hacer de

la forma habitual. Este es el motivo por el que ISATAP es un poco más complejo que 6over4.

El nivel de enlace asociado con una dirección IPv6 dada está incluido en los 32 bits más bajos de la

dirección IPv6, por lo que el descubrimiento de vecinos no se necesita realmente. Sin embargo, la falta

de capacidad Multicast impide el uso del descubrimiento automático del enrutador (Router Discovery).

Por lo tanto, los hosts con ISATAP tienen que configurar una lista de enrutadores posibles (potential

routers list o PRL). Cada uno de estos enrutadores son sondeados con poca frecuencia por un

mensaje ICMPv6 de Descubrimiento de enrutador, para determinar cuáles de ellos están funcionando,

y para realizar la autoconfiguración de direcciones Unicast.

En la práctica, las implementaciones construyen su PRL consultando el DNS, por ejemplo,

preguntando por isatap.example.com si el dominio local esexample.com. El dominio local se obtiene a

través de DHCP (sobre IPv4) o se configura localmente.

Teredo

Distintos mecanismos de transición trabajan con hosts de IPv6 identificados por direcciones IPv4, sin

embargo, estos mecanismos no soportan conectividad IPv6 a hosts aislados detrás de un NAT. Las

direcciones privadas no pueden ser usadas en redes públicas como un mecanismo 6to4. Acoplar un

http://es.wikipedia.org/wiki/Direcci%C3%B3n_IPv6

http://es.wikipedia.org/wiki/Neighbor_Discovery

http://es.wikipedia.org/wiki/Ethernet

http://es.wikipedia.org/w/index.php?title=ICMPv6_Neighbor_Discovery&action=edit&redlink=1

http://es.wikipedia.org/wiki/6over4

http://es.wikipedia.org/w/index.php?title=Router_Discovery&action=edit&redlink=1

http://es.wikipedia.org/wiki/ICMPv6

http://es.wikipedia.org/wiki/DNS

http://es.wikipedia.org/wiki/DHCP


73

NAT y un mecanismo de túnel no es escalable y puede producir resultados inesperados, como deterioro

en la calidad de la transmisión e inclusive el mismo servidor del túnel se puede convertir en un “cuello

de botella” en la trayectoria de transmisión.

Tratando de ofrecer una alternativa a los usuarios privados detrás de un NAT, se propone Teredo para

proveer conectividad IPv6 a hosts aislados detrás de un NAT. Teredo provee un túnel automático

extremo a extremo a sitios Teredo y ofrece trayectorias a hosts de solo IPv6.

Teredo se compone de tres elementos: un servidor Teredo, un retransmisor Teredo y un cliente Teredo.

El servidor provee su dirección IPv4 al cliente; una vez que el cliente aprende la dirección IPv4,

automáticamente construirá la dirección IPv6 del servidor donde la dirección de IPv4 está incrustada.

El retransmisor ayuda a los clientes a conectarse a hosts de solo IPv6. Las comunicaciones de hosts

solo IPv6 en el “backbone” no están soportadas de forma inmediata. En lugar de eso, el servidor

Teredo mediará entre los clientes Teredo y los retransmisores Teredo y seleccionará el apropiado, el

cual es seleccionado por la distancia entre el cliente y el retransmisor, así como el número de clientes a

los cuales les provee servicio el retransmisor.

El cliente Teredo es un nodo que reside detrás de un NAT y que desea tener conectividad IPv6. Para la

configuración de la dirección, el cliente obtiene el prefijo del servidor; especialmente, se requiere que

el cliente tenga una dirección IPv4 antes del proceso de calificación con el fin de mantener el mapeo de

dirección y número de puerto asociado con el puerto de servicio Teredo.

2.5.3 Traducción

Hasta ahora se han visto dos formas generales del enfoque de redes híbridas que están destinadas a

apoyar tanto la transición IPv6 y mayores niveles de uso de direcciones en IPv4, es decir, abordar el

mapeo y excavación de túneles. Un tercer enfoque se encuentra en el área de la traducción de

protocolo.

Técnicas de traducción realizan la traducción de IPv4 a IPv6 y viceversa a una determinada capa de la

pila de protocolos, por lo general la capa de red, el transporte o aplicación. A diferencia de un túnel, los

mecanismos de traducción no modifican los paquetes IP comúnmente entre IPv4 e IPv6. Enfoques de

traducción recomiendan generalmente en un entorno con nodos sólo IPv6 comunicarse con nodos sólo

IPv4.


74

Network Address Translation with Protocol Translation (NAT-PT)

El proceso de NAT-PT, que todavía está en fase experimental, implica la traducción de direcciones

IPv4 en direcciones IPv6, como un IPv4 NAT familiar, sino que también realiza la traducción de

encabezado.

NAT-PT sirve como Gateway entre una red IPv6 y una red IPv4 y permite a los dispositivos IPv6

nativo para comunicarse con anfitriones de Internet IPv4, por ejemplo. El dispositivo NAT-PT

mantiene un conjunto de direcciones IPv4 y asocia una dirección IPv4 dada con una dirección IPv6.

NAPT-PT permite a los nodos IPv6 comunicarse con nodos IPv4 utilizando una sola dirección IPv4.

Por lo tanto, en lugar de mantener una asociación uno a uno de una dirección IPv6 y una dirección

IPv4, cada dirección IPv6 a una dirección IPv4 común establece con un único valor TCP o UDP fijado

en el paquete IPv4 correspondiente. El uso de una única dirección IPv4 compartida, elimina la

posibilidad de agotamiento de IPv4 conjunto de direcciones en el escenario de NAT-PT.

Figura 2.34. NAT-PT

NAT64

No era de esperar, NAT-PT está experimentando un renacimiento, esta vez bajo el nombre de

"NAT64." No ha cambiado mucho desde el enfoque básico descrito en NAT-PT. El cliente solo IPv6

realiza una búsqueda de DNS a través de un servidor DNS modificado que está configurado con

DNS64. Si el nombre consultado sólo contiene una dirección IPv4, el servidor DNS64 sintetiza una

respuesta IPv6 mediante la fusión de la dirección de prefijo de la pasarela NAT64 con la dirección

IPv4. Cuando el cliente utiliza esta dirección, el paquete IPv6 se dirige a la puerta de enlace NAT64, y

la misma transformación como se describe previamente para NAT-PT se lleva a cabo.

Esta configuración es similar al modelo de CGN, en la medida en que el proveedor de servicios opera

un NAT común que comparte un conjunto de direcciones IPv4 a través de un conjunto de clientes

finales.

Red IPv4 Red IPv6

Anfitrión

IPv4

Anfitrión

IPv6NAT-PT


75

Capítulo 3. Diseño de una red de área local con direccionamiento

IPv6

El protocolo de internet versión 4 y versión 6 coexistirán por varios años, es por eso que se

decidió, en lugar que crear una red IPv6 nativa, diseñar una red de doble pila, es decir una red

que ejecute ambos protocolos a la vez, así los usuarios que quieran acceder a los recursos

IPv6 podrán hacerlo utilizando direcciones IPv6, y las aplicaciones que solo estén disponibles

en IPv4 puedan ser accesibles con direcciones IPv4.

3.1 Topología física

Para el planteamiento de esta propuesta, se tomaron en cuenta algunas recomendaciones para el diseño

de redes de Cisco, entre las cuales la que más destaca es el modelo jerárquico que consta de tres capas:

Capa de acceso

La capa de acceso hace interfaz con dispositivos finales como las PC, impresoras y teléfonos IP,

cámaras, para proveer acceso al resto de la red. Esta capa de acceso puede incluir conmutadores,

puentes, hubs y puntos de acceso inalámbricos. El propósito principal de la capa de acceso es aportar

un medio de conexión de los dispositivos a la red y controlar qué dispositivos pueden comunicarse en

la red.

Capa de distribución

La capa de distribución agrega los datos recibidos de los conmutadores de la capa de acceso antes de

que se transmitan a la capa núcleo para el enrutamiento hacia su destino final. La capa de distribución

controla el flujo de tráfico de la red con el uso de políticas y traza los dominios de broadcast al realizar

el enrutamiento de las funciones entre las LAN virtuales (VLAN) definidas en la capa de acceso. Las

VLAN permiten al usuario segmentar el tráfico sobre un conmutador en subredes separadas. Por

ejemplo, en una universidad el usuario podría separar el tráfico según se trate de profesores, estudiantes

y huéspedes. Normalmente, los conmutadores de la capa de distribución son dispositivos que presentan

disponibilidad y redundancia altas para asegurar la fiabilidad.


76

Capa de núcleo

La capa núcleo del diseño jerárquico es la backbone de alta velocidad de la Internetwork. La capa

núcleo es esencial para la interconectividad entre los dispositivos de la capa de distribución, por lo

tanto, es importante que el núcleo sea sumamente disponible y redundante. El área del núcleo también

puede conectarse a los recursos de Internet. El núcleo agrega el tráfico de todos los dispositivos de la

capa de distribución, por lo tanto debe poder reenviar grandes cantidades de datos rápidamente. En la

figura 3.1 se muestra la distribución de las tres capas del modelo jerárquico de redes.

Capa de

Acceso

Capa de

Distribución

Capa de

Nueclo

Figura 3.1. Modelo Jerárquico de redes.

El diseño propuesto en este documento plantea el escenario de una escuela que consta de 4 edificios y

la unidad de informática. La figura 3.2 presenta un bosquejo de la distribución geográfica de la red, así

mismo nos representa la topología física propuesta empleando el modelo jerárquico de tres capas.

Los conmutadores de la capa de acceso tienen características solo de capa 2 y admiten funcionalidades

como VLANs y seguridad en los puertos, estos conmutadores están repartidos en todos los edificios

dependiendo de la densidad de usuarios y dispositivos finales, se pueden ir agregando mas

conmutadores fácilmente en caso de que aumente el número de usuarios ya que la red esta diseñada

para ser escalable.


77

En la capa de distribución se tienen conmutadores con características de capa 2 y 3 por lo tanto son

capaces de enrutar paquetes, estos conmutadores están distribuidos uno en cada edificio y tienen la

suficiente capacidad de conmutación para procesar de manera óptima el tráfico de los equipos de la

capa de acceso que están conectados a ellos.

En la capa de núcleo existe un conmutador de capa 3 el cual admite protocolos de enrutamiento

avanzado y su rendimiento es mucho más alto que los equipos de la capa de distribución, en esta capa

también se encuentra un enrutador el cual permite la entrega de paquetes que vienen de internet hacia

su destino final. La ubicación física de la red de la capa de núcleo se encuentra en el edificio de la

unidad informática.

EDIFICIO 1 EDIFICIO 2 EDIFICIO 3 EDIFICIO 4

UNIDAD DE

INFORMÁTICA

Figura 3.2 Topología física de la red propuesta


78

3.2 Topología Lógica

3.2.1 Direccionamiento IPv4

La topología lógica de la red define el direccionamiento de la misma y como los paquetes son

trasmitidos. En esta etapa se decidió segmentar el tráfico de cada edificio en seis VLANs las cuales

son:

Estudiantes

Profesores

Administrativos

Visitas

Voz

Servidores

Para la red IPv4 se utilizó la dirección privada 172.16.0.0 /16 la cual fue debidamente segmentada para

las VLANs mencionadas anteriormente por lo cual la asignación de direcciones IPv4 quedo como se

muestra en la tabla 3.1.

Los detalles para asignación de direcciones y la configuración en ipv4 para equipos finales e

intermediarios no se describen ya que no es el objetivo de este trabajo. En su lugar damos por hecho

que la red IPv4 ya existe y es funcional.

La distribución geográfica del direccionamiento IPv4 se muestra en la figura 3.3 y la topología lógica

de la propuesta se muestra en la figura 3.4.


79

Tabla 3.1 Direccionamiento IPv4 de la red propuesta.

La red completa que se propone también consta de tres servidores.

Servidor de DNS: El cual sirve para resolver direcciones IP a nombres fáciles de recordar, funciona

principalmente para la navegación en internet.

Servidor de archivos. Este servidor está compuesto principalmente por unidades de almacenamiento,

que respaldan la información de los usuarios.

Servidor de correo: Funciona para que los usuarios tenga su propia cuenta de correo y puedan enviar y

recibir e-mails.

VLAN ID VLAN NAME NETWORK DEF GATEWAY

IPv4 Network 172.16.0.0 /16

Estu

dia

ntes

2 Estudiantes_2 172.16.2.0 /24 172.16.2.254

3 Estudiantes_3 172.16.3.0 /24 172.16.3.254

4 Estudiantes_4 172.16.4.0 /24 172.16.4.254

5 Estudiantes_5 172.16.5.0 /24 172.16.5.254

6 Estudiantes_6 172.16.6.0 /24 172.16.6.254Es

tudia

ntes

Profe

sore

s

21 Profesores_1 172.16.21.0 /26 172.16.21.62

22 Profesores_2 172.16.22.0 /26 172.16.22.62

23 Profesores_3 172.16.23.0 /26 172.16.23.62

24 Profesores_4 172.16.24.0 /26 172.16.24.62

25 Profesores_5 172.16.25.0 /26 172.16.25.62

Profe

sore

s

Adm

instra

tivo

41 Administrativos_1 172.16.41.0 /27 172.16.41.30




45 Administrativos_5 172.16.45.0 /27 172.16.45.30Adm

instra

tivo

Visita

s

61 Visitas_1 172.16.61.0 /26 172.16.61.62

62 Visitas_2 172.16.62.0 /26 172.16.62.62

63 Visitas_3 172.16.63.0 /26 172.16.63.62

64 Visitas_4 172.16.64.0 /26 172.16.64.62

65 Visitas_5 172.16.65.0 /26 172.16.65.62

Visita

s

Voz

81 Voz_1 172.16.81.0 /27 172.16.81.30

82 Voz_2 172.16.82.0 /27 172.16.82.30

83 Voz_3 172.16.83.0 /27 172.16.83.30

84 Voz_4 172.16.84.0 /27 172.16.84.30

85 Voz_5 172.16.85.0 /27 172.16.85.30

Voz

Serv

idore

s

100 Serv idores_0 172.16.101.0 /29 172.16.101.6

101 Serv idores_1 172.16.101.0 /29 172.16.101.6

102 Serv idores_2 172.16.102.0 /29 172.16.102.6

103 Serv idores_3 172.16.103.0 /29 172.16.103.6

104 Serv idores_4 172.16.104.0 /29 172.16.104.6

105 Serv idores_5 172.16.105.0 /29 172.16.105.6

Serv

idore

s

Enlaces punto a punto

172.16.0.0 /30

172.16.0.4 /30

172.16.0.8 /30

172.16.0.12 /30

172.16.0.16 /30

172.16.0.20 /30

172.16.0.24 /30

172.16.0.28 /30

172.16.0.32 /30



UNIDAD DE INFORMÁTICA

Figura 3.3 Distribución geográfica del direccionamiento IPv4.

VLAN ID VLAN NAME NETWORK DEF. GATEWAY

EDIFIC

IO 1

2 Estudiantes_2 172.16.2.0 /24 172.16.2.254 2 Estudiantes_2 2001:db8:df:0002::/64 2001:db8:df:0002::a/64

EDIFIC

IO 1

21 Profesores_1 172.16.21.0 /26 172.16.21.62


61 Visitas_1 172.16.61.0 /26 172.16.61.62

81 Voz_1 172.16.81.0 /27 172.16.81.30

101 Serv idores_1 172.16.101.0 /29 172.16.101.6

EDIFIC

IO 1


EDIFIC

IO 2

3 Estudiantes_3 172.16.3.0 /24 172.16.3.254 3 Estudiantes_3 2001:db8:df:0003::/64 2001:db8:df:0003::a/64

EDIFIC

IO 2

22 Profesores_2 172.16.22.0 /26 172.16.22.62


62 Visitas_2 172.16.62.0 /26 172.16.62.62

82 Voz_2 172.16.82.0 /27 172.16.82.30

102 Serv idores_2 172.16.102.0 /29 172.16.102.6

EDIFIC

IO 2


EDIFIC

IO 3

4 Estudiantes_4 172.16.4.0 /24 172.16.4.254

23 Profesores_3 172.16.23.0 /26 172.16.23.62


63 Visitas_3 172.16.63.0 /26 172.16.63.62

83 Voz_3 172.16.83.0 /27 172.16.83.30

103 Serv idores_3 172.16.103.0 /29 172.16.103.6

EDIFIC

IO 3


EDIFIC

IO 4

5 Estudiantes_5 172.16.5.0 /24 172.16.5.254

24 Profesores_4 172.16.24.0 /26 172.16.24.62


64 Visitas_4 172.16.64.0 /26 172.16.64.62

84 Voz_4 172.16.84.0 /27 172.16.84.30

104 Serv idores_4 172.16.104.0 /29 172.16.104.6

EDIFIC

IO 4


Figura 3.4. Topología lógica de la red IPv4 propuesta.

172.16.5.0 /24

172.16.24.0 /26

172.16.44.0 /27

172.16.64.0 /26

172.16.84.0 /27

172.16.104.0 /29

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

172.16.100.1/24

Internet

172.16.2.0 /24

172.16.21.0 /26

172.16.41.0 /27

172.16.61.0 /26

172.16.81.0 /27

172.16.101.0 /29

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

172.16.3.0 /24

172.16.22.0 /26

172.16.42.0 /27

172.16.62.0 /26

172.16.82.0 /27

172.16.102.0 /29

EDIF_1

EDIF_2

EDIF_4

EDIF_3

SW0101

SW0102 SW0201

SW0202

SW0301

SW0302

SW0401

SW0402

172.16.0.0 /30172.16.0.4 /30

172.16.0.12 /30

172.16.0.8 /30

172.16.0.16 /30

.1

.2

.5

.6

.9

.10

.13.14

.17

.18

172.16.100.2/24 172.16.100.3/24

SERVIDOR

DE

ARCHIVOS

DNSSERVIDOR

DE CORREO

200.125.10.4

SW_CORE

RO_CORE

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

172.16.4.0 /24

172.16.23.0 /26

172.16.43.0 /27

172.16.63.0 /26

172.16.83.0 /27

172.16.103.0 /29


82

3.2.2 Direccionamiento IPv6

Las recomendaciones para obtener direcciones ipv6 son: solicitar al ISP un prefijo IPv6, la IEEE recomienda que los ISP o RIRs entreguen un prefijo /48 a los clientes finales, de tal modo de que cada prefijo /48 puede tener un total de 65536 subredes /64. Si el ISP no soporta IPV6 (que es la situación actual en México) se puede utilizar un túnel 6to4 a través de los diferentes proveedores de tunelbroker que en su mayoría son gratis ya que estas entidades promueven el despliegue del nuevo protocolo. El único requisito para utilizar un túnel 6to4 es contar con al menos una dirección IPv4 publica de preferencia estática.

Tabla 3.2 Direccionamiento IPv4 de la red propuesta.

VID VLAN NAME PREFIX DEFAULT GATEWAY

IPv6 Prefix 2001:db8:df:: /48

Estu

dia

ntes

2 Estudiantes_2 2001:db8:df:0002::/64 2001:db8:df:0002::a/64




6 Estudiantes_6 2001:db8:df:0006::/64 2001:db8:df:0006::a/64Es

tudia

ntes

Profe

sore

s

21 Profesores_1 2001:db8:df:0021::/64 2001:db8:df:0021::a/64





Profe

sore

s

Adm

instra

tivo

41 Administrativos_1 2001:db8:df:0041::/64 2001:db8:df:0041::a/64




45 Administrativos_5 2001:db8:df:0045::/64 2001:db8:df:0045::a/64Adm

instra

tivo

Visita

s

61 Visitas_1 2001:db8:df:0061::/64 2001:db8:df:0061::a/64





Visita

s

Voz

81 Voz_1 2001:db8:df:0081::/64 2001:db8:df:0081::a/64

82 Voz_2 2001:db8:df:0082::/64 2001:db8:df:0082::a/64

83 Voz_3 2001:db8:df:0083::/64 2001:db8:df:0083::a/64

84 Voz_4 2001:db8:df:0084::/64 2001:db8:df:0084::a/64

85 Voz_5 2001:db8:df:0085::/64 2001:db8:df:0085::a/64

Voz

Serv

idore

s

100 Serv idores_0 2001:db8:df:0100::/64 2001:db8:df:0100::a/64






Serv

idore

s

Enlaces punto a punto

2001:db8:df:fff1::/64

2001:db8:df:fff2::/64

2001:db8:df:fff3::/64

2001:db8:df:fff4::/64

2001:db8:df:fff5::/64

2001:db8:df:fff6::/64

2001:db8:df:fff7::/64

2001:db8:df:fff8::/64

2001:db8:df:fff9::/64


83

En este documento solo se discuten fundamentos teóricos y por tanto se utilizará el prefijo

2001:db8::/32, todas las direcciones que estén dentro de este rango son meramente como propósitos

educativos, no se espera ver un dispositivo con esta dirección en la red publica

Se agregan los siguientes 16 bits como :00ff para obtener un prefijo /48, y resulta en la siguiente

dirección de red.

2001:db8.df::/48

La especificación IPv6 recomienda utilizar prefijos /64 en los dispositivos finales para un mejor

funcionamiento del protocolo, por lo cual la dirección 2001:db8:df:: /48 se dividirá en múltiples

subredes /64, incluso los enlaces punto a punto serán /64.

Para asignar el direccionamiento IPv6 a los equipos, tomaremos como referencia el esquema de la red

IPv4 antes mencionada.

La distribución geográfica del direccionamiento IPv4 se muestra en la figura 3.5 y la topología lógica

de la propuesta se muestra en la figura 3.6.

3.2.2.1 Implementación de direccionamiento IPv6 en dispositivos intermediarios

La asignación de direcciones IPv6 en los dispositivos intermediarios tales como conmutadores,

enrutadores y servidores debe ser de forma estática, para la configuración de estas direcciones existen

dos opciones, escribir los 128 bits de la dirección a asignar en la interfaz, o escribir solo los primeros

64 bits y dejar que el propio equipo obtenga los siguientes 64 bits (interfaz ID) empleando una regla

llamada EUI-64 la cual utiliza la dirección MAC para completar la dirección IP.

En la red propuesta se hará uso de ambos mecanismos y se abordaran con más detalle en el próximo

capítulo.


84

3.2.2.2 Implementación de direccionamiento IPv6 en dispositivos finales

Para la asignación de direcciones de dispositivos finales tales como PC, Laptop, impresoras, etc. Al

igual que en IPv4 se puede hacer mediante asignación dinámica de direcciones (DHCP) o

direccionamiento estático manualmente configurado.

IPv6 introduce una nueva forma de autoconfiguración de direcciones denominada Autoconfiguración

de Direcciones sin Estado (Stateless Address Autoconfiguration SLAAC) el cual se apoya en el

protocolo de descubrimiento de vecinos (Neigtbor Discovery protocol NDP) para determinar las

direcciones que tendrán los dispositivos finales.

En la red propuesta se hará uso de estas técnicas mocionadas y se abordaran con más detalle en el

próximo capítulo.

3.2.2.3 Enrutamiento IPv6

En la red propuesta se hará uso de rutas estáticas y del protocolo de enrutamiento RIPng ya que es una

red relativamente pequeña, en el próximo capítulo se explicara más a fondo como se configura este

protocolo para IPv6 y se demostrará su funcionamiento.


V ID VLAN NAME PREFIJO DEF. GATEWAY

EDIFIC

IO 1


EDIFIC

IO 1




81 Voz_1 2001:db8:df:0081::/64 2001:db8:df:0081::a/64

101 Servidores_1 2001:db8:df:0101::/64 2001:db8:df:0101::a/64

EDIFIC

IO 1

VID VLAN NAME NETWORK DEF. GATEWAY

EDIFIC

IO 2


EDIFIC

IO 2




82 Voz_2 2001:db8:df:0082::/64 2001:db8:df:0082::a/64


EDIFIC

IO 2


UNIDAD DE INFORMÁTICA

Figura 3.5 Distribución geográfica del direccionamiento IPv4.


EDIFIC

IO 3





83 Voz_3 2001:db8:df:0083::/64 2001:db8:df:0083::a/64


EDIFIC

IO 3


EDIFIC

IO 4





84 Voz_4 2001:db8:df:0084::/64 2001:db8:df:0084::a/64


EDIFIC

IO 4


EDIF_

1

EDIF_2

EDIF_4

EDIF_3

SW0101

SW0102SW0201

SW0202

SW0301

SW0302

SW0401

SW0402

2001:db8:df:fff1::/64

2001:db8:df:fff2::/64

2001:db8:df:fff4::/64

2001:db8:df:fff3::/64

2001:db8:df:fff5::/64

::2

::1

::2

::1

::2

::1

::2::1

::1

::2

2001:db8:df:0100::1/64 2001:db8:df:0100::2/64 2001:db8:df:0100::3/64SERVIDOR

DNS

SERVIDOR

DE ARCHIVOSSERVIDOR

DE CORREO

2001:db8:df:0001::1/64

SW_CORE

RO_CORE

2001:db8:df:0002::/64

2001:db8:df:0021::/64

2001:db8:df:0041::/64

2001:db8:df:0061::/64

2001:db8:df:0081::/64

2001:db8:df:0101::/64

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

2001:db8:df:0003::/64

2001:db8:df:0022::/64

2001:db8:df:0042::/64

2001:db8:df:0062::/64

2001:db8:df:0082::/64

2001:db8:df:0102::/64

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

2001:db8:df:0004::/64

2001:db8:df:0023::/64

2001:db8:df:0043::/64

2001:db8:df:0063::/64

2001:db8:df:0083::/64

2001:db8:df:0103::/64

2001:db8:df:0005::/64

2001:db8:df:0024::/64

2001:db8:df:0044::/64

2001:db8:df:0064::/64

2001:db8:df:0084::/64

2001:db8:df:0104::/64

Estudiantes

Profesores

Administrativo

Visita

Voz

Servidores

IPv6 Prefix2001:db8:df:: /48

Figura 3.6. Topología lógica de la red IPv6 propuesta.


87

Capítulo 4 Simulación de la red

Primeramente, debido a la falta de elementos para poder diseñar la red físicamente, recurrimos a un

programa de simulación, lo cual nos ayudará a demostrar lo planteado en los capítulos anteriores.

Lamentablemente para la red propuesta, el programa no cuenta con los equipos necesarios para simular

la red de manera óptima, por lo que se utilizaron equipos de menores recursos dentro del simulador.

Para la simulación solamente se manejaron dos edificios ya que el procesamiento es demasiado para

los recursos de la computadora, ya que esta no puede otorgar el rendimiento ideal para demostrar la red

simulada como se propuso en el capítulo 3. Finalmente los resultados se aproximan bastante al

ambiente real, haciendo posible la demostración de la base principal del proyecto.

Así mismo el proyecto debe de seguir pasos principales para llevar un orden de implantación y evitar

caer en errores que puedan confundir u ocupar demasiado tiempo para su solución, por eso a

continuación se redactan los pasos en orden en el que se implantó la red.

4.1 Configuración de la red

4.1.1 Configuración del equipo principal (Core)

Ya que el equipo Core es parte del esqueleto principal de la red es importante recalcar que si se llegase

a caer, absolutamente toda la red dejaría de funcionar por eso este equipo debe tener alta disponibilidad

y ser configurado para obtener redundancia, así evitaremos costosas perdidas de información y otros

elementos, este equipo es parte del cerebro de la red implantada, es por eso que debe de ser compatible

con IPv6 para realizar correctamente el diseño propuesto.

Para iniciar nuestra simulación se configuraron las rutas de acuerdo al diseño planteado en el capítulo

3, el protocolo utilizado es RIPng por ser un protocolo dinámico, esto nos da una mayor facilidad para

conocer la direcciones donde se desea de tener conexión y al ser una red lo suficientemente grande es

recomendable utilizar este protocolo en vez de utilizar rutas estáticas, por el motivo que causaría una

alta probabilidad de error a la hora de configurar y resolver problemas futuros.


88

La figura 4.1 muestra en los puntos verdes las zonas configuradas, donde se han asignado las

direcciones IPv6 al enrutador, obteniendo una entrada y una salida para conectarse a los enrutadores

distribución desde el enrutador Core.

Figura 4.1 Puntos configurados en el enrutador Core

Las configuraciones aplicadas al enrutador han sido: asignarle un nombre al equipo, asignarle

direcciones IPv6 a las interfaces, crear y activar la función de RIPng.

Comando para asignar el nombre “CORE” al equipo.

router>ena

router#conf t

router(config)#hostname CORE

CORE(config)#

Se habilita la función del protocolo de enrutamiento para IPv6 (RIPng).

CORE(config)#ipv6 unicast-routing activa el enrutamiento para IPv6.

CORE(config)#ipv6 router rip CISCO activa enrutmaiento RIPng llamado “CISCO”.

El siguiente comando asigna las direcciones IPv6 en las cuatro interfaces del enrutador, solamente se

muestra una interfaz para demostrar la manera en que se hizo la configuración. De esta manera se

configuraron las demás interfaces.

CORE(config)#interface FastEthernet0/0 Ingreso a la interfaz seleccionada.

CORE(config-if)#ipv6 address 2001:DB8:DF:FFF1::2/64 Dirección IPv6.

CORE(config-if)#ipv6 rip CISCO enable Habilita la funcion CISCO de enrutamiento IPv6 dentro

de la interface.

CORE(config-if)#no shutdown Habilita la interfaz lógica.

Core

Edificio 1 Edificio 2 Edificio 3 Edificio 4


89

NOTA: Para comprobar si la configuración hecha en el equipo cuenta con los datos deseados

utilizamos el comando show run.

La configuración del equipo CORE es muy sencilla pero en realidad es la que mayor peso tiene en la

red ya que hace toda la interconexión entre equipos usando un mayor procesamiento que los demás

equipos.

4.1.2 Configuración de equipos de distribución (Edificios)

Habiendo finalizado la configuración del equipo Core, se prosigue con la configuración los equipos de

distribución para terminar de interconectar las LANs de los cuatro edificios con el equipo CORE vía

protocolo RIPng. La figura 4.2 muestra en los puntos verdes las zonas configuradas en los enrutadores.

Figura 4.2. Puntos configurados en la capa de distribución

El equipo de distribución esta mostrado como un enrutador de alta disponibilidad. La capa de

distribución está conformada por cuatro equipos en diferentes edificios como se muestra en la figura

4.2.

La configuración que se realizó, es darle entrada y salida a las interfaces de cada enrutador para

interconectar las LANs de cada enrutador, así nos permite conocer la rutas hacia el equipo CORE y por

ende hacia los demás enrutadores de distribución.

Solo se muestra la configuración hecha en un enrutador, ya que la misma configuración se aplicó a los

demás enrutadores, cuidando los detalles de la dirección que se ha propuesto en el diseño.

Core

Edificio 1 Edificio 2 Edificio 3 Edificio 4


90

Se asignó el nombre “Edificio-1” al equipo.

router>ena

router#conf t

router(config)#hostname Edificio-1

Edificio-1(config)#

Se habilitó el protocolo RIPng para tener ruteo hacia el equipo CORE.

Edificio-1(config)#ipv6 unicast-routing Habilita el enrutamineto Ipv6.

La función que hace posible el enrutamiento mediante el protocolo RIPng para el aprendizaje dinámico

de rutas dentro del protocolo IPv6 también la activamos.

Edificio-1(config)#ipv6 router rip CISCO

Esta misma configuración se hizo para cada una de la VLANs propuestas, cuidando los detalles para

cada VLAN como las direcciones, Gateway y DNS.

Configuración de rangos para IPv6.

Edificio-1(config)#ipv6 dhcp pool VLAN-2 Asigna el nombre de la VLAN.

Edificio-1(config-dhcp)#prefix-delegation pool VLAN-2 Prefijo de la VLAN 2.

Edificio-1(config-dhcp)#dns-server 2001:DB8:DF:2::1 Dirección IPv6 para DNS.

Al igual que en IPv4, estos comandos son para la asignación de prefijos de cada VLAN en IPv6, esto

mismo se hizo con las VLANs faltantes, con sus respetivos rangos.

Ahora, lo que se ha hecho hasta el momento, es asignar los rangos para el protocolo IPv6, después se

han configurado las rutas hacia el equipo Core.

Para configurar se requiere observar que interfaz está directamente conectada al enrutador principal, en

este caso es la interfaz FastEthernet f0/0 que está directamente conectada con el enrutador principal o

Core, se configuró con una dirección IPv6. Dentro de la interfaz se hizo mención de la función CISCO,

para que la dirección IPv6 pueda ser aprendida por el protocolo RIPng. La figura 4.3 muestra la

interfaz que se configuro.


91

.

Figura 4.3. Interfaz FastEthernet 0/0

El siguiente comando se utilizó para asignar la dirección IPv6 a la interfaz para que haya conectividad,

cabe aclarar que las direcciones deben de estar en el mismo segmento de red de la interfaz del

enrutador principal.

Edificio-1(config)#interface FastEthernet 0/0 Selección de la interfaz.

Edificio-1(config-if)#ipv6 address 2001:DB8:DF:FFF1::1/64 Direccion Ipv6.

Edificio-1(config-if)#ipv6 rip CISCO enable Habilita la función de enrutamiento en la

interfaz.

Edificio-1(config-if)# no shutdown Activa la interfaz lógica.

Este comando se utilizó para los demás enrutadores de los otros tres edificios, configurando su

respectivas interfaces y direcciones propuestas para cada enrutador.

Ahora, la interfaz conectada directamente a la LAN es la FastEthernet 0/1, esta interfaz es configurada

para tener enrutamiento entre VLANs, para ello se hizo la configuración de sub-interfaces para

asignarles los Gateway que permiten el enrutamiento. La figura 4.4 muestra la interfaz con la que se

trabajó para realizar lo mencionado anteriormente.

Figura 4.4. Interfaz FastEthernet 0/1

Core

F0/0

Edificio 1

F0/1

VLANs

.

.

.


92

Primero se ingresó a la interfaz, como se hace en pasos anteriores, se utiliza la función CISCO para

habilitar el enrutamiento IPv6 en la interfaz y por último se activa la interfaz lógica.

Edificio-1(config)#interface FastEthernet0/1

Edificio-1(config-if)#ipv6 rip CISCO enable

Edificio-1(config-if)#no shutdown

Posteriormente se crean la sub-interfaces colocando un “.x”, siendo x cualquier número, recomendado

que este número sea el correspondiente a la VLAN que se está utilizando.

Los siguientes comandos nos indican la configuración de una sub-interface hecha para la VLAN 2.

Edificio-1(config)#interface FastEthernet0/1.2

Edificio-1(config-subif)#encapsulation dot1Q 2

Edificio-1(config-subif)#ipv6 address 2001:DB8:DF:2::1/64

Edificio-1(config-subif)#ipv6 rip CISCO enable

Edificio-1(config-subif)#ipv6 dhcp server VLAN-2

Se vuelve a llamar la función “CISCO” para que el protocolo RIPng aprenda las direcciones de la

diferentes VLANs, además de asignarle la función de DHCP, que les otorgará las dichas direcciones.

Para comprobar la configuración se usa el comando “show run”.

Hasta el momento ya tenemos configuradas las áreas de CORE y de distribución, únicamente falta el

área de acceso que se conforma por conmutadores capa 2, donde solamente es necesario configurar la

VLANs y así obtener la conexión entre todos lo equipos, contando también las computadoras.

4.1.3 Configuración de los equipos de acceso (Host)

En los equipos de acceso se configuraran las seis VLANs dentro de los cuatro enrutadores, además de

crear un puerto troncal donde el tráfico de estas VLANs fluirá para salir hacia el enrutador y por ende

hacia toda la red. La figura 4.5 muestra las zonas configuradas.


93

Figura 4.5. Puertos troncales configurados en los conmutadores

Para comenzar en cada edificio se configuraron los conmutadores de acceso, se crearon las seis

diferentes VLANs, además de crear los puertos troncales y asignarle nombre al equipo.

Para el edificio 1, es utilizado un conmutador de veinticuatro puertos, el cual es compatible con IPv6.

Se asignó un nombre del equipo.

switch>ena

switch#conf t

switch(config)# hostname SW-1

SW-1(config)#

Se configuraron las VLANs en el conmutador SW-1.

SW-1(config)#vlan 2

SW-1(config-vlan)#ex

SW-1(config)#vlan 21










Edificio 1

F0/23

Troncal

VLANs

Edificio 2

F0/23

Troncal

VLANs

Edificio 3

F0/23

Troncal

VLANs

Edificio 4

F0/23

Troncal

VLANs


94

Para confirmar que se crearon correctamente la VLANs se teclea el comando “show vlan”.

Ya creadas la VLANs se seleccionaron lo puertos a los que van a pertenecer a cada VLAN, en la

simulación solamente se seleccionó un puerto por VLAN para reducir el procesamiento de la

simulación.

SW-1(config)#interface fastethernet 0/2

SW-1(config-if)# switchport mode access

SW-1(config-if)# switchport access vlan 2 “Para VLAN 2”
















Se creó el puerto troncal que es un puerto especial para transmitir tráfico de más de una VLAN-

SW1-1(config)#interface fastethernet 0/23

SW1-1(config-if)# switchport mode trunk

Este comando es bastante sencillo y se hizo en los otros tres conmutadores con su información

correspondiente, solamente es mostrada una sola configuración para evitar colocar tanto comando, que

pudiese llegar a ser confuso.


95

4.1.4 Configuración de Hosts

La configuración de host en el programa de simulación es muy sencilla, ya que los enrutadores son los

encargados de asignar direcciones IPv4 e IPv6, solamente se activa la opción de DHCP en IPv4 y la

opción Autoconfig para IPv6, como se muestran en las siguientes figuras.

Se hace selecciona la computadora a configurar, se dirige a la pestaña “desktop” y seleccionamos la

opción de configuración de IP.

Figura 4.6. Configuración IP

Dentro de configuración de IP solamente seleccionamos DHCP y automáticamente se asignará una

dirección IPv4.

Figura 4.7. Activar DHCP

Para obtener una dirección IPv6 en una computadora, se activa el Autoconfig, siguiendo los pasos

anteriores, se selecciona el menú config.

Figura 4.8. Menú Config


96

Dentro del menú de configuración, en la opción de Gateway y DNS seleccionar “autoconfig”.

Figura 4.9. Activar autoconfig

Ahora seleccionamos FastEthernet.

Figura 4.10. Menú FastEthernet

Y activamos la opción Autoconfig para que automáticamente se asigne una dirección IPv6.

Figura 4.11. Activa Autoconfig en la configuración IPv6

Así es como se termina de configurar la red simulada, se prosigue hacer evaluaciones de la conexión

entre computadoras y equipos, como recordatorio hay que decir que el simular una red de este tamaño

es fácil a comparación de implantarla en un ambiente real, ya que muchos factores influyen e

interfieren para una correcta implantación, desde la capa 1 hablando del modelo OSI hasta la capa 7.


97

4.2 Configuración de servicios en la red

4.2.1 Servidor DNS

Los servidores DNS son computadoras que almacenan una gran base de datos, en la cual tienen el

registro de la relación que existe entre el nombre de dominio y su dirección IP.

Esto es importante ya que para todos los seres humanos identificamos las páginas de internet mediante

nombres como lo es google.com, yahoo.com, etc. lo que nos hace más fácil de recordar y de escribir,

estos nombres son los que se conocen como nombres de dominio. Las computadoras identifican los

sitios web y se conectan a ellos utilizando el formato numérico, lo que nosotros conocemos como

dirección IP.

Ahí es donde los servidores DNS nos sirven como traductores cuando ingresamos un nombre de

dominio les indica a las computadoras las dirección IP correspondiente a ese nombre de dominio.

Para configurar este servidor empezaremos por asignarle la dirección IPv6 a la cual se dirigirán todos

los host de la red como se muestra en la figura 4.12 en la parte de Desktop del servidor.

Después damos clic sobre la pestaña de config y DNS como se observa en la figura 4.13.

Figura 4.12. Asignación de direcciones al serv idor


98

Y por último agregamos las páginas con su nombre de dominio y su respectiva dirección IP para la

resolución de nombres como se muestra en la figura 4.14. Los números indican los pasos a seguir.

En el paso 2 se indica el nombre de dominio en este caso google.com, después se debe de indicar la

dirección IP del servidor de donde se encuentre esta página indicado con el número 3, se procede a dar

“add” para agregar la página y su respectiva dirección IP y así se podrá dar acceder a este servicio

desde cualquier host de la red.

Para muestra de que el servicio está disponible, nos dirigimos a cualquier PC de la red y entramos a la

página google.com o a la dirección 220.220.220.1 y observamos que efectivamente está funcionando

como se muestra en la figura 4.15. y 4.16

Figura 4.13. Pestañas para configurar DNS

Figura 4.14. Muestra como agregar un nombre de dominio con su respectiva dirección IP


99

4.2.2 Servidor de MAIL

Un servidor de correo, es el que almacena la aplicación que nos permitirá enviar y recibir correos

independientemente de cualquier red mediante un conjunto de protocolos como los son, SMTP, POP3

e IMAP.

Nosotros nos enfocamos solo en algunos datos para la configuración de este servidor en nuestro

programa de simulación.

Como en el servidor anterior procedemos primero a colocar las direcciones para que los host puedan

indicar que dirección tendrá su servidor de correo, como se muestra en la figura 4.17.

Figura 4.15. Pagina web google.com

Figura 4.16. Página web 220.220.220.1


100

Después procederemos a crear el nombre de dominio que tendrá nuestro servidor de correo y los

usuarios que tendrán acceso a nuestra aplicación de correo como lo indica la figura 4.18.

Como se muestra en la figura 4.19, primero se indicó el nombre de dominio del servidor de correo en

este caso mail.com, seguido creamos los usuarios y sus contraseñas que tendrán acceso a esta

aplicación y damos agregar como se muestra en el punto 2,3 y 4.

Ya que tenemos el nombre de dominio y los usuarios creados lo siguiente será la configuración de mail

en los host de la red y eso se puede observar en las figuras 4.20

Figura 4.17. Asignación de direcciones al serv idor

Figura 4.18. Creación de aplicación de correo y usuarios


101

Figura 4.19 y 4.20. Configuración de mail en los Host

Como se puede observar en la figura 4.20 se asignan los datos importantes y necesarios para la

configuración de mail a los usuarios, como son:

1. Dirección de correo del usuario, en este caso [email protected], donde luis es el usuario que

creamos y @mail.com es la parte del dominio de correo.

2. Dirección del servidor de correo saliente y entrante, para este caso es el mismo por lo cual

colocaremos la misma dirección en estos dos campos.

3. Usuario y contraseña, aquí va uno de los usuarios que creamos en el servidor por ejemplo:

luis y su contraseña 1234.

Por último damos en la pestaña “save” y con esto concluimos la parte de configuración para la

aplicación de correo.


102

4.3 Verificación de conectividad

En esta etapa lo que prosigue es confirmar que la red esta funcionado correctamente, lo que se hizo es

demostrar que hay comunicación en cada uno de los nodos de red como enrutadores, servidores,

computadoras, etc. La manera correcta de verificar la conexiones es mediante el uso del protocolo

ICMP e ICMPv6 conocido comúnmente como ping, este se puede hacer desde el servidor, enrutador,

conmutador o computadoras y debe de comunicarse con cualquier nodo de la red.

A continuación de muestran en las figuras los ping en los nodos más importantes, donde se requiere

que funciones perfectamente para evitar problemas, Las imágenes mostradas son directas de los equipo

y computadoras.

Figura 4.21 Ping desde el CORE a Edificio 2

Figura 4.22. Ping desde CORE a Edificio 1


103

Figura 4.23. Ping desde Edificio 1 a Edificio 2

Figura 4.24. Ping desde Core a computadora de VLAN 2

La configuración que se aplicó al equipo Core en sus 4 interfaces, fue aplicada de manera similar a la

hecha en los enrutadores de distribución, con la diferencia que la capa de distribución debe de tener

conexión hacia el enrutador Core y conmutadores de acceso.

Como se puede apreciar que tenemos conectividad sin problemas en la zona de Core y distribución,

dentro de la zona hacia los equipos de acceso (PCs) tampoco se detectan problemas de conectividad.

Para finalizar mostramos el resultado de la tabla de enrutamiento de la rutas aprendidas con el

protocolo IPv6 obtenida del equipo Core.


104

CORE#sh ipv6 route

IPv6 Routing Table - 19 entries

R 2001:DB8:DF:2::/64 [120/2]

via FE80::205:5EFF:FE55:C301, FastEthernet0/0

R 2001:DB8:DF:3::/64 [120/2]

via FE80::240:BFF:FE14:D414, FastEthernet0/1

R 2001:DB8:DF:21::/64 [120/2]


R 2001:DB8:DF:22::/64 [120/2]


R 2001:DB8:DF:41::/64 [120/2]


R 2001:DB8:DF:42::/64 [120/2]


R 2001:DB8:DF:61::/64 [120/2]


R 2001:DB8:DF:62::/64 [120/2]


R 2001:DB8:DF:81::/64 [120/2]


R 2001:DB8:DF:82::/64 [120/2]


C 2001:DB8:DF:100::/64 [0/0]

via ::, FastEthernet1/1

L 2001:DB8:DF:100::A/128 [0/0]


R 2001:DB8:DF:101::/64 [120/2]


R 2001:DB8:DF:102::/64 [120/2]


C 2001:DB8:DF:FFF1::/64 [0/0]


L 2001:DB8:DF:FFF1::2/128 [0/0]


C 2001:DB8:DF:FFF2::/64 [0/0]


L 2001:DB8:DF:FFF2::1/128 [0/0]


L FF00::/8 [0/0]

via ::, Null0

Figura 4.23 Rutas del Core

Con esta tabla y los ping hechos se comprueba la configuración de manera correcta de la red, haciendo

visible su funcionamiento de manera correcta.


105

Aunque no se tengan problemas en la red siempre se debe de estar monitoreando la red para evitar

fallas repentinas y estar siempre alertas para ofrecer una solución rápida y de calidad para poder dejar

nuevamente funcionando la red, siempre es recomendable tener un administrador de red el cual tenga

el conocimiento de la red para que pueda detectar el mínimo error que se tenga.

4.4 Detección y Solución de errores

En la etapa de cierto modo, después de hacer una configuración así, se debe de esperar al menos 24

horas para que se puedan detectar errores mediante la colocación de un sniffer, este equipo ayuda a

analizar el tráfico en la red permitiendo conocer las velocidades de transferencia y detectar posible

errores físicos o de configuración.

Se recomienda que a las 24 horas se implante esta acción pero también es necesario que la red tenga un

administrador que aplica esta acción por lo menos una vez al mes para prevenir estos errores que

pueden causar muchos problemas a la empresa.

Ya que esta red es simulada es imposible saber cada uno de los detalles de transferencia de archivos

pero sin duda este paso es importante a la hora de implantarlo en un ambiente real, los ingenieros no

pueden pasar desapercibidos ante esta situación, por eso es importante mencionarlo como parte de una

implantación de una red.

4.5 Memoria Técnica.

Por último, al haber acabado el proyecto es necesario que se tengan registrados los cambios que tuvo la

red para conocer los cambios físicos y de configuración que la red ha sufrido en caso de que llegará a

fallar nuevamente. También es importante para mantener un orden en la red y evitar lo menos posibles

cambios inesperados por parte de los usuarios.

Una memoria técnica es un documento que se entrega al cliente después de terminado el proyecto, debe

contar con el nuevo diagrama de red, registrando todas la direcciones de cada nodo, desde la

computadoras hasta el equipo CORE, además de la configuraciones de cada uno de lo equipo dentro de

la red como enrutadores y conmutadores otra información que se cuenta son:


106

Diagramas de red

Especificaciones del equipo utilizado

Configuraciones

Contraseñas

Estado del equipo (antes y después)

Todo esto es necesario para que el cliente tenga un orden y en caso de haber una falla, tener en cuanta

donde esta esa posible falla.

Por último siempre es recomendable tomar fotografías del antes y después de cada cambio, sobre todo

si también hubo un cambio fisco como conectores o en su caso el cableado, para que el cliente tenga de

cierta manera tranquilidad de que realmente se trabajó para que su red este en óptimas condiciones.

Con esto se concluyó la simulación, obteniendo un resultado positivo de acuerdo a lo planteado en el

capítulo 3. Habiendo realizado de manera exitosa la simulación de la red, hay que destacar que se están

utilizando de manera simultánea los protocolos IPv4 e IPv6 pero siendo IPv6 el predeterminado, ya

que este tiene ventajas sobre su predecesor que también son mostrados en esta simulación.

La ventaja de implantar IPv6 sobre la red como se ha dicho no solo fue la expansión de direcciones IP

para permitir un mayor número de dispositivos conectados a Internet. Entre los mayores beneficios es

la incorporación de reglas ayudando a la calidad de servicio en la red con la desaparición de las

direcciones de broadcast y con la incursión de las direcciones Anycast.

Un ejemplo de los problemas con la direcciones broadcast, es la incorporación de nuevos elementos a

la red, los enrutadores necesitan conocer la dirección física de los elementos, precisamente para poder

enviarle información, por lo que mandan a través del protocolo ARP un mensaje broadcast para

buscarlo, y que este elemento responda y envié su dirección física, causando que en la red haya

latencia y perdida de paquetes o en su caso no procese bien la información cuando hay más equipos

trabajando.

Sin embargo en IPv6 desaparecen este tipo de direcciones, utilizando el mismo ejemplo la diferencia

está en que usa las direcciones Multicast tipo 135 y 136 bajo el protocolo ICMPv6 para conocer la

dirección física, el mismo enrutador envía la petición hacia la dirección Multicast de los elementos,

estos responden y envían su dirección física hacia el enrutador para guardarla en su tabla.


107

Al final esto ayuda a la red a no ser congestionada simplemente para conocer a un nuevo integrante en

la red, utilizando sus recursos en lo que verdaderamente se necesita, que es la transferencia de

información en el menor tiempo posible.

Este es un ejemplo de muchos del porque las direcciones broadcast en demasía perjudican el

rendimiento de la red, este ejemplo fue elegido por la facilidad de poder mostrarlo en la simulación

visiblemente.

Finalmente otro de los beneficios que puede observarse en la simulación, es la autoconfiguración de la

direcciones IP que consiste en asignarle una dirección a los elementos a través de su dirección física,

haciendo más sencilla su configuración y sobre todo evitar la duplicación de direcciones en la redes ya

que la direcciones en IPv6 son punto a punto hacia Internet.

Estos beneficios se pueden mostrar en la simulación aunque existen muchos más, lamentablemente no

pueden ser mostrados en la simulación ya que necesitaríamos la red físicamente activa para colocar el

sniffer y éste nos arrojará todas las mejoras que se dan cuando se usa IPv6, aun así estos ejemplos

muestran lo bondadoso que es este protocolo con su antecesor.


108

Conclusiones

Implantar una red de doble pila implica un gran reto para los ingenieros, ya que se trabaja con una

“nueva” tecnología que todavía no está desarrollada al 100% pero que de inmediatamente resalta sus

ventajas con el protocolo anterior. Hay que recalcar que trabajar con nueva tecnología implica mucho

estudio, interactuar con distinto equipo para configurarlo, etc. pero muy importante siempre partiendo

de las bases para que el entendimiento del tema sea mucho mayor.

El proyecto que se ha propuesto y demostrado, cumple con el objetivo que se ha planteado para que su

funcionamiento sea el correcto. Si bien el proyecto en un ambiente empresarial no sería el idóneo por

diversos factores que no se han tomado en cuenta, y siendo simplemente un laboratorio para mostrar

las bondades del protocolo IPv6, empezando desde la teoría de como el protocolo a ido evolucionando,

características, estadísticas, situaciones actuales en todo el mundo, etc. Aspectos técnicos del mismo,

configuraciones, especificaciones, etc.

Un tema que también se tomó mucho en cuenta es el cómo implantar la red de un modo correcto, no es

solo implantarla y dejar botado todo el equipo, hacen la recomendaciones de cómo hacer la topología

física y lógica. Montaje y acomodo de los equipos, distribución de los Host, etc. Lógicamente hay

también un orden para administrar de mejor manera la red.

El proyecto da incluso la idea de cómo implantar redes mucho más pequeñas e ir aprendiendo como

configurar y administrar que al final en un ambiente laboral es muy práctico e indispensable conocer

estos temas.

Finalmente como punto de vista el futuro ya está a la vuelta y el protocolo IPv6 debe ser implantado

tarde o temprano, sin embrago el ya ir planeando este cambio te da la ventaja de estar listo para

cualquier situación y que la tecnología no te rebase en el momento que se sufra el cambio completo a

este protocolo, que por cierto falta bastante tiempo.


109

Bibliografía

McFarland Shannon; Sambi Munider; Sharma Nikhil y Hooda Snajay. IPv6 for Enterprise Networks .

Ciscopress.

Cicileo Guillermo; Gagliano Roque; O’Flaherty Christian; Olvera Morales César; Rocha Mariela y

Vives Martínez Álvaro. IPv6 para Todos. (Argentina). Internet Society.

Odom Wendell. CCENT/CCNA ICDN1 100-101. Ciscopress.

http://blog.capacityacademy.com/2013/04/13/cisco-ccna-todo-sobre-ipv 6-las-v entajas/

http://blog.capacityacademy.com/2013/04/13/cisco-ccna-todo-sobre-ipv6-espacio-de-direccionamiento/

http://blog.capacityacademy.com/2013/04/14/cisco-ccna-todo-sobre-ipv 6-prefijos-notacion/

http://blog.capacityacademy.com/2013/04/16/cisco-ccna-todo-sobre-ipv 6-tipos-de-direcciones/

http://blog.capacityacademy.com/2013/04/17/cisco-ccna-todo-sobre-ipv6-direcciones-global-unicast-55/

http://windowserv er.wordpress.com/2013/09/25/aprendiendo-ipv 6-clases-de-direcciones-ipv 6/

http://es.kioskea.net/contents/268-protocolo-ipv 6

www.ipv 6v e.info/project-definition/tipos-de-direcciones

http://inconfor.me/index.php/tutoriales/routing-switching/25-spadv route/51-ipv 6-multicast

http://docs.oracle.com/cd/E19957-01/820-2981/ipv 6-ov erv iew-201/index.html

http://lobobinario.blogspot.mx/2011/03/saga-ipv 6-episode-ii-direcciones-ipv 6.html

http://msdn.microsoft.com/en-us/library/ms882958.aspx

https://supportforums.cisco.com/docs/DOC-17232

http://cesarcabrera.info/blog/subneteo-en-ipv 6/

http://technet.microsoft.com/es-es/library/cc758763(v =ws.10).aspx

http://meetings.ripe.net/ripe-53/presentations/dhcpv 6.pdf

http://cocobinario.blogspot.mx/2011/03/nat-nat-tp-ipv 6.html

http://technet.microsoft.com/es-es/library/cc736336(WS.10).aspx

http://ipv 4to6.blogspot.mx/p/traducciones.html


http://msdn.microsoft.com/es-es/library/ms172317(v =v s.110).aspx


https://sites.google.com/site/ccna2redii/3-introduccion-a-los-protocolos-de-enrutamiento-dinamico

www.labs.lacnic.net/drupal/sites/default/files/ospf-isis-ipv 6.pdf

www.cisco.com/cisco/web/support/LA/111/1116/1116304_ip6-is-is.pdf

www.labs.lacnic.net/site/sites/default/files/09-protocolos-de-ruteo.pdf

www.6deploy.eu/workshops2/20111128_santo_domingo/TallerIPv 6RepDominicana_Routing.pdf

www.nanog.org/meetings/nanog46/presentations/Tuesday/Brzozowski_introDHCP_N46.pdf

www.eslared.org.v e/walc2012/material/track2/DHCPv 6.pdf

www.6deploy.org/workshops/20101011_santa_cruz_boliv ia/WALC2010-dhcpv 6-es.pdf

www.cisco.com/en/US/docs/v oice_ip_comm/cucm/srnd/ipv 6/basics.html

www.cu.ipv 6tf.org/pdf/carlos_ralli_transitiontutorial.pdf

www.brocade.com/downloads/documents/html_product_manuals/FI_08001_L3_ROUTE/GUID-0FD08DCF-

1959-4028-85D9-F3C870F567C7.html

www.systemconsultores.com/data/carpetas/2/CCNA2_Capitulo%203%20Introduccion%20a%20los%20proto

colos%20de%20enrutamiento%20dinamico.pdf

www.6deploy.eu/workshops2/20111128_santo_domingo/TallerIPv 6RepDominicana_Routing.pdf

www.cisco.com/en/US/docs/ios-xml/ios/ipmulti_lsm/configuration/xe-3s/ipv 6-mcast-mld-xe.html

http://www.cisco.com/cisco/web/support/LA/111/1116/1116304_ip6-is-is.pdf


110

Anexo 1. Internet y modelos de referencia.

En este anexo se verán dos arquitecturas de redes importantes, los modelos de referencia OSI y

TCP/IP. Aunque los protocolos asociados con el modelo OSI ya casi no se usan, el modelo en si es

muy general y aun es válido, y las características tratadas en cada capa aun son muy importantes. El

modelo TCP/IP tiene las propiedades opuestas: el modelo en si no se utiliza mucho pero los protocolos

sí. Por estas razones se analizan con detalle ambos modelos.

1.1 El modelo de referencia OSI.

El modelo OSI se muestra en la figura 1.1 (sin el medio físico). Este modelo está basado en una

propuesta desarrollada por la ISO (Organización Internacional de Estándares) como un primer paso

hacia la estandarización internacional de los protocolos utilizados en varias capas. Fue revisado en

1995.El modelo se llama OSI (Interconexión de Sistemas Abiertos) de ISO porque tiene que ver con la

conexión de sistemas abiertos, es decir, sistemas que están abiertos a la comunicación con otros

sistemas.

El modelo OSI tiene siete capas. Se puede resumir brevemente los principios que se aplicaron para

llegar a dichas capas:

Una capa se debe crear donde se necesite una abstracción diferente.

Cada capa debe realizar una función bien definida.

Cada capa debe realizar una función bien definida.

Los límites de las capas se deben elegir a fin de minimizar el flujo de información a través de

las interfaces.

La cantidad de capas debe ser suficientemente grande para no tener que agrupar funciones

distintas en la misma capa y lo bastante pequeña para que la arquitectura no se vuelva

inmanejable

A continuación se analizan una por una cada capa del modelo, comenzando con la capa inferior. Se

observa que el modelo OSI no es en sí una arquitectura de red, debido a que no especifica los servicios

y protocolos exactos que se utilizarán en cada capa. Sólo indica lo que debe hacer cada capa. Sin

embargo, ISO también ha producido estándares para todas las capas, aunque éstos no son parte del

modelo de referencia mismo. Cada uno se ha publicado como un estándar internacional separado.


111

Figura 1.1. Modelo de referencia OSI

La capa física.

En esta capa se lleva a cabo la transmisión de bits puros a través de un canal de comunicación. Los

aspectos del diseño implican asegurarse de que cuando un lado envía un bit 1, éste se reciba en el otro

lado como tal, no como bit 0. Las preguntas típicas aquí son: ¿cuántos volts se deben emplear para

representar un 1 y cuántos para representar un 0?, ¿cuántos nanosegundos dura un bit?, ¿la transmisión

se debe llevar a cabo en ambas direcciones al mismo tiempo?, ¿cómo se establece la conexión inicial y

cómo se finaliza cuando ambos lados terminan?, ¿cuántos pines tiene un conector de red y para qué se

utiliza cada uno? Los aspectos de diseño tienen que ver mucho con interfaces mecánicas, eléctricas y

de temporización, además del medio físico de transmisión, que está bajo la capa física.


112

La capa de enlace de datos .

La tarea principal de esta capa es transformar un medio de transmisión puro en una línea de

comunicación que, al llegar a la capa de red, aparezca libre de errores de transmisión. Logra esta tarea

haciendo que el emisor fragmente los datos de entrada en tramas de datos (típicamente, de algunos

cientos o miles de bytes) y transmitiendo las tramas de manera secuencial. Si el servicio es confiable, el

receptor confirma la recepción correcta de cada trama devolviendo una trama de confirmación de

recepción.

Otra cuestión que surge en la capa de enlace de datos (y en la mayoría de las capas superiores) es cómo

hacer que un transmisor rápido no sature de datos a un receptor lento. Por lo general se necesita un

mecanismo de regulación de tráfico que indique al transmisor cuánto espacio de búfer tiene el receptor

en ese momento. Con frecuencia, esta regulación de flujo y el manejo de errores están integrados.

La capa de red.

Esta capa controla las operaciones de la subred. Un aspecto clave del diseño es determinar cómo se

enrutan los paquetes desde su origen a su destino. Las rutas pueden estar basadas en tablas estáticas

(enrutamiento estático) codificadas en la red y que rara vez cambian.

Si hay demasiados paquetes en la subred al mismo tiempo, se interpondrán en el camino unos y otros,

lo que provocará que se formen cuellos de botella. La responsabilidad de controlar esta congestión

también pertenece a la capa de red, aunque esta responsabilidad también puede ser compartida por la

capa de transmisión. De manera más general, la calidad del servicio proporcionado (retardo, tiempo de

tránsito, inestabilidad, etcétera) también corresponde a la capa de red.

Cuando un paquete tiene que viajar de una red a otra para llegar a su destino, pueden surgir muchos

problemas. El direccionamiento utilizado por la segunda red podría ser diferente del de la primera. La

segunda podría no aceptar todo el paquete porque es demasiado largo. Los protocolos podrían ser

diferentes, etcétera. La capa de red tiene que resolver todos estos problemas para que las redes

heterogéneas se interconecten.

La capa de trasporte .

La función básica de esta capa es aceptar los datos provenientes de las capas superiores, dividirlos en

unidades más pequeñas si es necesario, pasar éstas a la capa de red y asegurarse de que todas las piezas


113

lleguen correctamente al otro extremo. Además, todo esto se debe hacer con eficiencia y de manera que

aísle a las capas superiores de los cambios inevitables en la tecnología del hardware.

La capa de transporte también determina qué tipo de servicio proporcionar a la capa de sesión y,

finalmente, a los usuarios de la red. El tipo de conexión de transporte más popular es un canal punto a

punto libre de errores que entrega mensajes o bytes en el orden en que se enviaron. Sin embargo, otros

tipos de servicio de transporte posibles son la transportación de mensajes aislados, que no garantiza el

orden de entrega, y la difusión de mensajes a múltiples destinos. El tipo de servicio se determina

cuando se establece la conexión. (Como observación, es imposible alcanzar un canal libre de errores; lo

que se quiere dar a entender con este término es que la tasa de error es tan baja que se puede ignorar en

la práctica).

La capa de transporte es una verdadera conexión de extremo a extremo, en toda la ruta desde el origen

hasta el destino. En otras palabras, un programa en la máquina de origen lleva a cabo una conversación

con un programa similar en la máquina de destino, usando los encabezados de mensaje y los mensajes

de control. En las capas inferiores, los protocolos operan entre cada máquina y sus vecinos inmediatos,

y no entre las máquinas de los extremos, la de origen y la de destino, las cuales podrían estar separadas

por muchos enrutadores. En la figura 1.1 se muestra la diferencia entre las capas 1 a 3, que están

encadenadas, y las capas 4 a 7, que operan de extremo a extremo.

La capa de sesión.

Esta capa permite que los usuarios de máquinas diferentes establezcan sesiones entre ellos. Las

sesiones ofrecen varios servicios, como el control de diálogo (dar seguimiento de a quién le toca

transmitir), administración de token (que impide que las dos partes traten de realizar la misma

operación crítica al mismo tiempo) y sincronización (la adición de puntos de referencia a transmisiones

largas para permitirles continuar desde donde se encontraban después de una caída).

La capa de presentación.

A diferencia de las capas inferiores, a las que les corresponde principalmente mover bits, a la capa de

presentación le corresponde la sintaxis y la semántica de la información transmitida. A fin de que las

computadoras con diferentes representaciones de datos se puedan comunicar, las estructuras de datos

que se intercambiarán se pueden definir de una manera abstracta, junto con una codificación estándar

para su uso “en el cable”. La capa de presentación maneja estas estructuras de datos abstractas y


114

permite definir e intercambiar estructuras de datos de un nivel más alto (por ejemplo, registros

bancarios).

La capa de aplicación.

Esta capa contiene varios protocolos que los usuarios requieren con frecuencia. Un protocolo de

aplicación de amplio uso es HTTP (Protocolo de Transferencia de Hipertexto), que es la base de World

Wide Web. Cuando un navegador desea una página Web, utiliza este protocolo para enviar al servidor

el nombre de dicha página. A continuación, el servidor devuelve la página. Otros protocolos de

aplicación se utilizan para la transferencia de archivos, correo electrónico y noticias en la red.

1.2 El Modelo de referencia TCP/IP

ARPANET fue una red de investigación respaldada por el DoD (Departamento de Defensa de Estados

Unidos). Con el tiempo, conectó cientos de universidades e instalaciones gubernamentales mediante

líneas telefónicas alquiladas. Posteriormente, cuando se agregaron redes satelitales y de radio, los

protocolos existentes tuvieron problemas para interactuar con ellas, por lo que se necesitaba una nueva

arquitectura de referencia. De este modo, la capacidad para conectar múltiples redes en una manera

sólida fue una de las principales metas de diseño desde sus inicios. Más tarde, esta arquitectura se llegó

a conocer como el modelo de referencia TCP/IP, de acuerdo con sus dos protocolos primarios. Su

primera definición fue en 1974. Posteriormente se definió en1985.

Ante el temor del DoD de que algunos de sus valiosos hosts, enrutadores y puertas de enlace de inter-

redes explotaran en un instante, otro objetivo fue que la red pudiera sobrevivir a la pérdida de hardware

de la subred, sin que las conversaciones existentes se interrumpieran. En otras palabras, el DoD quería

que las conexiones se mantuvieran intactas en tanto las máquinas de origen y destino estuvieran

funcionando, aunque algunas de las máquinas o líneas de transmisión intermedias quedaran fuera de

operación repentinamente. Además, se necesitaba una arquitectura flexible debido a que se preveían

aplicaciones con requerimientos divergentes, desde transferencia de archivos a transmisión de palabras

en tiempo real.

La capa de intered.

Todos estos requerimientos condujeron a la elección de una red de conmutación de paquetes basada en

una capa de inter-red no orientada a la conexión. Esta capa, llamada capa de inter-red, es la pieza clave

que mantiene unida a la arquitectura. Su trabajo es permitir que los hosts inyecten paquetes dentro de


115

cualquier red y que éstos viajen a su destino de manera independiente (podría ser en una red diferente).

Tal vez lleguen en un orden diferente al que fueron enviados, en cuyo caso las capas más altas deberán

ordenarlos, si se desea una entrega ordenada. Observe que aquí el concepto “inter-red” se utiliza en un

sentido genérico, aun cuando esta capa se presente en Internet.

Aquí la analogía es con el sistema de correo tradicional. Una persona puede depositar una secuencia de

cartas internacionales en un buzón y, con un poco de suerte, la mayoría de ellas se entregará en la

dirección correcta del país de destino. Es probable que durante el trayecto, las cartas viajen a través de

una o más puertas de enlace de correo internacional, pero esto es transparente para los usuarios.

Además, para los usuarios también es transparente el hecho de que cada país (es decir, cada red) tiene

sus propios timbres postales, tamaños preferidos de sobre y reglas de entrega.

La capa de inter-red define un paquete de formato y protocolo oficial llamado IP (Protocolo de

Internet). El trabajo de la capa de inter-red es entregar paquetes IP al destinatario. Aquí, el

enrutamiento de paquetes es claramente el aspecto principal, con el propósito de evitar la congestión.

Por estas razones es razonable decir que la capa de inter-red del modelo TCP/IP es similar en

funcionalidad a la capa de red del modelo OSI. La figura 1.2 muestra esta correspondencia.

Figura 1.2. Modelo de referencia OSI

La capa de transporte.

La capa que está arriba de la capa de inter-red en el modelo TCP/IP se llama capa de transporte. Está

diseñada para permitir que las entidades iguales en los hosts de origen y destino puedan llevar a cabo

una conversación, tal como lo hace la capa de transporte OSI. Aquí se han definido dos protocolos de

transporte de extremo a extremo. El primero, TCP (Protocolo de Control de Transmisión), es un


116

protocolo confiable, orientado a la conexión, que permite que un flujo de bytes que se origina en una

máquina se entregue sin errores en cualquier otra máquina en la inter-red. Divide el flujo de bytes

entrantes en mensajes discretos y pasa cada uno de ellos a la capa de inter-red. En el destino, el proceso

TCP receptor reensambla en el flujo de salida los mensajes recibidos. TCP también maneja el control

de flujo para asegurarse de que un emisor rápido no sature a un receptor lento con más mensajes de los

que puede manejar.

El segundo protocolo de esta capa, UDP (Protocolo de Datagrama de Usuario), es un protocolo no

confiable y no orientado a la conexión para aplicaciones que no desean la secuenciación o el control de

flujo de TCP y que desean proporcionar el suyo. También tiene un amplio uso en consultas únicas de

solicitud-respuesta de tipo cliente-servidor en un solo envío, así como aplicaciones en las que la

entrega puntual es más importante que la precisa, como en la transmisión de voz o vídeo. La relación

de IP, TCP y UDP se muestra en la figura 1.3 Puesto que el modelo se desarrolló, se ha implementado

IP en muchas otras redes.

Figura 1.3. Protocolos y redes del modelo TCP/IP inicialmente.

La capa de aplicación.

El modelo TCP/IP no tiene capas de sesión ni de presentación. No se han necesitado, por lo que no se

incluyen. La experiencia con el modelo OSI ha probado que este punto de vista es correcto: son de

poco uso para la mayoría de las aplicaciones.

Arriba de la capa de transporte está la capa de aplicación. Contiene todos los protocolos de nivel más

alto. Los primeros incluyeron una terminal virtual (TELNET), transferencia de archivos (FTP) y correo

electrónico (SMTP), como se muestra en la figura 1.3. El protocolo de terminal virtual permite que un

usuario en una máquina se registre en una máquina remota y trabaje ahí. El protocolo de transferencia


117

de archivos proporciona una manera de mover con eficiencia datos de una máquina a otra. El correo

electrónico era originalmente sólo un tipo de transferencia de archivos, pero más tarde se desarrolló un

protocolo especializado (SMTP) para él. Con el tiempo, se han agregado muchos otros protocolos:

DNS (Sistema de Nombres de Dominio) para la resolución de nombres de host en sus direcciones de

red; NNTP, para transportar los artículos de noticias de USENET; HTTP, para las páginas de World

Wide Web, y muchos otros.

La capa de host a red.

Debajo de la capa de interred hay un gran vacío. El modelo de referencia TCP/IP en realidad no dice

mucho acerca de lo que pasa aquí, excepto que puntualiza que el host se tiene que conectar a la red

mediante el mismo protocolo para que le puedan enviar paquetes IP. Este protocolo no está definido y

varía de un host a otro y de una red a otra. Este tema rara vez se trata en libros y artículos sobre

TCP/IP.

1.3 Comparación entre los modelos de referencia OSI y TCP/IP.

Los modelos de referencia OSI y TCP/IP tienen mucho en común. Los dos se basan en el concepto de

una pila de protocolos independientes. Asimismo, la funcionalidad de las capas es muy parecida. Por

ejemplo, en ambos modelos las capas que están arriba de, incluyendo a, la capa de transporte están ahí

para proporcionar un servicio de transporte independiente de extremo a extremo a los procesos que

desean comunicarse. Estas capas forman el proveedor de transporte. De nuevo, en ambos modelos, las

capas que están arriba de la de transporte son usuarias orientadas a la aplicación del servicio de

transporte.

A pesar de estas similitudes fundamentales, los dos modelos también tienen muchas diferencias. En

esta sección nos enfocaremos en las diferencias clave entre estos dos modelos de referencia. Es

importante tener en cuenta que se están comparando los modelos de referencia, no las pilas de

protocolos correspondientes.

Tres conceptos son básicos para el modelo OSI.

Servicios

Interfaces

Protocolos.


118

Probablemente la contribución más grande del modelo OSI es que hace explícita la distinción entre

estos tres conceptos. Cada capa desempeña algunos servicios para la capa que está arriba de ella. La

definición de servicio indica qué hace la capa, no la forma en que la entidad superior tiene acceso a

ella, o cómo funciona dicha capa. Define el aspecto semántico de la capa.

La interfaz de una capa indica a los procesos que están sobre ella cómo accederla. Especifica cuáles

son los parámetros y qué resultados se esperan. Incluso, no dice nada sobre cómo funciona

internamente la capa.

Por último, una capa es quien debe decidir qué protocolos de iguales utilizar. Puede usar cualesquier

protocolo que desee, en tanto consiga que se haga el trabajo (es decir, proporcione los servicios

ofrecidos). También puede cambiarlos cuando desee sin afectar el software de las capas superiores.

Estas ideas encajan muy bien con las ideas modernas sobre la programación orientada a objetos. Un

objeto, como una capa, cuenta con un conjunto de métodos (operaciones) que pueden ser invocados por

procesos que no estén en dicho objeto. La semántica de estos métodos define el conjunto de servicios

que ofrece el objeto. Los parámetros y resultados de los métodos forman la interfaz del objeto. El

código interno del objeto es su protocolo y no es visible o no tiene importancia fuera del objeto.

Originalmente, el modelo TCP/IP no distinguía entre servicio, interfaz y protocolo, aunque las

personas han tratado de readaptarlo con el propósito de hacerlo más parecido al OSI. Por ejemplo, los

únicos servicios ofrecidos realmente por la capa de inter-red son SEND IP PACKET y RECEIVE IP

PACKET.

Como consecuencia, los protocolos del modelo OSI están mejor ocultos que los del modelo TCPI/IP y

se pueden reemplazar fácilmente conforme cambia la tecnología. La facilidad para realizar tales

cambios es uno de los objetivos principales de tener protocolos en capas.

El modelo de referencia OSI se vislumbró antes de que se inventaran los protocolos correspondientes.

Esta clasificación significa que el modelo no estaba diseñado para un conjunto particular de protocolos,

un hecho que lo hizo general. Una deficiencia de esta clasificación es que los diseñadores no tenían

mucha experiencia con el asunto y no tenían una idea concreta de qué funcionalidad poner en qué capa.

Por ejemplo, originalmente la capa de enlace de datos sólo trataba con redes de punto a punto. Cuando

llegaron las redes de difusión, se tuvo que extender una nueva subcapa en el modelo. Cuando las

personas empezaron a construir redes reales utilizando el modelo OSI y los protocolos existentes, se


119

descubrió que estas redes no coincidían con las especificaciones de los servicios solicitados, por lo que

se tuvieron que integrar subcapas convergentes en el modelo para proporcionar un espacio para

documentar las diferencias. Por último, el comité esperaba en un principio que cada país tuviera una

red, controlada por el gobierno y que utilizara los protocolos OSI, pero nunca pensaron en la

interconectividad de redes. Para no hacer tan larga la historia, las cosas no sucedieron como se

esperaba.

Con TCP/IP sucedió lo contrario: los protocolos llegaron primero y el modelo fue en realidad una

descripción de los protocolos existentes. No había problemas para ajustar los protocolos al modelo.

Encajaban a la perfección. El único problema era que el modelo no aceptaba otras pilas de protocolos.

Como consecuencia, no era útil para describir otras redes que no fueran TCP/IP.

Volviendo de los asuntos filosóficos a los más específicos, una diferencia patente entre los dos

modelos es el número de capas: el modelo OSI tiene siete y el TCP/IP sólo cuatro. Los dos tienen

capas de (inter)red, transporte y aplicación, pero las otras capas son diferentes.

Otra diferencia está en el área de la comunicación orientada a la conexión comparada con la no

orientada a la conexión. El modelo OSI soporta ambas comunicaciones en la capa de red, pero sólo la

de comunicación orientada a la conexión en la capa de transporte, donde es importante (porque el

servicio de transporte es transparente para los usuarios). El modelo TCP/IP sólo tiene un modo en la

capa de red (no orientado a la conexión) pero soporta ambos modos en la capa de transporte, lo que da

a los usuarios la oportunidad de elegir. Esta elección es importante especialmente para protocolos

sencillos de solicitud-respuesta.


120

Glosario

ARP - Address Resolution Protocol

BGP - Border Gateway Protocol

CPU - Central Processor Unit

CIDR - Classless Inter-Domain Routing

CBT - Core Based Trees

DNS - Domain Name Server

DHCP - Dynamic Host Configuration Protocol

EGP - Exterior Gateway Protocol

EUI-64 - Extended Unique Identifier 64

FTP - File Transfer Protocol

GGP - Gateway-to-Gateway

HTTP - HyperText Transfer Protocol

IETF - Internet Engineering Task Force

IANA - Internet Assigned Numbers Authority

ISP - Internet Service Provider

IP – Internet Protocol

ICMP - Internet Control Message Protocol

IGMP - Internet Group Management Protocol

IGP - Interior Gateway Protocol

ISATAP - Intra-Site Automatic Tunneling Addressing Protocol

Is-Is - Integrated System to Integrated System

IEEE - Institute of Electrical and Electronics Engineers

LSA - Link State Advertisements

NAT - Network Address Translation

NAT-PT - Network Address Translation with Protocol Translation

NDP - Neighbor Discovery Protocol

MLD - Multicast Listener Discovery

MAC address - Media Access Control address

OSPF - Open Shortest Path First

PIM - Protocol Independent Multicast

POP - Post Office Protocol

QoS - Quality of Service

RIR - Registro de Internet Regional

RIPng - Routing Information Protocol Next Generation

RIP - Routing Information Protocol

SMTP - Simple Mail Transfer Protocol

ST - Stream

SLAAC - Stateless Address Autoconfiguration

STUN - Session Traversal Utilities for NAT

TELNET – Telecommunication Network

TCP – Transmission Control Protocol

UDP - User Datagram Protocol

VoIP - Voice Over Internet Protocol

VLAN - Virtual Local Area Network

Documents

INSTITUTO POLITÉCNICO NACIONALtesis.ipn.mx/jspui/bitstream/123456789/13174/1/TS IPv6.pdf · 2017-06-12 · Un agradecimiento muy especial a mi mujer, Patricia Polo por apoyarme siempre,