Nueva Generación del Protocolo IP:IPv6

Ignacio Martínez


Introducción

La red Internet, basada en un diseño de primeros de los años 80, ha experimentado un crecimiento sin parangón en la historia de las telecomunicaciones tanto en número de usuarios conectados como en aplicaciones y servicios disponibles.

Aunque algunos de los nuevos servicios que encontramos en la Internet se podrían encuadrar dentro del marco aún difuso de las llamadas autopistas de la información por su naturaleza multimedia, la disponibilidad creciente de infraestructura de transmisión a alta velocidad y por su ámbito de difusión global [1], es bien cierto que han aparecido deficiencias en los aspectos administrativos y de seguridad así como carencias de cara a la prestación de los servicios avanzados que apuntan en el horizonte.

Para remediar estos males, los cuerpos técnicos de la Internet impulsaron un debate bajo el lema de IP Next Generation (IPng) que ha culminado con la especificación de un nuevo protocolo IP, sucesor del actual IPv4, y conocido formalmente como la versión 6 del Protocolo Internet o IPv6.

En este artículo se examinan algunos de los problemas inherentes a IPv4 así como las nuevas facetas que presenta IPv6, muchas de las cuales se encuentran en fase de discusión en la actualidad.

El modelo Internet. Direcciones y encaminamiento

La Internet representa el ejemplo paradigmático de las redes de datagramas o no orientadas a la conexión. En ella cada fragmento (paquete) de información es transmitido por la red de manera no fiable y sin mantener vínculo alguno, ni siquiera de orden, con el resto de los paquetes de la unidad de información intercambiada. Para que esto pueda ser así, cada paquete contiene en su interior (más explícitamente en su comienzo o cabecera) la identificación de su originador junto con la de su destinatario. Esta faceta del protocolo IP presenta la ventaja de facilitar la interconexión de subredes de diferente tecnología y es sin duda una de las claves del éxito de la Internet como red de redes en contraposición con otras tecnologías orientadas a la conexión como X.25 o ATM, basadas en el concepto de circuitos virtuales o canales fiables que asigna la red para la comunicación entre extremos de manera ordenada e íntegra. Véase [2] para una discusión más detallada sobre este tema.

El protocolo IP gobierna la estructura y la transmisión de los datagramas a través de los nodos de la red, sean éstos sistemas finales (ordenadores, con un punto de conexión a red) o intermedios (routers, con más de un punto de conexión). Cuestiones tales como la fragmentación de la información en paquetes de tamaño adecuado para su transmisión por un medio determinado, el formato de las direcciones de red o las opciones de encaminamiento de los datagramas están definidas en el protocolo. El recurso quizá más valioso de entre los que posee la red Internet es su espacio de direcciones o el conjunto de todos los identificadores que pueden ser asignados a los puntos de conexión a red y que, como veremos, está estrechamente ligado con los conceptos administrativos de direccionamiento y encaminamiento.

Para identificar cada uno de los interfaces de los sistemas finales y equipos encaminadores de la Internet se emplean direcciones IP de 32 bits, que usualmente se suelen representar textualmente en grupos de 8 bits en notación decimal (por ejemplo, 130.206.16.75). En IPv4 se definen tres tipos de direcciones: la más común o unicast (asociada a una única interfaz), multicast (asociada a un grupo de interfaces) y broadcast (asociada a todos los interfaces). Para asignar direcciones unicast a equipos se dispone de más de 3.750 millones de direcciones (0.0.0.0-223.255.255.255) que se agrupan de forma topológica en forma de parte de red (los bits más significativos o más a la izquierda), que es común a todos los miembros de la unidad topológica pudiendo ser ésta una red local, una organización o un proveedor y parte local (los bits menos significativos) que es diferente para cada ente individual.

        <----- r bits -----><----- 32-r bits ------->
+-------------------------------------------+
| parte de red | parte local |
+-------------------------------------------+
El encaminamiento en la Internet se lleva a cabo bajo la suposición que todos los equipos que tienen identificadores con una misma parte de red son miembros de una misma unidad topológica sujeta a una estructura administrativa única, lo que permite inferir que el encaminamiento interno es homogéneo y completo. El resultado de todo esto es que todos los equipos de la red son vistos desde el exterior como un único elemento de cara al encaminamiento, lo cual reduce en gran manera la cantidad de información que deben mantener, almacenar y procesar los equipos encaminadores o routers. En adelante, a la parte de red de una dirección la denominaremos prefijo, que nos servirá para representar diferentes estructuras topológicas mediante la sintaxis

direccion-IP-de-32-bits/tamaño-del-prefijo

Esto nos indicará qué parte de la dirección es significativa en términos de encaminamiento. Por ejemplo, 130.206.16.75/32 representa una única dirección de red mientras que 130.206.16.0/24 representa el conjunto de direcciones 130.206.16.0-130.206.16.255. Es importante resaltar la diferencia entre los procedimientos de encaminamiento internos a un dominio o intra-dominio, de los que ése dominio tiene respecto a los demás con los que tiene conexión directa o indirecta (inter-dominio). Existe una jerarquía de encaminamiento que se refleja en la mayor o menor generalidad de los prefijos empleados para anunciar el dominio. Por ejemplo, Fundesco anuncia el prefijo 130.206.16.0/24 dentro de RedIRIS, su proveedor, quien redistribuye esta información dentro de su dominio. Sin embargo, RedIRIS anuncia al exterior -a otros dominios con los que tiene conexión- un prefijo más general 103.206.0.0/16 que identifica la ruta a Fundesco de cara a todos estos dominios.

El problema de la asignación de direcciones

A la hora de diseñar un método de asignación de direcciones en los albores de la Internet, cuando estaba conectada apenas una docena de centros, se pensó en un esquema basado en el tamaño de las organizaciones y de ahí nació el modelo de clases en la que sólo se daba cabida a tres tipos de prefijo de longitud predeterminada según fuera una gran organización (clase A, prefijo 8 bits), de tamaño mediano (clase B, prefijo 16 bits) o pequeño (clase C, prefijo 24 bits). Tenemos pues 128 prefijos correspondientes a clases A (0.0.0.0/8-127.0.0.0/8), 16384 de clases B (128.0.0.0/16-191.255.0.0/16) y algo más de 2 millones de clases C (192.0.0.0/24-223.255.255.0/24).

                                         prefijo    hosts

+--------------------------+
clase A |0 | | /8 > 16M
+--------------------------+

+--------------------------+
clase B |10 | | /16 65536
+--------------------------+

+--------------------------+
clase C |110 | | /24 256
+--------------------------+

La asignación de direcciones comenzó a hacerse de manera centralizada por un único centro de registro (SRI-NIC) satisfaciendo casi todas las solicitudes sin necesidad de mayor trámite. Este modelo de asignación de direcciones, cuando la Internet comenzó a crecer de forma espectacular, trajo algunas de estas consecuencias:

  • Mal aprovechamiento del espacio de direcciones. Cada centro tendía a pedir una clase superior a la requerida, normalmente una clase B en vez de una o varias clases C, por puro optimismo en el crecimiento propio o por simple vanidad.

  • Peligro de agotamiento de las direcciones de clase B. Las más solicitadas debido a la escasez de posibilidades de elección. La alerta sonó cuando se había agotado el 30% de esta clase y la demanda crecía exponencialmente.

  • Síntomas de saturación en los routers de los backbones. Al imponerse restricciones severas en la asignación de clases B, las peticiones de múltiples clases C se hicieron masivas, lo que hizo que aumentara de forma explosiva el número de prefijos que los routers habían de mantener en sus tablas, llegándose a alcanzar los límites físicos impuestos por la capacidad de memoria y de proceso.

Por tanto nos encontramos ante un doble problema: agotamiento de direcciones y colapso de routers debido a la explosión de rutas. En una situación en la que la población conectada a la red se duplicaba (en términos de equipos y redes conectadas) en periodos que oscilaban en torno a los 6 meses había que tomar medidas urgentes, y he aquí algunas de las que se tomaron:

  • Imposición de políticas restrictivas de asignación de direcciones por parte de los centros de registros (ya descentralizados del primitivo NIC), como ya se ha apuntado antes.

  • Modificación de los protocolos exteriores de encaminamiento para soportar prefijos de red variables. Este método se conoce como CIDR (Classless Inter-Domain Routing) [3] y consiste en la agregación de prefijos que son adyacentes para dar lugar a prefijos menores (y por tanto más generales), con lo que se reducía el número de entradas en las tablas de los routers. Por ejemplo, el RIPE-NCC ha asignado a RedIRIS el bloque 193.144.0.0/15 (131.072 direcciones) para delegar entre sus miembros, anunciándose todo el bloque como un único prefijo.

  • Iniciación de la asignación, según el modelo CIDR o sin-clase, de partes del espacio de direcciones que estaban reservadas, como 64.0.0.0/8 - 126.0.0.0/8 que suponen aproximadamente 1/4 del total del espacio asignable. Estas direcciones se asignarán en bloques de prefijo variable.

Para entender bien el problema hay que tener en cuenta que el periodo de tiempo en el que los fabricantes duplican la capacidad de proceso de sus equipos y la de sus memorias es de aproximadamente dos años. La capacidad de los routers que deben mantener en sus tablas una información completa o full-routing sobre la topología de la Internet (equipos conectados a los backbones principales o de dominios conectados a múltiples proveedores -multi-homed-) se habría hoy día superado, con el colapso consiguiente de la Internet, si CIDR no hubiese sido puesto en funcionamiento a primeros de 1994. Téngase en cuenta que al escribir esto hay más de 60.000 redes conectadas mientras que los equipos que soportan full-routing manejan del orden de los 30.000 prefijos, estando el límite de tecnología actual en torno a los 40.000 prefijos. Como dato ejemplificador, RedIRIS cuenta en su dominio interno con más de 650 redes pero sólo anuncia al exterior 32 prefijos, en su mayoría clases B históricas, con lo que se consigue una agregación óptima.

En cualquier caso, hay que entender que tanto CIDR como las políticas restrictivas de asignación de direcciones son sólo medidas temporales, dirigidas a afrontar problemas concretos y que no resuelven (en algunos casos hasta agravan) los problemas crónicos detectados en la Internet en gran parte debidos a su tremendo éxito. Así, se han llegado a plantear iniciativas como la devolución de direcciones, la obligatoriedad de cambiar de direcciones al cambiar de proveedor (en un mundo en el que los operadores telefónicos están considerando introducir mecanismos para que esto no ocurra con el número de teléfono cuando se cambie de compaqma), la asignación dinámica de direcciones, el uso de traductores de direcciones (NAT) que transformen un espacio privado de direcciones en otro perteneciente al proveedor, o incluso el cobrar una cantidad elevada por cada prefijo (no perteneciente al espacio del proveedor) que un cliente desee que su proveedor anuncie.

Otros puntos débiles

De forma recurrente vemos como se achaca a la Internet el ser un medio de comunicación inseguro. Este es un tema con muchas aristas y que debe ser examinado en cada una de sus partes. Dado el carácter puramente académico de la Internet en el comienzo de su andadura, los asuntos relativos a la seguridad fueron, como desgraciadamente suele ocurrir en la práctica, relegados a posterior estudio hasta que los primeros ataques globales hacen sonar la alarma y empieza a producirse un notable esfuerzo en incorporar mecanismos de seguridad a las aplicaciones existentes.

Sin embargo, el problema de seguridad en el nivel de red sigue sin ser tenido en cuenta y comienza a producirse una serie de ataques cada vez más sofisticados y basados en la suplantación de la identidad de máquinas conectadas a la red, dando la posibilidad de violar un acceso prohibido o dando la posibilidad de escudriñar (o desviar) la información a intrusos. Como respuesta surgen mecanismos de barrera como los cortafuegos, pero los protocolos siguen sin incorporar medidas específicas de seguridad.

Pero esto es sólo una parte del problema. La seguridad integral comprende servicios tanto de confidencialidad como de autentificación, integridad y no rechazo para los que se requieren técnicas criptográfícas que están sujetas a diferentes normativas de exportación y uso en determinados países, lo que hace complicado su uso generalizado en un medio que se tiene por libre (en cuanto a la naturaleza de la información intercambiada y su formato) y homogéneo (en cuanto al tipo de protocolos/aplicaciones empleados). Se corre el peligro de fracturar la Internet en zonas donde se puedan intercambiar información de forma segura y otras en que no, bien por considerarse tecnología de uso militar, bien por el derecho que se guardan algunos gobiernos a poder intervenir -e interpretar- las comunicaciones de sus ciudadanos.

En otro orden de cosas, estamos asistiendo al nacimiento de servicios de transmisión de información en tiempo real dentro de la Internet. Ejemplos de ello son las aplicaciones para comunicaciones de voz a través de la red y el Mbone, red virtual superpuesta a la Internet, basada en el concepto de IP Multicast [4]. Un defecto claro de IPv4 es la falta de caracterización de los distintos flujos de información que viajan por la red, dando la misma consideración a un tráfico que podría considerarse como de relleno como las NetNews, sujeto a la redundancia de un mecanismo corrector de transporte, que a una transmisión de voz en tiempo real en la que la pérdida de un número significativo de paquetes puede alterar o incluso imposibilitar la interpretación de la información. El advenimiento de este tipo de servicios en la era de las autopistas de la información presenta una clara limitación al uso de la Internet tal y como la concebimos actualmente en contraposición a otro tipo de tecnologías orientadas a la conexión como ATM que parecen más adecuadas para los servicios en tiempo real.

Ipv6

Los problemas mencionados anteriormente han sido tenidos en cuenta por la comunidad Internet desde que se empezaron a predecir sus consecuencias (en mayor o menor grado de pesimismo catastrofista) lo que motivó que sus técnicos elaboraran una serie de propuestas conducentes a la creación de un nuevo protocolo para la red Internet, conocido como IP Next Generation (IPng). A finales de 1994 El IESG (Internet Engineering Steering Group), después de examinar las propuestas finales y en base a unos criterios que habían sido elaborados con anterioridad, emitió una recomendación para IPng que posteriormente se publicaría como RFC 1752 [5] con la categoría de Proposed Standard. Dicha recomendación está siendo desarrollada actualmente por los grupos de trabajo del IETF (Internet Engineering Task Force).

En esta recomendación se asigna para IPng el número de versión 6 y pasa a denominarse formalmente como IPv6 [6]. La decisión del IETF tiene como aspecto más importante la elección de SIPP (Simple IP Protocol Plus) [7] como base para la elaboración de IPv6 con aspectos de otros contendientes, en particular de TUBA (TCP & UDP with Bigger Addresses) [8] del que se toma el modelo de transición, uno de los aspectos más importantes recogidos entre los criterios de selección. Mientras que SIPP representa un paso evolutivo en el protocolo IP, tomando de la versión 4 los elementos que se emplean y desechando los que no se usan, simplificando al mismo tiempo el protocolo para optimizar la transmisión; TUBA proponía el empleo del protocolo de ISO para redes no orientadas a la conexión (CLNP) y el uso de direcciones NSAP normalizadas.

Volviendo a IPv6, nos encontramos como primera característica (como era fácil suponer) unas direcciones ampliadas (128 bits) junto con unas facilidades de encaminamiento mejoradas. El espacio de direcciones no sólo aumenta sino que su estructura se hace más adecuada para un encaminamiento óptimo mediante una jerarquía de prefijos que implican distintos estamentos de asignación. He aquí algunos ejemplos de estas nuevas direcciones en su representación textual (nótese la presentación hexadecimal y la eliminación de ceros no significativos):

unicast ( direcciones equivalentes)
4800:F400:0045:EA00:0000:0000:0000:04E7
4800:F400:45:EA00:0:0:0:4E7
4800:F400:45:EA00::4E7
multicast
FF02:0:0:0:0:0:0:2E5 ó FF02::2E5
compatible IPv4
0:0:0:0:0:0:130.206.16.75
::130.206.16.75

Otras características reseñables del nuevo esquema de direccionamiento son:

  • Da cabida a distintos modelos de asignación, como el basado en el proveedor (direcciones unicast de equipos que se conectan a través de un proveedor), el geográfico (para puntos neutros de interconexión, por ejemplo) o local, sin conexión a la red global. Hay prefijos preasignados a centros de registro como Internic, RIPE-NCC (Europa) y APNIC (Asia-Pacífico) que a su vez registrarán prefijos para los proveedores de su ámbito. También se pueden representar direcciones IPX y NSAP con las nuevas direcciones IPv6 de 128 bits.

  • Un nuevo tipo de dirección: anycast, que identifica un grupo de direcciones y que al ser empleado, se referirá al nodo más próximo al originador.

  • Las direcciones de broadcast no existen en IPv6. Son casos particulares de direcciones multicast. Estas últimas incorporan un campo de ámbito, en sustitución del parámetro TTL usado en la actualidad para determinar el rango de actuación de una sesión multicast.

  • Autoconfiguración. Uno de los aspectos fundamentales de IPv6 es la incorporación de mecanismos que permitan la conexión automática (modelo plug and play) de equipos a la red. Pueden construirse direcciones globales usando como parte local la dirección MAC de un equipo y obteniendo el prefijo a través de un servidor de la red.

Las cabeceras de los paquetes han sido simplificadas en IPv6 eliminando los campos no utilizados y añadiendo el concepto de cabeceras de extensión. Estas permiten seleccionar facilidades especiales de encaminamiento, fragmentación y seguridad así como el manejo de opciones, que han sido eliminadas de la cabecera IPv6. Cada cabecera incluye un campo que define el tipo de cabecera que le sigue a continuación, hasta llegar a la de transporte, con lo que se agiliza el proceso de los paquetes.

                    +----------------+-------------+-----------+
| cabecera IPv4 | cabecera | datos |
| + opciones | transporte | |
+----------------+-------------+-----------+

datagrama IP versión 4

+----------+ ... +-----------+ ... +---------+-------+
| cabecera | | cabecera | | cab. | datos |
| IPv6 | | extension | | transp. | |
+----------+ ... +-----------+ ... +-----------------+

datagrama IP versión 6

En IPv6 la fragmentación/ensamblado de paquetes es una tarea de los sistemas finales con lo que de nuevo se facilita la vida a los routers para que se entreguen a su misión primordial, encaminar paquetes. La unidad máxima de transmisión (MTU) de un enlace es ahora como mínimo de 576 octetos (68 en IPv4).

El encaminamiento propuesto permitirá la selección de proveedor por parte del originador así como la movilidad mediante el empleo de cabeceras de extensión de encaminamiento en la que se especifique un camino elegido (que será recorrido a la inversa al regreso) mediante direcciones unicast o anycast.

La transmisión de información en tiempo real se podrá realizar mediante el empleo de dos campos en la cabecera IPv6. La prioridad, que distingue los diferentes tipos de datagramas según la clase de servicio y la etiqueta de flujo, que permite diferenciar y asignar distintos estados a distintos flujos originados por la misma fuente.

Por fin, la seguridad en el nivel de red será una realidad mediante el empleo de cabeceras de extensión de autentificación, que proporciona servicios de verificación de identidad e integridad y de encapsulado de seguridad que proporciona servicios de confidencialidad. En el primer caso no se plantean problemas de exportación de tecnología por tratarse de un procedimiento de verificación (se cifra una función del contenido, pero no el contenido en sí) mientras que en el segundo caso todos los malos presagios mencionados en el capítulo anterior salen a relucir. Más sorprendente es aún el hecho de que, de acuerdo con las especificaciones, todo producto que pretenda ser conforme a IPv6 ha de incluir necesariamente ambos mecanismos de seguridad a pesar de los impedimentos expuestos.

El tránsito hacia Ipv6

Uno de los aspectos más importante de todos los contemplados durante el proceso IPng es el de la migración o paso de una red basada en la arquitectura IPv4 a IPv6. Un criterio que guió la selección de candidatos para IPng fue el de rechazar cualquier propuesta, por brillante que fuera, que no incluyera un plan viable de transición de la base actual instalada de equipos IPv4 a IPv6. La transición ha de hacerse de forma gradual, sin afectar a los servicios que se prestan en la actualidad.

En IPv6 el método propuesto se basa primordialmente en la coexistencia de ambos protocolos. Los nuevos sistemas que vayan incorporando IPv6 (ordenadores y routers) deberán mantener asimismo la plena capacidad de procesar paquetes IPv4. Para conectar las islas IPv6 que irán emergiendo mediante la infraestructura Internet actual se emplearán técnicas de encapsulado (túneles IPv6) en los datagramas IPv4 de forma similar a como funciona en la actualidad el Mbone. A medida que los routers vayan incorporando IPv6, los túneles se irán desmantelando para dar paso a una infraestructura ya basada en IPv6.

Respecto a las aplicaciones actuales, la migración a IPv6 requiere que todas las referencias a direcciones de 32 bits sean sustituidas por las nuevas de 128. Desgraciadamente eso supone cambiar prácticamente todas la aplicaciones existentes. Además, un nuevo tipo de registro deberá ser definido en el DNS para realizar la transformación de los nombres de dominio actuales (que no requieren cambio) en direcciones de 128 bits. Este nuevo registro es el AAAA y la traducción inversa de direcciones a nombres se realizará dentro de la nueva zona ip6.int dispuesta a tal efecto.

Diversos fabricantes e instituciones se hallan trabajando, en paralelo con el trabajo del IETF, en productos conformes a IPv6 para distintas plataformas. Para finales de este año se espera que algunos fabricantes ya ofrezcan prototipos para realizar pruebas de campo del nuevo protocolo. Detalles sobre este asunto y sobre todo lo que rodea a IPv6 se pueden encontrar en la página sobre IP Next Generation que puede visitarse en:

http://playground.sun.com/pub/ipng/html/ipng-main.html

¡Feliz transición!

Referencias

  1. From World-Wide Web to Information Superhighway. François Fluckiger. Proceedings of the JENC6 (Tel-Aviv). Publicado por TERENA. Amsterdam, 1995.
  2. La Internet y la tecnología de las autopistas de la información. Ignacio Martínez. Boletín de Fundesco nº 166-167. Madrid, julio-agosto 1995.
  3. Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. RFC 1519, septiembre 1993.

  4. Multimedia I: Multicast IP y su aplicación en audio/video conferencia en la Internet. Ignacio Martínez. Boletín de RedIRIS nº 24. Madrid, 1993.

  5. The Recommendation for the IP Next Generation Protocol. S. Bradner, A. Mankin. RFC 1752, enero 1995.

  6. Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R. Hinden. Internet-Draft <draft-ietf-ipngwg-ipv6-spec-02.txt>, junio 1995.

  7. Simple Internet Protocol Plus (SIPP) Specification (128-bit address version). S. Deering. Internet-Draft, julio 1994.

  8. TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing. R. Callon. RFC 1347, junio 1992.


Ignacio Martínez
Fundesco
Dpto. de Redes
dirección de correo martinez [at] fundesco [dot] es