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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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)
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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:2d2::/32 Grupo Telecom de Monterrey
2806:2d3::/32 Grupo Telecom de Monterrey
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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)
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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:
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Gateway
2001:0db8:1234:3f0d::1/64
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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)
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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).
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
42 Administrativos_2 172.16.42.0 /27 172.16.42.30
43 Administrativos_3 172.16.43.0 /27 172.16.43.30
44 Administrativos_4 172.16.44.0 /27 172.16.44.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
Instituto Politécnico Nacional ESIME
EDIFICIO 1 EDIFICIO 2 EDIFICIO 3 EDIFICIO 4
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
41 Administrativos_1 172.16.41.0 /27 172.16.41.30
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
VLAN ID VLAN NAME NETWORK DEF. GATEWAY
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
42 Administrativos_2 172.16.42.0 /27 172.16.42.30
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
VLAN ID VLAN NAME NETWORK DEF. GATEWAY
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
43 Administrativos_3 172.16.43.0 /27 172.16.43.30
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
VLAN ID VLAN NAME NETWORK DEF. GATEWAY
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
44 Administrativos_4 172.16.44.0 /27 172.16.44.30
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
3 Estudiantes_3 2001:db8:df:0003::/64 2001:db8:df:0003::a/64
4 Estudiantes_4 2001:db8:df:0004::/64 2001:db8:df:0004::a/64
5 Estudiantes_5 2001:db8:df:0005::/64 2001:db8:df:0005::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
22 Profesores_2 2001:db8:df:0022::/64 2001:db8:df:0022::a/64
23 Profesores_3 2001:db8:df:0023::/64 2001:db8:df:0023::a/64
24 Profesores_4 2001:db8:df:0024::/64 2001:db8:df:0024::a/64
25 Profesores_5 2001:db8:df:0025::/64 2001:db8:df:0025::a/64
Profe
sore
s
Adm
instra
tivo
41 Administrativos_1 2001:db8:df:0041::/64 2001:db8:df:0041::a/64
42 Administrativos_2 2001:db8:df:0042::/64 2001:db8:df:0042::a/64
43 Administrativos_3 2001:db8:df:0043::/64 2001:db8:df:0043::a/64
44 Administrativos_4 2001:db8:df:0044::/64 2001:db8:df:0044::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
62 Visitas_2 2001:db8:df:0062::/64 2001:db8:df:0062::a/64
63 Visitas_3 2001:db8:df:0063::/64 2001:db8:df:0063::a/64
64 Visitas_4 2001:db8:df:0064::/64 2001:db8:df:0064::a/64
65 Visitas_5 2001:db8:df:0065::/64 2001:db8:df:0065::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
101 Serv idores_1 2001:db8:df:0101::/64 2001:db8:df:0101::a/64
102 Serv idores_2 2001:db8:df:0102::/64 2001:db8:df:0102::a/64
103 Serv idores_3 2001:db8:df:0103::/64 2001:db8:df:0103::a/64
104 Serv idores_4 2001:db8:df:0104::/64 2001:db8:df:0104::a/64
105 Serv idores_5 2001:db8:df:0105::/64 2001:db8:df:0105::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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
V ID VLAN NAME PREFIJO DEF. GATEWAY
EDIFIC
IO 1
2 Estudiantes_2 2001:db8:df:0002::/64 2001:db8:df:0002::a/64
EDIFIC
IO 1
21 Profesores_1 2001:db8:df:0021::/64 2001:db8:df:0021::a/64
41 Administrativos_1 2001:db8:df:0041::/64 2001:db8:df:0041::a/64
61 Visitas_1 2001:db8:df:0061::/64 2001:db8:df:0061::a/64
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
3 Estudiantes_3 2001:db8:df:0003::/64 2001:db8:df:0003::a/64
EDIFIC
IO 2
22 Profesores_2 2001:db8:df:0022::/64 2001:db8:df:0022::a/64
42 Administrativos_2 2001:db8:df:0042::/64 2001:db8:df:0042::a/64
62 Visitas_2 2001:db8:df:0062::/64 2001:db8:df:0062::a/64
82 Voz_2 2001:db8:df:0082::/64 2001:db8:df:0082::a/64
102 Serv idores_2 2001:db8:df:0102::/64 2001:db8:df:0102::a/64
EDIFIC
IO 2
EDIFICIO 1 EDIFICIO 2 EDIFICIO 3 EDIFICIO 4
UNIDAD DE INFORMÁTICA
Figura 3.5 Distribución geográfica del direccionamiento IPv4.
VID VLAN NAME NETWORK DEF. GATEWAY
EDIFIC
IO 3
4 Estudiantes_4 2001:db8:df:0004::/64 2001:db8:df:0004::a/64
23 Profesores_3 2001:db8:df:0023::/64 2001:db8:df:0023::a/64
43 Administrativos_3 2001:db8:df:0043::/64 2001:db8:df:0043::a/64
63 Visitas_3 2001:db8:df:0063::/64 2001:db8:df:0063::a/64
83 Voz_3 2001:db8:df:0083::/64 2001:db8:df:0083::a/64
103 Servidores_3 2001:db8:df:0103::/64 2001:db8:df:0103::a/64
EDIFIC
IO 3
VID VLAN NAME NETWORK DEF. GATEWAY
EDIFIC
IO 4
5 Estudiantes_5 2001:db8:df:0005::/64 2001:db8:df:0005::a/64
24 Profesores_4 2001:db8:df:0024::/64 2001:db8:df:0024::a/64
44 Administrativos_4 2001:db8:df:0044::/64 2001:db8:df:0044::a/64
64 Visitas_4 2001:db8:df:0064::/64 2001:db8:df:0064::a/64
84 Voz_4 2001:db8:df:0084::/64 2001:db8:df:0084::a/64
104 Servidores_4 2001:db8:df:0104::/64 2001:db8:df:0104::a/64
EDIFIC
IO 4
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
.
.
.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
SW-1(config-vlan)#ex
SW-1(config)#vlan 41
SW-1(config-vlan)#ex
SW-1(config)#vlan 61
SW-1(config-vlan)#ex
SW-1(config)#vlan 81
SW-1(config-vlan)#ex
SW-1(config)#vlan 101
SW-1(config-vlan)#ex
Edificio 1
F0/23
Troncal
VLANs
Edificio 2
F0/23
Troncal
VLANs
Edificio 3
F0/23
Troncal
VLANs
Edificio 4
F0/23
Troncal
VLANs
Instituto Politécnico Nacional ESIME
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”
SW-1(config)#interface fastethernet 0/3
SW-1(config-if)# switchport mode access
SW-1(config-if)# switchport access vlan 21 “Para VLAN 21”
SW-1(config)#interface fastethernet 0/4
SW-1(config-if)# switchport mode access
SW-1(config-if)# switchport access vlan 81 “Para VLAN 81”
SW-1(config)#interface fastethernet 0/10
SW-1(config-if)# switchport mode access
SW-1(config-if)# switchport access vlan 41 “Para VLAN 41”
SW-1(config)#interface fastethernet 0/11
SW-1(config-if)# switchport mode access
SW-1(config-if)# switchport access vlan 61 “Para VLAN 61”
SW-1(config)#interface fastethernet 0/12
SW-1(config-if)# switchport mode access
SW-1(config-if)# switchport access vlan 101 “Para VLAN 101”
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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]
via FE80::205:5EFF:FE55:C301, FastEthernet0/0
R 2001:DB8:DF:22::/64 [120/2]
via FE80::240:BFF:FE14:D414, FastEthernet0/1
R 2001:DB8:DF:41::/64 [120/2]
via FE80::205:5EFF:FE55:C301, FastEthernet0/0
R 2001:DB8:DF:42::/64 [120/2]
via FE80::240:BFF:FE14:D414, FastEthernet0/1
R 2001:DB8:DF:61::/64 [120/2]
via FE80::205:5EFF:FE55:C301, FastEthernet0/0
R 2001:DB8:DF:62::/64 [120/2]
via FE80::240:BFF:FE14:D414, FastEthernet0/1
R 2001:DB8:DF:81::/64 [120/2]
via FE80::205:5EFF:FE55:C301, FastEthernet0/0
R 2001:DB8:DF:82::/64 [120/2]
via FE80::240:BFF:FE14:D414, FastEthernet0/1
C 2001:DB8:DF:100::/64 [0/0]
via ::, FastEthernet1/1
L 2001:DB8:DF:100::A/128 [0/0]
via ::, FastEthernet1/1
R 2001:DB8:DF:101::/64 [120/2]
via FE80::205:5EFF:FE55:C301, FastEthernet0/0
R 2001:DB8:DF:102::/64 [120/2]
via FE80::240:BFF:FE14:D414, FastEthernet0/1
C 2001:DB8:DF:FFF1::/64 [0/0]
via ::, FastEthernet0/0
L 2001:DB8:DF:FFF1::2/128 [0/0]
via ::, FastEthernet0/0
C 2001:DB8:DF:FFF2::/64 [0/0]
via ::, FastEthernet0/1
L 2001:DB8:DF:FFF2::1/128 [0/0]
via ::, FastEthernet0/1
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.
Instituto Politécnico Nacional ESIME
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:
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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://technet.microsoft.com/es-es/library/cc758763(v =ws.10).aspx
http://msdn.microsoft.com/es-es/library/ms172317(v =v s.110).aspx
http://technet.microsoft.com/es-es/library/cc725720(v =ws.10).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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Instituto Politécnico Nacional ESIME
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.
Instituto Politécnico Nacional ESIME
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
Top Related