Natalia Benito y Josu Aramberri
Desde hace varios años está planteado el problema del agotamiento de números de IP en su versión IPv4, por lo que la IETF inició un proceso para diseñar una nueva versión del protocolo. Esta versión de IP "nueva generación" vio la luz hace unos años. Pero su implantación se va retrasando al encontrarse algunos mecanismos paliativos para rescatar espacio de direcciones en IPv4. En cualquier caso, el futuro de IP está ya definido.
Teniendo en cuenta que el proceso de transición desde IPv4 va a ser largo, y que ambos protocolos van a tener que coexistir durante mucho tiempo, se ha procurado que no exista dependencia alguna en el proceso de migración a IPv6. De esta forma, un administrador de una red puede decidir actualizar sus hosts en primer lugar, para en una fase ulterior actualizar los routers, mientras que otro podría decidir acometer la actualización justo al contrario. La única excepción a la ausencia de dependencias es la necesidad de proporcionar servicio de nombres a las máquinas actualizadas.
Con objeto de ir abordando una posible migración a IPv6, se ha instalado en la Facultad de Informática de San Sebastián una red piloto IPv6 que nos permita familiarizarnos con el nuevo protocolo, utilizando para ello los dos mecanismos básicos de transición definidos en el RFC 1933: el nivel IP dual y los túneles IPv6-sobre-IPv4. Se trata de una red muy simple, constituida únicamente por dos máquinas: un Pentium II 400 MHz, con Linux como sistema operativo, que actúa como router, y una Sun SparcStation 10 con el sistema operativo Solaris 7.
Para incluir el soporte IPv6 en Solaris 7 basta con instalar un paquete preparado al efecto, que incluye las herramientas y aplicaciones de red más comunes portadas a IPv6: telnet, ftp, ping, traceroute... En cambio en Linux, además de necesitar un kernel con soporte IPv6 (cualquier kernel a partir del 2.1.8), es necesario obtener y compilar los diferentes paquetes que contienen versiones portadas a IPv6 de las aplicaciones más típicas (inet6-apps, net-tools, servidor y cliente Web...). Como se trata de versiones experimentales, esto no siempre es trivial, y en muchos casos es necesario parchear el código. En este sentido, la web de Peter Bieringer (http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO.html) resulta de gran utilidad para obtener información acerca de qué aplicaciones han sido portadas a IPv6, dónde conseguirlas y cómo resolver los problemas más comunes que pueden surgir a la hora de compilar e instalar las mismas.
Además de las ya mencionadas implementaciones para Solaris y Linux, existen otras implementaciones de IPv6 tanto para hosts (Microsoft, FTP software, FreeBSD,...) como para routers (CISCO, Telebit, Bay Networks,...). En la dirección http://playground.sun.com/pub/ipng/html/ipng-implementations.html se puede encontrar información referente a las implementaciones disponibles actualmente.
En cuanto a las aplicaciones que se han instalado en nuestra isla IPv6, éstas podrían dividirse en dos grandes grupos: aplicaciones importantes, con las que cualquier sistema conectado a una red debería contar, y aplicaciones adicionales. Dentro de las aplicaciones importantes estarían los clientes y demonios más típicos (ftp, finger, telnet,...), aplicaciones de configuración como ifconfig, netstat y route y aplicaciones de debugging como traceroute. Ahora mismo no existen demasiadas aplicaciones adicionales para IPv6. Se han instalado las siguientes: servidor web Apache y navegador Chimera, cliente Whois, TCP-wrapper, Radvd (demonio de anuncios de router, utilizado para la autoconfiguración de los hosts de una red) así como un servidor de nombres para dar servicio a nuestra red IPv6.
Instaladas y configuradas las aplicaciones mencionadas anteriormente, ya se dispone de una isla IPv6 operativa a nivel local: al incluir el soporte para IPv6 en el correspondiente sistema operativo y reiniciar la máquina, ésta autoconfigura su propia dirección local al enlace. Con esto ya es posible probar el funcionamiento de las aplicaciones a nivel local.
El siguiente paso consiste en conectar nuestra isla IPv6 con el exterior. Ante la ausencia de una infraestructura de encaminamiento para IPv6, en 1997 se creó 6bone, como una plataforma que proporcionase transporte IPv6 de ámbito mundial, desde la que ir probando los nuevos protocolos y políticas de uso que se vayan desarrollando en torno a IPv6. Se trata de una red IPv6 virtual compuesta por islas IPv6 conectadas entre sí utilizando la infraestructura de encaminamiento de IPv4, mediante el establecimiento de túneles IPv6-sobre-IPv4.
Para poder conectar nuestra isla a 6bone se necesitan, por un lado, direcciones globales, y por otro, alguna organización con quien establecer un túnel que nos proporcione el acceso al resto de 6bone. En ambos casos la solución pasa por RedIRIS: en su calidad de pTLA (integrante del backbone de 6bone) suministra rangos de direcciones oficiales y establece túneles con las redes piloto que quieran conectarse a 6bone. En nuestro caso, el túnel es entre la máquina que desarrolla esa tarea en RedIRIS, y la máquina Linux que hace el papel de router.
Desde el punto de vista del encaminamiento, destacaremos que las direcciones 6bone siguen el formato agregable global. El campo TLA (Top Level Agreggation) es utilizado como identificador de 6bone. Dicho campo toma el valor 0x1FFE, valor asignado por la IANA. Lo que se persigue con el formato agregable global es una mejor agregación de las rutas, de manera que el tamaño de las tablas de encaminamiento en los routers del backbone sea mínimo. Así en el caso de 6bone, se establece una jerarquía de 3 niveles: en el primer nivel se encuentran los pTLAs que conforman el backbone (RedIRIS, Surfnet,..), que desempeñan el papel de ISPs experimentales y son los encargados de distribuir rangos de direcciones. El segundo nivel está formado por nodos de tránsito, que se conectan a uno o a varios nodos del backbone, y que a su vez proporcionan servicio de tránsito al último nivel de la jerarquía: los nodos hoja.
Otro aspecto interesante es poder obtener una idea de las dimensiones de 6bone, así como del grado de conectividad de que disponemos con el resto de redes conectadas. Para ello, una vez establecido el túnel con RedIRIS, instalamos uno de los scripts de monitorización de los utilizados en 6bone. Dicho script genera como salida una página html con los datos que obtiene al enviar pings a todos los hosts que aparecen en el registro de 6bone. El script se ejecuta tres veces al día y los resultados se pueden consultar a través del servidor web IPv6 que hemos instalado en nuestra isla (http://www.ipv6.st.ehu.es/). Para conectarse a este servidor es necesario utilizar una navegador IP v6 como Chimera
6bone está concebido únicamente como una red experimental que facilite la transición a IPv6, y por tanto desaparecerá cuando el nuevo protocolo disponga de una infraestructura de encaminamiento propia. Ese día cada vez está más cerca, sobre todo desde que el 14 de Julio de este mismo año la IANA anunciara la asignación de espacio de direccionamiento IPv6 a los registros regionales de Internet, para comenzar así con el desarrollo a nivel mundial de las direcciones IPv6.
Por último, señalar que la red piloto instalada también nos ha servido para poder estudiar algunos de los mecanismos que proporciona el nuevo protocolo de Neighbor Discovery (concebido como sustituto de ARP), para resolver las diferentes situaciones que se plantean durante la interacción de nodos conectados a un mismo enlace: autoconfiguración de las direcciones, descubrimiento de parámetros, descubrimiento de vecinos...
Natalia Benito Ruiz de la Peña
acbberun [at] sc [dot] ehu.esJosu Aramberri Miranda
acparmij [at] si [dot] ehu.esDpto. de Arquitectura y Tecnología de Computadores
UPV/EHU