Teleprocesos y Redes 2 Esquema de Comunicaciones DIRECCIONES INTERNET Tipos primarios de direcciones IP: Para las direcciones los diseñadores de TCP/IP eligen un sistema en el que cada host en la red tiene asignada una dirección, que es un número entero de 32 bits, llamada dirección IP. Dicha dirección se utilizará en todas las comunicaciones con dicho host. Conceptualmente cada dirección es del par {RedID, HostID}, donde RedID identifica una red y HostID un host dentro de la red. En la práctica, cada dirección IP debe tener una de las primeras tres formas mostradas a continuación: Debido a que las direcciones IP codifican tanto una red y un host en dicha red, no especifican una computadora individual, sino una conexión a la red. Por lo tanto, un router que conecta cierto número de redes tiene cierto número de direcciones IP distintas, una para cada conexión de red Direcciones de red y de difusión {00…0.00…0} {RedID.00…0} {RedID.11…1} (0.0.0.0) Se refiere al host local. Suele utilizarse en casos en los que el Host se quiere comunicar a la red, pero aún no sabe su dirección IP. Normalmente las respuestas ya tendrán la dirección de red especificada, permitiendo que el host tome nota de ella. Hace referencia a la red en sí misma y se denomina dirección de red. Difusión Dirigida: Se utiliza como dirección de difusión y se refiere a todos los host de esta red. Se denomina dirección de broadcast. Esto permite que un sistema remoto envíe un solo paquete que será difundido en la red especificada. Posee como desventaja que se debe conocer el RedID. 1/70 Teleprocesos y Redes 2 {11…1.11…1} {127.00…0} Clase A B C D E Difusión limitada. Proporciona una dirección de difusión para la red local. Suele utilizarse en procedimientos de arranque antes de que el Host conozca su dirección IP o la dirección de la red. Loopback o Dirección de Bucle Local: Esta dirección es reservada. Se utiliza para pruebas y para la comunicación de los procesos internos en la máquina local. Cuando algún programa utiliza esta dirección como destino, el protocolo regresa los datos sin generar tráfico en la red. Rango 1.0.0.0 – 126.0.0.0 128.0.0.0 – 191.255.0.0 192.0.0.0 – 223.155.155.0 224.0.0.0 – 239.255.255.255 240.0.0.0 – 255.255.255.255 N° de Redes 126 16.384 2.097.152 N° de Host 16.777.214 65.534 254 Mascara de Red 255.0.0.0 255.255.0.0 255.255.255.0 Broadcast x.255.255.255 x.x.255.255 x.x.x.255 ARP (PROTOVOLO DE ASOCIACIÓN DE DIRECCIONES) ARP permite que un host encuentre la dirección física de otro host dentro de la misma red física con sólo proporcionar la dirección IP del objetivo. La idea es que cuando el host A quiere determinar la dirección física asociada a una dirección IP, transmite por difusión un paquete especial que pide al host que posee esa dirección IP, que responda con su dirección física. Memoria Intermedia para asociación de direcciones: Podría parecer extraño que A transmita por difusión para averiguar la dirección física de B en lugar sólo transmitir por difusión el paquete que quiere enviar. La razón más importante de esto es que la difusión es demasiado cara para utilizarse cada vez que una máquina necesita transferir un paquete a otra, debido a que requiere que cada máquina en la red procese dicho paquete. Para reducir los costos de comunicación, las computadoras que utilizan ARP, mantienen una memoria intermedia de las asociaciones de dirección IP con dirección física recientemente adquiridas, para que no tengan que utilizar ARP varias veces. Siempre que una computadora recibe una respuesta ARP, esta guarda la dirección IP del transmisor, así como la dirección física correspondiente, en su memoria intermedia para utilizarla en búsquedas posteriores. Refinamiento ARP: Una mejora de ARP es que el transmisor incluya, en cada difusión ARP, su IP y dirección física; los receptores actualizan su información en memoria intermedia antes de procesar el paquete ARP. Podría darse el caso en el que la máquina A ya posea una asignación de la maquina B, pero el hardware de B es reemplazado por algún motivo, haciendo que la dirección de B cambie, pero la asignación en la memoria temporal de A no, produciendo que A no pueda entregar paquetes a B. Esto se soluciona haciendo que ARP maneje de forma temporal la tabla de asignaciones, con lo cual remueve los registros después de un período de tiempo. La marca de tiempo de un registro se reinicia cada vez que se recibe una difusión ARP que lo contenga. Proxy ARP: Permite a un router responder peticiones ARP procedentes de una de las redes a la que está conectado, realizadas a un host que está conectado a otra red. Esto produce que el host emisor de la petición ARP crea que la dirección física del router es la del host destino. El router se dice que está actuando como un proxy-agent para el host destino, contestando los paquetes dirigidos a él desde otros hosts. El Proxy ARP también se denomina promiscuous ARP o ARP hack, debido al otro uso que se le da: conectar dos redes físicas mediante un router proxy-agent, haciendo “invisible” una a la otra. Esto permite que ambas redes puedan usar el mismo valor de subred. 2/70 Teleprocesos y Redes 2 Formato de Mensaje ARP TIPO DE HARDWARE TIPO DE PROTOCOLO HLEN PLEN OPERACION SENDER HA SENDER IP TARGET HA TARGET IP TIPO DE HARDWARE: El tipo de interfaz de hardware para el que el transmisor busca respuesta. TIPO DE PROTOCOLO: Tipo de protocolo de alto nivel (Por ejemplo IP). HLEN y PLEN: Permiten que ARP se utilice con redes arbitrarias ya que estas especifican la longitud de direcciones físicas y la longitud de las direcciones de protocolo de alto nivel. OPERACIÓN: (1) Solicitud ARP, (2) Respuesta ARP, (3) Solicitud RARP, (4) Respuesta RARP. SENDER HA: Dirección física del transmisor. SENDER IP: Dirección IP del transmisor. TARGET HA: Dirección física del objetivo. TARGET IP: Dirección IP del objetivo. Cuando el transmisor realiza una solicitud, proporciona la dirección IP del objetivo (ARP) o la dirección física (RARP). Antes que la máquina objetivo responda, completa las direcciones faltantes e intercambia objetivo y transmisor, y cambia la operación de respuesta. RARP (ARP Inverso) Una máquina utiliza este protocolo a fin de obtener su dirección IP desde un servidor. RARP es una adaptación de ARP y utiliza el mismo formato de mensaje. Al igual que ARP, un mensaje RARP se envía de una máquina a otra, encapsulado en la porción de datos de una trama de red. El que envía trasmite por difusión una solicitud RARP especificando su dirección física en el campo TARGET HA. Todas las máquinas en la red reciben la solicitud, pero sólo las autorizadas para proporcionar el servicio RARP (servidores RARP) la procesarán y enviarán respuesta. Servidores RARP Primarios y Secundarios: Bajo circunstancias normales, sólo el servidor primario responde a una solicitud RARP. Todos los servidores secundarios reciben la solicitud, pero únicamente registran su tiempo de llegada. Si el servidor primario no está disponible, la máquina original cronometra el tiempo de respuesta y, si esta no aparece, transmitirá de nuevo la solicitud por difusión. Cuando un servidor no primario recibe una segunda copia de una solicitud RARP, poco tiempo después de la primera, éste responde. Para intentar evitar que todos los servidores secundarios respondan a la vez. Cada servidor secundario que recibe una solicitud computa un retraso aleatorio y, luego, envía la respuesta. 3/70 Teleprocesos y Redes 2 PROTOCOLO IP IP realiza la función de ruteo seleccionando la ruta por la que los datos serán enviados. Se define al servicio como un sistema de entrega de paquetes no orientado a la conexión y con el mejor esfuerzo. El servicio se conoce como no confiable porque la entrega no esta garantizada. Los paquetes se pueden perder, duplicar, retrasar o entregar sin orden, pero el servicio no detectara ni informara al respecto. Se conoce como no orientado a la conexión dado que cada paquete es tratado de manera independiente. Se dice que trabaja con el mejor esfuerzo dado que se hace un serio intento por entregar los paquetes (no se descartan porque sí). La no confiabilidad aparece sólo cuando los recursos están agotados o la red subyacente falla. Formato del Datagrama IP: Cabecera, que contiene la información de control del protocolo. A su vez se divide en dos partes, una fija de 20 octetos (160 bits) existente en todos los datagramas IP y una variable múltiplo de 32 bits que en los casos más habituales no aparece Datos, contiene la información transportada por el protocolo IP, habitualmente contendrá información del nivel de transporte. El significado de los campos que aparecen en la cabecera del datagrama son: VERS: Indica la versión del protocolo LONG: Indica la longitud de la cabecera, medida en palabras de 32 bits. SERVICIO (TOS): Indica el tipo de servicio solicitado. Indica una serie de parámetros sobre la calidad de servicio deseada durante el tránsito por una red. Puede representar Prioridad, Retraso, Performance o Confiabilidad. LONGITUD TOTAL: Señala la longitud total de todo el datagrama (cabecera y datos) en bytes. IDENTIFICADOR: Es un identificador único del datagrama, y se utiliza en caso de segmentación para distinguir los fragmentos de un datagrama. FLAGS: Se utilizan para labores de fragmentación. Uno de sus bits indica si el datagrama es Divisible o no, mientras que otro bit indica si es un último fragmento o un fragmento intermedio. La indicación de que un paquete es indivisible debe ser tenida en cuenta bajo cualquier circunstancia. Si el paquete necesitara ser fragmentado, no se enviará. OFFSET: Se utiliza para identificar la posición de un fragmento cuando existe segmentación. TTL (Time To Live): Indica la validez de un datagrama. El origen indica un valor inicial. Cada vez que atraviesa un router, este decrementa el valor. Al llegar a 0 la red elimina el datagrama y se envía un mensaje de error a la fuente. 4/70 Teleprocesos y Redes 2 PROTOCOLO: Especifica que protocolo de alto nivel se utilizó para crear el mensaje que se esta transportando en el área DATA del datagrama (ej: TCP, UDP, ICMP; etc). CHECKSUM: Se trata de un código de redundancia de la cabecera utilizado para determinar si se han producido errores de transmisión o no. El método de cálculo consiste en sumar el complemento a 1 de cada palabra de 16 bits de la cabecera y hacer el complemento a 1 del valor resultante. DIR. IP ORIGEN: Es la dirección origen del datagrama, identifica al origen de la comunicación. DIR. IP DESTINO: Es la dirección destino del datagrama, identifica al destino de la comunicación. OPCIONES: Para utilizar opciones adicionales del protocolo IP. Es de tamaño variable. Las opciones actualmente definidas: - Final de Lista de Opciones: Se usa al final de la lista de opciones, si ésta no coincide con el final de la cabecera IP. - Ninguna Operación (NOP): Se puede usar para forzar la alineación de las opciones en palabras de 32 bits. - Seguridad: Especifica niveles de seguridad que van desde "No Clasificado" hasta "Máximo Secreto". - Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR): Esta opción provee el mecanismo para que el originador de un datagrama pueda indicar el itinerario que ha de seguir a través de la red y para registrar el camino seguido. Los Datos de Opción consisten en un puntero y una lista de direcciones IP que se han de alcanzar ("procesar"): El puntero indica la posición de la siguiente dirección de la ruta, dentro de la Opción; así, su valor mínimo es de 4. Cuando un nodo de Internet procesa la dirección de la lista apuntada por el puntero (es decir, se alcanza esa dirección) incrementa el puntero en 4, y redirige el paquete a la siguiente dirección. Si el puntero llega a ser mayor que el Tamaño de Opción significa que la información de ruta se ha procesado y registrado completamente y se redirigirá el paquete a su dirección de destino. Si se alcanza la dirección de destino antes de haber procesado la lista de direcciones completa (el puntero es menor que el Tamaño de Opción) la siguiente dirección de la lista reemplaza a la dirección de destino del paquete y es a su vez reemplazada por la dirección del nodo que está procesando el datagrama ("Ruta Registrada"), incrementando, además, el puntero en 4. Utilizando este método de sustituir la dirección especificada en origen por la Ruta Registrada se asegura que el tamaño de la Opción (y de la cabecera IP) no varía durante su recorrido por la red. - Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR): Exactamente igual que LSSR, excepto en el tratamiento que los nodos harán de este datagrama. Al ser la ruta especificada "estricta", un nodo debe reenviar el paquete directamente a la siguiente dirección, es decir, no podrá redireccionarlo por otra red. - Registro de Ruta: Mediante el uso de esta Opción se puede registrar el itinerario de un datagrama. Los Datos de Opción consisten en un puntero (un octeto) y un espacio relleno de ceros que contendrá la Ruta Registrada para el paquete. Cuando un nodo recibe un paquete en el que está presente esta opción, escribirá su dirección IP en la posición indicada por el puntero, siempre que ésta sea menor que el Tamaño de Opción, e incrementará el puntero en 4. RELLENO (Padding): Utilizado para alinear el campo de opciones a 32 bits. Tamaño de Datagrama, MTU y fragmentación MTU: (Maximum Trasfer Unit) Unidad de transferencia máxima. 5/70 Teleprocesos y Redes 2 TCP/IP selecciona el tamaño de datagrama más conveniente desde el principio y establece una forma de dividir datagramas en fragmentos más pequeños cuando necesita viajar a través de una red que tiene un MTU menor. Las piezas del datagrama dividido se conocen como fragmentos y al proceso de división se conoce como fragmentación. Una vez que un datagrama es fragmentado, los fragmentos viajan como datagramas separados hacia su destino final donde serán reensamblados. Esto produce que el datagrama, en su trayecto hacia su destino, una vez que sale de la red de MTU menor desaproveche el uso de otras redes con MTU mayor. Otro inconveniente es que si un fragmento se pierde, el datagrama no podrá reensamblarse. Reensamblado de Fragmentos: El host de destino iniciará un temporizador cuando recibe un fragmento inicial. Si el temporizador termina antes que lleguen todos los fragmentos, el host los descartará sin procesar el datagrama. Así la probabilidad de perder un datagrama se incrementa con la fragmentación. Control de fragmentación Los campos de INDENTIFICADOR, FLAGS y OFFSET, en el encabezado del datagrama, controlan la fragmentación y el reensamblado de los datagramas. Recordemos que el campo IDENTIFICADOR contiene un entero único que identifica al datagrama. Para un segmento, el campo OFFSET especifica el desplazamiento en el datagrama original de los datos que se están acarreando en el fragmento, medido en unidades de 8 bytes, comenzando con un desplazamiento igual a cero. Si el FLAG de no fragmentar esta puesto a 1 especifica que el datagrama no debe fragmentarse. Cada vez que un router necesita fragmentar un datagrama que tiene activado este FLAG, el router descarta el datagrama y devolverá un mensaje de error a la fuente. El FLAG de more fragments especifica si el fragmento contiene datos intermedios del datagrama original o se trata de la parte final del mismo. ENCABEZADO DEL DATAGRAMA Datos1 600 bytes ENCABEZADO DEL FRAGMENTO 1 Datos1 IDENTIFICACION1 = IDENTIFICACIONORIG OFFSET1 = OFFSETORIG MORE1 = 1 ENCABEZADO DEL FRAGMENTO 2 Datos2 IDENTIFICACION2 = IDENTIFICACIONORIG OFFSET2 = OFFSETORIG + (600 / 8) MORE2 = 1 ENCABEZADO DEL FRAGMENTO 3 Datos3 Datos2 600 bytes Datos3 200 bytes IDENTIFICACION3 = IDENTIFICACIONORIG OFFSET3 = OFFSET2 + (600 / 8) MORE3 = MOREORIG RUTEO DE DATAGRAMAS IP En un sistema de conmutación de paquetes, el ruteo es el proceso de selección de un camino sobre el que se mandarán paquetes, y el ruoter es la computadora que hace la selección. Entrega Directa: Es la transmisión de un datagrama desde una máquina hasta otra a través de una sola red física. Para hacer esto, el transmisor encapsula el datagrama en una trama física, transforma la dirección IP en una dirección física y utiliza la red para entregar el datagrama. Entrega Indirecta: Ocurre cuando el destino no esta en una red conectada directamente, lo que obliga al transmisor a pasar el datagrama a un router para su entrega. Una vez que la trama llega a un router, se extrae el datagrama encapsulado, e IP selecciona el siguiente router a lo largo del camino hacia el destino. Se vuelve a colocar el datagrama en una trama y se envía a través de la siguiente red física hacia el segundo router, y así sucesivamente, hasta que se puede entregar en forma directa. 6/70 Teleprocesos y Redes 2 Ruteo Controlado por Tablas: El algoritmo de ruteo IP emplea una tabla de ruteo en cada máquina que almacena información sobre posibles destinos y sobre cómo alcanzarlos. Debido a que tanto los ruters como los hosts rutean datagramas, ambos tienen tablas de ruteo IP. Siempre que el software de ruteo IP en un host necesita transmitir un datagrama, consulta la tabla de ruteo para decidir a donde enviarlo. Las tablas de ruteo sólo necesitan conocer prefijos de red y no direcciones IP completas, dado que contener información de cada posible dirección de destino sería imposible de manejar y de mantener actualizada. Ruteo con Salto al Siguiente: Utilizar la porción de red de una dirección de destino en vez de toda la dirección, hace que el ruteo sea eficiente y mantiene reducidas las tablas de ruteo. Por lo general, una tabla de ruteo contiene pares {N, R}, donde N es la dirección IP de una red de destino y R la dirección IP del “siguiente” router en el camino hacia la red N. Por lo tanto, la tabla de ruteo en el router R sólo especifica un paso a lo largo del camino de R a su red de destino, el router no conoce el camino completo hacia el destino. Es importante entender que cada registro en una tabla de ruteo apunta hacia un router que se puede alcanzar a través de una sola red. Todos los routers listados en la tabla de ruteo de la maquina M deben residir en las redes con las que M se conecta de manera directa. El ejemplo (a) muestra un ejemplo de internet con 4 redes y 3 routers, y (b) muestra la tabla de ruteo en R. Rutas por Omisión: Una técnica usada para ocultar información y mantener reducido el tamaño de las tablas de ruteo, es asociar muchos registros a un router por omisión. La idea es hacer que IP busque primero en la tabla de ruteo para encontrar la red de destino. Si no aparece una ruta en la tabla, las rutinas de ruteo envían el datagrama a un router por omisión. Rutas por host Específico: IP permite que se especifiquen rutas por host como caso especial. Algoritmo de Ruteo IP RutaDatagrama (Datagrama, Taba de Ruteo) Extraer la IP de destino, D, del datagrama y computar el prefijo de red, N; Si N corresponde a cualquier dirección de red directamente conectada Entregar el datagrama al destino D sobre dicha red (Esto comprende la transformación de D en una dirección física, encapsulando el datagrama y enviando el datagrama.) De otra forma, 7/70 Teleprocesos y Redes 2 si la tabla contiene una ruta con host específico para D, enviar el datagrama al salto siguiente especificado en la tabla. de otra forma, si la tabla contiene una ruta para la red N, enviar el datagrama al salto siguiente especificando en la tabla; de otra forma, si la tabla contiene una ruta asignada por omisión, enviar el datagrama al ruoter asignado por omisión especificado en la tabla; de otra forma, declarar un error de ruteo; Ruteo IP: Es importante entender que, a excepción de la disminución del TTL y de volver a calcular el CHECKSUM, el ruteo IP no altera el datagrama original. En particular, las direcciones de origen y destino del datagrama permanecen sin alteración. Cuando IP ejecuta el algoritmo de ruteo, selecciona una nueva dirección IP, que es la dirección IP de la máquina a la que a continuación se tendrá que enviar el datagrama. La nueva dirección es parecida a la dirección de un router. Sin embargo, si el datagrama se puede entregar directamente, la nueva dirección será la misma que la del último destino. Dijimos que la dirección IP seleccionada por el algoritmo de ruteo IP se conoce como la dirección de salto al siguiente, pues indica a donde enviará el datagrama (aunque no necesariamente sea el destino del datagrama). ¿Dónde almacena IP la dirección de salto al siguiente? No en el datagrama. De hecho, IP no almacena la dirección de salto al siguiente. Después de ejecutar el algoritmo de ruteo, IP utiliza ARP para transformar la dirección de salto al siguiente en una dirección física y luego pasa el datagrama y la dirección física de salto al siguiente al software de la interfaz de red, responsable de la red física sobre la que el datagrama se debe enviar. El software de interfaz de red, pone el datagrama en la porción de datos de la trama y lo envía. Manejo de los datagramas entrantes: Cuando un datagrama IP llega a un host, el software de interfaz de red lo entrega a IP para su procesamiento, si la dirección de destino del datagrama corresponde a la dirección IP del host, IP acepta el datagrama y lo pasa al software de protocolo de nivel superior. ICMP – Protocolo de Mensajes de Control Internet Para permitir que los routers en una red soporten errores, se agregó a los protocolos TCP/IP un mecanismo de mensajes de propósito especial. El mecanismo es conocido como Protocolo de Mensajes de Control Internet (ICMP). Al igual que el resto del tráfico, los mensajes ICMP viajan a través de la red en la porción de datos de los datagramas IP. Sin embargo, el destino final de un mensaje ICMP no es un programa de aplicación, sino el software de IP de dicha máquina. Cuando un datagrama causa un error, el ICMP sólo puede reportar la condición de error a la fuente original del datagrama; la fuente debe relacionar el error con un programa de aplicación individual o debe tomar alguna acción para corregir el problema. Entrega de mensajes ICMP: Hay una excepción en los procedimientos de manejo de errores si un datagrama que lleva un mensaje de ICMP causa un error. Esta excepción fue diseñada para evitar el problema de tener mensajes de error sobre mensajes de error. Formato de los Mensajes ICMP Aunque cada mensaje ICMP tiene su propio formato, todos comienzan con los mismos tres campos: TIPO CODIGO CHECKSUM 8/70 Teleprocesos y Redes 2 CODIGO: Proporciona información adicional sobre el tipo de mensaje. TIPO: Define el significado del mensaje así como su formato. Los tipos incluyen. - 0- Respuesta de Eco. - 3- Destino inaccesible. - 4- Disminución de origen. - 5- Redireccionar (cambiar una ruta) - 8- Solicitud de Eco. - 11- Tiempo excedido para un datagrama. - 12- Problema de parámetros para un datagrama - 13- Solicitud de TimeStamp. - 14- Respuesta de TimeStamp. - 15- Solicitud de Información (obsoleto). - 16- Respuesta de Información (obsoleto). - 17- Solicitud de mascara de dirección. - 18- Respuesta de mascara de dirección. 1) Prueba de accesibilidad y estado de un destino (Ping) Una de las herramientas más utilizadas incluye los mensajes ICMP de echo request (solicitud de eco) y echo reply (respuesta de eco). En muchos sistemas se conoce como el comando ping. El formato de los mensajes de solicitud de eco y de respuesta: TIPO CODIGO CHECKSUM IDENTIFICADOR NRO. SECUENCIA DATOS OPCIONALES ... DATOS OPCIONALES: Campo de longitud variable que contiene los datos que se regresarán al transmisor. IDENTIFICADOR: y NUMERO DE SECUENCIA: Los utiliza el transmisor para responder a las solicitudes. 2) Reporte de destinos no accedidos Cuando un router no puede direccionar o entregar un datagrama IP, envía un mensaje de destino no accesible a la fuente original, utilizando el formato: TIPO CODIGO CHECKSUM NO UTILIZADO (DEBE SER CERO) ENCABEZADO DEL DATAGRAMA + PRIMEROS 64 BITS DEL DATAGRAMA ... CODIGO: Contiene un número entero que describe con más detalle el problema. Los valores posibles son: - 0- Red inaccesible. - 1- Host inaccesible - 2- Protocolo inaccesible. - 3- puerto inaccesible. 9/70 Teleprocesos y Redes 2 - 4- Se necesita fragmentación y configuración DF. 5- Falla en ruta origen. 6- Red de destino desconocida. 7- Anfitrión de destino desconocido. 8- Anfitrión de origen aislado. 9- Comunicación con la red de destino administrativamente prohibida. 10- Comunicación con el host de destino administrativamente prohibida. 11- Red inaccesible por el tipo de servicio. 12- Host inaccesible por el tipo de servicio. Los errores de red no accesible por lo general implican fallas en el ruteo. Debido a que los mensajes de error ICMP contienen un prefijo del datagrama que causo el problema, la fuente sabrá exactamente qué dirección no es accesible. 3) Control de Congestionamiento y de flujo de datagramas Los routers se pueden saturar con el tráfico, condición conocida como congestionamiento. Es importante entender que el congestionamiento puede surgir por dos razones. Primero, una computadora de alta velocidad puede ser capaz de generar tráfico de forma más rápida de lo que una red lo puede transferir. Segundo, si muchas computadoras necesitan enviar datagramas al mismo tiempo por el router. Una máquina utiliza mensajes ICMP de este tipo para reportar el congestionamiento a la fuente original. Un mensaje de disminución de tasa a la fuente es una solicitud para que la fuente reduzca la velocidad de transmisión de datagramas. Por lo general, los routers congestionados envían un mensaje de disminución de tasa al origen por cada datagrama que descartan. Otros, intentan evitar los congestionamientos al enviar solicitudes de disminución cuando sus colas de espera crecen, pero antes de que se saturen. TIPO CODIGO CHECKSUM NO UTILIZADO (DEBE SER CERO) ENCABEZADO DEL DATAGRAMA + PRIMEROS 64 BITS DEL DATAGRAMA ... 4) Solicitudes de Cambio de Ruta Cuando un router detecta un host que utiliza una ruta no optima, le envía al host un mensaje ICMP, llamado de redireccionar solicitándole que cambie sus rutas. El router también redirecciona el datagrama original a destino. TIPO CODIGO CHECKSUM DIRECCION DEL ROUTER ENCABEZADO DEL DATAGRAMA + PRIMEROS 64 BITS DEL DATAGRAMA ... DIRECCION DEL ROUTER: Contiene la dirección de un router que el host utilizará para alcanzar el destino mencionado en la cabecera del datagrama. 10/70 Teleprocesos y Redes 2 5) Detección de rutas circulares o muy largas Un router disminuye siempre el contador de tiempo de vida que posee el datagrama y lo descarta cuando el conteo llega a cero. Siempre que un router descarta un datagrama ya sea porque su conteo de saltos llega a cero o porque ocurre una terminación de tiempo mientras espera fragmentos de un datagrama; envía un mensaje ICMP de tiempo excedido a la fuente del datagrama, utilizando el formato siguiente: TIPO CODIGO CHECKSUM NO UTILIZADO (DEBE SER CERO) ENCABEZADO DEL DATAGRAMA + PRIMEROS 64 BITS DEL DATAGRAMA ... En estos casos el valor de CODIGO puede ser alguno de los siguientes: - 0- Conteo de tiempo de vida excedido. - 1- Tiempo para reensamblado de fragmentos excedido. 6) Sincronización de relojes y estimación de tiempos del transito Una máquina solicitante envía un mensaje ICMP de solicitud de TimeStamp a otra, solicitándole que informe su valor actual del reloj. TIPO CODIGO IDENTIFICADOR CHECKSUM NRO. SECUENCIA ORIGINAR TIMESTAMP RECIBIR TIMESTAMP TRANSMITIR TIMESTAMP IDENTIFICADOR y NUMERO DE SECUENCIA: Los utiliza la fuente para asociar las solicitudes con las respuestas. ORIGINAR TIMESTAMP: Es llenado por la fuente original justo antes de transmitir el paquete. RECIBIR TIMESTAMP: Se llena inmediatamente al recibir la solicitud. TRANSMITIR TIMESTAMP: Se llena justo antes de transmitir la respuesta. 7) Obtención de Mascara de Red Para conocer la máscara de sub red utilizada por la red local, una máquina puede enviar un mensaje de solicitud de mascara de subred a un router. El mensaje puede ser enviado a un router determinado, si se conoce su dirección, o por difusión. TIPO CODIGO IDENTIFICADOR CHECKSUM NRO. SECUENCIA MASCARA DE RED IDENTIFICADOR y NUMERO DE SECUENCIA: Los utiliza la fuente para asociar las solicitudes con las respuestas. MASCARA DE RED: Una respuesta contiene la máscara de red. 11/70 Teleprocesos y Redes 2 DIRECCIONAMIENTO DE SUBRED Y SUPERRED El esquema de direccionamiento IP presenta una debilidad, y es debido al crecimiento no previsto por los diseñadores. Al pensar en cómo se podría minimizar el número de direcciones de red asignadas sin destruir el esquema original de direccionamiento, se pensó en que muchas redes físicas deben compartir el mismo prefijo de red. Una forma de hacer esto es mediante direccionamiento de subredes. Direccionamiento de SubRed Una manera de entender esto es imaginarse que una localidad tiene asignada una sola dirección IP, pero tiene dos o más redes físicas. Sólo los routers locales saben que existen muchas redes físicas y como rutear el tráfico entre ellas; los routers en otros sistemas rutean todo el tráfico como si sólo hubiera una única red. Para lograr esto, cambia ligeramente la interpretación de direccionamiento IP. En vez de dividir la dirección IP en Red y Host, la dirección se divide en una porción de red, y una porción local. La interpretación de la porción de red permanece igual que en las redes que no utilizan direccionamiento de subredes. La interpretación de la porción local identifica una red física y un host en dicha localidad. Flexibilidad en la asignación de direcciones de subred: Para permitir una máxima flexibilidad al particionar las direcciones de subred, el estándar TCP/IP de subred permite que la interpretación se escoja de forma independiente para cada red física, una vez que se selecciona una partición de subred, todas las máquinas la deben utilizar. Implantaciones de Subredes con Máscaras La forma de implementar subredes es mediante mascaras. Una máscara es un número de 32 bits, y se guarda en cada equipo que la necesite. Se debe escoger una máscara de subred para cada red. Los bits en 1 en la máscara identifican la parte de la dirección de red y los bits en 0 como parte del identificador de host. RedID = IP AND MASK. HostID = IP AND not MASK 12/70 Teleprocesos y Redes 2 El algoritmo de ruteo de subred. Al igual que el algoritmo estándar de ruteo IP, el algoritmo de ruteo en subredes basa sus decisiones en una tabla de ruteo. Recuerde que en el algoritmo estándar, las rutas por anfitrión y las rutas asignadas por omisión son casos especiales que se deben verificar de manera explícita; para los demás casos se lleva a cabo la búsqueda en tablas. Una tabla convencional de ruteo contiene registros de la siguiente forma: (dirección de red, dirección de salto siguiente) Donde el campo de red especifica la dirección IP de la red de destino, N, y el campo salto siguiente especifica la dirección de un router al que se deben enviar los datagramas destinados a N. El algoritmo estándar de ruteo compara la porción de red de una dirección destino con el campo de dirección de red de cada registro en la tabla de ruteo, hasta que encuentra una correspondencia. Debido a que el campo de dirección de salto siguiente está reservado sólo para especificar una máquina que se puede accesar a través de una red conectada de manera directa, solamente es necesaria una búsqueda en tabla. El algoritmo estándar sabe que una dirección esta divida en una porción de red y una porción local, ya que los primeros tres bits codifican el tipo y formato de la dirección. Con las subredes, no es posible decidir que bits corresponden a la red ni cuales corresponden al anfitrión sólo con la dirección. En cambio el algoritmo modificado que se utiliza con las subredes guarda información adicional en la tabla de ruteo. Cada registro dentro de la tabla contiene un campo adicional que especifica la máscara de subred utilizada con la red: (mascara de subred, dirección de red, dirección de salto siguiente) Mantenimiento de las máscaras de subred Las máscaras de Subred se propagan por de una solicitud de máscara de subred ICMP al router de la red. La solicitud se puede transmitir por difusión si el host no conoce la dirección específica de un router. Con respecto a la asignación de máscaras de subred, cada localidad tiene la libertad de escoger una cualquiera para sus redes. Cuando hacen asignaciones, los administradores intentan balancear los tamaños de las redes, los números de redes físicas, el crecimiento esperado y el mantenimiento. La dificultad surge porque las máscaras no uniformes proporcionan una flexibilidad máxima, pero posibilitan hacer asignaciones que llevan a rutas ambiguas. O peor aún, permiten que las asignaciones válidas se vuelvan no válidas si se agregan más hosts a las redes. Por lo general, para identificar una red, una localidad selecciona bits contiguos de la porción local de una dirección y utiliza la misma división para todas las redes físicas. Direccionamiento de SuperRed En el direccionamiento de SuperRedes, en contraposición con el de subredes, permite la utilización de muchas direcciones IP para una sola organización. Este tipo de direccionamiento crea un nuevo problema: la información que los routers almacenan e intercambian aumenta drásticamente. Esto se debe a que una tabla de ruteo en vez de tener un registro por cada organización, contiene muchos por cada una. Este problema se resuelve con una técnica conocida como “Ruteo sin tipo de Inter-Dominio”. Esta técnica colapsa un grupo de direcciones contiguas en un solo registro representado por dos datos: la dirección más baja del grupo y una máscara de 32 bits. En particular, la máscara opera como una máscara estándar de subred al determinar el fin del prefijo. Los routers y los hosts que utilizan el direccionamiento de superred necesitan software de ruteo no convencional que entienda los rangos de direcciones. 13/70 Teleprocesos y Redes 2 UDP – PROTOCOLO DE DATAGRAMA DE USUARIO En la capa de protocolo IP, una dirección de destino identifica un host; no se hace ninguna otra distinción con respecto a qué usuario o qué programa de aplicación recibirá el datagrama. Para esto cada máquina contiene un grupo de puntos abstractos de destino, llamados puertos de protocolo. Cada puerto de protocolo se identifica por medio de un número entero positivo. En general, los puertos tienen memoria intermedia, para que los datos que llegan antes de que un proceso esté listo para aceptarlos no se pierdan. Para comunicarse con un puerto externo, un transmisor necesita saber tanto la dirección IP de la máquina de destino como el número de puerto de protocolo del destino dentro de la máquina. Cada mensaje debe llevar el número de puerto de protocolo del destino de la máquina a la que se envía, así como el número de puerto de origen de la máquina fuente a la que se deben direccionar las respuestas. El UDP proporciona puertos de protocolo para distinguir entre muchos programas que se ejecutan en la misma máquina. UDP utiliza el protocolo IP subyacente para transportar un mensaje de una máquina a otra y proporciona la misma semántica de entrega de datagramas, sin conexión y no confiable que IP. No emplea acuses de recibo para asegurarse de que lleguen mensajes, no ordena los mensajes entrantes, ni proporciona retroalimentación para controlar la velocidad a la que fluye la información entre las máquinas. Por lo tanto, los mensajes UDP se pueden perder, duplicar o llegar sin orden. Formato del mensaje: Consiste de dos partes: un encabezado y un área de datos. PUERTO UDP ORIGEN PUERTO UDP DESTINO LONG. MSJ. UDP CHECKSUM DATOS ... PUERTO ORIGEN Y PUERTO DESTINO: Contiene los números de puerto. PUERTO DE ORIGEN es opcional. Cuando se utiliza, especifica la parte a la que se deben enviar las respuestas, de lo contrario, puede tener el valor cero. LONGITUD: contiene un conteo de los bytes en el datagrama UDP, incluye el encabezado y los datos. CHECKSUM: Es opcional y un valor de cero significa que la suma no se computo. Es aconsejable utilizarlo, dado que IP solo calcula el CHECKSUM del encabezado y no de los datos, con lo cual esta es la única manera de garantizar que los datos lleguen intactos. Para calcular el CHECKSUM, UDP añade un pseudo-encabezado al datagrama UDP y calcula el CHECKSUM sobre todo el conjunto. El pseudo-encabezado no se transmite con el datagrama UDP, ni se incluyen en su longitud. El propósito de utilizar un pseudo-encabezado es verificar que el datagrama UDP llegó a su destino correcto. En el destino final, el software de UDP revisa la suma de verificación utilizando la dirección IP de destino, obtenida del encabezado del datagrama IP que transportó el mensaje UDP. Si la suma concuerda, se confirma que llego al destino correcto, así como al puerto de protocolo deseado dentro del host. El pseudo-encabezado: DIRECCION IP DE ORIGEN DIRECCION IP DE DESTINO CERO PROTO LONGITUD UDP 14/70 Teleprocesos y Redes 2 DIRECCION IP DE ORIGEN y DIRECCION IP DE DESTINO: contienen las direcciones IP que se utilizan cuando se envíe el mensaje UDP. PROTO: Contiene el código del tipo de protocolo IP (17 para UDP). LONGITUD UDP: contiene la longitud del datagrama UDP (sin incluir el pseudo-encabezado). Para revisar la suma de verificación, el receptor debe extraer estos campos del encabezado IP, ensamblarlos en el formato de pseudo-encabezado y recuperar la suma. Número de Puertos UDP reservados y disponibles Existen dos enfoques para la asignación de puertos. El primero se vale de una autoridad central. Todos se ponen de acuerdo en permitir que una autoridad central asigne los números de puerto conforme se necesitan y publique la lista de todas las asignaciones, las cuales se conocen como asignaciones bien conocidas de puertos. El segundo enfoque emplea la transformación dinámica. En este enfoque, los puertos no se conocen de manera global. En vez de eso, siempre que un programa necesita un puerto, el software de red le asigna uno. Para conocer la asignación actual de puerto en otra computadora, es necesario enviar una solicitud para averiguar qué puerto está utilizando determinada aplicación. La máquina objetivo responde al proporcionar el número de puerto correcto a utilizar. Los diseñadores de TCP/IP adoptaron un enfoque hibrido. TCP – SERVICIO DE TRANSFERENCIA DE FLUJO CONFIABLE Características del Servicio de Entrega Confiable La interfaz entre los programas de aplicación y el servicio TCP/IP de entrega confiable, se puede caracterizar por cinco funciones: - - - - Orientación de flujo: El servicio de entrega de flujo en la máquina de destino pasa al receptor exactamente la misma secuencia de bytes que le pasa el transmisor en la máquina origen. Conexión de circuito virtual: la transferencia de flujo es análoga a realizar una llamada telefónica. Conceptualmente, una aplicación realiza una “llamada” que la otra debe aceptar. Una vez que se establece, los módulos de protocolo informan a los programas de aplicación que se estableció una conexión y que la transferencia puede comenzar. Si la comunicación no se logra por algún motivo, ambas máquinas detectarán la falla y la reportarán a los programas apropiados de aplicación. Transferencia con memoria intermedia: Cuando se transfieren datos, cada aplicación utiliza piezas del tamaño que encuentre adecuado, que pueden ser tan pequeñas como un byte. Para hacer eficiente la transferencia y minimizar el tráfico de red, las implantaciones por lo general recolectan datos suficientes de un flujo para llenar un datagrama razonablemente largo antes de transmitirlo a través de una red. De forma similar, si el programa de aplicación genera bloques de datos muy largos, el software de protocolo puede dividir cada bloque en partes mas pequeñas para su transmisión. Para aplicaciones en las que los datos se deben entregar aunque no se llene una memoria intermedia, el servicio de flujo proporciona un mecanismo de empuje (push) que las aplicaciones utilizan para forzar una transferencia. Flujo no estructurado. Conexión Full Duplex. 15/70 Teleprocesos y Redes 2 Proporcionando Confiabilidad El servicio de entrega confiable garantiza la entrega de los datos enviados de una máquina a otra sin pérdida o duplicación. Para lograr esto se utiliza una técnica fundamental conocida como acuse de recibo positivo con retransmisión. La técnica requiere que el receptor se comunique con el origen y le envíe un mensaje de acuse de recibo (ACK) conforme recibe los datos. El transmisor guarda un registro de cada paquete que envía y espera un acuse de recibo antes de enviar el siguiente paquete. El transmisor también inicia un temporizador cuando envía un paquete y lo retransmite si dicho temporizador expira antes de que llegue un acuse de recibo. El problema final de confiabilidad surge cuando un sistema subyacente de entrega de paquetes los duplica. La solución de la duplicación requiere acciones cuidadosas ya que tanto los paquetes como los acuses de recibo se pueden duplicar. Por lo general los protocolos confiables detectan los paquetes duplicados al asignar a cada uno un número de secuencia y al obligar al receptor a recordar que números de secuencia recibidos. Para evitar la confusión causada por acuses de recibo retrasados o duplicados, los protocolos de acuses de recibo positivos envían los números de secuencia dentro de los acuses, para que el receptor pueda asociar correctamente los acuses de recibo con los paquetes. Ventanas deslizantes: Esta técnica es una forma más compleja de acuse de recibo positivo y retransmisión que el método anterior. Los protocolos de ventana deslizante utilizan el ancho de banda de red de mejor forma, ya que permite que el transmisor envíe varios paquetes sin esperar un acuse de recibo. Por ejemplo un protocolo de ventana deslizante con un tamaño de ventana de 8, se permite al transmisor enviar 8 paquetes antes de recibir un acuse de recibo. 16/70 Teleprocesos y Redes 2 Una vez que el transmisor recibe un acuse de recibo para el primer paquete dentro de la ventana, “mueve” la misma y envía el siguiente paquete. La ventana continua moviéndose en tanto se reciban acuses de recibo. Con un tamaño de ventana de 1, un protocolo de ventana deslizante sería idéntico a un protocolo de acuse de recibo positivo. Al aumentar el tamaño de la ventana, es posible eliminar completamente el tiempo ocioso de la red. Conceptualmente, un protocolo de ventana deslizante siempre recuerda que paquetes tienen acuse de recibo y mantiene un temporizador separado para cada paquete sin acuse de recibo. Si se pierde un paquete, el temporizador concluye y el transmisor reenvía el paquete. Cuando el transmisor desliza su ventana, mueve hacia atrás todos los paquetes con acuse. En el extremo receptor, el software de protocolo mantiene una ventana análoga, que acepta y acusa como recibidos los paquetes conforme llegan. Por tanto, la ventana divide la secuencia de paquetes en tres partes: los paquetes a la izquierda de la ventana se transmitieron, recibieron y acusaron exitosamente; los paquetes a la derecha de la ventana no se han transmitido; y los paquetes que quedan dentro de la ventana están en proceso de transmisión. Puertos, conexiones y puntos extremos: TCP utiliza la conexión, no el puerto de protocolo, como su abstracción fundamental; las conexiones se identifican por medio de un par de puntos extremos. Una conexión consiste en un circuito virtual entre dos programas de aplicación. TCP define que un punto extremo es un par (hostId, puerto), en donde hostId es la IP de un host y puerto es un puerto TCP del host. Puede darse el caso que dos conexiones utilicen el mismo puerto en una máquina determinada, pero no hay ambigüedad. Debido a que el TCP asocia los mensajes entrantes con una conexión en vez de hacerlo con un puerto de protocolo, utiliza ambos puntos extremos para identificar una conexión apropiada. Desde el punto de vista de un programador, la abstracción de comunicación es importante. Significa que un programador puede diseñar un programa que proporcione servicio concurrente a varias conexiones al mismo tiempo, sin necesitar números únicos de puerto local para cada una. Aperturas pasivas y activas: Al ser TCP un protocolo orientado a la conexión, requiere que ambos puntos estén de acuerdo en participar. Para hacerlo, el programa de aplicación en un extremo realiza una función de apertura pasiva al contactar su sistema operativo e indicar que aceptará una conexión entrante. En ese momento, el sistema operativo asigna un número de puerto TCP a su extremo de la conexión. El programa de aplicación en el otro extremo debe contactar a su sistema operativo mediante una solicitud de apertura activa para establecer la conexión. Segmentos, flujos y números de secuencia: TCP visualiza el flujo como una secuencia de bytes que divide en segmentos para su transmisión. TCP también utiliza un mecanismo especializado de ventana deslizante para solucionar dos problemas importantes: la transmisión eficiente y el control de flujo. El mecanismo de ventana de TCP hace posible enviar varios segmentos antes de que llegue un acuse de recibo. También soluciona en problema de control de flujo de extremo a extremo, al permitir que el receptor restrinja la transmisión hasta que tenga espacio suficiente en memoria interna para incorporar más datos. El mecanismo TCP de ventana deslizante opera a nivel de byte, no a nivel de segmento ni de paquete. Los bytes del flujo de datos se numeran de manera secuencial, y el transmisor guarda tres punteros asociados con cada conexión. Los punteros definen una ventana deslizante. El primer puntero marca el extremo izquierdo de la ventana deslizante, separa los bytes que ya se enviaron. Un segundo puntero marca el extremo derecho de la ventana deslizante y define el byte más alto de la secuencia que se puede enviar antes de recibir más acuses de recibo. El tercer puntero señala la frontera dentro de la ventana que separa los bytes que ya se enviaron de los que aún no se envían. 17/70 Teleprocesos y Redes 2 Dado que las conexiones TCP son del tipo full duplex, se llevan a cabo dos transferencias al mismo tiempo en cada conexión, una en cada dirección. Por lo tanto el software TCP en cada extremo mantiene dos ventanas por cada conexión, una se desliza a lo largo del flujo de datos que se envía, mientras que la otra se desliza a lo largo de los que se reciben. Tamaño Variable de Ventana y Control de Flujo El protocolo TCP permite que el tamaño de la ventana varíe. Cada acuse de recibo, que informa cuántos bytes se recibieron, contiene un aviso de ventana, que especifica cuántos bytes de datos adicionales está preparado para aceptar el receptor. En respuesta a un aumento en el aviso de ventana, el transmisor aumenta el tamaño de su ventana deslizante y procede al envío de bytes de los que todavía no se tiene acuse de recibo. En respuesta a una disminución en el aviso de ventana, el transmisor disminuye el tamaño de su ventana y deja de enviar los bytes que se encuentran más allá de la frontera. De hecho, los anuncios más pequeños acompañan a los acuses de recibo, así que el tamaño de la ventana cambia en el momento que se mueve hacia delante. La ventaja de utilizar una ventana de tamaño variable es que ésta proporciona control de flujo así como una transferencia confiable. Si la memoria intermedia del receptor se llena, no puede aceptar más paquetes, así que envía un anuncio de ventana más pequeño. En caso extremo, el receptor anuncia un tamaño de ventana igual a cero para detener toda la transmisión. Después, cuando hay memoria intermedia disponible, el receptor anuncia un tamaño de ventana distinto a cero para activar el flujo de datos. Formato del Segmento TCP La unidad de transferencia entre el software TCP de dos máquinas se conocen como segmentos. Los segmentos se intercambian para establecer conexiones, transferir datos, enviar acuses de recibo, anunciar los tamaños de ventanas y para cerrar conexiones. PUERTO ORIGEN PUERTO DESTINO NUMERO DE SECUENCIA NUMERO DE ACUSE DE RECIBO HLEN RES. CODE VENTANA CHECKSUM PUNT. DE URGENCIA OPCIONES (SI LAS HAY) RELLENO DATOS … Cada segmento de divide en dos partes: encabezado y datos. PUERTO FUENTE Y PUERTO DESTINO: Contiene los números de puerto TCP que identifican a los programas de aplicación en los extremos de la conexión. NUMERO DE SECUENCIA: Identifica la posición de los datos del segmento en el flujo de datos del transmisor. NUMERO DE ACUSE DE RECIBO: Identifica el número de bytes que la fuente espera recibir después. HLEN: Contiene un número entero que especifica la longitud del encabezado del segmento, medida en múltiplos de 32 bits. Es necesario porque el campo OPCIONES puede variar su tamaño. CODE BITS: Determina el propósito y contenido del segmento. Los seis bits de izquierda a derecha representan lo siguiente. 18/70 Teleprocesos y Redes 2 - URG: El campo de puntero de urgente es válido. ACK: El campo de acuse de recibo es válido. PSH: Solicita una operación push. RST: Iniciación de la conexión. SYN: Sincronizar números de secuencia. FIN: El emisor ha llegado a su fin de flujo de bytes. VENTANA: Especifica el tamaño de su memoria intermedia. De esta manera TCP informa cuántos datos está dispuesto a aceptar cada vez que envía un segmento. PUNTERO DE URGENCIA: Cuando está activado el bit URG, éste campo especifica la posición dentro del segmento en la que terminan los datos urgentes. OPCIONES: TCP utiliza este campo para negociar con el software TCP del otro extremo de la conexión; una de las opciones permite que TCP especifique el tamaño máximo de segmento (MSS) que está dispuesto a recibir. CHECKSUM: Se utiliza para verificar la integridad del encabezado y los datos del segmento TCP. Para computar esta suma de verificación, TCP coloca un pseudo-encabezado en el segmento y recalcula la suma de 16 bits sobre todo el resultado. TCP no cuenta el pseudo-encabezado en la longitud del segmento, ni tampoco lo transmite. TCP utiliza aritmética de de 16 bits y toma el complemento a 1 de la suma. El propósito de utilizar un pseudo-encabezado es el permitir que el receptor verifique que el segmento llego a su destino correcto. Pseudo-Encabezado: DIRECCION IP DE LA FUENTE DIRECCION IP DEL DESTINO CERO PROTOCOLO LONGITUD TCP PROTOCOLO: es el valor que utilizara el sistema subyacente de entrega en su campo tipo de protocolo. En el caso de TCP el valor es 6. LONGITUD TCP: especifica la longitud total del segmento TCP, incluyendo el encabezado TCP. Datos Fuera de Banda: Para incorporar señalización fuera de banda, TCP permite que el transmisor especifique los datos como urgentes, dando a entender que se debe notificar su llegada al programa receptor tan pronto como sea posible, sin importar la posición en el flujo. Esto, se logra mediante el bit de URG y el campo PUNTERO DE URGENCIA del segmento. Opciones de Tamaño máximo de Segmento: No todos los segmentos que se envían a través de una conexión serán del mismo tamaño. Sin embargo, ambos extremos necesitan acordar el tamaño máximo de los fragmentos que transferirán. TCP por lo general computará un tamaño máximo de segmento de tal forma que los datagramas IP resultantes correspondan con la MTU de la red. Es claro que si el tamaño del segmento es chico, la utilización de la red permanece baja, esto se debe al elevado overhead producido por el agregado de los encabezados de TCP e IP. Por otro lado, si los tamaños de segmento son muy grandes, es posible que IP deba fragmentarlos. Acuses de Recibo y Retransmisión Como TCP envía los datos en segmentos de longitud variable, y debido a que los segmentos retransmitidos pueden incluir más datos de los originales, los acuses de recibo no pueden asociarse fácilmente con los datagramas o segmentos. De hecho, se remiten a una posición en el flujo, utilizando los números de secuencia de flujo. El receptor recolecta bytes de datos de los segmentos entrantes y reconstruye una copia exacta del flujo que se envía. Como los segmentos viajan en 19/70 Teleprocesos y Redes 2 datagramas IP, se pueden perder o llegar en desorden; el receptor utiliza los números de secuencia para reordenar los segmentos. Un acuse de recibo TCP especifica el número de secuencia del siguiente byte que el receptor espera recibir. A este esquema de acuses de recibo se lo llama acumulativo porque reporta cuánto se ha acumulado del flujo. Una ventaja de este esquema es que son fáciles de generar y no son ambiguos. Una desventaja es que el emisor no obtiene información sobre todas las transmisiones exitosas, sino únicamente sobre una sola porción. Para entender el porqué es una desventaja, piense en una ventana con 5000 bytes comenzando en la posición 101 en el flujo, y suponga que el transmisor envió todos los datos transmitiendo 5 segmentos. Supongamos también que llegan todos menos el primero. Conforme fue llegando cada segmento, el receptor envió un acuse de recibo, pero todos ellos especificaban el byte 101, que es el byte continuo siguiente más alto que espera recibir. No hay forma que el receptor indique al transmisor que llego la mayor parte de los datos para la ventana actual. Timeout y Retransmisión Cada vez que se envía un segmento, TCP arranca un temporizador y espera un acuse de recibo. Si se produce un timeout antes de recibir el acuse de recibo correspondiente, TCP asume que el segmento se perdió o corrompió y lo retransmite. TCP utiliza un algoritmo adaptable de retransmisión para manejar retrasos variables. TCP monitorea el desempeño de cada conexión y deduce valores razonables para el timeout. Para esto, TCP registra la hora que se envía cada segmento y la hora en que se recibe el acuse de recibo de los datos en el segmento. A partir de estos dos valores, TCP computa el tiempo transcurrido, conocido como muestra de tiempo de viaje redondo (muestra de RTT). TCP almacena el RTT como promedio y a medida que va recibiendo nuevas muestras de RTT, los utiliza para cambiar lentamente dicho promedio. RTT = (α * old_RTT) + ((1-α) * new_muestra_RTT) Elegir α cercano a 1, hace que el promedio sea inalterable ante cambios mínimos. Elegir un valor de α cercano a 0 hace que el promedio responda con rapidez a los cambios. Timeout = β * RTT Por una parte, para detectar con rapidez la pérdida de paquetes, el valor de timeout debe acercarse al actual RTT. La pronta detección de pérdida de paquetes hace que TCP no espere un tiempo innecesariamente largo para retransmitir. Por otra parte si β=1, hace que ante cualquier retraso pequeño, TCP retransmita innecesariamente, lo cual desperdiciará ancho de banda de la red. Medición precisa de muestra de RTT Ambigüedad de acuse de recibo: En el caso que TCP retransmita un segmento debido a un timeout, el receptor no tiene forma de saber si un acuse de recibo corresponde al segmento original o al retransmitido. El problema aquí radica sobre cual empezará a contar el tiempo (la original o la última). Veremos que ninguna de las dos funciona. En el caso de asociar los acuses de recibo con la transmisión original, puede causar que el RTT aumente sin medida en los casos en los que la red pierda datagramas. Asociar el acuse de recibo con la retransmisión más reciente tampoco funciona, dado que se podría asociar la retransmisión con un acuse de recibo anterior y producir un RTT más pequeño de lo que debería y causando más retransmisiones. 20/70 Teleprocesos y Redes 2 Algoritmo de Karn Para resolver el problema anterior, TCP no debe actualizar la estimación de RTT para los segmentos retransmitidos. Esto se conoce como algoritmo de Karn, y evita el problema de los acuses de recibos ambiguos (usa acuses relacionados con segmentos transmitidos sólo una vez). Una implementación simple del algoritmo de Karn también puede llevar a fallas. Considere lo que sucede si TCP envía un segmento después de un aumento en el retraso. TCP computa un timeout mediante la estimación existente de RTT. El timeout será demasiado pequeño para el nuevo retardo y forzará la retransmisión. Si TCP ignora los acuses de recibo para los segmentos retransmitidos, nunca actualizará la estimación y el ciclo continuará. Para resolver dicha falla, el algoritmo de Karn necesita que el transmisor combine las técnicas de timeout de transmisión con la estrategia de timer backoff (anulación del temporizador). Si se termina el tiempo y se provoca una retransmisión, TCP aumenta el valor de tiemout. new_timeout = * timeout Respuesta al congestionamiento El congestionamiento es una condición de retraso severo causada por una sobrecarga de datagramas en uno o más routers. Esto se produce cuando el número de datagramas entrantes en un router congestionado crece hasta alcanzar su capacidad máxima y comienza a descartar datagramas. La mayoría de los protocolos de transporte utilizan el timeout y la retransmisión, lo cual termina produciendo un aumento en el retraso al retransmitir datagramas, lo que empeora el congestionamiento. Para evitar congestionamiento, TCP recomienda la utilización de dos técnicas: arranque lento y disminución multiplicativa. Dijimos que para cada conexión, TCP debe recordar el tamaño de la ventana del receptor. Para controlar el congestionamiento, TCP mantiene un segundo límite, límite de ventana de congestionamiento. En una conexión no congestionada, la ventana de congestionamiento es del mismo tamaño que la ventana del receptor. La reducción de la ventana de congestionamiento reduce el tráfico que TCP inyecta a la conexión. Prevención del congestionamiento por Disminución Multiplicativa: Cuando se pierda un segmento, reducir a la mitad la ventana de congestionamiento (hasta un mínimo de 1). Si la pérdida continúa TCP continúa duplicando el timeout antes de retransmitir. Recuperación de Arranque Lento (Aditiva): Siempre que se arranque el tráfico en una nueva conexión o se aumente el tráfico después de un período de congestionamiento, activar la ventana de congestionamiento con el tamaño de un solo segmento y aumentarla un segmento cada vez que llegue un acuse de recibo. El termino arranque lento puede no estar bien aplicado porque bajo condiciones ideales, el arranque no es muy lento. TCP inicia la ventana de congestionamiento en 1, envía un segmento y espera. Cuando llega el acuse de recibo, aumenta la ventana de congestionamiento a 2, envía dos segmentos y espera. Cuando llegan los dos acuses de recibo, cada uno aumenta la ventana de congestionamiento en 1, por lo que TCP puede enviar 4 segmentos. Los acuses por estos 4 segmentos incrementarán a 8 la ventana de congestionamiento. Cuando ocurren cuatro viajes redondos, el TCP puede enviar 16 segmentos, que a veces es lo suficiente para llegar al límite de la ventana del receptor. Para evitar el aumento demasiado rápido del tamaño de la ventana y no causar congestionamiento adicional, TCP agrega una restricción más. Una vez que la ventana de congestionamiento llega a la mitad de su tamaño original, TCP entra en una fase de prevención de congestionamiento y hace más lenta la velocidad de incremento. Durante esta fase, aumenta el tamaño de la ventana por 1 solamente si, para todos los segmentos en la ventana, se tienen acuses de recibo. 21/70 Teleprocesos y Redes 2 Establecimiento de una conexión TCP Para establecer una conexión, TCP utiliza un saludo (handshake) de tres etapas. Números de Secuencia Inicial El saludo de tres etapas realiza dos funciones importantes. Garantiza que ambos lados estén listos para transferir datos (y que tengan conocimiento de que ambos están listos) y permite, a ambas partes, acordar un número de secuencia inicial. Los números de secuencia son enviados y reconocidos durante el saludo. Cada máquina debe seleccionar un número un número de secuencia inicial en forma aleatoria que se utilizará para identificar bytes en el flujo que se esta enviando. Para entender cómo las máquinas pueden acordar un número de secuencia para dos flujos después de sólo tres mensajes, recordemos que cada segmento contiene un campo de número de secuencia y un capo de acuse de recibo. La máquina A, que inicia un saludo, transfiere un número de secuencia inicial, x, en el campo de secuencia del primer segmento SYN como parte del saludo de tres etapas. La máquina B, recibe el SYN, registra el número de secuencia y responde enviando su número de secuencia inicial en el campo de secuencia así como un reconocimiento que especifica el byte x+1 esperado por B (piggybacking). En el mensaje final, A envía un “acuse de recibo” de la recepción del mensaje de B de los bytes a través de y. En todos los casos, los acuses de recibo siguen la convención de utilizar el número del próximo byte esperado. Terminación de una conexión TCP TCP utiliza una modificación del saludo de tres etapas para cerrar conexiones. Recordemos que las conexiones TCP son full duplex que contienen dos transferencias de flujos independientes. Cuando un programa de aplicación informa a TCP que ya no tiene más datos para enviar, cerrará la conexión en una dirección. Una vez que la conexión se ha cerrado en una dirección dada, TCP rechaza más datos en esta dirección. Mientras tanto, los datos pueden continuar fluyendo en la dirección opuesta hasta que el emisor se cierra. Por supuesto, los acuses de recibo continúan fluyendo hacia el emisor incluso después de que la conexión se ha cerrado. Cuando ambas direcciones se han cerrado, TCP en cada punto extremo borra sus registros de la conexión. 22/70 Teleprocesos y Redes 2 Reset de una conexión TCP TCP proporciona una capacidad de reiniciación (reset) para desconexiones anormales. Para resetear una conexión, un lado inicia la interrupción enviando un segmento con el bit RST activado en el campo CODIGO. El otro lado responde a un segmento de reset de forma inmediatamente interrumpiendo la conexión. TCP también informa al programa de aplicación que se ha presentado un reset. Un reset es una interrupción instantánea, lo cual significa que la transferencia en ambas direcciones se interrumpe de manera inmediata y se liberan recursos como los búfers. Forzando la entrega de datos Para forzar la entrega TCP proporciona la operación de push, que un programa de aplicación puede utilizar para forzar la entrega de bytes en el flujo de transmisión sin esperar a que se les almacene en memoria intermedia. También solicita que se active el bit PSH del campo CODIGO, así los datos se entregarán sin retraso al programa de aplicación en el receptor. Números reservados para puertos TCP TCP cambia la asignación dinámica de puertos mediante un conjunto de asignación de puertos bien conocidos para programas llamados con frecuencia, pero la salida de la mayor parte de los números de puerto disponibles para el sistema operativo se asigna conforme los programas lo necesitan. Síndrome de ventana tonta y paquetes pequeños Las primeras implementaciones de TCP presentaron un problema conocido como síndrome de ventana tonta en el cual cada acuse de recibo anunciaba una pequeña cantidad de espacio disponible y cada segmento transportaba una pequeña cantidad de datos. Por ejemplo, consideremos lo que sucedería si la aplicación de un receptor elige leer los datos de entrada un byte a la vez. Cuando una conexión se establece por primera vez, el receptor TCP asigna un búfer de K bytes y utiliza el campo VENTANA, en los segmentos de acuse de recibo, para anunciar el tamaño disponible del búfer al emisor. Si la aplicación del emisor genera datos rápidamente, el emisor TCP transmitirá segmentos con datos para toda la ventana. Finalmente, el emisor recibirá un acuse de recibo que especifica que la ventana está llena y que no queda espacio adicional en el búfer del receptor. Cuando la aplicación de recepción lee un byte de datos desde la memoria intermedia llena, queda disponible un espacio de un byte. Hemos dicho que cuando un espacio queda disponible en el búfer, el TCP genera un acuse de recibo que utiliza el campo VENTANA, en la máquina de recepción, para informar al emisor. En el ejemplo, el receptor anunciará una ventana de un byte. Cuando tenga 23/70 Teleprocesos y Redes 2 conocimiento del espacio disponible, el emisor TCP responderá con la transmisión de un segmento que contenga un byte de datos. Prevención del síndrome de ventana tonta Prevención del lado del receptor: En general un receptor mantiene un registro interno de la ventana disponible en el momento, pero retarda los anuncios para incrementar el tamaño de la ventana del emisor hasta que la ventana pueda avanzar una cantidad significativa. La definición de “significativa” depende del tamaño de la memoria intermedia del receptor y del tamaño del segmento máximo. TCP lo define como el mínimo de la mitad de la memoria intermedia del receptor o el número de bytes de datos en un segmento de tamaño máximo. Prevención de la ventana tonta del lado del emisor: Así, para lograr este objetivo, un emisor TCP debe permitir a la aplicación del emisor hacer múltiples llamadas a write y debe reunir los datos transferidos con cada llamada antes de transmitirlos a un solo segmento largo. Es decir que un emisor TCP debe retardar el envío de un segmento hasta que pueda acumular una cantidad razonable de datos. Esta técnica se conoce con el nombre de clumping (agrupamiento). La cuestión es la siguiente, ¿Qué tanto debe esperar TCP antes de transmitir datos? La técnica que un emisor TCP utiliza para evitar el envío de paquetes pequeños es flexible –el retraso depende del desempeño actual de la red. La prevención de la ventana tonta en el lado del emisor se conoce como self clocking pues no se calculan retardos. Por lo contrario, el TCP utiliza la llegada de un acuse de recibo para disparar la transmisión de paquetes adicionales. Si una aplicación genera datos un byte por vez, TCP enviará el primer byte inmediatamente. Sin embargo, hasta que llegue el ACK, TCP acumulará bytes adicionales en su memoria intermedia. Así, si la aplicación es razonablemente rápida, comparada con la red, los segmentos sucesivos contendrán muchos bytes. Si la aplicación es lenta en comparación con la red, se enviarán segmentos pequeños sin retardos largos. Esta técnica es conocida como algoritmo de Nagle. RUTEO – NUCLEOS PARES Y ALGORITMOS Orígenes de las Tablas de Ruteo Cada router está conectado a dos o más redes físicas y envía datagramas IP entre éstas, acepta datagramas que llegan por medio de una interfaz de red y los rutea hacia otra interfaz. Excepto para los destinos conectados directamente a la red. Un datagrama viaja de un router a otro hasta encontrar un router que se encuentre conectado directamente a la misma red en la que se ubica su destino final. El ruteo IP utiliza una tabla para tomar decisiones de ruteo. Cada elemento de información en la tabla de ruteo especifica la porción de red de una dirección de destino y establece la dirección de la siguiente máquina a lo largo de una ruta utilizada para alcanzar la red. En general el establecimiento de rutas comprende procesos de iniciación y actualización. Cada router debe establecer un conjunto inicial de rutas cuando es iniciado y debe actualizar las tablas cuando las rutas cambian. En algunos sistemas el router lee una tabla de ruteo inicial desde un almacenamiento secundario en el proceso de iniciación, haciéndola residente en la memoria principal. En otros casos, se comienza con una tabla vacía que debe llenarse ejecutando comandos explícitos. Otros comienzan por deducir un conjunto inicial de rutas del conjunto de direcciones para la red local a la que la máquina esta conectada, y se pone en contacto con las máquinas vecinas para solicitar rutas adicionales. 24/70 Teleprocesos y Redes 2 Ruteo con información parcial La diferencia principal entre los routers y los hosts, es que los hosts saben muy poco acerca de la estructura de la red a la que están conectadas. De hecho, muchos hosts tienen sólo dos rutas en su tabla de ruteo: una para la red local y otra por omisión hacia un router cercano. Un host puede rutear datagramas exitosamente aun cuando sólo cuente con información de ruteo parcial ya que puede basarse en un router. Router de núcleo El sistema de núcleo estaba diseñado para proporcionar rutas autorizadas consistentes y confiables para todos los destinos posibles. Debido a que coda router de núcleo conoce todas las rutas hacia todos los destinos posibles, no es necesaria una ruta por omisión. Si la dirección de destino del datagama no aparece en la tabla de ruteo de un router de núcleo, el router generará un mensaje de destino inalcanzable, ICMP, y eliminará el datagrama. En esencia, el diseño de núcleo evita la ineficiencia al eliminar las rutas por omisión. Una arquitectura de ruteo de núcleo requiere de un conjunto centralizado de servidores de ruteo como depósito de información acerca de todos los destinos posibles en una red. Este sistema trabaja mejor en redes que cuentan con una sola columna vertebral de red administrada centralmente. La expansión de la topología hacia múltiples columnas vertebrales de redes hace el ruteo mas complejo; el método de la división de la arquitectura de núcleo, en la que todos los routers utilizan rutas por omisión, introduce la posibilidad de que se desarrollen ciclos cerrados de ruteo. Ruteo por Vector-Distancia (Bellman-Ford) El router establece una lista de todas las rutas conocidas en una tabla. Cuando arranca, un router inicia esta tabla de ruteo para que contenga una entrada de información por cada red conectada directamente. Cada introducción en la red identifica una red de destino y establece una distancia hacia la red, por lo general medida en saltos. Periódicamente, cada router envía una copia de su tabla de ruteo a cualquier otro router que pueda alcanzar de manera directa. Cuando llega un reporte al router K desde el router J, K examina el conjunto de destinos reportados y la distancia de cada uno. Si J conoce una ruta más corta para alcanzar un destino o si J reporta un destino que K no tiene en su tabla, o bien si K rutea actualmente hacia un destino a través de J y la distancia de J hacia el destino ha cambiado, K actualiza esta información en su tabla. Observe que si J reporta una distancia N, el lado actualizado en K tendrá la distancia N+1 (la distancia para alcanzar el destino desde J, más la distancia de alcanzar J). Por supuesto, la tabla de ruteo completa contiene una tercera columna que especifica la ruta. La entrada inicial de datos se marca con el valor entrega inmediata. Cuando el router K añade o actualiza una entrada de datos en respuesta al mensaje de J, asigna a J como la ruta para tal dato. 25/70 Teleprocesos y Redes 2 El algoritmo vector-distancia crea un problema de convergencia lenta o conteo al infinito, problema en el cual aparecerán inconsistencias, debido a que los mensajes de actualización de ruteo se difunden lentamente a través de la red. Seleccionando un infinito pequeño se ayuda a limitar la convergencia, pero no se elimina. Como se muestra en (a), el router R1 tiene una conexión directa a la red 1, con lo cual tiene una ruta de distancia 1 en su tabla. El router R2 ha aprendido la ruta desde R1 y anuncia la ruta con distancia 2. Finalmente R3 aprende la ruta de R2 y la anuncia con distancia 3. Ahora R1 pierde conexión con la red 1. R1 actualiza su tabla de ruteo especificando una distancia a la red 1 como infinito (16 en RIP). Supongamos ahora que R2 logra anunciar sus rutas justo después de que la conexión de R1 fallara. Si esto sucede, R1 recibirá los mensajes de R2 y seguirá el algoritmo usual: éste notará que R2 ha anunciado una ruta hacia la red 1 a un costo más bajo, calculando ahora que se encuentra a 3 pasos para alcanzar la red 1 e instalará una nueva ruta a través de R2. En el siguiente ciclo de intercambio de ruteo, R1 difundirá sus tablas. Cuando R2 aprenda que las rutas de R1 hacia la red 1 tiene una longitud igual a 3, ésta calculará una nueva longitud para tal ruta, haciéndola igual a 4. En el siguiente ciclo, R1 recibe el incremento desde R2 e incrementa la distancia a 5. Este proceso continuará contando hasta el infinito. Solución al problema de la convergencia lenta Otra forma de pensar el problema de la convergencia lenta es en términos de flujo de información. Si un router anuncia una ruta corta hacia alguna red, todos los routers receptores responderán rápidamente instalando la ruta. Si un router deja de anunciar una ruta, el protocolo deberá depender de un mecanismo de límite de tiempo antes de considerar la ruta como inaccesible. Técnica de actualización de horizonte dividido: Cuando se utiliza está técnica, un router registra la interfaz por la que ha recibido una ruta particular y no difunde esta información acerca de la ruta de regreso sobre la misma interfaz. Poison Reverse: Una vez que la conexión desaparece, el router anuncia la conexión conservando la entrada de información por varios períodos de actualización e incluye un costo infinito en la difusión. Para hacer esta técnica más efectiva, se debe combinar con las triggered updates. Las actualizaciones activadas obligan a un router a que envíe una difusión inmediatamente que recibe malas noticias, en lugar de esperar el próximo período de difusión. Al enviar una actualización inmediatamente, un router minimiza el tiempo en el que es vulnerable por recibir las buenas noticias. RUTEO – SISTENAS AUTONOMOS Sistemas Autónomos Para propósitos de ruteo a un grupo de redes y routers controlados por una sola autoridad administrativa se lo conoce sistemas autónomos. Los routers dentro de un sistema autónomo son libres de seleccionar sus propios mecanismos de exploración, propagación, validación y verificar la consistencia de las rutas. Dado que las redes y los routers se encuentran bajo una sola unidad administrativa, esta autoridad puede garantizar que las rutas internas se mantengan consistentes y viables; más aún, la autoridad 26/70 Teleprocesos y Redes 2 administrativa puede seleccionar a una de sus máquinas para servir como la máquina que aparecerá ante el mundo exterior como el acceso hacia la red. Vecinos Exteriores: se los llama así a los routers que intercambian información de ruteo y que pertenecen a dos sistemas autónomos diferentes. Vecinos Interiores: se los llama así a los routers que intercambian información de ruteo y que pertenecen al mismo sistema autónomo. OSPF – RUTEO EN UN SISTEMA AUTONOMO Rutas Interiores dinámicas y Estáticas En redes pequeñas que cambian lentamente, los administradores pueden establecer y modificar las rutas a mano. El administrador tiene una tabla de redes y actualiza la tabla si una red nueva se añade o se elimina del sistema autónomo. La desventaja de un sistema manual es obvia; los sistemas manuales no se pueden adaptar al crecimiento o a los cambios rápidos, para lo cual son necesarios métodos automatizados. Estos métodos pueden también ayudar a mejorar la confiabilidad y la respuesta a las fallas en pequeñas redes que tienen rutas alternativas. Para automatizar información sobre la accesibilidad de una red, los routers interiores normalmente se comunican con otros, intercambian información de accesibilidad o información de ruteo, a partir de la cual la accesibilidad se puede deducir. Una vez que la información de accesibilidad para un sistema autónomo completo se ha ensamblado, uno de los routers en el sistema puede anunciarlo a otros sistemas autónomos utilizando EGP. Un solo router puede utilizar simultáneamente 2 protocolos de ruteo diferentes, uno para la comunicación al exterior del sistema autónomo y otro para la comunicación al interior del sistema autónomo. Protocolo SPF La principal alternativa a los algoritmos de vector-distancia es una clase de algoritmos conocidos como enlace estado, Shortest Path First (SPF). Estos algoritmos requieren que cada router participante tenga información de la topología completa. En lugar de enviar un mensaje que contenga una lista de destinos, un router que participa en un algoritmo SPF desempeña dos tareas. En primer lugar, prueba activamente el estado de todos los routers vecinos. En segundo lugar difunde periódicamente la información del estado del enlace hacia otros routers. Para informar a los otros routers, cada router difunde periódicamente un mensaje que lista el estado de cada uno de estos enlaces. Estos mensajes no especifican rutas, sólo si es posible la comunicación entre pares de routers. Cada vez que llega un mensaje de estado de enlace, un router utiliza la información para actualizar su mapa de la red. Cada vez que cambia el estado de un enlace, el router computa de nuevo las rutas aplicando el algoritmo de Dijkstra de la ruta más corta al grafo resultante. Una de las ventajas es que cada router computa trayectorias independientes, utilizando la misma información de estado original. Como los routers realizan el cálculo de rutas de manera local, la convergencia está garantizada. Por último, dado que los mensajes de estado de enlace sólo transportan información sobre conexiones directas desde un solo router, su tamaño no depende del número de redes en la red. De esta forma los algoritmos SPF se extienden mejor que los algoritmos de vector-distancia. 27/70 Teleprocesos y Redes 2 Protocolo OSPF OSPF incluye un ruteo por tipo de servicio. Los administradores pueden instalar múltiples rutas hacia un destino dado, uno por cada tipo de servicio (por ejemplo, retardo bajo, rendimiento alto). Cuando se rutea un datagrama, un router que corre OSPF utiliza la dirección de destino y el IP para seleccionar una ruta. El OSPF está entre los primeros protocolos TCP/IP que ofrecen un ruteo por tipo de servicio. OSPF proporciona balance de carga. Si un administrador especifica múltiples rutas hacia un destino dado con el mismo costo, OSPF distribuye el trafico entre todas las rutas de la misma manera. Protocolos como RIP calculan una sola ruta para cada destino. OSPF permite que una localidad divida sus redes y routers en subconjuntos llamados áreas. Cada área es autónoma; el conocimiento de la topología de un área se mantiene oculto para las otras áreas. El protocolo OSPF especifica que todos los intercambios entre routers deben ser autenticados. OSPF soporta rutas específicas para hosts y sub redes así como rutas específicas de red. Permite a los routers intercambiar información de ruteo aprendida desde otras localidades (externas). Básicamente uno o más routers con conexiones hacia otras localidades reciben información sobre éstas y la incluyen cuando envían mensajes de actualización. El formato de mensaje distingue entre información adquirida de fuentes externas e información adquirida de routers en el interior de la localidad, para evitar ambigüedad acerca de la fuente o de la confiabilidad de las rutas. Formato del Mensaje OSPF: VERSION LONG. DEL MENSAJE TIPO DIR IP DEL ROUTER FUENTE AREA ID CHECKSUM TIPO DE AUTENTICACION AUTENTICACION AUTENTICACION VERSION: Especifica la versión del protocolo. TIPO: Identifica el tipo de mensaje según lo siguiente - 1: Hello (Se utiliza para pruebas de accesibilidad). 2: Descripción de base de datos (topología) 3: Solicitud de estado de enlace. 4: Actualización de estado de enlace. 5: Acuse de recibo de estado de enlace. DIRECCION IP ROUTER FUENTE: Tiene la dirección de emisor. AREA ID: Tiene el número de identificación de 32 bits para el área. TIPO DE AUTENTICACIÓN: Dado que cada mensaje puede incluir la autenticación, este campo especifica qué esquema de autenticación se está utilizando (actualmente, 0 significa que no se está empleando ninguna autenticación y 1 que se está usando una simple clave de acceso) 28/70 Teleprocesos y Redes 2 1) Formato del mensaje Hello de OSPF OSPF envía periódicamente mensajes Hello en cada enlace para establecer y probar la accesibilidad del vecino. ENCABEZADO OSPF CON TIPO = 1 MASCARA DE RED HELLO INTER DEAD TIMER GWAY PRIO DIR IP DEL ROUTER FUENTE AREA ID CHECKSUM TIPO DE AUTENTICACION AUTENTICACION AUTENTICACION MASCARA DE RED: Contiene la máscara de red sobre la cual se esta enviando el mensaje. DEAD TIMER: Contiene el tiempo en segundos después del cual se considera sin actividad a un vecino que no responde. HELLO INTER: Es el período normal en segundos, entre mensajes Hello. GWAY PRIO: Es un entero que señala la prioridad del router y se utiliza en la selección de un router designado de respaldo ROUTER DESIGNADO y ROUTER DE RESPALDO: Contiene las direcciones IP que proporcionan la visión del emisor del router designado y del router de respaldo para la red sobre la que está enviando el mensaje. DIRECCION IP DE VECINOn: Contiene las direcciones IP de todos los vecinos de los que el emisor ha recibido recientemente mensajes Hello. 2) Formato del mensaje de Descripción de la Base de Datos del OSPF Los routers intercambian mensajes de descripción de la base de datos para iniciar su base de datos de la topología de red. En el intercambio, un router sirve como maestro, mientras que otro es esclavo. El esclavo envía acuses de recibo de cada mensaje de descripción de base de datos con una respuesta. Dado que la base de datos puede ser extensa, puede dividirse en varios mensajes utilizando los bits I y M. ENCABEZADO OSPF CON TIPO = 2 DEBE SER CERO I M S NUMERO DE SECUENCIA DE BASE DE DATOS TIPO DE ENLACE ID DE ENLACE ADVERTISING ROUTER NUMERO DE SECUENCIA DE ENLACE CHECKSUM LINK AGE … 29/70 Teleprocesos y Redes 2 I: Se setea a 1 en el mensaje inicial. M: Se setea a 1 si hay mensajes adicionales. S: Indica si el mensaje fue enviado por un maestro (valor 1) o por un esclavo (valor 0). NUMERO DE SECUENCIA DE BASE DE DATOS: Numera los mensajes secuencialmente, así el receptor puede saber si uno está equivocado. El mensaje inicial contiene un número aleatorio y los mensajes siguientes contienen enteros en secuencia que comienzan con R. TIPO DE ENLACE: describe un enlace según la siguiente tabla: - 1: Enlace de router. - 2: Enlace de red. - 3: Resumen de enlace (red IP) - 4: Resumen de enlace (enlace para router de frontera) - 5: Enlace externo (enlace hacia otras localidades) ENLACE ID: Contiene la identificación para el enlace (puede ser la dirección IP de un router o una red, dependiendo del tipo de enlace). ADVERTISING ROUTER: Especifica la dirección del router que anuncia este enlace. NUMERO DE SECUENCIA DE ENLACE: proporciona otra garantía de que la información del enlace no se ha alterado. LINK AGE: Contiene el tiempo en segundos desde que el enlace fue establecido (ayuda a ordenar los mensajes) Los campos resaltados, describen un enlace en la topología de red y se repiten por cada enlace. 3) Formato del mensaje de Solicitud de Estado de Enlace de OSPF Luego de intercambiar mensajes de descripción de bases de datos con un vecino, un router puede descubrir que algunas partes de su base de datos están fuera de fecha. Para solicitar que el vecino proporcione información actualizada, el router envía un mensaje de solicitud de estado de enlace. El mensaje lista enlaces específicos y el vecino responde con la información más actualizada que tiene en relación a estos enlaces. ENCABEZADO OSPF CON TIPO = 3 TIPO DE ENLACE ID DE ENLACE ADVERTISING ROUTER … 4) Formato del mensaje de Actualización de Estado de Enlace OSPF Los routers difunden el estado de enlace como un mensaje de actualización de estado de enlace. Cada actualización consiste en una lista de anuncios con la siguiente forma: ENCABEZADO OSPF CON TIPO = 4 NUMEROS DE ANUNCIOS DE ESTADO DE ENLACE ANUNCIO DE ESTADO DE ENLACE1 … ANUNCIO DE ESTADO DE ENLACESn 30/70 Teleprocesos y Redes 2 Cada anuncio de estado de enlace tiene un formato de encabezado como el siguiente: LINK AGE TIPO DE ENLACE ID DE ENLACE ADVERTISING ROUTER NUMERO DE SECUENCIA DE ENLACE CHECKSUM LINK AGE El valor utilizado en cada campo es el mismo que en el mensaje de descripción de base de datos. A continuación del encabezado de estado de enlace, se incluye uno de cuatro posibles formatos para describir el enlace desde un router hacia un área dada, el enlace desde un router hacia una red específica, el enlace desde un router hacia una red física que comprende una sola subred de una red IP o un enlace desde un router hacia una red en otra localidad. En todos los casos el campo TIPO DE ENLACE en el encabezado de estado de enlace especifica cuál de los formatos de ha utilizado. Así, un router que recibe un mensaje de actualización de estado de enlace sabe exactamente cuál de los destinos se ubica dentro de la localidad y cuales son externos. Ruteo con información parcial Los hosts pueden rutear con información parcial porque dependen de los routers. Está claro que todos los routers tienen información completa. La mayor parte de los sistemas autónomos tienen un solo router que forma un puente al conectar el sistema autónomo con otros sistemas autónomos. Los routers dentro del sistema autónomo tienen conocimiento sobre los destinos dentro de este sistema autónomo, pero éstos rutearán el tráfico restante hacia el puente. Los routers núcleo tienen un conjunto completo de rutas hacia todos los destinos posibles; éstos no utilizan el ruteo por omisión. Los routers no-nucleo usualmente no tienen un conjunto completo de rutas; éstos dependen de una ruta por omisión para manejar direcciones de redes que no entienden. Utilizar rutas por omisión para la mayor parte de los routers no-nucleo tiene dos consecuencias. Primero, significa que los errores de ruteo locales podrían no detectarse. Por ejemplo, si una máquina en un sistema autónomo rutea incorrectamente un paquete hacia un sistema autónomo externo en lugar de hacerlo hacia un router local, el sistema externo lo ruteará de regreso (posiblemente enviando un mensaje de redireccionamiento ICMP hacia la fuente original). En segundo lugar, por el lado positivo, tener rutas por omisión significa que el mensaje de actualización de ruteo será mucho más pequeño que las actualizaciones de ruteo utilizadas en un sistema núcleo. PROTOCOLOS DE ROUTING EXTERNO: BGP (BORDER GATEWAY PROTOCOL) Introducción Los protocolos de ruteo externo son los que se utilizan para interconectar Sistemas Autónomos. En los protocolos de ruteo interno la prioridad era buscar rutas optimas atendiendo únicamente al criterio de minimizar la “distancia” medida en términos de la métrica elegida para la red. La selección de rutas entre sistemas autónomos plantea un problema diferente, ya que la cuestión no se reduce a la selección de la ruta optima sino que se debe atender a criterios externos de tipo político, económico, administrativo, etc. Hasta 1990 se utilizaba como protocolo de ruteo externo en la Internet el denominado EGP (Exterior Gateway Protocol). Este protocolo no fue capaz de soportar el crecimiento de la Red y entonces se desarrollo un nuevo protocolo de ruteo externo denominado BGP. 31/70 Teleprocesos y Redes 2 BGP es un protocolo de transporte fiable. Esto elimina la necesidad de llevar a cabo la fragmentación de actualización explícita, la retransmisión, el reconocimiento, y secuenciación. Funciones de BGP BGP se diseño para permitir el intercambio de información de encaminamiento entre routers en sistemas autónomos diferentes. El protocolo opera en términos de mensajes, que se envían utilizando TCP. El repertorio de mensajes es el siguiente: 1.- OPEN 2.- UPDATE 3.- KEEPALIVE 4.- NOTIFICACION BGP supone tres procedimientos funcionales: - Adquisición de vecino. Detección de vecino alcanzable. Detección de red alcanzable. Dos routers se considera que son vecinos si están en la misma subred. Si los dos routers están en sistemas autónomos diferentes, podrían desear intercambiar información de encaminamiento. Para esto es necesario realizar primero el proceso de adquisición de vecino. Se requiere un mecanismo formal de encaminamiento ya que alguno de los dos vecinos podría no querer participar. Existirán situaciones en las que un vecino no desee intercambiar información esto se puede deber a múltiples factores como por ejemplo que este sobresaturado y entonces no quiere ser responsable del tráfico que llega desde fuera del sistema. En el protocolo de adquisición de vecino, un dispositivo envía un mensaje de petición al otro, el cual puede aceptar o rechazar el ofrecimiento. El protocolo no indica como puede saber un router la dirección o incluso la existencia de otro router. Estas cuestiones se tratan en el momento de establecer la configuración del sistema o por una intervención activa del gestor de la red. Para llevar a cabo la adquisición de vecino, un router envía al otro un mensaje OPEN. Este mensaje identifica al AS al que pertenece el emisor y suministra la dirección IP del router. Si el otro router acepta la relación, envía un mensaje de KEEPALIVE. Una vez establecida la relación de vecino, se utiliza el procedimiento de detección e vecino alcanzable para mantener la relación. Este procedimiento consiste en enviarse entre los dos vecinos periódicamente mensajes de KEEPALIVE para asegurarse de que la relación sigue establecida. El último procedimiento especificado por BGP es la detección de red alcanzable. Cada router mantiene una base de datos con las redes que puede alcanzar y la ruta preferida para llegar hasta esa red. Siempre que se realiza un cambio en esa base de datos, el dispositivo de almacenamiento envía un mensaje de UPDATE por difusión a todos los router que implementan BGP. Formato de Mensajes BGP Los mensajes BGP tienen una cabecera común que contiene los siguientes tres campos: - MARKER: reservado para autentificación. El emisor puede insertar un valor en este campo para permitir al receptor comprobar la veracidad del emisor. LONGITUD: longitud del mensaje en bytes. TIPO: tipo de mensaje: OPEN, UPDATE, NOTIFICATION, KEEPALIVE. 32/70 Teleprocesos y Redes 2 1) Mensaje OPEN. Para adquirir un vecino, un router abre primero una conexión TCP con el dispositivo vecino y después envía un mensaje OPEN. Este mensaje identifica al AS al que pertenece el emisor y suministra la dirección IP del router. En la siguiente figura se muestra el formato del mensaje OPEN: Campo Long (bytes) MARKER 16 LONGITUD 2 TIPO 1 VERSION 1 AS 2 TIEMPO DE PERMANENCIA 2 IDENTIFICADOR DE BGP 4 LONGITUD OPCIONES 1 OPCIONES Variable VERSION: indica la versión del protocolo del mensaje. La versión actual es 4. AS: identifica al sistema autónomo del emisor del mensaje. TIEMPO DE PERMANENCIA: indica el tiempo de que propone el emisor como Hold Time. IDENTIFICADOR DE BGP: identifica al BGP emisor. 2) Mensaje KEEPALIVE El mensaje KEEPALIVE consta solo de la cabecera. Cada router envía regularmente estos mensajes para evitar que expire el temporizador. En la siguiente figura se muestra el formato del mensaje KEEPALIVE: Campo Long (bytes) MARKER 16 LONGITUD 2 TIPO 1 3) Mensaje UPDATE El mensaje UPDATE facilita dos tipos de información: - Información sobre una ruta particular a través del conjunto de redes. Esa información se puede incorporar a la base de datos de cada router que la recibe. - Una lista de rutas previamente anunciadas por este router que van a ser eliminadas. En la siguiente figura se muestra el formato del mensaje UPDATE: Campo MARKER LONGITUD TIPO LONGITUD RUTAS NO FACTIBLES Long (bytes) 16 2 1 2 33/70 Teleprocesos y Redes 2 RUTAS RETIRADAS LONGITUD TOTAL ATRIBUTOS DE CAMINO ATRIBUTOS DE CAMINO INFORMACION DE ACCESIBILIDAD DE LA CAPA DE RED Variable 2 Variable Variable Un mensaje UPDATE puede contener uno o ambos tipos de información. Consideremos primero el tipo de información 1. La información sobre una ruta particular a través de la red implica tres campos, campo INFORMACION DE ACCESIBILIDAD DE LA CAPA DE RED (NLRI), LONGITUD TOTAL ATRIBUTOS DE CAMINO, y el campo ATRIBUTOS DE CAMINO. El campo NLRI contiene una lista de identificadores de redes que se pueden alcanzar por esta ruta. Cada red se identifica por su dirección IP, que es en realidad una parte de la dirección IP completa. El campo atributos de camino contiene una lista de atributos que se aplican a esta ruta particular. Los atributos definidos son los siguientes: - - Origen: indica si la información fue generada por un protocolo de router interior o exterior. Camino_AS: una lista de los AS que son atravesados por la ruta. Siguiente_salto: dirección IP del router frontera que se debe usar como siguiente salto para alcanzar los destinos indicados en el NLRI. Multi_exit_disc: se usa para comunicar alguna información sobre rutas internas a un AS. Local_pref: usado por un router para informar a otros router dentro del mismo AS de su grado de preferencia por una ruta particular. No tiene significado alguno para routers en otros AS. Agregado_atomico, Agente_union: estos dos campos implementan el concepto de unión de rutas. En esencia, un conjunto de redes y su espacio de direcciones correspondiente se pueden organizar jerárquicamente, o como un árbol. En este caso las direcciones de las redes se estructuran en dos o más partes. Todas las redes de un subarbol comparten una dirección internet parcial común. Usando esta dirección parcial común, la cantidad de información que se debe comunicar en NLRI se pude reducir significativamente. El atributo Camino_AS sirve realmente para dos objetivos. Ya que indica los AS que debe atravesar un datagrama si sigue esta ruta. La información de camino_AS habilita a un router a que implemente un criterio de ruteo. Esto es, un router puede construir un camino para pasar por un determinado AS. 4) Mensaje NOTIFICATION Se envían cuando se detecta algún tipo de error. Se puede informar de los siguientes tipos de errores: - - - Error en la cabecera del mensaje: incluye errores de sintaxis y autentificación. Error en mensaje OPEN: incluye errores de sintaxis y opciones no reconocidas en un mensaje OPEN. Este mensaje también se puede utilizar para indicar que el tiempo de mantenimiento en el mensaje OPEN es inaceptable. Error en el mensaje UPDATE: incluye errores de sintaxis y validación en un mensaje UPDATE. Tiempo de mantenimiento expirado: si el router que envía no recibe mensajes sucesivos de KEEPALIVE y/o UPDATE y/o NOTIFICATION durante el tiempo de mantenimiento, entonces se comunica este error y se cierra la conexión. Error en la máquina de estados finitos: incluye cualquier error de procedimiento. Cese: utilizado por un router para cerrar una conexión con otro router en ausencia de cualquier otro error. 34/70 Teleprocesos y Redes 2 En la siguiente figura se muestra el formato del mensaje NOTIFICATION: Campo MARKER LONGITUD TIPO CODIGO ERROR SUBCODIGO DE ERROR DATOS Long (bytes) 16 2 1 1 1 Variable El subcódigo de error nos da mas información sobre el error. 35/70 Teleprocesos y Redes 2 IGMP – MULTIDIFUSION INTERNET Difusión por hardware La entrega por difusión significa que la red entrega una copia de un paquete para cada destino. En Ethernet, esto puede completarse con la transmisión de un solo paquete. En redes compuestas por conmutadores con conexiones punto a punto, el software tiene que implantar la difusión enviando copias de los paquetes a través de conexiones individuales hasta que todas las computadoras han recibido una copia. En el caso de la mayor parte del hardware, el usuario especifica la entrega por difusión enviando el paquete hacia una dirección de destino especial y reservada, llamada dirección de difusión. La principal desventaja, es que toda difusión consume recursos en todas las máquinas. Multidifusión por hardware Algunas tecnologías de hardware soportan una segunda forma de entrega multipunto, llamada multidifusión. A diferencia de la difusión, la multidifusión permite que cada máquina elija si quiere participar en ella. Cuando un grupo de máquinas quiere comunicarse selecciona una dirección de multidifusión en particular para utilizarla durante la comunicación. Luego de configurar el hardware de interfaz de red, para conocer la dirección de multidifusión seleccionada, todas las máquinas en el grupo recibirán una copia de cada paquete enviado hacia tal dirección de multidifusión. Multidifusión IP La multidifusión IP permite la transmisión de un datagrama IP a un conjunto de hosts que forman un solo grupo de multidifusión. La multidifusión IP emplea el mismo concepto de entrega con el mejor esfuerzo que en otras entregas IP, esto significa que los datagramas de multidifusión pueden perderse, borrarse, duplicarse o entregarse sin orden. La pertenencia a un grupo de multidifusión IP es un proceso dinámico. Un anfitrión puede unirse o abandonar un grupo en cualquier momento. Además, un host puede ser miembro de un número indeterminado de grupos de multidifusión. Cada grupo de multidifusión tiene una dirección de multidifusión única de clase D. La multidifusión IP puede utilizarse en una sola red física o a través de una red de redes. En éste ultimo caso, routers de multidifusión especiales enviarán los datagramas de multidifusión. Direcciones de Multidifusión IP La multidifusión IP usa direcciones Clase D. Los primeros 4 bits contienen 1110 e identifican la dirección como una multidifusión. Los 28 bits restantes especifican un grupo de multidifusión particular. No hay estructura en el grupo de bits. En particular, el campo de grupo, no contiene una dirección de red como en las direcciones clase A, B y C. 224.0.0.0 a 239.255.255.255 La dirección 224.0.0.0 esta reservada; no se puede asignar a ningún grupo. Además, la dirección 224.0.0.1 está asignada permanentemente al grupo de todos los hosts, el cual incluye todos los hosts y routers que participan en la multidifusión IP. En general, esta dirección se utiliza para alcanzar todas las máquinas que participan en la multidifusión IP en una red local; no hay direcciones que hagan referencia a todos los hosts en todas las redes. Las direcciones de multidifusión solo pueden emplearse como direcciones de destino. 36/70 Teleprocesos y Redes 2 Transformación de Multidifusión IP en Multidifusión Ethernet Para transformar una dirección de multidifusión IP en su correspondiente dirección de multidifusión Ethernet, colocar los 23 bits de orden menor de la dirección de multidifusión IP dentro de los 23 bits de orden inferior de la dirección (hardware) de multidifusión Ethernet especial 01.00.5E.00.00.0016. Puede verse que la transformación no es única. La consecuencia de este diseño es que algunos datagramas de multidifusión puede recibirse en un host, aunque no estén destinados a tal host. Extensión de IP para manejar la Multidifusión Un host participa en una multidifusión IP en uno de tres niveles. 0: El host no puede ni enviar ni recibir multidifusión IP. 1: El host puede enviar pero no recibir multidifusión IP. 2: El host puede enviar y recibir multidifusión IP. El software IP debe permitir a un programa de aplicación especificar una dirección de multidifusión como una dirección IP de destino y el software de interfaz de red debe ser capaz de transformar una dirección de multidifusión en la correspondiente dirección de multidifusión de hardware (o utilizar la difusión si el hardware no soporta la multidifusión). Ampliar el software del host para recibir datagramas de multidifusión es más complejo. El software IP en el host debe tener una interfaz que permita a un programa de aplicación declarar si desea unirse o abandonar un grupo de multidifusión en particular. Si diversos programas de aplicación se unen al mismo grupo, IP debe recordar cada uno de ellos para transferir una copia de los datagramas que llegan destinados para este grupo. Si todos los programas de aplicación abandonan un grupo, el host debe recordar que no quedan participantes en el grupo. Además, el host tiene que correr un protocolo que informe a los routers de multidifusión local del estado de los miembros de un grupo. La complejidad radica en: los hosts se unen a un grupo de multidifusión IP específicos en redes específicas. Esto es, un host con diversas conexiones de red puede unirse a un grupo de multidifusión en una red y no en otra. IGMP – Protocolo de Gestión de Grupos en Internet Para participar en la multidifusión dentro de una red local, un host debe tener el software que le permita enviar y recibir datagramas de multidifusión. Para participar en una multidifusión que cubra varias redes, el host debe informar a los routers de multidifusión local. El router local se pone en contacto con otros routers de multidifusión, pasando información hacia los miembros y estableciendo rutas. Antes de que un router de multidifusión pueda difundir información a los miembros, debe determinar si uno o más hosts de la red local han decidido unirse a un grupo de multidifusión, para esto deben utilizar el protocolo IGMP (Internet Group Management Protocolo) para comunicar información a los miembros del grupo. IGMP utiliza datagramas IP para transportar mensajes y proporciona un servicio utilizado por IP. IGMP tiene dos fases. Fase 1: Cuando un host se une a un nuevo grupo envía un mensaje IGMP para la dirección de multidifusión “todos los hosts”, declarando su membresía. Los routers de multidifusión local reciben el mensaje y establecen el ruteo necesario para difundir la información de membresía del grupo hacia otros routers de multidifusión a través de la red. Fase 2: Debido a que la membresía es dinámica, los routers de multidifusión local muestrean de manera periódica a los hosts en la red local para determinar qué hosts se mantienen como miembros de qué grupos. Si en un grupo no se reportan miembros después de varios muestreos, el router asume que no hay hosts en la red que se mantengan en el grupo y deja de anunciar miembros del grupo a otros routers de multidifusión. 37/70 Teleprocesos y Redes 2 Implementación IGMP IGMP esta diseñado para evitar congestionamientos en la red local. En primer lugar, toda la comunicación entre hosts y routers de multidifusión utilizan multidifusión IP. Esto es, cuando los mensajes IGMP están encapsulados en un datagrama IP para su transmisión, la dirección de IP de destino es la dirección de multidifusión de todos los hosts. Así, los datagramas que transportan mensajes IGMP son transmitidos mediante hardware de multidifusión si éste esta disponible. Como resultado, en las redes en las que el hardware soporta la multidifusión, los anfitriones que no participan en la multidifusión IP nunca reciben mensajes IGMP. En segundo lugar, un router de multidifusión no enviará mensajes de solicitud individuales para cada grupo de multidifusión, sino un mensaje de muestreo para solicitar información relacionada con la membresía en todos los grupos. La cantidad de muestreos está restringida, a lo sumo, una solicitud por minuto. En tercer lugar, los hosts que son miembros de varios grupos no envían respuestas múltiples al mismo tiempo. Por el contrario, luego de que un host recibe un mensaje de solicitud IGMP, el host separa sus respuestas por un lapso aleatorio no mayor a 10 segundos. En cuarto lugar, los hosts escuchan las respuestas de otros hosts y suprimen cualquiera de estas respuestas que sea innecesaria. Esto es porque los routers de multidifusión sólo necesitan saber si al menos un host en la red sigue siendo miembro del grupo. Luego de que un router envia un mensaje de muestreo, todos los hosts asignan un retardo aleatorio para la respuesta. Cuando el host con el retardo más pequeño envía una respuesta (mediante multidifusión), otros hosts participantes reciben una copia. Cada host asume que el router también recibió una copia de la respuesta y cancelan sus respuestas. Así, en la práctica, sólo un host de cada grupo responde a un mensaje de solicitud del router. Transiciones del estado de la Membresía de Grupo: El IGMP debe recordar el estado de cada grupo de multidifusión al que el host pertenece. Cada vez que un programa de aplicación en el host se une a un nuevo grupo, el software IGMP asignará un espacio y lo llenará con información acerca del grupo. Dentro de dicha información, el IGMP establecerá un contador de referencia de grupo, el cual se inicia en 1. Si aplicaciones adicionales se unen al grupo, el IGMP incrementará el contador de referencia. Conforme los programas de aplicación abandonan el grupo, IGMP decrementa el contador. El host deja el grupo de multidifusión cuando el contador llega a cero. Formato del mensaje IGMP VER TYPE SIN USO CHECKSUM DIRECCION DE GRUPO (CERO EN SOLICITUD) VER: Versión del Protocolo. TYPE: Identifica al mensaje como una solicitud enviada por un router de multidifusión (tipo 1) o como una respuesta enviada por un host (tipo 2). CHECKSUM: Contiene la suma de verificación. Se calcula de la misma forma que en IP. DIRECCION DEL GRUPO: Los hosts utilizan este campo para reportar su membresía en un grupo de multidifusión en particular (en una solicitud, este campo contiene ceros y no tiene ningún significado). Asignación de Direcciones de Multidifusión: El estándar no especifica exactamente cómo son asignados los grupos de máquinas a las direcciones de multidifusión, pero una posibilidad es que se forme aleatoriamente hasta descubrir una que no esté en uso. También es posible asignarla manualmente. 38/70 Teleprocesos y Redes 2 Difusión de Información de ruteo: Aun cuando la multidifusión descrita es un estándar para TCP/IP, no existe un estándar para la difusión de información de ruteo entre routers de multidifusión. Sin embargo existe un protocolo experimental llamado Protocolo de Ruteo de Multidifusión Vector Distancia, DVMRP. Los routers de multidifusión utilizan DVMRP para transferir información de membresía entre ellos. Se valen de la información para establecer rutas y, así, entregar la copia de un datagrama de multidifusión a todos los miembros del grupo. Tunneling Uno de los mayores problemas con la multidifusión se debe a que no todos los routers pueden enviar datagramas de multidifusión. Mediante tunneling un routrer puede enviar datagramas de multidifusión a través de routers intermedios que no manejen multidifusión. De hecho, el tunneling consiste en un acuerdo entre dos routers. Cada router escucha en su red local si existen datagramas enviados hacia el grupo de multidifusión para los que el túnel está configurado. Cuando un datagrama de multidifusión llega y la dirección de destino corresponde a la del túnel, se envía el datagrama al otro router empleando una dirección de unidifusión IP convencional. Cuando se recibe un datagrama de unidifusión a través del túnel, se extrae el datagrama de multidifusión y entonces utiliza el hardware de multidifusión para entregar el datagrama a las computadoras de la red local. Para lograr esto, el datagrama de multidifusión, incluyendo el encabezado, viaja dentro de un datagrama de unidifusión convencional. El router receptor extrae y procesa el datagrama como si llegara en una interfaz local. BOOTP y DHCP – Arranque y Autoconfiguración La Necesidad de una Alternativa a RARP RARP tiene 3 inconvenientes: - Dado que RARP opera en un nivel bajo, su uso requiere de un acceso directo hacia el hardware de red. - Aun cuando RARP necesita un intercambio de paquetes entre una máquina cliente y una computadora que responda las solicitudes, la réplica contiene sólo una pequeña parte de la información (la dirección IP del cliente). Esto trae problemas en redes Ethernet dado que se impone un tamaño mínimo de paquete, ya que la información adicional puede enviarse en la respuesta sin costo adicional (piggybacking). - Como RARP emplea una dirección de hardware de computadora para identificar una máquina, no puede utilizarse en redes con una asignación dinámica de direcciones de hardware. BOOTP (BOOT-strap Protocol) Dado que BOOTP utiliza UDP e IP, debe implementarse como un programa de aplicación. Como ARP, BOOTP opera dentro de un paradigma cliente-servidor y requiere solo de un intercambio de paquetes. No obstante BOOTP especifica muchos aspectos necesarios para el arranque además de la dirección IP. Utilización de IP para Determinar una Dirección IP BOOTP se vale del UDP para transportar mensajes y los mensajes UDP están encapsulados en datagramas IP para su entrega. 39/70 Teleprocesos y Redes 2 Para poder enviar un datagrama IP antes de que la computadora conozca su dirección IP, un programa de aplicación puede utilizar la dirección IP de difusión límite (255.255.255.255) para obligar al IP a difundir un datagrama en la red local, antes de que el IP haya descubierto la dirección IP de la red local o la dirección IP de la máquina. Política de Retransmisión BOOTP BOOTP confiere toda la responsabilidad de la confiabilidad de la comunicación al cliente. Sabemos que como UDP utiliza IP para la entrega, los mensajes pueden retrasarse, perderse, entregarse en desorden, etc. Además, como IP no proporciona Checksum sobre los datos, por lo tanto, para protegerse contra las alteraciones de datos, BOOTP requiere que UDP utilice Checksum. También especifica que las solicitudes y las réplicas deben enviarse con el bit de NO FRAGMENT activado a fin de que los clientes tengan una memoria pequeña para reensamblar los datagramas. BOOTP también esta construido para permitir réplicas múltiples, las acepta y procesa primero. Para manejar datagramas perdidos utiliza la técnica convencional de Time Out y Retransmisión. Por supuesto, después de una falla generalizada, todas las máquinas de la red deben arrancar de nuevo de manera simultánea, posiblemente sobrecargando el servidor BOOTP de solicitudes. Para evitar esto implementa un retardo aleatorio de entre 0 y 4 segundos y va duplicando el temporizador después de cada retransmisión hasta un máximo de 60 segundos. OP: Especifica si el mensaje es una solicitud (valor 1) o una replica (valor 2). HTYPE y HLEN: Al igual que en ARP, estos campos especifican el tipo de hardware de red y la longitud de la dirección de hardware. HOPS: El cliente inicializa este campo en 0. Si un servidor recibe la solicitud y por algún motivo decide reenviarla hacia otro servidor, éste incrementara el valor de este campo. TRANSACTION ID: contiene un entero que la máquina sin disco utiliza para cotejar las respuestas con las solicitudes. SECONDS: reporta el número de segundos desde que el cliente comenzó el arranque. CLIENT IP ADDRESS: Un cliente que conozca su dirección IP la colocará en este campo; otros clientes utilizarán cero en este campo. Si la dirección IP del cliente es cero en la solicitud, un servidor devolverá la IP del cliente en el campo YOUR IP ADDRESS. SERVER IP ADDRESS y SERVER HOST NAME: Si un cliente conoce el nombre o la dirección de un servidor específico desde el que espera información, llena estos campos. Si estos campos no son 40/70 Teleprocesos y Redes 2 iguales a cero, sólo el servidor con el nombre-dirección que concuerde responderá la solicitud. Si los campos están puestos en cero, responderá cualquier servidor que reciba la solicitud. BOOT FILE NAME: Contiene un valor genérico, que BOOTP consultará en su base de datos, y especifica que sistema operativo se desea correr. VENDOR SPECIFIC AREA: contiene información opcional del vendedor para su transferencia del servidor al cliente, de información utilizada solo en sus computadoras. Los primeros 4 bytes del campo se llaman MAGIC COOKY y define el formato de los campos siguientes. A continuación de este campo, sigue una lista de términos, en la que cada aspecto contiene un byte TIPO, un byte LONGITUD opcional y varios bytes VALOR. Según el MAGIC COOKY 99.130.83.99 el formato es el siguiente: Procedimiento de Arranque de Dos Pasos No proporciona una imagen de memoria a los clientes, solo proporciona al cliente información necesaria para obtener una imagen. El cliente entonces utiliza un segundo protocolo para obtener la imagen de memoria. Ej: TFTP. Aunque el procedimiento de dos pasos parase innecesario, permite una clara separación de configuración y almacenamiento. La necesidad de una configuración dinámica BOOTP fue diseñado para un ambiente relativamente estático en el que cada host tiene una conexión de red permanente. Un administrador crea un archivo de configuración que especifica un conjunto de parámetros BOOTP para cada host. El archivo no cambia con frecuencia pues la configuración por lo general se mantiene estable. Con la llegada de redes inalámbricas y computadoras portátiles, se ha vuelto posible transportar computadoras de una localidad a otra. BOOTP no se adapta fácilmente, dado que no incluye una forma para asignar dinámicamente valores a máquinas individuales. DHCP (Dynamic Host Configuration Protocol) Para manejar la asignación de direcciones de manera automática, se creó un nuevo protocolo conocido como DHCP, el cual extiende BOOTP de dos formas: Permite que una computadora adquiera toda la información que necesita en un solo mensaje. - Permite que una computadora posea una dirección IP en forma rápida y dinámica. Para utilizar el mecanismo de asignación de direcciones dinámico DHCP, un administrador debe configurar un servidor DHCP suministrando un conjunto de direcciones IP. Cada vez que una computadora nueva se conecta a la red, la computadora contacta al servidor y solicita una dirección. El servidor selecciona una de las direcciones especificadas por el administrador y las asigna a la computadora. - DHCP permite tres tipos de asignación de direcciones; un administrador selecciona cómo responderá el DHCP a cada red o a cada host. - Configuración Manual: mediante el cual un administrador puede configurar una dirección específica para un host específico. 41/70 Teleprocesos y Redes 2 Configuración Automática: de esta forma el administrador permite a un servidor DHCP asignar una dirección permanente cuando una computadora se conecta por primera vez a la red. - Configuración Dinámica Completa: en la cual el servidor “presta” una dirección para un host por un tiempo limitado. El DHCP utiliza la identidad del cliente para decidir cómo proceder. Cuando un cliente conecta un servidor DHCP, envía un identificador, por lo general, la dirección de hardware del cliente. El servidor utiliza el identificador del cliente y la red a la que el cliente se ha conectado para determinar cómo asignar el cliente y la dirección IP. Así, el administrador tiene un control completo sobre la forma en que se asignan las direcciones. Un servidor puede configurarse para asignar direcciones a computadoras específicas de manera estática (como BOOTP), mientras permite a otras computadoras obtener dinámicamente direcciones de manera permanente o temporal. - Asignación Dinámica de Direcciones IP DHCP permite a un host obtener todos los parámetros necesarios para la comunicación, sin la intervención manual, también permite la auto configuración. Esta se encuentra sujeta, por supuesto, a restricciones administrativas. A diferencia de la asignación de direcciones estática, que asigna permanentemente cada dirección IP a host específico, la asignación de direcciones dinámicas es temporal. El servidor DHCP especifica el período de arrendamiento cuando asigna la dirección. Durante ese período el servidor no arrendará la misma dirección a ningún otro cliente. Al final del período de arrendamiento, el cliente debe renovar el arrendamiento o dejar de usar la dirección. Para adaptarse a todos los ambientes, DHCP no especifica un período de arrendamiento fijo y constante. De hecho, el protocolo permite que un cliente solicite un período de arrendamiento específico y permite a un servidor informar al cliente que el período de arrendamiento está garantizado. En el caso extremo, el DHCP reserva un valor infinito para permitir un arrendamiento por un período de tiempo indeterminadamente largo, como si fueran direcciones permanentes. Obtención de Direcciones Múltiples Un host multi-homed está conectado a más de una red, cuando arranca, puede necesitar información de configuración para cada una de sus interfaces. Un mensaje DHCP suele proporcionar información acerca de una interfaz. Una computadora con varias interfaces debe manejar cada interfaz por separado. BOOTP y DHCP utilizan la noción de Relay Agent (Agente Retrasmisión) para permitir que una computadora contacte un servidor en una red no local. Un agente de retransmisión retransmite los mensajes DHCP y BOOTP que se difunden en una de las interfaces físicas a las que está conectado. Formato de los mensajes DHCP DHCP se vale del formato de mensaje BOOTP, pero modifica el contenido y el significado de algunos campos. Casi todos los campos en un mensaje DHCP son idénticos a los de un mensaje BOOTP. De hecho, los dos protocolos son compatibles; un servidor DHCP puede ser programado para responder solicitudes BOOTP. Sin embargo DHCP cambia el significado de dos campos: FLAGS: (Sin uso en BOOTP), de los 16 bits del campo sólo el bit de orden superior tiene asignado un significado. El cliente activa este flag para solicitar que el servidor responda por medio de difusión en lugar de la unidifusión de hardware. Esto se debe a que el datagrama IP que lleva la respuesta tiene en su dirección de destino en su cabecera dirección IP fijada por el servidor DHCP, y la dirección MAC a la dirección hardware del cliente DHCP. Si un host no puede recibir un datagrama IP en unicast hasta saber su propia dirección IP, el bit de broadcast se debe poner a 1 para indicar al servidor que el mensaje DHCPREPLY se debe enviar como un broadcast en IP y MAC. De otro modo, este bit debe ponerse a cero. 42/70 Teleprocesos y Redes 2 OPTION: Este campo tiene el mismo formato que la VENDOR SPECIFIC AREA, asimismo DHCP acepta todos los temas de vendedores específicos definidos para BOOTP. Los primeros cuatro bytes del campo de opciones del mensaje DHCP contienen el magic cookie (99.130.83.99). El resto del campo de opciones consiste en parámetros marcados llamados opciones. El siguiente es el formato de una opción de tipo de mensaje del DHCP utilizado para especificar el mensaje DHCP que se está enviando. La siguiente tabla muestra los posibles valores para el tercer byte y sus significados: 1 Tipo de mensaje DHCP correspondiente DHCPDISCOVER 2 DHCPOFFER 3 DHCPREQUEST 4 DHCPDECLINE 5 DHCPACK 6 DHCPNAK 7 DHCPRELEASE Valor Función Difusión del cliente para localizar los servidores disponibles. Servidor al cliente en respuesta a DHCPDISCOVER con los parámetros de la configuración. Mensaje del cliente a los servidores. El cliente selecciona la configuración de los paquetes recibidos de DHCPOFFER. Lo envía el cliente al servidor cuando detecta un problema con los parámetros en el mensaje DHCPACK y reinicia el proceso de configuración. El servidor confirma el pedido y lo publica masivamente en la subred. El servidor envía al cliente un mensaje indicando que el contrato ha terminado o que la dirección IP asignada no es válida. Cliente al servidor que abandona la dirección de red y que cancela el arriendo restante. Opción Overload: Cuando esta presente esta opción, indica al receptor que debe ignorar el significado de los capos SERVER HOST NAME y BOOT FILE NAME y que debe considerar las opciones que están en lugar de los campos. Estados de Adquisición de Direcciones Cuando un cliente arranca por primera vez, entra en estado INITIALIZE. Para comenzar a adquirir una dirección IP, el cliente primero contacta a todos los servidores DHCP en la red local. Para hacerlo, el cliente difunde un mensaje DHCPDISCOVER y cambia al estado con el nombre SELECT. Todos los servidores DHCP de la red local reciben el mensaje y los servidores que hayan sido programados para responder a un cliente en particular enviarán un mensaje DHCPOFFER. Mientras permanece en estado SELECT, el cliente reúne respuestas DHCPOFFER. Cada oferta contiene información de configuración para el cliente junto con la dirección IP que el servidor ofrece para arrendar al cliente. El cliente debe seleccionar una de las respuestas y negociar con el servidor 43/70 Teleprocesos y Redes 2 un arrendamiento. Para ello, el cliente envía al servidor un mensaje DHCPREQUEST y entra al estado REQUEST. El servidor envía un DHCPACK para enviar un acuse de recibo y comenzar el arrendamiento. Esto hace que el cliente cambie al estado BOUND, en el cual el cliente procede a utilizar la dirección. Un cliente en estado BOUND, puede terminar un arrendamiento en forma temprana, con lo cual envía un mensaje DHCPRELEASE al servidor. Cuando un cliente entra al estado BOUND, éste instala tres temporizadores que controlan la renovación de arrendamiento, la reasignación y la expiración. Un servidor DHCP puede especificar valores explícitos para los temporizadores; si no asigna valores el cliente utilizará valores por omisión. El valor por omisión para el primer temporizador es la mitad del tiempo que tarda el arrendamiento. Cuando el primer temporizador expira, el cliente debe lograr la renovación de su arrendamiento. Para solicitar una renovación, el cliente envía un mensaje DHCPREQUEST hacia el servidor de donde obtuvo el arrendamiento. El cliente entonces cambia al estado RENEW en espera de una respuesta. Como en la negociación inicial de arrendamiento, un cliente puede solicitar un período para la extensión. Un servidor puede responder a una solicitud de renovación de dos formas: puede pedirle al cliente que deje de usar la dirección o aprobar que la continúe utilizando. Si se aprueba esto último, el servidor envía un DHCPHACK, el cual hace que le cliente regrese al estado BOUND y continúe utilizando la dirección. Si un servidor desaprueba que se continúe utilizando la dirección, el servidor enviará un DHCPNACK, el cual hace que el cliente deje de utilizar la dirección inmediatamente y regrese al estado INITIALIZE. Si el cliente no llegase a recibir una respuesta al mensaje que envió, el servidor se considera inactivo o inaccesible. Para manejar esta situación, se utiliza el segundo temporizador. Este temporizador expira luego que se cumple el 87,5% del período de arrendamiento y hace que el cliente pase a estado REBIND. Cuando pasa a este estado comienza a difundir nuevamente un mensaje DHCPREQUEST hacia cualquier servidor local. Cualquier servidor configurado puede responder de manera positiva (para extender el arrendamiento) o negativamente (para evitar que siga usando su IP). Si recibe una respuesta positiva, el cliente vuelve al estado BOUND y reinicializa los temporizadores. Si recibe una respuesta negativa, debe cambiar a estado INITIALIZE, deja de usar su dirección IP y debe adquirir una nueva IP antes de seguir utilizando IP. En el caso de que el cliente no reciba una respuesta de ningún servidor, el arrendamiento expirará. El cliente debe dejar de utilizar su dirección IP, y regresar al estado INITIALIZE y comenzar la adquisición de una dirección IP nueva. 44/70 Teleprocesos y Redes 2 DNS – Domain Name System Espacio de Nombres Plano Cada nombre consistía en una secuencia de caracteres sin ninguna estructura adicional. En el esquema original, una localidad central (NIC) administraba el espacio de nombres y determinaba si un nombre nuevo era apropiado. Ventajas: Los nombres eran convenientes y cortos. Desventajas: El espacio de nombres no podía generalizarse para grandes conjuntos de máquinas por razones técnicas y administrativas. - Como los nombres se construyen desde un solo conjunto de identificadores, la posibilidad de conflicto se incrementa. Dado que la autoridad es centralizada, la sobrecarga de trabajo administrativo se incrementa. Como los nombres cambian con frecuencia, es elevado el costo de mantener copias correctas de las listas correctas en cada localidad. Al estar la base de datos de nombres centralizada, el tráfico de red sobre la misma se incrementaría. Nombres Jerárquicos Consiste en la descentralización del mecanismo de asignación de nombres, mediante el cual se delega la autoridad de partes del espacio de los nombres y se reparte la responsabilidad de la traducción de nombres y direcciones. Características principales - De propósito general: Se puede usar para resolver nombres a cualquier serie de identificadores. Eficiente: La mayoría de los problemas no requieren de mucho tráfico. Distribuido: Información distribuida y Administraciones independientes. Delegar la autoridad para los nombres El espacio de nombres es particionado en el nivel superior y delega la autoridad a cada división. La sintaxis de asignación jerárquica de nombres casi siempre refleja la delegación jerárquica de la autoridad utilizada para asignarlos: local.localidad donde localidad es el nombre de la localidad autorizada por la unidad central, local es la parte del nombre controlado por la localidad. Se utiliza el punto como delimitador de separación. Autoridad para los subconjuntos de nombres En un espacio jerárquico de nombres, la autoridad puede ser subdividida en cada nivel. La idea es conservar subdividido el espacio de nombres hasta que cada subdivisión sea lo suficientemente pequeña como para que se pueda manejar. En una red TCP/IP, la jerarquía de nombres se asigna de acuerdo con la estructura de la organización que obtiene autoridad para dividir el espacio de nombres y no necesariamente de acuerdo con la estructura de las interconexiones de red física. Aunque en muchas localidades la jerarquía organizacional corresponde a la estructura de las interconexiones físicas de la red. 45/70 Teleprocesos y Redes 2 Nombres de dominio TCP/IP de Internet El mecanismo que implementa una jerarquía de nombres de máquina para las redes TCP/IP se conoce como Domain Name System (DNS). El DNS tiene dos aspectos conceptuales diferentes. El primero es abstracto. Especifica la sintaxis del nombre y las reglas para declarar la autoridad respecto a los nombres. El segundo es concreto: Especifica la implementación de un sistema distribuido que transforma eficientemente los nombres en direcciones. caece.edu.ar En el ejemplo, el dominio de nivel inferior es caece.edu.ar, el segundo nivel del dominio es edu.ar, y el nivel superior es ar. Los nombres de dominio están escritos con la etiqueta local primero y el dominio superior al último. Nombres de dominio oficiales y no oficiales de Internet El estándar de nombres especifica un espacio de nombre jerárquico abstracto con valores arbitrarios para las etiquetas. Como el sistema de dominio dicta sólo la forma de los nombres y no sus valores, es posible seleccionar etiquetas arbitrarias para todas las partes de su jerarquía. Sin embargo, la mayoría de los usuarios de tecnología de dominio sigue la jerarquía de etiquetas utilizadas por el sistema de dominio oficial de Internet. Hay dos razones para ello: - El esquema de Internet es completo y flexible. La mayor parte de las localidades respeta el esquema Internet porque de esta manera puede conectar sus instalaciones TCP/IP a la red global sin cambiar nombres. El nombre de nivel superior permite dos jerarquías de nombres completamente diferentes: - Esquema Geográfico (GTLD - Global Top Level Domain): Divide el universo de máquinas por país. Por ejemplo: ar, uy, es… Esquema Institucional/Organizacional (CCTLD - Country Code Top Level Domain): permite a las organizaciones que se agrupen según la función de su organización. Por ejemplo: com, edu, mil, gov… Asociación de nombres de dominio en direcciones Características principales - Distribuido: esto significa que un conjunto de servidores, que opera en varias localidades de manera conjunta, resuelve el problema de la asociación de nombres en direcciones. Eficiente: la mayor parte de los nombres se puede asociar localmente, sólo unos pocos requieren tráfico de red de redes. De propósito general: porque no se encuentra restringido a nombres de máquina. Confiable: dado que una sola falla de una máquina prevendrá al sistema para que opere correctamente. Componentes del DNS - - Servidor DNS (Servidores de Dominio): Sistema independiente y cooperativo. Un servidor DNS es un programa servidor que ofrece la asociación nombre-dirección, asociando los nombres de dominio en direcciones IP. Clientes DNS (Resolver): Utiliza uno o más servidores de nombre cuando traduce un nombre. Zonas de Autoridad: Áreas de nombres de dominio que abarcan al menos un dominio. 46/70 Teleprocesos y Redes 2 La forma más fácil de entender cómo trabaja un servidor de dominio es imaginándolo como una estructura de árbol que corresponde a la jerarquía, como se muestra en la figura siguiente. La raíz del árbol es un servidor que reconoce el dominio de nivel superior y sabe qué servidor resuelve cada dominio. Teniendo un nombre por resolver, la raíz puede resolver el servidor correcto para este nombre. En el siguiente nivel, el conjunto de servidores de nombre proporciona respuestas para un dominio de nivel superior. Un servidor en este nivel sabe qué servidor puede resolver cada uno de los subdominios bajo su dominio. En el tercer nivel del árbol, el servidor de nombres proporciona respuestas para el subdominio. El árbol conceptual continúa con un servidor en cada nivel para el que se ha definido un subdominio. Los enlaces en el árbol conceptual no indican conexiones de red física. De hecho, muestran qué otros servidores conoce y contacta un servidor dado. El servidor por sí mismo puede localizarse en una localidad cualquiera dentro de la red de redes. De esta manera, el árbol de servidores es una abstracción que emplea una red de redes para comunicarse. En la práctica, la relación entre una jerarquía de nombres y el árbol de nombres no resulta tan sencilla como el modelo. Las organizaciones a menudo reúnen información de todos los subdominios desde un solo servidor. Resolución de nombres de dominio El software cliente forma una solicitud de nombres de dominio que contiene el nombre a resolver, una declaración sobre la clase del nombre, el tipo de respuesta deseada y un código que especifica si el servidor de nombres debe traducir el nombre completamente. Se envía la solicitud a un servidor de nombre para su resolución. Cuando un servidor de nombres de dominio recibe una solicitud, verifica si el nombre señala un subdominio sobre el cual tenga autoridad. Si así es, traduce el nombre a una dirección de acuerdo con su base de datos y anexa una respuesta a la solicitud, antes de enviarla de regreso al cliente. Si el servidor de nombre no puede resolver el nombre, verifica qué tipo de interacción especifico el cliente, y en base a eso realiza lo siguiente: - - Resolución Recursiva: El servidor contactará a otro servidor, y en el momento de recibir la respuesta de éste último, copia el mensaje al solicitante, ocultando las respuestas intermedias. Resolución Iterativa: En servidor responderá con la dirección del próximo server de dominio que el cliente deberá contactar, para consultarle por el nombre. 47/70 Teleprocesos y Redes 2 Los clientes deben conocer al menos un Servidor de Dominio local (Normalmente provisto por DHCP). Cada Servidor de Dominio debe conocer por lo menos a un Servidor de nivel superior y a todos los servidores de los dominios jerárquicos inferiores. Desempeño del cache La búsqueda de nombres puede representar una pesada carga para una red de redes. Así, para mejorar el desempeño global de un sistema de servidor de nombres, es necesario reducir los costos de búsqueda para nombres no locales. Los servidores de nombre utilizan una memoria intermedia de nombres (name caching) para optimizar los costos de búsqueda. Cada servidor mantiene una memoria intermedia: - Los nombres y sus direcciones utilizados más recientemente. Un registro de dónde fue obtenida la información para la asociación de nombres. Un TTL para mantener la memoria intermedia con información correcta, suprimiendo las entradas que excedan un tiempo especificado. Cuando un cliente interroga a un servidor a fin de resolver el problema de un nombre, el servidor verifica primero si tiene autoridad para el nombre. Si no es así, el servidor verifica su memoria intermedia para ver si el problema del nombre se resolvió recientemente. Los servidores reportan la información almacenada en memoria intermedia a los clientes, pero la marcan como que no tiene autoridad y entrega el nombre del servidor y su dirección desde la cual obtiene la asignación. De esta manera, los clientes reciben respuestas rápidamente, pero la información podría no estar actualizada. Si la eficiencia es importante, el cliente elegirá aceptar la respuesta sin autoridad y continuar. Si la seguridad es importante, el cliente seleccionará contactar a la autoridad y verificar que la asignación entre el nombre y la dirección siga siendo válida. 48/70 Teleprocesos y Redes 2 TELNET – Acceso Remoto Protocolo TELNET Se utiliza para servicio de terminal remota. TELNET permite al usuario de una localidad interactuar con un sistema de tiempo compartido como si el teclado y el monitor del usuario estuvieran conectados a la máquina remota. TELNET permite a un usuario acceder a una computadora a través de internet. TELNET transfiere las pulsaciones de teclado directamente desde el teclado del usuario a la computadora remota como si hubiesen sido hechos en un teclado unido a la máquina remota. TELNET también transporta la salida de la máquina remota de regreso a la pantalla del usuario. El servicio se llama transparente porque da la impresión de que el teclado y el monitor del usuario están conectados de manera directa a la máquina remota. TELNET ofrece tres servicios básicos: - Terminal Virtual de Red (network virtul terminal - NVT): Proporciona una interfaz estándar para los sistemas remotos. Los programas clientes no tienen que comprender los detalles de todos los sistemas remotos, se construyen para utilizarse con ésta interfaz estándar. - Negociación de Opciones: Telnet incluye un mecanismo que permite al cliente y al servidor negociar opciones, permitiendo a cualquiera de los dos extremos negociar las opciones. Asimismo proporciona un conjunto de opciones estándar. - Simétrico: TELNET trata a ambos lados de la conexión de manera simétrica. En particular, TELNET no fuerza la entrada de cliente para que ésta provenga de un teclado, ni al cliente para que muestre su salida en la pantalla. De esta manera TELNET permite que cualquier programa se convierta en cliente. Como se muestra en la figura, cuando un usuario invoca a TELNET, un programa de aplicación en la máquina del usuario se convierte en el cliente. El cliente establece una conexión TCP con el servidor por medio de la cual se comunicarán. Una vez establecida la conexión, el cliente acepta los pulsos de teclado del usuario y los manda al servidor, al tiempo que acepta caracteres de manera concurrente que el servidor regresa y despliega en la pantalla del usuario. El servidor debe aceptar una conexión TCP del cliente y después transmitir los datos entre la conexión TCP y el sistema operativo local. El servidor debe manejar diversas conexiones concurrentes. Normalmente, un proceso de servidor maestro espera nuevas conexiones y crea nuevos esclavos para manejar cada conexión. Utilizamos el término pseudo terminal para describir el punto de entrada del sistema operativo que permite que un programa, que se está corriendo como el servidor TELNET, transfiera caracteres al sistema operativo como si vinieran de un teclado. Al ser TELNET un programa de nivel de aplicación tiene sus ventajas y desventajas: 49/70 Teleprocesos y Redes 2 Ventaja: hace la modificación y el control del servidor más fácil que si el código estuviera embebido en el sistema operativo. Desventaja: su ineficiencia. Esto se debe a que cada pulso del teclado viaja a través de la red hacia el servidor. Después de llegar a su máquina destino, la salida (si es que el eco de caracteres remotos esta activado) viaja de regreso al cliente. Adaptarse a la heterogeneidad Para hacer que TELNET interopere entre tantos sistemas operativos como sea posible, debe adaptarse a las distintas computadoras y sistemas operativos existentes. Para adaptar la heterogeneidad, TELNET define cómo deben mandarse las secuencias de datos y comandos a través de Internet. La definición se conoce como NVT (teminal virtual de red). El software cliente traduce las pulsaciones de teclado y las secuencias de comandos que vienen de la terminal del usuario a formato NVT y las envía al servidor. El software del servidor traduce los datos y comandos que acaban de llegar de formato NVT al formato que el sistema requiera. Para devolver los datos, el servidor traduce a NVT y el cliente los traduce al formato de la máquina local. Transferencia de Comandos que Controlan el Extremo Remoto Para transferir las funciones de control a través de la conexión TCP, TELNET las codifica mediante la secuencia de escape. Una secuencia de escape se vale de un byte reservado para indicar que a continuación sigue un byte de código de control. En TELNET, el byte reservado que inicia una secuencia de escape se conoce como el byte Interpret As Command (IAC). A continuación se listan los comandos posibles: - Comando Significado - IAC DON’T DO WON’T WILL SB GA EL EC AYT AO IP BRK DMARK - - NOP SE EOR SYNCH - Se interpreta al siguiente byte como comando. Negación de petición para ejecutar una operación especificada. Aprobación para permitir una opción especificada. Rechazo de ejecución de una operación especificada. Autorización de realizar una operación especificada. Inicio de subnegociación de opción. Señal de Go Ahead. Continuar Señal de Erase Line. Borra toda la línea actual. Señal de Erase Character. Borra carácter previo. Señal de Are You There. Estás ahí. Prueba si el servidor responde. Señal de Abort Output. Salida Abortada. Se descarta cualquier salida de búfer. Señal de Interrupt Process Interrupción de proceso. Termina de ejecutarse el programa. Señal de Breack. Tecla de pausa o señal de atención. La porción de datos de un SYNCH (siempre acompañada de una notificación de urgente del TCP) Sin operación. Fin de operación de subnegociación. Fin de registro. (Synchronize) Sincroniza. Elimina los datos hasta que el puntero de datos urgente, pero no interpreta comandos. 50/70 Teleprocesos y Redes 2 Forzar al servidor a leer una función de control El envío de funciones de control junto con datos normales no siempre es suficiente para garantizar los resultados deseados. TELNET no puede confiarse del flujo de datos convencional por sí sola para transportar secuencias de control entre el cliente y el servidor. Pues una aplicación que se conduce mal necesita estar controlada ya que se podría bloquear de manera inadvertida el flujo de datos. Para resolver el problema, TELNET utiliza una señal fuera de banda. El TCP implementó señalización fura de banda con el mecanismo de dato urgente. Dondequiera que se coloque una función de control en una corriente de datos, TELNET también mandará un comando SYNCH. TELNET después anexará un byte reservado, llamado marca de datos y hará que TCP emita una señal hacia el servidor enviando un segmento con el conjunto de bits de URGEN DATA. Los segmentos que llevan los datos urgentes evitan el control de flujo y llegan de inmediato al servidor. En respuesta a una señal de urgente, el servidor lee y descarta todos los datos hasta que encuentra la marca de datos. El servidor regresa a su procesamiento normal cuando encuentra esta marca. Opciones de TELNET En TELNET, las opciones son negociables, lo que hace posible reconfigurar su conexión para el cliente y el servidor. El rango de opciones es amplio: algunos extienden las capacidades de manera significativa mientras que otros tratan con los detalles menores. Una de las opciones controla si TELNET opera en modo half-duplex o full-duplex. Otra de las opciones permite que el servidor, en una máquina remota, determine el tipo de terminal de usuario. El tipo de terminal es importante para las secuencias de posicionamiento del cursor. Negociación de opciones de TELNET Como en algunas opciones tiene sentido para el server iniciar una operación en particular, el protocolo está diseñado para permitir o dejar de hacer una petición. De este modo, se dice que el protocolo es simétrico con respecto al procesamiento de opciones. El extremo de recepción puede responder a una petición con una aceptación positiva o un rechazo. La petición es WILL X, que significa “estarías de acuerdo en dejarme usar la opción X”; y la respuesta podría ser DO X o DON’T X, que significa “estoy de acuerdo en dejarte usar la opción X” o “no estoy de acuerdo en dejarte usar la opción X”. La simetría surge porque DO X pide que la parte receptora comience a utilizar la opción X, y WILL X o WON’T X significa “comenzaré a utilizar la opción X” o “no comenzaré a utilizar la opción X”. TELNET utiliza un mecanismo de negociación de opciones simétrica para permitir a los clientes y a los servidores reconfigurar los parámetros que controlan su interacción. Como el software TELNET comprende un protocolo NVT básico, los clientes y los servidores pueden interoperar aun cuando uno comprenda las opciones y el otro no. FTP - PROTOCOLO DE TRANSFERENCIA DE ARCHIVOS Los objetivos del FTP son: 1) Promocionar el uso compartido de ficheros. 2) Animar al uso indirecto o implícito (a través de programas) de servidores remotos. 3) Hacer transparente al usuario las variaciones entre la forma de almacenar ficheros en diferentes ordenadores. 4) Transferir datos fiable y eficientemente. El FTP, aunque puede ser utilizado directamente por un usuario en un terminal, está diseñado principalmente para ser usado por programas. 51/70 Teleprocesos y Redes 2 TERMINOLOGIA Conexión de datos: Una conexión bidireccional sobre la que se transfieren los datos (parte de un fichero, un fichero entero o un cierto número de ficheros). La conexión se puede establecer entre un server-DTP y un user-DTP o entre dos server-DTP's. DTP (Data Transfer Process): Establece y maneja la conexión de datos. Puede ser activo o pasivo. PI (Protocol Interpreter): El Intérprete del Protocolo. La parte del usuario y del servidor del protocolo tienen distintos papeles que se implementan como un user-PI y un server-PI. Server-DTP (server Data Transfer Process): En su estado normal de "activo", establece una conexión de datos con el puerto de datos que está a la espera. Prepara los parámetros para transferir y almacenar y transfiere los datos cuando así se requiere a través de su PI. El DTP se puede poner en estado "pasivo" para esperar una conexión, en lugar de iniciarla. Server-PI (server Protocol Interpreter): "Escucha" en el puerto determinado hasta que recibe una conexión de un user-PI y establece una conexión de comunicaciones para control. Recibe órdenes FTP estándar desde el user-PI, envía respuestas y controla el server-DTP. User-DTP (user Data Transfer Process): Espera a recibir una conexión en el puerto de datos desde el proceso server-FTP. Si dos servidores están transfiriendo datos entre ellos, el user-DTP permanece inactivo. User-PI (user Protocol Interpreter): El intérprete de protocolo de usuario inicia la conexión de control desde su puerto U hasta el proceso server-FTP, envía órdenes FTP y controla el user-DTP si es necesario para la transferencia de ficheros. EL MODELO FTP El siguiente modelo representa un diagrama de un servicio FTP. Figura 1: Modelo para el uso del FTP. NOTAS: a. La conexión de datos es bidireccional. b. La conexión de datos no tiene por qué existir todo el tiempo. En el modelo descrito en la Figura 1, el user-PI, inicia la conexión de control, la cual se usará para el intercambio de órdenes y respuestas, esta conexión sigue el Protocolo Telnet. Las órdenes FTP especifican parámetros para la conexión de datos (puerto de datos, modo de transferencia, tipo de representación y estructura) y la naturaleza de la operación sobre el sistema de ficheros (almacenar, recuperar, añadir, borrar, etc.). 52/70 Teleprocesos y Redes 2 En otra situación, un usuario puede querer transferir ficheros entre dos ordenadores que no son locales. El usuario prepara las conexiones de control con los dos servidores y da las órdenes necesarias para crear una conexión de datos entre ellos. De esta forma, la información de control se envía al user-PI pero los datos se transfieren entre los procesos de transferencia de datos de los servidores. Figura 2 El protocolo requiere que las conexiones de control permanezcan abiertas mientras se transfieren datos. Es responsabilidad del usuario solicitar el cierre de las conexiones de control una vez termine de usar el servicio, mientras que el servidor es el encargado de cerrarlas. El servidor puede interrumpir la transferencia de datos si las conexiones de control se cierran sin previa solicitud. 3. FUNCIONES DE TRANSFERENCIA DE DATOS Los ficheros sólo se transmiten por la conexión de datos. La conexión de control se usa para enviar órdenes, que describen la función a realizar, y las repuestas a estas órdenes. Representación de Datos y Almacenamiento A menudo es necesario realizar ciertas transformaciones en los datos porque la representación de los datos almacenados varía de un ordenador a otro. Tipos de Datos: El usuario especifica las representaciones de datos que se manejarán en el FTP. - Tipo ASCII: Este es el tipo por omisión. Su principal propósito es transferir ficheros de texto. - Tipo EBCDIC: El propósito de este tipo es la transferencia eficaz entre ordenadores que usan EBCDIC como su representación de carácter interna. - Tipo IMAGEN: El tipo imagen está indicado para el almacenamiento y obtención de ficheros y la transferencia de datos binarios. - Tipo LOCAL Control de Formato: Los tipos ASCII y EBCDIC llevan un segundo parámetro (opcional); este es para indicar qué tipo de control de formato vertical. Los tipos son: - NO PARA IMPRIMIR [NON PRINT]: Este es el formato por omisión. - CONTROLES DE FORMATO TELNET: El fichero contiene controles de formato vertical ASCII/EBCDIC que el proceso para imprimir interpretará apropiadamente. - CONTROL DE CARRO (ASA): El fichero contiene caracteres de control de formato vertical ASA (FORTRAN). 53/70 Teleprocesos y Redes 2 Estructura de Datos Se definen tres estructuras de fichero en el FTP: - Estructura de fichero: donde no hay una estructura interna y el fichero se considera como una secuencia continua de bytes de datos. - Estructura de registro: donde el fichero está compuesto de registros secuenciales. - Estructura de página: donde el fichero está compuesto de páginas indizadas independientes. CONEXIONES Modos de conexión del cliente FTP FTP admite dos modos de conexión del cliente. Estos modos se denominan Activo (o Estándar, o PORT, debido a que el cliente envía comandos tipo PORT al servidor por el canal de control al establecer la conexión) y Pasivo (o PASV, porque en este caso envía comandos tipo PASV). Tanto en el modo Activo como en el modo Pasivo, el cliente establece una conexión con el servidor mediante el puerto 21, que establece el canal de control. Modo Activo En modo Activo, el servidor siempre crea el canal de datos en su puerto 20, mientras que en el lado del cliente el canal de datos se asocia a un puerto aleatorio mayor que el 1024. Para ello, el cliente manda un comando PORT al servidor por el canal de control indicándole ese número de puerto, de manera que el servidor pueda abrirle una conexión de datos por donde se transferirán los archivos y los listados, en el puerto especificado. Lo anterior tiene un grave problema de seguridad, y es que la máquina cliente debe estar dispuesta a aceptar cualquier conexión de entrada en un puerto superior al 1024, con los problemas que ello implica si se tiene el equipo conectado a una red insegura como Internet. De hecho, los cortafuegos que se instalen en el equipo para evitar ataques seguramente rechazarán esas conexiones aleatorias. Para solucionar esto se desarrolló el modo Pasivo. Modo Pasivo Cuando el cliente envía un comando PASV sobre el canal de control, el servidor FTP abre un puerto efímero (cualquiera entre el 1024 y el 5000) e informa de ello al cliente FTP para que, de esta manera, sea el cliente quien conecte con ese puerto del servidor y así no sea necesario aceptar conexiones aleatorias inseguras para realizar la transferencia de datos. 54/70 Teleprocesos y Redes 2 Antes de cada nueva transferencia, tanto en el modo Activo como en el Pasivo, el cliente debe enviar otra vez un comando de control (PORT o PASV, según el modo en el que haya conectado), y el servidor recibirá esa conexión de datos en un nuevo puerto aleatorio (si está en modo pasivo) o por el puerto 20 (si está en modo activo). 3.4. MODOS DE TRANSMISION Se definen los siguientes modos de transmisión en el FTP: - Modo Flujo: Los datos se transmiten como un flujo de bytes. No hay ninguna restricción en el tipo de representación usado. - Modo Bloque: El fichero se transmite como una serie de bloques de datos precedidos por uno o más bytes de cabecera. Los bytes de la cabecera contienen un campo contador y un código descriptor. El campo contador indica la longitud total del bloque de datos en bytes, indicando así el inicio del siguiente bloque de datos (no hay bits de relleno). El código descriptor define: último bloque del fichero. - Modo Comprimido: Hay tres clases de información a enviar: datos normales, enviados en una cadena de bytes; datos comprimidos, formados por repeticiones o relleno. 3.5. RECUPERACION DE ERRORES Y REINICIO No hay nada que detecte bits perdidos o alterados en las transmisiones de datos; esto lo maneja el TCP. Sin embargo, se proporciona un medio para recomenzar transferencia para proteger a los usuarios de fallos graves en el sistema. Sólo está definido el procedimiento de reinicio para los modos de transferencia de bloque y comprimido. Requiere que el que envía datos inserte un código marcador especial en el flujo de datos con información que indique por dónde vamos. El receptor de los datos, si implementa el procedimiento de reinicio, debería guardar la correspondiente posición de este marcador en el sistema receptor y devolver esta información al usuario. En el caso de un fallo del sistema, el usuario puede reiniciar la transferencia de datos identificando el último marcador recibido con el procedimiento de recomenzar del FTP. 55/70 Teleprocesos y Redes 2 ORDENES FTP Ordenes de Control de Acceso - USER: Recibe el nombre de usuario que lo identifica en el sistema. Es requerido para acceder al sistema de archivos del servidor. - PASS: Especifica el password del usuario. Este comando siempre es precedido por USER. - ACCT: Un string Telnet con el nombre de la cuenta constituye el argumento de este comando. - CWD: Permite al usuario cambiar de directorio de trabajo sin alterar su estadía en el sistema. - CDUP: Caso particular del anterior. Sirve para cambiar al directorio raíz desde cualquier ubicación. - SMNT: Sirve para montar un sistema de archivos distinto sin alterar la estadía del usuario. - REIN: Reinicializa el sistema para el ingreso de un nuevo usuario. - QUIT: Permite cerrar la sesión de un cliente o usuario. Ordenes de Parámetros de Transferencia - PORT: Especifica el puerto de la conexión de datos. - PASV: Comando que hace una petición al DTP de servidor para que “escuche” en un puerto (no el por defecto) para la conexión de datos. - TYPE: Especifica el tipo de representación de los datos (ASCII, EBCDIC, Image, Local). - STRU: Especifica la estructura de archivo (File, Record structure, Page structure) - MODE: Especifica el modo de transmisión de los datos (Stream, Bloque o Comprimida). Ordenes de Servicio FTP - RETR: Comando que da la orden al DTP de servidor para que transfiera una copia del archivo al DTP de usuario. - STOR: Da la orden para que el DTP de servidor acepte el archivo transferido hacia el lado servidor y lo guarde. - STOU: Caso particular del comando anterior donde el archivo queda en un directorio con nombre único. - APPE: Ordena al DTP de servidor aceptar un archivo y si este existiese, adjunta la información a dicho archivo antiguo. - ALLO: Este comando permite reservar un espacio en disco duro en el servidor para un posible archivo. - REST: Reinicia la transferencia de un archivo indicando el marcador del servidor. - RNFR: Este comando especifica el nombre antiguo de un directorio que será renombrado. - RNTO: Especifica el nombre nuevo de un directorio que será renombrado. - ABOR: Aborta el comando ingresado previamente. - DELE: Elimina el archivo especificado en el lado del servidor. - RMD: Remueve un directorio completo. - MKD: Crea un directorio nuevo. - PWD: Este comando hace que el nombre del directorio de trabajo sea retornado en una respuesta. - LIST: Comando que provoca el envió de una lista de archivos desde el servidor al DTP. - NLST: Envía una lista de directorios desde el servidor hacia el usuario. - SITE: Comando que sirve para que el servidor provea servicios más específicos. - SIST: Comando que sirve para identificar el sistema operativo del servidor. 56/70 Teleprocesos y Redes 2 - STAT: Causa el envió de una respuesta de status de las operaciones en desarrollo. HELP: Entrega información acerca de cualquiera de los comandos y su sintaxis. NOV: Sirve para recibir una respuesta de OK del servidor. No altera otros parámetros. RESPUESTAS FTP Las respuestas a órdenes del FTP están pensadas para asegurar la sincronización entre peticiones y acciones en el proceso de transferencia de ficheros y para garantizar que el proceso de usuario siempre conoce el estado del servidor. Cada orden debe generar por lo menos una respuesta. Una respuesta FTP consiste en un número de tres cifras seguidas de texto. Hay cinco valores para el primer dígito del código de respuesta: - 1XX: El comando fue aceptado pero se debe esperar una segunda respuesta para ingresar nuevo comando. 2XX: El comando fue aceptado y la acción se llevó a cabo con éxito. Se puede ingresar uno nuevo. 3XX: El comando fue aceptado pero se necesita el ingreso de otro comando especificando información requerida. 4XX: El comando fue rechazado y la acción requerida no se efectuó, pero el error es temporal y la acción podría ser solicitada de nuevo. 5XX: Comando no aceptado y acción no efectuada. 57/70 Teleprocesos y Redes 2 TFTP – Trivial File Tranfer Protocol Este protocolo se diseño para aplicaciones que no necesitan interacciones complejas entre cliente y servidor. Restringe las operaciones a transferencia de archivos sencillas y no proporciona autenticación. El TFTP corre bajo UDP y utiliza time-out y retransmisión para asegurar que los datos lleguen. El lado que envía transmite un bloque y espera un acuse de recibo para cada bloque antes de enviar el siguiente. El receptor envía un acuse de recibo por cada bloque cuando le llega. Las reglas del TFTP son sencillas. El primer paquete enviado requiere de una transferencia de archivo y establece la interacción entre cliente y servidor, especifica el nombre del archivo y si se lee o escribe. Los bloques de archivos están numerados secuencialmente comenzando en 1, el cual figura en el encabezado del bloque que se transporta. A su vez cada acuse de recibo contiene el número del bloque al que corresponde. Un bloque de menos de 512 bytes señala el final del archivo. Es posible enviar mensajes de error. Normalmente los mensajes de error terminan con la transferencia. La figura anterior muestra el formato de cinco tipos de paquetes TFTP. El paquete inicial debe utilizar códigos de operación 1 o 2, según se trate de una petición de lectura o escritura. Una vez enviado el paquete inicial, el servidor utiliza la dirección IP y el número de puerto de protocolo UDP del cliente para identificar las operaciones subsiguientes. De este modo, ni los mensajes de datos ni los mensajes de ACK necesitan especificar el nombre del archivo. La retransmisión de TFTP es simétrica. Cada lado implementa time-out y retransmisión. Si el emisor llega a un time-out, vuelve a retransmitir el último bloque de datos. Si el receptor llega a un time-out vuelve a transmitir el último acuse de recibo. Tener a ambas partes participando en la transmisión ayuda a asegurar que no falle la transferencia después de que se haya perdido un paquete. Este tipo de retransmisión simétrica puede conducir a retransmisiones excesivas. Este problema se conoce como Falla del Aprendiz de Brujo, y surge cuando un acuse de recibo para un paquete k se demora pero no se pierde. El emisor vuelve a transmitir el paquete de datos para el cual el receptor emite un acuse de recibo. Ambos acuses de recibo llegan en algún momento y cada uno dispara una transmisión del paquete k+1. El receptor emite un acuse de recibo para ambas copias del paquete k+1, y los dos acuses de recibo causan que el emisor transmita el paquete de datos k+2. 58/70 Teleprocesos y Redes 2 SMTP - Protocolo Simple de Transmisión de Correo Este protocolo es el estándar de Internet para el intercambio de correo electrónico. SMTP utiliza los servicios de TCP. Para que dos sistemas intercambien correo mediante el protocolo SMTP, no es necesario que exista una conexión interactiva, ya que este protocolo usa métodos de almacenamiento y reenvío de mensajes. Modo de Comunicación SMTP Cuando un servidor de SMTP, requiere transmitir un mensaje a otro servidor SMTP, el emisor (servidor que inicia la sesión SMTP) establece una conexión con el receptor (servidor que recibe petición de establecer sesión SMTP). Esta conexión es unidireccional, es decir, el emisor puede enviar correo al receptor, pero durante esa conexión, el receptor no puede enviar correo al emisor. Si el receptor tiene que enviar correo al emisor, tiene que esperar a que finalice la conexión establecida y establecer otra en sentido contrario, cambiando los papeles de emisor y receptor. Una vez establecida la conexión, el emisor envía comandos y mensajes. Los mensajes pueden tener como destino el receptor o un intermediario para llegar a un destino más lejano. El receptor puede enviar al emisor respuestas y códigos de estado. Los comandos son cadenas de caracteres que se pueden entender fácilmente y las respuestas son códigos numéricos seguidos de una explicación del código. Por lo señalado, SMTP (RFC 821) está basado en entrega "end-to-end". Esto es diferente del principio guardar y enviar común en muchos sistemas de mensajería electrónica, donde el mensaje puede pasar a través de un numero de maquinas intermediarias su camino al destino final. Existen aplicaciones que permiten intercambiar correo entre SMTP y el sistema de correo localmente usado. Estas aplicaciones son llamadas "Gateways" de correo o "Bridges" de correo. Enviar correo a través de un "Gateway" puede alterar la entrega "end-to-end". El protocolo SMTP solo puede garantizar la entrega al "Gateway" y no al destino final que está localizado más allá de la red TCP/IP. Cuando el "Gateway" es usado, la transmisión SMTP "end-to-end" se realiza en varias partes, de "host" a "Gateway", "Gateway" a "host" o "Gateway" a "Gateway". El comportamiento más allá del "Gateway" no está especificado por SMTP. En la Fig. 2-1 se observa la comunicación a través de los "Gateways". SMTP se basa en el modelo de comunicación que se muestra en la Fig. 2-2. 59/70 Teleprocesos y Redes 2 En este modelo de comunicación en primera instancia un usuario establece la petición de enviar un mensaje a través de correo electrónico, luego el Emisor SMTP establece una conexión de dos hilos con el Receptor SMTP. El Receptor SMTP puede ser la destinación última o un intermediario, como es el caso del "Gateway". El Emisor SMTP genera comandos que son contestados por el Receptor SMTP. Comandos SMTP HELO: Se utiliza para identificar el Remitente-SMTP al Receptor SMTP. EHLO: HELO Extendido (RFC 2821). MAIL: Este comando se utiliza para iniciar una transacción de correo en la cual el correo se entrega a uno o más buzones de correo. DATA: Agrega líneas de datos al buffer de datos del correo. SEND: Se usa para iniciar una transacción de mail en el cual el mail es entregado a una o más terminales. SOML (SEND OR MAIL): Inicializa una transacción de mail en el cual el mail es entregado a una o más terminales o buzones de correo. SAML (SEND AND MAIL): Inicializa una transacción de mail en el cual el mail es entregado a una o más terminales y buzones de correo. RSET (RESET): Aborta la transacción de mail actual. VRFY (VERIFY): Solicita al receptor confirmar el argumento que identifica a un usuario. EXPN (EXPAND): Solicita al receptor confirmar el argumento que identifica una lista de correo, y si es así, regresar a la composición de dicha lista. HELP: El receptor envía información de ayuda al remitente. NOOP: Este comando no afecta ningún parámetro ingresado previamente. QUIT: El receptor debe enviar una respuesta de OK, y a continuación, cerrar el canal de transmisión. TURN: Este comando especifica que el receptor SMTP y el remitente SMTP intercambien roles. Flujo de Transferencia de los Mensajes de Correo Electrónico Aunque los comandos y respuestas son estrictamente definidos por el protocolo, el intercambio de ellos entre emisor y receptor resultar fácil de comprender. El ejemplo de trasferencia se detalla a continuación: 60/70 Teleprocesos y Redes 2 · El Emisor SMTP establece una conexión TCP con el destino SMTP y luego espera que el servidor envíe un 220 Servicio de lectura de mensaje o un 421 Servicio de mensaje no habilitado, esto último, cuando la destinación está temporalmente inhabilitada para procesar el mensaje. · HELO es enviado para que el receptor identifique si el Emisor SMTP está enviando su nombre de dominio. El Emisor SMTP puede usarlo para verificar si contactó la destinación SMTP correcta. Si el Emisor SMTP soporta Extensión de Servicios ("Service Extensions") SMTP, puede sustituir por un comando EHELO el comando HELO. El Receptor SMTP que no soporta Extensión de Servicios, responde con una sintaxis de error 500, que es un comando de mensaje no reconocido. El Emisor SMTP debe entonces reintentar con HELO, o si el emisor no puede transmitir el mensaje sin uno o más de los comandos que son propios de Extensión de Servicios, éste debe enviar un mensaje QUIT. · Si el Receptor SMTP soporta Extensión de Servicios, responde con un mensaje multilínea 250 OK, que incluye una lista de extensión de servicios que soporta. · El Emisor SMTP, luego de recibir este comando 250 OK, inicializa la transferencia del mensaje enviando el comando MAIL al Receptor SMTP. Este comando contiene el "reverse-path" (habitualmente se utiliza para el envío del nombre de dominio del emisor) que puede ser usado para reportar errores. Esta "reverse-path" puede contener más que solamente el nombre de dominio de usuario (del emisor), en adición, éste puede contener una lista de "host" de la ruta. Ejemplo de esto es cuando se pasa por un "Bridge" o cuando se provee explícitamente información de la ruta en la dirección de destino. Si el Receptor SMTP acepta responde con un 250 OK. · El segundo paso del intercambio de mensajes a través de correo electrónico, consiste en proveer al servidor SMTP la destinación para el mensaje. Se realiza enviando uno o más comandos RCPT TO: forward-path. Cada uno de estos envíos es contestado por parte del Receptor SMTP con un 250 OK, si la destinación es conocida por el servidor, o un 550 NO, si tal usuario no es conocido. · Cuando todos los comandos RCPT son enviados, el Emisor SMTP emite un comando DATA para notificar al Receptor SMTP que el contenido del mensaje será el siguiente envío. El Receptor SMTP responde con 354 Start mail input, end with CRLF CRLF. Esta secuencia final es la que el Emisor SMTP utiliza cuando termina el envío de datos del mensaje a transferir. · El cliente ahora envía las líneas de datos, una a una, finalizando con la secuencia CRLF.CRLF, secuencia que el Receptor SMTP responde con un 250 OK o un mensaje de error si es que algo ha fallado. · Luego se tienen algunas opciones: - El Emisor SMTP no tiene más mensajes que enviar, por lo que se finaliza la conexión con un comando QUIT, a lo cual el Receptor SMTP responde con 221 Service closing transmission channel. - Si el Emisor SMTP no tiene más mensaje es que enviar, pero quiere recibir mensajes del otro extremo. Este envía el comando TURN. Los dos extremos de la comunicación SMTP ahora cambian roles de Emisor/Receptor y el nuevo Emisor SMTP (Anterior Receptor SMTP) puede enviar mensajes partiendo del paso 3 del esquema mostrado en la Fig. 2-3. - Si el Emisor SMTP tiene otro mensaje para enviar retorna al paso 3 y envía un comando MAIL. 61/70 Teleprocesos y Redes 2 PROTOCOLO MIME - Extensión de Correo de Internet Multipropósito SMTP tradicional es adecuado para la transmisión de mensajes de texto en inglés, pero es inadecuado para texto en otro idioma o para datos no textuales. Uno de los métodos para superar estas limitaciones es el protocolo MIME. Este protocolo, especifica un mecanismo para codificar texto y datos binarios en 7-bit ASCII. MIME y Extensión de servicios SMTP son cercanos y complementarios más que estándares excluyentes. Desde el estándar MIME, se permiten mensajes para ser declarados como consistentes de datos de 8-bit más que de datos de 7-bit, debido a que los mensajes no pueden ser transmitidos por agentes SMTP que estrictamente se ajusten a RFC 821(especifica ASCII de 7-bit). Cuando un cliente SMTP intenta enviar datos de 8 bits a un servidor que no soporta esa extensión, el cliente SMTP debe codificar el contenido del mensaje a una representación de 7 bits o retornara un error permanente del servidor. MIME redefine el formato de mensajes para permitir cuerpos de mensajes textuales y no textuales con un conjunto de caracteres diferentes a EE.UU.-ASCII de 7 bits. El protocolo MIME surge por la incapacidad que tiene SMTP para representar todos los datos que se desean transmitir a través de correo electrónico. Desde un principio SMTP define el formato normal de mensajes textuales en Internet (define sintaxis de cuerpo y cabecera). Su éxito ha sido tal que se utiliza más allá de los límites de Internet. Cuando el formato se ha usado en forma más extensa, se ha observado un aumento de las limitaciones para la comunidad de usuarios, dado que no se considera mensajes multimediales que incluyan audio o imágenes. Incluso, en el caso de texto, cuyos idiomas requieren el uso de un conjunto de caracteres más rico. Dada estas limitaciones, se necesitan las características técnicas adicionales que proporciona MIME. Una de las limitaciones notables de SMTP es que limita la longitud del mensaje de correo electrónicos a líneas relativamente cortas (Ej. 1000 caracteres o menos). Esto obliga a los usuarios a convertir cualquier dato no textual a la representación de caracteres de bytes de 7-bits EE.UU.-ASCII antes de invocar un UA (Agente del Usuario, un programa con el que los usuarios humanos envían y reciben correo). Mensajes Multiparte: Un mensaje MIME multiparte contiene una frontera en el encabezado; esta frontera, que no puede aparecer en ninguna de las partes, es ubicada entre cada una de ellas, y al inicio y al final del cuerpo del mensaje. Cada parte consiste de su propio encabezado de contenido y un cuerpo. El contenido multiparte puede estar anidado. Subtipos de Multiparte El estándar MIME define varios subtipos para mensajes multiparte, estos especifican la naturaleza de la parte del mensaje y su relación con otras partes. El subtipo es especificado en el encabezado para todo el mensaje. Lo que sigue es una lista de los subtipos más comúnmente usados: Mixed: es usado para enviar mensajes o archivos con diferentes encabezados ya sea en línea o como adjuntos. Si se envían imágenes u otros archivos fácilmente legibles, la mayoría de los clientes de correo electrónico las mostrarán como parte del mensaje. De otra manera serán ofrecidos como adjuntos. Digest: es una forma simple de enviar múltiples mensajes de texto. Alternative: indica que cada parte es una versión "alternativa" del mismo contenido (o similar), cada una en formatos diferentes denotados por su encabezado. Los formatos son ordenados atendiendo a cuan fieles son al original, con el menos fiel al inicio. Los sistemas pueden escoger la "mejor" representación que ellos son capaces de procesar; en general esta será la última parte que el sistema entiende, a menos que otros factores puedan afectar este comportamiento. Parallel: es similar a Mixed, pero con una representación en paralelo. 62/70 Teleprocesos y Redes 2 POP - Protocolo de Oficina de Correos El protocolo SMTP, aparece cuando la red Internet no estaba en auge. El protocolo SMTP surgió cuando los usuarios tenían cuentas en computadores que estaban continuamente conectados a Internet, de tal forma que cuando un usuario quería leer su correo, entraba en una sesión de terminal y solicitaba al servidor el mensaje que tenía almacenado para él. Esta situación ha cambiado considerablemente, hoy en día, los usuarios se conectan al servidor de correo por un período de tiempo muy breve, el suficiente para solicitar el envío del correo mediante un programa cliente. Por tanto, el servidor de correo electrónico debe mantener almacenado el correo en sus casillas y enviarlo a los clientes cuando se conecten y lo soliciten. Este es el objetivo para el cual se creó el protocolo POP. En la actualidad, se utiliza el protocolo SMTP para el envío de correo y para la recepción de correo se utiliza el protocolo POP, el cual, ya está en su tercera versión desde su aparición (POP3). Modelo de Comunicación POP El modelo de comunicaciones POP se basa en el concepto de buzón, que posee un espacio para almacenar los mensajes de correo hasta que se solicite la descarga de estos mensajes. El cliente POP se conecta con el servidor a través del puerto TCP, 110. Para conectarse al servidor, es necesario una cuenta de identificación en dicha máquina (lo que le permite tener un espacio reservado para sus correos). A continuación es necesario verificar que es dueño de la cuenta a través de una clave. Una vez conectado al sistema, el cliente POP puede dialogar con el servidor para saber, entre otras cosas, si existen mensajes en la casilla, cuántos mensajes son o para solicitar la descarga de alguno de ellos. Para poder ofrecer estas funciones, el modelo de comunicación POP se basa en estados. Estos son estado de autorización, estado de transacción y estado de actualización. Después de establecer la conexión, el servidor POP se encuentra en un estado de autorización, esperando que el cliente le envíe el nombre y clave de la cuenta de usuario. Cuando se verifica que son correctos, el servidor pasa a un estado de transacción. Antes de pasar a este estado, el servidor POP bloquea el buzón para impedir que los usuarios modifiquen o borren el correo antes de pasar al estado siguiente. En este estado de transacción el servidor atiende las peticiones del cliente. Después de enviar al servidor el comando QUIT el servidor pasa al estado de actualización. En este estado el servidor elimina los mensajes que están con la marca de borrado y finaliza la conexión. Comandos POP El diálogo desde el cliente al servidor, se basa en el envío de comandos, a los que el servidor responde con código y cambiando, cuando corresponda, de un estado a otro. Lo que el protocolo busca es conocer si los comandos funcionan, por tanto, sólo se establecen dos códigos de respuesta, uno para cuando el comando funciona correctamente y otro para cuando no es así. Los códigos de respuesta que el servidor POP envía, van seguidos de una frase que explica el código. El Código de respuesta es el siguiente: +OK: El comando funcionó correctamente +ERR: El comando falló Los comandos POP se pueden agrupar según el estado en el que se encuentre el servidor: Comandos del Estado de Autorización Al conectarse a un servidor POP, éste entra en un estado de autorización. El cliente de correo debe enviar el nombre de la cuenta y la clave para poder continuar. Si son correctos, la casilla correspondiente a esa cuenta pasa a un estado de bloqueo exclusivo, para impedir que los mensajes 63/70 Teleprocesos y Redes 2 sean modificados o borrados antes de llegar al estado de actualización del servidor POP. Si no se consigue pasar la casilla al estado de bloqueo exclusivo, se produce un fallo y no se puede pasar al estado de transacción. USER: le proporciona el nombre de la cuenta de usuario. PASS: señala la clave de la cuenta de usuario indicada por el comando USER. QUIT: se puede usar cuando el servidor está en estado de autorización y en estado de transacción. Si se usa cuando está en estado de autorización, la sesión finaliza y se interrumpe la conexión. Si se usa cuando está en estado de transacción, se cierra la sesión y el servidor pasa a estado de actualización. Comandos del Estado de Transacción DELE: marca como eliminado un mensaje, se elimina realmente cuando se pasa al estado de actualización. LIST: recupera información acerca del tamaño que ocupa un mensaje determinado o todos los mensajes. NOOP: comando de no operación. Cuando se envía, el servidor responde con un OK. Se utiliza para mantener activa la sesión. RETR: (Recuperar) permite recuperar un mensaje determinado del servidor. RSET: (Reiniciar) anula la marca de borrado de todos los mensajes en la casilla. STAT: (Estado) permite obtener un resumen del contenido de la casilla. Comandos del Estado de Actualización En este estado no hay comandos. A este estado se llega desde el estado de transacción cuando se envía al servidor el comando QUIT. En este estado de actualización se eliminan los mensajes que han sido marcados en el estado anterior. A continuación se le quita el bloqueo exclusivo a la casilla para que pueda actualizarse con nuevo correo. Por último, el servidor termina la conexión. Comandos POP Opcionales APOP: (entrar en el sistema con contraseña encriptada) es una alternativa a los comandos USER y PASS. TOP: permite al cliente de correo recuperar la parte del encabezado del mensaje y un número de líneas del cuerpo o núcleo del mensaje. Este comando se suele utilizar cuando se desea conocer los mensajes sin leerlos. UIDL: (lista de identificadores únicos) permite obtener del servidor una identificación (ID) de mensaje única y persistente para uno o todos los mensajes de la casilla. NAT – Network Address Translation y PAT – Port Address Translation El uso de redes de computadoras en las empresas ha crecido y continúa creciendo drásticamente. Además, el rápido agotamiento de las direcciones IP públicas hace que adquirirlas sea costoso, razón por la cual las redes privadas utilizan un direccionamiento basado en direcciones IP reservadas que son inválidas para su uso fuera de la red interna. NAT – Network Address Translation NAT es un método mediante el que las direcciones IP son mapeadas desde un dominio de direcciones a otro, proporcionando encaminamiento transparente a las máquinas finales. Características: - Asignación transparente de direcciones. Encaminamiento transparente mediante la traducción de direcciones (aquí el encaminamiento se refiere al reenvío de paquetes, no al intercambio de información de encaminamiento). - Traducción de la carga útil de los paquetes de error ICMP La traducción de la dirección de red, se aplica en redes que fueron implementadas con direcciones IP privadas y necesitan tener un acceso a Internet, se debe solicitar a un proveedor un rango de 64/70 Teleprocesos y Redes 2 direcciones válidas para poder asociar dichas direcciones válidas con los hosts que tengan direcciones inválidas y necesiten salida a Internet. Operación básica: Para que una red privada tenga acceso a Internet, el acceso debe ser por medio de un dispositivo ubicado en la frontera de las dos redes que tenga configurado NAT para la traducción de direcciones, en estos casos lo más conveniente es poner a un router para que los paquetes sean enviados hacia él. Existen dos tipos de asignación de direcciones: - Asignación estática de direcciones, en este caso, existe un mapeo uno a uno de direcciones para las máquinas entre una dirección privada de red y una dirección externa de red durante el tiempo en funcionamiento del NAT. La asignación estática de direcciones asegura que NAT no tiene que administrar la gestión de direcciones con los flujos de sesión. SRC: 192.168.0.2:1108 DST: 207.28.194.84:80 SRC: 206.245.160.2:1108 DST: 207.28.194.84:80 A Cliente 192.168.0.2 B Web Server 207.29.194.84 Router NAT 192.168.0.1 Privada 206.245.160.1 Publica Internet SRC: 192.168.0.3:1101 DST: 207.28.194.84:21 Cliente 192.168.0.3 SRC: 206.245.160.2:1101 DST: 202.197.101.111:21 FTP Server 205.197.101.111 Tabla NAT Estatico Interno Externo 192.168.0.x 206.245.160.x Figura 1: NAT estático: cuando el host 192.168.0.2 envía un paquete al servidor 207.28.194.84 tiene en la cabecera de sus paquetes los datos mostrados en “A”, al pasar estos paquetes por el router NAT, los datos son modificados y llegan al servidor con los datos mostrados en “B”. Las relaciones de direcciones de la tabla del router son puestas estáticamente - Asignación dinámica de direcciones, en este caso, las direcciones externas son asignadas a las máquinas de la red privada de manera dinámica, basándose en los requisitos de uso y el flujo de sesión que el NAT determine heurísticamente. Cuando la última de las sesiones que use una dirección asociada termine, NAT liberará la asociación para que la dirección global pueda ser reciclada para su posterior uso. 65/70 Teleprocesos y Redes 2 SRC: 192.168.0.2:1108 DST: 207.28.194.84:80 SRC: 206.245.160.2:1108 DST: 207.28.194.84:80 A Cliente 192.168.0.2 B Web Server 207.29.194.84 Router NAT 192.168.0.1 Privada 206.245.160.1 Publica Internet SRC: 192.168.0.3:1101 DST: 207.28.194.84:21 Cliente 192.168.0.3 SRC: 206.245.160.2:1101 DST: 202.197.101.111:21 FTP Server 205.197.101.111 Tabla NAT Dinamico Interno Externo 192.168.0.2 206.245.160.5 192.168.0.3 206.245.160.6 NAT Pool: 206.245.160.5 - 10 Figura 2: NAT dinámico: en este caso sucede lo mismo que en el anterior con las cabeceras de los paquetes que salen de “A”, en este caso la tabla muestra una lista con las direcciones válidas disponibles para ser usadas, estas direcciones son asignadas dinámicamente a los hosts. NAT tradicional: En un NAT tradicional, las sesiones son unidireccionales, salientes de la red privada. Las sesiones en la dirección opuesta pueden ser permitidas en una base excepcional usando mapeos de dirección estáticos para hosts preseleccionados. Existen dos variantes del NAT Tradicional: NAT Básico y PAT (Port Address Translation). NAT Básico: Una zona con un conjunto de direcciones de red privadas puede ser habilitada para comunicarse con una red externa mapeando dinámicamente el conjunto de direcciones privadas a un conjunto de direcciones de red válidas globalmente, cada dirección tiene garantizada una dirección global para ser mapeada a ella. De lo contrario, los nodos habilitados para tener acceso simultáneo a la red externa son limitados por el número de direcciones en el conjunto global. Direcciones locales individuales pueden ser estáticamente mapeadas a direcciones globales específicas para asegurarse acceso garantizado hacia fuera o para permitir acceso al host local desde hosts externos mediante una dirección pública fija. Sesiones múltiples simultáneas pueden ser iniciadas desde un nodo local, usando el mismo mapeo de dirección. PAT – Port Address Translation Digamos, una organización tiene una red IP privada y una conexión WAN a un proveedor de servicio. El router de zona de la red privada es asignado a una dirección válida globalmente en la conexión WAN y los demás nodos en la organización usan direcciones IP que tienen sólo significado local. En este caso, a los nodos en la red privada se les puede permitir acceder simultáneamente a la red externa, usando la única dirección IP registrada con la ayuda de PAT. PAT permitiría mapeos del tipo (direcciones IP local, número de puerto local) a tipos del tipo (dirección IP registrada, número de puerto asignado). Este modelo es adecuado para muchos grupos de redes pequeñas para acceder a redes externas usando una sola dirección IP asignada del proveedor de servicio. Este modelo debe ser extendido para permitir acceso entrante mapeando estáticamente un nodo local por cada puerto de servicio TU de la dirección IP registrada. 66/70 Teleprocesos y Redes 2 SRC: 192.168.0.2:1108 DST: 207.28.194.84:80 SRC: 206.245.160.2:61001 DST: 207.28.194.84:80 A Cliente 192.168.0.2 B Web Server 207.29.194.84 Router PAT 192.168.0.1 Privada 206.245.160.1 Publica Internet SRC: 192.168.0.3:1101 DST: 207.28.194.84:21 Cliente 192.168.0.3 SRC: 206.245.160.2:61002 DST: 202.197.101.111:21 FTP Server 205.197.101.111 Tabla PAT Interno Externo 192.168.0.2:1108 61001 192.168.0.3:1108 61002 Figura 4: PAT: ejemplo de funcionamiento de PAT, se usa una sola dirección IP válida y se conectan diferentes hosts de la red interna hacia Internet por diferentes puertos. Fases de Traducción: - Asociando la dirección, con NAT Básico, una dirección privada se la asocia a una dirección externa cuando la primera sesión saliente es iniciada desde el host privado. Después de esto, todas las otras sesiones salientes originadas desde la misma dirección privada usarán la misma dirección unida por la traducción de paquete. En el caso de PAT, donde muchas direcciones privadas son mapeadas a un sola dirección globalmente única, la asociación sería entre <dirección privada y puerto privado> a <dirección global y puerto asignado>. Como con NAT Básico, esta unión es determinada cuando la primera sesión saliente es iniciada. - Búsqueda y traducción de dirección, Después de que una unión de dirección o dirección y puerto en el caso de PAT se establece, se puede mantener un estado para cada una de las conexiones. Los paquetes pertenecientes a la misma sesión estarán sujetos a la búsqueda de sesión para propósitos de traducción. - Desasociando la dirección, Cuando la última sesión basada en una dirección o dirección y puerto es terminada, ésta sesión finaliza. Manipulación de Cabeceras En el modelo NAT Básico, el encabezado IP de todos los paquetes debe ser modificado. Esta modificación incluye la dirección IP (dirección IP origen para paquetes salientes y dirección IP destino para paquetes entrantes) y la suma de control IP. Para las sesiones TCP y UDP, las modificaciones deben incluir actualización de la suma de control en los encabezados TCP/UDP. Esto es porque la suma de control de TCP/UDP también cubre un pseudoencabezado que contiene las direcciones IP origen y destino. Como una excepción, los encabezados UDP con suma de control 0 no deben ser modificados. Como para los paquetes de petición ICMP, no son requeridos cambios adicionales en el encabezado ICMP como la suma de control en el encabezado ICMP que no incluye las direcciones IP. En el modelo PAT, las modificaciones al encabezado IP son similares a las del modelo NAT Básico. Para las sesiones TCP/UDP, las modificaciones deben ser extendidas para incluir la traducción del puerto (puerto origen para paquetes salientes y puerto destino para paquetes entrantes) en el encabezado TCP/UDP. El encabezado ICMP en los paquetes de petición ICMP deben también ser 67/70 Teleprocesos y Redes 2 modificados para reemplazar el ID de petición y la suma de control del encabezado ICMP. La suma de control del encabezado ICMP debe ser corregida para contar la traducción del ID de petición. Estas son algunas de las modificaciones efectuadas: - Ajuste de la suma de control, las modificaciones de NAT son por paquete y puede ser un cómputo muy intensivo, ello involucra una o más modificaciones a la suma de control, inclusive para traducciones de un sólo campo. - Modificaciones al paquete de error ICMP, los cambios al mensaje de error ICMP incluirán cambios a los encabezados IP e ICMP en la capa saliente como bien cambios a los encabezados de los paquetes embebidos en la carga útil del mensaje ICMP-error. El método para NAT debe ser transparente para el host-final, la dirección IP del encabezado IP embebido en la carga útil del mensaje ICMP-error debe ser modificado, el campo de suma de control del encabezado IP embebido debe ser modificado, y finalmente, la suma de control del encabezado ICMP debe también ser modificada para reflejar los cambios a la carga útil. - Manipulando la opción IP, un datagrama IP con una de las opciones IP de Registrar Ruta, Encaminamiento de Origen Fijo o Encaminamiento de Origen No Estricto involucraría registro o uso de direcciones IP de routers intermedios. Un router NAT intermedio puede elegir no soportar estas opciones o dejar las direcciones sin traducir mientras que si procesa las opciones. El resultado de dejar las direcciones sin traducir sería que direcciones privadas a lo largo del encaminamiento origen son expuestas de extremo a extremo. Esto no debe poner en peligro la ruta atravesada por el paquete, de hecho, como cada router se supone que mira sólo al próximo salto. En general, NAT no debería trabajar con ninguna aplicación que envíe direcciones IP o puertos como datos. Por ejemplo, cuando dos programas usan FTP mantienen una conexión TCP entre ellos. Como parte del protocolo, un programa obtiene un número de puerto en la máquina local, y envía los datos por la conexión TCP al otro programa. Si la conexión entre los programas pasa por medio de un router configurado con PAT, el puerto podría ser cambiado y reemplazado por el puerto que PAT le asigne. Así, si NAT falla al cambiar el número de puerto, el protocolo podría fallar. Las implementaciones de NAT fueron creadas para reconocer puertos conocidos como el de FTP y hacer los cambios necesarios en el flujo de datos. Pero existen aplicaciones que no pueden ser usadas con NAT. Conclusiones Gracias a la invención de NAT, se detuvo el agotamiento de las direcciones IP válidas, porque permite que varios hosts dentro de una red privada, tengan acceso a Internet con sólo usar unas pocas direcciones IP válidas. Esta es una gran ventaja porque le dio un respiro a IPv4 para que no colapse rápido y dio tiempo para la creación de una nueva versión de IP (IPv6) que soluciones el problema de agotamiento de direcciones. Aunque un router que utiliza NAT no es un firewall, provee de cierta seguridad, porque los hosts externos a la red no conocen las direcciones verdaderas de los hosts que se encuentran dentro de la red privada, haciendo que sea difícil poder realizar un ataque desde hosts externos. Una desventaja de PAT es cuando se debe traducir paquetes fragmentados TCP/UDP, sólo el primer fragmento contiene el encabezado TCP/UDP que sería necesario para asociar el paquete a una sesión para la traducción. Los fragmentos siguientes no contienen información del puerto, simplemente llevan el mismo identificador de fragmentación especificado en el primer fragmento. El problema se presenta cuando dos hosts de la red privada originan paquetes TCP/UDP fragmentados al mismo host destino, si por coincidencia usaron el mismo identificador de fragmentación, cuando el host destino recibe los datagramas de ambas fuentes (que no tienen relación entre si) con el mismo identificador de fragmentación y desde la misma dirección de host asignada, es incapaz de determinar a cuál de las dos sesiones pertenece cada datagrama y las dos sesiones se corrompen. 68/70 Teleprocesos y Redes 2 RUTEO COMPLETO Normalmente A generará segmentos TCP de tal forma que el datagrama IP resultante coincida con el MTU, con lo que no suele haber fragmentación en el origen. La capa IP llena los campos IP DE DESTINO y PROTOCOLO provisto por TCP. Luego completa el campo IP DE ORIGEN, inicializa el campo TTL, asigna el número de identificación del datagrama, si no hay fragmentación inicializa el OFFSET en cero, el MORE FLAG en cero. Finalmente, luego de completar el resto de los campos calcula el CHECKSUM. Con la IP DE DESTINO, IP busca en su tabla de ruteo para saber si es una entrega directa o no: - En el caso de ser entrega directa, la IP DE ENTREGA será la IP DE DESTINO. - En el caso de no ser entrega directa, la IP DE ENTREGA será la IP del GATEWAY por default. Mediante ARP traduce la IP DE ENTREGA en una dirección de física y luego le pasa dicha dirección y el datagrama a la capa NAL. La capa NAL lo encapsule en una trama y lo envía. El host o router que reconoce su dirección física lee la trama completa de la red, toma el datagrama y se lo entrega a la capa IP. - - - IP toma el datagrama y le calcula el CHECKSUM, y lo compara con el campo CHECKSUM del datagrama. Si son distintos, IP descarta el datagrama y envía un mensaje ICMP (TIPO = 12, Problema de parámetros para un datagrama) a quien originó el datagrama. IP decrementa y el TTL del datagrama. Si éste llegó a cero, IP descarta el datagrama y envía un mensaje ICMP (TIPO = 11, Tiempo excedido para un datagrama) a quien originó el datagrama. La capa IP del router toma la IP DE DESTINO del datagrama, y realiza el algoritmo de ruteo. Para ello busca en su tabla de ruteo si existe una entrada para la red a la que corresponde la IP. Si existe una entrada en la tabla de ruteo, y ésta indica que es entrega inmediata, el algoritmo de ruteo devolverá la misma IP DE DESTINO y por qué interfaz deberá ser enviado el datagrama. 69/70 Teleprocesos y Redes 2 - - - - - Si existe una entrada en la tabla de ruteo, y ésta indica la dirección de un router, el algoritmo de ruteo devolverá la misma IP del router y por qué interfaz deberá ser enviado el datagrama. Si no existe entrada en la tabla de ruteo y existe un router por default, el algoritmo de ruteo devolverá la IP del router por default como salto al siguiente y por qué interfaz deberá ser enviado el datagrama. Si no existe entrada en la tabla de ruteo y tampoco existe un router por default, el router descarta el datagrama y envía un mensaje ICMP (TIPO = 3, Destino inaccesible) a quien originó el datagrama. Una vez que IP sabe por qué interfaz va a enviar el datagrama, chequea si el datagrama puede ser enviado en una sola trama de esa red o si debe fragmentarlo. Si no es necesario fragmentar, IP actualiza el TTL y recalcula el CHECKSUM del datagrama; y al igual que antes utiliza ARP para traducir la dirección de entrega en una dirección física. Luego IP entrega la dirección física y el datagrama a la capa NAL. La que se encargará de enviar el datagrama en una trama a dicha dirección física. Si es necesario fragmentar, y el datagrama tiene el flag de NO FRAGMENTAR = 1, el router descarta el datagrama y envía un mensaje ICMP (TIPO = 12, Problema de parámetros para un datagrama) a quien originó el datagrama. Si es necesario fragmentar, y el datagrama tiene el flag de NO FRAGMENTAR = 0, 70/70