MIT 18.996: Temas sobre informática teórica: problemas de investigación en Internet Clase 2 – 13 de Febrero, 2002 Profesor: Ravi Sundaram Primavera de 2002 Copistas: Zeeshan Syed, Asfandyar Qureshi 2.1 Historia El precursor de Internet fue un experimento académico que se llevó a cabo en los años 60. Fundada por la Defence Advanced Research Projects Agency (DARPA), la propuesta para ARPANET fue publicada en primer lugar por Lawrence G. Roberts en 19661. Influido por su relación con Leonard Kleinrock de MIT2, Roberts se imaginó ARPANET como una red de área amplia para la transmisión de la información en forma de paquetes. Una labor basada en ideas similares se había desarrollado en paralelo en la compañía RAND y en NPL y algunos de sus estándares fueron adoptados por DARPA. A finales de 1969, cuatro ordenadores host se conectaron conjuntamente a la inicial red ARPANET y la prometedora red Internet se puso en marcha. Uno por uno, los ordenadores de UCLA (conectados en septiembre), el Standford Research Institute (SRI, en octubre), la University of California, Santa Barbara (en noviembre) y por último la University of Utah (en diciembre) entraron en línea, todos ellos comunicados por conexiones de 56 Kbps. El 29 de octubre, Charley Kline de UCLA, envió los primeros paquetes cuando intentó entrar en SRI. Este primer intento provocó un bloqueo del sistema al introducir la letra G de LOGIN (registro). No obstante, durante los años siguientes, se conectaron rápidamente más ordenadores a ARPANET. En 1970, el Network Working Group3 publicó el primer protocolo host a host llamado Network Control Protocol (NCP) (Protocolo de control de capa de red). Más tarde en ese mismo año, se añadieron las primeras conexiones a través del país, entre UCLA, RAND y MIT. En 1973 la red ARPANET se expandió a nivel internacional con conexiones al University College de Londres, Inglaterra y al Royal Radar Establishment de Noruega. En Marzo de 1972, Ray Tomlinson de BBN creó el software básico para lectura y envío de mensajes por correo electrónico, impulsado por la necesidad de los programadores de ARPANET de hacerse con un mecanismo de sencilla coordinación. El email pronto pasó a ser la aplicación más de moda por más de una década. La red ARPANET se convirtió en una oficina de correos digital de 1 G. Roberts, MIT: “Towards a Cooperative Network of Time-Shared Computers”, 1966 2 Leonard Kleinrock, MIT: “Information Flow in Large Communication Nets”, Mayo, 1961. 3 C.S. Carr, S. Crocker, V.G. Cerf, “Host-Host Communication Protocol in the ARPA Network,” en las actas de AFIPS de SJCC. Figura 2.1. ARPANET 1971 alta velocidad que la gente utilizaba para colaborar en proyectos de investigación y tratar temas de diversos intereses. Sin embargo, el rápido crecimiento de ARPANET creó la necesidad de un software más completo y de protocolos que controlaran una complejidad cada vez mayor. En concreto, NCP confiaba en que ARPANET proporcionara una fiabilidad completa. Si algún paquete se perdía, el protocolo (y supuestamente cualquier aplicación que éste soportara) se estancarían. La colaboración entre Robert Kahn (de DARPA) y Vinton Cerf (de Standford) nos condujo hasta los protocolos actuales. En 19784 publicaron la especificación del Transmission Control Protocol (TCP) (Protocolo de control de transmisión) y el Internet Protocol (IP) (Protocolo de Internet). Los dos protocolos a la vez facilitaron los medios para transmitir paquetes de forma segura a cualquier host de la red. En 1982 ARPANET se había dividido en MILNET (la parte militar) y en lo que más tarde llegaría a ser Internet. Por esa época, a comienzos de los 80, surgieron redes tales como USENET, BITNET, CSNET y un host de otras. Exceptuando a BITNET y USENET, estas primeras redes (incluyendo a ARPANET) estaban destinadas a ser construidas con un objetivo y restringidas en gran medida a grupos limitados de estudiosos. Los acuerdos entre DARPA y los demás a principios de la década permitieron la interconexión de algunas de estas redes. A principios de los 80, la National Science Foundation (NSF) anunció abiertamente su intención de atender a la comunidad universitaria al completo. Como resultado de su financiación, en 1986 surgió NSFNET – esto más tarde constituiría el pilar de las comunicaciones de la primera Internet. La NSF también fundó enormes centros informáticos – en Princeton, Cornell, Pittsburgh, UIUC y UCSD – para suministrar a cada uno un alto poder informático. Esto provocó un aumento de conexiones, sobre todo desde las universidades. De hecho, aunque en 1986 existían algo más de 5.000 hosts en Internet, este número aumentaría a más de 28.000 durante el año siguiente. Sin embargo, el NSF había prohibido el uso del pilar NSFNET, el segmento a escala nacional de la NSFNET, para propósitos que “no apoyasen la educación y la investigación”. El 2 de noviembre de 1988, se soltó en la red un gusano que afectó a casi 6.000 de los 60.000 ordenadores que se encontraban en línea. Finalmente aniquilado y erradicado por investigadores de Berkeley y MIT, el gusano dejó al descubierto algunos agujeros de 4 V. G. Cerf y R. E. Kahn, “A protocol for packet network interconnection”, IEEE Trans. Comm. Tech., vol. COM-22, V 5, págs. 627-641, mayo de 1974. seguridad graves en la creciente red. Como respuesta a las necesidades mostradas durante este incidente, DARPA creó el Computer Emergency Response Team (CERT). Figura 2.2. ARPANET 1980 En 1978, había menos de 200 ordenadores en línea. En 1989, eran muchos más de 100.000. Esto quería decir que tener una sencilla tabla con todos los hosts no era ya viable, y Mockapetris de USC/ISI inventó el Domain Name System (Sistema de nombre de dominio) (DNS) en el año 1984. El DNS permitió un mecanismo distribuido escalable para resolver la jerarquía de los nombres de los hosts (ej. www.akamai.com) en una dirección de Internet. El aumento del tamaño de Internet también desafió las capacidades de los enrutadores y originó problemas de congestión de ancho de banda que los protocolos TCP/IP no habían tenido en cuenta. En 1989, TCP había sido revisado para facilitar el control de la congestión y evitar así el colapso de la red. Los enrutadores se modificaron también para controlar una complejidad que iba en aumento. Al principio, existía un único algoritmo distribuido para el enrutamiento, que fue implementado uniformemente por todos los enrutadores de Internet. Cuando el número de redes en Internet se disparó, este diseño inicial no pudo extenderse como se requería, así que se reemplazó por un modelo de enrutamiento jerárquico, con un protocolo llamado Interior Gateway Protocol (IGP) utilizado dentro de cada zona de Internet, y un Exterior Gateway Protocol (EGP) para unir todas las zonas. En 1990, ARPANET, feliz víctima de su inesperado e imprevisto éxito, fue desmantelada, dejando una amplia red de redes conocida como Internet. El número de hosts superó esta vez los 300.000. Sin embargo, incluso en 1990, el tráfico comercial estaba todavía prohibido en el eje de NSFNET. Durante este tiempo, existía un auténtico miedo entre los investigadores de que Internet se colapsase bajo su propio peso y por tanto se mostraba reticencia a aumentar el tráfico en ella. Finalmente, en 1991 se levantó la veda comercial y ello condujo al desarrollo de un gran número de aplicaciones de Internet. En la University of Minnesota, un equipo dirigido por un programador informático, Mark MaCahill, dio a conocer “gopher” en 1991, el primer modo point-and-click de navegar por los archivos de Internet. Diseñado en un principio para facilitar las comunicaciones en el campus, gopher se distribuyó de forma gratuita en Internet. MaCahill lo llamó “la primera aplicación de Internet que hasta mamá puede usar”. 1991 fue también el año en el que Tim Berners-Lee, que trabajaba para CERN en Suiza, hizo público el primer código informático del World Wide Web en “alt.hypertext”, un grupo de noticias relativamente inofensivo. Marc Andreesen y un grupo de estudiantes programadores del NCSA (el National Center for Supercomputing Applications situado en el campus de la University of Illinois en Urbana Champaign) crearían finalmente un navegador gráfico para el World Wide Web llamado Mosaic. Andreesen continuaría hasta fundar Netscape. Finalmente, el gobierno comenzó a apartarse del mantenimiento de Internet. En mayo de 1993, tuvo lugar la última solicitud a NSFNET para obtener puntos de acceso privados a la red (Network Access Points) (NAPs). Ese mismo año, NFS creó InterNIC para facilitar servicios específicos de Internet, como los relacionados con el registro y las bases de datos del host. Por tanto, al final, la gestión de Internet se trasladó hacia el dominio público con una supervisión cada vez menor por parte del gobierno. Sin embargo, en una entrevista con CNN en marzo de 1999, el vicepresidente Al Gore se jactaba de haber tomado “la iniciativa de crear Internet”. El espectacular crecimiento de Internet había acarreado la necesidad de un nuevo eje de comunicaciones. En 1995, el eje de NSFNET se sustituyó por vBNS –servicio de alto rendimiento desarrollado por MCI, que conectaba algunas universidades y centros de investigación a más de 155 Mbps. Internet está muy lejos de aquellos cuatro host que se conectaron en línea en 1969. En el año 2002, había aproximadamente 350 millones de hosts – un número que se ha previsto que crezca bastante. Los diseñadores iniciales de los protocolos y de la arquitectura que conforman Internet no tuvieron en cuenta la multitud de cuestiones que surgen del nivel actual de complejidad: el enrutamiento no es del todo óptimo, las conexiones y los hosts son poco fiables, no hay seguridad intrínseca, no hay directorio ni índice y el espacio para las direcciones es diminuto. La naturaleza descentralizada de Internet trae consigo muchos desafíos y oportunidades. Durante este tiempo, mucha gente ha intentado retocar la arquitectura original para poder controlar nuevas situaciones, pero como es de esperar, actualmente Internet no proporciona un rendimiento óptimo5. 2.2 Protocolos de Internet 2.2.1 Capas de redes Desarrollar software para redes es una tarea complicada debido al afinado número de diferentes servicios subyacentes que deben facilitarse. Entre estos se encuentran el envío de bits a través de varios medios de transmisión, datos de enrutamiento entre máquinas de redes distintas, facilitar la detección del error, la corrección y una conectividad de confianza, regular el flujo y la definición de formatos para la aplicación. La mayoría de estas funciones son en gran medida independientes de la red y son lo suficientemente genéricas para que se normalicen. Como consecuencia, y para reducir la complejidad del diseño, las redes se disponen como una serie de capas o niveles, construidas unas sobre otras. El número exacto, los nombres, contenidos y funciones de cada capa puede variar de red a red, pero su propósito es ofrecer ciertos servicios a las capas más altas, 5 Esta sección está basada principalmente en las dos fuentes siguientes: [1] Barry M. Leiner, Vinton G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G. Roberts, Stephen Wolff, “A Brief History of the Internet” y [2] Robert H. Zakon, “Hobbes’ Internet Timeline”, http://www.zakon.org/robert/internet/timeline protegiéndolas de detalles sobre cómo se han implementado en realidad los servicios ofrecidos. De este modo, las capas implementan abstracciones y ofrecen a las aplicaciones construidas por encima de ellas una serie de servicios bien definidos. Figura 2.3. Ejemplo de un paquete con cabeceras y colas Cada capa de una red añade por regla general, información adicional al paquete que ésta recibe de la capa que se encuentra justo encima de ella (como se muestra en la figura 2.3). Esto está pensado para que lo interprete únicamente la correspondiente capa que se encuentra en el otro extremo. Se denomina cabecera cuando se añade al principio del paquete y cola cuando se pega al final. La parte de los datos que pertenece a la capa justo de encima se conoce con el nombre de payload. Las colas y cabeceras contienen normalmente información de control como tamaños, tiempos y otros campos de este tipo. Pueden contener también números de secuencia (para permitir que la capa correspondiente de la máquina destino entregue los mensajes en un orden adecuado si las capas inferiores no mantienen la secuencia). Todo esto hace que el tamaño de un paquete típico tenga un límite de entre 46 y 1500 bytes. Las entidades que constan de las correspondientes capas en máquinas distintas se llaman peers. Las reglas y convenciones que se utilizan para la comunicación entre éstas son conocidas como protocolos. Dicho de otro modo, un protocolo es fundamentalmente un acuerdo entre las partes comunicantes sobre cómo debería transcurrir la comunicación (mediante la especificación y el formato de los mensajes enviados entre los pares iguales). La arquitectura de capa de redes se verá más detalladamente en el Apéndice A. 2.2.2 Argumento end-to-end (Chequeo de punta a cabo) El principio, llamado argumento end-to-end, indica que las funciones situadas en los niveles bajos de un sistema pueden resultar superfluas o de poco valor si se comparan con el coste que supone proporcionarlas en ese nivel bajo. La idea clave de este argumento es que una aplicación conoce mejor cuáles son sus verdaderos requisitos comunicativos y que una capa más baja trate de implementar cualquier característica al otro lado transportando como mínimo los datos, pone en peligro algo que no es exactamente lo que se requiere, en cuyo caso, la aplicación terminará volviendo a implementar esa función de un modo distinto que sea más útil. El argumento se explicará más detalladamente en otra parte6 2.2.3 6 Protocolos contemporáneos J.H. Saltzer, D.P. Reed y D.D. Clark. “End-to-End Arguments in System Design”, MIT-LCS En esta sección se verán brevemente algunos de los protocolos usados con más frecuencia. Puede encontrar una descripción más exhaustiva de cada uno de ellos en el documento RFC (Request For Comment) (Petición de comentarios) que se asocia con cada protocolo7 2.2.3.1 Protocolo de Internet (IP) Este protocolo proporciona todos los servicios de transporte de datos de Internet, con todos los demás protocolos puestos finalmente en capas sobre IP o usados para apoyar a IP desde abajo. IP es el protocolo más básico de Internet. El único requisito de un segmento de red para poder funcionar en una red TCP/IP es enviar paquetes IP. De hecho, una red TCP/IP se puede definir como un medio de comunicación que puede transportar paquetes IP. Casi todas las demás funciones TCP/IP se construyen superponiendo capas sobre IP. IP es un protocolo de datagrama que trata cada paquete por separado. Esto significa que cada paquete debe contener toda la información relativa a las direcciones. Además, IP no hace ningún intento por determinar si los paquetes llegan a su destino o por tomar las medidas adecuadas si no es así. IP únicamente contiene la suma de verificación de la cabecera, los contenidos del paquete no se validan de este modo. IP proporciona varios servicios: • Direccionamiento: las cabeceras IP contienen direcciones de 32 bits que identifican a los hosts remitentes y destinatarios. Los enrutadores intermedios utilizan estas direcciones para seleccionar una ruta para el paquete a través de la red. • Fragmentación: los paquetes IP pueden estar divididos o fragmentados en paquetes pequeños. Esto permite que un paquete grande viaje por una red que sólo puede manejar paquetes más pequeños. IP fragmenta y vuelve a armar los paquetes. • Timeout (tiempo de espera) del paquete: Cada paquete IP contiene un campo de tiempo de vida (TTL) que disminuye cada vez que un enrutador maneja el paquete. Si el TTL llega a cero, el paquete se descarta, impidiendo así que los paquetes permanezcan en un bucle infinito y que colapsen la red. Este tiempo se fija por lo general a 30 al principio. • Tipo de servicio: IP soporta la priorización del tráfico al permitir que los paquetes sean etiquetados con un tipo de servicio abstracto. Esto casi nunca se utiliza. • Opciones: IP proporciona varios elementos opcionales, permitiendo que el remitente de un paquete establezca los requisitos sobre la ruta que éste toma a través de la red (enrutamiento fuente), que encuentre la ruta que el paquete toma (grabación de la ruta) y que etiquete los paquetes con elementos de seguridad. 2.2.3.2 Protocolo de control de mensajes de Internet (ICMP) Este es un protocolo necesario estrictamente integrado con IP. Los mensajes ICMP, que se entregan en paquetes IP, se utilizan para mensajes out-of-band relacionados con una operación o fallo en la red. Por supuesto, dado que ICMP utiliza IP, la entrega de un paquete ICMP es poco fiable, así que los hosts no pueden contar con recibir paquetes ICMP por cualquier problema en la red. Algunas de las funciones de ICMP son: 7 Los RFCs pertinentes pueden encontrarse en: www.ietf.org, www.w3.org y www.freesoft.org • • • • Notificación de error: los errores en la red se anuncian, como cuando no se puede acceder a un host o una parte completa de la red debido a algún tipo de fallo. Un paquete TCP o UDP dirigido a un número de puerto sin destinatario adjunto también se presenta mediante ICMP. Notificación de congestión: cuando un enrutador empieza a acumular en el búfer demasiados paquetes por no ser capaz de transmitirlos tan rápidamente como éstos se reciben, éste generará mensajes ICMP de disminución del tráfico desde el origen. Dirigidos al remitente, estos mensajes deberían hacer que se disminuyera la velocidad de transmisión del paquete. Por supuesto, generar demasiados mensajes de este tipo provocaría aún más congestión en la red, de modo que se utilizan con moderación. Notificación del tiempo de espera: si el campo TTL de un paquete IP baja a cero, el enrutador, deshaciéndose del paquete, normalmente generará un paquete ICMP en el que se notifique este hecho. TraceRoute es una herramienta que traza rutas en la red enviando paquetes con valores TTL pequeños y vigilando las mensajes ICMP de tiempo de espera. Ayuda para la resolución de problemas: ICMP admite una función Eco, que simplemente envía un paquete entre dos hosts en un viaje de ida y vuelta. Ping, que es una herramienta común de gestión de red, está basado en esta característica. Ping transmitirá una serie de paquetes, midiendo el promedio de veces que se hace un viaje de ida y vuelta y calculando los porcentajes de pérdidas. 2.2.3.3 Protocolo de control de transmisión (TCP) Este protocolo está pensado en gran medida para compensar las deficiencias de IP, proporcionando conexiones de secuencias fiables que oculten la mayoría de los defectos de IP. El conjunto TCP/IP recibe este nombre porque la mayoría de dichos protocolos están basados en TCP, que está a su vez implementado sobre IP. TCP añade gran funcionalidad al servicio IP sobre el que se encuentra superpuesto: • Flujos: los datos de TCP están organizados como un flujo de bytes, muy similar a un fichero. El carácter de datagrama de la red está oculto. Existe un mecanismo (el puntero urgente) que permite que los datos out-of-band sean marcados expresamente. • Entrega fiable: los números secuenciales se utilizan para coordinar cuáles son los datos que se transmiten y reciben. TCP planeará una retransmisión si determina que los datos se han perdido. • Adaptación a la red: TCP asimilará dinámicamente las características del retraso de una red y regulará su funcionamiento para maximizar el rendimiento sin sobrecargar la red. • Control de flujo: TCP controla los búfers de datos y coordina el tráfico, de forma que sus búfers no se excederán. Los remitentes rápidos serán detenidos de vez en cuando para que puedan seguir el ritmo de los destinatarios más lentos. Sea cual sea la aplicación en concreto, TCP funciona casi siempre como transmisión fullduplex. Los algoritmos descritos a continuación funcionan en ambas direcciones, de un modo casi completamente independiente. Algunas veces es útil pensar en una sesión TCP como dos flujos de bytes por separado que viajan en direcciones opuestas. No existe ningún mecanismo en TCP que asocie los datos de los flujos de bytes enviados con los que viajan en sentido inverso. TCP muestra un comportamiento asimétrico (es decir, transferencia de datos hacia delante pero no al revés), sólo durante el inicio de conexión y las secuencias de cierre o viceversa. TCP utiliza un número de secuencia de 32 bits que cuenta los bytes del flujo de datos. Cada paquete TCP contiene el número de secuencia inicial de los datos de ese paquete y el número de secuencia (llamado número de reconocimiento) del último byte recibido desde el par remoto. Con esta información, se implementa un protocolo de ventana deslizante. Los números de secuencia que van hacia delante y que vuelven hacia atrás son completamente independientes y cada par TCP debe controlar tanto su propio número de secuencia como el número que el par remoto está usando. TCP utiliza un número de indicativos de control para controlar la conexión. Algunos de estos indicativos están relacionados con un único paquete, como el indicativo URG, que señala los datos válidos del campo Puntero urgente. Sin embargo, existen dos indicativos, SYN y FIN, que requieren una entrega fiable ya que marcan el comienzo y el fin del flujo de datos. Para asegurar la entrega fiable de estos dos indicativos, se les asignan posiciones dentro del espacio número de secuencia. Cada indicativo ocupa un único byte. Cada punto final de una conexión TCP tendrá un búfer para almacenar los datos que se transmiten por la red antes de que la aplicación esté lista para leer esos datos. Esto permite que la transferencia de red ocurra mientras las aplicaciones están activas con otro procesamiento, mejorando el rendimiento global. Para evitar que la memoria intermedia se sature, TCP coloca un campo de Tamaño de ventana en cada paquete que transmite. Este campo contiene la cantidad de datos que pueden transmitirse al búfer o memoria intermedia. Si este número desciende a cero, el TCP remoto no puede enviar más datos. Debe esperar hasta que el espacio del búfer esté disponible y reciba un paquete que anuncie que el valor del campo de tamaño de ventana no es cero. En algunas ocasiones, el espacio del búfer es demasiado pequeño. Esto sucede cuando el producto ancho de banda-retraso de la red sobrepasa el tamaño del búfer. La solución más sencilla consiste en aumentar la memoria intermedia, pero en casos extremos, el mismo protocolo se convierte en un obstáculo (porque no posee un tamaño de ventana suficientemente grande). Bajo estas condiciones, se califica a la red como una LFN (Long Fat Network (red de larga distancia de banda ancha) – pronunciada como "elefante" en inglés). RFC 1072 habla de las redes LFN. Cuando un host transmite un paquete TCP a su igual, éste debe esperar un periodo de tiempo para obtener confirmación. Si la respuesta no llega dentro del tiempo esperado, se asume que el paquete se ha perdido y se vuelven a transmitir los datos. La pregunta lógica - ¿cuánto tiempo debemos esperar? – no tiene una respuesta simple. Por cable Ethernet, se necesitarían tan sólo unos pocos microsegundos para obtener una respuesta. Si el tráfico debe fluir por la red Internet de área amplia, uno o dos segundos podrían ser razonables durante periodos de máxima utilización. Si nos estamos comunicando con un paquete de instrumentación de un satélite, que va a toda velocidad hacia Marte, podrían necesitarse unos minutos antes de obtener una respuesta. No existe respuesta para la pregunta ¿cuánto tiempo? Todas las implementaciones TCP modernas tratan de responder a esta cuestión controlando el intercambio normal de paquetes de datos y realizando un cálculo del tiempo que representa “demasiado tiempo”. Este proceso se conoce como cálculo de Round-Trip Time (RTT) (Tiempo de viaje completo). Los cálculos de RTT constituyen uno de los parámetros de rendimiento más importantes en un intercambio TCP, especialmente cuando se piensa que en una transferencia importante de tiempo indefinido, todas las implementaciones TCP al final lanzan paquetes y los retransmiten, sin importar la buena calidad de la conexión. Si el cálculo de RTT es demasiado bajo, los paquetes se retransmiten innecesariamente; si éste es demasiado alto, la conexión puede quedarse parada mientras el host permanece en tiempo de espera. 2.2.3.4 Protocolo de datagrama de usuario (UDP) Este protocolo facilita el acceso de los usuarios a los servicios IP. La entrega de paquetes UDP es similar a la de paquetes IP – datagramas sin conexión que pueden ser desechados antes de alcanzar su objetivo. UDP es útil cuando TCP resulta demasiado complejo, demasiado lento o simplemente innecesario. UDP proporciona algunas funciones más que IP: • Números de puerto: UDP proporciona números de puerto de 16 bits para permitir que múltiples procesos utilicen servicios UDP en el mismo host. Una dirección UDP es la combinación de una dirección IP de 32 bits y el número de puerto de 16 bits. • Suma de verificación: A diferencia de IP, UDP verifica la suma de sus datos, asegurando la integridad de los mismos. Un paquete que falle en la suma de verificación simplemente se descarta y no lleva a cabo ninguna otra acción. 2.2.3.5 Protocolo simple de transferencia de correo (SMTP) Éste es el protocolo estándar de Internet para la transferencia de correo electrónico host a host (entre sistemas) y actúa tradicionalmente sobre el puerto TCP 25. Es decir, un usuario de UNIX puede escribir telnet y a continuación el nombre del host 25 y conectar con un servidor SMTP, si hay uno presente. SMTP usa un tipo de protocolo asimétrico de petición-respuesta, de moda a comienzos de los 80, que aún se ve ocasionalmente, la mayoría de las veces en protocolos de correo. El protocolo está diseñado para ser tan útil para el ordenador como para el hombre, aunque no muestra demasiada compasión con el hombre. Desde el punto de vista del servidor, en el documento RFC se facilita una lista clara de comandos bien documentados. Para el hombre, todos los comandos finalizan claramente en saltos de línea y aparecen enumerados bajo el comando HELP. Desde el punto de vista del remitente, las respuestas al comando adoptan siempre la forma de líneas de texto, que comienzan cada una por un código de tres dígitos que identifica el resultado de la operación, un carácter de continuación para indicar las otras líneas que siguen y además, información textual arbitraria con carácter informativo para el hombre. Si la entrega de correo falla, sendmail (la implementación SMTP más importante) pondrá los mensajes de correo en cola y volverá a intentar la entrega más tarde. Sin embargo, se usa un algoritmo de backoff, no hay ningún mecanismo para enviar todos los elementos hosts de Internet por mail, SMTP no facilita ningún servicio de buzón de correo o cualquier elemento especial aparte de la transferencia de correo electrónico. Por estas razones, SMTP no es una buena elección para los hosts que están situados detrás de líneas sumamente inciertas (como los módems). Se puede designar a un host con mejor conexión, como un DNS encargado del intercambio de correo, además de organizar un plan de transmisión. Actualmente, se pueden utilizar dos configuraciones fundamentales. Una consiste en configurar los buzones de correo POP y un servidor POP en el host de intercambio y en permitir que todos los usuarios usen clientes de correo POP. La otra posibilidad se centra en fijar una transferencia de correo SMTP periódica desde el host de intercambio a otro host local de intercambio SMTP que haya estado poniendo en cola todo el correo saliente. Por supuesto, esta conexión queda descartada ya que no permite un pleno acceso a Internet. 2.2.3.6 Protocolo simple de gestión de red (SNMP) Este es básicamente un protocolo de petición-respuesta que se ejecuta sobre UDP (en los puertos 161 y 162), aunque la operación TCP es posible. SNMP es un protocolo asimétrico, que opera entre una estación de gestión (inteligente) y un agente (silencioso). El agente es el dispositivo que se gestiona – su software tiene que implementar algunos tipos de paquetes simples y una función genérica get o set sobre sus variables de MIB. La estación de gestión presenta la interfaz del usuario. Las estaciones de gestión simples pueden construirse con los servicios de la línea comandos UNIX. Otros más complejos (y caros) recopilan datos del módulo MIB durante el tiempo y utilizan las GUI para trazar mapas de red. Una operación SNMP adopta la forma de Unidad de datos de protocolo (PDU), que es básicamente una palabra elegante para referirse a un paquete. La versión 1 de SNMP admite cinco posibles PDU: • GetRequest/SetRequest proporciona una lista de objetos y, posiblemente, valores que deben establecerse en (SetRequest). En cualquiera de los dos casos, el agente devuelve una respuesta GetResponse. • GetResponse informa a la estación de administración sobre los resultados de una GetRequest o SetRequest devolviendo una indicación de error y una lista de las obligaciones de los valores y variables. • GetNextRequest se utiliza para realizar una transversal de la tabla y en otros casos en los que la estación de administración no conoce el nombre exacto MIB del objeto que solicita. GetNextRequest no requiere la especificación de un nombre exacto; si no existe un objeto con el nombre especificado, se devuelve el siguiente objeto en el MIB. Tenga en cuenta que para admitir esta característica, los MIB deben ser (y son) conjuntos ordenados de forma rigurosa. • Trap es la única PDU enviada por un agente por iniciativa propia. Se utiliza para notificar a la estación de administración sobre un evento poco común que pueda requerir una atención especial (como un enlace que falla). En la versión 2, las traps se nombran en el espacio del MIB. Los MIB más recientes especifican los objetos de administración que controlan la forma en que se envían las traps. 2.2.3.7 Protocolo de transferencia de hipertexto Funciona con conexiones TCP, normalmente en el puerto 80, que pueden ignorarse y utilizar otro puerto. Tras una conexión correcta, el cliente transmite un mensaje de solicitud al servidor, que envía un mensaje de respuesta. Los mensajes HTTP pueden ser leídos por el hombre y un servidor HTTP puede funcionar manualmente con un comando como el servidor telnet 80. El mensaje HTTP más simple es “GET url”, al que el servidor responde enviando el documento con dicho nombre. Si el documento no existe, el servidor probablemente enviará un mensaje de HTML cifrado informando sobre este hecho. Este sencillo método ofrece una reducida gestión de errores y su uso se ha descartado por el del método más completo que se describirá a continuación. Un mensaje completo HTTP 1.0 comienza por “GET url HTTP/1.0”. La adición del tercer campo indica que se utilizan cabeceras completas. El cliente puede enviar entonces campos adicionales de cabeceras (uno por línea) terminando el mensaje con una línea en blanco. El servidor contesta de forma similar, primero con una serie de líneas de cabecera, luego con una línea en blanco y, por último, con el documento propiamente dicho. A continuación se incluye una muestra de intercambio de HTTP 1.0: GET / HTTP/1.0 > > < HTTP/1.0 200 OK < Date: Wed, 18 Sep 1996 20:18:59 GMT < Server: Apache/1.0.0 < Content-type: text/html < Content-length: 1579 < Last-modified: Mon, 22 Jul 1996 22:23:34 GMT < < HTML document La utilización de cabeceras completas se recomienda por varios motivos: • La primera línea de una cabecera de servidor incluye un código de respuesta indicando el éxito o el fallo en la operación. • Uno de los campos de cabecera del servidor será Content-type:, que especifica el tipo MIME que describe cómo se debe interpretar el documento. • Si el documento ha cambiado de lugar, el servidor puede especificar su nueva ubicación con el campo Location:, permitiendo así que el cliente pueda reintentar de forma transparente la solicitud utilizando la nueva URL. • Los campos Authorization: y WWW-Authenticate: permiten que los controles de acceso se ubiquen en los documentos Web. • El campo Referer: permite que el cliente informe al servidor sobre la URL del documento que ha generado la solicitud, permitiendo que los servidores más rápidos puedan rastrear a los clientes en las solicitudes. Además de las solicitudes GET, los clientes también pueden enviar solicitudes HEAD y POST, de las cuales, las POST son las más importantes. Las POST se utilizan en los formularios HTML y en otras operaciones que requieren que el cliente transmita un bloque de datos al servidor. Tras enviar la cabecera y la línea en blanco, el cliente envía los datos. La cabecera debe contener un campo Content-Length:, que permite que el servidor determine cuándo se han recibido todos los datos. 2.2.3.8 Protocolo de transferencia de archivos (FTP) Se trata de uno de los protocolos de Internet más antiguos, que sigue utilizándose de forma generalizada y que se implementa utilizando el protocolo TCP. Los objetivos del FTP son: • Promocionar la compartición de archivos (programas informáticos y datos). • Apoyar el uso directo o indirecto (mediante programas) de equipos remotos. • Proteger al usuario frente a las variaciones de los sistemas de almacenamiento de archivos en los hosts. • Transferir datos de forma fiable y eficiente. Los servidores FTP se conectan al puerto 21. El FTP utiliza dos conexiones: una se utiliza como canal de datos y la otra como canal de control. Las conexiones de datos se inician en el servidor desde su puerto 20 hacia un puerto ubicado en el cliente e identificado con el comando PORT. El cliente solicita los archivos utilizando comandos enviados por el canal de control y los transmite mediante el canal de datos. El FTP, aunque el usuario puede utilizarlo en un terminal, está diseñado fundamentalmente para que lo utilicen los programas. 2.3 Direccionamiento 2.3.1 Direccionamiento básico En el sistema existente, los hosts de Internet se referencian por medio de direcciones IP ubicadas en la cabecera de los paquetes IP y se utilizan para encaminar los paquetes hacia su destino. Están formadas por un número de 32 bits, representado con una notación separada por puntos a.b.c.d (por ejemplo, 10.0.0.1), donde a, b, c y d son cada uno de 1 byte. El direccionamiento IP utiliza una direccionamiento basado en prefijos. Los prefijos iniciales de la dirección IP pueden utilizarse para tomar decisiones generales de enrutamiento. Por ejemplo, los primeros 16 bits pueden identificar a Akamai, los primeros 20 bits, su oficina en Boston, los primeros 26 bits, una Ethernet concreta en la oficina y los 32 bits al completo, un host particular. Además, el direccionamiento IP también admite asignaciones por interfaz. Esto quiere decir que las direcciones IP se asignan basándose en las interfaces, de tal forma que un host único puede tener varias direcciones IP si cuenta con varias interfaces. Por ejemplo, un host con interfaz Ethernet e interfaz serie podría tener una dirección IP para cada una de ellas. Dicho de otro modo, una dirección IP no necesita hacer referencia a un host. Es más, a lo que hace referencia es a una interfaz. Cada dirección consta de dos partes: un número de red y un número de host. En los albores de Internet, las fronteras de estas dos partes venían definidas únicamente por la clase de dirección IP y este método de direccionamiento recibía el nombre de modelo de clases. Existen cinco clases principales (de la A a la E) y a continuación nos centraremos en las tres primeras. 2.3.1.1 Direccionamiento de clase A Una red de clase A está representada por un 0 como primer bit. Está seguida de 7 bits de red y 24 bits de host. Como resultado, el byte inicial oscila entre 0 y 127, llevando a un total de 128 redes de clase A posibles (este número es, en realidad, menor, ya que algunos de los valores no se utilizan) y 16777216 hosts por cada red de este tipo. 2.3.1.2 Direccionamiento de clase B Una red de clase B está representada por una secuencia de 10 en los dos primeros bits. A éstos les siguen 14 bits de red y 16 bits de host. Como resultado, el byte inicial oscila entre 128 y 191, llevando a un total de 16384 redes de clase B posibles y 655366 hosts por cada red de este tipo. 2.3.1.3 Direccionamiento de clase C Una red de clase C está representada por una secuencia de 110 en los primeros tres bits. A éstos les siguen 21 bits de red y 8 bits de host. Como resultado, el byte inicial oscila entre 192 y 223, llevando a un total de 2097152 redes de clase C posibles y 256 hosts por cada red de este tipo. 2.3.2 Subredes La limitación de todos los hosts de una red a contener el mismo número de red puede causar problemas a medida que la red crece. Por ejemplo, una empresa que comienza con una LAN de clase C en Internet, con el tiempo, puede terminar con varias LAN, cada una de ellas con su propio enrutador y número de red de clase C. Esto puede suponer un problema, ya que cada vez que se instala una nueva red, el administrador del sistema debe ponerse en contacto con InterNIC para obtener un nuevo número de red que, posteriormente, debe anunciarse. Además, mover una máquina de una LAN a otra requiere modificar su dirección IP y esto, a su vez, implica la modificación de los archivos de configuración y un cambio de entorno, mientras que la otra máquina, al adoptar una dirección IP de reciente creación, puede recibir datos que en realidad iban dirigidos a la máquina anterior. Con el fin de solucionar estos problemas, se introdujo el concepto de subred como ampliación al sistema original creado a mediados de la década de 1980. Este concepto hace referencia a la subdivisión de una red basada en clases en varias subredes (esta definición se actualizará en las siguientes secciones para reflejar la introducción del enrutamiento sin clases). Como resultado, la empresa mencionada anteriormente podría comenzar con una dirección de clase B y no con una de clase C y, a medida que las necesidades de la máquina aumentasen, podría optar por dividir su número de host de 16 bits en un número de subred de 8 bits y otro número de host de 8 bits, consiguiendo 256 LAN, cada una de ellas con 256 hosts. Este cambio no sería apreciable de forma externa, por lo que la adjudicación de una nueva subred no requiere ponerse en contacto con InterNIC ni modificar las bases de datos externas. Una ventaja importante de las subredes reside en la reducción drástica del tamaño de las tablas de enrutamiento. Esto se basa en el hecho de que cada enrutador sólo debe realizar el seguimiento del resto de subredes y hosts locales dentro de su propia subred. Cuando llega un paquete, todo lo que debe hacer el enrutador es ejecutar un operador AND booleano de la dirección en la cabecera del paquete IP y en la máscara de subred del enrutador. Ésta última es un número de 32 bits que determina cómo se divide una dirección IP en porciones de red y de host. Por ejemplo, en una red estándar de clase B, la máscara de subred es 255.255.0.0, ya que los dos primeros bytes son todo unos (bytes de red) y los últimos dos bytes son todo ceros (bytes de host). En una red de subred similar a la propuesta anteriormente, la porción de red se amplía. Más concretamente, una máscara de subred de 255.255.255.0 dividiría el espacio de la dirección de clase B utilizando su tercer byte, y sería necesaria para generar 256 LAN, cada una de ellas con 256 hosts. Al ejecutar un AND de la dirección IP del paquete y de la máscara de subred, el enrutador puede deshacerse de la parte host del número y buscar el resultado en su tabla para decidir sobre un posterior redireccionamiento si fuera necesario. Como las máscaras de subred se utilizan bit a bit, máscaras como 255.255.240.0 (4 bits de subred y 12 bits de host) son perfectamente normales. Un aspecto importante que no hay que olvidar es que no es posible dividir una red de subredes en partes aisladas. Como resultado, todas las subredes son contiguas, ya que la información de enrutamiento no puede transmitirse a entidades que no sean miembro. Dentro de una red, todas las subredes deben poder comunicarse con el resto de subredes sin generar tráfico que fluya por otras redes. 2.3.3 El problema de los tres osos En teoría, en el modelo de clases presentado anteriormente, son posibles 4.000 millones de direcciones IP diferentes. A primera vista, esto puede resultar adecuado para los 350 millones de hosts que hay actualmente en Internet. Sin embargo, la práctica de organizar el espacio de las direcciones por clases utiliza millones de ellos. En la mayor parte de las organizaciones, una red de clase A con 16 millones de direcciones resulta demasiado grande y una red de clase C con 256 direcciones resulta demasiado pequeña. Una red de clase B con 65.536 direcciones tiene el tamaño justo. Inspirada en el cuento de Ricitos de oro y los tres osos, esta situación se conoce como el “problema de los tres osos” en la jerga de Internet. Como resultado, se utiliza un número cada vez mayor de redes de clase C, por lo que se ha producido un aumento vertiginoso en el tamaño de las tablas de enrutamiento, hecho éste que complica aún más los casos en el modelo de clases. Finalmente, junto con los dos problemas planteados arriba, la creciente demanda de direcciones IP también ha generado una necesidad de convertir el proceso de asignación de direccionamiento IP a partir de un registro central. Para tratar todos estos problemas, se introdujo el concepto de enrutamiento de interdominio sin clases. 2.3.4 Enrutamiento de interdominio sin clases 2.3.4.1 Conceptos básicos de CIDR CIDR es un sustituto del proceso de asignación de las direcciones de clase A, B y C (como ya se ha visto anteriormente) con un prefijo de red generalizado. En vez de estar limitado por identificadores (o prefijos) de 8, 16 ó 24 bits, el CIDR utiliza en la actualidad prefijos que van de 13 a 27 bits. Así, los bloques de direcciones pueden asignarse a redes con tan sólo 32 hosts o a aquéllas que tienen más de 500.000. Con esto se consigue que la asignación de direcciones sea mucho más precisa y se ajuste a las necesidades concretas de una empresa. Una dirección CIDR incluye: • La dirección IP estándar de 32 bits. • Información sobre la cantidad de bits que se utilizan en el prefijo de red. Con ello se consiguen direcciones con la forma a.b.c.d/m. Por ejemplo, podemos tener una dirección CIDR 201.14.02.48/25. En ella, “/25” indica que los primeros 25 bits se utilizan para identificar la red única. Como resultado de estos desarrollos, la definición de subred se ha actualizado a la subdivisión de un bloque CIDR en varios bloques CIDR más pequeños. Es importante mencionar en este punto que el límite del prefijo para las direcciones CIDR no está obligado a ser mayor que el de las máscaras naturales de red. Las redes existen donde el límite del prefijo contiene menos bits que la máscara natural de red y éstas reciben el nombre de superredes. Por ejemplo, una red de clase C 198.32.1.0 tiene una máscara natural de 255.255.255.0 (máscara creada por la propia definición de la red y por las proporciones de hosts de cada clase, es decir, una clase A tiene una máscara natural de 255.0.0.0, una clase B, una de 255.255.0.0, etc.). La representación 198.32.0.0/16, por otra parte, tiene una máscara más corta que la natural y es, en consecuencia, una superred según nuestra definición. 2.3.4.2 Adición de enrutamiento jerárquico para minimizar las entradas de la tabla de enrutamiento El método CIDR (en concreto, la posibilidad de crear superredes tal y como se entienden en la sección anterior) permite la adición de enrutamiento, que consiste en la capacidad de fusionar varios prefijos que tengan cierto número de bits de peso en común. De forma alternativa, la adición también puede explicarse como una situación en la que una entrada de enrutamiento de alto nivel representa a varios enrutamientos de menor nivel en tablas de enrutamiento globales. Como ejemplo, consideremos el caso en que ISP1 ha asignado el bloque CIDR 204.71.0.0/16. Éste se subasignará por ISP1 a otros clientes tal y como se muestra a continuación: 204.71.1.0/24 asignado a PequeñoCliente1 204.71.2.0/24 asignado a PequeñoCliente2 204.71.128.0/22 asignado a ClienteMedio 204.71.136.0/20 asignado a ClienteGrande. Durante el intercambio de información con otros ISP, ISP1 sólo necesita anunciar el prefijo único 204.71.0.0/16 y no todos y cada uno de los prefijos empleados por sus clientes por separado. Este método resulta ser una estructura más organizada similar a la de las redes telefónicas. Un nodo de red de eje de alto nivel sólo analiza los bits más altos y luego encamina el paquete al nodo del eje específico responsable. Éste, a continuación, busca en los bits más bajos y encamina el paquete a los nodos subtendidos que son responsables. Al aplicar esta técnica de forma recurrente, los paquetes terminan por alcanzar su destino. En general, CIDR termina siendo una estructura nueva de Internet, más jerárquica, en la que cada dominio obtiene sus direcciones IP de un nivel superior. Los servicios del registro pueden asignar las direcciones a los ISP quienes, a su vez, las subasignan a sus clientes y así sucesivamente. Además de la reducción intrínseca del tamaño de las tablas de enrutamiento, este enfoque también consigue lograr un sistema en el que, más que buscar asignaciones de direcciones directamente desde InterNIC, resulta posible obtenerlas de forma descentralizada. 2.3.4.3 Regla de enrutamiento de coincidencia más específica Encaminar a todos los destinos utilizando la técnica de direccionamiento CIDR siempre se lleva a cabo siguiendo un proceso largo de coincidencias. Un enrutador que se ha decidido entre dos prefijos de distinta longitud en la misma red siempre seguirá al de la máscara más larga. Por ejemplo, un enrutador con las siguientes dos rutas en su tabla de enrutamiento: 198.32.1.0/24 a través de la ruta 1 198.32.0.0/16 a través de la ruta 2 intentará buscar coincidencias del host 198.32.1.1 con el destino que tenga el prefijo más largo y, en consecuencia, se enviará el tráfico por la ruta 1. Dicho de otra manera, las redes “más específicas” (en el sentido de que son una subred del total o de un bloque CIDR) prevalecen, ya que ofrecen más información sobre la ubicación de una red. 2.3.4.4 Problemas asociados a la adición La adición, si no se aplica correctamente, podría conllevar la aparición de agujeros negros. Esto tiene lugar cuando el tráfico llega y se detiene en una máquina que no representa el destino esperado, pero en la que no es posible efectuar un reenvío. Estas situaciones pueden darse, por ejemplo, si un cliente se conecta a un proveedor único y tiene un espacio de dirección IP totalmente distinto. Esto podría ser el resultado de un cambio de proveedores por parte del cliente sin haber modificado antes la dirección de asignación. Normalmente, en estas situaciones, se anima (o se obliga) a los clientes a que vuelvan a numerar, pero si no ocurre así, el nuevo proveedor no podrá añadir la dirección y, además, el antiguo proveedor no podrá hacerlo de forma tan eficiente como antes, ya que se habrá creado un agujero negro en el espacio de la dirección. El efecto global de la utilización de direcciones ajenas al espacio de la dirección del proveedor se resume en que se deben instalar más rutas en las tablas de enrutamiento globales. Otra situación que podría darse es el caso en el que los clientes, con el fin de evitar verse a merced de un ISP en concreto, se conectan a varios proveedores (esto es, se convierten en multihome) pero tienen IP asignadas sólo a uno de ellos. A menudo resulta imposible que los otros ISP agreguen las IP de estos clientes, ya que una o varias de las direcciones intermediarias pertenecen a algún cliente que no está en multihome con ellos y cualquier adición podría crear un agujero negro. En consecuencia, los ISP deben observar cada uno de estos rangos de direcciones IP que tienen en común con otro ISP más allá de su propio espacio de direcciones. Éstas son a menudo más específicas que las direcciones para el bloque CIDR del ISP que las asignó originalmente y, por lo tanto, el tráfico se encamina fundamentalmente a través de los ISP que no emitieron la IP. Una solución para estos clientes multihome es adquirir IP de cada uno de los ISP a los que están conectados, pero esto provoca la pérdida de rutas en la organización multihome. Si uno de los ISP tiene problemas, el tráfico del host multihome de la IP obtenida desde ese ISP se perderá, ya que no se publica en ningún otro lugar. Este hecho anula, en gran parte, el propósito del multihoming. Un enfoque alternativo requiere tomar una dirección totalmente distinta del espacio de dirección de todos los ISP a los que el cliente está conectado. Sin embargo, en este caso la desventaja es que todos los enrutadores de Internet deben tener una ruta específica a estas direcciones de nueva creación, con lo que se generarían tablas de enrutamiento muy grandes. 2.3.5 Problemas asociados al IPv4 – escalabilidad, seguridad y calidad del servicio “Creo que hay un mercado mundial para, tal vez, cinco ordenadores” - Thomas Watson, 1943 “640 K debería ser suficiente para cualquiera” - Bill Gates, 1981 “32 bits debería ser espacio suficiente para las direcciones” - Vinton Cerf, 1977 Con el gran crecimiento inesperado y sin precedentes de Internet, se ha hecho cada vez más obvio que los días del IPv4 (la implementación actual del protocolo IP analizada en secciones anteriores) están contados. Los problemas de disminución de espacio de direcciones y el control de un registro central siguen estando ahí y la llegada del CIDR sólo ha servido como parche temporal. Actualmente, los registros no pueden dar respuesta a solicitudes de grandes bloques IP y se espera que para el año 2008 las direcciones IPv4 se hayan terminado. Este hecho proviene del aumento de las comunicaciones móviles de tercera generación, la demanda impuesta por los países emergentes que no estuvieron presentes en la “fiebre del oro” del IPv4 y la llegada de las redes locales. Además, está el aumento drástico del tamaño de las tablas de rutas (que ascienden a aproximadamente 60.000 entradas en la actualidad) debido a una falta inherente de cualquier red o consideración de enrutamiento. Dejando a un lado los problemas de la memoria estática, esto provoca una degradación del rendimiento, ya que los algoritmos actuales no escalan de forma lineal. El IPv4 también echa en falta la ausencia de un mecanismo incorporado que cumpla los requisitos del servicio que deben cumplirse en la red mientras se transporta un flujo. Esto también puede denominarse como ausencia de calidad de servicio o CdS y se suele entender como la limitación para ir más allá del servicio de datagrama de “mejor esfuerzo” disponible en la actualidad, que se centra solamente en una métrica arbitraria única: el peso administrativo o el recuento de saltos. Por último, el IPv4 también parece adolecer de la ausencia de un mecanismo intrínseco de seguridad, que desemboca en caras modificaciones de aplicaciones y hosts para poder protegerlos frente a diversos ataques. Si no se tiene este mecanismo, es posible que tengan lugar pérdidas de privacidad, pérdidas de integridad de datos, intercambios de identidades o negaciones del servicio. Quizá el problema más imperioso al que se enfrenta la Internet IP es la disminución de direcciones. Las soluciones concebidas a corto y largo plazo están aún en fase de desarrollo. La solución a corto plazo es el CIDR (enrutamiento de interdominio sin clases). Las soluciones a largo plazo consisten en varias propuestas de nuevos protocolos de Internet con direcciones más largas. Es posible, no obstante, que el CIDR no sea suficiente para mantener Internet hasta que las soluciones a largo plazo puedan implementarse. En consecuencia, se ha planteado otra solución: alguna forma de reutilización de direcciones, ya sea complementando al CIDR o relegándolo al olvido. La solución de reutilización de direcciones se basa en ubicar los traductores de direcciones de red (NAT)8 en la frontera de los dominios stub. Cada cuadro NAT tiene una tabla formada por pares de direcciones IP y direcciones globales únicas. Las direcciones IP incluidas en el dominio stub no son globales ni únicas. Se reutilizan en otros dominios y con ello se resuelve el problema de disminución de direcciones. Las direcciones IP globales únicas se asignan siguiendo los métodos actuales de asignación de direcciones CIDR. La principal ventaja del NAT es que puede instalarse sin necesidad de modificar ni los hosts ni los enrutadores. Ahora bien, los NAT también presentan numerosos inconvenientes9 que van desde su incapacidad para gestionar protocolos arbitrarios, hasta el hecho de que representan puntos únicos de fallos y reducen la fiabilidad total del sistema. 2.3.6 La solución IPv6/Ipng Para afrontar las limitaciones del IPv4, se ha propuesto un nuevo protocolo denominado IPv6 o IPng (IP de nueva generación). En la actualidad existe una infraestructura de IPv6 en Internet, pero aún no se han implementado los DNS. El IPv6 cuenta con varias características. Para empezar, proporciona un espacio de direcciones aumentado de 128 bits que permite IP globales únicas para todos los dispositivos. Además, también ofrece un enrutamiento más eficaz gracias a una estructura jerárquica que consigue la asignación de direcciones añadidas desde el principio. Sin embargo, los clientes multihome representan un fracaso en esta jerarquía y actualmente es bastante común que las empresas recurran al multihome. El IPv6 también reserva campos de estas cabeceras de paquetes para encargarse de la seguridad y de la CdS. Con el fin de enfrentarse al problema de la CdS, la cabecera del IPv6 tiene dos campos; una etiqueta de flujo de 20 bits y un indicador de clase de tráfico de 8 bits. Por último, los problemas de seguridad se abordan con la introducción del IPSec, que utiliza un nuevo conjunto de cabeceras añadidas para asegurar el payload del paquete IP. Éstas incluyen la autenticación de cabecera (AH) y el payload de seguridad encapsulado (ESP). 2.3.7 La transición del IPv4 al IPv6 La idea más importante en la que se basa la transición del IPv4 al IPv6 es que Internet es demasiado grande y está demasiado descentralizada para tener un “día D” (un día concreto en el que cada host y enrutador se actualicen desde el IPv4 al IPv6). Por lo tanto, el IPv6 necesita desarrollarse progresivamente de tal forma que los hosts y los enrutadores que sólo funcionan con el IPv4 puedan seguir operando tanto tiempo como sea posible. No se espera la conclusión de este proceso hasta el año 2010. Además, la aparición de los NAT ha retrasado la adopción generalizada del IPv6. Aunque son muchos los que detestan los NAT, su uso proporciona la funcionalidad principal del IPv6: un mayor número de direcciones de host. Los NAT han reducido hasta ahora de forma eficaz la presión para implementar una solución más elegante a largo plazo al problema de la 8 9 K. Egevang, P. Francis, “The IP Network Address Translator (NAT)” - RFC1631 Keith Moore “Things that NATs break,” http://www.cs.utk.edu/ moore/what-natsbreak.html disminución de direcciones. El espacio de direcciones aumentado que brindan los NAT ha conseguido que sean menos los que estén dispuestos a adoptar este nuevo protocolo de red. Por lo tanto, parece que tendremos IPv4 para largo. Sin embargo, tras la transición, los nodos del IPv4 deberían (idealmente) poder comunicarse con el resto de nodos del IPv4 y con algunos conjuntos de nodos admitidos por el IPv6 de forma indefinida. Asimismo, los hosts del IPv6 deberían poder comunicarse con otros nodos del IPv6, incluso cuando parte de su infraestructura sólo sea compatible con el IPv4. Se han definido dos mecanismos principales para contribuir a esta transición y se analizan a continuación. 2.3.7.1 Funcionamiento de doble pila La idea de este concepto es bastante sencilla. Los nodos del IPv6 se ejecutan tanto en IPv6 como en IPv4 y utilizan el campo de la versión de la cabecera para decidir en qué pila se procesa el paquete recibido. 2.3.7.2 Tunelización Se trata de la técnica empleada en muchas situaciones en las que un paquete IP se envía como payload de otro paquete IP; es decir, se adjunta una nueva cabecera IP en frente de la cabecera de un paquete IP existente. En la transición del IPv6, la tunelización se utiliza para enviar un paquete IPv6 a través de una porción de red que sólo admita IPv4. Esto significa que el paquete IPv6 se encapsula dentro de una cabecera de IPv4 que contenga la dirección del punto final del túnel en su cabecera y se transmite a través de una porción exclusiva de la red IPv4 para, después, desencapsularse en el punto final. El punto final puede ser un enrutador o un host. En cualquiera de los dos casos debe ser capaz de procesar el paquete IPv6 tras la desencapsulación. 2.4 Enrutamiento Internet está formada por millones de ordenadores y cualquier de ellos puede, en teoría, comunicarse con el otro. Sin embargo, no todos los equipos están vinculados físicamente entre sí y la información se transmite desde un punto a otro utilizando un paradigma de almacenamiento y reenvío. Los paquetes de datos se transmiten entre equipos enlazados físicamente y se encaminan a través de la red hacia sus destinos. Distintos protocolos de enrutamiento son los que definen las reglas para el reenvío de los paquetes. En esta sección abordaremos el estudio de estos protocolos. 2.4.1 Modelo topológico La arquitectura de área extensa de Internet está dividida en un número de sistemas autónomos (AS) conectados arbitrariamente. Un AS es un conjunto de enrutadores y hosts regidos por una administración técnica única (normalmente una entidad comercial única) que utilizan uno o varios protocolos de pasarela interior (IGP) y métricas comunes para encaminar los paquetes dentro del AS y utilizan un protocolo de pasarela exterior (EGP) para encaminar los paquetes hacia y desde otros AS. El uso del término sistema autónomo refuerza en este caso el hecho de que, aunque se utilicen varios IGP y métricas distintas, la administración de un AS tiene para el resto de AS un plan único y coherente de enrutamiento interior y presenta una imagen constante de los destinos que se pueden alcanzar. Cada AS se identifica de forma única mediante un entero de 16 bits asignado por InterNIC y utilizado por los EGP para implementar la directiva de enrutamiento y evitar los bucles de enrutamiento de alto nivel. Un AS puede entenderse como un conjunto de prefijos de direcciones IP de CIDR que comparten una administración técnica común. Por ejemplo, el bloque CIDR desde 208.130.28.0 a 208.130.31.255, así como la red 201.64.75.0 puede ser un AS 2934. La red del MIT es un AS 3. Gran parte del tráfico portado dentro de un AS comienza o termina en dicho AS (esto es, o bien la dirección IP origen o la dirección IP de destino del paquete IP identifica un host interno de dicho AS). El tráfico que se ajusta a esta descripción recibe el nombre de “tráfico local”. El tráfico que no se ajusta a esta descripción recibe el nombre de “tráfico de tránsito”. Teniendo en cuenta la forma concreta de un AS para gestionar el tráfico de tránsito, los AS pueden dividirse en las siguientes categorías: • AS de stub: es aquél que se conecta a otro AS. En lo que a enrutamiento se refiere, podría entenderse como una simple ampliación del otro AS. De hecho, muchas redes con conexión simple a Internet no tienen un número único de AS asignado y sus direcciones de red se tratan como parte del AS padre. • AS de tránsito: tiene conexiones a más de un AS y puede utilizarse como conducto para el tráfico (tráfico de tránsito) entre otros AS. Los proveedores de servicios de Internet más importantes son AS de tránsito. • AS multihome: tiene conexiones a más de un AS, pero no permite el paso del tráfico de tránsito, aunque sus hosts internos sí pueden encaminar tráfico a través de varios AS. Se trata de la configuración característica de redes empresariales grandes con varias conexiones redundantes a Internet, pero que no desean que el tráfico de otros pase por sus redes. 2.4.2 Tipos de protocolos de enrutamiento Para una red determinada que pueda representarse como un gráfico no directo conectado (en el que los extremos representan las conexiones directas entre las entidades de red) existen dos clases generales de protocolos que pueden utilizarse para encaminar paquetes entre nodos. 2.4.2.1 Protocolos distancia-vector Este tipo de protocolo de enrutamiento requiere que cada enrutador simplemente informe a sus vecinos sobre su tabla de enrutamiento. Los enrutadores envían actualizaciones periódicas de enrutamiento que incluyen un vector de las distancias al resto de nodos. En cada ruta de red, los enrutadores receptores seleccionan al vecino que se anuncia al menor coste y agregan su entrada a la tabla de enrutamiento. Como resultado, cada nodo tiene el árbol de ruta más corto (determinado por la normativa) que ofrece las rutas al resto de los nodos disponibles. Los algoritmos de protocolo DV sólo utilizan la información de los nodos cercanos. Estos protocolos suelen ser descentralizados e iterativos y están basados en algoritmos como el de Bellman-Ford para las rutas más cortas. Los protocolos DV también suelen ser relativamente escalables. El protocolo DV básico recibe el nombre de protocolo de información de enrutamiento (RIP). El protocolo de pasarela fronterizo (BGP) utiliza esencialmente un algoritmo DV, pero con varios cambios añadidos. Trataremos este asunto más adelante en profundidad. El enrutamiento basado en los protocolos DV puede causar muchos problemas si los enlaces no son estables o si los nodos anuncian información incorrecta. Podría desembocar en bucles infinitos y desincronizar la red. La convergencia en los protocolos DV suele ser baja. De hecho, la topología de una red puede tardar minutos e incluso horas en sincronizarse, independientemente de los recursos computacionales que haya disponibles en cada nodo. 2.4.2.2 Protocolos Link-State (LS) Los protocolos Link-State requieren que cada enrutador mantenga al menos una asignación parcial de la red. Cuando una red cambia de estado (de activa a inactiva o viceversa), se envía una notificación llamada aviso de estado de enlace (link state) a toda la red. Todos los enrutadores advierten el cambio y vuelven a calcular sus rutas en concordancia. El protocolo OSPF (abrir ruta más corta primero) es un ejemplo de protocolo LS. Como cada nodo da una buena idea del gráfico de red y las actualizaciones sólo requieren la adición o eliminación de nodos y extremos, los protocolos LS convergen más rápidamente hacia un estado estable que los protocolos DV. También son más fiables, fáciles de depurar y con menor intensidad de ancho de banda que los protocolos DV. Por otro lado, los protocolos LS suelen ser más complejos que los protocolos DV. También tienden a ser más intensivos en términos de memoria y de cálculo local. Los protocolos LS no escalan tan bien como los DV, por lo que los protocolos como el OSPF suelen utilizarse normalmente para encaminar paquetes de forma interna dentro de un AS. Los IGP suelen estar relacionados con la optimización de una métrica de ruta concreta y su escalabilidad no supone un problema importante. 2.4.3 Protocolo de pasarela fronterizo (BGP) El protocolo de pasarela fronterizo (BGP) es un protocolo de enrutamiento de interdominio de facto utilizado para intercambiar la accesibilidad de información entre sistemas autónomos en la Internet global. Se trata de un protocolo distancia-vector que permite que cada AS ignore la métrica basada en la distancia con métricas basadas en normativas cuando se seleccionan las mejores rutas. 2.4.3.1 Motivaciones de diseño El diseño de un BGP estuvo motivado por tres importantes necesidades: • Escalabilidad. La división de Internet en distintos dominios de enrutamiento (los AS) se realizó en tiempos de NSFNET. Un requisito importante del BGP era garantizar que la infraestructura de enrutamiento de Internet permaneciese escalable a medida que el número de redes conectadas aumentaba. • Normativa. La capacidad de cada AS para implementar y afianzar varias formas de normativas de enrutamiento era un objetivo importante de diseño. Algunas de las consecuencias de esto fueron el desarrollo de estructuras de atributos de BGP para anuncios de rutas, la permisividad del filtrado de las mismas y la priorización de las preferencias locales. • Cooperación en circunstancias competitivas. El BGP se diseñó en gran parte para gestionar la transición desde NSFNET hacia una situación en la que la infraestructura principal ya no se ejecutase mediante una entidad administrativa. El enrutamiento en Internet se gestionaría mediante un gran número de ISP mutuamente competitivos que cooperarían libremente para proporcionar conectividad global. El protocolo de enrutamiento se creó entonces para permitir que los AS pudiesen tomar decisiones estrictamente locales sobre la forma de encaminar los paquetes teniendo a su disposición cualquier conjunto de posibilidades. 2-20 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Figure 2.4. Sistemas autónomos en BGP 2.4.3.2 El protocolo BGP-4 2.4.3.2.1 Un modelo idealizado Los protocolos modelan Internet como un conjunto de sistemas autónomos con relaciones de peering entre sí. Esto crea un gráfico no dirigido en el que los vértices representan los AS y los extremos representan las conexiones directas fiables entre los AS. Cada vértice mantiene el árbol encaminado de ruta más corta especificando las mejores rutas a los otros vértices. Las rutas son seleccionadas por cada AS basándose en su propia normativa y en las mejores rutas próximas. Un vértice reconoce el conjunto de rutas disponibles mediante los anuncios de las rutas próximas. Los vértices envían dichos anuncios siempre que las tablas de enrutamiento cambian. Estos anuncios contienen, entre otros, información sobre los AS que necesitan utilizarse en la ruta. Con ellos se consigue la distancia-vector o la ruta-vector de la ruta. Siempre que un vértice tiene más de una ruta en un destino determinado, se selecciona la mejor de todas. Primero se selecciona según las preferencias locales del vértice y, a continuación, se escoge la ruta con la distancia-vector más corta. Las coincidencias se solucionan de forma arbitraria. Los anuncios de rutas sufren transformaciones a medida que pasan de un vértice al siguiente. En concreto, cada vez que se transmite una ruta, el vértice adjunta su identificador a la ruta-vector de la ruta. Los bucles pueden evitarse de esta manera, ya que ningún vértice acepta anuncios de ruta cuya ruta-vector aparezca en el propio vértice. A medida que los anuncios se propagan por la red, cada vértice mejora de forma iterativa su visión del resto de las rutas disponibles. Por último, se espera que el sistema converja a un estado estable. En este estado final, cada vértice conoce la mejor ruta hacia el resto de los vértices. Como existen preferencias locales, la definición sobre qué hace que una ruta sea la mejor puede variar de nodo A medida que los anuncios se propagan por la red, cada vértice mejora de forma iterativa su visión del resto de las rutas disponibles. Por último, se espera que el sistema converja a un estado estable. En este estado final, cada vértice conoce la mejor ruta hacia el resto de los vértices. Como existen preferencias locales, la definición sobre qué hace que una ruta sea la mejor puede variar de nodo 2-21 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 2.4.3.2.2 El protocolo Dos sistemas (normalmente dos enrutadores fronterizos en distintos AS) forman una conexión TCP fiable entre uno y otro e intercambian mensajes para abrir y confirmar los parámetros de conexión. El flujo inicial de datos es la tabla de enrutamiento BGP al completo. Más tarde, se envían actualizaciones incrementales a medida que las tablas de enrutamiento cambian. Hay dos tipos de actualizaciones. El primero son los anuncios, que son cambios en las rutas existentes o en rutas nuevas. El otro son las retiradas, que informan que el peer que nombró las rutas ya no está disponible. Los anuncios del BGP contienen un conjunto de prefijos formados, a su vez, por un conjunto de atributos asociados a él. El atributo de ruta AS es un vector que enumera todos los AS (en orden inverso) por los que este anuncio de ruta del prefijo ha pasado. Tras cruzar una frontera AS, el primer enrutador toma el único identificador de su propio AS a este vector antes de seguir propagando el anuncio. Los enrutadores evitan los bucles mediante la eliminación de mensajes si sus AS ya están presentes en este vector. Un enrutador utiliza normativas de importación para transformar las actualizaciones de ruta entrantes. Estas normativas de importación incluyen la negación de una actualización o la aceptación de la actualización y la asignación de una preferencia local para indicar el grado de aptitud de la ruta. De forma similar, las normativas de exportación permiten que un enrutador determine si debe enviar la mejor ruta a un vecino y, de ser así, qué sugerencia debe enviarle para utilizarla. Los enrutadores BGP utilizan los campos de los anuncios de las rutas para determinar qué rutas deben utilizar en la tabla de enrutamiento. Generalmente, las rutas adquiridas de forma externa (mediante eBGP) son preferibles a las adquiridas internamente (mediante iBGP). Las preferencias locales que representan cualquier normativa local arbitraria obtienen la máxima prioridad en la selección. La longitud de la ruta-vector del AS es el segundo criterio más importante. Puede que no sea la distancia más corta, ya que sólo debe contar el número de AS que se necesitan encaminar. Los enrutadores también pueden utilizar la ruta del AS mediante la repetición de los identificadores del AS para localizar las rutas menos aptas a otros AS. Por último, señalar que las coincidencias se evitan de forma arbitraria. Debido a estos factores y a algunas decisiones de implementación de enrutadores específicas de los proveedores, resulta prácticamente imposible determina las mejores rutas sólo a partir de las relaciones de conectividad. BGP utiliza TCP, lo que proporciona un envío ordenado y fiable y no necesita una actualización periódica de toda la tabla de enrutamiento. Un portavoz BGP debe, por lo tanto, retener la versión actual de todas las tablas de enrutamiento BGP y de todos sus peers en la duración de la conexión. Los mensajes KeepAlive se envían de forma periódica en las dos direcciones para garantizar que la sesión BGP sigue ejecutándose. Si no existen dichos mensajes, la sesión BGP se cierra y todas las rutas adquiridas en dicha sesión se eliminan de las tablas de enrutamiento de sus respectivos peers. Los mensajes de notificación se envían como respuesta a errores o condiciones especiales. Si una conexión presenta una condición de error, se enviará un mensaje de notificación y se cerrará la conexión. Sin embargo, el BGP no se diseñó para gozar de una rápida detección y recuperación de fallos, por lo que estos mecanismo no suelen ser especialmente útiles en escalas de tiempo pequeñas. 2-22 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Figure 2.5. Sesiones iBGP 2.4.3.2.3 eBGP: enrutamiento inter-AS El BGP externo (eBGP) es un modo estándar en el que se utiliza BGP. Los enrutadores fronterizos de un AS determinado se conectan a los enrutadores de otros AS a través de sesiones BGP. Estos enrutadores proporcionan los únicos puntos de entrada y salida de sus AS. Implementan reglas de filtrado de rutas e intercambian un subconjunto de las mismas mediante BGP y enrutadores en otros AS a través de sesiones BGP. 2.4.3.2.4 iBGP: coherencia intra-AS Si un AS en concreto tiene varios portavoces BGP y proporciona servicio de tránsito para otros AS (como suele ser el caso, al menos para un número reducido de rutas), debe prestarse atención para garantizar una visibilidad constante de las rutas dentro del AS. En general, cada AS tendrá más de un enrutador fronterizo que participará en las sesiones eBGP con los AS próximos. Durante este proceso, cada enrutador eBGP obtendrá información sobre algún subconjunto de reglas conocidas por el AS. Como uno de los objetivos del BGP es permitir que cada AS sea tratado como una entidad monolítica abstracta, es fundamental que cada enrutador del AS tenga un concepto completo de las rutas disponibles para el eBGP en todo el AS. La coherencia se consigue permitiendo que los enrutadores fronterizos intercambien información mediante iBGP. Los enrutadores eBGP se conectan entre sí dentro del AS y mantienen sesiones iBGP entre sí. Estas sesiones permiten que cada enrutador actualice sus tablas con la información contenida en el resto. 2-23 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Es importante señalar que un iBGP no es un IGP como RIP o OSPF. De hecho, los mensajes enviados durante una sesión iBGP se encaminan dentro del AS con cualquier IGP que esté operativo. Las sesiones iBGP sólo proporcionan un medio por el cual los enrutadores dentro de un AS pueden utilizar el mismo protocolo (BGP) para intercambiar información completa. 2.4.3.2.5 La cuestión de la convergencia Informalmente, un sistema BGP puede representarse por un estado S = <G, Normativa(G), S0>, incluyendo un gráfico AS G = (V, E), y conteniendo normativas de importación para cada vj en V y con un estado inicial S0 = (c0,1, c0,2,c0,n) donde c0,j es el destino originado por vj en el estado S0. Si vj se activa, obtiene anuncios de ruta de sus vecinos intermediarios y selecciona las mejores rutas. Se dice que el estado S es final si en la activación de cualquier vj, el sistema permanece en el estado S. Una secuencia de activación del sistema simplemente es una secuencia que proporciona los vértices vj y el orden en que se activan. Se dice que un sistema BGP es convergente si concluye en un estado final independiente de la secuencia de activación. Se dice que el sistema es soluble si cuenta con un estado final. Al contrario de lo que ocurre con protocolos distancia-vector puros, como el RIP, el BGP no garantiza la convergencia. Las normativas BGP se implementan de forma local en la actualidad con mucho o poco conocimiento global. Aunque la mayoría de los conflictos de las normativas de enrutamiento son gestionables, siempre existe la posibilidad de que puedan provocar divergencias en el protocolo. Las normativas de enrutamiento de cada AS por separado pueden ser razonables localmente, pero no hay garantía alguna de que la interacción de normativas definidas independientemente puedan ser razonables globalmente. En teoría, un conjunto de normativas bien configuradas localmente puede seguir provocando anomalías de enrutamiento globales. Es posible, por lo tanto, que un conjunto de AS intercambie mensajes en todo momento sin converger hacia un conjunto de rutas estable. Esta divergencia del BGP podría contribuir a una gran cantidad de inestabilidad en el sistema de enrutamiento global. La fluctuación de la topología de red puede tener un efecto directo en el rendimiento final. Una red que no haya logrado convergencia puede descartar paquetes o enviarlos inutilizados. En casos extremos, la ausencia de convergencia puede tener como resultado la creación de agujeros negros en paquetes (con rutas de anuncios de AS que, en esencia, no tiene y con la eliminación de paquetes que se envían por dichas rutas). En consecuencia, con el fin de que una red basada en BGP pueda funcionar eficientemente, debe ser convergente. Por desgracia, son muchos los sistemas BGP que no gozan de convergencia. 2.4.3.2.6 El sistema Bad Gadget En esta sección se incluye un ejemplo de un sistema BGP no soluble denominado “Bad Gadget” (mal aparato). Ninguna ejecución del protocolo BGP puede llegar a un enrutamiento estable en este sistema. La red “Bad Gadget” se presenta en la figura 2.6, donde cada nodo representa un AS y los extremos representan las conexiones entre los AS. Supongamos que existe un destino único con d originado en AS 0. La normativa se implementa de tal forma que cada AS opta por la ruta en el sentido de las agujas del reloj de longitud 2 sobre el resto de las rutas hacia 0. Es decir, AS 3 opta por la ruta 3 - 2 - 0 y no por la 3 - 0. Puede demostrarse así que este sistema es divergente. Esta prueba se documenta en un estudio de Griffen y Wilfong10. En este tema se presenta una visión general. 2-24 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Figura 2.6. Red Bad Gadget Un ejemplo es el primero presentado abajo para proporcionar una idea intuitiva. La figura 2.7 muestra el sistema a través de una secuencia de cuatro activaciones. Los nodos negros representan un nodo activándose, es decir, anunciando sus rutas. Las flechas rojas indican las rutas. En (1) no se han realizado anuncios y ningún nodo conoce las rutas. En (2) el nodo 0 anuncia todas las rutas directas hacia él y cada nodo toma la conexión directa hacia 0 como la mejor ruta. En (3) el nodo 1 anuncia sus rutas, que hacen que el nodo 2 cambie su ruta hacia la más adecuada en el sentido de las agujas del reloj. En (4) el nodo 3 anuncia sus rutas y hace que el nodo 1 cambie. Por último, en (5) el nodo 0 se anuncia de nuevo y el nodo 2 vuelve a cambiar. Si vamos más allá con este razonamiento, podemos obtener la prueba de que no se está estableciendo ninguna ruta estable. La prueba formal presentada en el documento verifica esta intuición. A continuación se incluye una visión general de la prueba. Para que este sistema tenga una solución debe lograr un estado final. Es fácil ver que en el caso de sistemas de destino único, en un estado final el gráfico inducido por la ruta del AS de cada vértice al destino es un árbol con raíces en el destino y que este estado final puede alcanzarse mediante la activación de todos los nodos del primer orden del árbol (esta conclusión está extraída del documento). Utilizando este hecho, podemos demostrar que este sistema es divergente. Sólo es necesario tener en cuenta dieciséis árboles extendidos con raíz en AS 0. Cualquier árbol que no se expanda en este gráfico no puede ser una solución, ya que cada AS 1, 2 y 3 tiene una ruta directa hacia d. Además, al tratarse de un sistema simétrico, sólo los seis casos presentados en la figura 2.8 son relevantes. 10 Este ejemplo se estudia detalladamente en los siguientes documentos: [1] Timothy Griffn and Gordon T. Wilfong, “An Analysis of BGP Convergence Properties” SIGCOMM [2] K. Varadhan, R. Govindan & D. Estrin, “Persistent Route Oscillations in Inter-Domain Routing” ISI TR 96-631 2-25 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Figura 2.7. Ejemplo de activación de Bad Gadget Figura 2.8. Posibles árboles de enrutamiento para Bad Gadget 2-26 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 En la figura 2.8, los AS que cambiarán su selección de mejores rutas hacia d están marcados con un círculo con relleno. Cada AS marcado puede seleccionar una ruta en el sentido contrario a las agujas del reloj de longitud 2 o invertir la ruta directa a d. Es fácil ver que el sistema no tiene solución. Este sistema divergente podría parecer un ejemplo artificioso y hacernos pensar que en la práctica esta divergencia podría cuestionarse en un BGP. En la siguiente sección se incluyen algunos aspectos de la inestabilidad del BGP en Internet. 2.4.3.2.7 Observaciones sobre la inestabilidad ¿Diverge el BGP en la práctica? Existen varias historias horribles sobre redes que de forma accidental se establecieron de forma autónoma como sumideros de tráfico y hay algunas pruebas sobre oscilaciones crónicas. También se han observado algunos casos de convergencia desfasada hasta 50 minutos. Aun así, BGP por lo general ha demostrado ser convergente en Internet. Es posible que los enrutadores de Internet experimenten cargas de CPU importantes y problemas de memoria a altos niveles de inestabilidad de enrutamiento. En 1997 por ejemplo, muchos de los enrutadores de Internet desarrollados comúnmente estaban basados en el procesador de la serie relativamente ligera 68000 de Motorola. La alta inestabilidad solía causar problemas en el consumo de memoria y en el retraso del procesamiento de las colas de paquetes. A menudo, los retrasos en el procesamiento eran tan acusados que los enrutadores desfasaban el enrutamiento en paquetes KeepAlive que, en consecuencia, se marcaban como inactivos o no localizables por otros enrutadores. La experiencia con NSFNet y los ejes de área extensa han demostrado que un enrutador que no consigue funcionar con gran inestabilidad de enrutamiento puede provocar una “tormenta de agitación de rutas”. En este modo de oscilación patológica, los enrutadores sobrecargados son marcados como no localizables por los peers BGP a medida que van fallando para mantener el intervalo requerido de transmisiones KeepAlive. Como los enrutadores se marcan como no localizables, los enrutadores peer seleccionan rutas alternativas para los destinos previamente localizables a través del enrutador “inactivo” y transmite actualizaciones que reflejan el cambio de la topología en cada uno de sus peers. Por su parte, tras la recuperación de problemas transitorios de CPU, el enrutador “fallido” intentará reiniciar una sesión BGP de peering con cada uno de los otros enrutadores y generará un estado de transmisiones dump. Esta carga aumentada provocará que aún más enrutadores fallen e iniciará una “tormenta” que comenzará a afectar a secciones más grandes de Internet. Varias de las tormentas de agitación de rutas ocurridas hasta ahora han causado la inactividad de millones de clientes de red. La última generación de enrutadores de varios proveedores proporciona un mecanismo por el cual el tráfico BGP obtiene mayor prioridad y los mensajes KeepAlive resisten incluso en condiciones de alta inestabilidad. La mayor parte de la inestabilidad de los enrutadores de Internet es resultado de los fallos de software y de decisiones de implementación concretas de ciertos proveedores. Sin embargo, tras el desarrollo de enrutadores actualizados por los ISP, esta inestabilidad ha decrecido en gran medida. La heurística como la disminución de los anuncios de rutas también ha mejorado las propiedades del BGP. Así que, aunque en teoría es posible que BGP diverja, se ha demostrado empíricamente que en última instancia resulta convergente. No obstante, son muchos los casos de convergencia desfasada. En un estudio11, Labovitz et al introdujeron fallos BGP (anuncios/extracciones) de prefijos variados y longitudes de ruta de AS en sesiones de peering IP en varios puntos geográficos. Observaron desfases que ascendían hasta a 50 en su estudio. De hecho, los tiempos de convergencia de enrutamiento tras los fallos se encontraban en el orden de decenas de minutos. 11 “Delayed Internet Routing Convergence” C. Labovitz, A. Ahuja, A. Bose & F. Jahanian, Proceedings of SIGCOMM 200 2-27 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Esta latencia puede entenderse estudiando la forma en que BGP explora las rutas. Además de las distintas anomalías específicas de cada proveedor, la razón fundamental para la convergencia pasa por que los protocolos de ruta-vector consideran varias rutas de una longitud determinada en contraposición a los protocolos de distancia-vector, que sólo consideran una ruta de una longitud determinada. En Labovitz et al construyen un ejemplo en el que tienen en cuenta cada ruta libre de bucle de la malla al completo (hay un número exponencial de dichas rutas). Se ha demostrado que existe un posible orden de mensajes de tal forma que BGP explore todas las rutas posibles de AS, con todas las longitudes posibles. BGP es, por lo tanto, O(N!), donde N es el número de portavoces BGP no predeterminados en un gráfico completo con normativa predeterminada. Además, no existe ningún conocimiento global en los protocolos de ruta-vector, por lo que las heurísticas de optimización no son muchas. Así, no resulta sorprendente que la convergencia tarde bastante tiempo en conseguirse. 2.4.3.2.8 Accesibilidad en un AS Dada una red de sistemas autónomos vinculada por un BGP y un destino accesible desde un vértice (x), en ocasiones es útil saber si el destino es accesible desde cualquier otro vértice (y). La accesibilidad es una propiedad que se presenta si existe un estado final del sistema en el que hay una ruta desde y hacia el destino. La determinación de la existencia de la accesibilidad en un sistema BGP es NP-completa. Esto puede demostrarse mediante la reducción de 3-SAT y la prueba se presenta en el documento de Griffen y Wilfong. La base de datos de arbitraje de enrutamiento (RADB) pretende ofrecer información de accesibilidad entre AS a los usuarios de Internet. El registro de enrutamiento de Internet (IRR, del que RADB forma parte) mantiene la información de enrutamiento de los ISP por separado en varios depósitos públicos como intento de coordinación de una normativa de enrutamiento global. La base de datos de la normativa de enrutamiento del IRR incluye información de enrutamiento a varios niveles (por ejemplo, prefijos de direcciones distintas, AS, etc.) Las rutas se registran con la RADB de forma voluntaria. Registrar una ruta en la RADB implica que el registrador es capaz de proporcionar accesibilidad en el destino, es decir, es posible acceder al destino a través de la infraestructura de red del registrador. Hasta no hace mucho, se ha advertido un especial interés por el estudio y el diseño de la topología de Internet, especialmente en el nivel de los sistemas autónomos (AS). En la actualidad, estas actividades se consideran más como medidas de análisis y diseño (en su mayoría a partir de bases de datos como la RADB) para deducir el gráfico de conectividad de los AS de Internet y describir sus propiedades, explicando los orígenes y las causas de algunas de las funciones observadas más sorprendentes y diseñando simuladores que generan estructuras de gráficos que coincidan con los gráficos de conectividad AS medidos. También pueden utilizarse para obtener un contexto realista para el aislamiento de fallos. En un documento reciente de Chang et al12, se observaba que estas bases de datos nos muestran que un número significativo de conexiones AS existentes permanecen ocultas en la mayoría de las tablas de enrutamiento BGP. El conocimiento sobre la conectividad de Internet puede proporcionarnos un marco de trabajo mejor para entender el comportamiento del BGP en la realidad. Por desgracia, mucha de la información proporcionada a la RADB puede ser filtrada de forma selectiva por las empresas. Por ejemplo, se sabe que un número creciente de ISP utilizan el IRR para filtrar los anuncios de rutas en los enrutadores fronterizos (la mayoría de ISP europeos utilizan de forma activa). El 12 H. Chang, R. Govindan, S. Jamin et al, “On Inferring AS level Connectivity from BGP Routing Tables” 2-28 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 conocimiento de este comportamiento puede influir en las rutas que se registran en la RADB. 2.4.3.2.9 Otros resultados de complejidad del BGP Se han estudiado muchas más propiedades el protocolo BGP, tanto de forma matemática como empíricamente. A continuación se incluyen algunos otros resultados de complejidad del BGP. Algunas de estas propiedades se presentan abajo tal y como se incluyen en el documento de Wilfong y Griffen. Para un sistema S BGP, el gráfico de evaluación, Eval(S), se define como el gráfico que se dirigirá, en cada estado s accesible hay un vértice etiquetado por s en Eval(S) y si s y s’ son estados accesibles y las transiciones a s y a s’ con la activación de algún conjunto de vértices no vacío A, entonces habrá un extremo dirigido desde s a s’ etiquetado por A en Eval(S). Un estado s en Eval(S) es final si para todos los vértices (v) del conjunto de vértices del sistema BGP existe un extremo entre s y s’ llamado v. ² Asimetría Dado un sistema S BGP, AS v en S, AS w en S, un destino d1 originado por w, un destino d2 originado por v, ¿existe un estado final s en Eval(S) en el que la ruta desde v a d1 no sea la inversa de la ruta desde w a d2? La asimetría es NP-completa. ² Solubilidad/Insolubilidad Dado un sistema S, ¿existe un estado final en Eval(S)? ¿O podemos afirmar que no existe un estado final en Eval(S)? La solubilidad y la insolubilidad son NP-completas. Observe que un sistema insoluble no puede converger hacia un estado estable, ya que no existe ninguno. De forma operativa, esto significa que en sistemas insolubles, es probable que BGP tienda hacia una “oscilación de protocolo” que no termine nunca. ² Solubilidad/Insolubilidad (SD) Dado un sistema S con un único destino d originado por algún AS w, ¿existe un estado final en Eval(S)? ¿O podemos afirmar que no existe un estado final en Eval(S)? Estos problemas son NP-hard. ² Trampas Dado un sistema S, ¿contiene Eval(S) una trampa? Formalmente, podemos definir una trampa como un subgráfico de Eval(S) que (1) no contiene un estado final y (2) no tiene arcos dirigidos hacia el subgráfico. Este problema es NP-hard. ² Solidez K Dado un sistema soluble S que sólo tiene un único destino d originado por algún AS w, ¿permanecerá S soluble ante un posible fallo de k vínculos? Este problema es NP-hard. ² Unicidad Dado un sistema S, ¿existe exactamente un estado final en Eval(S)? Este problema es NP-hard. 2-29 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 ² Multiplicidad Dado un sistema S, ¿existen varios estados finales posibles en Eval(S)? Este problema es NP-hard. Figure A.1. Modelo de referencia OSI APDU – Unidad de datos de protocolo de aplicación PPDU – Unidad de datos de protocolo de presentación SPDU – Unidad de datos de protocolo de sesión TPDU – Unidad de datos de protocolo de transferencia Apéndice A El modelo OSI está formado por: 1. Capa física: La capa física está relacionada con la transmisión de bits sin compresión en un canal de comunicación. Los problemas de diseño están relacionados con garantizar que cuando un extremo envía 1 bit, se recibe en el otro extremo como 1 bit, y no como un bit 0. Las preguntas comunes en este caso son la cantidad de voltios necesarios para representar un 1 y la cantidad para representar un 0, cuántos microsegundos tarda un bit, si la transmisión se realiza de forma simultánea en las dos direcciones, cómo se establece la conexión inicial y cómo se concluye cuando los dos extremos han terminado y cuántos pins tiene un conector de red y cuántos se utilizan. Los problemas de diseño tienen que ver, en gran parte, con interfaces mecánicas, eléctricas y de procedimientos y con el medio de transmisión física, que se encuentra debajo de la capa física. El diseño de la capa física puede considerarse dentro del dominio de la ingeniería eléctrica. Ejemplo: RDSI, CAT 1, ADSL, ATM, FDDI, cables coaxiales 2-31 2-30 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 2. Capa de enlace de datos: la tarea principal de la capa de enlace de datos es obtener un medio de transmisión sin compresión y transformarlo en una línea libre de errores de transmisión en la capa de red. Para conseguirlo, el emisor divide los datos en marcos de datos (normalmente de cientos de bytes), transmite los marcos secuencialmente y procesa los marcos de aviso de recepción devueltos por el receptor. Como la capa física sólo acepta y transmite una secuencia de bits sin tener en cuenta el significado de la estructura, dependerá de la capa de enlace de datos crear y reconocer los límites de los marcos. Esto puede realizarse adjuntando patrones de bits especiales al comienzo y al final de cada marco. Si hay una posibilidad de que estos patrones de bits se produzcan en los datos, es preciso prestar especial atención para evitar confusiones. Ejemplo: SLIP, PPP, 802.2 SNAP, Ethernet II 3. Capa de red: La capa de red está relacionada con el control del funcionamiento de la subred. Un problema clave de diseño es determinar cuántos paquetes se encaminan desde el origen hasta el destino. Las rutas deben estar basadas en tablas estáticas que están “enlazadas” con la red y que no suelen cambiar. También deben calcularse al principio de cada conexión, por ejemplo, en una sesión de terminal. Finalmente, pueden ser muy dinámicas y calcularse de nuevo para cada paquete, reflejando así el estado actual de la carga de red. Si hay muchos paquetes en la subred al mismo tiempo, interferirán entre sí y formarán cuellos de botella. El control de estas congestiones también es responsabilidad de la capa de red. Ejemplo: IPv4, IPv6. 4. Capa de transporte: la función básica de la capa de transporte es aceptar datos en una capa de sesión, dividirlos en unidades más pequeñas si es necesario, enviarlos a la capa de red y garantizar que todas las partes llegan correctamente al otro extremo. Además, todo esto debe realizarse de forma eficiente aislando la capa de sesión de los posibles cambios que puedan producirse en la tecnología del hardware. En condiciones normales, la capa de transporte crea una conexión distinta de red para cada conexión de transporte necesaria para la capa de sesión. Ahora bien, si la conexión de transporte requiere un alto rendimiento, la capa de transporte puede crear varias conexiones de red, dividir los datos entre las conexiones de red y mejorar así el rendimiento. Por otro lado, si crear y mantener una conexión de red resulta caro, la capa de transporte puede multiplexar varias conexiones de transporte en la misma conexión de red para reducir costes. En todos los casos, la capa de transporte es necesaria para que el multiplexado sea transparente para la capa de sesión. La capa de transporte también determine el tipo de servicio ofrecido a la capa de sesión y, en última instancia, los usuarios de la red. El tipo más usual de conexión de transporte es un canal punto a punto sin errores que envía mensajes en el orden en que fueron enviados. No obstante, también son posibles otros tipos de transporte, de servicio y de mensajes aislados de transporte sin garantía alguna sobre el orden de envío, así como difusión de mensajes a varios destinos. El tipo de servicio viene determinado cuando se establece la conexión. La capa de transporte es una capa real punto a punto y origen a destino. Dicho de otra manera, un programa de la máquina origen mantiene una conversación con un programa similar en la máquina de destino utilizando cabeceras de mensajes y mensajes de control. 2-32 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 Ejemplo: TCP,UDP 5. Capa de sesión: la capa de sesión permite que usuarios de distintas máquinas puedan establecer sesiones entre sí. Una sesión permite el transporte común de datos, tal y como ocurre con la capa de transporte, pero también proporciona servicios mejorados que resultan de gran utilidad en ciertas aplicaciones. Una sesión puede utilizarse para permitir que el usuario inicie sesión en un sistema remoto de compartición de tiempo o que transfiera un archivo entre dos máquinas. Uno de los servicios de la capa de sesión es la administración del control de diálogo. Las sesiones permiten que el tráfico fluya en ambas direcciones al mismo tiempo o sólo en una cada vez. Si el tráfico sólo puede ir en una dirección, la capa de sesión ayuda a saber de quién es el turno. Un servicio relacionado con la sesión es la gestión de testigos. En algunos protocolos, resulta esencial que los dos extremos no intenten realizar la misma operación al mismo tiempo. Para gestionar estas actividades, la capa de sesión ofrece testigos que pueden intercambiarse. Únicamente el extremo que tenga el testigo podrá realizar la operación crítica. Otro servicio de sesión es la sincronización. Piense en los problemas que pueden surgir al intentar establecer una transferencia de archivos de dos horas entre dos máquinas de una red con un tiempo medio de una hora antes de que falle. Tras la cancelación de cada transferencia, la transferencia al completo debe iniciarse otra vez y probablemente fallará de nuevo cuando la red caiga. Para eliminar este problema, la capa de sesión ofrece un método de inserción de puntos de comprobación en el flujo de datos para que, al caer la red, sólo deban repetirse los datos situados después de este punto de comprobación. Ejemplo: RPC Portmapper 6. Capa de presentación: la capa de presentación lleva a cabo funciones que suelen solicitarse con frecuencia para encontrar una solución y no dejar que el usuario tenga que resolver el problema. En concreto, y al contrario de lo que ocurre con el resto de capas inferiores que sólo muestran interés por mover bits de forma fiable entre varios puntos, la capa de presentación se encarga de la sintaxis y de la semántica de la información transmitida. Un ejemplo característico del servicio de presentación es la codificación de datos de forma acordada y normalizada. La mayoría de programas de usuarios no intercambian cadenas de bits binarios de forma aleatoria. Intercambian cosas como nombres de personas, fechas, cantidades de dinero y facturas. Estos elementos se representan con cadenas de caracteres, enteros, números de coma flotante y estructuras de datos formadas por elementos más simples. Los distintos equipos contienen distintos códigos para representar las cadenas de caracteres, los enteros, etc. Con el fin de hacer posible que los equipos puedan comunicarse entre sí con distintas representaciones, las estructuras de datos que se intercambian pueden definirse de forma abstracta y con una codificación estándar que se utilizará en la red. La tarea de gestionar estas estructuras de datos abstractos y convertirlos en la representación utilizada por los equipos en las redes estándar la lleva a cabo la capa de presentación. Esta capa también se encarga de otros aspectos de la representación de información. Por ejemplo, la compresión de datos puede utilizarse aquí para reducir el número de bits 2-33 MIT 18.996 Clase 2 – 13 de febrero, 2002 Primavera de 2002 que se deben transmitir y la criptografía suele requerirse para la privacidad y la autenticación. Ejemplo: HTTP, FTP, Telnet, DNS, SNMP, NFS 7. Capa de aplicación: la capa de aplicación contiene una variedad de protocolos que suelen ser necesarios. Por ejemplo, existen cientos de tipos de terminales no compatibles en el mundo. Piense en la complicación de un editor de pantalla completa que supuestamente debe funcionar en muchos tipos de terminales distintos, cada uno de ellos con apariencias de pantalla diferentes, secuencias de escape para la inserción y borrado de texto, movimiento del cursor, etc. Una forma de solucionar este problema es definir un terminal virtual de red abstracto para el que los editores y otros programas puedan escribir. Para administrar cada tipo de terminal, debe escribirse una porción de software que asigne las funciones del terminal virtual de red al terminal real. Por ejemplo, cuando el editor mueve el cursor del terminal virtual hacia la esquina superior izquierda de la pantalla, este software debe enviar la secuencia de comandos adecuada para que el terminal real también realice dicho movimiento. Todo el software del terminal virtual se encuentra en la capa de aplicación. Otra función de la capa de aplicación es la transferencia de archivos. Los distintos sistemas de archivos tienen diferentes convenciones de nomenclatura de archivos, formas distintas de representar líneas de texto, etc. Transferir un archivo entre dos sistemas distintos requiere el tratamiento de éstas y otras incompatibilidades. Esta tarea también es responsabilidad de la capa de aplicación, al igual que el correo electrónico, las entradas de tareas remotas, la búsqueda en directorios y otras utilidades generales y concretas. Ejemplos: correo electrónico, grupos de noticias, servicios de directorio, servicios de archivos 2-34 MIT 18.996 Primavera de 2002 Referencias [1] ”Computer Networks”, Andrew S. Tanenbaum [2] ”Internet Routing Architectures”, Bassam Halabi [3] ”Computer Networks: A Systems Approach”, Bruce S. Davie, et al [4] ”OSI Reference Model”, http://www.rad.com/networks/1994/osi/intro.htm Clase 2 – 13 de febrero, 2002 2-35