Simulacion de Implementacion de Red Basada en IpV6

Objetivos y necesidades...................................................................3

Implementacion de la red.................................................................5

Pasos a seguir................................................................................7

Protocolos......................................................................................11

Apendices......................................................................................26

Bibliografia.....................................................................................34

Bibliografia.............................................................48

1. OBJETIVOS

Los principales objetivos que se pretenden alcanzar con esta práctica son:

· Conocer las principales características de la nueva versión del protocolo de red de la arquitectura TCP/IP: IP versión 6 o, de forma abreviada, IPv6.

· Comprender su funcionamiento y aplicar los conocimientos adquiridos a la configuración de un escenario de red sencillo compuesto por dos routers, tres segmentos Ethernet y varios sistemas finales.

· Conocer las técnicas básicas diseñadas para la migración hacia IPv6 de redes basadas en el protocolo IP actual (IPv4) y experimentar con ellas sobre el escenario anterior.

2. CONOCIMIENTOS PREVIOS

Para realizar esta práctica es necesario poseer unos conocimientos básicos sobre el protocolo IPv6. Por ello, antes de abordar su realización, es imprescindible haber leído alguna descripción de las características básicas de IPv6 y de sus diferencias con respecto a IPv4. Se puede consultar, por ejemplo, el capítulo 29 de [Comer95] o la sección 5.5.10 de [Tannen96]. Alternativamente, puede consultar los tutoriales [Stallings] o [IPv6Forum] disponibles en la red.

3. DESCRIPCIÓN DEL ENTORNO DE RED

El entorno de red sobre el cual se desarrollará la práctica aparece representado en la Figura 1. Está compuesto por:

¨ Dos router CISCO, que en adelante denominaremos CISCOA y CISCOB, dotados de dos interfaces Ethernet. CISCO1, CISCO2, CISCO5 y CISCO6 (ver mapa de la red en [RED]).

¨ Dos PCs, que en adelante denominaremos PCA y PCB, dotados de placa Ethernet adicional y conectados a las redes virtuales en las que se encuentran los router CISCOA y CISCOB respectivamente.

¨ El servidor DORADA, conectado a la VLAN1.

Por tanto, para la realización de esta práctica deberá buscar dos router CISCO (CISCO1/CISCO2, o CISCO5/CISCO6) y dos puestos contiguos conectados a sus redes.

4. GUIÓN DE LA PRÁCTICA

4.1. Instalación del protocolo IPv6 sobre un PC

Para realizar la práctica es necesario instalar el protocolo IPv6 sobre los dos PCs utilizados (PCA y PCB). Para ello siga el procedimiento siguiente:

Arranque el PC con una copia nueva de Windows NT 4.0, siguiendo el procedimiento descrito en [DocAdic].

Instale la segunda tarjeta Ethernet del PC. Siga el procedimiento descrito en el Apéndice A (es prácticamente igual al utilizado para instalarla en Windows 95, aunque con alguna particularidad importante).

Finalmente instale el protocolo IPv6. Para ello, acceda al “Panel de Control | Red | Protocolos” y elija la opción “Añadir”. Una vez dentro de ésta diríjase al directorio “E:\Drivers\ipv6” y cargue el protocolo MSR IPv6. Tras concluir la instalación, es necesario rearrancar la máquina para que los cambios surtan efecto.

Una vez terminada la instalación, puede comprobar que la instalación se ha realizado con éxito abriendo una ventada de DOS y tecleando el comando “ipv6 if”. Como resultado deberá obtener la lista de interfaces IPv6 de la máquina.

Realice también un ping a la dirección de loopback (“::1”) para comprobar que todo funciona correctamente. Para ello, teclee en una ventana MS-DOS el comando “ping6 ::1”; deberá obtener un resultado similar al siguiente:

C:\>ping6 ::1

Pinging ::1 with 32 bytes of data:

Reply from ::1: bytes=32 time<1ms

…

4.2. Instalación del protocolo IPv6 en un CISCO

El software que cargan por defecto los routers CISCO no incluye el protocolo IPv6, por lo que es necesario configurarlos para que carguen una versión distinta del software desde uno de los servidores de la red (DORADA) utilizando el protocolo TFTP.

Busque en la bibliografía (por ejemplo en [Comer95]) o en Internet cuál es la utilidad del protocolo TFTP. Averigüe qué protocolo de transporte utiliza TFTP (UDP o TCP) y porqué.

Para cargar el software con IPv6, añada la siguiente línea a la configuración del router:

boot system c1600-yipv6-mz.19990308 255.255.255.255

Para simplificar, se han copiado en DORADA unas configuraciones por defecto que ya incluyen dicho comando, por lo que solamente es necesario cargar la configuración inicial de los router siguiendo el procedimiento descrito en [CISCO1] y eligiendo como fichero de configuración "ciscoX-confg.ipv6", siendo X el número de orden del router que corresponda.

Tras rearrancar el router, se debe comprobar que la versión del software se ha cargado correctamente mediante el comando “show versión”, que debe mostrar lo siguiente:

Cisco6#sh ver

Cisco Internetwork Operating System Software

IOS (tm) 1600 Software (C1600-YIPV6-M), Experimental Version 11.3

4.3. Autoconfiguración de direccionesIPv6

Una de las mejoras que aporta IPv6 en el entorno local consiste en la posibilidad de que los sistemas finales se autoconfiguren, asignándose automáticamente sus direcciones IPv6 y descubriendo la dirección de los routers de la red.

Existen dos métodos básicos que permiten a un sistema final IPv6 autoconfigurarse: autoconfiguración sin estado (“stateless autoconfiguration”) y autoconfiguración con estado (“statefull autoconfiguration”).

La autoconfiguración sin estado (en la cual nos centraremos en este apartado) permite que los sistemas finales se autoasignen una dirección IP de ámbito local (“link-local address”) nada más arrancar. Estas direcciones se construyen añadiendo al prefijo “fe80::/64” un identificador basado en la dirección MAC del interfaz, lo que garantiza que la dirección construida sea única. Las direcciones de ámbito local se utilizan única y exclusivamente para comunicarse con sistemas localizados en la misma subred. Por ejemplo, se utilizan a la hora de enviar mensajes del protocolo “Neighbour Discovery”.

La autoconfiguración con estado se basa en la utilización del protocolo DHCP, que permite a un sistema final solicitar a un servidor de DHCP que le proporcione los datos de configuración que necesita (dirección IP, dirección router, dirección del servidor de DNS, etc).

Compruebe la dirección de ámbito local asignada a los PCs. Para ello, utilice el comando “ipv6 if” (descrito en el Apéndice B), que muestra todos los interfaces IPv6 asignados.

Active el protocolo IPv6 en cada uno de los interfaces Ethernet de los CISCOs mediante el comando:

interface etherX

ipv6 enable

y compruebe la dirección de ámbito local asignada a cada uno de ellos. Para ello, utilice el comando “show ipv6 interfaces”.

Incluya en la memoria la direcciones locales asignadas a cada uno de los interfaces de los PCs y los CISCOs. Describa brevemente el método exacto utilizado para construir las direcciones “link-local” a partir de las direcciones MAC.

A continuación configure los routers para que comiencen a enviar paquetes “Router Advertisement (RA)” a las distintas VLAN. Para ello:

1. Arranque el analizador de protocolos en uno de los PCs y comience a capturar. Opcionalmente, puede activar también las trazas de depuración de los protocolos ICMP y ND en los CISCOs mediante “debug ipv6 icmp” y “debug ipv6 nd”. (Para facilitar el desarrollo de la práctica, se recomienda siempre mantener dos “telnet” simultáneos con cada CISCO, uno para ver las trazas de depuración, y otro para teclear los comandos de configuración.)

2. Active el encaminamiento de paquetes IPv6 en ambos CISCOs añadiendo el comando:

ipv6 unicast-routing

3. Asigne el prefijo IPv6 que corresponda a cada interface Ethernet mediante el comando:

ipv6 address 3ffe:3328:4:X::/64 eui-64

(Consulte la lista de prefijos IPv6 asignados a cada VLAN en el Apéndice D).

4. Active el envío de paquetes “Router Advertisement” en cada interfaz Ethernet mediante:

no ipv6 nd suppress-ra

Tras la configuración, repita los comandos “ipv6 if” en los PCs y “show ipv6 interfaces” en los CISCOs.

4.4. Pruebas del Protocolo Neighbour Discovery

El protocolo “Neighbour Discovery (ND)” se ocupa principalmente de las funciones de resolución de direcciones dentro de la subred. Equivale al protocolo ARP utilizado en IPv4, aunque incorpora una serie de modificaciones que resuelven algunos de los problemas detectados hasta la fecha en ARP, además de mejorar su eficiencia. Por ejemplo, una de las mejoras incorporadas ha sido la independización del protocolo de la subred empleada. A diferencia de lo que sucede en IPv4, en cuyo caso existen varias versiones del protocolo de resolución (ARP para LAN; ATMARP para ATM, etc); en IPv6 el protocolo es el mismo para cualquier subred, lo que simplifica notablemente la implementación y gestión.

Arranque la captura de tramas en el analizador de protocolos de PCA. Opcionalmente, active el trazado del protocolo ND en el CISCOA mediante el comando “debug ipv6 nd”. Realice un ping entre PCA y CISCOA utilizando las direcciones de ámbito local. Consulte el contenido de las tablas de vecindades en el PC (mediante “ipv6 nc”) y en el CISCO (mediante “show ipv6 neighbors”) antes y después de la prueba para ver como se actualizan. Repita la prueba utilizando direcciones globales.

Realice un ping continuo (mediante la opción “-t”). Verá que, a pesar de que las direcciones Ethernet de los vecinos son conocidas, periódicamente se envían paquetes de tipo NS y NA.

4.5. Configuración de tablas de encaminamiento

Para añadir una entrada en las tablas de encaminamiento IPv6 de un CISCO se utiliza el comando global “ipv6 route”. Por ejemplo:

(config)# ipv6 route 3ffe:3328:5::/64 3ffe:3328:1::10

encamina todo los datagramas dirigidos hacia el prefijo 3ffe:3328:5::/64 (de 64 bits de longitud) hacia el router cuya dirección es 3ffe:3328:1::10.

Configure las tablas de encaminamiento necesarias para que exista conectividad entre las subredes de PCA y PCB. Una vez configuradas las rutas, compruebe la conectividad entre PCA y PCB utilizando ping6 y tracert6. Compruebe además la conectividad con DORADA (3ffe:3328:1::210:5aff:feaf:5615).

4.6. Traceroute y Cabecera de Encaminamiento

IPv6 incluye una opción similar a la de encaminamiento fijado en origen que ya existía en IPv4. Esta opción, denominada Cabecera de Encaminamiento o “Routing Header”, permite especificar una serie de direcciones IP por las que necesariamente un datagrama debe pasar. Son múltiples las posibilidades que ofrece esta opción: elección de proveedores, diagnóstico de encaminamiento, etc.

En este apartado vamos a utilizar dicha opción conjuntamente con la herramienta “traceroute” con la finalidad de conocer precisamente el camino seguido por los datagramas enviados entre PCA y PCB. La herramienta “tracert6” disponible en los PCs incluye una opción, “-r”, para activar el uso de la opción de encaminamiento fijado en origen.

Cuando se realiza un tracert6 desde PCA con destino en PCB SIN la opción “-r”, se envían sucesivas solicitudes de eco con destino en PCB utilizando valores crecientes del TTL. Sin embargo, cuando se emplea la opción “-r”, se envían sucesivas solicitudes de echo con destino en PCA y con una cabecera de encaminamiento que incluye a PCB.

Arranque la captura de trazas con el analizador en PCA y PCB y realice un tracert6 desde PCA a PCB con y sin la opción “-r”.

Analice las trazas capturadas y describa en la memoria las diferencias entre utilizar o no la opción -r del traceroute.

4.7. Configuración de túneles

Uno de los mecanismos básicos en que se basará la transición de la actual red basada en IPv4 hacia la nueva red IPv6 son los llamados “túneles”. En general, un túnel consiste en la encapsulación de un protocolo X sobre otro protocolo Y, con el objeto de enviar paquetes del protocolo X sobre una red que no conoce dicho protocolo. Por ejemplo, la siguiente figura representa un escenario típico, en el cual interconectamos dos “islas” que utilizan el protocolo Y a través de una red que sólo conoce el protocolo X.

En nuestro caso los túneles se utilizan para encapsular paquetes IPv6 sobre datagramas IPv4 y de esta forma poder conectar a través de Internet las distintas “islas” que vayan migrando a IPv6.

Existen básicamente dos tipos de túneles según se configuren manual o automáticamente. Los túneles manuales son aquellos que se configuran entre routers con el objeto de atravesar “islas” IPv4, tal como aparece en la siguiente figura:

Los túneles automáticos se establecen directamente entre sistemas finales y, como su nombre indica, no necesitan ser configurados, ya que se utilizan conjuntamente con direcciones IPv6 especiales que contienen una dirección IPv4 (por ejemplo, ::192.168.17.1). Su funcionamiento es simple: el sistema origen encapsula directamente los datagramas IPv6 sobre datagramas IPv4 cuya dirección IPv4 destino obtiene de la parte final de la dirección IPv6. Estos túneles se utilizan principalmente para comunicar sistemas IPv6 localizados en redes cuyos routers no soportan IPv6 (encapsulación extremo a extremo).

Configuración de un túnel manual

Para comprobar el funcionamiento de los túneles manuales, vamos a deshabilitar el protocolo IPv6 en los interfaces ether0 de ambos CISCOs y establecer un túnel IPv4 entre ellos. Para ello:

1. Deshabilite IPv6 en los CISCOS mediante los comandos siguientes:

# interface ether0

# no ipv6 address ……

# no ipv6 enable

Borre, además las rutas IPv6 que añadió en los apartados anteriores. Compruebe que, efectivamente, la conectividad IPv6 entre CISCOs se ha perdido.

2. Establezca un túnel entre CISCOA y CISCOB añadiendo en AMBOS routers los comandos siguientes:

# interface tunnel0

# no ip address

# ipv6 address 3ffe:3328:1::/64

# tunnel source X.X.X.X

# tunnel destination Y.Y.Y.Y

# tunnel mode ipv6ip

siendo X.X.X.X e Y.Y.Y.Y las direcciones IPv4 origen y destino del túnel (las de CISCOA y CISCOB en la VLAN1).

3. Añada las rutas IPv6 necesarias para encaminar entre PCA y PCB. Por ejemplo, en CISCOA habrá que incluir:

# ipv6 route X:X:X::/64 tunnel0

siendo X el prefijo IPv6 correspondiente a la red ethernet1 del CISCOB.

Finalmente, active el trazado de paquetes IPv6 e IPv4 en los CISCOs y compruebe que el túnel funciona haciendo un ping6 y un tracert6 entre PCA y PCB.

Túneles automáticos

Para utilizar los túneles automáticos, no es necesario configurar nada, basta con utilizar las direcciones IPv6 compatibles con IPv4 que tiene asignado cada PC, y configurar las rutas IPv4 para que exista conectividad entre PCA y PCB. Para conocer las direcciones IPv4 compatibles de los PCs puede utilizar el comando “ipv6 if 2” (el interfaz número 2 es siempre el utilizado para los túneles automáticos).

Active la captura de trazas en los analizadores de protocolos. Opcionalmente, active las trazas de paquetes IPv6 en los CISCOs. Realice un ping6 entre PCA y PCB utilizando la dirección “IPv6 compatible IPv4” de PCB. Realice además un tracert6 hacia PCB.

5. Datos de interes

5.1. Encaminamiento dinámico con RIP

Es posible configurar los router CISCO para que utilicen encaminamiento dinámico mediante el protocolo RIP

5.2. Configuración de un traductor IPv6/IPv4

Existe un método para traducir datagramas IPv6 a IPv4 y viceversa. Este métodos está pensado para poder comunicar sistemas que sólo conocen IPv6 con sistemas que sólo conocen IPv4.

Consulte en [CISCO] los comandos necesarios para configurar un traductor (NAT) y trate de garantizar la conectividad en un escenario en el que, por ejemplo, PCA no soporte IPv6 y quiera comunicarse con PCB que sólo soporta IPv6.

6. Bibliografía

[Comer95] "Internetworking with TCP/IP. Volume I: Principles, Protocols and Architecture", D. E. Comer. 3rd ed., Prentice-Hall, 1995. (Nota: existe ya una cuarta edición actualizada de este libro publicada en el año 2000).

[Tannen96] "Computer Networks", Andrew S. Tannenbaum, Tercera edición. Prentice-Hall, 1996.

[IPv6Forum] “Tutorial de IPv6”, Jordi Palet, IPv6 Forum. Disponible en: http://www.consulintel.com/Html/ForoIPv6/Documentos/Tutorial de IPv6.pdf

[Stallings] IPv6 : The New Internet Protocol”, W. Stallings. Disponible en: http://www.comsoc.org/pubs/surveys/stallings/stallings-orig.html

[CISCO] "IPv6 Commands". CISCO. Disponibles en http://www.lab.dit.upm.es/~labrst/config/comandos-cisco6.txt

[WNT] Aplicación de medida de prestaciones WinNetTest. Ver http://www.lab.dit.upm.es/~labrst/config/config.htm#wnettest

[DocAdic] Procedimiento de Arranque de PCs con Windows NT. http://www.lab.dit.upm.es/~labrst/config/config.htm#nt

[MSRIPv6] “Configuring MSR IPv6”. Microsoft Research.

http://www.lab.dit.upm.es/~labrst/config/config-msripv6.htm

[RED] Mapa de la red del laboratorio, plan de numeración y otras informaciones de interés en http://www.lab.dit.upm.es/~labrst/mapas/mapa.htm

[Agilent] Manual del Analizador de Protocolos “Advisor SW Edition” de Agilent. http://www.lab.dit.upm.es/~labrst/config/AdvisorSWEdition.pdf

[mem-itr-ipv6] Plantilla de la Memoria de la Práctica de Interconexión de Redes con IPv6. http://www.lab.dit.upm.es/~labrst/00-01/p.itr-ipv6/memoria-itr-ipv6.doc

Apéndice Datos Necesarios Adicionales paramontar un red:

Instalación de Tarjetas de Red sobre Windows NT

1. Arranque el ordenador con Windows NT y copie los controladores de las tarjetas Ethernet al disco duro local. Estos se encuentran en “E:\Drivers\3Com”. Cópielos, por ejemplo, a “C:\TEMP”.

2. Acceda a la solapa Adaptadores de la opción Red del Panel de Control y borre el adaptador “3Com Fast EtherLink XL Adapter (3C905)”.

3. Rearranque el ordenador. Al hacerlo dará una serie de errores al tratar de “montar” los discos de red debido a que la red no esta configurada. Dígale que reintente en el futuro.

4. Acceda a “Panel de Control | Red | Adaptadores” y elija la opción de agregar adaptador desde disco utilizando los controladores copiados en el paso 1 (“C:\TEMP\3COM\DISK1”).

5. Cierre el cuadro de diálogo de Red. Al hacerlo le preguntará los parámetros de configuración de TCP/IP correspondientes a las dos tarjetas Ethernet. Configúrelas de la forma siguiente:

a. Red de producción (es la tarjeta que aparece como 3C905-TX). Debe utilizar DHCP para autoconfigurarse (opción “Obtener una dirección IP automáticamente).

b. Red de experimentación (tarjeta 3C905-TXB). Configure la dirección IP y máscara que corresponda (consulte el mapa de la red en [RED] para conocer los valores que corresponden a cada ordenador). Deje en blanco el campo de router y añada a mano una ruta pata encaminar todo el tráfico dirigido hacia 192.168.0.0/16 hacia el router de la red (CISCOA o CISCOB).

Nota: en Windows NT es posible añadir una ruta permanente (que no se borre al rearrancar) utilizando la opción “-p” del comando “route add”.

6. Rearranque otra vez más y compruebe que ambas tarjetas funcionan correctamente y tienen conectividad IP.

Apéndice B: Comandos de interés sobre IPv6 en Windows

Se describen en este apéndice algunos comandos de utilidad incluidos en la implementación de IPv6 de Microsoft Research. Para una referencia completa, consultar [MSRIPv6]. Todos los comandos aquí descritos deben ejecutarse desde una ventana de MS-DOS.

1. ipv6 if. Muestra información completa sobre los interfaces IPv6 de una máquina. Por ejemplo, en un PC con una sola tarjeta Ethernet el comando muestra la siguiente información (ver los comentarios marcados con ***):

C:\>ipv6 if

Interface 4 (site 1): *** Este es el interface Ethernet. Se

*** distingue por que la dirección de

*** enlace es una dirección MAC (00-c0-...)

uses Neighbor Discovery

sends Router Advertisements

link-level address: 00-c0-df-e6-47-ff

preferred address 3ffe::2c0:dfff:fee6:47ff, infinite/infinite

preferred address fe80::2c0:dfff:fee6:47ff, infinite/infinite

multicast address ff02::1, 1 refs, not reportable

multicast address ff02::1:ffe6:47ff, 2 refs, last reporter

multicast address ff02::2, 1 refs, last reporter

multicast address ff05::2, 1 refs, last reporter

anycast address 3ffe::

multicast address ff02::1:ff00:0, 1 refs, last reporter

link MTU 1500 (true link MTU 1500)

current hop limit 128

reachable time 41500ms (base 30000ms)

retransmission interval 1000ms

DAD transmits 1

Interface 3 (site 1): *** 6-over-4 interface (se usa en uno de

*** los métodos de transición). Se distingue

*** porque la dirección de subred es una

*** dirección IP. NO se utiliza en esta

*** práctica

uses Neighbor Discovery

link-level address: 138.4.3.159

preferred address fe80::8a04:39f, infinite/infinite

multicast address ff02::1, 1 refs, not reportable

multicast address ff02::1:ff04:39f, 1 refs, last reporter

link MTU 1280 (true link MTU 65515)

current hop limit 128

reachable time 39500ms (base 30000ms)

retransmission interval 1000ms

DAD transmits 1

Interface 2 (site 0): *** Interface para túneles automáticos. Se

*** distingue por sus direcciones IPv4

*** compatibles (::X.X.X.X)

does not use Neighbor Discovery

link-level address: 0.0.0.0

preferred address ::138.4.3.159, infinite/infinite

link MTU 1280 (true link MTU 65515)

current hop limit 128

reachable time 0ms (base 0ms)

retransmission interval 0ms

DAD transmits 0

Interface 1 (site 0): *** Interface Loopback

does not use Neighbor Discovery

link-level address:

preferred address ::1, infinite/infinite

link MTU 1500 (true link MTU 1500)

current hop limit 1

reachable time 0ms (base 0ms)

retransmission interval 0ms

DAD transmits 0

2. ipv6 rt. Permite consultar el contenido de las tablas de encaminamiento IPv6.

3. ipv6 nc. Permite consultar el contenido de las tablas de vecindades IPv6.

4. ping6. Implementación para IPv6 de la herramienta ping. Teclear "ping6" para ver opciones.

5. tracert6. Implementación para IPv6 del conocido programa "traceroute", que permite conocer el camino seguido por los datagramas hacia un determinado destino. Teclear "tracert6" para ver opciones.

Apéndice C: Comandos de interés sobre IPv6 en los CISCOs

Se citan a continuación los principales comandos relacionados con IPv6 en los CISCOs que se utilizan en la práctica. Para una referencia completa consultar [CISCO].

show ipv6 interfaces. Muestra información sobre los interfaces configurados con IPv6.

show ipv6 route. Muestra las tablas de encaminamiento IPv6.

show ipv6 neighbors. Muestra la tabla de vecindades del router.

debug ipv6 *. Permite activar las trazas de depuración de IPv6. Teclear “debug ipv6 ?” para consultar opciones.

Apéndice D: Prefijos IPv6 asignados a la Lan

Subred Prefijo

VLAN1 3ffe:3328:4:1::/64

VLAN2

3ffe:3328:4:2::/64

VLAN3

3ffe:3328:4:3::/64

VLAN4

3ffe:3328:4:4::/64

VLAN5

3ffe:3328:4:5::/64

VLAN6

3ffe:3328:4:6::/64

VLAN7

3ffe:3328:4:7::/64

Apéndice C Informacion Necesaria sobre el Protocolo ipv6:
IPng (IPv6)

IP "next generation" ha sido el nombre con el que se ha bautizado a la versión seis del protocolo Internet (IP). Se trata de la definición de un nuevo protocolo de red destinado a sustituir a la actual versión IP, la cuatro.

¿Por qué se necesita un nuevo protocolo de red?. La respuesta es muy simple. Cuando IPv4 fue estandarizado, hace unos quince años, nadie podía imaginar que se convertiría en lo que es hoy: una arquitectura de amplitud mundial, con un número de usuarios superior al centenar de millones y que crece de forma exponencial. Aquella primera "Internet" fundada, sobre todo, con fines experimentales, científico-técnicos y, por supuesto, con objetivos militares, no se parece en nada a la actual. Cada día se advierte una mayor tendencia hacia su comercialización, ya sea por el propio acceso en sí a la red (empresas proveedoras) o por servicios accesibles desde ella.

Estos cambios de escala y orientación suponen varios problemas para IPv4 [RFC1287] [RFC1338] [RFC1917]:

• Escala:

Cada máquina presente en la red dispone de una dirección IP de 32 bits. Ello supone más de cuatro mil millones de máquinas diferentes. Esa cifra, no obstante, es muy engañosa. El número asignado a un ordenador no es arbitrario, sino que depende de una estructura más o menos jerárquica (en especial, pertenece a una red), lo cual ocasiona que se desperdicie una enorme cantidad de direcciones. La cuestión es que en 1.993 fue claro que con el ritmo de crecimiento sostenido de Internet hasta aquel momento (exponencial), el agotamiento del espacio de direcciones era casi inminente.

• Enrutado:

Otro de los grandes problemas del crecimiento de Internet es la capacidad de almacenamiento necesaria en la pasarelas (routers) y el tráfico de gestión preciso para mantener sus tablas de encaminamiento. Existe un límite tecnológico al número de rutas que un nodo puede manejar, y como dado que Internet crece mucho más rápidamente que la tecnología que la mantiene, se vió que las pasarelas pronto alcanzarían su capacidad máxima y empezarían a desechar rutas, con lo que la red comenzaría a fragmentarse en subredes sin acceso entre sí.

Dado lo grave de la situación se definió el CIDR (Classless Inter-Domain Routing) [RFC1481] [RFC1517..1519], con el que las pasarelas reducían el tamaño de sus tablas colapsando juntas varias subredes con el mismo prefijo. Gracias a ello se ha ganado un tiempo muy valioso, pero tan sólo se ha postergado lo inevitable.

En [RFC1797] y [RFC1879] se realiza el experimento de dividir una red A (la red 39) en multitud de pequeñas subredes. Los resultados fueron alentadores, por lo que dicha técnica podría utilizarse para ampliar de nuevo el tiempo de vida de IPv4.

• Multiprotocolo:

Cada vez resulta más necesaria la convivencia de diversas familias de protocolos: IP, OSI, IPX... Se necesitan mecanismos que permitan abstraer al usuario de la tecnología subyacente para permitir que concentre su atención en los aspectos realmente importantes de su trabajo. Se tiende, pues, hacia una red orientada a aplicaciones, que es con lo que el usuario interacciona, más que a una red orientada a protocolos (como hasta el momento) [RFC1560].

• Seguridad:

El mundo IPv4 es el mundo académico, científico, técnico y de investigación. Un ambiente, en general, que podría calificarse como "amigable", desde el punto de vista de la gestión y la seguridad en la red. Con la aparición de servicios comerciales y la conexión de numerosísimas empresas, el enorme incremento en el número de usuarios y su distribución por todo el planeta, y la cantidad, cada vez mayor, de sistemas que necesitan de Internet para su correcto funcionamiento, etc., es urgente definir unos mecanismos de seguridad a nivel de red. Son necesarios esquemas de autentificación y privacidad, tanto para proteger a los usuarios en sí como la misma integridad de la red ante ataques malintencionados o errores [RFC1281] [RFC1636] [RFC1828..1829].

• Tiempo Real:

IPv4 define una red pura orientada a datagramas y, como tal, no existe el concepto de reserva de recursos. Cada datagrama debe competir con los demás y el tiempo de tránsito en la red es muy variable y sujeto a congestión. A pesar de que en la cabecera IP hay un campo destinado a fijar, entre otras cosas, la prioridad del datagrama [RFC1349] [RFC1455], en la práctica ello no supone ninguna garantía. Se necesita una extensión que posibilite el envío de tráfico de tiempo real, y así poder hacer frente a las nuevas demandas en este campo [RFC1667].

• Tarificación:

Con una red cada día más orientada hacia el mundo comercial hace falta dotar al sistema de mecanismos que posibiliten el análisis detallado del tráfico, tanto por motivos de facturación como para poder dimensionar los recursos de forma apropiada [RFC1272] [RFC1672].

• Comunicaciones Móviles:

El campo de las comunicaciones móviles está en auge, y aún lo estará más en un futuro inmediato. Se necesita una nueva arquitectura con mayor flexibilidad topológica, capaz de afrontar el reto que supone la movilidad de sus usuarios. La seguridad de las comunicaciones, en este tipo de sistemas, se ve, además, especialmente comprometida [RFC1674] [RFC1688].

• Facilidad de Gestión:

Con el volumen actual de usuarios y su crecimiento estimado, resulta más que obvio que la gestión de la red va a ser una tarea ardua. Es preciso que la nueva arquitectura facilite al máximo esta tarea. Un ejemplo de ello sería la autoconfiguración de los equipos al conectarlos a la red [RFC1541].

• Política de enrutado:

Tradicionalmente los datagramas se han encaminado atendiendo a criterios técnicos tales como el minimizar el número de saltos a efectuar, el tiempo de permanencia en la red, etc. Cuando la red pertenece a una única organización eso es lo ideal, pero en el nuevo entorno económico en el que diferentes proveedores compiten por el mercado las cosas no son tan simples. Es imprescindible que la fuente pueda definir por qué redes desea que pasen sus datagramas, atendiendo a criterios de fiabilidad, coste, retardo, privacidad, etc. [RFC1674..1675].

A lo largo de los años se han propuesto varios protocolos como sustitutos al IPv4. Los tres más importantes han sido PIP ('P' Internet Protocol) [RFC1621] [RFC1622], TUBA (TCP/UDP With Bigger Addresses) [RFC1347] [RFC1526] y SIP/SIPP (Simple Internet Protocol/Simple Internet Protocol Plus) [RFC1710]. En [RFC1454] se realiza una buena comparativa entre ellos.

En 1.993 se decidió solicitar opiniones sobre "cómo debería ser" el IP del futuro (IPng) a través de [RFC1550]. Las respuestas recibidas fueron numerosas y provenientes de fuentes muy diversas. En general todas coincidían en los puntos básicos mencionados previamente. Tal vez los más interesantes hayan sido los que mostraban el punto de vista de varias multinacionales [RFC1669] [RFC1684].

Por fin se propuso un estándar en 1.995 [RFC1752], refinado a principios de 1.996 en [RFC1883]. Como puede verse se trata de un tema de máxima actualidad. De hecho todavía faltan por publicar, al menos, dos funciones adicionales: configuración dinámica y búsqueda de máquinas vecinas. Los datos de que dispongo son de finales de Abril de 1.996 así que es muy posible que ahora, Junio, se hayan publicado algunos documentos adicionales.

Las principales características del nuevo IPv6, como diferencias respecto a IPv4, son [RFC1883]:

• Se trata de un protocolo diseñado para ser ampliado, de forma simple, con funcionalidades adicionales, ya sea a través de nuevas cabeceras de extensión o bien de opciones incluidas en las cabeceras ya existentes.

• Los nuevos números IP constan de 128 bits, lo cual permitirá efectuar una división muy jerárquica del espacio de direcciones para facilitar el enrutado. Adicionalmente ello posibilitará incluir la dirección física de la interfaz de red de la máquina en la propia dirección IP, facilitando de forma considerable el proceso de autoconfiguración.

• Se codifica directamente en el datagrama qué acción debe adoptar una máquina cuando ésta no es capaz de reconocer alguna de las opciones del mismo.

• Se incluyen cabeceras destinadas a la autentificación y la encriptación de los datagramas.

• Se permite que la fuente encamine directamente sus datagramas, como soporte a su política o necesidades de rutado.

• Los datagramas ya no tienen un límite de longitud de 65536 bytes.

• El soporte de encapsulados es muy natural, dado su diseño de cabeceras encadenadas.

• La fragmentación, en caso de ser necesaria, la realiza la fuente. Para facilitar el cálculo del MTU [RFC1191] [RFC1435] del camino hace falta el apoyo de la nueva capa ICMP [RFC1885]. Ahora, cuando una pasarela genera un mensaje ICMP "Datagram Too Big", indica cuál es el MTU de la red problemática.

• La gestión de Multicasting [RFC966] [RFC988] [RFC1112] y Anycasting [RFC1546] (IGMP) ha pasado a formar parte del nuevo ICMP [RFC1886].

• Para acelerar el cálculo de los enrutamientos y atender las necesidades de las aplicaciones en tiempo real, cada datagrama puede contener un "identificador de flujo". Esos identificadores son, en cierta medida, equivalentes al concepto de circuitos virtuales, pero se trata de unos circuitos virtuales "suaves" que pueden ser desde ignorados hasta completamente vinculantes, según el diseño del sistema. Ello da un juego enorme. En mi opinión, éste es el concepto más novedoso e importante de IPv6 [RFC1809].

• IPv6 no incluye una suma de control en la cabecera. Para asegurar la validez de la información la capa UDP está obligada a utilizar su opción de suma de control. Adicionalmente el nuevo ICMP también incluye una suma de control, por razones similares.

Las nuevas direcciones IP, como ya se ha dicho, constan de 128 bits. Ello hace que la notación "punto" común de IPv4 sea poco práctica. IPv6 utiliza notación hexadecimal en grupos de 16 bits, separándolos por el carácter de dos puntos (":") [RFC1884]. En [RFC1920] se propone una codificación más compacta.

En [RFC1884] se realiza una asignación preliminar de direcciones, muy agresiva. Se reserva una enorme cantidad de valores para determinados grupos de direcciones (por ejemplo, multicasting, NSAP (OSI), etc.), pero aún así el espacio disponible para usos todavía no especificados es del 85%. Las propias direcciones IPv4 están incluidas aquí. Hay varias novedades interesantes, como el hecho de definir direcciones especificamente locales a nivel de capa de enlace (MAC) u organización.

En definitiva, el IPv6 ya está aquí. Todavía queda un largo trecho hasta que se implante de forma mayoritaria, pero sin duda incorpora numerosas características que lo hacen atractivo, como el soporte de comunicaciones en tiempo real, la autoconfiguración de sistemas, seguridad, etc. La mayoría de los detalles todavía se están ultimando y, hasta donde sabe el autor, no se han propuesto aún plazos de implantación.

Bibliografía

[RFC791] RFC 791: "Internet Protocol"

Jon Postel

Septiembre 1.981

[RFC792] RFC 792: "Internet Control Message Protocol"

Jon Postel

Septiembre 1.981

[RFC801] RFC801: "NCP/TCP TRANSITION PLAN"

Jon Postel

Noviembre 1.981

[RFC907] RFC907: "INTERNET SUBNETS"

Jeffrey Mogul

Octubre 1.984

[RFC919] RFC919: "BROADCASTING INTERNET DATAGRAMS"

Jeffrey Mogul

Octubre 1.994

[RFC922] RFC922: "BROADCASTING INTERNET DATAGRAMS IN THE

PRESENCE OF SUBNETS"

Jeffrey Mogul

Octubre 1.984

[RFC925] RFC925: "Multi-LAN Address Resolution"

Jon Postel

Octubre 1.984

[RFC932] RFC932: "A SUBNETWORK ADDRESSING SCHEME"

David D. Clark

Enero 1.985

[RFC936] RFC936: "Another Internet Subnet Addressing Scheme"

Michael J. Karels

Febrero 1.985

[RFC940] RFC940: "Toward an Internet Standard Scheme for

Subnetting"

Gateway Algorithms and Data Structures (GADS) Task

Force

Abril 1.985

[RFC947] RFC947: "Multi-network Broadcasting within the

Internet"

Ken Lebowitz

David Mankins

Junio 1.985

[RFC950] RFC950: "Internet Standard Subnetting Procedure"

J. Mogul

Jon Postel

Agosto 1.985

[RFC966] RFC966: "Host Groups: A Multicast Extension to the

Internet Protocol"

S. E. Deering

D. R. Cheriton

Diciembre 1.985

[RFC988] RFC988: "Host Extensions for IP Multicasting"

S. E. Deering

Julio 1.986

[RFC1108] RFC1108: "U.S. Department of Defense Security Options

for the Internet Protocol"

Stephen Kent

Noviembre 1.991

[RFC1112] RFC1112: "Host Extensions for IP Multicasting"

Steve Deering

Agosto 1.989

[RFC1191] RFC1191: "Path MTU Discovery"

Jeffrey Mogul

Steve Deering

Noviembre 1.990

[RFC1234] RFC1234: "Tunneling IPX Traffic through IP Networks"

Don Provan

Junio 1.991

[RFC1241] RFC1241: "A Scheme for an Internet Encapsulation

Protocol: Version 1"

Robert A. Woodburn

David L. Mills

Julio 1.991

[RFC1272] RFC1272: "INTERNET ACCOUNTING: BACKGROUND"

Cyndi Mills

Donald Hirsh

Gregory Ruth

Noviembre 1.991

[RFC1281] RFC1281: "Guidelines for the Secure Operation of the

Internet"

Richard D. Pethia

Stephen D. Crocker

Barbara Y. Fraser

Noviembre 1.991

[RFC1287] RFC1287: "Towards the Future Internet Architecture"

David D. Clark

Vinton G. Cerf

Lyman A. Chapin

Robert Braden

Russell Hobby

Diciembre 1.991

[RFC1335] RFC1335: "A Two-Tier Address Structure for the

Internet: A Solution to the Problem of Address Space

Exhaustion"

Zheng Wang

Jon Crowcroft

Mayo 1.992

[RFC1338] RFC1338: "Supernetting: an Address Assignment and

Aggregation Strategy"

Vince Fuller

Tony Li

Jessica (Jie Yun) Yu

Kannan Varadhan

Junio 1.992

[RFC1347] RFC1347: "TCP and UDP with Bigger Addresses (TUBA), A

Simple Proposal for Internet Addressing and Routing"

Ross Callon

Junio 1.992

[RFC1349] RFC1349: "Type of Service in the Internet Protocol

Suite"

Philip Almquist

Julio 1.992

[RFC1380] RFC1380: "IESG Deliberations on Routing and

Addressing"

Phillip Gross

Philip Almquist

Noviembre 1.992

[RFC1393] RFC1393: "Traceroute Using an IP Option"

Gary Scott Malkin

Enero 1.993

[RFC1435] RFC1435: "IESG Advice from Experience with Path MTU

Discovery"

Stev Knowles

Marzo 1.993

[RFC1454] RFC1454: "Comparison of Proposals for Next Version of

IP"

Tim Dixon

Mayo 1.993

[RFC1455] RFC1455: "Physical Link Security Type of Service"

Donald E. Eastlake, III

Mayo 1.993

[RFC1466] RFC1466: "Guidelines for Management of IP Address

Space"

Elise Gerich

Mayo 1.993

[RFC1467] RFC1467: "Status of CIDR Deployment in the Internet"

Claudio Topolcic

Agosto 1.993

[RFC1475] RFC1475: "TP/IX: The Next Internet"

Robert Ullmann

Junio 1.993

[RFC1481] RFC1481: "IAB Recommendation for an Intermediate

Strategy to Address the Issue of Scaling"

Christian Huitema

Julio 1.993

[RFC1517] RFC1517: "Applicability Statement for the

Implementation of Classless Inter-Domain Routing

(CIDR)"

Robert M. Hinden

Septiembre 1.993

[RFC1518] RFC1518: "An Architecture for IP Address Allocation

with CIDR"

Yakov Rekhter

Tony Li

Septiembre 1.993

[RFC1519] RFC1519: "Classless Inter-Domain Routing (CIDR): an

Address Assignment and Aggregation Strategy"

Vince Fuller

Tony Li

Septiembre 1.993

[RFC1520] RFC1520: "Exchanging Routing Information Across

Provider Boundaries in the CIDR Environment"

Yakov Rekhter

Claudio Topolcic

Septiembre 1.993

[RFC1526] RFC1526: "Assignment of System Identifiers for

TUBA/CLNP Hosts"

David M. Piscitello

Septiembre 1.993

[RFC1541] RFC1541: "Dynamic Host Configuration Protocol"

R. Droms

Octubre 1993

[RFC1546] RFC1546: "Host Anycasting Service"

Walter Milliken

Trevor Mendez

Craig Partridge

Noviembre 1.993

[RFC1550] RFC1550: "IP: Next Generation (IPng) White Paper

Solicitation"

Scott Bradner

Allison Mankin

Diciembre 1.993

[RFC1560] RFC1560: "The MultiProtocol Internet"

Dr. Barry M. Leiner

Yakov Rekhter

Diciembre 1.993

[RFC1597] RFC1597: "Address Allocation for Private Internets"

Yakov Rekhter

Robert G Moskowitz

Daniel Karrenberg

Geert Jan de Groot

Marzo 1.994

[RFC1621] RFC1621: "Pip Near-term Architecture"

Paul Francis

Mayo 1.994

[RFC1622] RFC1622: "Pip Header Processing"

Paul Francis

Mayo 1.994

[RFC1636] RFC1636: "Report of IAB Workshop on Security in the

Internet Architecture. February 8-10, 1994"

Bob Braden

David Clark

Steve Crocker

Christian Huitema

Junio 1.994

[RFC1639] RFC1639: "FTP Operation Over Big Address Records

(FOOBAR)"

David M. Piscitello

Junio 1.994

[RFC1667] RFC1667: "Modeling and Simulation Requirements for

IPng"

Susan Symington

David Wood

J. Mark Pullen

Agosto 1.994

[RFC1668] RFC1668: "Unified Routing Requirements for IPng"

Deborah Estrin

Tony Li

Yakov Rekhter

Agosto 1.994

[RFC1669] RFC1669: "Market Viability as a IPng Criteria"

John Curran

Agosto 1.994

[RFC1670] RFC1670: "Input to IPng Engineering Considerations"

Denise Heagerty

Agosto 1.994

[RFC1671] RFC1671: "IPng White Paper on Transition and Other

Considerations"

Brian E. Carpenter

Agosto 1.994

[RFC1672] RFC1672: "Accounting Requirements for IPng"

Nevil Brownlee

Agosto 1.994

[RFC1673] RFC1673: "Electric Power Research Institute Comments

on IPng"

Ron Skelton

Agosto 1.994

[RFC1674] RFC1674: "A Cellular Industry View of IPng"

Mark S. Taylor

Agosto 1.994

[RFC1675] RFC1675: "Security Concerns for IPng"

Steven M. Bellovin

Agosto 1.994

[RFC1676] RFC1676: "INFN Requirements for an IPng"

Davide Salomoni

Cristina Vistoli

Antonia Ghiselli

Agosto 1.994

[RFC1677] RFC1677: "Tactical Radio Frequency Communication

Requirments for IPng"

R. Brian Adamson

Agosto 1.994

[RFC1678] RFC1678: "IPng Requirements of Large Corporate

Networks"

Edward Britton

John Tavs

Agosto 1.994

[RFC1679] RFC1679: "HPN Working Group Input to the IPng

Requirements Solicitation"

Dan Green

Phil Irey

Dave Marlow

Karen O'Donoghue

Agosto 1.994

[RFC1680] RFC1680: "IPng Support for ATM Services"

Christina Brazdziunas

Agosto 1.994

[RFC1681] RFC1681: "On Many Addresses per Host"

Steven M. Bellovin

Agosto 1.994

[RFC1682] RFC1682: "IPng BSD Host Implementation Analysis"

Jim Bound

Agosto 1.994

[RFC1683] RFC1683: "Multiprotocol Interoperability In IPng"

Russell J. Clark

Mostafa H. Ammar

Kenneth L. Calvert

Agosto 1.994

[RFC1686] RFC1686: "IPng Requirements: A Cable Television

Industry Viewpoint"

Mario P. Vecchi

Agosto 1.994

[RFC1687] RFC1687: "A Large Corporate User's View of IPng"

Eric Fleischman

Agosto 1.994

[RFC1688] RFC1688: "IPng Mobility Considerations"

William Allen Simpson

Agosto 1.994

[RFC1701] RFC1701: "Generic Routing Encapsulation (GRE)"

Stan Hanks

Tony Li

Dino Farinacci

Paul Traina

Octubre 1.994

[RFC1705] RFC1705: "Six Virtual Inches to the Left: The Problem

with IPng"

Richard Carlson

Domenic Ficarella

Octubre 1.994

[RFC1707] RFC1707: "CATNIP: Common Architecture for the

Internet"

Michael McGovern

Robert Ullmann

Octubre 1.994

[RFC1710] RFC1710: "Simple Internet Protocol Plus White Paper"

Robert M. Hinden

Octubre 1.994

[RFC1719] RFC1719: "A Direction for IPng"

Phill Gross

Diciembre 1.994

[RFC1726] RFC1726: "Technical Criteria for Choosing IP The Next

Generation (IPng)"

Craig Partridge

Frank Kastenholz

Diciembre 1.994

[RFC1750] RFC1750: "Randomness Recommendations for Security"

Donald E. Eastlake 3rd

Stephen D. Crocker

Jeffrey I. Schiller

Diciembre 1.994

[RFC1752] RFC1752: "The Recommendation for the IP Next

Generation Protocol"

Scott Bradner

Allison Mankin

Enero 1.995

[RFC1753] RFC1753: "IPng Technical Requirements Of the Nimrod

Routing and Addressing Architecture"

J. Noel Chiappa

Enero 1.995

[RFC1797] RFC1797: "Class A Subnet Experiment"

Internet Assigned Numbers Authority (IANA)

Abril 1.995

[RFC1809] RFC1809: "Using the Flow Label Field in IPv6"

Craig Partridge

Junio 1.995

[RFC1817] RFC1817: "CIDR and Classful Routing"

Yakov Rekhter

Agosto 1.995

[RFC1825] RFC1825: "Security Architecture for the Internet

Protocol"

Randall Atkinson

Agosto 1.995

[RFC1826] RFC1826: "IP Authentication Header"

Randall Atkinson

Agosto 1.995

[RFC1827] RFC1827: "IP Encapsulating Security Payload (ESP)"

Randall Atkinson

Agosto 1.995

[RFC1828] RFC1828: "IP Authentication using Keyed MD5"

Perry Metzger

William Allen Simpson

Agosto 1.995

[RFC1829] RFC1829: "The ESP DES-CBC Transform"

Perry Metzger

William Allen Simpson

Agosto 1.995

[RFC1852] RFC1852: "IP Authentication using Keyed SHA"

Perry Metzger

William Allen Simpson

Septiembre 1.995

[RFC1853] RFC1853: "IP in IP Tunneling"

William Allen Simpson

Octubre 1.995

[RFC1878] RFC1878: "Variable Length Subnet Table For IPv4"

Troy T. Pummill

Bill Manning

Diciembre 1.995

[RFC1879] RFC1879: "Class A Subnet Experiment Results and

Recommendations"

Bill Manning

Enero 1.996

[RFC1881] RFC1881: "IPv6 Address Allocation Management"

Internet Architecture Board

Internet Engineering Steering Group

Diciembre 1.995

[RFC1883] RFC1883: "Internet Protocol, Version 6 (IPv6)

Specification"

Stephen E. Deering

Robert M. Hinden

Diciembre 1.995

[RFC1884] RFC1884: "IP Version 6 Addressing Architecture"

Robert M. Hinden

Stephen E. Deering

Diciembre 1.995

[RFC1885] RFC1885: "Internet Control Message Protocol (ICMPv6)

for the Internet Protocol Version 6 (IPv6)

Specification"

Stephen Deering

Alex Conta

Diciembre 1.995

[RFC1886] RFC1886: "DNS Extensions to support IP version 6"

Susan Thomson

Christian Huitema

Diciembre 1.995

[RFC1887] RFC1887: "An Architecture for IPv6 Unicast Address

Allocation"

Yakov Rekhter

Tony Li

Diciembre 1.995

[RFC1897] RFC1897: "IPv6 Testing Address Allocation"

Robert M. Hinden

Jon Postel

Enero 1.996

[RFC1917] RFC1917: "An Appeal to the Internet Community to

Return Unused IP Networks (Prefixes) to the IANA"

Philip J. Nesser II

Febrero 1.996

[RFC1924] RFC1924: "A Compact Representation of IPv6 Addresses"

Robert Elz

Abril 1.996

[RFC1933] RFC1933: "Transition Mechanisms for IPv6 Hosts and

Routers"

Robert E. Gilligan

Erik Nordmark

Abril 1.996