Beruflich Dokumente
Kultur Dokumente
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.
· 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.
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.
1
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
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
2
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:
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
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.
3
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:
ipv6 unicast−routing
3. Asigne el prefijo IPv6 que corresponda a cada interface Ethernet mediante el comando:
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
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.
Para añadir una entrada en las tablas de encaminamiento IPv6 de un CISCO se utiliza el comando
global ipv6 route. Por ejemplo:
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).
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.
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
5
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).
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:
# 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
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:
6
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
Es posible configurar los router CISCO para que utilicen encaminamiento dinámico mediante el
protocolo RIP
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
7
[DocAdic] Procedimiento de Arranque de PCs con Windows NT.
http://www.lab.dit.upm.es/~labrst/config/config.htm#nt
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
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).
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).
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.
8
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
DAD transmits 1
9
*** dirección IP. NO se utiliza en esta
*** práctica
DAD transmits 1
DAD transmits 0
link−level address:
10
preferred address ::1, infinite/infinite
DAD transmits 0
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.
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.
debug ipv6 *. Permite activar las trazas de depuración de IPv6. Teclear debug ipv6 ? para consultar
opciones.
Subred Prefijo
VLAN1 3ffe:3328:4:1::/64
VLAN2
3ffe:3328:4:2::/64
VLAN3
3ffe:3328:4:3::/64
VLAN4
11
3ffe:3328:4:4::/64
VLAN5
3ffe:3328:4:5::/64
VLAN6
3ffe:3328:4:6::/64
VLAN7
3ffe:3328:4:7::/64
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í.
12
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].
13
• 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
14
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
Jon Postel
Septiembre 1.981
Jon Postel
Septiembre 1.981
Jon Postel
Noviembre 1.981
Jeffrey Mogul
Octubre 1.984
Jeffrey Mogul
Octubre 1.994
15
[RFC922] RFC922: "BROADCASTING INTERNET DATAGRAMS IN THE
PRESENCE OF SUBNETS"
Jeffrey Mogul
Octubre 1.984
Jon Postel
Octubre 1.984
David D. Clark
Enero 1.985
Michael J. Karels
Febrero 1.985
Subnetting"
Force
Abril 1.985
Internet"
Ken Lebowitz
David Mankins
Junio 1.985
J. Mogul
Jon Postel
16
Agosto 1.985
Internet Protocol"
S. E. Deering
D. R. Cheriton
Diciembre 1.985
S. E. Deering
Julio 1.986
Stephen Kent
Noviembre 1.991
Steve Deering
Agosto 1.989
Jeffrey Mogul
Steve Deering
Noviembre 1.990
Don Provan
Junio 1.991
Robert A. Woodburn
17
David L. Mills
Julio 1.991
Cyndi Mills
Donald Hirsh
Gregory Ruth
Noviembre 1.991
Internet"
Richard D. Pethia
Stephen D. Crocker
Barbara Y. Fraser
Noviembre 1.991
David D. Clark
Vinton G. Cerf
Lyman A. Chapin
Robert Braden
Russell Hobby
Diciembre 1.991
Exhaustion"
Zheng Wang
Jon Crowcroft
Mayo 1.992
18
[RFC1338] RFC1338: "Supernetting: an Address Assignment and
Aggregation Strategy"
Vince Fuller
Tony Li
Kannan Varadhan
Junio 1.992
Ross Callon
Junio 1.992
Suite"
Philip Almquist
Julio 1.992
Addressing"
Phillip Gross
Philip Almquist
Noviembre 1.992
Enero 1.993
Discovery"
Stev Knowles
19
Marzo 1.993
IP"
Tim Dixon
Mayo 1.993
Mayo 1.993
Space"
Elise Gerich
Mayo 1.993
Claudio Topolcic
Agosto 1.993
Robert Ullmann
Junio 1.993
Christian Huitema
Julio 1.993
(CIDR)"
Robert M. Hinden
20
Septiembre 1.993
with CIDR"
Yakov Rekhter
Tony Li
Septiembre 1.993
Vince Fuller
Tony Li
Septiembre 1.993
Yakov Rekhter
Claudio Topolcic
Septiembre 1.993
TUBA/CLNP Hosts"
David M. Piscitello
Septiembre 1.993
R. Droms
Octubre 1993
Walter Milliken
Trevor Mendez
21
Craig Partridge
Noviembre 1.993
Solicitation"
Scott Bradner
Allison Mankin
Diciembre 1.993
Yakov Rekhter
Diciembre 1.993
Yakov Rekhter
Robert G Moskowitz
Daniel Karrenberg
Marzo 1.994
Paul Francis
Mayo 1.994
Paul Francis
Mayo 1.994
Bob Braden
22
David Clark
Steve Crocker
Christian Huitema
Junio 1.994
(FOOBAR)"
David M. Piscitello
Junio 1.994
IPng"
Susan Symington
David Wood
J. Mark Pullen
Agosto 1.994
Deborah Estrin
Tony Li
Yakov Rekhter
Agosto 1.994
John Curran
Agosto 1.994
Denise Heagerty
Agosto 1.994
23
Considerations"
Brian E. Carpenter
Agosto 1.994
Nevil Brownlee
Agosto 1.994
on IPng"
Ron Skelton
Agosto 1.994
Mark S. Taylor
Agosto 1.994
Steven M. Bellovin
Agosto 1.994
Davide Salomoni
Cristina Vistoli
Antonia Ghiselli
Agosto 1.994
R. Brian Adamson
Agosto 1.994
24
Networks"
Edward Britton
John Tavs
Agosto 1.994
Requirements Solicitation"
Dan Green
Phil Irey
Dave Marlow
Karen O'Donoghue
Agosto 1.994
Christina Brazdziunas
Agosto 1.994
Steven M. Bellovin
Agosto 1.994
Jim Bound
Agosto 1.994
Russell J. Clark
Mostafa H. Ammar
Kenneth L. Calvert
Agosto 1.994
25
Industry Viewpoint"
Mario P. Vecchi
Agosto 1.994
Eric Fleischman
Agosto 1.994
Agosto 1.994
Stan Hanks
Tony Li
Dino Farinacci
Paul Traina
Octubre 1.994
with IPng"
Richard Carlson
Domenic Ficarella
Octubre 1.994
Internet"
Michael McGovern
Robert Ullmann
Octubre 1.994
26
Robert M. Hinden
Octubre 1.994
Phill Gross
Diciembre 1.994
Generation (IPng)"
Craig Partridge
Frank Kastenholz
Diciembre 1.994
Stephen D. Crocker
Jeffrey I. Schiller
Diciembre 1.994
Generation Protocol"
Scott Bradner
Allison Mankin
Enero 1.995
J. Noel Chiappa
Enero 1.995
27
Abril 1.995
Craig Partridge
Junio 1.995
Yakov Rekhter
Agosto 1.995
Protocol"
Randall Atkinson
Agosto 1.995
Randall Atkinson
Agosto 1.995
Randall Atkinson
Agosto 1.995
Perry Metzger
Agosto 1.995
Perry Metzger
Agosto 1.995
28
Perry Metzger
Septiembre 1.995
Octubre 1.995
Troy T. Pummill
Bill Manning
Diciembre 1.995
Recommendations"
Bill Manning
Enero 1.996
Diciembre 1.995
Specification"
Stephen E. Deering
Robert M. Hinden
Diciembre 1.995
Robert M. Hinden
Stephen E. Deering
29
Diciembre 1.995
Specification"
Stephen Deering
Alex Conta
Diciembre 1.995
Susan Thomson
Christian Huitema
Diciembre 1.995
Allocation"
Yakov Rekhter
Tony Li
Diciembre 1.995
Robert M. Hinden
Jon Postel
Enero 1.996
Philip J. Nesser II
Febrero 1.996
Robert Elz
30
Abril 1.996
Routers"
Robert E. Gilligan
Erik Nordmark
Abril 1.996
31