Introducción A IPv6 - Unidad 1

CURSO:
Introduccin a IPv6, el futuro de

Internet.
Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

UTN - FRBA. Secretara de Cultura y Extensin Universitaria
Medrano 951 2do piso (1179) // Tel. +54 11 4867 7589 / Fax +54 11 4032 0148 // e-learning@sceu.frba.utn.edu.ar
www.sceu.frba.utn.edu.ar/e-learning
p. 2
Unidad 1:
IPv4 vs IPv6, Formato de header principal y extendido.

p. 3
Presentacin:
En esta primera Unidad del curso, nos introducimos en la comprensin del porqu de la
necesidad de implementacin de un nuevo protocolo IP y de sus implicancias.
Comenzaremos por definir las limitaciones de la versin actual y de las consideraciones
que se tuvieron en cuenta al momento de disear la nueva versin.
Paso seguido nos introduciremos en los detalles de la implementacin de IPv6, haciendo
foco en una comparacin con IPv4 y las ventajas que aporta teniendo en cuenta los
objetivos planteados para la Internet de las siguientes dcadas.
Se bien se abordara un detalle del de los distintos campos que forman el Header de esta
nueva versin, se pretende como foco fundamental, que quede bien en claro que esta
nueva versin posee importantes cambios en el modo de trabajo, los cuales son ms
importantes que el simple incremento de las direcciones disponibles.
De todos modos y para no generar miedos innecesarios, se adelanta que en el momento
de analizar los protocolos de ruteo, se encontrar que son mucho mayores las similitudes
con IPv4, que las diferencias.

p. 4
Objetivo:
Al terminar la Unidad los participantes abran analizado:
Las principales limitaciones del protocolo IP en su versin 4.
La propuestas de soluciones planteadas por IP v6.
La manera en la cual se dise los Header para cumplir con los requerimientos del
protocolo IP en las prximas dcadas.

p. 5
Bloques temticos:
1. Problemas de la implementacin actual de IP.

2. Headers de IPv4 eliminados.
3. Headers de IPv4 modificados.
4. Headers agregados en IPv6 (extension headers).

p. 6
Consignas para el aprendizaje colaborativo

En esta Unidad los participantes se encontrarn con diferentes tipos de actividades que,
en el marco de los fundamentos del MEC*, los referenciarn a tres comunidades de
aprendizaje, que pondremos en funcionamiento en esta instancia de formacin, a los
efectos de aprovecharlas pedaggicamente:
Los foros proactivos asociados a cada una de las unidades.
La Web 2.0.
Los contextos de desempeo de los participantes.
Es importante que todos los participantes realicen algunas de las actividades sugeridas y
compartan en los foros los resultados obtenidos.
Adems, tambin se propondrn reflexiones, notas especiales y vinculaciones a
bibliografa y sitios web.
El carcter constructivista y colaborativo del MEC nos exige que todas las actividades
realizadas por los participantes sean compartidas en los foros.

p. 7
Tomen nota
Las actividades son opcionales y pueden realizarse en forma

individual, pero siempre es deseable que se las realice en equipo, con la finalidad de
estimular y favorecer el trabajo colaborativo y el aprendizaje entre pares. Tenga en cuenta
que, si bien las actividades son opcionales, su realizacin es de vital importancia para el
logro de los objetivos de aprendizaje de esta instancia de formacin. Si su tiempo no le
permite realizar todas las actividades, por lo menos realice alguna, es fundamental que lo
haga. Si cada uno de los participantes realiza alguna, el foro, que es una instancia clave en
este tipo de cursos, tendr una actividad muy enriquecedora.
Asimismo, tambin tengan en cuenta cuando trabajen en la Web, que en ella hay de todo,
cosas excelentes, muy buenas, buenas, regulares, malas y muy malas. Por eso, es
necesario aplicar filtros crticos para que las investigaciones y bsquedas se encaminen a
la excelencia. Si tienen dudas con alguno de los datos recolectados, no dejen de consultar
al profesor-tutor. Tambin aprovechen en el foro proactivo las opiniones de sus compaeros
de curso y colegas.

p. 8
Protocolo IPv5
El protocolo de red utilizado mayoritariamente en la actualidad en internet como todos

sabemos, es la versin 4 del protocolo IP. El protocolo que estamos actualmente
empezando a implementar y que viene a reemplazar a dicho protocolo es la versin 6 de
mismo.
Ante esto puede surgir la duda de que es, o que pas con la versin 5 del protocolo.
Lo cierto es que la versin 5 fue una versin de prueba experimental que no tena nada en
comn con los objetivos planteados para IPv6.
El objetivo de IPv5, fue nicamente realizar un protocolo similar a IP, pero que permitiera la
reserva de recursos. Esto es por ejemplo, poder solicitar ancho de banda, antes de efectuar
una llamada.
Agotamiento de las direcciones de IPv4

Como todos sabemos, para tener presencia en internet, todo dispositivo necesita tener una
direccin IPv4 que sea nica a nivel mundial.
Esto es, la cantidad de direcciones de IPv4 disponibles es un recurso limitado, que
lamentablemente se est agotando muy rpidamente.
Esto se debe a diversas causas:
Una de ellas es simplemente el crecimiento de la poblacin mundial que tiene acceso al
uso de internet.
Esto se da principalmente impulsado por el crecimiento de las poblaciones de pases
como India y China, en los cuales adems, por el crecimiento del nivel de vida de su
poblacin, se incorporan diariamente miles y miles de personas al acceso a internet.
Otra cuestin a considerar, es lo que se llama internet de las cosas (Internet of Things
o IoT).

p. 9
Estbamos acostumbrados a que las direcciones IP eran utilizadas para conectar

grandes mquinas, servidores o PC de usuarios a internet.
Hoy en da con el abaratamiento de los costos de la electrnica, es cada vez ms comn
que, no solamente dispositivos celulares, si no dispositivos ms pequeos, como puede
ser controladores de puerta, dispositivos de los automotores, telfonos convencionales,
encendido y apagado de luces, control de aires acondicionados o cualquier dispositivo
de la casa o empresa, quiera ser conectado a internet.
Esto sin duda traer que el requerimiento de direcciones sea cada vez mayor.
El organismo que se encarga a nivel mundial de asignar las direcciones IP, para evitar que
las mismas se dupliquen en distintas empresas, es el IANA.

p. 10
Este organismo toma bajo su control todo el rango de direcciones IPv4 disponibles y se los
asigna a distintos sub organismos regionales, que se encargan de administrar las
direcciones a utilizar en distintas zonas del planeta, como se ve en el ejemplo siguiente,
esas zonas son: APNIC, RIPE, AfriNIC, LacNIC en nuestro caso para Amrica Latina y
ARIN para Estados Unidos.
En la actualidad, el IANA ya se ha quedado sin direcciones IP para asignar. Todas las

disponibles han sido entregadas para su control a los distintos organismos de
administracin local, por lo cual el IANA ya no tiene la posibilidad de asignar ningn nuevo
rango de direcciones IPv4.
En algunos casos, estos organismos regionales, como en el caso de APNIC, ya se van
quedando tambin sin direcciones IP para asignar.
Esto se puede ver en algunas grficas siguientes en las cuales se muestran los rangos de
direcciones IPv4 disponibles para asignar en cada regin o grficos estadsticos, en los

p. 11
cuales se pretende prever, en forma estadstica, en qu momento se van a agotar las

direcciones disponibles en cada regin, segn es la cantidad actualmente disponible y la
cantidad de incremento de uso cada uno.

p. 12
Lo cierto es, que ms all de cualquier intento de prediccin de cuando se acabarn las
direcciones disponibles en cada zona del planeta. Ya en la actualidad hay zonas, en las
cuales no existen disponibilidad para asignar nuevos rangos de direcciones IPv4.
En algunos casos se estudian estos grficos y se pretende estimar cuando ser el momento
en el cul sa escases llegue a una zona determinada del planeta, como en nuestro caso
Amrica Latina.
Lo cierto es que tenemos que tener en cuenta, que internet es una red mundial. Lo cual
implica que el hecho de que en Asia y Pacfico ya se hayan agotado las direcciones de
IPv4, es algo que repercute en todas las regiones del mundo.
Esto implicara a la fuerza problemas de conectividad entre pares de empresas, o entre
empresas y clientes, de distintas partes del mundo.

p. 13
Como veremos en esta unidad, la manera de solucionar la falta de direcciones, es

implementando una nueva versin del protocolo, que es la nmero 6, la cual tiene como
principal caracterstica el usar un espacio de direccionamiento enormemente mayor que
disponible para IPv4. Asegurndonos de esta manera tener suficientes direcciones
disponibles para cualquier futuro actualmente imaginable de la evolucin de internet.
Problemas de IPv4
Como ya hemos mencionado en el punto anterior, el principal problema de IPv4 es la falta

de direcciones disponibles para permitir un mayor crecimiento de internet.
Sin duda, como veremos en esta unidad, esto se soluciona cambiando simplemente el
esquema de direccionamiento por uno que posea mayor cantidad de bits disponibles para
asignar nuevas direcciones. Pero es importante tambin considerar que este no es el
nico problema existente en IPv4.
IPv4 fue un protocolo diseado hace muchos aos, el cual ha tenido un enorme crecimiento.
En el momento de disear dicho protocolo, no se tuvieron en cuenta todos los posibles
usos, que este iba a tener en el futuro.
Esto ha generado otra serie de inconvenientes, como por ejemplo:
Crecimiento de las tablas de ruteo.
Requerimiento de calidad de servicio o reserva de ancho de banda.
Mejor en seguridad e implementacin de IP Sec.
Uso de NAT.
Posibilidad de aplicar o utilizar el protocolo IP, no desde estaciones fijas en un punto

determinado del planeta, si no desde estaciones que se estn moviendo.( Mobile IP)

p. 14
Incremento en el trfico de Broadcast en los segmentos de LAN.
Problema de asignacin dinmica de direcciones IP.
Cuando nos referimos a grandes volmenes de conexiones, como en este caso

particular por ejemplo en algunas redes de Cableras, el hecho de que toda una
regin se desconecte y necesite volver a conectarse, genera una carga tan excesiva
en el protocolo de asignacin dinmico de direcciones (DHCP) que hace lo que
debera hacer un corte menor pueda generar una cada de servicios que dure
inclusive en algunos casos varias horas.
Teniendo esto en cuenta y la posibilidad de implementacin de redes cada vez

mayores, se decidi implementar en IPv6 la posibilidad de que los dispositivos
puedan auto configurarse, sin requerir del uso de un servidor de DHCP.
Esto son algunos de los problemas que presenta el direccionamiento IP actual.

Sin duda un incremento de la cantidad de dispositivos conectados a internet va a tener
como resultado que estos problemas aumenten a una escala tal que es posible que hagan
colapsar por completo la totalidad de Internet.
Para tener una mejor idea de lo que estamos hablando, tomemos por ejemplo del
crecimiento de la cantidad de direcciones de IP que debe analizar cada router conectado a
internet y el crecimiento del trfico.
Los routers deben poseer suficiente memoria para almacenar todas las direcciones de
prefijos alcanzadas a nivel mundial.
Como se ve en la siguiente grfica, este es un nmero que se incrementa exponencialmente
con el paso del tiempo.

p. 15
En el caso de IPv6, debemos tener en cuenta, adems, que estas direcciones son mucho
ms largas en tamao, por el cul requerirn mayor capacidad de memoria del equipo.
Adems de eso, durante el proceso de migracin de IPv4 a IPv6, que sin duda durar varias
dcadas, los equipos de internet, debern agregar a su direccionamiento IPv4 actual, en
paralelo el direccionamiento IPv6.
Sin duda este solo hecho generar un incremento de los requerimientos de capacidad de
los equipos muy difcil de manejar.

p. 16
Por otro lado, tendramos que tener en cuenta la capacidad de procesamiento requerida en
cada equipo, para manejar el trfico. Esta capacidad de direccionamiento, es proporcional
al trfico, el cual tambin est en incremento, como se nota en los siguientes grficos.
Adems el esfuerzo del router para re enviar cada paquete se ver afectada, por el
incremento de las rutas disponibles en las tablas de ruteo y el tamao del campo a analizar
al rutear cada paquete.
Esto es, por cada paquete que ingresa a un router, debo analizar la totalidad de la tabla de
ruteo, la cual est incrementndose en tamao y adems para el caso de IPv6, debo realizar
comparaciones con tamao de direcciones cuatro veces mayores.
Sumando todo esto efecto, el paso del trfico de IPv4 a IPv6 podra crear una sobrecarga
en los requerimientos de la red, que genere el colapso de gran parte de la estructura de
Internet.

p. 17
Teniendo estos factores en cuenta, se han efectuado diversas modificaciones al modo de

operacin de IPv6, para liberar a la red de todo trabajo innecesario y permitir adems un
diseo jerrquico que controle mejor el crecimiento de las tablas de ruteo.
Lo importante de esto, es que este cambio en el modo de trabajo, tiene determinadas

implicancias, que es necesario entender en el momento del diseo de una red IPv6.
Dichas modificaciones no solo deben ser comprendidas por el personal de comunicaciones,
dado que la misma podr tener importantes efectos en los aspectos de seguridad y diseo
de aplicativos.
Eliminacin del uso de direcciones privadas.

Otro de los puntos que se considera en el diseo de IPv6, es la posibilidad de asignar a
todos los dispositivos direcciones pblicas (Ruteables a nivel global).
Esto es permitir que cualquier dispositivo se pueda conectar con cualquier otro de internet,
sin necesidad de pasar por un PROXY, o verse sometido a un proceso de NAT.
Sin dudas el hecho de eliminar, el proceso de NAT, por un lado puede aumentar, como
demuestran algunos estudios el nivel de seguridad de la red y por otro lado puede permitir
el surgimiento de nuevas aplicaciones, que si bien en algunos casos son aplicables o
realizables hoy en da, se ven dificultadas por la presencia del proceso de NAT.
Autoconfiguracin.
Otro de los puntos que se incorpora a IPv6 es la posibilidad de que los equipos se auto
configuren, sin requerir la presencia de un servidor de DHCP.

p. 18
Tamao de campo de direcciones en IPv6
En IPv4, el campo de direcciones tiene 32 bits.

Esto nos da una capacidad aproximada direccional 4 mil millones de dispositivos con una
direccin nica en internet.
Sin duda un nmero demasiado pequeo para el crecimiento que esta registrando Internet
en la actualidad.
En el caso de IPv6, la cantidad de bits disponibles en el campo de direcciones es de 128
bits.
Esto es cuatro veces mayor.
Un anlisis rpido puede llevarnos al error de pensar que hemos multiplicado por cuatro la
cantidad de direcciones disponibles, pero esto no es correcto. Lo que hemos multiplicado
por cuatro es la cantidad de bits disponibles.
Si aumentramos el campo de direcciones de IPv4 nicamente en un bit, estaramos

duplicando el tamao de las direcciones disponibles.
En nuestro caso, al multiplicar por cuatro la cantidad total de bits estaramos generando un
espacio direccionamiento muy complicado de asimilar para los valores numricos a los que
estamos acostumbrados a trabajar.
Esto es aproximadamente multiplicar los cuatro mil millones de direcciones que tenamos
disponibles por cuatro mil millones, por cuatro mil millones y nuevamente por cuatro mil
millones. Sin duda esto da un nmero demasiado elevado.
En el momento de generarse IPv4 existan muy pocos ordenadores a nivel mundial. Con lo
cual el nmero de cuatro mil millones de direcciones pareca algo que nunca se iba a
alcanzar.
Es lgico que hoy en da pensemos si no ocurrir lo mismo, con el tamao de direcciones
que actualmente le asignamos a IPv6.

p. 19
Para comprender el enorme tamao del espacio de direcciones al que nos estamos
refiriendo existen mltiples comparaciones en Internet.
Por ejemplo comparan la cantidad de direcciones con el nmero de tomos que existen en
una ballena.
De todos los ejemplos disponibles, creo que el que mejor nos permite visualizar que tan
til ser este espacio direccionamiento en el futuro, es uno que relaciona la cantidad de
direcciones IP disponibles con este nuevo esquema por cada metro de superficie del
planeta.
En realidad esta comparacin no habla de cantidad de direcciones por metro cuadrado, si
no que habla de cantidad de direcciones disponibles por milmetro cuadrado de la superficie
de la Tierra y al nmero que se llega es 6,7 mil billones de direcciones.
Sin duda es un nmero que va a hacer muy difcil de alcanzar o superar. Por lo que
podemos suponer que el esquema de direccionamiento actualmente planteado, no va a
llegar en ningn momento a ser saturado.

p. 20
Representacin de las direcciones de IPv6
En el caso de IPv4, los 32 bits que forman la direccin, se representan agrupados de a ocho
en formato decimal y separados por un punto cada grupo de ocho bits. Esto nos lleva al
tpico ejemplo de direcciones, por ejemplo:
201.10.2.5
En el caso de querer representar una red, existen dos opciones: se muestra a continuacin
la mscara de bits que representa a la red o simplemente con una barra se indica la cantidad
de bits consecutivos de la direccin que sern utilizados para representar la parte que
identifica a la red en s.
201.10.2.0 255.255.255.0
O
201.10.2.0 / 24
En el caso de IPv6, en el cual la cantidad de bits es mucha mayor, para su representacin,

se ha adoptado otro esquema en el cual los bits en vez de agruparse de a ocho, se agrupan
de a diecisis, se lo separa por un conjunto de dos puntos.
A cada grupo de diecisis bits, en vez de presentarse en formato decimal, lo cual generara
un nmero demasiado largo, se lo presenta en formato Hexa decimal.

p. 21
Por ejemplo:
2001:0310:0110:0102:0201:2BCF:1234:4302
Al igual que en el caso de IPv4, cuando queramos referirnos a una direccin de red, se
puede indicar esta por medio del nmero de la direccin seguido por una barra invertida y
la cantidad de bits que sern utilizados para representar la mscara.
Por ejemplo:
2001:0310:0110:0102:0000:0000:0000:0000 / 64
En siguiente unidad, veremos determinadas normas que se utilizan para simplificar el modo
en el cul se representan este tipo de direcciones.

p. 22
Agregacin de direcciones y tamao de la tabla de ruteo de internet.
Tanto para IPv4 como para IPv6, a todo dispositivo que se conecte con internet, se le asigna
una direccin nica a nivel mundial.
Los rangos a los que pertenecen dichas direccin como hemos visto las administra un
organismo denominado IANA.
El IANA asigna rango de direcciones contiguas a los distintos registros regionales.
Esos registros regionales a su vez asignan rangos de IP contiguos a los distintos Service
Provider, los cuales a su vez asignan direcciones o rango de direcciones ms pequeos a
cada usuario final.
Este esquema jerrquico, hace que los routers del centro de internet, que manejan el mayor
volumen de trfico, no necesiten saber en forma detallada el rango de direcciones IP
asignado a cada empresa del planeta.
Simplemente alcanza con que sepan rutear los datagramas a los distintos rangos mayores
asignados a cada Service Provider (SP).
Luego ser cada SP ser responsable de conocer la sub divisin de dicho rango entre todos
sus clientes.
De este modo, se puede disminuir notablemente el tamao de las tablas de ruteo que tiene
que manejar los equipos centrales de la red.
Como se muestra en el siguiente ejemplo de direccionamiento jerrquico con IPv6, a un

usuario final, se le puede asignar un rango de direcciones barra 48.

p. 23
En este caso al usuario A el rango 2001:0dv8:001::/48.

Ms adelante veremos en detalle cmo se interpreta esta direccin, pero lo importante es
que es un rango que tiene una parte de red de 48 bits.
Al usuario B, se le asigna otro rango similar tambin de 48 bits, pero los dos pertenecientes
a un rango mayor de un mismo ISP o Internet Service Provider.
Eso hace que el ISP pueda ensear a los routers de internet, no todos sus rangos /48 en
forma individual, sino un rango /32, que acumule mucha mayor cantidad de usuarios en
forma conjunta y que haga por lo tanto ms chica la tabla de ruteo global de internet.

p. 24
Si bien este esquema jerrquico ya exista en IPv4, se empezaban a presentar algunos

inconvenientes de ruteo que no analizaremos en detalle, pero que se daban en el caso cada
vez ms comn, de que un usuario decidiera conectarse al mismo tiempo a dos ISPs.
Como es sabido internet es muy importante para la economa de la Empresa, y cada vez
es menos aceptable el estar desconectado de la red, aunque sea por un pequeo periodo
de tiempo.
Dado esto, para protegerse de las posibles fallas de servicio de un ISP se utiliza lo que se
llama MULTIHOMIN, que es conectarnos al mismo tiempo a dos ISPs.
En el caso de IPv4, la manera de implementar MULTIHOMING, era que un usuario si

decida navegar o publicar un servicio en internet por medio del ISP1, lo hiciera con un
rango de direcciones asignado por ese ISP.
Si en algn momento determinado decida trabajar o navegar usando el rango de
direcciones provisto por el segundo ISP, deba de algn modo utilizar el rango de
direcciones del segundo.
Esto traa una serie de inconvenientes, que se solucionaba llamaba Asignacin de rango
de direcciones independientes del Provider.
Esto es simplemente asignar a un usuario que deseara utilizar MULTIHOMING, un rango
de direcciones que no perteneca ni al Service Provider A, ni al Service Provider B.
El rango de direcciones se asignaba directamente al usuario final.
Esto simplificaba los sistemas de ruteo, haca que ese nico rango pudiera se informado
por los dos ISPs, pero tena como consecuencia que ese rango tena que pasar a ser visible
en el resto de internet, o sea, dicho de otra manera, no poda ser sumarizado
jerrquicamente, generando los problemas de crecimiento de las tablas de ruteo que
comnmente vemos con IPv4.
En el caso de IPv6, se ha hecho un esfuerzo para evitar este tipo de problemas y permitir
construir este nuevo internet en un esquema jerrquico que no sea violado por la asignacin
de direcciones individuales a cada usuario.
Esta es posible por medio de la modificacin del modo comn de trabajo empleado en IPv4.

p. 25
Mientras que en el caso de IPv4, solamos asignar una direccin IP a un dispositivo, en el

caso de IPv6, se puede asignar a un mismo dispositivo ms de una direccin IP.
Incluso veremos que este es el modo de trabajo ms comn, teniendo cada dispositivo en
IPv6 comnmente un mnimo de dos direcciones.
Para el ejemplo que estamos planteando un mismo usuario A podra tener asignado un
rango de direcciones perteneciente al Service Provider A, y otro perteneciente al Service
Provider B, los cuales seran sumarizados en forma normal en internet y el usuario
libremente podra navegar utilizando uno u otro rango de direccionamiento.
Veremos ms adelante como se hace esta asignacin y el esfuerzo que se ha hecho para
permitirle a IP trabajar con mltiples rangos de direcciones y permitir una remuneracin de
los equipos mucho ms simple en caso de ser necesario.
Header de IPv6

p. 26
Como ya hemos mencionado, una de las cuestiones a las que se le presento mayo foco
durante el diseo de IPv6 fue conseguir buenas tazas de transmisin y afectar lo mnimo
posible la performance de los routers, a pesar de estar usando un rango de direcciones que
debe ser procesado por cada equipo que es cuatro veces mayor en tamao en cantidad de
bits.
Para esto se ha modificado el Header y el funcionamiento del protocolo en s, tratando de

optimizarlo de distintos modos.
A continuacin veremos los distintos campos que el Header IPv4 comparados con el
Header IPv6 y veremos que muchos campos han sido eliminados o cambiados de nombre.
En trminos generales, lo que se ha buscado es tener un Header lo ms simple posible,

para lo cual todo lo que no era estrictamente necesario fue eliminado o pasado a otro nivel.
Tambin se ha buscado que el nuevo Header tenga un tamao fijo y que todos sus campos
estn alineados a 64 bits.
El tema de que los campos estn alineados a 64 bits es para permitir un mejor
procesamiento con microprocesadores de 64 bits.
Esto sumado al hecho de tener un formato fijo, facilita la implementacin de muchas
funciones en hardware dedicado, consiguiendo por lo tanto mayores tazas de transmisin.

p. 27
En las siguiente figuras veremos en forma simplificada una comparacin de los Headers de
IPv4 y de IPv6, para ver sus funciones y como ha sido posible remover algunos de ellos.
En el caso del Header de IPv4, algunos campos estn pintados en gris.

Estos campos son los que han sido removidos del Header de IPv6.
El objetivo de esto como ya hemos mencionado es simplificar el formato general del header,
hacerlo ms chico, darle un tamao fijo y permitir su alineacin a campos de 64 bits.

p. 28
A modo de ejemplo en el Header de IPv6 se ve una flecha con un campo que indica Next
Header, luego explicaremos su funcin, pero lo que queda claro al ver la imagen con un
formato fijo es que ese siguiente campo, va a estar siempre en la misma posicin del
paquete. Es muy simple por lo tanto para un Hardware que se encargue de ruteo, anlisis
de QoS o de cualquier otro tipo de funcion, proceder rpidamente a buscar la informacin
del siguiente nivel, pues no necesita leer toda la informacin previa para identificar donde
esta este campo especifico.
Volviendo a los campos removidos, si bien no est pintado en gris en el Header de IPv4 ,
en IPv4 existe un campo de opciones que ya no es utilizado en IPv6.
En IPv6 todo lo que sea opcional queda fuera del Header principal.
Al remover este Header, se consigue principalmente, que el tamao de todo el Header sea
fijo, con lo cual no se hacen necesario, el campo de Padding que se utilizaba para hacer
una alineacin de los bits restantes hasta la frontera que se haba establecido y tampoco
hace falta el primer campo que est pintado en gris que es el de Header Length y que
indicaba la longitud del Header del IPv4.
Estos son los dos primeros campos que son removidos del Header de IPv4.
En segundo lugar para facilitar el trabajo de los routers se establece que en IPv6 est
prohibido la fragmentacin de paquetes en su trnsito por la red.
La fragmentacin de paquetes era en IPv4 un proceso por el cual cualquier dispositivo poda
generar un paquete de un tamao determinado, y si un router intermedio que no poda
transmitir el paquete de ese tamao, estaba autorizado a fragmentarlo.
Esto implicaba que el router debera hacer un trabajo extra, que hoy en dia ya no va a
realizar en IPv6.

p. 29
Adems se requera setear una serie de campos para permitir al dispositivo receptor
rearmar el paquete en su formato original.
Para eso se usaban los campos de la segunda fila indicados como identificacin, Flags y
Fragment Offset. Todos esos campos al prohibirse la fragmentacin en IPv6 en los routers,
han sido removidos del Header Principal.
Evidentemente esta funcin de fragmentacin de ser necesaria hoy en da va a tener que

ser realizada por el dispositivo original que enva los paquetes. Esto nos demuestra una
vez ms que en el caso de IPv6 no solo se ha cambiado el campo de direcciones, si no que
se ha cambiado en gran medida el esquema de trabajo del protocolo.
Otro punto de importancia en la evolucin de las redes, es que hoy en da los dispositivos
y los enlaces son mucho ms confiables, esto implica que la tasa de error es mucho menor.
En el pasado para evitar este tipo de problemas que eran bastante frecuentes, se decidi
introducir dentro del Header de IPv4 un campo de chequeo, denominado Header
Checksum.
Este campo si bien protega al paquete IPv4 la cabecera el paquete IPv4, generaba un gran
trabajo para los routers, pues al recibir cada paquete, el router se vea obligado a ejecutar
un proceso para calcular el Header Checksum, y compararlo con el del paquete recibido
para ver si era un paquete valido. Luego al retransmitirlo por otra interfaz, dado que algunos
campos del Header cambiaban como el caso del TTL o (Time To Live), el router se vea
obligado antes de transmitir el paquete a recalcular este Header e insertarlo nuevamente
en el paquete que el estaba por transmitir.
Todo este trabajo a sido removido en el caso de IPv6 pues se ha eliminado la funcionalidad
de Header Checksum dada la baja taza de errores presentes en la actualidad.
Cambiado de nombre.

p. 30
En otros casos, algunos campos del Header del IPv4 se mantienen pero han cambiado de
nombre, por ejemplo el campo Time to Live.
El campo Time to Live es un campo que impide que un datagrama IP quede circulando en
caso de encontrarse con un bucle en forma indefinida por la red.
Como todos sabemos, cada vez que un paquete es reenviado, este campo es
decrementado en uno y cuando llega a su valor de cero, es eliminado de la red.
El nombre de Time to Live se debe a que la definicin original del mismo estableca que un
router deba decrementar del mismo la cantidad de segundos que el paquete haba
permanecido en el router, esto es, si un paquete ingresaba en un router y el router lo
mantena en colado hasta que tena tiempo suficiente de procesarlo durante cuatro
segundos, deba decrementar el campo de Time to Live en cuatro unidades.
Como todos sabemos, en la actualidad no se espera que un router tarde varios segundos
en procesar un paquete, si no milisegundos, con lo cual en todos los casos siempre se
decrementa este campo en una unidad.
Dado eso, es que en el nuevo Header se mantiene la funcionalidad pero se ha cambiado
el nombre eliminando la palabra Time, en este caso en lugar del Time to Live, el nuevo
Header se llama Hop Limit, pues lo que establece es un lmite a la cantidad de saltos o
equipos que es capaz de atravesar cada paquete.
Luego tenemos tambin el campo Type of Service. El campo Type of Service se usa para
clasificar el trfico en distintas colas y darle distintos tratamientos en lo que se refiere a
calidad de servicio. Este campo se mantiene con funcionalidades similares a la de IPv4
pero ha sido renombrado como Traffic Class.
Adems de estos campos que han cambiado de nombre, se ha agregado un nuevo campo
que se llama Flow Label.
Todava no se han establecido muchos usos para este campo, pero la idea original del
mismo es permitir identificar a todos los paquetes que pertenecen a un mismo flujo de datos
para facilitar el tratamiento de los mismos en esquema de seguridad, balanceo o calidad de
servicio

p. 31

p. 32
Campo Next Header
Como se nota en la comparacin de los dos Headers, el campo de protocolo ha sido

cambiado por un campo denominado Next Header.
Este campo en IPv4, nos indicaba cul era el tipo de protocolo de capa 4 que estaba siendo
transportado por ese paquete.
Dicho de otro modo, nos indicaba con un nmero determinado si se trataba de TCP, de
UDP, ICMP o un protocolo especfico como podra ser el caso de OSPF.
Este campo en IPv6 ha sido cambiado por un nuevo campo que se llama Next Header.
Pasaremos ahora a explicar la importante funcionalidad de dicho campo.
En el diseo de IPv6, se present un interesante desafo, que era, por un lado, simplificar
el Header, con lo cual se elimina el campo de opciones.
Por el otro lado, tratar de realizar un protocolo que no tenga que ser cambiado en un futuro
cercano, porque carezca de alguna funcionalidad.
Como es fcil imaginarse, no hay modo de predecir al futuro, que nuevas funcionalidades
o requerimientos se le van a exigir al protocolo.
En el caso de IPv4, hoy en da enfrentamos importantes desafos para afrontar los temas
de movilidad.
Evidentemente cuando se invent IPv4 no existan muchas posibilidades de que alguien se

imaginaba, en un futuro no muy lejano, que la gente iba a tener un telfono celular que iba
a llevar en el bolsillo y desde el cual iba a acceder por medio del protocolo IP a cualquier
dato a cualquier parte del mundo.

p. 33
Es muy difcil imaginar el tipo de aplicaciones que puedan surgir a futuro, por eso, por un
lado se necesita el campo de opciones, pero por el otro, se decidi eliminarlo para
simplificar el Header de IPv4 en su formato bsico.
El truco que se ha realizado con el campo Next Header es el siguiente:

En el caso de que con el Header bsico de IPv6 podamos transmitir toda la informacin que
necesitamos se utiliza el Header del IPv6 y a continuacin con el campo de Next Header
se indica cual es el protocolo de capa tres transportado, del mismo modo que se haca con
el campo protocolo de IPv4.
En algunos grafico del Next Header, la imagen con una flecha pareciera indicar que es el
punto en el cul vamos a encontrar la siguiente informacin dentro del flujo de datos
binarios, pero en realidad recordemos que el siguiente campo de Next Header siempre est
en la posicin fsica.
El valor que va a ir en el campo de Next Header no es un apuntador a una posicin si no

un valor que nos indica que encontraremos a partir de dicha posicin fija.
En el caso ms simple el valor que posea no indicara que lo siguiente es el comienzo de
un paquete de UDP, TCP, ICMP, OSPF o algn otro protocolo.
Lo importante de este campo se da en el caso en que el Header bsico no sea suficiente
para transportar toda la informacin de capa tres requerida.
En dicho caso el campo nos indicara con un calor especial, que lo que continua es un
Header extendido con alguna informacin til de capa 3.
Por ejemplo para un paquete que ha sido fragmentado por el origen, se agregara a
continuacin del Header Basico, un nuevo Header extra con la informacin requerida para
tratar el re ensamblado del paquete.
Como se ver a continuacin, todos los Header agregados, poseen a su vez un campo Next
Header que nos indica cual es el tipo de informacin siguiente.

p. 34
Dado la enorme importancia que tiene el campo Next Header o los Extension Headers en
IPv6, presentaremos dos imgenes a continuacin que pretenden aclarar un poquo ms el
tema y agregar un concepto extra que es el encadenamiento de Headers.

p. 35
Como se ve en las dos imgenes, en el caso de que el Header bsico de IPv6 sea suficiente
para realizar todas funcionalidades de la etapa 3. El campo de Next Header simplemente
apuntar o indicar que lo que sigue a continuacin es un paquete de UDP, TCP o el
protocolo de capa 4 que corresponda.
Ese es el ejemplo mostrado en las dos grficas, en la primera parte.
En el caso en que nos encontremos por ejemplo con un paquete fragmentado, el campo de
Next Header, indicara que lo que sigue es un Header extra con informacin de
fragmentacin y a su vez, dicho campo extra, tendr otro campo Next Header que indicara
finalmente que lo que sigue es un paquete TCP, UDP o lo que corresponda.

p. 36
Otra opcin importante de este esquema es que puedo obtener distintas combinaciones de
Next Header , con lo cual el Header bsico de IP puede apuntar a otro Header extendido
que a su vez puede apuntar a otro Header extendido, que a su vez puede apuntar a un
siguiente Header extendido o a un protocolo de Capa 4.
De esta manera puedo tener un Header que se encargue de temas especficos de movilidad
que apunte a otro Header que indique que se ha realizado una fragmentacin y a
continuacin que apunte a un Header que tiene el protocolo de la capa siguiente.
La idea general es que de este modo sea simplificado el Header bsico, por lo tanto todo
router que no necesita procesar la informacin de las siguientes capas simplemente
dispone de forma rpida de toda la informacin necesaria para ejecutar el ruteo del equipo.
La mayora de los Headers extra no son procesados por los routers. Como ejemplo el router
no efecta ninguna tarea de fragmentacin, por lo tanto si se encuentra con un Next Header
que indica que contiene informacin de fragmentacin, simplemente lo ignora.
Adems de permitir un ruteo ms rpido de los datagramas, el esquema del Next Header
permite a futuro upgradear de forma simple el protocolo sin tener que pasar a una nueva
versin como podra ser IPv7.
Esto es simplemente, si llegase a surgir algn requerimiento de un nuevo Header que no
est cubierto en el Header bsico de IPv6, simplemente se podra agregar un campo de
Next Header con la informacin adecuada.
Sin duda esto es uno de los puntos ms importantes que hacen que IPv6 sea un protocolo,
con grandes posibilidades de crecimiento que no afecte tanto la estabilidad de la red o la
performance de los equipos y que tenga una larga vida por delante dado su facilidad de ser
extendido.
Otro campo que mantiene su funcionalidad pero que cambia de nombre es el campo de
Total Length, que en este caso pasa a llamarse Payload Length, esto es por haber dejado

p. 37
el Header de un tamao fijo simplemente podemos hacer referencia al tamao total de la

carga interior del paquete.
A continuacin y antes de profundizar en el tema de los distintos tipos de Header extendidos

que existen, vamos a presentar una serie de imgenes que pueden servir como repaso o
para ver en un formato distinto, y un poco ms claro los distintos campos de los paquetes
IPv4 e IPv6.

p. 38

p. 39

p. 40
Siguiendo nuestro anlisis del Extention Headers, veremos cules son los tipos de
Extention Headers que estn definidos en la actualidad.
Es bueno recordar que en caso de requerirse en el futuro nuevas funcionalidades para el

protocolo, se podrn generar nuevos Extention Headers de ser necesarios.
En la siguiente figura se ve los Extention Headers actualmente definidos.
En primer lugar tenemos Hop-by-Hop option y Source Routing.

p. 41
Estos dos Headers son los nicos que deben ser procesados por los routers, los
restantes Headers de la lista son nicamente para ser usados por los dispositivos finales y
por lo tanto ignorados por todos los routers.
El campo Hop-by-Hop options, es para agregar funcionalidades que deben ser ejecutadas
en cada equipo en el camino del paquete o datagrama.
El caso de Source Routing existen funcionalidades para forzar el seguimiento de un camino

determinado, las cuales han sido en algunos casos dados de baja por cuestiones de
seguridad.
Este Header es parte integra de lo que se denomina Mobile IP.
Esto es permitir que un dispositivo en movimiento como un celular pueda mantener su
direccin IP en forma independiente de en que parte del pas o del mundo se encuentra
conectado.
Esto es algo que en IPv4 se haca de una manera especial y que traa como consecuencia
en muchos casos el camino final de los datagramas no fueran ptimos.
Por ejemplo en el caso de IPv4 , dos dispositivos Mobile IP de la Argentina estuvieran
viajando por alguna ciudad del mundo, podran estar a poca distancia uno del otro y para
poder conectarse entre ellos, estaran forzados a pasar por un punto comn de Buenos
Aires.
En el caso de IPv6, con su funcionalidad de Mobile IP integrada se permite el trfico directo
de forma optimizada.
Los siguiente Headers son el Header de Fragmentacion, como ya se ha mencionado es

utilizado para la funcionalidades de fragmentacin de paquetes, que en este caso son
ejecutadas por los dispositivos extremos de la conexin.
Esto es, el que origina el datagrama es el que debera fragmentarlo y receptor el que debe
reconstruirlo, por lo tanto los routers intermedios hacen caso omiso de este tipo de Headers.

p. 42
Otra cuestin importante que ya hemos mencionado es que IPv6 trae algunas mejoras en
seguridad respecto a IPv4.
Algunas de ellas las veremos ms adelante, pero una de las que debemos mencionar ahora
es la posibilidad de autenticar los paquetes o encriptar los mismos.
En el caso de IPv4 , no exista ninguna seguridad para los datagramas definida en el

protocolo.
Si uno deseaba autenticar el origen de los paquetes o encriptar su contenido, debera
hacerlo mediante un protocolo especial que se denominaba IPsec y que era opcional.
En este caso, en el caso de IPv6, las funcionalidades de IPsec se han puesto como
mandatorias para el protocolo y por eso se incorporan directamente en los Headers.
La informacion requerida, se incorpora en los Headers que se denominan Authentication
and Encrypted Security Payload. En el caso de una conexin de extremo a extremo,
nuevamente estos Headers son nicamente utilizados por los equipos extremos y son
completamente ignorados por los routers intermedios.
Por ltimo, existe un Header extra que es denominado Destination Option, que como su
mismo nombre lo indica las funcionalidades del mismo son nicamente utilizadas para el
equipo final de la conexin.

p. 43
La siguiente tabla mostramos los tipos de Headers indicados, una breve descripcin de su
uso y en la columna tipo, el valor numrico que ira en el campo Next Header para indicar
cul es el siguiente Header que se ha incorporado al datagrama.
En la ltima columna tenemos la RFC en la cual est definido el uso de dicho Header.
Como sabemos las RFC son los documentos que definen la funcionalidad de los distintos
protocolos que usamos en IP y en internet.
Si bien no es muy comn su lectura, en este caso se menciona las distintas RFC y se
aconseja en el momento de realizar alguna implementacin recurrir a la pgina Web del
IETF (www.ietf.org) y verificar que la mencionada RFC siga siendo vigente.
No tanto para los campos que estamos mencionado, pero si se aconseja para los protocolos
de migracin de IPv6.
En algunos casos, algunos protocolos mencionados en muchos documentos han sido
declarados obsoletos y dados de baja.
La mejor manera de saber si una especificacin o protocolo sigue en uso o ha sido
reemplazado es verificando en la pgina del IETF.

p. 44
Presentamos a continuacin una tabla resumen con los valores del campo Next Header
ms comunes y algunos ejemplos de su uso.

p. 45

p. 46

p. 47
Formato bsico de los Extension Headers.
A continuacin mostramos el formato bsico de los Extension Headers.

En el se nota que todo Extension Headers. tiene un campo Next Header que indica cual es
el siguiente Header o protocolo de capa superior que lo sigue.
Adems de esto, estos campos ya pasan a tener longitud variable, por lo cual el siguiente
campo indica Extension Header Lenght que es la longitud total de Extension Headers.
Sin pretender avanzar en detalle en el anlisis de cada tipo de formato o informacin

transportada en las distintas variantes de los Extention Header, queremos mencionar un
punto que consideramos muy importante en lo que hace a la flexibilidad del protocolo de
IPv6.
Para eso presentamos a continuacin el formato del Header del tipo Hop-by-Hop.

p. 48
En l se ve que adems del campo Next Header y Ext. Length, toda la informacin
transportada se hace por medio de campos denominados TLV. Siendo la cantidad los
mismos opcional y variable.
Esto es algo que agrega un nivel extra de flexibilidad a lo ya visto en el campo del IPv6.
Por un lado, podamos generar nuevos Headers para transportar nueva informacin y por
el otro con este tipo de codificacin llamada TLV, se puede agregar opciones al Header ya
existente.
Este tipo de funcionalidad llamada TLV es muy usada en protocolos modernos del tipo BGP
o ISIS, no siendo utilizada lamentablemente en protocolos como OSPF lo cul le resta al
mismo cierto nivel de flexibilidad
Presentamos a continuacin una imagen que muestra un campo genrico del tipo Type
Length Value o TLV.

p. 49
En el mismo se ve que todos tienen un formato fijo de cabecera del campo TLV que empieza
con dos bytes, el primero indica el tipo y el segundo indica la longitud del campo siguiente.
Cul es la ventaja de este tipo de formato?

Supongamos que tenemos una red en la cual implementamos un nuevo protocolo que
requiere una nueva funcionalidad.
Sin campos del tipo TLV, nos veramos obligados a generar un nuevo tipo de paquete que
tiene que ser interpretado por todos los equipos de la red y a upgradear toda la red para
poder poner en uso la nueva funcionalidad.
En algunos casos puede que quiera implementar alguna funcionalidad que requiera
simplemente ser procesada por los equipos de borde.
En el caso genrico de no usar campos del tipo TLV me vera igual obligado a upgradear
todos los equipos de la red para que entienda el nuevo formato de paquetes, pero en el
caso de utilizar formatos TLV, simplemente podra upgradear los equipos del borde.
Cmo funciona esto?

Generara un nuevo tipo de paquete con un cdigo terminado, 99 por ejemplo.
El mismo tendra la longitud adecuada y al final, en el campo de opciones, pongo todas las
opciones que tienen que ser utilizadas por los equipos de borde.
En los equipos de borde efectu un upgrade de software que le permita interpretar que es
el paquete tipo 99.
De esa manera los equipos de borde podran procesar estos paquetes de la forma correcta.
En el resto de los equipos de la red los mismos no sabran que hacer con un paquete tipo
99 pero el truco esta que a continuacin del tipo hay un campo de longitud.
Con el campo de longitud los equipos que estn en el centro de la red y que no saben ni
deben procesar este tipo de paquete pueden calcular cual es la longitud total de las

p. 50
opciones, saltear esa parte del paquete y seguir procesando otro campo TLV que si sepan
interpretar.
Es una manera muy inteligente de conseguir flexibilidad en el desarrollo de nuevos tipos de
paquetes y agregar funcionalidades sin verme obligado a upgradear todos los equipos de
la red.
Por supuesto que adems del ejemplo visto uno podra imaginarse casos en los cuales es
mandatorio que todos los equipos de la red interpreten correctamente la funcionalidad
nueva adicionada para que esta pueda entrar en efecto.
Eso sera el caso por ejemplo de querer hacer algn esquema orientado a la conexin o de
reserva de ancho de banda, en el cul si uno de los equipos intermedios no es capaz de
interpretar el contenido del paquete, esto no me es til.
Para entender cmo implementar estos casos con mayor claridad, presentamos a
continuacin la siguiente grafica que me muestra la informacin extra que es transportada
en forma fija en el campo Type de los paquetes.

p. 51
En ella se ve que con los dos primeros bites se le informa al equipo como debe actuar en
el caso que no interprete el contenido del paquete.
Los ejemplos ms destacables son los dos primeros en los cuales se ve en el caso que el
valor sea 00, sera como el ejemplo que presentamos antes si el equipo no interpreta la
opcin y adems ve que los dos primeros bites son 0 puede simplemente ignorar ese campo
TLV y seguir procesando el resto de los campos del paquete.
En el caso de que los dos primeros bites sean 01, sera el caso en el cual estoy obligado a
que todos los equipos intermedios interpreten el paquete para poder aplicar la nueva
funcionalidad.

p. 52
Si esto no ocurre como indica la grfica simplemente procedo a descartar todo el paquete
sin interpretar ninguno ms de los campos.
Las dos siguiente opciones son en caso de descartarse los paquetes para datagramas
Unicast y Multicast, si se enva o no paquetes de ICMP hacia el origen informando de la
situacin para permitir alguna remediacin o por lo menos que se est al tanto de lo que ha
ocurrido y cul es el equipo intermedio que no ha aceptado la opcin que se le est
solicitando.

p. 53
Bibliografa
Silvia Hagen. IPv6 Essentials. Segunda edicin. Sebastopol, USA: Editorial O'Reilly;
9 de Febrero del 2009.
Rick Graziani. IPv6 Fundamentals: A Straightforward Approach to Understanding

IPv6. Primera edicin. Indianapolis, USA: Editorial Cisco Press; Octubre del 2012 .
Peter Loshin. IPv6: Theory, Protocol, and Practice. Segunda edicin. San Francisco,
USA: Editorial Morgan Kaufmann; 26 de Diciembre del 2003.
Ciprian P. Popoviciu. Eric Levy-Abegnoli. Patrick Grossetete. Deploying IPv6

Networks. Primera edicin. Indianapolis, USA : Editorial Cisco Press; 25 de Mayo
del 2008.


Introducción A IPv6 - Unidad 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Introducción A IPv6 - Unidad 1

Încărcat de

Drepturi de autor:

Formate disponibile

CURSO:

Introduccin a IPv6, el futuro de

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Las principales limitaciones del protocolo IP en su versin 4.

La propuestas de soluciones planteadas por IP v6.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

1. Problemas de la implementacin actual de IP.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Consignas para el aprendizaje colaborativo

Los foros proactivos asociados a cada una de las unidades.

Los contextos de desempeo de los participantes.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Las actividades son opcionales y pueden realizarse en forma

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

El protocolo de red utilizado mayoritariamente en la actualidad en internet como todos

Agotamiento de las direcciones de IPv4

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Estbamos acostumbrados a que las direcciones IP eran utilizadas para conectar

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

En la actualidad, el IANA ya se ha quedado sin direcciones IP para asignar. Todas las

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

cuales se pretende prever, en forma estadstica, en qu momento se van a agotar las

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Como veremos en esta unidad, la manera de solucionar la falta de direcciones, es

Como ya hemos mencionado en el punto anterior, el principal problema de IPv4 es la falta

Crecimiento de las tablas de ruteo.

Requerimiento de calidad de servicio o reserva de ancho de banda.

Mejor en seguridad e implementacin de IP Sec.

Posibilidad de aplicar o utilizar el protocolo IP, no desde estaciones fijas en un punto

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Incremento en el trfico de Broadcast en los segmentos de LAN.

Problema de asignacin dinmica de direcciones IP.

Cuando nos referimos a grandes volmenes de conexiones, como en este caso

Teniendo esto en cuenta y la posibilidad de implementacin de redes cada vez

Esto son algunos de los problemas que presenta el direccionamiento IP actual.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Teniendo estos factores en cuenta, se han efectuado diversas modificaciones al modo de

Lo importante de esto, es que este cambio en el modo de trabajo, tiene determinadas

Eliminacin del uso de direcciones privadas.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Tamao de campo de direcciones en IPv6

En IPv4, el campo de direcciones tiene 32 bits.

Si aumentramos el campo de direcciones de IPv4 nicamente en un bit, estaramos

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Representacin de las direcciones de IPv6

En el caso de IPv6, en el cual la cantidad de bits es mucha mayor, para su representacin,

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Agregacin de direcciones y tamao de la tabla de ruteo de internet.

Como se muestra en el siguiente ejemplo de direccionamiento jerrquico con IPv6, a un

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

En este caso al usuario A el rango 2001:0dv8:001::/48.

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Si bien este esquema jerrquico ya exista en IPv4, se empezaban a presentar algunos

En el caso de IPv4, la manera de implementar MULTIHOMING, era que un usuario si

Centro de Formacin, Investigacin y Desarrollo de Soluciones de e-Learning.

Mientras que en el caso de IPv4, solamos asignar una direccin IP a un dispositivo, en el