...

El Protocolo IP

by neverland79

on

Report

Category:

Documents

Download: 0

Comment: 0

3

views

Comments

Description

Describe el funcionamiento del protocolo IP
Download El Protocolo IP

Transcript

  • El protocolo IP RFC útiles :  RFC791 - Internet Protocol - Septiembre 1981;  RFC1122 - Requirements for Internet Hosts - Communication Layers - Octubre 1989. IP es el protocolo de la capa Internet. Es el único protocolo de la capa 3 utilizado en Internet. Existen otros protocolos de la capa 3 que garantizan un servicio parecido:  IPX, Internetwork Packet eXchange, el protocolo de la marca Novell, para su red Netware.  Appletalk, utilizado durante mucho tiempo en los ordenadores Macintosh, de la marca Apple. Estos dos protocolos, que ofrecen soluciones técnicas interesantes, fueron sustituidos por IP en un movimiento de convergencia que hemos llamado «IP Everywhere». La UIT (Unión Internacional de Telecomunicaciones), ha desarrollado sus propias especificaciones: el servicio CLNS (Connection Less Network Service), está implementado en el protocolo de la capa de red CLNP (Connection Less Network Protocol) y se utiliza por el protocolo de transporte TP4 (Transport Protocol Class 4). La ventaja de CLNP es proporcionar un espacio de direccionamiento mayor que IPv4, con las direcciones expresadas en 20 bytes. IPv6 sirvió de base para la propuesta TUBA, candidata a la sucesión de IPv4. Parece obvio que estos protocolos permanecerán para siempre en fase de especificaciones. La función principal que garantiza el protocolo IP es el encaminamiento a través de la malla de red, actividad inseparable del enrutamiento. IP funciona en modo desconectado y garantiza un servicio de entrega de los datagramas de tipo «Best effort», hace «todo lo posible» para garantizar su misión y no tiene la capacidad de gestionar los paquetes no entregados, duplicados, sin secuencia o corruptos. Para conseguir un diseño confiable del protocolo IP, fue necesario utilizar cabeceras más pesadas en todos los intercambios que transitan por la red. Además, los routeres debieron asumir una mayor complejidad. Ahora bien, no todos los intercambios que transitan por la red necesitan esta confiabilidad. El transporte de flujos de información en tiempo real (voz o vídeo), tienen otros requerimientos (retardo, banda ancha, etc.), para los cuales la búsqueda de esta confiabilidad, podría llegar a ser contraproducente. La palabra «datagrama», utilizada para hacer referencia al paquete IP, recuerda esta falta de fiabilidad. Son los diseñadores de Internet los que tomaron la opción de trasladar la búsqueda de esta fiabilidad a los host de los extremos y por lo tanto, en la capa de Transporte, en lo que se ha llamado el control de punto a punto o de principio a fin. Cada datagrama se encamina por la red de manera independiente al resto de datagramas, ya que
  • cada uno tiene, al mismo tiempo, información sobre su dirección de origen y su dirección de destino. IP se basa en las redes existentes. El transito del paquete por el medio elegido incumbe a la capa de Enlace. De nuevo, el principio de independencia de las capas parece que se respeta, aunque sin embargo hay una pega: la trama de la capa de Enlace no puede aceptar cualquier tamaño de paquete (MTU). De la misma manera que «un guante se adapta a una mano», la capa de red se debe adaptar a la capacidad de la capa de Enlace y aprender esta información MTU: De esta manera, en el ejemplo anterior, debido a que el MTU del enlace entre los routeres es inferior al correspondiente a las redes locales que soportan los PC, IP del router R1 fragmenta los datos que salen de PC1 o PC2 cuando estos se destinan a PC3 o PC4. De la misma manera, IP del router R2 fragmenta los datos que salen de PC3 o PC4 cuando estos van destinados a PC1 o PC2. Lo que es necesario recordar es lo siguiente: IP proporciona un servicio de entrega:  en modo no conectado;  cuya unidad de datos, llamada datagrama, se asocia a un formato de paquete;  cuya actividad principal consiste en encaminar los paquetes, siendo ésta una actividad distribuida, ya que cada nodo de la red (router), intenta acercar el datagrama de su destino;  enmarcado por una serie de normas (el vínculo…), que especifican el comportamiento de los host y de los routeres durante el tratamiento de los paquetes: creación de mensajes de error, acción «papelera»…  1. El datagrama IP   Aquí está el detalle de los diferentes campos. Los campos más importantes, se resaltan mediante (→ campo clave)…  a. Campo Version  Único campo que ocupa la misma posición en el formato IPv4 y en el formato IPv6. El número de versión del protocolo IP es 4 o 6, expresado en 4 bits.  b. Campo IHL (Internet Header Length) Longitud del encabezado del paquete IP, necesario porque hay un campo Options de longitud variable. Gracias al campo IHL, IP puede determinar dónde termina el encabezado y dónde comienzan los datos. Atención, el valor se expresa en unidades de 32 bits, lo que implica que la longitud del encabezado es obligatoriamente múltiplo de 32, ver también el campo Atasco. La longitud del encabezado mínimo se establece en 20 bytes (opción cero). El valor contenido en el campo IHL está limitado a 15 (4 bits) y la longitud máxima del
  • encabezado correspondiente a 60 bytes (40 bytes de opciones). Por tanto, al final, el valor del campo IHL, está comprendido entre 5 y 15. c. Campo TOS (Type Of Service) (→ campo clave) Atención, muchos de los documentos circulan con una definición de este campo desactualizada. En efecto, el campo TOS ya ha pasado por tres versiones, propuestas en los RFC siguientes:  la versión del RFC791, que describe el protocolo IP;  RFC2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers - Diciembre de 1998;  RFC3168 - The Addition of Explicit Congestion Notification (ECN) to IP - Septiembre de 2001. Este campo también existe en el encabezado IPv6, pero se convierte en el campo Clase de tráfico. El contenido de este campo, tal y como se define en el RFC791, es el siguiente: La ilustración siguiente muestra el contenido actual del byte TOS: ¿Qué sucede cuando un router no puede trasmitir los paquetes que recibe? En condiciones normales, se pueden producir ráfagas de los paquetes, cuyo ritmo supera la capacidad de procesamiento del router. Estos paquetes se ubican en la cola de espera y el router viene a buscarlos de manera secuencial y a su ritmo. Por supuesto, el sistema tiene un límite. Un flujo de entrada demasiado grande puede provocar la saturación de estas colas de espera. A este fenómeno se le llama congestión. Inevitablemente, el router está forzado a eliminar paquetes y puede hacerlo de manera aleatoria (es la noción de «Best effort»), aunque con la ayuda del campo DS (Differentiated Services), es posible hacerlo de manera más inteligente. La idea es crear clases de tráfico, caracterizadas por una probabilidad de rechazo. Las clases mayores corresponden a una probabilidad de rechazo menor. El RFC2474 define la noción de PHB (Per Hop Behaviour), difícil de traducir que consiste en definir el comportamiento del router en la transmisión de los paquetes, según el nivel de prioridad DSCP (Differentiated Services Code Point), contenido en el campo DS. El valor DSCP 000000 sólo garantiza el comportamiento por defecto de tipo «Best Effort». Para los paquetes que necesitan un tratamiento incluso «Best» los RFC 2597 y 2598 proporcionan los valores de DSCP para dos tipos de comportamiento:
  •  El PHB «Expedited Forwarding» (tratamiento acelerado), definido en el RFC 2598 y después en 3246, ofrece un ancho de banda garantizado, con una tasa de pérdida, retraso y fluctuación bajas, similar a un servicio de reserva de recursos (en resumen, ¡un circuito!). Este PHB se destina a las aplicaciones en tiempo real de tipo telefonía sobre IP. El DSCP toma el valor 46.  El grupo PHB «Assured Forwarding» (enrutamiento asegurado), definido en el RFC 2597, ofrece cuatro clases de servicio y tres niveles de prioridad («precedencia»), que permiten componer doce PHB diferentes. De esta manera, un proveedor de acceso puede proporcionar diferentes niveles de servicio definidos por el ancho de banda asignado, así como el volumen de las colas de espera. Los paquetes que se ajustan al grupo PHB AF, se asignan a una o varias clases por el cliente o el proveedor de acceso, según el contrato de prestación de servicios firmado. Dentro de una clase, el paquete se marca de nuevo con una prioridad entre tres, que se ajusta en caso de congestión en la clase en cuestión, arbitrando la eliminación de paquetes. La siguiente tabla agrupa los valores DSCP recomendados del grupo PHB AF: La figura siguiente ilustra un ejemplo de uso de los PHBs AF para el despliegue de una oferta «Triple Play» sobre ADSL: Observe que los valores DSCP elegidos no interfieren ni con el antiguo valor de prioridad 000 del campo TOS («Best effort»), ni con los antiguos valores de prioridad 11x correspondientes a la gestión de red. Esto permite que los antiguos routeres «TOS-capable» todavía presentes en la red, continúen funcionando. El campo ECN (Explicit Congestion Notification), sólo apareció en el byte TOS durante su última revisión, propuesta por el RFC3168. La idea es avisar a un emisor de que su emisión en curso, contribuye a la formación de una congestión, antes de que se produzca el rechazo de los paquetes. Además, se advierte al emisor con la ayuda de banderas situadas en el acuse de recibo que normalmente debe recibir. No hay creación de flujo adicional para alertar a este emisor. De hecho, lo peor sería crear un dispositivo que ayudara a transformar el riesgo de congestión en congestión efectiva. Un router mide el riesgo de congestión llenando sus colas de espera. Cuando un router que utiliza ECN quiere evitar una congestión (la carga media excede un umbral), marca los paquetes que están «ECN-capable» es decir, los paquetes que tienen una etiqueta que certifica que el emisor entenderá el marcado. El RFC3168 proporciona la tabla siguiente: ECN Descripción 00 No ECT (ECN Capable Transport), paquete no ECN
  • ECN Descripción 01 ECT(1): paquete ECN todavía sin marcar 10 ECT(0): paquete ECN todavía sin marcar normalmente aprovechado por TCP 11 CE (Congestion Experienced), paquete ECN marcado Es complicado ir más allá en la descripción de este mecanismo, ya que sería necesario tener sólidos conocimientos sobre el protocolo de transporte TCP y abordar algunas nociones referentes a las estrategias posibles de gestión de la cola de espera. d. Campo Total Length Tamaño del paquete IP, encabezado + datos, expresado en bytes. El campo está expresado en 16 bits, la longitud máxima se establece en 65535 bytes, pero es probable que ningún host ni ninguna red sea capaz de tratar semejantes datagramas. El RFC 791 precisa y el RFC 1122 lo recuerda, que todo host debe poder aceptar los datagramas para los que la longitud alcance 576 bytes, ya sean datagramas completos o fraccionados. Por otro lado, un host no debería emitir un datagrama de longitud superior a 576 bytes, excepto si tiene la seguridad de que el host remoto puede aceptarlo. Aquí tocamos un punto delicado, al que se le podría dedicar un capítulo completo. Puede encontrarse más información en el estudio del protocolo de transporte TCP. e. Campo Identification Cuando, durante el envío, un proceso IP se ve obligado a fragmentar un paquete para tener en cuenta el MTU del siguiente salto, el proceso IP destinatario final, deberá acometer la tarea adicional que consiste en reasociar los diferentes fragmentos para reconstruir el paquete inicial. En este punto se ayuda del campo Identification (un «tag»), cuyo valor se genera aleatoriamente en el paquete inicial y después se copia en cada uno de sus fragmentos. f. Campo Banderas El bit más significativo no se utiliza y permanece a cero. Los otros dos bits intervienen en el proceso de fragmentación:  Bit DF (Don’t Fragment): situado a 1, indica que el datagrama no se debe fragmentar. Un router que no tenga otra opción, destruirá el paquete generando un mensaje ICMP de información de destino inaccesible;  Bit MF (More Fragment): situado a 1, indica que el datagrama sólo es una parte del datagrama inicial. Situado a 0 con un valor del campo Fragment offset diferente de 0, indica que el datagrama es la última parte del datagrama inicial.
  • g. Campo Fragment Offset (→ campo clave) En 13 bits, permite volver a ensamblar un paquete fragmentado, proporcionando la posición en el datagrama inicial. Fuera de la cabecera, la posición expresada en bytes es igual a 8 veces el valor contenido en el campo Fragment Offset (Desplazamiento). Ejemplo: enviar 1400 bytes de datos en una conexión de MTU 620. El datagrama inicial se ha emitido en una red LAN de MTU 1500. Suponiendo que el encabezado IP no tenga opciones, cada datagrama emitido en la conexión MTU 620 puede tener 620 - 20 = 600 bytes de datos.  el primer datagrama lleva el primer fragmento de 600 bytes, le quedan 800;  el segundo datagrama lleva el segundo fragmento de 600 bytes, le quedan 200;  el tercer datagrama lleva el último fragmento de 200 bytes. Los valores correspondientes del campo Fragment Offset y del bit MF son: Número de fragmento Datos transportados Fragment Offset Bit MF 1 600 0 1 2 600 600/8 = 75 1 3 200 75 + 75 = 150 0 Podemos identificar un datagrama no fragmentado cuando, tanto el bit MF como el valor de desplazamiento, son iguales a 0. h. Campo TTL (→ campo clave) En 8 bits, vida útil del datagrama en la red, expresado en segundos. Cada router por el que transita el paquete, decrementa la vida útil en al menos uno, sea cual sea el tiempo inferior a uno transcurrido en el router. En la práctica, este campo se considera como el número de saltos máximo que limita el alcance del paquete, pero sobre todo, que permite eliminar un datagrama que «vaga» por la red sin alcanzar nunca su destino (bucle de enrutamiento). i. Campo Protocol (→ campo clave) En 8 bits, el campo Protocol contiene el N-SAP de capa 3, es decir, la información que permite al proceso IP de destino resituar la carga útil al protocolo de capa 4 adecuado. Este mecanismo se llama demultiplexación de protocolo: Los números asignados son bien conocidos y por lo tanto gestionados por la autoridad IANA. La lista se encuentra en el sitio web: http://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml
  • Es imprescindible conocer algunos valores, como ICMP → 1, TCP → 6 o UDP → 17. j. Campo Header checksum La suma de control del encabezado, expresada en 16 bits, permite garantizar la integridad del encabezado del datagrama IP. Un router que recibe un datagrama calcula esta suma y después la compara con la suma recibida. Si los valores son diferentes, el paquete se destruye y el router genera un mensaje ICMP. Si los valores son idénticos, el router decrementa el valor TTL, lo que le obliga a recalcular una suma de control que sustituye a la recibida, antes de enviar el paquete al router siguiente. El procedimiento de cálculo es el siguiente: 1) Poner checksum a 0. 2) Calcular la suma de las palabras de 16 bits que componen el encabezado. 3) Añadir resta1 a suma1. 4) Añadir resta2 a suma2. 5) Complementar a 1 suma3 → obtenemos el valor buscado. k. Campo Address Source (→ campo clave) La dirección Source identifica al emisor del datagrama y los routeres no la modifican. Por lo tanto, permanece inalterable durante todo el proceso de enrutamiento del paquete. l. Campo Address Destination (→ campo clave) La dirección Destination identifica el destinatario final del datagrama y los routeres no la modifican. Por lo tanto, permanece inalterable durante todo el proceso de enrutamiento del paquete (excepto, de nuevo, si hay traducción de direcciones de red). m. Campo Options La presencia de opciones se indica por medio de un valor del campo IHL superior a cinco. Las opciones se destinan normalmente a realizar pruebas durante las fases de optimización. La organización de las opciones recuerda a la de la zona del proveedor de BOOTP: cada opción presente tiene un código de opción en un byte, seguido de un campo longitud y de los datos propios de la opción:
  • Para poner un ejemplo, la opción Registro de ruta tiene una lista vacía de direcciones IP en el momento de su emisión por el origen. Después, cada router que hace avanzar al datagrama, añade su dirección IP a la lista. El campo Puntero le permite determinar la siguiente ubicación libre en el campo Datos de la opción. n. Campo Padding (Atasco) El campo IHL expresa la longitud del encabezado en unidades de 32 bits y el campo Atasco permite conseguir una longitud múltiplo de 32 bits, cuando esto no es posible de manera natural. Cuando, por ejemplo, no hay opciones, el campo Atasco no es necesario y por tanto, la longitud del encabezado se fija en 5 x 4 bytes.
Fly UP