7 EL NIVEL DE RED EN INTERNET

La Internet es un compendio de redes diferentes que comparten una pila de protocolos comunes. Cada una de estas redes es administrada por una entidad diferente: universidades, redes académicas nacionales, proveedores comerciales también llamados ISPs (Internet Service Providers), operadores, empresas multinacionales, etc. Como consecuencia de esto las políticas de uso son muy variadas.

Técnicamente a nivel de red la Internet puede definirse como un conjunto de redes o sistemas autónomos [1] conectados entre sí que utilizan el protocolo de red IP.

IP es una red de datagramas, no orientada a conexión, con servicio 'best effort', es decir no ofrece calidad de servicio o QoS (Quality of Service)[2]. La entrega de los paquetes no está garantizada ya que en momentos de congestión éstos pueden ser descartados sin previo aviso por los routers que se encuentren en el trayecto.

7.2 EL DATAGRAMA IP

En una red IP absolutamente toda la información viaja en datagramas IP. Esto incluye tanto la intercambiada a nivel de transporte por TCP y UDP como cualquier información de control que tenga que intercambiarse, por ejemplo para routing dinámico, mensajes de error, etc.

El datagrama IP tiene dos partes: cabecera y texto; la cabecera tiene una parte fija de 20 bytes y una opcional de entre 0 y 40 bytes. La longitud total de la cabecera siempre es múltiplo de 4; esto garantiza un proceso eficiente por parte de equipos (hosts o routers) cuya arquitectura optimiza el acceso a direcciones de memoria que estén en frontera de 32 bits. La estructura de la cabecera IP es la que se muestra en la tabla 3.1.

Campo	Longitud (bits)
Versión	4
IHL (Internet Header Length)	4
DS (Differentiated Services)	8
Longitud total	16
Identificación	16
Reservado	1
DF (Don't Fragment)	1
MF (More Fragments)	1
Fragment offset	13
TTL (Time To Live)	8
Protocolo (de transporte)	8
Checksum (de cabecera)	16
Dirección de origen	32
Dirección de destino	32
Opciones	0-320

Tabla 3.1.- Estructura de la cabecera de un datagrama IP

El campo versión permite que coexistan en la misma red sin ambigüedad paquetes de distintas versiones de IP; la versión actualmente utilizada (que corrresponde a la estructura de datagrama que estamos viendo) es la 4. Como veremos mas tarde, se empieza a extender el uso de una nueva versión (la 6) con una estructura de datagrama diferente.

El campo IHL especifica la longitud de la cabecera, ya que ésta puede variar debido a la presencia de campos opcionales. Se especifica en palabras de 32 bits. La longitud mínima es 5 y la máxima 15, que equivale a 40 bytes de información opcional. La longitud de la cabecera siempre ha de ser un número entero de palabras de 32 bits, por lo que si la longitud de los campos opcionales no es un múltiplo exacto de 32 bits se añade un relleno al final de la cabecera.

El campo Differentiated Services ha sustituido recientemente al antes denominado tipo de servicio. Su finalidad es implementar Calidad de Servicio en redes IP mediante la arquitectura denominada Servicios Diferenciados o Diffserv. La descripción de este campo y su funcionamiento la haremos más adelante al hablar de Calidad de Servicio.

El campo longitud total especifica la longitud del datagrama completo (cabecera incluida) en bytes. El valor máximo es 65535 bytes. Este campo sirve para saber donde termina el datagrama información que es realmente necesaria sólo en muy pocos casos, ya que en la mayoría de situaciones puede deducirse a partir de la información que posee el nivel de enlace. Por ejemplo en PPP, ATM o LANs no Ethernet el nivel de enlace sabe o puede deducir fácilmente la longitud del datagrama; el único caso en Ethernet donde es preciso indicar la longitud del datagrama es cuando se utiliza encapsulado DIX (donde el campo longitud se ha reemplazado por el campo Ethertype) y se envía una trama que no llega a 64 bytes; en este caso la trama contendrá relleno y la única forma de averiguar donde empieza éste es a partir de la longitud total indicada en la cabecera IP.

Los cuatro campos siguientes (Identificación, DF, MF y Fragment Offset) están relacionados con la fragmentación de datagramas que explicaremos más adelante.

El campo TTL (Time To Live) sirve para descartar un datagrama cuando ha dado un número excesivo de saltos o ha pasado un tiempo excesivo viajando por la red y es presumiblemente inútil. Se trata de un contador regresivo que indica el tiempo de vida restante del datagrama medido en segundos, de forma que si llega a valer cero el datagrama debe ser descartado. Además cada router por el que pasa dicho datagrama está obligado a restar uno del TTL, independientemente del tiempo que tarde en reenviarlo. Esto evita que por algún problema en las rutas se produzcan bucles y un datagrama permanezca 'flotando' indefinidamente en la red. Para medir el tiempo que un datagrama emplea en pasar de un router a otro sería preciso que los relojes de ambos estuvieran sincronizados; como esto no siempre ocurre en la práctica el tiempo en tránsito se ignora y el TTL se convierte simplemente en un contador de saltos; en muchas implementaciones ni siquiera cuando el datagrama esta mas de un segundo esperando en un router se disminuye por ello el valor del TTL, aunque esto ocurre raramente. En el caso particular de producirse fragmentación el host receptor sí puede retener datagramas durante varios segundos, mientras espera a recibir todos los fragmentos; en este caso el host sí disminuirá el valor del TTL en uno por cada segundo de espera, pudiendo llegar a descartar datagramas por este motivo, como veremos más adelante. Es habitual utilizar para el TTL los valores 64 o 255. El comando de prueba ping permite fijar el valor inicial del TTL en los datagramas de prueba enviados; por ejemplo en los sistemas operativos windows se utiliza para este fin la opción –i del comando ping.

El campo protocolo especifica a que protocolo del nivel de transporte corresponde el datagrama. La tabla de protocolos válidos y sus correspondientes números son controlados por el IANA (Internet Assigned Number Authority) y pueden consultarse en su web, www.iana.org/numbers.html. La tabla 3.2 muestra a título de ejemplo algunos de los posibles valores de este campo.

Valor	Protocolo	Descripción
0		Reservado
1	ICMP	Internet Control Message Protocol
2	IGMP	Internet Group Management Protocol
3	GGP	Gateway-to-Gateway Protocol
4	IP	IP en IP (encapsulado)
5	ST	Stream
6	TCP	Transmission Control Protocol
8	EGP	Exterior Gateway Protocol
17	UDP	User Datagram Protocol
29	ISO-TP4	ISO Transport Protocol Clase 4
38	IDRP-CMTP	IDRP Control Message Transport Protocol
80	ISO-IP	ISO Internet Protocol (CLNP)
88	IGRP	Interior Gateway Routing Protocol (Cisco)
89	OSPF	Open Shortest Path First
255		Reservado

Tabla 3.2.- Ejemplo de valores y significados del campo protocolo en un datagrama

Merece la pena llamar la atención sobre el valor 4 del campo protocolo, que está reservado para el uso de IP para transportar IP, es decir al encapsulado de un datagrama IP dentro de otro. Esta técnica permite realizar un encaminamiento desde el origen de los paquetes encapsulando el datagrama en otro dirigido al nodo intermedio por el que queremos pasar. Esto es como si para enviar una carta a Sevilla vía Madrid metiéramos el sobre dirigido a Sevilla en otro que lleve una dirección de Madrid; la carta llegaría a Madrid y de allí se enviaría a Sevilla.

El campo checksum sirve para detectar errores producidos en la cabecera del datagrama; no es un CRC sino el complemento a uno en 16 bits de la suma complemento a uno de toda la cabecera tomada en campos de 16 bits (incluidos los campos opcionales si los hay). Para el cálculo el campo checksum se pone a sí mismo a ceros. El checksum permite salvaguardar al datagrama de una alteración en alguno de los campos de la cabecera que pudiera producirse por ejemplo por un problema hardware en un router. Obsérvese que el checksum solo cubre la cabecera del datagrama, no los datos. El campo checksum se ha de recalcular en cada salto, ya que al menos el TTL cambia. En routers con mucho tráfico el recálculo del checksum supone un inconveniente desde el punto de vista de rendimiento.

Los campos dirección de origen y dirección de destino corresponden a direcciones IP de cuatro bytes según el formato que veremos luego.

Los campos opcionales de la cabecera no siempre están soportados en los routers y se utilizan muy raramente. Cada campo opcional está compuesto por una etiqueta, seguida opcionalmente de información adicional. Los más importantes son los siguientes:

Record route (registrar la ruta): Esta opción solicita a los routers por los que pasa que anoten su dirección en la cabecera del datagrama, con lo que al final del trayecto se dispone de una traza de la ruta seguida para fines de prueba o diagnóstico de problemas. Esto es como si cada router estampara su sello en el datagrama antes de reenviarlo. El máximo de direcciones que puede registrarse es de 9, ya que si se registraran 10 se ocuparían los 40 bytes de opciones y no quedaría sitio para la propia opción record route. El comando de prueba ping permite solicitar el uso de este campo para registrar la ruta; por ejemplo en los sistemas operativos windows se utiliza para este fin la opción –r del comando ping.

Timestamp (marca de tiempos): esta opción actúa de manera similar a record route, pero el router en lugar de anotar su dirección anota el instante (tiempo desde la medianoche en milisegundos) en el que el datagrama pasa por él; es un campo entero de 32 bits. También puede acompañarse el timestamp de la dirección IP del router; en este caso cada anotación ocupa ocho bytes y solo pueden producirse cuatro ya que la quinta superaría el tamaño máximo del campo opciones (la propia indicación de que se trata de un campo timestamp ya ocupa cuatro bytes). El comando de prueba ping permite solicitar el uso de este campo para registrar la ruta y hora; por ejemplo en los sistemas operativos windows se utiliza para este fin la opción -s del comando ping.

Source routing (encaminamiento desde el origen): permite al emisor especificar la ruta que debe seguir el datagrama hasta llegar a su destino. Existen dos variantes: strict source routing (encaminamiento estricto desde el origen) especifica la ruta exacta salto a salto, de modo que si en algún caso la ruta marcada no es factible se producirá un error (una ruta no es factible cuando el router siguiente en la secuencia no es accesible directamente, es decir a nivel de enlace, desde el router actual). El funcionamiento de esta opción es equivalente al de los puentes con encaminamiento desde el origen. La opción loose source routing (encaminamiento aproximado desde el origen) indica una serie de routers por los que debe pasar un datagrama, pero deja la posibilidad de pasar por otros no especificados para llegar al siguiente router marcado en la secuencia. La limitación en la longitud de las opciones impone también aquí un límite máximo en el número de saltos que pueden especificarse en estas opciones, por lo que a menudo se utiliza en su lugar la técnica antes descrita de encapsulado IP en IP. Ambas variantes actúan también como record route, pues la secuencia no se va borrando a medida que se utiliza con lo que al final del trayecto el campo opciones contiene la ruta que se ha utilizado. El comando de prueba ping permite solicitar el uso de estos campo para especificar la ruta; por ejemplo en los sistemas operativos windows se utilizan las opciones –j y –k para indicar loose source routing y strict source routing, respectivamente.

El uso de los campos opcionales de la cabecera IP tiene generalmente problemas de rendimiento, ya que las implementaciones de los routers optimizan el código para las situaciones normales, es decir para datagramas sin campos opcionales. Aun en el caso de que las opciones estén implementadas lo harán generalmente de forma poco eficiente, ya que en el diseño del equipo no se ha hecho énfasis en su optimización. Por tanto solo deben utilizarse en situaciones de prueba o diagnóstico de errores, nunca en entornos en producción.

7.2.1 Fragmentación

El tamaño de un datagrama IP se especifica en un campo de dos bytes en la cabecera, por lo que su valor máximo es de 65535 bytes, pero muy pocos protocolos o tecnologías a nivel de enlace admiten enviar tramas de semejante tamaño. Normalmente el nivel de enlace no fragmenta [3], por lo que tendrá que ser IP el que adapte el tamaño de los datagramas para que quepan en las tramas del nivel de enlace; por tanto en la práctica el tamaño máximo del datagrama viene determinado por el tamaño máximo de trama característico de la red utilizada. Este tamaño máximo de datagrama se conoce como MTU (Maximum Transfer Unit). La tabla 3.3 muestra algunos ejemplos de valores de MTU característicos de las redes más habituales.

Protocolo a nivel de enlace	MTU (bytes)
PPP (valor por defecto)	1500
PPP (bajo retardo)	296
SLIP	1006 (límite original)
X.25	1600 (RFC 1356)
Frame relay	1600 normalmente (depende de la red)
SMDS	9235
Ethernet DIX	1500
Ethernet LLC-SNAP	1492
IEEE 802.4/802.2	8166
Token Ring 16 Mb/s	17940 (token holding time 8 ms)
Token Ring 4 Mb/s	4440 (token holding time 8 ms)
FDDI	4352
Hyperchannel	65535
Classical IP over ATM	9180

Tabla 3.3.- Valor de MTU para los protocolos más comunes a nivel de enlace.

Podemos distinguir dos situaciones en las que se produce fragmentación. La primera, que podemos denominar fragmentación en ruta, se produce cuando un datagrama es creado por un host en una red con un valor determinado de MTU y en su camino hacia el host de destino ha de pasar por otra red con una MTU menor. Por ejemplo un datagrama creado en una Token Ring con MTU de 4440 bytes dirigido a una Ethernet con MTU de 1500 bytes. En estos casos el router que hace la transición a la red de MTU menor ha de fragmentar los datagramas para que no excedan el tamaño de la nueva red.

La segunda, que podemos llamar fragmentación en origen, se produce como consecuencia del diseño de la aplicación. Por ejemplo muchas implementaciones de NFS generan datagramas de 8 Kbytes de datos (8212 bytes con la cabecera IP). Un host en una red Ethernet que utilice NFS tendrá que fragmentar cada datagrama en seis fragmentos antes de enviarlo, aun cuando el host de origen y destino se encuentren ambos en el mismo concentrador de Ethernet. Como podemos ver en la tabla 3.3 solo una minoría de las redes existente soporta datagramas NFS sin fragmentar.

Existe una fuerte polémica sobre la conveniencia de que realice la fragmentación en ruta, ya que esto perjudica seriamente la eficiencia de los routers por la carga de CPU que supone y la de la red ya que la probabilidad de perder algún framento es mayor y en ese caso es preciso reenviar todos los fragmentos. En general se considera preferible realizar la fragmentación en origen siempre que esto sea posible. Una forma fácil de conseguirlo es utilizar un MTU de 1500, valor que es soportado por la mayoría de las redes existentes, con lo que se minimizan los casos en que los routers han de recurrir a la fragmentación. Otra forma de evitar la fragmentación es emplear la técnica de descubrimiento de la MTU del trayecto que describiremos más tarde.

La fragmentación se hace cortando la parte de datos del datagrama en trozos tales que cada fragmento con su cabecera quepa en la MTU de la nueva red (redondeado por abajo para que la cantidad de datos sea múltiplo de ocho bytes ). Todos los campos de la cabecera del datagrama original se replican en los fragmentos excepto aquellos que se emplean para distinguir los fragmentos y que describiremos a continuación. Una vez fragmentado un datagrama no se reensambla hasta que llegue al host de destino, aun cuando en el trayecto pase a redes que admitan una MTU mayor. Los estándares Internet recomiendan que todas las redes que soporten TCP/IP tengan una MTU de al menos 576 bytes y esta condición la cumplen la mayoría de las redes, aunque no todas. La MTU mínima imprescindible para funcionar en TCP/IP es de 68 bytes, valor que corresponde a 60 bytes de cabecera (el máximo con todos los campos opcionales) y 8 bytes de datos, que es el fragmento mínimo de datos que puede hacerse.

El campo Identificación de la cabecera IP lo usa el emisor para marcar en origen cada datagrama emitido; de esta forma en caso de que se produzca fragmentación el receptor podrá reconocer las partes que corresponden al mismo datagrama original, ya que todas irán acompañadas de la misma identificación.

El bit DF (Don't Fragment) cuando está a 1 indica a los routers que este datagrama no debe fragmentarse. Normalmente esto se hace por uno de los dos motivos siguientes:

a) El receptor no está capacitado para reensamblar los fragmentos. Por ejemplo cuando un ordenador arranca su sistema operativo a través de la red normalmente el software que tiene para iniciar el proceso es muy sencillo y no soporta el reensamblado. En este caso el ordenador solicitará que el ejecutable correspondiente se le envíe como un único datagrama. Evidentemente para que esto sea posible será necesario que el trayecto completo por el que ha de transitar ese datagrama soporte el tamaño de MTU correspondiente.

b) Cuando se aplica la técnica de descubrimiento de la MTU del trayecto o ‘path MTU discovery’ para averiguar la MTU de una ruta. Esta técnica consiste en que el host de origen envía un datagrama del tamaño máximo al host de destino con el bit DF puesto; si el datagrama no puede pasar en algún punto del trayecto el router correspondiente genera un mensaje de error que es devuelto al host emisor; entonces este envía otro datagrama mas pequeño, también con el bit DF a 1 y así sucesivamente, hasta que consigue que algún datagrama pase sin fragmentar al host de destino; tanteando de esta forma consigue averiguar cual es la máxima MTU de la ruta y a partir de ahí utiliza este como valor máximo para todos los datagramas [4]. Para acelerar el proceso de tanteo algunos routers incorporan en los mensajes de error información sobre la MTU máxima que puede admitir la red que ha provocado el rechazo.

El comando de prueba ping permite especificar la no fragmentación. Por ejemplo en los sistemas operativos windows se utiliza para este fin la opción –f. Esto combinado con la especificación de un dterminado tamaño de paquete (opción –l en windows) permite hacer sondeos manuales de la MTU de un trayecto, lo cual resulta muy útil en la resolución de problemas o en pruebas de rendimiento.

El bit MF (More Fragments) puesto a 1 especifica que este datagrama es realmente un fragmento de un datagrama mayor, y que no es el último. Si está a 0 indica que este es el último fragmento o bien que el datagrama no ha sido fragmentado.

El campo Fragment offset sirve para indicar, en el caso de que el datagrama sea un fragmento, en que posición del datagrama original se sitúan los datos que contiene. Los cortes siempre se realizan en múltiplo de 8 bytes, que es la unidad elemental de fragmentación, por lo que el Fragment offset cuenta los bytes en grupos de 8. Gracias a eso este contador requiere únicamente 13 bits en vez de los 16 que harían falta si contara bytes (2¹³=8192, 8192 x 8 = 65536). De los tres bits que se ganan dos se utilizan en los flags DF y MF y el tercero no se utiliza.

Los fragmentos de un datagrama pueden llegar desordenados a su destino; el receptor podrá identificarlos gracias al campo Identificación. La longitud total del datagrama puede calcularla cuando recibe el último fragmento (identificado por el bit MF a 0) a partir de los campos Longitud y Fragment offset; la longitud será fragment_offset*8 + longitud.

Cuando se fragmenta un datagrama el host receptor retiene en su buffer los fragmentos y los reensambla cuando los ha recibido todos. Mientras mantiene retenido un fragmento el host va restando cada segundo una unidad al campo TTL. Cuando el valor de TTL es igual a cero descarta el fragmento. Si alguno de los fragmentos de un datagrama se pierde el resto terminarán desapareciendo a medida que agoten su TTL. No existe ningún mecanismo en IP que contemple el reenvío de datagramas o de fragmentos. Si el protocolo utilizado a nivel superior contempla reenvío de paquetes perdidos (por ejemplo TCP a nivel de transporte) se provocará el reenvío del datagrama correspondiente. Normalmente el segundo envío se verá sometido a la misma fragmentación que el primero, pero el segundo no podrá en ningún caso aprovechar fragmentos residuales que pudiera haber en el host receptor correspondientes al primer envío, ya que desde el punto de vista del nivel IP se trata de dos datagramas distintos e independientes que reciben identificaciones diferentes.

Veamos un ejemplo de cómo se produciría la fragmentación en ruta de un datagrama. Supongamos que generamos en una red Token Ring un datagrama de 4000 bytes de datos (es decir 4000 bytes más la cabecera IP) que ha de pasar por una red Ethernet DIX (MTU de 1500 bytes); el resultado de la fragmentación será el siguiente:

	Campos de cabecera en datagrama IP					Datos

Datagrama Original	Id = X	L = 4020	DF = 0	MF = 0	Offset = 0	ABCDEF GHIJKL MNOP

Fragmento 1	Id = X	L = 1500	DF = 0	MF = 1	Offset = 0	ABCDEF
Fragmento 2	Id = X	L = 1500	DF = 0	MF = 1	Offset = 185	GHIJKL
Fragmento 3	Id = X	L = 1060	DF = 0	MF = 0	Offset = 370	MNOP

El primer y segundo fragmentos contendrán 1480 bytes de datos y 20 de cabecera; el tercero tendrá 1040 de datos y 20 de cabecera.

Puede suceder que un datagrama que ha sido fragmentado en un punto determinado de la ruta tenga que ser fragmentado de nuevo más tarde porque pase a otra red de MTU aun menor. Supongamos que los fragmentos 2 y 3 anteriores pasan después por una red PPP con bajo retardo (MTU de 296 bytes); el resultado será el siguiente:

	Campos de cabecera en datagrama IP					Datos

Fragmento 2	Id = X	L = 1500	DF = 0	MF = 1	Offset = 185	GHIJKL

Fragmento 2a	Id = X	L = 292	DF = 0	MF = 1	Offset = 185	G
Fragmento 2b	Id = X	L = 292	DF = 0	MF = 1	Offset = 219	H
Fragmento 2c	Id = X	L = 292	DF = 0	MF = 1	Offset = 253	I
Fragmento 2d	Id = X	L = 292	DF = 0	MF = 1	Offset = 287	J
Fragmento 2e	Id = X	L = 292	DF = 0	MF = 1	Offset = 321	K
Fragmento 2f	Id = X	L = 140	DF = 0	MF = 1	Offset = 355	L

	Campos de cabecera en datagrama IP					Datos

Fragmento 3	Id = X	L = 1060	DF = 0	MF = 0	Offset = 370	MNOP

Fragmento 3a	Id = X	L = 292	DF = 0	MF = 1	Offset = 370	M
Fragmento 3b	Id = X	L = 292	DF = 0	MF = 1	Offset = 404	N
Fragmento 3c	Id = X	L = 292	DF = 0	MF = 1	Offset = 438	O
Fragmento 3d	Id = X	L = 244	DF = 0	MF = 0	Offset = 472	P

Aquí cada fragmento (excepto el último de cada grupo) lleva 272 bytes de datos y 20 de cabecera. Aunque la MTU posible es de 296 bytes los datagramas generados son de 292 bytes porque la parte de datos de los fragmentos siempre debe ser múltiplo de 8 bytes. Obsérvese que después de una fragmentación múltiple solo el último fragmento del último grupo (el 3d en nuestro ejemplo) tiene puesto a 0 el bit MF.

Es interesante analizar el comportamiento de los campos opcionales cuando se realiza fragmentación. Por ejemplo el campo opcional Strict Source Route se replica en todos los fragmentos ya que de lo contrario no puede asegurarse que todos vayan por la ruta indicada. Lo mismo ocurre con el campo Loose Source Routing. En el caso de los campos Record Route y Timestamp los campos opcionales solo se copian en el primer fragmento, lo cual supone que los demás pueden ir por otras rutas; pero se supone que en estas opciones no se quiere obligar a utilizar un trayecto determinado, sino simplemente se pretende obtener información sobre la ruta utilizada; en estas condiciones se ha considerado razonable suministrar únicamente la información relativa al primer fragmento de la secuencia, evitando así el costo que supondría ejecutar la opción para cada fragmento, lo cual en la mayoría de los casos daría solo información redundante.

7.3 DIRECCIONES IP

Cada interfaz de red de cada nodo (host o router) en una red IP se identifica mediante al menos una dirección única de 32 bits. Las direcciones IP se suelen representar por cuatro números decimales separados por puntos, que equivalen al valor de cada uno de los cuatro bytes que componen la dirección. Por ejemplo una dirección IP válida sería 147.156.23.208.

Si un nodo dispone de varias interfaces físicas (cosa habitual en los routers) cada una de ellas deberá tener necesariamente una dirección IP distinta si se desea que sea accesible de forma diferenciada para este protocolo. Es posible también y en algunas situaciones resulta útil, definir varias direcciones IP asociadas a una misma interfaz física.

Como ocurre en la mayoría de las redes las direcciones IP tienen una estructura jerárquica. Una parte de la dirección corresponde a la red, y la otra al host dentro de la red. Cuando un router recibe un datagrama por una de sus interfaces compara la parte de red de la dirección con las entradas contenidas en sus tablas (que normalmente sólo contienen direcciones de red, no de host) y envía el datagrama por la interfaz correspondiente.

En el diseño inicial de la Internet se reservaron los ocho primeros bits para la red, dejando los 24 restantes para el host; se creía que con 254 redes habría suficiente para la red experimental de un proyecto de investigación del Departamento de Defensa americano. Pronto se vio que esto resultaba insuficiente, por lo que se reorganizó el espacio de direcciones reservando unos rangos para definir redes más pequeñas. El resultado de esa reorganización es lo que hoy conocemos como las redes clase A, B y C:

o Una red de clase A se caracteriza por tener a 0 el primer bit de dirección; el campo red ocupa los 7 bits siguientes y el campo host los últimos 24. Puede haber hasta 128 redes de clase A con 16777216 direcciones cada una.

o Una red de clase B tiene el primer bit a 1 y el segundo a 0; el campo red ocupa los 14 bits siguientes, y el campo host los 16 últimos. Puede haber 16384 redes clase B con 65536 direcciones cada una.

o Una red clase C tiene los primeros tres bits a 110; el campo red ocupa los siguientes 21 bits, y el campo host los 8 últimos. Puede haber hasta 2097152 redes clase C con 256 direcciones cada una.

Para indicar qué parte de la dirección corrresponde a la red y qué parte al host se suele utilizar una notación denominada máscara, consistente en poner a 1 los bits que corresponden a la parte de red y a 0 los que corresponden a la parte host. Así por ejemplo diremos que una red clase A tiene una máscara 255.0.0.0, lo cual equivale a decir que los ocho primeros bits especifican la red y los 24 restantes el host. Análogamente decimos que una red clase B tiene una máscara 255.255.0.0 y una clase C una máscara 255.255.255.0.

Las máscaras permiten extraer de forma sencilla la parte de red o de host de una dirección. Por ejemplo un router que ha de enviar un datagrama puede realizar un AND entre la dirección de destino y la máscara correspondiente, con lo que extraerá la parte de red de la dirección.

Existen además direcciones (no redes) clase D cuyos primeros cuatro bits valen 1110. Las direcciones clase D se utilizan para definir grupos multicast. El grupo queda definido por los 28 bits siguientes. Puede haber hasta 268435456 direcciones multicast en Internet. Las direcciones clase D nunca puede aparecer como direcciones de origen de un datagrama.

Por último, la clase E, que corresponde al valor 1111 en los primeros cuatro bits, no se utiliza de momento y está reservada para usos futuros.

De los valores de los primeros bits de cada una de las clases antes mencionadas se puede deducir el rango de direcciones que corresponde a cada una de ellas. Así pues, en la práctica es fácil saber a que clase pertenece una dirección determinada sin más que observar el primer byte de su dirección. La tabla 3.4 resume la información esencial sobre las clases de redes de Internet.

Clase	Primerosbits	Bits red/host	Núm. Redes	Núm. Direcc.	Máscara	Rango de direcciones
A	0---	7/24	128	16777216	255.0.0.0	0.0.0.0 - 127.255.255.255
B	10--	14/16	16384	65536	255.255.0.0	128.0.0.0 -191.255.255.255
C	110-	21/8	2097152	256	255.255.255.0	192.0.0.0 -223.255.255.255
D	1110			268435456		224.0.0.0 -239.255.255.255
E	1111					240.0.0.0 -255.255.255.255

Tabla 3.4 - Clases de direcciones Internet y sus principales características

La asignación de direcciones válidas de Internet la realizan los NICs (NIC = Network Information Center). Al principio había un NIC para toda la Internet pero luego se crearon NICs regionales. Actualmente existen los tres siguientes:

América: www.internic.net
Europa: www.ripe.net
Asia y Pacífico: www.apnic.net

Estos NICs asignan direcciones IP a los proveedores de Internet y a las grandes organizaciones. Los proveedores a su vez asignan direcciones a las organizaciones de menor tamaño y a sus usuarios.

Existen unas reglas y convenios que asignan significados especiales a determinadas direcciones IP que es importante conocer:

1. La dirección 255.255.255.255 se utiliza para indicar broadcast en la propia red. La utilizaría por ejemplo como dirección de destino un host que está arrancando en una red local y que para averiguar la red en la que se encuentra y su propia dirección IP necesita localizar un servidor que le de los parámetros de configuración básicos. Solo se puede utilizar como dirección de destino, nunca como dirección de origen.

2. La dirección 0.0.0.0 identifica al host actual. La utilizaría el host del supuesto anterior como dirección de origen de sus datagramas. Solo se puede utilizar como dirección de origen, no de destino.

3. Las direcciones con el campo host todo a ceros identifican redes y por tanto no se utilizan para ningún host. Se emplean para especificar rutas y nunca deberían aparecer somo direcciones de origen o destino de un datagrama. Por ejemplo la dirección 147.156.0.0 identifica la red clase B que pertenece a la Universidad de Valencia.

4. La dirección con el campo host todo a unos se utiliza como dirección broadcast dentro de la red y por tanto no se utiliza para ningún host. Solo puede ser una dirección de destino. Por ejemplo para enviar un mensaje broadcast a la red de la Universidad de Valencia utilizaríamos la dirección 147.156.255.255.

5. La dirección con el campo red todo a ceros identifica a un host en la propia red, cualquiera que esta sea. Solo puede utilizarse como dirección de origen al enviar un paquete, nunca como dirección de destino.

6. La dirección 127.0.0.1 se utiliza para pruebas loopback; todas las implementaciones de IP devuelven a la dirección de origen los datagramas enviados a esta dirección sin intentar enviarlos a ninguna parte [5].

7. Las redes 127.0.0.0, 128.0.0.0, 191.255.0.0, 192.0.0.0 y el rango de 240.0.0.0 en adelante (clase E) están reservados y no deben utilizarse.

8. Las redes 10.0.0.0 (clase A), 172.16.0.0 a 172.31.0.0 (clase B) y 192.168.0.0 a 192.168.255.0 (clase C) están reservadas para redes privadas ('intranets') por el RFC 1918; estos números no se asignan a ninguna dirección válida en Internet y por tanto pueden utilizarse para construir redes, por ejemplo detrás de un cortafuego, sin riesgo de entrar en conflicto de acceso con redes válidas de la Internet.

Como consecuencia de las reglas 3 y 4 antes mencionadas siempre hay dos direcciones inútiles en una red, la primera y la última. Por ejemplo, si tenemos la red 200.200.200.0 (clase C) tendremos que reservar la dirección 200.200.200.0 para denotar la red misma, y la dirección 200.200.200.255 para envíos broadcast a toda la red; dispondremos pues de 254 direcciones para hosts, no de 256.

7.3.1 Subredes

Supongamos que una empresa dispone de varias oficinas, cada una con una red local, todas ellas interconectadas entre sí, y que desea unirlas mediante el protocolo TCP/IP; una de dichas oficinas (la principal) dispone además de una conexión a Internet. Supongamos también cada oficina tiene suficiente con 254 direcciones de hosts. En principio sería posible asignar una red clase C diferente para cada oficina, pero esto supone solicitar al NIC una red para cada oficina que se conecte, y al ser cada una independiente de las demás la gestión se complica; por ejemplo sería preciso anunciar en Internet la ruta para cada nueva red para que la oficina correspondiente fuera accesible. Dado que cada red sería en principio independiente de las demás no habría una forma sencilla de agrupar las redes de la organización.

Hay un mecanismo que permite dividir una red IP en trozos o subredes, de forma que la empresa de nuestro ejemplo podría solicitar una clase B y asignar fragmentos de dicha red a cada oficina a medida que se fueran incorporando a la red. Esto equivale a crear un nivel jerárquico intermedio entre la red y el host, permitiendo así grados variables de agrupación según el nivel en el que nos encontramos. Supongamos que a la empresa de nuestro ejemplo se le asigna una red clase B, la 156.134.0.0; de los 16 bits que en principio corresponden al host podría reservar los primeros 8 para la subred y dejar los 8 siguientes para el host, con lo que dispondrá de 256 subredes de 256 direcciones cada una. Desde fuera la red de la empresa seguirá siendo 156.134.0.0, ya que la estructura de subred no será visible.

Las subredes se añadieron a la Internet en 1982; con ello se consiguió una mayor flexibilidad en el reparto de direcciones dentro de una red.

Para dividir la red en subredes se define una nueva máscara. Como siempre los bits a 1 de la máscara identifican la parte de red (en este caso la parte de red-subred) y los bits a cero corresponden al host. Por ejemplo, la máscara 255.255.255.0 aplicada sobre una red clase B la divide en 256 subredes de 256 direcciones cada una, pues tiene puestos a 1 los primeros 24 bits; en cierto modo podríamos decir que esta máscara convierte una red clase B en 256 subredes clase C. Se pueden hacer divisiones que no correspondan a bytes enteros, por ejemplo la máscara 255.255.252.0 hace subredes mas grandes, reserva los primeros 6 bits para la subred y deja 10 para el host, con lo que podría haber hasta 64 subredes con 1024 direcciones cada una.

Cuando se crean subredes hay dos direcciones en cada subred que quedan automáticamente reservadas: las que corresponden al campo host todo a ceros y todo a unos; estas se emplean para designar la subred y para broadcast dentro de la subred, respectivamente. Así si la red 156.134.0.0 se subdivide con la máscara 255.255.255.0 se crean 256 subredes del tipo 156.134.subred.host, cada una con 256 direcciones. En cada subred hay 254 direcciones aprovechables para hosts, ya que la primera dirección (156.134.subred.0) identifica a la subred y la última (156.134.subred.255) es la dirección broadcast de esa subred. Por tanto el número de hosts de una subred es siempre dos menos que el rango de direcciones que abarca. Una consecuencia de lo anterior es que resulta absurdo crear subredes con la máscara 255.255.255.254, ya que el campo host tendría un bit solamente y no quedaría ninguna dirección aprovechable para hosts.

Del mismo modo que los valores todo ceros o todo unos del campo host están reservados con un significado especial, los valores todo ceros y todo unos del campo subred (es decir la primera y la última subredes) también son especiales. El valor todo ceros se utiliza para representar la subred misma; por ejemplo si a la red 156.134.0.0 le aplicamos la máscara 255.255.255.0 la primera subred (campo subred todo a ceros) no debería utilizarse, pues resultaría ambiguo el significado de la dirección 156.134.0.0, que representaría tanto a dicha subred como a la red entera. Análogamente la última subred (campo subred todo a unos) tampoco debería utilizarse porque entonces la dirección 156.134.255.255 significaría tanto broadcast en dicha subred como en la red entera. Por consiguiente en el campo subred también se pierden siempre dos direcciones, y tampoco tendría sentido crear máscaras con el campo subred de un bit, como sería el caso de una máscara 255.255.128.0 en el caso de una red clase B.

Mientras que la restricción de las direcciones todo ceros o todo unos en el campo host se ha de respetar siempre, existen muchas situaciones en las que interesa aprovechar la subred toda a ceros o toda a unos, violando la segunda norma antes mencionada. Esta violación, permitida por muchas implementaciones, se conoce como subnet-zero y se adopta para aprovechar mejor el espacio de direcciones disponible; con subnet-zero es posible por ejemplo dividir una red clase B por la mitad en dos subredes mediante la máscara 255.255.128.0, cosa que no sería posible si no se permitiera esta pequeña 'infracción'.

En todos nuestros ejemplos la parte de subred de la máscara es contigua a la parte de red; en un principio se permitía crear subredes con máscaras no contiguas, por ejemplo dividir una clase B con la máscara 255.255.0.255; en este caso el host vendría especificado por el tercer byte y la subred por el cuarto. Dado que esta práctica solo resta claridad y hace menos eficiente el proceso de direcciones en los routers, actualmente la norma exige que la máscara sea contigua.

Para terminar de clarificar la creación de subredes y el uso de máscaras resumimos en la tabla 3.5 todas las posibles subredes y máscaras que se pueden utilizar con una red clase B. En el caso de una red clase C las posibles subredes y máscaras son las que se recogen en la tabla 3.6.

Bits de subred	Número de subredes	Nº subredes (subred cero)	Bits de host	Número de hosts	Máscara
0	0	0	16	65534	255.255.0.0
1	0	2	15	32766	255.255.128.0
2	2	4	14	16382	255.255.192.0
3	6	8	13	8190	255.255.224.0
4	14	16	12	4094	255.255.240.0
5	30	32	11	2046	255.255.248.0
6	62	64	10	1022	255.255.252.0
7	126	128	9	510	255.255.254.0
8	254	256	8	254	255.255.255.0
9	510	512	7	126	255.255.255.128
10	1022	1024	6	62	255.255.255.192
11	2046	2048	5	30	255.255.255.224
12	4094	4096	4	14	255.255.255.240
13	8190	8192	3	6	255.255.255.248
14	16382	16384	2	2	255.255.255.252
15	32766	32768	1	0	255.255.255.254
16	65534	65536	0	0	255.255.255.255

Tabla 3.5.- Subredes y máscaras que pueden definirse en una red clase B

Bits de subred	Número de subredes	Nº subredes (subred cero)	Bits de host	Número de hosts	Máscara
0	0	0	8	254	255.255.255.0
1	0	2	7	126	255.255.255.128
2	2	4	6	62	255.255.255.192
3	6	8	5	30	255.255.255.224
4	14	16	4	14	255.255.255.240
5	30	32	3	6	255.255.255.248
6	62	64	2	2	255.255.255.252
7	126	128	1	0	255.255.255.254
8	254	256	0	0	255.255.255.255

Tabla 3.6.- Subredes y máscaras que pueden definirse en una red clase C

La división en subredes no ha de hacerse necesariamente de forma homogénea en todo el espacio de direcciones, como hemos hecho hasta ahora. Supongamos que la empresa de nuestro ejemplo anterior tiene una serie de oficinas pequeñas que tienen bastante con subredes de 256 direcciones, pero otras mas grandes requieren un número mayor; podríamos partir la red en 256 subredes de 256 hosts y asignar varias de esas subredes a las oficinas mayores, pero esto complicaría la gestión y las tablas de rutas. La solución más adecuada en este caso sería dividir la red en subredes de diferentes tamaños y asignar a cada oficina una subred adecuada a sus necesidades. Asi en nuestro ejemplo se podría dividir la red 156.134.0.0 de la siguiente manera:

16 subredes de 256 direcciones:

Subred	Máscara	Subred/bits de máscara
156.134.0.0	255.255.255.0	156.134.0.0/24
156.134.1.0	255.255.255.0	156.134.1.0/24
156.134.2.0	255.255.255.0	156.134.2.0/24
156.134.3.0	255.255.255.0	156.134.3.0/24
156.134.4.0	255.255.255.0	156.134.4.0/24
156.134.5.0	255.255.255.0	156.134.5.0/24
156.134.6.0	255.255.255.0	156.134.6.0/24
156.134.7.0	255.255.255.0	156.134.7.0/24
156.134.8.0	255.255.255.0	156.134.8.0/24
156.134.9.0	255.255.255.0	156.134.9.0/24
156.134.10.0	255.255.255.0	156.134.10.0/24
156.134.11.0	255.255.255.0	156.134.11.0/24
156.134.12.0	255.255.255.0	156.134.12.0/24
156.134.13.0	255.255.255.0	156.134.13.0/24
156.134.14.0	255.255.255.0	156.134.14.0/24
156.134.15.0	255.255.255.0	156.134.15.0/24

16 subredes de 1024 direcciones

Subred	Máscara	Subred/bits de máscara
156.134.16.0	255.255.252.0	156.134.16.0/22
156.134.20.0	255.255.252.0	156.134.20.0/22
156.134.24.0	255.255.252.0	156.134.24.0/22
156.134.28.0	255.255.252.0	156.134.28.0/22
156.134.32.0	255.255.252.0	156.134.32.0/22
156.134.36.0	255.255.252.0	156.134.36.0/22
156.134.40.0	255.255.252.0	156.134.40.0/22
156.134.44.0	255.255.252.0	156.134.44.0/22
156.134.48.0	255.255.252.0	156.134.48.0/22
156.134.52.0	255.255.252.0	156.134.52.0/22
156.134.56.0	255.255.252.0	156.134.56.0/22
156.134.60.0	255.255.252.0	156.134.60.0/22
156.134.64.0	255.255.252.0	156.134.64.0/22
156.134.68.0	255.255.252.0	156.134.68.0/22
156.134.72.0	255.255.252.0	156.134.72.0/22
156.134.76.0	255.255.252.0	156.134.76.0/22

3 subredes de 4096 direcciones:

Subred	Máscara	Subred/bits de máscara
156.134.80.0	255.255.240.0	156.134.80.0/20
156.134.96.0	255.255.240.0	156.134.96.0/20
156.134.112.0	255.255.240.0	156.134.112.0/20

Y por último una subred de 32768 direcciones:

Subred	Máscara	Subred/bits de máscara
156.134.128.0	255.255.128.0	156.134.128.0/17

La técnica que hemos aplicado en el ejemplo anterior de dividir una red en subredes de diferentes tamaños se conoce comúnmente como máscaras de tamaño variable. Obsérvese que en este ejemplo hemos seguido la práctica de subnet-zero, es decir, se han considerado válidas subredes con el campo subred todo a ceros y todo a unos, de lo contrario no habría sido posible crear una subred con 32768 direcciones. Obsérvese en la columna de la derecha el uso de la notación subred/bits de máscara para representar las subredes; esta notación abreviada está sustituyendo en algunos casos a la tradicional y se emplea en la configuración de algunos equipos, en RFCs y otros documentos.

Cuando el campo subred ocupa bytes enteros es trivial la identificación de subredes. Las cosas se complican un poco más cuando no es así, por ejemplo en el caso anterior la primera subred de 1024 direcciones abarca un bloque de cuatro valores en el tercer byte, del 16 al 19; los bloques han de empezar en valores múltiplo de cuatro, si en vez de empezar en el 16 hubiéramos empezado en el 15 (15, 16, 17 y 18) no habría sido posible crear una subred pues la dirección 156.134.15.0 no tiene una máscara de 22 bits común con las otras tres; por consiguiente las subredes formadas con máscara de 22 bits (grupos de cuatro números) necesariamente han de empezar en valores múltiplos de cuatro (0, 4, 8, etc.). Análogamente puede deducirse que las subredes de máscara de 20 bits (4096 direcciones) han de empezar en valores múltiplos de 16, y así sucesivamente.

7.3.2 Superredes: Routing classless (CIDR)

El rápido crecimiento de la Internet está creando varios problemas, el más importante de los cuales es el agotamiento del espacio de direcciones IP. La causa de esto ha sido en parte la excesiva disparidad de tamaños entre las diferentes clases de redes. Hace ya mucho tiempo que han dejado de asignarse redes clase A, debido a su escaso número y tamaño excesivo. Las organizaciones tenían pues que elegir entre solicitar una clase B o una clase C. En muchos casos una clase B era excesiva, pero una C resultaba insuficiente, por lo que la mayoría de las organizaciones optaban por solicitar una clase B, aunque a menudo no necesitaban tantas direcciones. A la vista del rápido agotamiento de redes clase B debido a este motivo se pensó en crear grupos de clases C, de forma que las organizaciones pudieran optar por niveles intermedios entre las redes B y C, más adecuados a sus necesidades; por ejemplo una organización que necesite 2048 direcciones puede hoy en día solicitar un grupo de ocho redes clase C . De esta forma se reduce el problema de escasez de direcciones, pero se crea un problema nuevo: el crecimiento de las tablas de rutas. Antes, cuando a una organización que se conectaba a Internet se le asignaba una red esto suponía una nueva entrada en las tablas de rutas de Internet, pero al dar grupos de clases C se requiere una entrada diferente para cada red asignada. Esto habría provocado un crecimiento exponencial en las tablas de rutas de los routers que forman el ‘backbone’, cuyas capacidades se encuentran ya bastante cerca del límite de la tecnología.

El gran tamaño de las tablas de rutas de Internet se debe también al mecanismo de asignación de direcciones que se ha seguido, que durante mucho tiempo ha sido estrictamente cronológico. Al no haber una correspondencia entre la ubicación geográfica de una organización o el proveedor que la conecta a Internet y su rango de direcciones no es posible resumir o ‘sumarizar’ las tablas de rutas; la información se ha de incluir enumerando una a una todas las redes existentes. Esto se podría resolver con una organización jerárquica de direcciones de acuerdo con criterios geográficos, como ocurre por ejemplo en el direccionamiento de la red telefónica que identifica a cada país con prefijo, cada región dentro de un país con un subprefijo, y así sucesivamente.

Actualmente hay mas de 100.000 redes registradas en la Internet. Además del costo en memoria RAM que supone el mantener tablas extremadamente grandes en los routers, los algoritmos de búsqueda se complican y no funcionan adecuadamente con esas tablas, ya que fueron diseñados pensando en tablas con muchas menos entradas. A principios de los 90 el crecimiento de la Internet se estaba produciendo a un ritmo tal que el número de redes conectadas se duplicaba cada 9 meses, mientras que la tecnología sólo permite duplicar la capacidad y potencia de los routers cada 18 meses. En esta situación la explosión de las tablas de routing se estaba convirtiendo en un problema aún más grave que la escasez de direcciones. Según cálculos hechos por la IETF en 1993 de seguir produciéndose el crecimiento al mismo ritmo en el número de redes y rutas la Internet se habría colapsado hacia 1998.

Los dos problemas antes descritos, desperdicio del espacio de direcciones debido a la rigidez en la asignación de rangos (redes clase B o C) y crecimiento de las tablas de rutas, se resolvieron conjuntamente en 1993 con la adopción de un sistema denominado CIDR (Classless InterDomain Routing) descrito en los RFCs 1466, 1518 y 1519 que consiste en dos medidas complementarias.

La primera medida consiste en establecer una jerarquía en la asignación de direcciones. En vez de utilizar un criterio puramente cronológico, que desde le punto de vista geográfico o de topología de la red equivale a una asignación aleatoria, los rangos se asignan por continentes. Inicialmente se realizó la asignación de una parte del espacio de clase C de la siguiente manera:

Multi regional: 192.0.0.0 - 193.255.255.255

Europa: 194.0.0.0 - 195.255.255.255

Otros: 196.0.0.0 - 197.255.255.255

Noteamérica: 198.0.0.0 - 199.255.255.255

Centro y Sudamérica: 200.0.0.0 - 201.255.255.255

Anillo Pacífico: 202.0.0.0 - 203.255.255.255

Otros: 204.0.0.0 - 205.255.255.255

Otros: 206.0.0.0 - 207.255.255.255

Algunos de estos grupos se han ampliado posteriormente con nuevos rangos. A su vez cada proveedor Internet solicita rangos propios al NIC que le corresponde según el continente donde se encuentra. Con esta distribución regional de los números es en principio posible agrupar las entradas en las tablas de rutas; por ejemplo un router en Japón podría tener una sola entrada en sus tablas indicando que todos los paquetes dirigidos a las redes 194.0.0.0 hasta 195.255.255.0 se envíen a la interfaz por la cual accede a Europa, evitando así las 131.072 entradas que normalmente harían falta para este rango de direcciones.

Una consecuencia curiosa de la asignación de rangos de direcciones por proveedor es que si una empresa cambia de proveedor normalmente tendrá que 'devolver' al primero sus direcciones, y solicitar direcciones al nuevo proveedor; por supuesto tendrá que modificar la configuración de todas las máquinas que tuviera utilizando direcciones del primero.

Para que la sumarización de rutas (o agrupamiento de redes clase C) sea posible es preciso introducir una ligera modificación en el software de los routers, ya que en principio el software no considera el rango 194.0.0.0–195.255.255.255 como una sola red sino como 131.072 redes clase C. Para resolver este problema se ha extendido el concepto de subred en sentido contrario, es decir la máscara no solo puede crecer hacia la derecha para dividir una red en subredes sino que puede menguar hacia la izquierda para agrupar varias redes en una mayor (de ahí la denominación de ‘superredes’). Dicho de otra forma, la parte red de la dirección vendrá especificada por la longitud de la máscara únicamente, no teniendo ya ningún significado la clasificación tradicional en clases A, B y C de acuerdo con el valor de los primeros bits; solo se repeta dicho significado en el caso de las clases D (multicast) y E (reservado). Dicha supresión de las clases tradicionales es lo que da nombre a esta técnica conocida como enrutamiento entre dominios sin clases o CIDR (Classless InterDomain Routing).

La segunda medida adoptada por CIDR es en realidad un complemento de la anterior. Consiste sencillamente en dar a cada organización (bien directamente o a través de su proveedor correspondiente) la posibilidad de solicitar rangos de direcciones ajustado a sus necesidades previstas, dándole siempre un rango contiguo y que tenga una máscara de red común; por ejemplo un rango de 2048 direcciones se daría asignando los primeros 21 bits de la dirección y podría estar formado por ejemplo por el rango que va del 194.0.8.0 al 194.0.15.255.

Supongamos que la Universidad de Málaga solicita a su proveedor direcciones de red y justifica la previsión de tener 1200 hosts en un plazo razonable; como 1024 direcciones no serían suficientes su proveedor le asigna 2048 direcciones, equivalentes a ocho redes clase C. Supongamos que el proveedor tiene disponible el rango 195.100.0.0 a 195.100.255.255 y que ha ido asignando direcciones a sus clientes por orden cronológico, quedándole libre a partir de la 195.100.12.0; no es posible asignar a la Universidad de Málaga de la 195.100.12.0 a la 195.100.19.255 ya que aunque el rango es contiguo las direcciones no tienen una máscara común (los primeros 21 bits no son iguales). El primer rango de 2048 direcciones con máscara común es el 195.100.16.0-195.100.23.255, que es el que se deberá asignar. Las direcciones 195.100.12.0 a 195.100.15.255 quedarían libres para otros clientes con menores necesidades.

Con esta asignación de direcciones y sin utilizar CIDR el aspecto de la tabla de rutas para la Universidad de Málaga sería por ejemplo:

A 195.100.16.0/24 por 192.168.1.2

A 195.100.17.0/24 por 192.168.1.2

A 195.100.18.0/24 por 192.168.1.2

A 195.100.19.0/24 por 192.168.1.2

A 195.100.20.0/24 por 192.168.1.2

A 195.100.21.0/24 por 192.168.1.2

A 195.100.22.0/24 por 192.168.1.2

A 195.100.23.0/24 por 192.168.1.2

donde se supone que 192.168.1.2 es la interfaz por la que se accedería a la Universidad de Málaga.

El uso de CIDR permite sintetizar estas ocho entradas en una sola:

A 195.100.16.0/21 por 192.168.1.2

El software de hosts normalmente no soporta CIDR, por lo que éstos siguen ‘pensando’ en términos de redes clase A, B y C. Por tanto cuando dos hosts de la misma organización ubicados en redes clase C diferentes desean intercambiar tráfico han de hacer uso del router para iniciar el diálogo.

El espacio de redes clase A, que suponen la mitad del espacio total, está asignado actualmente sólo en un 50% aproximadamente. Está prevista la posibilidad de dividir cuando sea necesario la parte no utilizada de este rango de direcciones en redes de menor tamaño para su asignación mediante CIDR, igual que se hace actualmente con el rango 192.0.0.0-207.255.255.255.

La aplicación de CIDR ha permitido extender considerablemente la vida prevista inicialmente del espacio de direcciones de 32 bits de IPv4.

7.4 PROTOCOLOS DE CONTROL DE INTERNET

Antes hemos dicho que todo el tráfico de Internet está formado por datagramas IP. Normalmente los datagramas transportan TPDUs (Transport Protocol Data Unit) de TCP o UDP, que son los dos protocolos de transporte utilizados en Internet. Todas las aplicaciones de interés para el usuario de Internet (correo electrónico, transferencia de ficheros, videoconferencia, etc.) generan tráfico TCP o UDP. Sin embargo cuando vimos en la estructura de la cabecera de un datagrama el valor del campo protocolo observamos que existen muchos posibles significados del contenido de un datagrama IP, aparte de los ‘normales’ que serían TCP y UDP. Algunos de los datos que pueden transportarse en datagramas IP son mensajes de protocolos de control de Internet como los que veremos en este apartado. Los protocolos de control son una parte necesaria para el correcto funcionamiento de la red. Aquí describiremos los más utilizados que son ICMP, ARP, RARP, BOOTP y DHCP.

7.4.1 ICMP (Internet Control Message Protocol)

En el funcionamiento normal de una red se dan a veces situaciones extraordinarias que requieren enviar avisos especiales. Por ejemplo, si un datagrama con el bit DF (Don’t Fragment) puesto a 1 no puede pasar por una determinada red el router donde se produce el problema debe devolver un mensaje al host emisor indicándole lo sucedido. El mecanismo para reportar todos estos incidentes en Internet es el protocolo conocido como ICMP, que veremos a continuación. Aquí solo describiremos someramente los más importantes, para una descripción detallada de todos ellos se puede consultar el RFC 792.

Conviene recordar que los mensajes ICMP viajan por la red como datagramas IP (con el valor 1 en el campo ‘protocolo’), sujetos en los routers a las mismas reglas que cualquier otro datagrama. Los mensajes ICMP son generados por el host o router que detecta el problema o situación extraordinaria y dirigidos al host o router que aparece en el campo dirección origen del datagrama que causó el problema. Para facilitar la identificación del datagrama por parte del host emisor la mayoría de los mensajes ICMP incluyen, además del código de error correspondiente, la cabecera y los primeros ocho bytes de datos del datagrama original.

A continuación describiremos los mensajes ICMP más importantes:

DESTINATION UNREACHABLE. Este mensaje se produce cuando no se puede entregar el datagrama en su destino por diversas situaciones, entre las que destacaremos a modo de ejemplo las dos siguientes: a) cuando un router se encuentra con un datagrama que tiene puesto a 1 el bit DF (Don’t Fragment) y que no cabe en la MTU de la red por la que ha de enviarlo, y b) cuando un router no encuentra en sus tablas ninguna ruta por la que pueda llegar a la dirección para la que va dirigido un datagrama. Obsérvese que cuando un router tiene configurada ruta por defecto nunca enviará mensajes ICMP Destination Unreachable por este segundo motivo.

· SOURCE QUENCH. Este mensaje se creó para permitir a los routers solicitar una reducción en el tráfico generado por los hosts en caso de congestión, por lo que actuaban como paquetes de asfixia. En la práctica se ha visto que el uso de este tipo de mensajes agrava los problemas en caso de congestión, por lo que la recomendación actual es que los routers no deben generar paquetes SOURCE QUENCH en ningún caso.

ECHO REQUEST y ECHO REPLY: se usan para detectar si un destino determinado está operativo. Al recibir el mensaje el destino debe responder con el comando ICMP ECHO REPLY. El comando ping, muy utilizado en Internet para pruebas de accesibilidad, utiliza este comando. En la mayoría de las implementaciones de ping es posible especificar el tamaño del datagrama a enviar, y también la frecuencia de los envíos, con lo que se puede utilizar para generar un tráfico en la red de forma controlada. El comando ping suministra información del tiempo de ida y vuelta y porcentaje de datagramas perdidos, por lo que permite tener una idea bastante aproximada del estado de la red.

TIME EXCEEDED se envía al emisor cuando un paquete es descartado porque su TTL ha llegado a cero. Esto puede se síntoma de que se ha producido algún bucle en la red, o que el valor del TTL utilizado es demasiado bajo para el diámetro de la red. Hay un programa muy utilizado para diagnóstico de redes, denominado traceroute [6], que averigua la ruta a un destino determinado enviando paquetes con TTL de 1, 2, 3, y así sucesivamente. A partir de los mensajes ICMP TIME EXCEEDED recibidos el programa puede deducir la ruta completa hasta el destino especificado. Traceroute mide además el tiempo de ida y vuelta en cada caso, y para dar una información estadísticamente más significativa normalmente envía tres paquetes para cada valor de TTL y muestra los tiempos de ida y vuelta de cada uno, dando así información no sólo de la ruta seguida sino de los retardos en cada parte del trayecto.

REDIRECT se utiliza para alertar al host emisor cuando se sospecha que un paquete se está encaminando incorrectamente. Por ejemplo este mensaje lo utilizan los routers cuando reciben de un host datagramas que van dirigidos a otro host que se encuentra en la misma LAN.

7.4.2 Resolución de direcciones: ARP

Cuando se utilizan líneas punto a punto en una red la interfaz física fija el siguiente nodo al que se dirige el datagrama, ya que para cada enlace existe un único destinatario posible. En cambio cuando se utiliza una red multiacceso (por ejemplo RDSI, ATM o una LAN cualquiera) la tecnología utilizada para enviar los datagramas permite llegar por la misma interfaz física a más de un destinatario. En este caso es necesario algún mecanismo que permita saber a cual de todos los destinos posibles se dirigen los paquetes. Todas las redes multiacceso disponen de un sistema de direccionamiento propio, por ejemplo en una RDSI las direcciones serían los números de teléfono RDSI con los que queremos conectar, en una LAN serían las direcciones MAC de las estaciones, etc. En todos estos casos es el nivel de red el encargado de realizar la correspondencia entre la dirección en la tecnología multiacceso correspondiente y la dirección de red, correspondencia que se conoce como resolución de direcciones.

Existen múltiples mecanismos posibles para realizar la resolución de direcciones. De ellos comentaremos aquí algunos de los más utilizados.

a) Tabla estática mantenida manualmente en cada nodo. En este caso se tiene en cada nodo de la red multiacceso la tabla completa de equivalencia de direcciones. Esta técnica se utilizaba en las primeras redes locales y se utiliza actualmente en RDSI, X.25, Frame Relay y también en ATM en algunos casos. El principal problema que tiene es la necesidad de actualizar las tablas en todos los nodos de la red cada vez que se produce alguna modificación en la tabla de direcciones.

b) Tabla dinámica mantenida de forma automática en un servidor de la red conocido por todos. Cuando un nodo quiere enviar un mensaje a un destino determinado indica al servidor la dirección de red que busca y éste le devuelve la dirección de la red multiacceso correspondiente. Cualquier equipo que desee adherirse a la red deberá en primer lugar registrarse en el servidor para que éste incluya la entrada correspondiente en sus tablas. Este mecanismo se utiliza como veremos más adelante en IP sobre redes ATM como parte de la técnica denominada ‘Classical IP over ATM’; en ese caso el servidor facilita la dirección ATM que corresponde a una dirección IP determinada. Los principales problemas de esta solución son la necesidad del registro previo y que el servidor se convierte en una pieza clave de la red que puede limitar la disponibilidad y el rendimiento en algunos casos.

c) Establecer un mecanismo trivial por el que se pueda deducir la dirección de la red multiacceso a partir de la dirección de red. De esta forma cualquier nodo puede derivar la dirección de la red multiacceso a partir de la dirección de red. Este mecanismo se emplea por ejemplo en DECNET que construye la dirección MAC añadiendo a la dirección de red un prefijo determinado y conocido por todos los nodos. Para que esto sea posible no se utiliza la dirección global grabada en la tarjeta de red y se recurre al uso de direcciones MAC locales (las fijadas por software, que tienen a 1 el segundo bit) para poder imponer la dirección MAC a partir de la dirección de red. Este mecanismo no puede ser utilizado simultáneamente por mas de un protocolo de red ya que se produciría conflicto entre las direcciones MAC requeridas por los diversos protocolos. Como veremos más adelante un mecanismo de este tipo se utiliza en IP para la resolución de direcciones multicast en Ethernet.

d) Utilizar un mensaje broadcast para lanzar a la red una pregunta solicitando respuesta del nodo en la red multiacceso que posee la dirección de red buscada. Esta técnica da máxima flexibilidad ya que los equipos no necesitan registrarse y no hay un servidor centralizado del que dependa el funcionamiento de la red. Sin embargo solo es factible en redes de naturaleza broadcast, como las redes locales. El principal inconveniente de esta solución es el uso de paquetes broadcast que produce una degradación del rendimiento de toda la red [7]. Esta técnica es la utilizada en IP sobre redes locales de todo tipo.

En este apartado veremos en detalle el funcionamiento del protocolo ARP (Address Resolution Protocol) que utiliza el mecanismo descrito en último lugar. Veamos como funciona con un ejemplo:

Supongamos que Luis tiene su PC conectado a una red local Ethernet mediante una tarjeta configurada con la dirección IP 147.156.1.2 y la máscara 255.255.0.0; Luis quiere iniciar una sesión de terminal remoto telnet con un ordenador cuya dirección IP es 147.156.1.3. En el momento en que Luis teclea telnet 147.156.1.3 el software del PC compara la dirección de destino con la suya propia y con su máscara y deduce que el ordenador de destino se encuentra en la misma red local [8]. El PC genera entonces un mensaje ARP con la pregunta ¿quién tiene la dirección 147.156.1.3? y lo envía en una trama Ethernet que tiene como dirección MAC de destino la dirección broadcast (todo a unos); la trama es recibida y procesada por todas las máquinas de la red que en ese momento estén activas, siendo retransmitida a través de los conmutadores o puentes transparentes locales o remotos que haya. Eventualmente una máquina (y solo una) se reconoce propietaria de la dirección IP solicitada y responde al mensaje; la respuesta puede ser y normalmente será una trama unicast puesto que el ordenador de destino ya conoce la dirección MAC del PC que lanzó la pregunta; la respuesta incluye la dirección MAC solicitada, por lo que a partir de ese momento ambos ordenadores pueden comunicarse mediante tramas unicast, de forma que la generación de tráfico broadcast queda estrictamente limitada al primer mensaje enviado por el PC de Luis.

Cada ordenador de la red local mantiene en memoria una tabla denominada ARP cache con las parejas de direcciones MAC-IP utilizadas recientemente. Por tanto si Luis termina su sesión telnet pero olvidó algún detalle podrá durante varios minutos establecer otra conexión telnet con el mismo ordenador sin necesidad de enviar otro paquete ARP broadcast. Generalmente cuando un ordenador envía un mensaje ARP buscando a otro todas las máquinas de la red, no sólo la destinataria del mensaje, aprovechan para 'fichar' al emisor, anotándolo en su ARP cache. De esta forma si más tarde necesitan contactar con dicha máquina podrán hacerlo directamente, sin necesidad de enviar un mensaje ARP broadcast.

Las entradas en la ARP cache expiran pasados unos minutos sin que haya tráfico con la máquina correspondiente, para permitir que se produzcan cambios en la tabla por ejemplo por avería de una tarjeta de red o cambio de la dirección IP de un host. El comando arp –a, disponible en UNIX y en Windows, nos permite conocer en cualquier momento la tabla ARP cache disponible en un host.

En caso de que en una misma red local haya por error más de un ordenador con la misma dirección IP se pueden producir resultados inesperados [9]; en el mejor de los casos el primero en responder será el único en ser incluido en la ARP cache de los ordenadores que busquen esa dirección, dejando a los demás inaccesibles. Un caso típico en que se da este problema es cuando dos o mas usuarios comparten un disquete con software de red en el cual están incluidos además del software los ficheros de configuración que contienen la dirección IP (afortunadamente este problema hoy en día es menos frecuente ya que normalmente los sistemas operativos incorporan el software de red). En una red de grandes dimensiones es fundamental disponer de mecanismos que permitan detectar y minimizar el riesgo de tener direcciones duplicadas.

Aunque lo hemos visto aplicado al caso concreto de resolver una dirección IP en una red local, el protocolo ARP tiene un ámbito bastante más amplio. A nivel Ethernet ARP es un protocolo diferente de IP, con un valor de Ethertype de 806 (hexadecimal). Esto permite que los routers no confundan los paquetes ARP con los paquetes IP y no los propaguen; de este modo los paquetes ARP quedan siempre confinados en red local donde se producen, evitando así que el tráfico broadcast que generan se propague a otras redes.

Para poder adaptarse a cualquier tipo de red broadcast y a cualquier protocolo a nivel de red el paquete ARP prevé el uso de longitudes arbitrarias tanto de la dirección de red como de la dirección de enlace. A título de ejemplo la tabla 3.7 muestra el formato del paquete ARP para el caso más habitual, que corresponde a una red con direcciones MAC de 6 bytes y direcciones IP de 4 bytes. Los campos se describen a continuación:

Campo	Longitud (Bytes)
Tipo de hardware	2
Tipo de protocolo	2
Long. Dirección hardware	1
Long. Dirección red	1
Código operación	2
Dirección MAC emisor	6
Dirección IP emisor	4
Dirección MAC destino	6
Dirección IP destino	4

Tabla 3.7.- Estructura de un paquete ARP IP para redes 802

Tipo de hardware: especifica el tipo de red local, por ejemplo el código 1 identifica Ethernet.

Tipo de protocolo: especifica el protocolo de red utilizado. Se emplean los mismos códigos que en el Ethertype (por ejemplo x0800 en el caso de IP).

Long. Dirección hardware: se especifica en bytes. Por ejemplo en el caso de direcciones MAC la longitud es de seis bytes.

Long. Dirección red: también en bytes, por ejemplo cuatro en el caso de IP.

Código operación: vale 1 en el caso de una pregunta ARP (¿quién tiene la dirección IP tal?) y 2 en el de una respuesta.

7.4.3 Resolución inversa de direcciones

A veces se plantea el problema inverso a ARP, es decir hallar la dirección IP a partir de una determinada dirección LAN. Por ejemplo cuando se arranca una estación de trabajo 'diskless', es decir sin disco, ésta ha de cargar su sistema operativo desde otro ordenador normalmente situado en la misma red local, pero desconoce todo lo relativo a su configuración de red, incluida la dirección IP; lo único que la estación conoce en principio es su dirección MAC, que se encuentra escrita en su tarjeta de red local.

7.4.3.1 RARP

Para estas situaciones se inventó RARP (Reverse Address Resolution Protocol), que funciona de la siguiente manera: la estación diskless envía un mensaje broadcast en el que indica su dirección MAC y solicita que alguien le informe de cual es la dirección IP que le corresponde. En la red habrá un servidor RARP encargado de atender este tipo de peticiones que consultará sus tablas y devolverá la dirección IP correspondiente.

RARP utiliza el mismo formato de mensaje que ARP. La única diferencia es que utiliza los códigos de operación 3 y 4 para la pregunta y respuesta RARP, respectivamente. Además en vez de utilizar el Ethertype x0806 emplea el x8035; esto permite a los hosts que no soportan el protocolo RARP descartar estos mensajes rápidamente, sin tener que analizar su contenido.

7.4.3.2 BOOTP

RARP aporta funcionalidades interesantes pero tiene algunas limitaciones importantes. Como la consulta se realiza mediante un mensaje broadcast el servidor RARP ha de estar en la misma LAN que el cliente; por tanto es necesario prever un servidor RARP en cada LAN, ya que los mensajes broadcast a nivel MAC no atraviesan los routers. Otra limitación es el hecho de que el protocolo RARP solo preve el envío de la dirección IP, cuando sería interesante aprovechar el mensaje para informar al cliente de todo el conjunto de parámetros relacionados con la configuración de la red (la máscara, el router por defecto, etc.). Para superar estas limitaciones de RARP se inventó el protocolo BOOTP (BOOTstrap Protocol).

Cuando un host lanza una pregunta BOOTP lo hace en un datagrama IP con la dirección de destino 255.255.255.255 y dirección de origen 0.0.0.0. De esta forma el datagrama es recibido por todos los hosts de la LAN. Si alguno de ellos es el servidor BOOTP consultará sus tablas y devolverá la información requerida al solicitante, en otro datagrama IP. Resulta interesante analizar como se envía dicha contestación. En principio, al tratarse de un datagrama IP el proceso servidor BOOTP debería consultar su tabla ARP cache para averiguar la dirección MAC del destinatario; es evidente que la ARP cache no contendrá dicha dirección puesto que el servidor BOOTP no ha realizado todavía ningún envío al cliente. Por tanto el paso siguiente sería que el servidor enviara un mensaje ARP request preguntado quien tiene la dirección IP solicitada, pero en este caso el cliente no respondería puesto que aún desconoce cual es su dirección IP. Esto es lo que en el RFC 951 (que especifica el protocolo BOOTP) se describe como el problema ‘del huevo y la gallina’. Existen dos posibles soluciones a este problema:

a) Enviar la respuesta en broadcast, es decir a la dirección 255.255.255.255. Esta es la solución más habitual.

b) Actualizar la tabla ARP cache para incluir en ella la entrada correspondiente al cliente y poder así enviar el datagrama a su destino. Este es un procedimiento irregular, ya que en principio el único autorizado a modificar la ARP cache de un host es el proceso ARP. Solo en algunos casos el kernel o los drivers disponen de mecanismos que permitan al proceso servidor BOOTP realizar dicha modificación.

Los mensajes BOOTP se envían en datagramas UDP/IP. Esto tiene la ventaja de permitir que el servidor BOOTP no esté ubicado en la misma LAN que el cliente, pero para que esto funcione es necesario disponer en la LAN del cliente de un router que actúe como agente de reenvío de mensajes BOOTP. Dicho router se encargará de recoger los BOOTP request de la LAN y redirigirlos hacia el servidor. El intercambio de mensajes BOOTP entre el agente de reenvío y el servidor BOOTP se realiza de forma normal, pero el problema que se plantea es la entrega del BOOTP reply al cliente, que como ya hemos visto requiere seguir un procedimiento especial (normalmente un envío broadcast). Para que quede claro quien es el responsable de realizar dicho procedimiento ‘singular’ en el sentido inverso, cuando el router reenvía el BOOTP request anota en él la dirección IP de la interfaz por la que lo recibió; dicha información acompañará el BOOTP reply correspondiente y permitirá al router realizar la entrega según el procedimiento singular. Para que este procedimiento funcione es preciso que las rutas sean simétricas, es decir que el BOOTP request y el BOOTP reply utilicen el mismo camino.

Además de la dirección el protocolo BOOTP permite indicar el nombre del host, la máscara de subred, el router por defecto, servidor de nombres, etc. Aunque no se utiliza a menudo también puede indicarse el nombre y ubicación del fichero desde el cual debe hacer boot la máquina cliente, si se desea que arranque de forma remota desde otra máquina. BOOTP fue el primer protocolo estándar para arranque automático de ordenadores en TCP/IP.

BOOTP permite centralizar en uno o unos pocos servidores la configuración de todas las máquinas de una red y debido a su mayor flexibilidad ha desplazado prácticamente por completo a RARP. Esta facilidad de configuración centralizada resulta especialmente útil en redes grandes, ya que permite hacer de manera cómoda cambios en la configuración de una red sin tener que hacer los cambios localmente máquina a máquina. La configuración centralizada ayuda a evitar la duplicidad de direcciones IP, que puede dar muchos problemas como comentábamos al hablar de ARP.

7.4.3.3 DHCP

Tanto RARP como BOOTP requieren una asignación estática biunívoca entre direcciones MAC y direcciones IP; hacen falta tantas direcciones IP como ordenadores vayan a utilizar el protocolo TCP/IP. Existen situaciones en las que esto no es conveniente, por ejemplo:

o Una empresa con 500 ordenadores quiere conectarse a la Internet, de forma que cualquiera de ellos pueda salir al exterior; para esto dispone de una clase C; se calcula que nunca habrá más de 200 ordenadores simultáneamente conectados a la Internet, por lo que en principio una red clase C sería suficiente, pero la necesidad de asignar una dirección IP a cada ordenador requiere disponer de 500 direcciones IP si se quiere ofrecer conectividad a todos ellos.

o En una universidad se dispone de una sala para la conexión a Internet de los ordenadores portátiles de los alumnos. No se conocen las direcciones MAC de los ordenadores que se utilizarán ni cuantos serán, lo único que se sabe es que no habrá en ningún momento más de 50 conectados simultáneamente ya que esta es la capacidad de la sala.

Evidentemente en estas situaciones es necesario un mecanismo más flexible de asignación de direcciones IP que el ofrecido por BOOTP.

Para resolver estos problemas el IETF diseñó en 1993 el protocolo DHCP (Dynamic Host Configuration Protocol), que es similar a BOOTP pero es más versátil en los mecanismos de asignación de direcciones IP. En DHCP los clientes pueden recibir sus direcciones por uno de los tres mecanismos siguientes:

Asignación indefinida y estática. En este caso la dirección es fijada por el administrador. Este equivale a BOOTP.

Asignación automática. La asignación es también estática pero la elección de la dirección IP correspondiente es tomada por el servidor DHCP la primera vez que el equipo le solicita su dirección.

Asignación dinámica. En este caso el cliente recibe la dirección IP del servidor durante un tiempo limitado. Pasado ese tiempo el cliente debe renovar su solicitud o de lo contrario la concesión expirará. De esta forma una misma dirección puede ser reutilizada por diferentes máquinas en momentos diferentes. Esta modalidad es también conocida como ‘alquiler de direcciones’.

La mayor flexibilidad de DHCP le ha convertido en el protocolo preferido para la configuración remota de ordenadores en redes locales. Con DHCP se mejora notablemente la seguridad y fiabilidad de una red; también se simplifican las labores de administración de la misma.

Con la asignación dinámica de direcciones DHCP desempeña en redes locales un papel similar a PPP en las conexiones de RTC.

Un inconveniente de la asignación dinámica de direcciones es que si se desea rastrear un problema y, como es lo normal, sólo se dispone de la dirección IP resulta más difícil (a veces imposible) averiguar que ordenador o usuario ha sido el causante del problema. Otro problema es la asociación de direcciones y nombres en el DNS; con la asignación dinámica diferentes máquinas pueden recibir el mismo nombre en diferentes momentos.

DHCP es lo más parecido a la autoconfiguración en IPv4.

RARP se describe en el RFC 903. BOOTP se describe en los RFC 951, 1497 y 1542. DHCP se describe en el RFC 1541.

7.5 PROTOCOLOS DE ROUTING

La Internet está formada por multitud de redes interconectadas, pertenecientes a diversas empresas y organizaciones. Todas estas redes interconectadas comparten a nivel de red el protocolo IP. Al margen de esta interoperabilidad existen dos aspectos fundamentales en los que las redes pueden diferir entre si:

El protocolo de routing utilizado: existen como veremos multitud de protocolos de routing diferentes, unos basados en el algoritmo del vector distancia y otros en el del estado del enlace; incluso utilizando el mismo algoritmo se pueden emplean protocolos diferentes. Aun utilizando el mismo algoritmo y protocolo de routing dos proveedores diferentes normalmente no querrán que sus routers intercambien entre sí la misma información de routing que intercambian internamente.

La política de intercambio de tráfico: un proveedor puede tener acuerdos bilaterales o multilaterales para intercambiar tráfico con otros, pero normalmente no estará dispuesto a ser utilizado como vía de tránsito para el tráfico entre dos proveedores si esto no está expresamente recogido en los acuerdos, aun cuando desde el punto de vista de topología de la red pueda ser ese el camino más corto entre ambas.

7.5.1 Sistema Autónomo

Entendemos por Sistema Autónomo (AS, Autonomous System) la subred que es administrada o gestionada por una autoridad común, que tiene un protocolo de routing homogéneo mediante el cual intercambia información en toda la subred y que posee una política común para el intercambio de tráfico con otras redes o sistemas autónomos.

Normalmente cada ISP (Internet Service Provider) constituye su propio sistema autónomo; por ejemplo en España (como en otros países) la red académica RedIRIS (que a estos efectos es un ISP mas) tiene un sistema autónomo propio. Los sistemas autónomos reciben números de dos bytes que se registran en el IANA de forma análoga a las direcciones IP; por ejemplo el sistema autónomo de RedIRIS tiene el número 766.

De la misma forma que existen unos rangos de direcciones IP reservados para redes privadas existe un rango de números de sistemas autónomos reservados para sistemas autónomos privados, que son los que van del 64512 al 65535. Por ejemplo los routers de las Universidades de Valencia y Politécnica de Valencia forman un sistema autónomo privado, ya que intercambian información de routing entre ellos pero no con otros , por tanto tienen asignado el sistema autónomo 65432.

Así pues, como mínimo en la Internet se dan dos niveles jerárquicos de routing, el que se realiza dentro de un sistema autónomo (AS) y el que se efectúa entre sistemas autónomos. Al primero lo denominamos routing interno, o routing en el interior de la pasarela (pasarela es una antigua denominación de router). Al routing entre sistemas autónomos lo denominamos routing externo, o también routing exterior a la pasarela. Dado que los requerimientos en uno y otro caso son muy diferentes, se utilizan protocolos de routing distintos. Los protocolos de routing dentro del sistema autónomo se denominan IGP (Interior Gateway Protocol), mientras que los utilizados entre sistemas autónomos se llaman EGP (Exterior Gateway Protocol).

7.5.2 Protocolos de routing interno (IGP)

En la Internet se usan actualmente diversos protocolos de routing interno. Estos pueden agruparse en protocolos de vector distancia entre los que destacamos RIP, RIPv2, IGRP y EIGRP, y protocolos del estado del enlace de los que los más importantes son IS-IS y OSPF. Los describiremos someramente, centrándonos en el caso de OSPF que es el más importante por su mayor uso y sofisticación.

7.5.2.1 RIP y RIPv2

RIP (Routing Information Protocol) es uno de los protocolos de routing más antiguos y deriva del protocolo de routing de XNS (Xerox Network Systems); RIP sufre los problemas típicos de los algoritmos basados en el vector distancia, tales como la cuenta a infinito, etc. Además RIP arrastra otros problemas que son consecuencia de ser un protocolo de routing muy antiguo, como son:

Métricas basadas exclusivamente en número de saltos

No soporta subredes ni máscaras de tamaño variable (si en RIPv2).

No permite usar múltiples rutas simultáneamente.

Se genera una gran cantidad de información de routing que se intercambia cada 30 segundos. Con el paso del tiempo los routers tienden a sincronizarse de forma que todos acaban enviando los paquetes a la vez; esto provoca congestión y parones en la red durante el momento en que se intercambia la información de routing.

Algunos de estos problemas aumentan a medida que crece el tamaño de los sistemas autónomos, por lo que en la práctica no es aconsejable usar RIP en ninguna red que tenga mas de 5 a 10 routers. A pesar de todos sus inconvenientes RIP aún se utiliza en algunas partes de Internet. Existen dos versiones de RIP: la versión 1, que se definió en el RFC 1058 y se publicó en 1983 (aunque se empezó a utilizar mucho antes) se ha declarado histórica, es decir su uso está desaconsejado. En vista de la popularidad de RIP y de los muchos problemas que presentaba en 1993 se publicó RIP versión 2, que intentaba resolver al menos algunos de ellos (RFC 1388).

RIP está implementado en muchas versiones de UNIX, aunque desgraciadamente se trata generalmente de RIPv1.

7.5.2.2 IGRP y EIGRP

A pesar de sus inconvenientes, el routing por vector distancia tiene algunos serios partidarios. Quizá el más importante sea la empresa Cisco, actualmente el principal fabricante de routers en el mundo. En 1988, cuando el único protocolo de routing estandarizado y ampliamente utilizado era RIP, Cisco optó por crear un protocolo de routing propio denominado IGRP (Interior Gateway Routing Protocol) para resolver algunos de los problemas que presentaba RIP. IGRP está basado también en el vector distancia. Cisco siguió (y sigue) apostando por los protocolos de routing basados en el vector distancia ya que en 1993 produjo un nuevo protocolo denominado EIGRP (Enhanced IGRP) que introducía mejoras importantes respecto a IGRP, pero basado también en el vector distancia. Hay que resaltar que tanto IGRP como EIGRP son protocolos propietarios, y no hay implementaciones de ellos para equipos de otros fabricantes, por lo que el uso de estos protocolos requiere que todos los routers del sistema autónomo correspondiente sean de Cisco. Los routers Cisco también pueden funcionar con protocolos estándar, tales como RIP OSPF e IS-IS.

EIGRP es el protocolo de routing utilizado por ejemplo en el sistema autónomo de la Universidad de Valencia.

7.5.2.3 OSPF

La respuesta del IETF a los problemas de RIP fue OSPF (Open Shortest Path First), protocolo de routing basado en el estado del enlace. OSPF fue desarrollado entre 1988 y 1990, y en 1991 ya se había producido OSPF versión 2. OSPF esta basado en IS-IS y muchos de los conceptos que maneja son comunes a ambos protocolos. Es un estándar Internet y es el protocolo actualmente recomendado por el IAB para sustituir a RIP. Su complejidad es notablemente superior, mientras que la descripción de RIP ocupa menos de 20 páginas la especificación de OSPF emplea más de 200. La especificación vigente de OSPF está en el RFC 2328.

Entre las características más notables de OSPF podemos destacar las siguientes:

o Es un algoritmo dinámico autoadaptativo, que reacciona a los cambios de manera automática y rápida.

o Soporta una diversidad de parámetros para el cálculo de la métrica, tales como capacidad (ancho de banda), retardo, etc.

o Realiza balance de carga si existe más de una ruta hacia un destino dado.

o Establece mecanismos de validación de los mensajes de routing, para evitar que un usuario malintencionado envíe mensajes engañosos a un router.

o Soporta rutas de red, de subred y de host.

o Se contempla la circunstancia en la que dos routers se comuniquen directamente entre sí sin que haya una línea directa entre ellos, por ejemplo cuando están conectados a través de un túnel.

OSPF permite dos niveles de jerarquía creando lo que se denominan áreas dentro de un sistema autónomo. De esta forma un router sólo necesita conocer la topología e información de routing correspondiente a su área, con lo que la cantidad de información de routing se reduce. En redes complejas esta es una característica muy valiosa.

Los algoritmos de routing por el estado del enlace se aplican dentro de cada área. En todo Sistema Autónomo (AS) hay al menos un área, el área 0 denominada backbone. Un router puede pertenecer simultáneamente a dos o mas áreas, en cuyo caso debe disponer de la información de routing y ejecutar los cálculos correspondientes a todas ellas. Al menos un router de cada área debe estar además en el backbone, para conectar dicha área con el resto del Sistema Autónomo. Dos áreas sólo pueden hablar entre sí a través del backbone.

En OSPF se contemplan cuatro clases de routers:

o Routers backbone; son los que se encuentran en el área 0 ó backbone.

o Routers internos; los que pertenecen únicamente a un área.

o Routers frontera de área; son los que están en mas de un área, y por tanto las interconectan (una de las áreas interconectadas siempre es necesariamente el backbone).

o Routers frontera de Sistema Autónomo; son los que intercambian tráfico con routers de otros Sistemas Autónomos. Estos routers pueden estar en el backbone o en cualquier otra área.

Existen tres tipos de rutas: intra-área, inter-área e inter-AS. Las rutas intra-área son determinadas directamente por cualquier router, pues dispone de toda la información; las rutas inter-área se resuelven en tres fases: primero ruta hacia el backbone, después ruta hacia el área de destino dentro del backbone, y por último ruta hacia el router deseado en el área de destino.

Para el intercambio de información cada router envía cuando arranca unos mensajes de salutación, denominados HELLO, por todas sus interfaces. Este y otros mensajes los reenvía periódicamente para asegurarse de que las líneas permanecen operativas. Con la información que posee y la recabada en respuesta a sus mensajes el router calcula las rutas óptimas para cada destino en cada momento.

Cuando en una red local hay varios routers resulta poco eficiente que cada uno intercambie toda la información de routing que posee con todos los demás, ya que mucha de la información sería redundante. En una red local con n routers esto produciría (n²-n)/2 intercambios de información diferentes. En estos casos OSPF prevé que uno de los routers se convierta en el router designado, siendo éste el único que intercambiará información con todos los demás. De esta forma el número de intercambios de información se reduce a n-1.

7.5.2.4 IS-IS

El protocolo de routing IS-IS (Intermediate System-Intermediate System) está basado en el algoritmo del estado del enlace; además IS-IS permite hacer routing integrado, es decir calcular las rutas una vez y aplicarlas para todos los protocolos utilizados, permitiendo así auténtico routing multiprotocolo (de este tema hablaremos en más detalle en el capítulo de Internetworking). Soporta hasta ocho niveles jerárquicos, para reducir así la cantidad de información de routing intercambiada. IS-IS fue diseñado para el protocolo DECNET (de Digital) y adoptado después por ISO como protocolo de routing para el protocolo de red CLNP [10]. Una variante de IS-IS se utiliza en Netware de Novell.

IS-IS también se utiliza en algunas zonas de la Internet. El protocolo IS-IS se especifica en el RFC 1142.

IS-IS no es un estándar Internet, aunque se especifica en el RFC 1142. Actualmente es el protocolo utilizado en las redes grandes, por ejemplo la gran mayoría de las redes de los ISPs utilizan IS-IS en lugar de OSPF. Actualmente es el protocolo utilizado por RedIRIS, que migró del EIGRP que utilizaba anteriormente.

7.5.3 Protocolos de routing externo

Todos los protocolos de routing hasta ahora descritos se emplean dentro de sistemas autónomos. Normalmente un sistema autónomo corresponde a una subred que tiene una entidad común desde el punto de vista administrativo y de gestión, puede ser por ejemplo la red de una gran empresa, de un proveedor de servicios Internet o la red académca de un país como RedIRIS. En estos casos se supone que el protocolo de routing ha de buscar la ruta óptima atendiendo únicamente al criterio de minimizar la ‘distancia’ medida en términos de la métrica elegida para la red.

La selección de rutas para el tráfico entre sistemas autónomos plantea un problema diferente, ya que la cuestión no se reduce a la selección de la ruta óptima sino que se debe atender a criterios externos que obedezcan a razones de tipo político, económico, administrativo, etc. (recordemos que se trata de decidir el routing entre redes que pertenecen a organizaciones diferentes). Un ejemplo típico de este tipo de restricciones es el caso en que la ruta óptima entre dos sistemas autónomos, X e Y, pasa por un tercero Z que no desea que su red sea utilizada como vía de tránsito. Para dar cabida a la utilización de criterios externos en el cálculo de las rutas entre sistemas autónomos se utilizan en este caso otro tipo de protocolos de routing, denominados protocolos de routing externo.

Hasta 1990 se utilizaba como protocolo de routing externo en la Internet el denominado EGP (Exterior Gateway Protocol), diseñado entre 1982 y 1984. Como era de esperar EGP no fue capaz de soportar la enorme evolución que sufrió Internet y como ya era habitual el IETF desarrolló un nuevo protocolo de routing externo, denominado BGP (Border Gateway Protocol). La primera especificación de BGP apareció en 1989; desde entonces el IETF ha producido cuatro versiones de BGP; las especificaciones actualmente vigentes de BGP-4 se encuentran en el RFC 1771.

Los routers que utilizan BGP (pertenecientes a diferentes ASes) forman entre ellos una red e intercambian información de routing para calcular las rutas óptimas; se utiliza el vector distancia, pero para evitar el problema de la cuenta a infinito la información intercambiada incluye, además de los routers accesibles y el costo, la ruta completa utilizada para llegar a cada posible destino; de esta forma el router que recibe la información puede descartar las rutas que pasan por él mismo que son las que podrían dar lugar al problema de la cuenta a infinito. La especificación de la ruta completa permite también a los routers revisar si dicha ruta es conforme con las políticas que se hayan especificado en cuanto a tránsito por otros sistemas autónomos.

BGP permite introducir manualmente restricciones o reglas de tipo 'político'; éstas se traducen en que cualquier ruta que viola la regla recibe automáticamente una distancia de infinito.

Para simplificar la gestión de los Sistemas Autónomos se crean Confederaciones de Sistemas Autónomos; una confederación es vista como un único Sistema Autónomo desde el exterior. Esto equivale a introducir en el protocolo de routing externo dos niveles jerárquicos, con lo que se reduce la información de routing de forma análoga a lo que ocurría con las áreas de OSPF dentro de un Sistema Autónomo.

7.5.4 Puntos neutros de interconexión

Cuando dos ISPs están conectados a la Internet en principio siempre es posible el intercambio de información entre ellos. Sin embargo este intercambio no siempre ocurre por el camino óptimo. Por ejemplo, si en España dos ISPs contratan conectividad Internet, uno a Telefónica y el otro a British Telecom (BT), su intercambio de tráfico se realizará normalmente a través de algún punto de interconexión fuera de España, lo cual no es óptimo ya que consume costosos recursos de líneas internacionales. La solución a este problema es la realización de un acuerdo bilateral entre los dos proveedores (Telefónica y BT), de forma que se establezca un enlace directo entre sus sistemas autónomos en España para que puedan intercambiar tráfico sin necesidad de salir fuera. Cuando el número de proveedores crece la cantidad de enlaces que hay que establecer aumenta de forma proporcional a (n²-n)/2 donde n es el número de proveedores que intercambian tráfico [11]. Para reducir el número de enlaces se suelen crear los denominados puntos neutros de interconexión, consistentes en un nodo normalmente gestionado por una entidad independiente (para garantizar su 'neutralidad') al cual se conectan los proveedores que desean participar. En principio en el ámbito del punto neutro el intercambio de tráfico debería ocurrir sin restricciones entre todos los proveedores; sin embargo en la práctica los proveedores han de establecer acuerdos bilaterales, por lo que no siempre dos proveedores conectados a un mismo punto neutro intercambian tráfico.

La implementación de un punto neutro es muy sencilla. Se trata básicamente de un conmutador LAN Ethernet/Fast Ethernet en el que a cada proveedor se le asigna una LAN a la que puede conectar sus routers. Los routers de diferentes proveedores intercambian información de routing mediante BGP. Cada proveedor ha de conseguir los medios necesarios para conectar su red al punto neutro (líneas dedicadas, etc.). Físicamente las instalaciones de un punto neutro han de cumplir unos requisitos de fiabilidad y seguridad muy altos, ya que se trata de un elemento crítico en el funcionamiento de la red.

Existen gran cantidad de puntos neutros de interconexión en Internet. En España el primer punto neutro de interconexión que se creó en febero de 1997 fue el ESPANIX (http://www.espanix.net/) ubicado en el Centro de Proceso de Datos de Banesto, en Madrid. Dado que se trata de un punto neutro de interconexión a nivel nacional solo se conectan a él los proveedores que tienen conectividad internacional propia. Los proveedores que no tienen enlaces internacionales se conectan normalmente a través de alguno de esos proveedores con conectividad internacional, por lo que acceden de forma indirecta al punto neutro. Actualmente (octubre de 2003) existen 29 proveedores conectados a ESPANIX.

Posteriormente han ido apareciendo otros puntos neutros en España. En junio de 1999 se creó el CATNIX (www.catnix.net) en el CESCA (Centre de Supercomutació de Catalunya) en Barcelona, que conecta actualmente a 10 proveedores. En julio de 2002 el GALNIX (www.galnix.net) en el CESGA (Centro de Supercomputación de Galicia) que conecta 6 proveedores. También se está poniendo en marcha el EUSKONIX en la Universidad del País Vasco y en Madrid han aparecido recientemente otros dos puntos neutros, el MAD-IX (www.mad-ix.net) y el NAP (www.napmadrid.com).

7.5.5 Routing Multicast

Las direcciones IP clase D (entre 224.0.0.0 y 239.255.255.255) están reservadas para tráfico multicast. Se pueden crear dos tipos de grupos multicast, temporales y permanentes. Algunos grupos permanentes que están ya predefinidos son los siguientes:

224.0.0.1 Todos los hosts en una LAN

224.0.0.2 Todos los routers en una LAN

224.0.0.5 Todos los routers OSPF en una LAN

224.0.0.6 Todos los routers OSPF designados en una LAN

Los grupos temporales se han de crear cada vez que se van a utilizar. Un host (más exactamente un proceso en un host) puede solicitar unirse a un grupo multicast (join), o puede decidir abandonarlo (leave). Cuando el último proceso de un host abandona un grupo multicast el host mismo abandona el grupo. En Internet el protocolo que gestiona todas las operaciones relacionadas con los grupos multicast es el IGMP (Internet Group Management Protocol). Para captar una emisión multicast es preciso fromar parte del grupo correspondiente, pero no es necesario estar en dicho grupo para realizar una emisión multicast hacia él.

En una LAN, al ser el medio físico intrínsecamente broadcast, no es necesaria ninguna acción especial para permitir el tráfico multicast; los paquetes viajan por la red y los hosts capturan los que corresponden a los grupos multicast a los que pertenecen. El router multicast de la LAN pregunta aproximadamente una vez por minuto a los hosts de su LAN (dirección 224.0.0.1) en que grupos multicast están interesados. Los hosts devuelven la relación de direcciones clase D en las que están interesados. De acuerdo con las respuestas que recibe el router van actualizando el árbol de distribución, añadiendo o suprimiendo (podando) ramas de éste. Si el detecta que alguna dirección multicast ha dejado de interesar (es decir, ya no hay miembros de ese grupo en la LAN) envía un mensaje al router siguiente en el árbol solicitándole le ‘pode’, es decir le suprima de la distribución. Inversamente puede también solicitar su adhesión a un grupo en el que antes no estuviera.

En enlaces punto a punto los routers han de revisar regularmente el árbol de distribución multicast, a fin de ‘podar’ de éste las ramas innecesarias e incluir las que presenten nuevos miembros del grupo multicast; de esta forma se evita cargar las líneas con tráfico innecesario.

La resolución de direcciones multicast en redes locales no se realiza mediante el protocolo ARP, ya que no tendría sentido que el emisor multicast tuviera que preguntar a los miembros del grupo cual es la dirección MAC multicast correspondiente a una dirección IP determinada. En este caso se aplica la técnica de emplear un algoritmo que permita deducir la dirección MAC a partir de la dirección IP (RFC 1112): la dirección IP multicast está representada por 28 bits (ya que los cuatro primeros siempre son 1110) por lo que se podría trasladar por ejemplo a los 28 bits menos significativos de la dirección MAC, fijando los 20 primeros. Dado que el OUI (Organizationally Unique Identifier) ocupa los 24 primeros bits de la dirección MAC para poder utilizar cuatro de estos bits en las direcciones multicast habría sido necesario reservar para este fin 16 valores consecutivos de OUI, cosa que llegó a ser propuesta por el IETF al IEEE, pero no fue considerada aceptable por éste. En su lugar se decidió utilizar la mitad del OUI que había reservado para el IETF (01.00.5E), dejando así 23 bits libres en los que se mete la parte menos significativa de la dirección IP multicast de 28 bits. La correspondencia por tanto no es biunívoca, ya que existen 32 direcciones IP multicast diferentes por cada dirección MAC multicast; por ejemplo las direcciones IP multicast 224.0.0.1 y 224.128.0.1 que tienen iguales los 23 últimos bits se mapean ambas en la dirección MAC multicast 01.00.5E.00.00.80 [12]. Podrá por tanto ocurrir que en una misma LAN dos grupos IP multicast diferentes utilicen la misma dirección MAC multicast; en este caso algunos hosts capturarán tramas multicast que luego, al examinar la cabecera IP, descubrirán que no iban dirigidas a ellos; esto produce una pequeña pérdida de eficiencia por el tiempo que el nivel de red emplea en analizar una trama que no iba dirigida a él, pero la probabilidad de que esto ocurra en la práctica es tan pequeña que la pérdida de eficiencia es despreciable [13]. Aun cuando se produzca coincidencia de direcciones MAC entre dos grupos diferentes nunca debe producirse por este motivo la entrega al nivel de transporte de datagramas que no vayan dirigidos al grupo multicast al que pertenece el host.

El soporte de tráfico multicast en routers es relativamente reciente, y existen aún pocas experiencias de redes con tráfico multicast en redes de área extensa en producción, casi todas ellas limitadas a redes académicas.

La mayor experiencia de routing multicast que ha habido en la Internet es la conocida como MBone (Multicast Backbone). La red MBone existe desde 1992 y se emplea principalmente con un conjunto de aplicaciones de videoconferencia. Las reuniones del IETF, congresos y todo tipo de eventos se transmiten regularmente por MBone. Hay retransmisiones de ámbito mundial, continental, nacional y regional.

A veces se quiere interconectar dos redes con tráfico multicast que están conectadas entre sí mediante una red que solo soporta tráfico unicast. En estos casos es posible construir un túnel entre dos routers de las redes multicast y enviar los datagramas multicast encapsulados en paquetes unicast; dado que estos paquetes son vistos como tráfico normal por la red unicast los routers multicast pueden manejarlos sin ningún problema. En estos casos se habla de 'islas' multicast unidas a través de túneles unicast. En parte la red MBone está construida mediante túneles de este tipo usando hosts UNÍX como routers multicast (existe software de routing multicast de libre distribución disponible para los principales sistemas operativos UNIX, como Linux, Solaris, Iris, etc.).

Un problema que se plantea con el tráfico multicast en MBone es la forma de limitar el ámbito o alcance de los paquetes. En principio un usuario puede estar interesado en realizar una emisión multicast en un ámbito restringido (por ejemplo a España únicamente). En MBone esto se puede resolver de dos formas: la antigua, aun bastante utilizada el campo TTL de la cabecera IP para limitar el alcance del datagrama. Los routers multicast que se encuentran en la frontera del ámbito correspondiente (en nuestro ejemplo los routers internacionales) restarán varias unidades al TTL de forma que esos paquetes no puedan salir al exterior. La solución más reciente a este problema consiste en asignar el ámbito de acuerdo con el rango de direcciones multicast de que se trate, y elegir la dirección de acuerdo con este criterio. Para este fin se ha reservado el rango de 239.0.0.0 a 239.255.255.255 según se especifica en el RFC 2365.

7.6 IPV6

Aunque la adopción de medidas paliativas como CIDR ha dado un respiro momentáneo en el problema del agotamiento del espacio de direcciones y tablas de routing, es evidente que hay que ampliar el campo dirección en la cabecera de los datagramas IP.

En un intento por resolver este problema el IETF empezó a trabajar ya en 1990 en una nueva versión de IP. Aunque fuera el más importante, la escasez de direcciones no era el único problema que presentaba el protocolo IP, por lo que ya puesto a diseñar un nuevo protocolo el IETF decidió abordar también otras deficiencias detectadas. Los objetivos planteados fueron los siguientes:

o Direcciones: Establecer un espacio de direcciones que no se agote en el futuro previsible.

o Eficiencia: Reducir el tamaño de las tablas de routing. Simplificar el protocolo (la cabecera IP) para permitir a los routers procesar los paquetes más rápidamente.

o Seguridad: Ofrecer mecanismos que permitan incorporar fácilmente en el protocolo medidas de seguridad (privacidad y validación) mediante técnicas criptográficas.

o Tipo de servicio: Manejar mejor los diferentes tipos de servicio, en especial para poder ofrecer garantías de Calidad de Servicio y para permitir el uso de aplicaciones en tiempo real.

o Multicasting: Facilitar el uso de aplicaciones multicast.

o Movilidad: Permitir la movilidad de un host sin necesidad de cambiar su dirección.

o Evolución: Contemplar un mecanismo que permita extender el protocolo en el futuro.

o Compatibilidad: Permitir la coexistencia del protocolo nuevo con el viejo.

El IETF hizo una convocatoria pública (RFC 1550) para que se presentaran propuestas de como podría ser el nuevo protocolo. De las propuestas iniciales se fueron descartando las consideradas menos interesantes, y finalmente la propuesta finalmente adoptada fue un híbrido de dos de las presentadas.

Durante el período en que se celebraban en el seno del IETF las discusiones sobre las diferentes propuestas el nuevo protocolo se denominó IPng o IP next generation (de la serie de televisión Star Trek cuya segunda parte recibió esa denominación [14]. Finalmente el nombre oficial elegido fue IP Versión 6 o abreviadamente IPv6 (el IP actualmente en uso es Versión 4, y la Versión 5 se había utilizado ya para un protocolo experimental denominado ST, STream protocol). El protocolo se especificó en el RFC 1883 publicado en diciembre de 1995; este RFC ha sido sustituido posteriormente por el RFC 2460 que introdujo pequeños cambios en la cabecera relativos al campo Differentiated Services, publicado en diciembre de 1998.

Uno de los aspectos más polémicos que rodearon la estandarización de IPv6 fue la decisión sobre el tamaño de las direcciones a utilizar. Se barajaron alternativas que iban desde ocho hasta 20 bytes. Probablemente la opción de 20 bytes era la más razonable, no porque hicieran falta direcciones tan grandes sino porque este era el formato utilizado en las direcciones OSI y existía ya un protocolo muy similar a IP que utilizaba este formato de direcciones, que era CLNP. De esta forma IPv6 podría haberse reducido simplemente a la adopción de CLNP, y de hecho esta opción llegó a plantearse seriamente en el seno del IAB. Pero cuando la noticia llegó a oídos del IETF se produjo un clamor en contra de CLNP, fundamentalmente por razones políticas: después de los años de enfrentamiento vividos entre los partidarios de los protocolos OSI y los de TCP/IP se consideraba inaceptable y políticamente incorrecto que el IAB adoptara CLNP como el IP del futuro, lo cual habría significado que después de todo había algo aprovechable en los protocolos OSI. Finalmente el IAB aceptó el requerimiento del IETF, desestimó la propuesta de adoptar CLNP y se creó un protocolo con direcciones de 16 bytes.

En el mercado existen ya varias implementaciones de IPv6 para hosts y para routers, aunque su uso hasta ahora se ha limitado a experiencias piloto.

IPv6 coincide con IPv4 en ofrecer un servicio de entrega de datagramas sin garantías, es decir 'best effort'. Se contemplan sin embargo algunas opciones que permiten ofrecer calidad de servicio.

IPv6 no es realmente compatible con IPv4 ya que utiliza un formato de cabecera diferente, pero lo es (con pequeñas modificaciones) con los demás protocolos de Internet. La implantación del nuevo protocolo se está realizando de forma gradual mediante la creación de 'islas' IPv6 en las que se utiliza el nuevo protocolo; para la interconexión de esas islas a través del backbone IPv4 se utilizan túneles, de forma similar a lo que se hace con la red MBone. La red experimental así formada se conoce como 6Bone (IPv6 Backbone) y empezó a funcionar en 1996. En España ya hay una red 6Bone funcionando entre varias universidades españolas desde 1997. La Universidad de Valencia se incorporó a esta red en 1998.

Los protocolos de routing se han tenido que modificar para tener en cuenta las características propias y el nuevo formato de direcciones que utiliza IPv6; así se ha creado por ejemplo RIPv6 y OSPFv6.

Muy brevemente algunas de las principales virtudes de IPv6 son las siguientes:

o Las direcciones son de 16 bytes, lo cual da un espacio de direcciones increíblemente grande, suficiente con creces para todo futuro uso previsible.

o La cabecera se simplifica, pasando de 13 a 8 campos [15]. Se acelera así el proceso en los routers.

o Se ha mejorado el soporte de los campos opcionales en la cabecera.

o La seguridad (validación y privacidad) es ahora una parte fundamental del protocolo.

o Se dan más facilidades que antes para especificar el tipo de servicio.

7.6.1 Direcciones en IPv6

Una dirección IPv6 está compuesta por 16 bytes. Los primeros bits identifican el tipo de dirección, de manera análoga a IPv4. Existen muchas clases de direcciones, pero no todas tienen asignado el mismo rango, y la mayoría están reservadas para usos futuros.

Se ha previsto un rango específico para direcciones IPv4. De esta forma cualquier dirección IPv4 puede incluirse en un datagrama IPv6.

Una parte del espacio de direcciones se reserva para distribución geográfica, de manera similar a como se hace actualmente en la Internet con CIDR.

Otra parte se ha reservado para repartir direcciones por proveedor. Se ha contemplado la posibilidad de que la Internet (o una parte de ella) evolucione hacia una red que interconecte las redes de los grandes proveedores a nivel mundial, siendo secundaria en este caso la ubicación geográfica. Se contempla para este caso una estructura de direcciones jerárquica con varios niveles.

No se ha previsto ninguna dirección específica para broadcast, ya que esto se considera un caso particular de multicast. Para las direcciones multicast se ha previsto también un rango específico, y en la propia dirección multicast se ha reservado un campo de 4 bits que permite especificar el ámbito o alcance que se pretende tenga la emisión. El ámbito puede valer entre 0 y 15; el valor 14 se utiliza para indicar todo el planeta, y el valor 15 podría eventualmente utilizarse para transmisiones multicast que abarquen el espacio interestelar. Esto es similar a lo que se hace en IPv4 cuando se limita el ámbito en base a la dirección (RFC 2365).

Además de envíos unicast y multicast pueden hacerse envíos anycast, en los que el paquete se envía a uno cualquiera de los miembros de un grupo, sin importar a cual. Esto permite por ejemplo acceder a un servidor multihomed haciendo balance de carga entre varias interfaces, o por aquella que esté mas cerca del solicitante. También facilita configuraciones redundantes donde un determinado servicio puede ser facilitado por mas de un servidor.

Se ha previsto un rango de direcciones de significado puramente local, equivalentes a las actuales redes privadas (intranets), para casos en que por razones de seguridad se quiera estar completamente aislado del exterior.

La escritura de direcciones de 16 bytes usando el sistema tradicional resulta muy farragosa, por ejemplo:

128.0.0.0.0.0.0.0.1.35.69.103.137.171.205.239

Para evitarlo se ha diseñado una notación en la que las direcciones se escriben como 8 grupos de 4 dígitos hexadecimales separados por dos puntos; por ejemplo la dirección anterior se escribiría así:

8000:0000:0000:0000:0123:4567:89AB:CDEF

Dado que muchas direcciones contendrán gran cantidad de ceros se ofrece la posibilidad de utilizar una notación abreviada en la que los ceros a la izquierda pueden omitirse, y además si uno o más grupos tienen todos los dígitos a cero se pueden omitir poniendo en su lugar dobles dos puntos (::). Así por ejemplo la dirección anterior se escribiría:

8000::123:4567:89AB:CDEF

Para evitar ambigüedad la notación abreviada :: sólo puede utilizarse una vez en una dirección.

Por último, para facilitar la escritura de direcciones IPv4 se prevé también el uso de la notación decimal si se desea utilizando puntos, por ejemplo :

::147.156.11.11

Gracias a la mucho mayor longitud del campo dirección en IPv6 se pueden reservar los últimos bytes de la dirección para incluir una parte local globalmente única en la dirección, que normalmente es una dirección MAC IEEE [16]. Este ‘truco’ (utilizado ya en redes OSI y ATM) permite la autoconfiguración de los sistemas: el equipo fija la parte host de su dirección a partir de la dirección contenida en su tarjeta de red y escucha por el cable para que el router le informe de la parte de red, con lo que la conexión de nuevos equipos a una red puede hacerse verdaderamente 'Plug-and-Play'. Una empresa que estuviera conectada a Internet a través de un proveedor podría cambiar de proveedor y cambiar todas sus direcciones sin más que cambiar en el router la parte de red de la dirección. Los ordenadores obtendrían el nuevo prefijo del router y le añadirían cada uno la parte host correspondiente. El uso de la dirección MAC como sufijo garantiza que la dirección sea única. La autoconfiguración también facilita grandemente la movilidad de equipos.

Con 16 bytes es posible crear 2¹²⁸ direcciones, equivalente a aproximadamente 3 x 10³⁸; aunque el reparto produce mucho despilfarro es evidente que IPv6 no andará escaso de direcciones en mucho tiempo.

7.6.2 La cabecera de IPv6

Para tener una idea más exacta de las características de IPv6 vamos a repasar brevemente los campos de la cabecera, cuya estructura aparece en la tabla 3.8.

Campo	Longitud (bits)
Versión	4
DS (Differentiated Services)	8
Etiqueta de flujo	20
Longitud de carga útil	16
Siguiente cabecera	8
Límite de saltos	8
Dirección origen	128
Dirección destino	128

Tabla 3.8.- Formato de la cabecera de un datagrama IP Versión 6

El campo versión vale siempre 6. En principio este campo debería servir para distinguir las versiones de IP, de forma que todas pudieran identificarse como un mismo protocolo a nivel de enlace, por ejemplo utilizando el mismo valor de Ethertype. En la práctica muchas implementaciones de IPv4 no comprueban este campo sino que suponen que el datagrama es IPv4 cuando la cabecera del nivel de enlace especifica protocolo IP, por lo que a pesar de existir el campo versión es necesario asignar a IPv6 un valor propio en el nivel de enlace, como si se tratara de un protocolo diferente de IPv4.

El campo DS (Differentiated Services) se utiliza para especificar parámetros de Calidad de Servicio de acuerdo con la arquitectura Diffserv que veremos más adelante.

El campo etiqueta de flujo permite identificar los paquetes que pertenecen a una sesión concreta entre dos hosts, normalmente para solicitar un trato preferente o una determinada Calidad de Servicio. A este campo y al concepto de flujo nos referiremos más adelante cuando hablemos de Calidad de Servicio.

El campo longitud de carga útil indica el tamaño del paquete en bytes, excluidos los 40 bytes de la cabecera. El valor máximo es 65535. El paquete máximo es pues 65575.

El campo siguiente cabecera indica si esta cabecera esta seguida por alguna de las cabeceras opcionales. Si no hay cabeceras opcionales este campo indica el protocolo del nivel de transporte al que pertenece este paquete, para lo cual utiliza los mismos códigos numéricos que en IPv4 (ver tabla 3.2).

El campo límite de saltos equivale al antiguo campo TTL, pero se ha decidido ponerle un nombre que refleje su uso real. Como en IPv4 el campo tiene 8 bits, por lo que el máximo número de saltos que puede especificarse es también 255. Algunos opinaban que este valor era demasiado bajo y que en algunos casos podría plantear problemas. Actualmente ya hay situaciones en la Internet donde se esta próximo a los 64 saltos.

Por último, los campos dirección de origen y dirección de destino corresponden a las direcciones de 16 bytes que hemos descrito.

Los campos de la cabecera IPv4 que han desaparecido de la IPv6 son los siguientes:

IHL (Internet Header Length): este campo no existe pues la cabecera tiene ahora una longitud fija.

El campo protocolo no aparece pues su función la desempeña el campo siguiente cabecera.

El campo checksum se ha suprimido ya que no se consideró justificada la pérdida de rendimiento que supone el cálculo del checksum en cada salto ante la rara eventualidad de que se produzca un error en el nivel de red, tomando en cuenta que normalmente tanto el nivel de enlace como el de transporte realizan su propia comprobación de errores, por lo que realmente el checksum del datagrama IP no protege de errores de transmisión sino solamente de errores internos que se puedan producir en el router (por fallos en la memoria RAM por ejemplo). La supresión de este campo fue algo muy debatido durante la elaboración del nuevo estándar.

Todos los campos relativos a fragmentación han desaparecido de la cabecera porque en IPv6 la fragmentación se controla mediante cabeceras adicionales o extendidas; además en IPv6 todos los nodos han de aceptar paquetes de 1280 bytes como mínimo y sólo se permite la fragmentación en origen, es decir el emisor debe generar datagramas suficientemente pequeños para que puedan llegar a su destino sin fragmentaciones adicionales. Normalmente el emisor realizará el Path MTU Discovery, como ya era habitual en muchas implementaciones de IPv4.

7.6.3 Cabeceras extendidas

En IPv4 la cabecera puede contener algunos campos opcionales, principalmente para diagnóstico de problemas de routing, pero debido a su escasa longitud esos campos son poco utilizados. El sistema es demasiado rígido y poco eficiente, ya que los campos opcionales tienen que ser procesados en todos los routers del trayecto. En IPv6 se ha habilitado un mecanismo más flexible y eficiente; las cabeceras opcionales aparecen como cabeceras adicionales al final de la cabecera estándar; su presencia queda indicada por el campo siguiente cabecera, que en caso de que no haya opciones inidcará el protocolo de transporte (normalmente TCP o UDP). De esta forma los campos opcionales en IPv6 pueden extenderse cuando se considere necesario. Además se prevé un mecanismo por el cual se puede indicar si las opciones deben ser procesadas por todos los routers del trayecto o solo por el ultimo, lo cual permite una reducción significativa del trabajo a desarrollar por los routers intermedios cunado se trata de una opción que solo debe ser procesada por el nivel de red en el host de destino.

La cabecera salto-a-salto indica información que debe ser examinada por todos los routers por los que transite este datagrama. Hasta ahora solo se le ha definido a esta cabecera una opción, que permite especificar datagramas de longitud superior a 64 KB; estos datagramas (que pueden llegar a tener hasta 4 GB) se conocen como jumbogramas.

La cabecera routing realiza las funciones combinadas del strict source routing y loose source routing de IPv4; el máximo número de direcciones que pueden especificarse es de 24.

La cabecera fragment se utiliza cuando hay que fragmentar un datagrama; el mecanismo utilizado es muy similar al de IPv4 (campos Identificación, Desplazamiento del fragmento y MF), con la diferencia de que en IPv6 solo se permite la fragmentación en origen. De esta forma se simplifica notablemente la complejidad de proceso en los routers.

La cabecera authentication permite el uso de técnicas criptográficas para incorporar un mecanismo de firma digital por el cual el receptor del paquete puede estar seguro de la autenticidad del emisor.

La cabecera encrypted security payload permite el envío de información encriptada para que solo pueda ser leída por el destinatario. Evidentemente la encriptación afecta únicamente a los datos, no incluye la cabecera del datagrama puesto que ésta ha de ser leída e interpretada por cada router por el que pasa.

7.7 EJERCICIOS

1. Indique si es verdadera o falsa cada una de las siguientes afirmaciones:

a) Cuando un router IP detecta un error en el checksum de un datagrama envía un mensaje ICMP al emisor notificándole para que lo reenvíe.

b) Una de las ventajas de IP es su capacidad de reencaminar el tráfico por rutas alternativas en caso de problemas en la red; sin embargo esta característica solo esta disponible cuando se utiliza un protocolo de routing, no cuando se emplean rutas estáticas.

c) El protocolo OSPF permite crear niveles jerárquicos dentro de un sistema autónomo.

d) Los protocolos de routing empleados dentro de un sistema autónomo, tales como RIP u OSPF, no son apropiados para su utilización entre sistemas autónomos debido a los mayores retardos de las comunicaciones en este caso, al tratarse normalmente de enlaces que cubren grandes distancias.

e) En IP los datagramas pueden llegar desordenados y son en todo caso los niveles superiores (TCP por ejemplo) los que se ocupan de reordenar los datos; sin embargo cuando hay fragmentación en ruta los fragmentos deben llegar necesariamente en orden puesto que el datagrama original se ha de recomponer a nivel IP al no tener el nivel de transporte conocimiento de la fragmentación, por lo que carece en este caso de mecanismos para detectar los cambios de orden.

f) Cuando se crea una subred con direcciones IP el numero de hosts es siempre dos menos que el espacio de direcciones correspondiente, es decir, si se utilizan n bits para la parte host el numero de hosts posibles es de 2ⁿ-2.

g) El protocolo BOOTP permite averiguar la dirección MAC que corresponde a una dirección IP dada.

h) El protocolo ARP solo es necesario en redes broadcast.

2. Suponga que se tiene una red formada por tres routers, X, Y y Z, unidos entre sí mediante tres líneas de 64 Kb/s en topología triangular. ¿Que diferencia supondría el uso de routing dinámico o estático desde el punto de vista de la eficiencia y fiabilidad de la comunicación entre ellos?

3. Un datagrama IP que utiliza la opción source routing llega a un punto en la red en el que tiene que ser fragmentado. Tendrá este campo opcional que copiarse en cada uno de los fragmentos, o bastará con que se copie en el primero de ellos únicamente?

4. En IPv6 se modifica sustancialmente la cabecera de los datagramas IP, debido especialmente al cambio en la longitud de las direcciones de 32 a 128 bits. Como afectará esto al funcionamiento de los puentes transparentes? Y al de los puentes con encaminamiento desde el origen?

5. Diga cual(es) de los siguientes protocolos permite(n) realizar asignación dinámica de direcciones IP:

A: _ BOOTP B: _ DHCP C: _ RARP

D: _ ARP E: _ PPP F: _ SLIP

6. Un sistema autónomo es:

§ A: _ Una red que utiliza protocolo TCP/IP

§ B: _ Un conjunto de routers que intercambian información de routing mediante un protocolo común

§ C: _ Un conjunto de routers y hosts con una adminstración centralizada

§ D: _ La parte de la Internet que corresponde a un Proveedor

7. La fragmentación en ruta es una causa de ineficiencia en redes IP. Algunos hosts intentan evitarla aplicando la técnica conocida como descubrimiento de la MTU del trayecto ('path MTU discovery') consistente en enviar datagramas de prueba con el bit DF (Don't Fragment) puesto; por los mensajes de error recibidos es posible averiguar el tamaño máximo de datagrama que se puede utilizar.

Algunos hosts cuando utilizan el 'path MTU discovery', una vez han averiguado la MTU del trayecto realizan dos acciones no habituales:

§ Siguen poniendo a 1 el bit DF en todos los datagramas que envían.

§ De vez en cuando envían un datagrama de un tamaño mayor que el máximo permitido por el trayecto, con el bit DF puesto.

¿Podría dar alguna razón que justifique estos comportamientos?

8. A continuación aparece el fichero de configuración de un router. Dibuje el croquis correspondiente indicando la dirección IP de cada interfaz, que rangos de direcciones está accesible por cada una de ellas, y todo lo que pueda inferir sobre la topología de la red a partir de la información facilitada. Realice los comentarios que considere oportunos sobre los comandos y su significado.

Notas:

· La configuracion presentada es ficticia, no corresponde a ninguna configuración real.

· Se utilizan únicamente rutas estáticas.

· En la configuración se utilizan máscaras de tamaño variable.

----------------------- FICHERO DE CONFIGURACION -----------------

version 11.1

hostname router

ip subnet-zero

interface Ethernet0

description conexion red local UV

ip address 147.156.1.11 255.255.128.0

interface Ethernet1

description conexion aula SIUV

ip address 147.156.147.129 255.255.255.224

interface serial0

description primera conexion Magisterio

ip address 192.168.1.1 255.255.255.252

bandwidth 64

interface serial1

description segunda conexion Magisterio

ip address 192.168.1.5 255.255.255.252

bandwidth 64

interface serial2

description conexion UJI

ip address 130.206.211.5 255.255.255.252

bandwidth 2048

interface serial3

description salida al resto del mundo

ip address 130.206.211.2 255.255.255.252

bandwidth 2048

! Ruta host

ip route 130.206.211.174 255.255.255.255 147.156.147.130

! Subred Magisterio (balance de trafico entre ambas lineas)

ip route 147.156.198.0 255.255.254.0 192.168.1.2

ip route 147.156.198.0 255.255.254.0 192.168.1.6

! Clase C del IATA.CSIC (Paterna)

ip route 193.145.246.0 255.255.255.0 147.156.15.9

! Red de la UJI

ip route 150.208.0.0 255.255.0.0 130.206.211.6

! Ruta por defecto

ip route 0.0.0.0 0.0.0.0 130.206.211.1

! Ruta loopback

ip route 127.0.0.1 255.255.255.255 Null0

9. Suponga que en la configuración del ejercicio anterior se suprime la línea:

ip route 0.0.0.0 0.0.0.0 130.206.211.1

Indique que ocurriría en este caso con un datagrama que llegara a este router por la interfaz Ethernet1 que tuviera como dirección de origen la 147.156.147.132 y como dirección de destino la 138.247.12.32.

¿Y que pasaría si llegara un datagrama por la interfaz serial3 con dirección de origen la 138.247.12.32 y de destino la 147.156.147.132?

10. Una empresa tiene una red local conectada a Internet mediante un router que solo posee dos interfaces, una ethernet y una puerta serie conectada a una línea punto a punto de 2048 Kb/s. La configuración del router es la siguiente:

version 11.1

hostname router

interface Ethernet0

description conexion red local

ip address 190.190.190.1 255.255.255.0

interface serial0

description salida al resto del mundo

ip address 192.168.200.6 255.255.255.252

bandwidth 2048

! Ruta por defecto

ip route 0.0.0.0 0.0.0.0 192.168.200.5

! Ruta loopback

ip route 127.0.0.1 255.255.255.255 Null0

Se desea sustituir el router por otro, también con una interfaz serie y una ethernet.

Para hacer el cambio de la manera mas sencilla posible el administrador de la red ha preparado el nuevo router con una configuración idéntica al antiguo; de esta forma los usuarios con sus ordenadores configurados con la dirección 190.190.190.1 como salida (gateway) al exterior no tendrán que modificar nada. Calcula el administrador que con la ayuda de otra persona puede sustituir físicamente un router por el otro en cinco segundos, tiempo que espera pase desapercibido por sus usuarios, acostumbrados al lento funcionamiento de la Internet (el funcionamiento no orientado a conexión de IP permite hacer estas maniobras sin perturbar la red de forma apreciable). El administrador decide pues hacer el cambio en horas normales de funcionamiento.

El cambio se efectúa según lo previsto, y después de hacerlo el administrador va a un PC próximo, lo enciende y comprueba que se puede conectar a Internet a través del nuevo router sin problemas, por lo que considera terminada con éxito la tarea. Justo en ese momento empieza a recibir multitud de llamadas de los usuarios que se quejan de no poder salir a Internet. El administardor revisa y comprueba la configuración y todas las conexiones, pero no encuentra ningún error; pasados unos minutos, y sin que el administrador haya hecho nada, los usuarios empiezan a poder conectar de nuevo con el exterior y poco a poco el teléfono deja de sonar.

Podría decir por que ha fallado el plan? Como debería haber procedido el administrador para hacer el cambio en horas normales de funcionamiento sin afectar el servicio de forma apreciable?

11. La siguiente es una configuración hipotética de un router:

Version 11.1

hostname centro-remoto

ip subnet-zero

ip classless

interface Ethernet0

description conexion LAN

ip address 194.125.1.63 255.255.255.192

interface Ethernet1

description conexion LAN

ip address 195.0.0.195 255.255.255.128

interface serial0

description conexion WAN

ip address 195.100.1.2 255.255.255.252

interface serial1

description conexion WAN

ip address 197.160.1.1 255.255.255.252

ip route 157.34.33.0 255.255.255.255 195.0.0.199

ip route 160.87.34.0 255.255.248.0 195.100.1.1

ip route 198.0.0.0 255.254.0.0 197.160.1.2

ip route 0.0.0.0 0.0.0.0 195.100.1.1

Comente el significado de los comandos que aparecen.

Dibuje el esquema de la red correspondiente.

En los parámetros de algunos comandos existen valores inadecuados. Localícelos y coméntelos.

12. Una empresa de consultoría informática tiene su oficina principal en Madrid, con sucursales en Barcelona, Bilbao y Sevilla. Cada una de las cuatro oficinas tiene una red local basada en los protocolos TCP/IP. Se desea unirlas todas entre sí, para lo cual se realiza un estudio necesidades y se evalúa el costo de diversas alternativas. Además se quiere dar acceso a Internet a todas las oficinas. Como resultado de todo ello se decide montar una red con la siguiente topología:

Internet

|128 Kb/s

| 256 Kb/s 128 Kb/s

Madrid ------------------- Barcelona ------------- Bilbao

|128 Kb/s

Sevilla

Se prevé un máximo de 100 ordenadores en la oficina de Madrid, 50 en la de Barcelona, 25 en la de Bilbao y 20 en la de Sevilla. Se necesita que todos los ordenadores tengan acceso directo a Internet, es decir, tengan números IP públicos o 'legales'. Para ello la empresa ha obtenido del NIC la red 194.100.100.0.

Se le pide que:

a) Diseñe un esquema de reparto de direcciones IP entre las diferentes oficinas que satisfaga los requerimientos planteados.

b) Rellene los campos que faltan en la siguiente configuración, correspondiente al router Cisco de Madrid:

Version 11.1

hostname Router-Madrid

ip subnet-zero

interface Ethernet0

description conexion LAN Madrid

ip address ............ ............

interface serial0

description conexion WAN Internet

bandwidth 128

ip address ............ ............

interface serial1

description conexion WAN Barcelona

bandwidth 256

ip address ............ ............

interface serial2

description conexion WAN Sevilla

bandwidth 128

ip address ............ ............

ip route ............ ............ ............

ip route 0.0.0.0 ............ ............

ip route 127.0.0.1 ............ ............

13. Una empresa farmacéutica tiene una red local Ethernet con varios ordenadores, y tiene contratada una conexión a Internet con el proveedor X por la cual todos los ordenadores pueden enviar y recibir del exterior datagramas IP, sin restricciones. Los ordenadores tienen números de la red 199.199.199.0 (máscara 255.255.255.0) asignada por el proveedor a la empresa, dentro del rango que le corresponde. La conexión física se realiza mediante una línea punto a punto, para lo cual en la red local hay un router con una interfaz ethernet y una serie. El router tiene una segunda interfaz serie actualmente no utilizada.

El proveedor X ha ido ampliando el número de usuarios sin aumentar de forma proporcional la infraestructura, con lo cual ha ido bajando la calidad de servicio que ofrece. Como consecuencia de ello la empresa decide contratar una segunda conexión a Internet con el proveedor Y, mas caro pero que ofrece un servicio de mayor calidad. El proveedor Y asigna a la empresa la red 200.200.200.0 (máscara 255.255.255.0), y la conexión se realiza también mediante una línea punto a punto, como en el caso del proveedor X.

A pesar de tener una nueva conexión con el proveedor Y se quiere mantener la conexión al proveedor X dado su bajo costo, para utilizarla en servicios poco críticos, como por ejemplo las news. Algunas máquinas de la red local mantendrán direcciones de la red 199.199.199.0, y deberán utilizar el proveedor X, mientras que a otras se les asignarán direcciones de la red 200.200.200.0 y deberán utilizar el proveedor Y.

Diga si para efectuar la conexión al proveedor Y es posible utilizar la interfaz serie que queda libre en el router existente, o si por el contrario es necesario adquirir un segundo router para dicha conexión. Explique su respuesta.

Escriba un ejemplo de la configuración que habría(n) de tener el (los) router(s) necesario(s) para realizar las conexiones indicadas. En todo momento se utiliza routing estático. Recuerde que una interfaz puede tener mas de una dirección IP.

7.8 SOLUCIONES

S1.-

a) Falsa. El protocolo IP no implementa ningún mecanismo de reenvío de la infromación. En caso de error en la comprobación del checksum el datagrama es simplemente descartado.

b) Verdadera. En caso de rutas estáticas sería necesaria una reconfiguración manual de los equipos para modificar la ruta utilizada.

c) Verdadera. Los niveles jerárquicos se establecen mediante las denominadas áreas.

d) Falsa. Entre sistemas autónomos (ASes) se requieren otros protocolos de routing debido a la necesidad de establecer reglas de tipo 'político', por ejemplo un proveedor que no quiere ser utilizado como vía de tránsito para la comunicación entre otros dos proveedores con los cuales está conectado.

e) Falsa. Los datagramas en IP siempre pueden llegar desordenados, independientemente de que se trate de fragmentos o de datagramas enteros. En caso de fragmentación el campo offset permite al nivel IP del receptor reordenar adecuadamente los fragmentos.

f) Verdadera. Se reservan dos direcciones para usos especiales: la que tiene el campo host todo a ceros para indicar la subred, y la que lo tiene todo a unos para transmisiones broadcast dentro de la subred. Esta restricción se aplica siempre, incluso cuando se especifica subnet-zero; subnet-zero permite eludir una restricción similar que normalmente se aplica al campo subred.

g) Falsa. Es lo contrario: BOOTP permite averiguar la dirección IP que corresponde a una dirección MAC (normalmente la de la máquina que está haciendo la consulta).

h) Verdadera. En redes punto a punto cada ordenador sabe por sus tablas de routing por donde ha de acceder a una dirección de red determinada.

S2.-

Con routing dinámico el tráfico podría reencaminarse por la ruta alternativa en caso de caída de uno de los tres enlaces. Además el tráfico se podría repartir de forma mas o menos homogénea entre las dos rutas posibles, con lo que en el caso límite se podría llegar a tener una capacidad de 128 Kb/s entre dos nodos en el supuesto de que el otro no generara ni recibiera ningún tráfico. Ninguna de estas cosas sería posible con routing estático. Por otro lado el uso de routing dinámico provocaría una pequeña proporción de tráfico en la red debido a la información intercambiada por los routers, aunque esto se vería sobradamente compensado por las ventajas antes mencionadas. Así pues el routing dinámico permitiría tener una red mas fiable y eficiente.

S3.-

Tendrá que copiarse en todos, ya que cada fragmento puede seguir en principio una ruta diferente y solo así podremos estar seguros de que se respeta la ruta marcada.

S4.-

No afecta en absoluto a ninguno de los dos puesto que tanto los puentes transparentes como los de encaminamiento desde el origen utilizan direcciones MAC, que son direcciones a nivel de enlace. Las direcciones IPv4 o IPv6 son direcciones a nivel de red, que van en la cabecera del datagrama, y no son visibles para los puentes ya que forman parte de lo que se consideran 'datos'.

S5.-

DHCP y PPP

S6.-

B: Un conjunto de routers que intercambian información de routing mediante un protocolo común

S7.-

En IP la ruta seguida por los datagramas puede variar, ya que las tablas de encaminamiento de los routers pueden verse modificadas, bien porque se esté utilizando un protocolo de routing dinámico que reacciona a los cambios que se producen en la red, o porque utilizando routing estático se modifiquen 'en caliente' las tablas de encaminamiento de algún router del trayecto. Por tanto es posible que no todos los datagramas de una sesión entre dos hosts discurran por la misma ruta.

Poniendo a 1 el bit DF en todos los datagramas el host emisor comprueba si algún datagrama es fragmentado debido a alteraciones en la ruta que causen una reducción del MTU, cosa que de otro modo podría pasar desapercibida; al estar puesto el bit DF el intento de fragmentación provocaría que el datagrama fuera rechazado por el router, devolviendo un mensaje ICMP al host emisor que así se daría cuenta de la situación.

Análogamente la emisión cada cierto tiempo de un datagrama con el bit DF puesto de tamaño mayor que la MTU negociada, permite al host emisor detectar si la MTU del trayecto ha aumentado debido a las modificaciones que se puedan haber producido en la ruta durante la sesión.

S8.-

Se intercalan los comentarios en el fichero de configuración.

----------------------- FICHERO DE CONFIGURACION -----------------

version 11.1

hostname router

Especifica la versión de software utilizada y el nombre del router

ip subnet-zero

Indica que se permite el uso no estándar de poner completamente a ceros o a unos el campo subred

interface Ethernet0

description conexion red local UV

ip address 147.156.1.11 255.255.128.0

Indica que la interfaz Ethernet0 tiene la dirección IP 147.156.1.11 y que esta interfaz está integrada en (y por tanto da acceso a) una subred formada por las direcciones 147.156.0.0 hasta 147.156.127.255

interface Ethernet1

description conexion aula SIUV

ip address 147.156.147.129 255.255.255.224

La interfaz Ethernet1 tiene la dirección IP 147.156.147.129 y está integrada en una subred formada por las direcciones 147.156.147.128 hasta 147.156.147.159

interface serial0

description primera conexion Magisterio

ip address 192.168.1.1 255.255.255.252

bandwidth 64

La interfaz serial0 tiene la dirección IP 192.168.1.1 y está integrada en una subred formada por las direcciones 192.168.1.0 hasta 192.168.1.3; corresponde a una línea de 64 Kb/s que en el otro lado tiene la dirección 192.168.1.2 (las direcciones 0 y 3 están reservadas pues corresponden al campo host todo a ceros y todo a unos, respectivamente).

interface serial1

description segunda conexion Magisterio

ip address 192.168.1.5 255.255.255.252

bandwidth 64

La interfaz serial1 tiene la dirección IP 192.168.1.5 y está integrada en una subred formada por las direcciones 192.168.1.4 hasta 192.168.1.7. Corresponde a una línea de 64 Kb/s que en el otro lado tiene la dirección 192.168.1.6.

interface serial2

description conexion UJI

ip address 130.206.211.5 255.255.255.252

bandwidth 2048

La interfaz serial2 tiene la dirección IP 130.206.211.5 y está integrada en una subred formada por las direcciones 130.206.211.4 hasta 130.206.211.7. Corresponde a una línea de 2048 Kb/s que en el otro lado tiene la dirección 130.206.211.6.

interface serial3

description salida al resto del mundo

ip address 130.206.211.2 255.255.255.252

bandwidth 2048

La interfaz serial3 tiene la dirección IP 130.206.211.2 y está integrada en una subred formada por las direcciones 130.206.211.0 hasta 130.206.211.3. Corresponde a una línea de 2048 Kb/s que en el otro lado tiene la dirección 130.206.211.1.

! Ruta host

ip route 130.206.211.174 255.255.255.255 147.156.147.130

Esta es una ruta host, que indica la ruta a seguir para el destino 130.206.211.174; las rutas host tienen máxima prioridad, por lo que esta se seguirá independientemente de lo que indiquen otras rutas declaradas para la red 130.206 o para sus posibles subredes.

! Subred Magisterio (balance de trafico entre ambas lineas)

ip route 147.156.198.0 255.255.254.0 192.168.1.2

ip route 147.156.198.0 255.255.254.0 192.168.1.6

Estas dos rutas indican que todos los datagramas destinados a direcciones en el rango 147.156.198.0-147.156.199.255 deberán enviarse por las interfaces serial0 y serial1, realizando balance de tráfico entre ambas líneas.

! Clase C del IATA.CSIC (Paterna)

ip route 193.145.246.0 255.255.255.0 147.156.15.9

Indica que la red clase C 193.145.246.0 está accesible a través de la dirección 147.156.15.9. Por información dada anteriormente el router sabe que dicha dirección está accesible a través de la interfaz Ethernet0.

! Red de la UJI

ip route 150.208.0.0 255.255.0.0 130.206.211.6

La red 150.208.0.0 (una clase B completa) está accesible a través de la dirección 130.206.211.6; por la información anterior el router ya sabe que dicha dirección corresponde al otro extremo de la interfaz serial2.

! Ruta por defecto

ip route 0.0.0.0 0.0.0.0 130.206.211.1

Esta instrucción indica que todo datagrama que no haya podido ser enrutado aplicando alguna de las rutas explícitas (de red o de host) debe enviarse a la dirección 130.206.211.1; por la información dada en las instrucciones anteriores el router ya sabe que dicha dirección corresponde al otro extremo de la línea a la que está conectada la interfaz serial3.

! Ruta loopback

ip route 127.0.0.1 255.255.255.255 Null0

Esta instrucción, que corresponde a una ruta host, indica que cualquier datagrama dirigido a la dirección 127.0.0.1 deberá descartarse, de acuerdo con lo que especifican los estándares Internet.

Obsérvese que para su aplicación las instrucciones ip route se clasifican previamente en tres categorías:

· Rutas host: se caracterizan por tener la máscara toda a unos (255.255.255.255)

· Rutas red: se caracterizan por tener máscaras con parte a ceros y parte a unos

· Ruta por defecto: se caracteriza por tener la máscara toda a ceros (0.0.0.0)

Independientemente de su ubicación en el fichero de configuración siempre se aplican por este orden: primero las reglas correspondientes a rutas host, en segundo lugar las rutas de red, y por último la ruta por defecto.

Obsérvese que las máscaras que acompañan a la dirección IP de cada interfaz indican de manera implícita la red o subred en la que dicha interfaz está integrada; por tanto no es necesario incluir una instrucción ip route para indicar por donde se debe encaminar el tráfico dirigido a dichas direcciones.

S9.-

En el caso de un datagrama de 147.156.147.132 a 138.247.12.32 entraría en el router por la interfaz Ethernet1 y el router buscaría alguna entrada 'ip route' que le permitiera saber por donde enviarlo. Al no haber ninguna entrada que incluya dicha dirección (pues se ha suprimido la ruta por defecto) el router descartará el datagrama y enviará un comando ICMP DESTINATION UNREACHABLE al host origen, esto es a la dirección 147.156.147.132. Obsérvese que todas las decisiones de encaminamiento se toman en base a la dirección de destino; normalmente el router solo utilizará la dirección de origen contenida en el datagrama cuando tenga que devolver al emisor algún mensaje ICMP.

En el caso del datagrama de 138.247.12.32 dirigido a 147.156.147.132 sería encaminado correctamente a la interfaz Ethernet1, ya que el router sabe que dicha dirección debe estar accesible a través de esa interfaz.

Tenemos en este caso un ejemplo de rutas asimétricas: mientras que en un sentido no es posible entregar los datagramas en el otro la red funciona sin problemas. Sin embargo la mayoría de las aplicaciones requieren comunicación full dúplex para su correcto funcionamiento, por lo que en la práctica un error como este casi siempre habría supuesto la imposibilidad de comunicación entre ambas direcciones.

S10.-

El problema ocurrido se debe a que en el momento de reemplazar el router viejo por el nuevo los ordenadores que estaban trabajando con la Internet tenían en su memoria la tabla ARP cache, esto es la equivalencia entre direcciones IP y direcciones MAC; al cambiar el router viejo por el nuevo se mantenía la dirección IP, pero se modificaba la dirección MAC puesto que cada interfaz Ethernet tiene una dirección diferente, pero los usuarios que utilizaban la tabla ARP existente en su cache intentaban salir al exterior buscando el router viejo, ahora desconectado de la red.

Para solucionarlo se podía haber hecho la sustitución en los siguientes pasos:

I. Configurar el nuevo router con idéntica configuración al viejo, pero sin conectarlo a la red.

II. Cargar en el router viejo la siguiente configuración (hemos marcado con negrita las partes modificadas o añadidas respecto a la configuración original):

version 11.1

hostname router

interface Ethernet0

description conexion red local

ip address 190.190.190.100 255.255.255.0

interface serial0

shutdown

description salida al resto del mundo

ip address 192.168.200.6 255.255.255.252

bandwidth 2048

! Ruta por defecto

ip route 0.0.0.0 0.0.0.0 190.190.190.1

! Ruta loopback

ip route 127.0.0.1 255.255.255.255 Null0

III. Inmediatamente después enchufar a la red Ethernet el nuevo router, desenchufar la línea serie del router viejo y enchufarla al router nuevo. Mantener enchufado a la Ethernet el router viejo hasta pasados quince minutos.

De esta forma el router nuevo aceptaría todas las conexiones que se produjeran a partir de ese momento, mientras que los ordenadores que ya estuvieran trabajando anteriormente y que tuvieran en su tabla ARP la dirección MAC del router viejo seguirían accediendo a éste, el cual reencaminaria los datagramas a su nuevo destino. Pasados unos minutos las entradas de la tabla ARP se habrán renovado, por lo que a partir de ese momento ya sería posible desconectar completamente el router viejo.

S11.-

Version 11.1

Indica la versión del software utilizado

hostname centro-remoto

Indica el nombre del router

ip subnet-zero

Indica que se puede infringir la regla que prohibe utilizar los valores extremos (todo ceros o todo unos) del campo subred.

ip classless

Indica que el software del router soporta CIDR (Classless InterDomain Routing)

interface Ethernet0

description conexion LAN

ip address 194.125.1.63 255.255.255.192

Define la interfaz de conexión a red ethernet. A la vista de la máscara utilizada esta ethernet comprende un rango de 64 direcciones que por la dirección de esta interfaz se deduce que debe ser del 194.125.1.0 al 194.125.1.63; de estas solo 62 son aprovechables, ya que la primera y la última estan reservadas (subred y broadcast). La dirección IP de esta interfaz es incorrecta ya que corresponder a la dirección broadcast de la subred (campo host todo a unos). La interfaz debería tener una dirección en el rango 194.125.1.1 a 194.125.1.62.

interface Ethernet1

description conexion LAN

ip address 195.0.0.195 255.255.255.128

Interfaz de conexión a red ethernet, con un rango de 128 direcciones: 195.0.0.128 a 195.0.0.255.

interface serial0

description conexion WAN

ip address 195.100.1.2 255.255.255.252

Interfaz de conexión WAN. Subred formada por cuatro direcciones, de la 195.100.1.0 a la 195.100.1.3. Como solo dos direcciones son aprovechables la dirección del otro lado de la línea (del otro router) ha de ser la 195.100.1.1.

interface serial1

description conexion WAN

ip address 197.160.1.1 255.255.255.252

Interfaz WAN. Rango 197.160.1.0 a 197.160.1.3. La interfaz del otro lado tiene que ser 197.160.1.2.

ip route 157.34.33.0 255.255.255.255 195.0.0.199

Ruta host (máscara toda a unos). Los datagramas dirigidos a 157.34.33.0 se enviarán a 195.0.0.199, que es un host conectado a la ethernet1.

ip route 160.87.34.0 255.255.248.0 195.100.1.1

Esta parece ser una subred de una clase B que esta accesible a través de la interfaz serial0. Por la máscara utilizada se emplean 5 bits para la parte subred y 11 para la parte host, sin embargo la dirección 160.87.34.0 no tiene a cero los últimos 11 bits, por lo que no es una dirección de red válida para dicha máscara. Un valor válido habría sido por ejemplo 160.87.32.0.

ip route 198.0.0.0 255.254.0.0 197.160.1.2

Esta ruta dirige a la interfaz serial1 todos los datagramas que lleven una dirección de destino comprendida en el rango de 198.0.0.0 a 198.1.255.255. Se está haciendo agregación de direcciones (mediante CIDR) puesto que se trata de dos redes clase C diferentes.

ip route 0.0.0.0 0.0.0.0 195.100.1.1

Esta es la ruta por defecto, que indica que cualquier datagrama cuya dirección no sea resuelta por la rutas anteriores deberá ser enviado por la interfaz serial0.

S12.-

Dado que el número de direcciones de una subred IP ha de ser necesariamente potencia entera de 2 (para que pueda identificarse mediante una máscara común), las subredes mínimas que podemos asignar en este caso son las siguientes:

Oficina	Rango	Rango útil	Máscara
Madrid	128	126	255.255.255.128
Barcelona	64	62	255.255.255.192
Bilbao	32	30	255.255.255.224
Sevilla	32	30	255.255.255.224

Para hacer esto con la red clase C de que disponemos es preciso crear máscaras de tamaño variable y utilizar todas las subredes, incluídas las que tienen el campo subred todo a ceros y todo a unos, es decir suprimir la restricción subred cero. El reparto podría ser por ejemplo el siguiente:

Oficina	Subred	Máscara	Rango	Direcciones útiles
Madrid	194.100.100.0	255.255.255.128	194.100.100.0-127	126
Barcelona	194.100.100.128	255.255.255.192	194.100.100.128-191	62
Bilbao	194.100.100.192	255.255.255.224	194.100.100.192-223	30
Sevilla	194.100.100.224	255.255.255.224	194.100.100.224-255	30

Una posible configuración para el router de Madrid sería la siguiente (la parte añadida aquí aparece en negrita):

Version 11.1

hostname Router-Madrid

ip subnet-zero

interface Ethernet0

description conexion LAN Madrid

ip address 194.100.100.1 255.255.255.128

interface serial0

description conexion WAN Internet

bandwidth 128

ip address 192.168.1.2 255.255.255.252

interface serial1

description conexion WAN Barcelona

bandwidth 256

ip address 192.168.2.1 255.255.255.252

interface serial2

description conexion WAN Sevilla

bandwidth 128

ip address 192.168.3.1 255.255.255.252

! Ruta a Barcelona

ip route 194.100.100.128 255.255.255.192 192.168.2.2

! Ruta a Bilbao

ip route 194.100.100.192 255.255.255.224 192.168.2.2

! Ruta a Sevilla

ip route 194.100.100.224 255.255.255.224 192.168.3.2

! Ruta a Internet

ip route 0.0.0.0 0.0.0.0 192.168.1.1

! Ruta loopback

ip route 127.0.0.1 255.255.255.255 Null0

Obsérvese que para las interfaces WAN se han utilizado direcciones privadas según el RFC1918 y máscaras 255.255.255.252, que dan solamente 2 direcciones útiles.

S13.-

Suponemos que para la red 199.199.199.0 el router es la dirección 199.199.199.1, y para la 200.200.200.0 es la 200.200.200.1.

Solución utilizando el router existente:

hostname router

interface Ethernet0

description conexion LAN

ip address 199.199.199.1 255.255.255.0

ip address 200.200.200.1 255.255.255.0 secondary

interface serial0

description linea con el proveedor X

ip address 192.168.1.5 255.255.255.252

interface serial1

description linea con el proveedor Y

ip address 192.168.2.5 255.255.255.252

ip route 0.0.0.0 0.0.0.0 192.168.1.6

ip route 0.0.0.0 0.0.0.0 192.168.2.6

Esta configuración produciría que los datagramas de salida se repartieran entre las dos interfases por igual, balanceando tráfico, pero no conseguiría el efecto buscado de utilizar el proveedor X para la red 199.199.199.0 y el Y para la 200.200.200.0. Además, datagramas provinientes de la red 199.199.199.0 se enviarían por el proveedor Y y viceversa. Podría ser que los routers de los proveedores X e Y tengan filtros de entrada para impedir la entrada por estas interfases de datagramas provinientes de redes que no sean las suyas.

La comunicación entre las dos redes (199.199.199.0 y 200.200.200.0) se realizaría a través de la interfaz Ethernet del router. En realidad dicha interfaz solo actuaría en el primer paquete enviado de cada lado, ya que enviaría a los hosts correspondientes un mensaje ICMP REDIRECT indicando que pueden comunicar por la LAN. Sin embargo si el router careciera de una de las dos direcciones IP la comunicación sería imposible. (suponemos que los hosts de las dos redes solo conocen su router por defecto).

Solución utilizando dos routers:

hostname router1

interface ethernet0

description conexion LAN

ip address 199.199.199.1 255.255.255.0

ip address 200.200.200.2 255.255.255.0 secondary

interface serial0

description linea con el proveedor X

ip address 192.168.1.5 255.255.255.252

ip route 0.0.0.0 0.0.0.0 192.168.1.6

hostname router2

interface ethernet0

description conexion LAN

ip address 200.200.200.1 255.255.255.0

ip address 199.199.199.2 255.255.255.0 secondary

interface serial0

description linea con el proveedor Y

ip address 192.168.2.5 255.255.255.252

ip route 0.0.0.0 0.0.0.0 192.168.2.6

En este caso los host de la red 199.199.199.0 usarán el router 1, que accede a la Internet por el proveedor X, y los de la red 200.200.200.0 usarán el router 2, que accede a través del proveedor Y.

La comunicación entre las dos redes se hará usando el router1 para el sentido 199 -> 200 y el router2 para el sentido inverso. Análogamente al caso anterior se enviaría un ICMP REDIRECT para informar a los hosts que pueden comunicar directamente, sin necesidad de utilizar el router.

En caso de que alguno de los dos routers no tuviera la dirección secundaria la comunicación en el sentido correspondiente se haría a través de la Internet. Por ejemplo supongamos que se suprime la dirección secundaria en router1, en tal caso los datagramas enviados por hosts de la red 199 hacia la 200 viajarían a través de la Internet (con el consiguiente retardo); tendríamos pues una ruta asimétrica, ya que el viaje de vuelta (de la 200 a la 199) si que se llevaría a cabo por la vía local, es decir mediante ICMP REDIRECT seguido de conexión directa por la LAN del host 200 al 199.

[1] Más tarde definiremos el significado del término sistema autónomo.

[2] Esta afirmación es incorrecta estrictamente hablando, ya que recientemente se han incorporado una serie de mejoras y modificaciones que permiten disponer de Calidad de Servicio en una red IP.

[3]Existen algunas excepciones a esto, siendo las más conocidas X.25 y ATM. X.25 utiliza normalmente paquetes de 128 bytes y ATM emplea celdas de 48 bytes. En ambos casos el nivel de ‘enlace’ (X.25 o ATM) dispone de mecanismos de fragmentación propios de forma que el tamaño que IP percibe es mayor (hasta 1600 bytes en el caso de X.25 y hasta 9180 en el de ATM).

[4] Esta técnica supone que la ruta no se modificará durante la sesión, cosa que no siempre es cierta. Algunas implementaciones revisan la MTU del trayecto periódicamente durante la sesión para asegurarse de que se está utilizando el valor óptimo en cada momento (ver el ejercicio número 14).

[5] Según el estándar todas las direcciones de la red 127.0.0.0 deberían ser loopback, pero en muchos casos esto sólo funciona para la primera dirección (127.0.0.1).

[6] Este programa está disponible en UNIX con su propio nombre y en Windows con el nombre tracert.

[7] El tráfico broadcast es altamente perjudicial para el rendimiento por dos razones: no es aislado por los conmutadores y además tiene que ser recibido y procesado por todas las estaciones de la red, ya que en principio les incumbe. En una red de gran tamaño con mucho tráfico broadcast el consumo en ciclos de CPU debido a este motivo puede llegar a ser considerable.

[8] A los efectos del funcionamiento de ARP es irrelevante el hecho de que los dos ordenadores se encuentren en el mismo dominio de colisiones o en dos diferentes unidos entre sí por puentes o conmutadores.

[9] Esta es una forma educada de decir que se pueden producir caídas de sistema operativo.

[10] CLNP (ConnectionLess Network Protocol) es un protocolo desarrollado por ISO a imagen y semejanza de IP. Su mayor diferencia estriba en el uso de direcciones OSI de 20 bytes en vez de lasde 4 bytes de IP.

[11] El problema que se plantea es en cierto modo parecido al que se da cuando varios routers de una misma red local participan en un protocolo de routing, problema que OSPF resolvía mediante el mecanismo del router designado.

[12] Es importante recordar en este punto que las direcciones MAC en Ethernet se representan empezando por el bit menos significativo de cada byte. En cambio en Token Ring y FDDI la representación es al contrario.

[13] Suponiendo un reparto aleatorio la probabilidad de coincidencia entre dos grupos multicast sería de una en diez millones (2⁵ / 2²⁸ = 0,0000001)

[14] Por alguna razón esta serie, y la ciencia ficción en general, siempre ha gozado de gran popularidad entre los ‘gurús’ de Internet

[15] En IPv4 no se consideran campos los bits reservados ni las opciones.

[16] A partir del RFC 2373 se ha previsto utilizar para IPv6 el nuevo formato de direcciones MAC de ocho bytes aprobado por el IEEE, denominadas direcciones EUI-64 (EUI = Extended Unique Identifier). Las direcciones EUI-64 utilizan el mismo prefijo de tres bytes que las direcciones MAC tradicionales para identificar al fabricante pero amplían a cinco bytes la parte que identifica al equipo. Se ha definido una forma estándar de convertir las direcciones de 48 bits en direcciones de 64 bits.