Introducción a IPv6 - Unidad 1

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 // [email protected]

www.sceu.frba.utn.edu.ar/e-learning

CURSO:

Introduccin a IPv6, el futuro de Internet.

p. 2

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 // [email protected]


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

Documents

Transcript of Introducción a IPv6 - Unidad 1