3.1 Introducción. 3.2 El protocolo IP.

Transcripción

1 TEMA 3: La capa de red en Internet 3.1 Introducción. La red Internet es un compendio de redes diferentes que comparten un protocolo, o pila de protocolos comunes (IP a nivel de red y sobre todo TCP a nivel de transporte); 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, multinacionales, etc. Como consecuencia de esto las políticas de uso son muy variadas. La capa Internet tiene como protocolo principal al protocolo IP pero dentro de ella encontramos otros auxiliares que se emplearán para determinadas funciones que debe realizar esta capa. Técnicamente a nivel de red la Internet puede definirse como un conjunto de redes o sistemas autónomos conectados entre sí que utilizan el protocolo de red IP. IP es una red de datagramas, no orientada a conexión, con calidad de servicio best effort, es decir, no hay calidad de servicio; no se garantiza la entrega de los paquetes ya que en momentos de congestión éstos pueden ser descartados sin previo aviso por los routers que se encuentren en el trayecto. 3.2 El protocolo IP. Toda información en una red IP ha de viajar en datagramas IP. Esto incluye tanto las TPDUs (Transport Protocol Data Units) de TCP y UDP, como cualquier información de routing que se intercambie en la red (paquetes ECHO, HELLO, PRUNE; de asfixia, etc.). El datagrama tiene dos partes: cabecera y texto; la cabecera tiene una parte fija de 20 bytes y una opcional de entre 0 y 40 bytes (siempre múltiplo de 4).La estructura de la cabecera es la que se muestra en la figura Versión IHL Tipo de servicio Longitud total Identificación 16 Flags 19 Desplazamiento del fragmento Tiempo de vida Protocolo Suma de comprobación de la cabecera Dirección de origen Dirección de destino Opciones IP (0 o más palabras) Datos (Opcional) Figura 3.2.1: Campos del Datagrama IP. 31 El campo versión permite que coexistan en la misma red sin ambigüedad paquetes de distintas versiones; la versión actualmente utilizada de IP (que corresponde 31

2 a la estructura de datagrama que estamos estudiando) es la 4. Actualmente está en fase de desarrollo e introducción una nueva versión (la versión 6) con una estructura de datagrama diferente. El campo IHL especifica la longitud de la cabecera, en palabras de 32 bits, 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 utiliza un campo de relleno al final de la cabecera. El campo tipo de servicio tiene la siguiente estructura: Subcampo Longitud (bits) Precedencia (o prioridad) 3 TOS (Type Of Service) 4 Reservado 1 Figura 3.2.2: Estructura del campo 'Tipo de servicio La precedencia permiten especificar una prioridad entre 0 y 7 para cada datagrama, pudiendo así marcar los paquetes normales con prioridad 0 y los importantes (por ejemplo paquetes de asfixia) con prioridad 7. La prioridad actúa alterando el orden de los paquetes en cola en los routers, pero no modifica la ruta de éstos. Dada la actual abundancia de ordenadores personales y estaciones de trabajo gestionadas por el usuario final, existe un gran debate sobre si es conveniente la existencia de un campo prioridad, ya que el usuario podría descubrir que obtiene mejor servicio con alta prioridad y utilizar sistemáticamente el valor 7 para todo tipo de paquetes; en la práctica muchos equipos ignoran este campo y cuando hacen uso de él es únicamente para datagramas transmitidos desde dentro de la subred (es decir, entre routers), que se supone que están libres de esta sospecha. Los cuatro bits siguientes actúan como flags denominados D, T, R y C respectivamente. El primero indica que se desea un servicio de bajo retardo (D=Delay); el segundo que se quiere elevado rendimiento (T=Throughput), el tercero que se quiere una elevada fiabilidad (R=Reliability), y el cuarto que se quiere un bajo costo (C=Cost). Las combinaciones válidas del subcampo TOS son las siguientes: Valor TOS Descripción 0000 Valor por defecto 0001 Mínimo costo 0010 Máxima fiabilidad 0100 Máximo rendimiento 1000 Mínimo retardo 1111 Máxima seguridad Figura 3.2.3: Combinaciones válidas del campo TOS. Para cada aplicación existe un valor de TOS recomendado. Por ejemplo, para telnet se recomienda 1000 (mínimo retardo), para FTP 0100 (máximo rendimiento) y para NNTP (news) 0001 (mínimo costo). Algunos routers utilizan el subcampo TOS para encaminar los paquetes por la ruta óptima en función del valor especificado (podrían tener una ruta diferente según se 32

3 desee mínimo retardo o mínimo costo, por ejemplo); también pueden utilizar el valor del campo TOS para tomar decisiones sobre que paquetes descartar en situaciones de congestión (por ejemplo descartar antes un paquete con mínimo costo que uno con máxima fiabilidad). Algunos routers simplemente ignoran este subcampo. El campo longitud total especifica la longitud del datagrama completo (cabecera incluida) en bytes. Su tamaño se especifica en un campo de dos bytes, por lo que su valor máximo es de bytes, pero muy pocas redes admiten este valor. Normalmente el nivel de enlace no fragmenta, por lo que el nivel de red adapta el tamaño de cada paquete para que viaje en una trama; con lo que en la práctica el tamaño máximo de paquete viene determinado por el tamaño máximo de trama característico de la red utilizada. Este tamaño máximo de paquete se conoce como MTU (Maximum Transfer Unit). En la tabla se dan 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 (varía según las redes) Frame relay Al menos 1600 normalmente SMDS 9235 Ethernet versión IEEE 802.3/ IEEE 802.4/ Token Ring IBM 16 Mbps máximo IEEE 802.5/ Mbps 4464 máximo FDI 4352 Hyperchannel ATM 9180 Figura 3.2.4: Valor de MTU para los protocolos mas comunes a nivel de enlace. Es bastante normal utilizar 1500 como valor de MTU. Cualquier red debe soportar como mínimo un MTU de 68 bytes. El campo identificación lo usa el emisor para marcar en origen cada datagrama emitido, y permite al receptor reconocer las partes correspondientes en caso de que se haya producido fragmentación por el camino (dado que se pueden tener que atravesar varias redes puede ocurrir que ya estando el datagrama de camino se encuentre una red con un tamaño menor de MTU, por lo que el router de turno deberá fragmentar el datagrama). Dentro de los flags el bit más significativo está reservado. El siguiente bit, el bit DF (Don't Fragment), cuando está a 1 indica a los routers que no fragmenten el paquete, ya que el receptor no está capacitado para reensamblarlo. Por ejemplo, si un ordenador arranca su sistema operativo a través de la red solicitará que el ejecutable correspondiente se le envíe desde algún servidor a través de la red como un único datagrama (ya que en ese estado él aun no está capacitado para reensamblar datagramas). Si un datagrama con el bit DF puesto no puede pasar por una red el router lo rechazará con un mensaje de error al emisor. Existe una técnica para averiguar el 33

4 MTU de una ruta (denominada path MTU discovery ) que consiste en enviar un datagrama grande con el bit DF puesto al destino deseado; si se recibe un mensaje de error se envía otro mas pequeño, hasta que el emisor averigua a base de tanteos cual es el valor de MTU de la ruta correspondiente, y a partir de ahí puede utilizarla para todos los datagramas sin riesgo de que sean fragmentados en el camino (siempre y cuando la ruta no cambie sobre la marcha). El otro flag corresponde al bit MF (More Fragments) y 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 original no esta fragmentado). El campo fragment offset sirve para indicar, en el caso de que el datagrama sea un fragmento de un datagrama mayor, en que posición del datagrama mayor empieza este fragmento. Los cortes siempre se realizan en frontera múltiplo de 8 bytes (la unidad elemental de fragmentación), por lo que este campo en realidad cuenta los bytes de 8 en 8. Al ser su longitud de 13 bits el número máximo de fragmentos es de 8192, que da cabida a la longitud máxima de un datagrama (8192 x 8 = 65536). Los fragmentos pueden llegar desordenados, por lo que el último fragmento puede llegar al receptor sin que haya recibido aun todos los fragmentos; la información fragment offset junto con longitud del último fragmento (identificado porque tiene el bit MF a 0) le permite al receptor calcular la longitud total del datagrama original (que sería fragment_offset*8 + longitud). El campo TTL (Time To Live, tiempo de vida) permite descartar un datagrama cuando ha pasado un tiempo excesivo viajando por la red y es presumiblemente inútil. En el diseño original se pretendía que el valor de este campo (que inicialmente podía valer por ejemplo 64) disminuyera en cada router en un valor igual al tiempo en segundos que el paquete había empleado en esa parte del trayecto, restando como mínimo 1 en cualquier caso. En la práctica medir tiempos en una red es mucho más difícil de lo que parece (los relojes de los routers han de estar muy bien sincronizados, cosa que hoy en día no ocurre), por lo que todas las implementaciones se limitan sencillamente a restar 1 al valor de TTL de cada paquete que pasa por ellos, sin analizar el tiempo que el paquete ha invertido en el salto. Como de cualquier forma hoy en día es muy raro que un paquete tarde más de un segundo en cada salto esto está aproximadamente de acuerdo con el diseño original. El valor inicial de TTL de un paquete fija el número máximo de saltos que podrá dar, y por tanto debería ser suficientemente grande como para que pueda llegar a su destino. El TTL evita que por algún problema de rutas se produzcan bucles y un datagrama pueda permanecer flotando indefinidamente en la red. 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 se especifican (junto con muchas otras tablas de números) en un RFC muy especial, denominado Assigned Numbers, que se actualiza regularmente; el vigente actualmente es el RFC Algunos de los posibles valores del campo protocolo son los siguientes: 34

5 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 Internet Gateway Routing Protocol (Cisco) 89 OSPF Open Shortest Path First 255 Reservado Figura 3.2.5: Ejemplo de valores y significados del campo protocolo en un datagrama. Obsérvese que el valor 4 está reservado al uso de IP para transportar IP, es decir al encapsulado de un datagrama IP dentro de otro. El campo checksum sirve para detectar errores producidos en la cabecera del datagrama; el checksum es el complemento a uno en 16 bits de la suma complemento a uno de toda la cabecera (incluidos los campos opcionales si los hubiera), tomada en campos de 16 bits; para el cálculo el campo checksum se pone a sí mismo a ceros. Este campo permite salvaguardar a la red de un router que alterara los campos de cabecera de un datagrama, por ejemplo por un problema hardware. El campo checksum se ha de recalcular en cada salto, ya que al menos el TTL cambia. Esto supone un serio inconveniente desde el punto de vista de rendimiento en routers con mucho tráfico. Los campos dirección de origen y dirección de destino corresponden a direcciones IP según el formato que veremos con posterioridad. Los campos opcionales de la cabecera no siempre están soportados en los routers y se utilizan muy raramente; de estos podemos destacar los siguientes: Record route: Esta opción pide a cada router por el que pasa este datagrama que anote en la cabecera su dirección, con lo que se dispone de una traza de la ruta seguida para fines de prueba o diagnóstico de problemas (es como si el router estampara su sello en el datagrama antes de reenviarlo). Debido a la limitación en la longitud de la cabecera como máximo pueden registrarse 9 direcciones, lo cual es insuficiente en algunos casos. Source routing: permite al emisor especificar la ruta que debe seguir el datagrama hasta llegar a su destino. Existen dos variantes: strict source routing permite especificar la ruta exacta salto a salto, de modo que si algún paso de la ruta no es factible por algún motivo se producirá un error. Con loose source routing no es preciso detallar todos los saltos, puede haber pasos intermedios no especificados. 35

6 Timestamp: esta opción actúa de manera similar a record route, pero además de anotar la dirección IP de cada router atravesado se anota en otro campo de 32 bits el instante en que el datagrama pasa por dicho router. El uso de dos campos de 32 bits acentúa aún mas el problema antes mencionado del poco espacio disponible para grabar esta información. De estos el más utilizado es source routing, y aún éste se usa poco por el problema del espacio en la cabecera; generalmente se prefiere usar en su lugar encapsulado IP en IP, que es más eficiente. 3.3 Direcciones IP. Cada interfaz de red de cada nodo (host o router) en una red IP se identifica mediante 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 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 para este protocolo. Es posible además, y en algunas situaciones resulta útil, definir varias direcciones IP asociadas a una misma interfaz física. 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 una red experimental que era fruto de un proyecto de investigación del Departamento de Defensa americano. Ya en 1980 se vio que esto resultaba insuficiente, por lo que se reorganizó el espacio de direcciones reservando una parte para poder definir redes más pequeñas. Para dar mayor flexibilidad y permitir diferentes tamaños se optó por dividir el rango de direcciones en tres partes adecuadas para redes grandes, medianas y pequeñas, conocidas como redes de clase A, B y C respectivamente: Una red de clase A (que corresponde a las redes originalmente diseñadas) 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 bits. Puede haber hasta 126 redes de clase A con 16 millones de hosts cada una. 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 bits. Puede haber redes clase B con hosts cada una. 36

7 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 dos millones de redes clase C con 254 hosts cada una. Para indicar qué parte de la dirección corresponde 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 , 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 y una clase C una máscara Existe además direcciones (no redes) clase D cuyos primeros cuatro bits valen 1110, que se utilizan para definir grupos multicast (el grupo viene definido por los 28 bits siguientes). Por último, la clase E, que corresponde al valor en los primeros cinco bits, 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 inmediato saber a que clase pertenece una dirección determinada sin más que saber el primer byte de su dirección. La figura resume la información esencial sobre los tipos de direcciones de Internet Clase A Clase B 0 Red 10 Red Host Host Clase C 110 Red Host Clase D 1110 Dirección multicast Figura 3.3.1: Clases de direcciones Internet y sus principales características. La asignación de direcciones válidas de Internet la realizan los NICs (Network Information Center). Al principio había un NIC para toda la Internet pero luego se crearon NICs regionales (por continentes); actualmente muchos países tienen un NIC propio; en España el NIC es administrado por RedIRIS. Existen unas reglas y convenios en cuanto a determinadas direcciones IP que es importante conocer: 37

8 1. La dirección se utiliza para indicar broadcast, esto es emisión del mensaje a todos los ordenadores en la propia red, cualquiera que esta sea (y sea del tipo que sea). 2. La dirección identifica al host actual. 3. La dirección con el campo host todo a ceros se utiliza para indicar la red misma, y por tanto no se utiliza para ningún host. Por ejemplo la dirección 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 la dirección broadcast de la red indicada, y por tanto no se utiliza para ningún host. Por ejemplo para enviar un mensaje broadcast a la red de la Universidad de Valencia utilizaríamos la dirección La dirección con el campo red todo a ceros identifica a un host en la propia red, cualquiera que esta sea; por ejemplo si queremos enviar un datagrama al primer host (1.1) de una red clase B podemos utilizar la dirección Esto permite enviar datagramas sin saber en que red nos encontramos, aunque es preciso conocer si es clase A, B o C para saber que parte de la dirección es red y que parte es host. 6. Las redes , , , y el rango de en adelante están reservados y no deben utilizarse. 7. La dirección 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. 8. Las redes , a , y a están reservadas para redes privadas ( intranets ) por el RFC 1918, por lo que 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 a redes válidas de la Internet. Como consecuencia de las reglas 3 y 4 siempre hay dos direcciones inútiles en una red. Por ejemplo, si tenemos la red (clase C) tendremos que reservar la dirección para denotar la red misma, y la dirección para envíos broadcast a toda la red; dispondremos pues de 254 direcciones para hosts, no de 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 la Internet. Sería posible asignar una red clase C diferente para cada oficina, pero esto supone solicitar al NIC una nueva 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 informar 38

9 de la red asignada a cada nueva oficina a routers externos a la organización, no sería posible enviar datagramas dentro de la empresa usando direcciones con el campo red todo a ceros (pues cada oficina tendrá una red diferente), no se puede utilizar una dirección broadcast para toda la empresa, etc. En estos casos resulta útil disponer de algún mecanismo que permita dividir una red IP en trozos o subredes, creando así un nivel jerárquico intermedio entre la red el host; de esa forma la empresa podría por ejemplo solicitar una clase B y asignar fragmentos de dicha red a cada oficina a medida que fueran creándose. Supongamos que a la empresa se le asigna la clase B ; 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 habría 256 subredes de 256 direcciones cada una. Desde fuera la red de la empresa seguiría siendo , ya que la estructura de subred no sería visible. Las subredes se añadieron a la Internet en 1982, con lo que se consiguió una mayor flexibilidad en el reparto de direcciones dentro de una red. Para dividir la red en subredes se define una máscara en la que están a 1 los bits de la dirección que corresponden a la red-subred, y a cero los que corresponden al host. Por ejemplo, la máscara divide una red clase B en 256 subredes de 256 hosts pues tiene puestos a 1 los primeros 24 bits (los 16 de la clase B mas los 8 de la subred). Se pueden hacer divisiones que no correspondan con bytes enteros, por ejemplo si la máscara fuera se estarían reservando los primeros 6 bits del campo host para la subred y dejando 10 para el host; con lo que podría haber hasta 64 redes con 1024 hosts cada una. Al crear subredes hay dos direcciones de cada subred que quedan automáticamente reservadas: las que corresponden al campo host todo a 0 y todo a 1; estas se emplean para la designación de la subred y para la dirección broadcast, respectivamente. Así si la red se subdivide con la máscara se crean 256 subredes del tipo subred.host, siendo subred.0 la dirección que identifica a toda la subred y subred.255 la dirección broadcast de la subred. Por tanto el número de hosts de una subred es siempre dos menos que el número de direcciones que abarca; por lo que no tiene sentido crear subredes con la máscara en las que el campo host tendría un bit, pues no quedarían direcciones útiles. Del mismo modo que los valores todos ceros o todo unos del campo host están reservados con un significado especial, el valor todos ceros y todo unos del campo subred también son especiales. El valor todos ceros se utiliza para representar la subred misma; por ejemplo si a la red le aplicamos la máscara el campo subred todo a ceros no debería utilizarse, pues resultaría ambiguo el significado de la dirección , que representaría tanto a dicha subred como a la red entera. Por otro lado, el campo subred todo a unos tampoco debería utilizarse porque de lo contrario el significado de la dirección sería ambiguo, significaría tanto broadcast en la subred como en la red entera. Por consiguiente en el campo subred también se pierde siempre dos direcciones, y tampoco tendría sentido crear máscaras con el campo subred de un bit, tales como en el caso de una red clase B. Mientras que la restricción de no utilizar direcciones todos ceros o todo unos en el campo host se cumple siempre, existen muchas instalaciones que por conveniencia 39

10 incumplen la restricción equivalente en el campo subred, es decir, consideran válida la subred especificada por el campo subred todo a ceros o todo a unos. Esta práctica se conoce como subnet-zero y se adopta para poder aprovechar mejor el espacio de direcciones disponible; con subnet-zero es posible por ejemplo dividir una red clase B o clase C por la mitad en dos subredes mediante la máscara o , 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áscara no contigua, por ejemplo en una clase B con la máscara el host vendría especificado por el tercer byte y la subred por el cuarto. Dado que esta práctica solo complicaba la comprensión de las subredes y hacía menos eficiente el proceso en los routers, actualmente la norma exige que la máscara sea contigua. La división en subredes no ha de hacerse necesariamente de forma homogénea en todo el espacio de direcciones, como hemos supuesto hasta ahora. Supongamos siguiendo con nuestro ejemplo anterior que la empresa tiene una serie de oficinas pequeñas que tienen suficiente con subredes de 256 direcciones, pero otras mas grandes requieren un número mayor; en vez de dividir toda la red en 256 subredes de 256 hosts y asignar varios fragmentos a las oficinas mayores podemos hacer una partición en trozos de diferente tamaño, asignando así a cada oficina un trozo acorde con sus necesidades. Es importante destacar que la creación de subredes impone ciertas restricciones. Analicemos por ejemplo en el caso anterior la primera subred de 1024 direcciones; vemos que abarca un bloque de cuatro valores en el tercer byte, del 16 al 19; 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 la subred, pues la dirección no tiene una máscara común de 22 bits 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 fácilmente que las subredes de máscara de 20 bits (4096 direcciones) han de empezar en múltiplos de 16, y así sucesivamente. 3.5 Superredes: Routing classless (CIDR). El rápido crecimiento de la Internet está creando varios problemas, el más importante de los cuales es el rápido agotamiento de las direcciones. Las redes clase A ya prácticamente no se asignan, y resulta muy difícil obtener una clase B. Muchas empresas no tienen bastante con una clase C pero una B les resulta excesiva. Entre las medidas que se están adoptando para paliar el problema de escasez de direcciones está la de asignar un conjunto de redes clase C donde antes se asignaba una clase B. De esta forma se puede ajustar mejor el rango de direcciones asignado a las necesidades reales previstas de cada organización Esto ha resuelto un problema pero ha creado otro: el crecimiento desmedido de las tablas en los routers. Muchos routers de la Internet funcionan con unas tablas de encaminamiento que solo recogen una pequeña parte de todas las redes existentes, y 40

11 disponen de una ruta por defecto por la cual se sale hacia el resto de la Internet. Sin embargo, a medida que nos aproximamos al centro o 'backbone' de la Internet las tablas tienen que ser necesariamente mas exhaustivas; en las tablas de los denominados core routers se mantienen entradas para la mayoría de las redes existentes en la Internet. Al asignar a una organización varias clases C donde normalmente hubiera bastado con una clase B hace falta definir varias entradas en las tablas de routing (una por cada clase C asignada) cuando antes habría bastado una para toda la clase B. Actualmente hay mas de 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 ya que fueron diseñados pensando en muchas menos entradas. El crecimiento de la Internet se está produciendo a un ritmo que duplica el número de redes conectadas 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 el problema de la explosión de las tablas de routing se convirtió 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 normal en el número de redes y rutas la Internet se colapsaría hacia Para solucionar este problema se adoptó en 1993 un sistema denominado CIDR (Classless InterDomain Routing) descrito en el RFC Se trata de dos medidas complementarias. La primera consiste en establecer una jerarquía en la asignación de direcciones. Antes de CIDR la asignación de números de red se hacía por orden puramente cronológico, independientemente de la ubicación geográfica, lo cual equivalía en la práctica a una asignación aleatoria del número de red. Con CIDR se han asignado rangos por continentes: a para Europa a para Norteamérica a para Centro y Sudamérica a para Asia y la zona del Pacífico A su vez dentro de cada uno de estos rangos se ha dado una parte a cada país, y dentro de éste un rango a cada proveedor de servicios Internet. Con esta distribución regional de los números y los cambios pertinentes en el software las entradas en las tablas de routing pueden agruparse, con lo que las tablas se simplifican; por ejemplo un router en Japón puede poner una sola entrada en sus tablas indicando que todos los paquetes dirigidos a las redes hasta vayan a la interfaz que da acceso a Europa. Se ha establecido pues un criterio geográfico jerárquico en las direcciones IP. 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 a este sus direcciones, y solicitar direcciones nuevas al nuevo proveedor; por supuesto tendrá que modificar las direcciones IP de todas sus máquinas. La segunda medida adoptada por CIDR es en realidad es un caso particular de la anterior. Consiste en dar a cada organización (bien directamente o a través de su proveedor correspondiente) un conjunto de redes clase C ajustado a lo que son sus necesidades previstas, dándole siempre un rango contiguo y un número de redes que sea 41

12 potencia entera de 2 (es decir 1, 2, 4, 8 redes, etc.) elegidas de modo que tengan una máscara común en la parte de red; por ejemplo un grupo de 8 redes clase C puede hacerse variando únicamente los 3 últimos bits (22 a 24) de la parte de red, por lo que el grupo deberá tener comunes los primeros 21 bits de la parte de red, y deberá empezar necesariamente por un valor múltiplo de ocho y abarcar los siete valores siguientes. Por ejemplo, supongamos que la Universidad de Valencia solicita a su proveedor direcciones de red y justifica la previsión de tener 1200 hosts en un plazo razonable; como 4 redes clase C no serían suficientes se le asignan 8 redes, que permiten llegar a 2032 hosts (254 x 8). Supongamos que somos el proveedor de la Universidad de Valencia y que tenemos disponible para nuestro uso el rango a (obsérvese que en este caso el número de redes clase C válidas es de 256, no 254, pues las redes y son perfectamente utilizables); supongamos que hemos ido asignando redes clase C a nuestros clientes por orden cronológico, y que nos queda libre a partir del 12, es decir de la red ; si le asignamos de a la el rango es contiguo pero 12 no es múltiplo de 8, por lo que la máscara no es común (es decir, los primeros 21 bits no son iguales en las 8 redes). El primer rango de 8 redes con máscara común sería a , que es el que le asignaríamos a nuestro cliente. Las redes a quedarían libres para otros clientes, por ejemplo podrían formar un grupo contiguo de 4 redes (22 bits iguales) para alguno que necesitara conectar entre 509 y 1016 hosts. Obsérvese que CIDR es en realidad el mismo mecanismo que las subredes, pero aplicado en sentido inverso. Las subredes permiten dividir una red, ampliando la parte red a costa de la parte host de la dirección. El CIDR funde diferentes redes en una, reduciendo la parte red y ampliando la parte host. Por este motivo el CIDR también se conoce como supernet addressing. Cuando se utiliza CIDR como en el ejemplo anterior los hosts finales que se encuentran en distintas redes clase C no pueden hablar directamente entre ellos, han de hacerlo a través de un router, a menos que soporten CIDR que no es lo normal en hosts. Un grupo CIDR de clases C siempre funciona como subnet-zero, es decir: No existe una dirección que haga referencia al grupo; en nuestro ejemplo la dirección haría referencia a la primera red clase C únicamente. No existe una dirección broadcast del grupo; en nuestro ejemplo la dirección es la dirección broadcast de la red únicamente. El espacio de redes clase A, que suponen la mitad del espacio total, está asignado actualmente sólo en un 50% aproximadamente. Se está estudiando la posibilidad de dividir 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