IPv6 surgió desde el IETF (Internet Engineering Task Force) indicando a través de un RFC en 1993 las NECESIDADES que debía cubrir y las ESPECIFICACIONES que debía cumplir.

Las RAZONES PRINCIPALES DE LA APARICION de IPv6 (o IPng -IP Next Generation) son,

• el más que previsible AGOTAMIENTO a corto plazo de las direcciones IPv4 dada la expansión y crecimiento de Internet,
• los problemas de SEGURIDAD, dado que IPv4 no tiene mecanismos a nivel de red para evitar ataques,
• los problemas de RENDIMIENTO que presenta. En cuanto a esto último, la capacidad de los routers es limitada en cuanto al número de entradas que pueden manejar en sus tablas, por lo que una vez superado ese valor tienden a deshechar rutas, perdiéndose parte de la conectividad.

MEJORAS con respecto a IPv4:

• DIRECCIONAMIENTO, se trata de un nuevo esquema con 128 bits con notación hexadecimal en vez de los 32 bits con representacion decimal que se usan ahora. Los 128 bits que se han utilizado, aumentan de manera muy significativa el número de máquinas que pueden conectarse con respecto al direccionamiento IPv4 y quizás es la razón de mayor peso por la cual se comenzó el desarrollo.

• CALIDAD DE SERVICIO, consistente en dar prioridad a paquetes pertenecientes a un mismo flujo para poder mantener un tráfico continuo y no depender de la congestión de las redes. Esto se aplica sobre todo en aplicaciones en tiempo real y además ofrece la posibilidad de facturar dado que se conocen los distintos tráficos que pasan por la red.

• SEGURIDAD. Se ha provisto a IPv6 de mecanismos para intentar mejorar la seguridad de los datos, de dos maneras principalmente:

  • el primero proporcionando integridad y autentificación de los datos, pero no confidencialidad (sin encriptación),
  • el segundo proporcionando integridad y confidencialidad.

• AUTOCONFIGURACION tanto de routers como de hosts, de manera que no será necesario que un administrador se encarge de llevar un estricto control de la asignacion de direcciones como se viene haciendo hasta ahora y facilita la gestión de la red en general.

TRANSICION de IPv4 a IPv6.

Hasta ahora parecen todo ventajas pero el problema que se va a presentar es la MIGRACION de todo lo que hay configurado ya: servidores de DNS, protocolos de encaminamiento, etc.

Lo que más problemático puede resultar es la migración de la aplicaciones porque es necesario adaptarlas para que puedan continuar funcionando (por ejemplo el cambio de la dirección de interfaz de usuario). La ventaja para poder llevar a cabo esta migración es el procedimiento de COMPATIBILIDAD de direcciones IPv6 con direcciones IPv4 con un formato mixto que facilita el entendimiento entre máquinas con distintos protocolos (formato que veremos después).

Para la migración, lo más adecuado es el paso de uno a otro estado de un modo gradual. La arquitectura recomendable debera estar basada en nodos que soporten a la vez ambos protocolos y que las zonas de IPv6 que se conecten a través de túneles sobre la actual infraestructura de IPv4.

En algunos casos se piensa en usar alguna otra herramienta ya existente para evitar realizar la migración como NAT, o seguir confiando de momento en el ahorro de direcciones IPv4 a través del CIDR.

• NAT (Network Address Translation).

  Esta es una de las soluciones que se esta utilizando para poder ahorrar direcciones en redes no demasiado grandes. Se trata de que el servidor o router que lo tiene implementado se encuentra en el borde entre una red privada y el resto de Internet, y tiene la mision de asignar direcciones públicas de un pool solamente a aquellos usuarios que mantienen una conexión externa a esa red. Al desconectarse, la dirección se libera para que pueda volver a ser utilizada.

• CIDR (Classless Inter-Domain Routing).

  Es el procedimiento por el cual se ha conseguido reducir un poco más el tamaño de las tablas de routing a base de unir redes cuyos prefijos pueden sumarse en uno único que las representase a todas.

ESQUEMA DE DIRECCIONAMIENTO.

En IPv6 existen tres tipos de direcciones principalmente:

• UNICAST (identifica a una sola máquina o interfaz).
• MULTICAST (identifica a un grupo de máquinas o grupo de interfaces. El paquete se envía a todos los miembros de un grupo).
• ANYCAST (también identifica a un grupo de máquinas, pero se diferencia en el proceso de transmisión; en vez de enviar el paquete a todos los miembros del grupo, se envía solo al miembro del grupo mas cercano).

Vamos a comentar solo el formato de las direcciones unicast.

La dirección IPv6 esta formada por 128 bits y se representa con 8 grupos de 16 bits representados con notación hexadecimal separados por ":", del tipo

AAAA:BBBB:CCCC:DDDD:EEEE:FFFF:GGGG:HHHH

Si cualquiera de los grupos esta formado únicamente por ceros, pueden sustituirse por un único cero

AAAA:BBBB:CCCC:0000:EEEE:FFFF:GGGG:HHHH

AAAA:BBBB:CCCC:0:EEEE:FFFF:GGGG:HHHH

Si varios grupos consecutivos estan formados por ceros, pueden sustituirse por la notación "::" pero solo una única vez en la dirección

AAAA:0000:0000:0000:0000:0000:GGGG:HHHH

AAAA::GGGG:HHHH

AAAA:GGGG:HHHH:0000:0000:0000:0000:0000

AAAA:GGGG:HHHH::

Para facilitar la migración se ha considerado un formato que incluye directamente las direcciones IPv4 en un formato IPv6

0:0:0:0:0:0:130.206.1.1

::130.206.1.1

Las máscaras de red se utilizan del mismo modo que ahora pero lógicamente sus valores han cambiado.

La dirección IPv6 se divide en los siguientes campos:

<------------Public Topology------------->

FP Format Prefix

Este campo tiene como valor fijo (001).

TLA ID Top-Level Aggregation Identifier

Este campo de 13 bits permite direccionar hasta 8.192 TLA ID. La longitud de este campo se ha escogido en base a que la Tabla de routing de los routers más importantes que contiene todas las entradas de Internet este dentro de unos límites adecuados de tamaño. También se intenta evitar que las redes se anuncien varias veces por distintos caminos como pasa con IPv4. La complejidad de Internet va creciendo y se pretende que la Tabla de Routing basada en IPv6 soporte esta complejidad.

Si en el futuro se necesitase identificar mas TLA's se podría hacer dando más valores al campo FP o tomando más bits del campo RES.

RES Reserved.

Este campo esta reservado en principio para un uso futuro, que sería, tanto poder ampliar la capacidad de identificación de los TLA's como hemos indicado, como aumentar las posibilidades de direccionamiento de los NLA's.

NLA ID Next-Level Aggregation Identifier

Este campo de 24 bits permite direccionar unos 16 millones de NLA's, equivalente más o menos al actual direccionamiento aprovechable de IPv4. Aun asi, si fuera necesario direccionar mas se utilizarían bits del campo RES. El formato de la dirección facilita el que puedan conectarse las mismas redes a distintos proveedores o el cambio de uno a otro con solo modificar el valor de los campos citados. Este sería el campo que distingue la asignacion a los Centros dependiendo de su importancia.

SLA ID Site-Level Aggregation Identifier

Este campo de 16 bits permite direccionar 65536 redes por organización, y esta pensado para considerar las redes de los Centros de mayor tamaño. No obstante, si se necesitase direccionar mas redes, se podría solicitar un nuevo NLA.

INTERFACE ID Interface Identifier (RFC 2373)

Este campo de 64 bits esta pensado par poder soportar el formato de direcciones EUI-64 de los interfaces, basado en las direcciones MAC.

Actualmente el campo RES, reservado para posteriores expansiones según necesidades, se esta utilizando ya para direccionamiento experimental de pTLA's considerandose 32 bits.

ANTECEDENTES.

Hasta el momento en que quedó paralizada la actividad del grupo de trabajo de IPv6 se había comenzado a experimentar en algunas áreas. SURFNET asignó a RedIRIS el prefijo del antiguo esquema de direccionamiento 5F02:FE00::/32 y se tomó como red la 130.206.1.0/24, con lo que el direccionamiento usado fue

5F02:FE00:82CE:0100::/64

En cuanto a infraestructura, se usó y se sigue utilizando un router CISCO 2501 con una versión de IOS experimental desde el cual se establecieron túneles sobre IPv4

• con SURFNET, que proporcionaba el acceso de RedIRIS al 6bone con RIPng como protocolo de encaminamiento,
• con la Universidad de Murcia, estableciendose routing estático del direccionamiento asignado, y
• con una de las máquinas de RedIRIS con software Linux, con la que se estuvo probando también RIPng.

En cuanto a DNS, se creó el dominio "ipv6.rediris.es" y "ipv6.um.es" tanto la zona directa (con registros IN AAAA) como la inversa (ipv6.int) teniendo instalado el servidor BIND 4.9.5.

SITUACION ACTUAL.

Una vez retomado SURFNET nos había asignado un nuevo rango de direcciones dado que en este tiempo cambió el esquema anterior de direccionamiento, con lo que los túneles estuvieron caidos unos meses; ahora se dispone de

3FFE:0608:0::/48

que se trata de un rango de direcciones mucho menor que el que se tenía y con el que temporalmente se ha restablecido el tunel con ellos y el tunel con la Universidad de Murcia. En el primer caso se ha pasado de RIPng a BGP+, que es el protocolo de encaminamiento que se esta utilizando en el 6bone (backbone de IPv6) para unir las islas de IPv6.

OBJETIVOS.

Solicitar direccionamiento como pTLA.

Dado que prácticamente casi todas las redes académicas europeas han solicitado y poseen direccionamiento suficiente para poder experimentar y reasignar direcciones a sus Centros, vamos a pedir inmediatamente este direccionamiento para lo que hay que justificar el uso que se ha estado haciendo y se va a hacer del mismo.

Asignación de direcciones IPv6 a Centros de RedIRIS.

Esperamos que el plazo de concesión por parte del 6bone sea el mínimo posible para poder asignar cuanto antes direccionamiento a los Centros y poder continuar con la experimentación con alguna garantía de continuidad durante un periodo estable.

Concentración de conexiones IPv6 a nivel internacional.

Tras el direccionamiento el siguiente paso es negociar el establecimiento de túneles con el resto de pTLA's, del mismo modo que el resto. En primer lugar, mantener el túnel con SURFNET pero ya no con direccionamiento asignado por ellos sino con el propio.

Ofrecer información de utilidad.

Sobre todo software actualizado aplicable a los distintos tipos de hosts y a routers e información de interés general (URL's sobre todo).

Experimentación.

Coordinar pruebas con distintos protocolos, routing, DNS y desarrollar la utilización de distintas aplicaciones (web, ftp, ... las que funcionan actualmente).

Experimentacion en la red del TEN-155.

Existe un grupo de trabajo propio dentro del TEN-155 cuyos objetivos son:

• Implantar
  • IPv6 nativo dentro de la infraestructura de esta red.
  • como protocolo de routing BGP+

• Conexión de todas las redes IPv6 académicas al backbone propio de TEN-155.

• Registro del TEN-155 como pTLA.

• Investigar
  • las posibilidades de gestion y diagnóstico y realizar estadísticas de tráfico IPv6,
  • la comunicación entre máquinas IPv4 - IPv6,
  • procedimientos de seguridad,
  • IPv6 sobre ATM.

En definitiva, implementar conectividad a través de IPv6 como un servicio operativo y obtener una red IPv6 Pan-Europea a la que poder aplicar y controlar protocolos de routing y aplicaciones en la medida en que es posible actualmente en el 6bone. Esta red coexistiría con la actual de multicast IPv4 y se contempla la posibilidad de crear una red ATM propia separada si fuese necesario. Como requisito imprescindible, se indica que el ancho de banda mínimo para esta infraestructura seria de lineas de 1 - 2 Mbps.

Se ha mostrado bastante interés por parte de algunos Centros en reactivar la experimentación y se solicita en cuanto sea posible la asignación de direccionamiento.