Protocolos TCP/IP

Juan Salvador Miravet Bonet

al019803@alumail.uji.es

ICQ:81034697

FastCounter by LinkExchange
Contador Instalado el 5-11-1999
(Y se reseteo por razones desconocidas el 3-3-2000)

Resumen

Este trabajo intenta dar una información clara y directa de los protocolos englobados dentro del conjunto de protocolos TCP/IP. Este documento esta ideado como un manual de referencia de algunos de los protocolos antes mencionados, asi como del formato de los mensajes que utilizan estos.

Indice

1. Introducción
2. Estructura interna
3. La Capa de Aplicación
• 3.1. BOOTP (Bootstrap Protocol)
• 3.2. DNS (Domain Name Server)
• 3.3. Echo Protocol
• 3.4. NTP (Network Time Protocol)
• 3.5. SNMP (Simple Network Management Protocol)
• 3.6. ICMP (Internet Control Message Protocol)
• 3.7. IGMP (Internet Group Management Protocol)
• 3.8. Protocolos para actualizar la Tabla de Direcionamiento
4. La Capa de Transporte
• 4.1. UDP (User Datagram Protocol)
• 4.2. TCP (Transmision Control Protocol)
5. La Capa de Red
• 5.1. IP (Internet Protocol) Versión 4
• 5.2. Direcciones IP de la Versión 4
• 5.3. IP (Internet Protocol) Versión 6
• 5.4. Direcciones IP de la Versión 6
6. La Capa Física
• 6.1. ARP (Address Resolution Protocol)
• 6.2. RARP (Reverse Address Resolution Protocol)
7. Conclusión
8. Referéncias

Algunos de los motivos de su popularidad son: [Tcpip3]

• Independencia del fabricante 
• Soporta multiples tecnologias 
• Puede funcionar en maquinas de cualquier tamaño 
• Estandar de EEUU desde 1983 

• La independencia de la tecnologia usada en la conexión a bajo nivel y la arquitectura del ordenador 
• Conectividad Universal a traves de la red 
• Reconocimientos de extremo a extremo 
• Protocolos estandarizados 

2. ESTRUCTURA INTERNA

El modelo básico en internet es el modelo Cliente/Servidor. El Cliente es un programa que le solicita a otro que le preste un servicio. El Servidor es el programa que proporciona este servicio.

La arquitectura de Internet esta basada en capas. Esto hace mas facil implementar nuevos protocolos. El conjunto de protocolos TCP/IP, al estar integrado plenamente en Internet, tambien dispone de este tipo de arquitectura. El modelo de capas de TCP/IP es algo diferente al propuesto por ISO (International Standard Organization) para la interconexión de sistemas abiertos (OSI). (Ver imágenes 1 y 2).

Imagen 1. Relación del modelo TCP/IP con el modelo OSI

Imagen 2. Modelo de capas de TCP/IP

3.1. BOOTP (Bootstrap Protocol)

---

Información general

En lugar de utilizar el protocolo ARP, una maquina que acaba de ponerse en funcionamiento por primera vez, puede utilizar el protocolo bootstrap para obtener la direccion IP y información sobre su sector de arranque. Este metodo tiene algunas ventajas respecto al del protocolo ARP.

Formato del mensaje

• Tipo (Type): Este campo identifica si el mensaje es una solicitud o una respuesta
• Cabecera (Header): Este campo identifica el tipo de direccion de hardware
• Longitud-H (H-Length): Este campo identifica la longitud de la direccion de hardware en octetos
• Contador de saltos (Hop count): Se utiliza cuando el protocolo BOOTP se utiliza a traves de varios Gateways. Cada paso por un Gateways aumenta en uno el contador.
• ID de Transacción (transaction ID): Lo utiliza la estacion de trabajo para asignar las respuestas a las solicitudes
• Segundos (Seconds): Se utiliza para calcular el tiempo transcurrido desde el envio de la solicitud hasta la recepcion de la respuesta.
• Direccion IP del Cliente (Client IP address): Este campo lo completa el cliente, si la conoce. En otro caso se pone a cero.
• Direccion IP del servidor (Server IP address): Puede ser introducido por el cliente, si la conoce. Cuando el valor es diferente de cero, solo el servidor especificado puede contestar a la solicitud. Esta es una forma de forzar al servidor para que proporcione la información de arranque.
• Direccion IP del Gateways (Gateways IP address): Este campo lo pone a cero el cliente, y si la solicitud la obtiene un Gateways, este escribe su direccion en este campo.
• Direccion de Hardware del cliente (Client Hardware Address): Este campo lo completa el cliente
• Nombre del servidor Host (Server Host Name): Este campo es opcional, y puede ponerlo a cero tanto el servidor como el cliente.
• Nombre del archivo de arranque (Boot File Name): Puede ponerlo a cero el cliente, o poner un nombre generico. El servidor reemplazara este campo por la ruta completa del archivo completo.
• Area del Fabricante (Vendor-specific area): Puede tener un codigo escrito por el cliente.

3.2. DNS (Domain Name Service) [Wylder93]

---

Muchos usuarios prefieren utilizar un nombre que sea mas fácil de recordar que una direccion numerica. Para hacer esto, un servidor debe transformar el nombre en la direccion correcta. Esto se hacia originalmente en Internet mediante una tabla unica situada en un servidor central, donde estaban contenidos todos los nombres de Host. Esto era posible debido a que solo existian unos cientos de servidores, pero debido a un gran aumento del numero de servidores, fue necesario descentralizar el servidor de nombres y dividirlo en multiples DNS (servidores de nombres de dominio).

Esto redujo el tiempo de respuesta del sevidor, y disminuyo el trafico en la red.

La estructura del sistema de dominios es similar a la estructura de directorios del DOS o del UNIX. Es decir, es una estructura en forma de arbol, y los archivos estan identificados con una ruta de acceso. La diferencia es que en el DNS la ruta empieza con el nombre del nodo en vez del directorio raiz. Ademas, las rutas en un servidor DNS se escriben en sentido inverso a las del DOS.

Desde el punto de vista de un programa el funcionamiento de este servicio en muy simple. El programa proporciona un nombre de dominio, y el DNS le devuelve su direccion IP.

Nombres de dominio

El programa de usuario proporciona el nombre de dominio como una secuencia de palabras. Las palabras estan listadas de izquierda a derecha, y la que representa la zona mas cercana al usuario es la primera.

Los programas DNS manipulan el nombre del dominio proporcionado por el usuario de manera que sea facilmente interpretado por otros programas. Para los programas, cada nombre de dominio contiene una secuencia de etiquetas, y cada etiqueta contiene un octeto de longitud seguido por una cadena de caracteres de un subconjunto de caracteres ASCII. Este subconjunto está formado por caracteres alfa (A-Z), digitos (0-9) y un signo menos (-).

Arquitectura del DNS

DNS es un protocolo de la capa de aplicacion y esta clasificado como una utilidad por convenio entre los usuarios y el administrador del sistema, en vez de una parte integrada en los servicios de usuario.

Elementos de programas de DNS

Siguiendo el modelo Cliente/Servidor, DNS consiste en un usuario, un cliente, un servidor de nombres local y un servidor de nombres remoto. En terminos de las especificaciones, DNS consiste en un programa de usuario, un cliente, un servidor de nombres, y un servidor de nombres remoto. Cada Host debe implementar un mecanismo utilizando el cliente DNS para convertir nombres de Host en direcciones IP.

Elementos de Datos de DNS

Un nodo DNS se representa por una etiqueta en el interior del nombre de dominio, y todos los nodos tienen unos archivos de recursos (resource records (RRs)) que contienen información que habilita el programa DNS para encontrar el nombre de dominio solicitado.

Formato de un RR. (Ver Figura 2)

• Nombre del propietario (Owner Name) o (SNAME) es el nombre del nodo al cual pertenece el Resource Record. Este nombre que sera comparado con el nombre proporcionado por el programa de usuario El nombre está en formato DNS con unos octeto de longitud seguido por cadenas ASCII.
• Tipo (Type) es un entero de 16 bits que describe el tipo de Resource Record. (Ver Tabla 1).
• Clase (Class) es un entero de 16 bits que define la clase del Resource Record. Un RR de Internet tiene el campo igual a 1.
• Tiempo de vida (Time-to-live) es un entero de 32 bits que especifica el intervalo de tiempo en el cual el RR debe ser almacenado en la memoria cache, antes de ser actualizado con la información del origen. El valor cero significa que el RR debe ser utilizado solo en la transaccion en progreso, y no tiene que ser almacenado. El valor cero tambien se utiliza para datos muy volatiles.
• Longitud RD (RDLength) es un entero de 16 bits especifica la longitud en octetos del campo RDATA.
• RData es una cadena de longitud variable de octetos que describen el recurso. El formato de esta información varia segun el tipo y clase del RR. Para el tipo A RR (Internet) , el campo RData contiene una direccion IP de 32 bits.

Figura 2.
Formato de un Resource Record

msb							lsb
7	6	5	4	3	2	1	0
Owner name
Type
Class
Time to live
RDLength
RData
27	26	25	24	23	22	21	20

Funcionamiento del DNS

Un programa manda una solicitud a un cliente (resolver) que contiene un nombre de dominio para el cual se quiere la direccion IP asociada. La solicitud se suele hacer con una subrutina, o un puntero hacia el nombre de dominio en la pila del sistema. Los nombres de dominio en el cache del Resolver (cliente) estan en un formato estándar contenido en RRs. Existen tres posibles respuestas de un Resolver al programa de usuario.

• Uno o mas RRs conteniendo la direccion IP solicitada. En el caso de que el nombre proporcionado fuera un alias, el Resolver simplemente devuelve el nombre de dominio al que hace referencia el alias.
• Un mensaje de error en el nombre, que significa que el nombre proporcionado no existe.
• Un error de datos no encontrado, que significa que el nombre proporcionado existe, pero no se refiere a ninguna direccion IP.

Formato de un mensaje DNS

El Protocolo DNS utiliza mensajes enviados por el UDP para trasladar solicitudes y respuestas entre servidores de nombres. La transferencia de zonas completas la hace el TCP.
El formato de un mensaje DNS tiene cinco partes.

• Cabecera define el formato de las otras partes
• Pregunta es el objetivo a resolver
• Respuesta es la resolucon del objetivo
• Autoridad es la referencia a un servidor autorizado
• Adicional es información relacionada, pero no la respuesta.

Formato de la cabecera. (Ver Figura 3)

La cabecera contiene los siguientes campos:

• ID es un campo de 16 bits utilizado para relacionar solicitudes y respuestas.
• QR es un campo de 1 bit que identifica el mensaje como una solicitud (0) o una respuesta (1).
• OPcode es un campo de 4 bits que describe el tipo de mensaje. (Ver Tabla 2)

  Tabla 2.
  Codigo de operacion/Tipo de mensaje

  Codigo	Descripcion
  0	Solicitud normal (nombre a direccion)
  1	Solicitud Inversa (direccion a nombre)
  2	Solicitud del estado del servidor

• A es un campo de 1 bit que cuando tiene valor 1 indica que la respuesta la ha hecho un servidor autorizado
• T es un campo de 1 bit que cuando toma valor 1 indica que el mensaje ha sido truncado
• RQ es un campo de 1 bit que cuando esta puesto a 1, indica la solicitud de un servicio recursivo por parte del servidor de nombres. Este servicio normalmente no esta disponible.
• RA es un campo de 1 bit que indica la disponibilidad del servicio recursivo.
• Z es un campo de 3 bits reservado para un uso futuro, y su valor debe ser 0.
• RCode es un campo de 4 bits que lo rellena el servidor de nombres, y sirve para indicar el estado de la busqueda. (Ver Tabla 3)

  Tabla 3.
  Estado de la busqueda

  Codigo	Descripcion
  0	Sin errores
  1	Error de Imposible interpretar el formato de la busqueda
  2	Error de Imposible procesar el servidor
  3	Error de nombre inexistente
  4	Tipo de busqueda no soportado
  5	Solicitud rechazada

• QDCount es un campo de 16 bits que indica el numero de entradas en la sección de Preguntas.
• ANCount es un campo de 16 bits que indica el numero de Resource Records en la sección de Respuesta.
• NSCount es un campo de 16 bits que define el numero de Resource Records en la sección de Autoridad.
• ARCount es un campo de 16 bits que define el numero de Resource Records en la sección de Archivos Adicionales.

Formato de la sección Preguntas

Esta sección la construye el cliente, y siempre esta presente. Contiene el nombre de dominio objetivo, seguido por los campos Qtype y Qclass. Esta sección es identica en longitud y formato que la definida para los campos CName, tipo y clase de un Resource Record.

Formato de la sección Respuesta

Esta sección contiene uno o mas RRs.

Formato de la sección Autoridad

La sección autoridad contiene uno o mas RRs que apuntan hacia los origenes de la información autorizada.

Formato de la sección Adicional

Esta sección contiene uno o mas RRs que proporcionan fuentes adicionales de información.

3.3. Echo Protocol

---

3.4. NTP (Network Time Protocol) [Wylder93]

---

El NTP se utiliza para sincronizar los servidores con una precisión de nanosegundos.

Formato del mensaje. (Ver Figura 4).

• Indicador de Ajuste (Leap Indicator)(LI): Es un campo de 2 bits que indica el ajuste debido al periodo de rotacion de la Tierra. (Ver Tabla 4)

  Tabla 4.
  Indicador de Ajuste

  Valor	Significado
  00	Sin advertencias
  01	-1 segundo
  10	+1 segundo
  11	Condicion de alarma (Reloj no sincronizado)

• Numero de Version (Version Number) (VN): Es un campo de 3 bits que indica el numero de version.
• Reservado (Reserved): Es un campo de 3 bits, que tienen valor cero.
• Estrato (Stratum): Este campo tiene una longitud de 8 bits, y se utiliza para indicar el estrato local del reloj. (Ver Tabla 5)

  Tabla 5.
  Estrato del reloj local

  Valor	Significado
  0	Sin especificar
  1	Referencia primaria
  2..n	Referencia secundaria (via NTP)

• Poll: Este campo tiene una longitud de 8 bits. Indica el intervalo maximo de tiempo entre mensajes.
• Precision: Este campo tiene una longitud de 8 bits y indica la precision del reloj local.
• Distancia de sincronia (Sincronize distance): Este es un campo de 32 bits, que indica el retraso aproximado de la primera ruta de sincronizacion.
• Nivel de velocidad aproximado (Estimated Drift Rate): Es un campo de 32 bits que indica el nivel de velocidad del reloj local.
• Identificador del reloj de referencia (Reference Clock Identifier): Campo de 32 bits que indica una reloj de referencia particular. (Ver Tabla 6)

  Tabla 6.
  Identificador de reloj de referencia

  Valor	Codigo	Significado
  0	DCN	Determinado por el algoritmo DCN
  1	WWVB	Radio Reloj WWVB (60 KHz)
  1	GOES	Reloj de satelite GOES (450 MHz)
  1	Radio Reloj WWV	WWV (5/10/15 MHz)

• Fecha y Hora (Timestamps) :Existen 3 Timestamps (Fecha y hora) de 64 bits cada uno.

3.5. SNMP (Simple Network Management Protocol)

---

[Raro97] El protocolo SNMP se utiliza para administrar multiples redes fisicas de diferentes fabricantes, es decir Internet, donde no existe un protocolo comun en la capa de Enlace. La estructura de este protocolo se basa en utilizar la capa de aplicacion para evitar el contacto con la capa de enlace.

Formato del mensaje

Existen tres partes en un mensaje SNMP:

• Numero de versión (Version number): Se utiliza para identificar el nivel de SNMP
• Cadena de Comunidad (Community string): Se utiliza para la seguridad, restrigiendo el acceso a los datos.
• PDU: Esta sección contiene los comandos y respuestas, llamados PDU (Protocol Data Units).

3.6. ICMP

---

[Wylder93]

Internet es un sistema autonomo que no dispone de ningun control central. El protocolo ICMP (Internet Control Message Protocol), proporciona el medio para que el software de hosts y gateways intermedios se comuniquen. El protocolo ICMP tiene su propio numero de protocolo (numero 1), que lo habilita para utilizar el IP directamente. La implementacion de ICMP es obligatoria como un subconjunto logico del protocolo IP. Los mensajes de error de este protocolo los genera y procesa TCP/IP, y no el usuario.

Formato del mensaje ICMP

• Tipo (Ver Tabla 7)
• Código
• Checksum
• Otras variables

Solicitud de Eco. (Ver Figura 5)

Un Host puede comprobar si otro Host es operativo mandando una solicitud de eco. El receptor de la solicitud la devuelve a su origen. Esta aplicacion recibe el nombre de Ping. Esta utilidad encapsula la solicitud de eco del ICMP (tipo 8) en un datagrama IP y lo manda a la direccion IP.

El receptor de la solicitud de eco intercambia las direcciones del datagrama IP, cambia el codigo a 0 y lo devuelve al origen.

Figura 5.
Formato del mensaje de Eco ICMP

	Octet +0								Octet +1								Octet +2								Octet +3
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
+0	Type								Code								Checksum
+4	Identifier																Sequence number
	Optional Data

Informes de Destinos Inalcanzables. (Ver Figura 6)

Si un Gateways no puede enviar un datagrama a la direccion de destino, este manda un mensaje de error ICMP al origen. El valor del campo tipo es 3, y el tipo de error viene dado por el campo codigo. (Ver Tabla 8).

Control de flujo

Para contener los datagramas IP, un Gateways dispone de un buffer. Si el numero de datagramas es grande, el buffer se satura. En este momento el Gateways descarta todos los mensajes que recive hasta que obtiene un nivel de buffer aceptable. Cada datagrama descartado hace que el Gateways mande un mensaje ICMP de control de flujo al origen. Esto informa de que un mensaje ha sido descartado.

Originalmente el mensaje ICMP de control de flujo se enviaba cuando el buffer estaba lleno, pero esto llegaba demasiado tarde, y el sistema ya estaba saturado.

El algoritmo se cambio para que el mensaje ICMP de control de flujo se enviara cuando el buffer estuviera al 50%.

Formato del mensaje

Cambio de ruta (redireccionamiento)

Los Gateways en cualquier Internet contienen las tablas de redireccionamiento mas comunes. Cuando la ruta por defecto no es la mas adecuada, el Gateways puede enviar al Host un mensaje de redireccionamiento ICMP que contiene la ruta correcta.

Formato del mensaje

El formato del mensaje ICMP de control de flujo es igual al del mensaje de Inalcanzable, excepto que el tipo es 5 y el valor del codigo es variable entre 1 y 3. Los motivos para la redireccion y sus codigos se pueden consultar en la Tabla 9.

Tiempo de vida excedido

Para prevenir bucles en la redireccion, el datagrama IP contiene un tiempo de vida definido por el origen. A medida que cada Gateways procesa el datagrama, el valor del campo disminuye en una unidad. Posteriormente el Gateways verifica si el valor del campo es 0. Cuando se detecta un 0, el Gateways manda un mensaje de error ICMP y descarta el datagrama.

Formato del mensaje

El formato del mensaje de error es igual al del mensaje de inalcanzable, pero el tipo es 11, y el codigo es igual a 0 (contador sobrepasado), o 1 (tiempo de reensamblaje de fragmento excedido).

Errores de parametros

Un error de parametros se produce cuando el que origina el datagrama, lo construye mal, o el datagrama esta dañado. Si un Gateways encuentra un error en un datagrama, manda un mensaje ICMP de error de parametros al origen y descarta el datagrama.

Formato del mensaje

El formato del mensaje ICMP de error de parametros es igual al de inalcanzable, pero su tipo es 12, y el codigo es 0 si se utilizan punteros, o 1 si no se utilizan.

Mensaje Fecha y hora del ICMP

El Mensaje Fecha y hora del ICMP es una herramienta util para diagnosticar problemas de internet, y recoger información acerca del rendimiento. El protocolo NTP (Network Time Protocol), puede utilizarse para marcar el tiempo inicial, y puede guardar la sincronizacion en milisegundos del reloj.

Formato del mensaje. (Ver Figura 7)

El mensaje Fecha y hora tiene los siguientes campos: Tipo, Codigo, Checksum, Identificador, Numero de secuencia, Fecha y hora original, Fecha y hora receptor y Fecha y hora de transmision. El tipo es igual 13 para el origen y 14 para el Host remoto. El codigo es igual a cero. El identificador y el numero de secuencia se usan para identificar la respuesta. El Fecha y hora original es el tiempo en el que el emisor inicia la transmision, el Fecha y hora receptor es el tiempo inicial en el que el receptor recibe el mensaje. El Fecha y hora de transmision es el tiempo en que el receptor inicia el retorno del mensaje.

Figura 7.
Formato ICMP de fecha y hora

Octet +0								Octet +1								Octet +2								Octet +3
7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
Type								Code								Checksum
Identifier																Sequence number
Originate Timestamp
Receive Timestamp
Transmit Timestamp

Mascara de subred

Cuando un Host quiere conocer la mascara de subred de una LAN fisica, puede mandar una solicitud ICMP de mascara de subred.

Formato del Mensaje

El formato es igual a los primeros ocho octetos del ICMP Fecha y hora. El valor del campo tipo es 17 para la solicitud de mascara de subred y 18 para la respuesta. El codigo es 0, y el identificador y el numero de secuencia se utilizan para identificar la respuesta.

3.7. IGMP

---

Un Gateways multicast manda mensajes una vez por minuto como maximo. Un Host receptor responde con un mensaje IGMP, que marca al Host como miembro activo. Un Host que no responde al mensaje se marca como inactivo en las tablas de direccionamiento de la red multicast.

3.8. PROTOCOLOS DE ACTUALIZACIÓN DE LA TABLA DE DIRECCIONAMIENTO

Los protocolos que se describen a continuacion se utilizan en el proceso automatico de actualizacion de la tabla de direccionamiento. [Wylder93]

EGP (Exterior Gateways Protocol)

---

Un dominio de direccionamiento es un grupo de redireccionadores que usan un IGP(Internal Gateways Protocol) comun. Una forma de reducir el volumen de información intercambiado se basa en que un dominio de redireccionmiento utilice un Gateways seleccionado para comunicar información de direccionamiento con los Gateways seleccionados de otros dominios. El Gateways seleccionado se considera como un Gateways exterior, y el protocolo usado entre Gateways exteriores es el EGP.

El protocolo EGP se compone de tres partes:

• Neighbor Adquisition Protocol
• Neighbor Reachability Protocol (NR)
• Network Reachability Determination

El Neighbor Reachability Protocol se basa en un mensaje "Hello" (comando), y una respuesta "I heard you". Se utiliza para saber si la comunicacion continua.

El mensaje Network Reachability se usa para comprobar si el siguiente "vecino" es un camino valido para llegar a un destino particular.

EL principal inconveniente del protocolo EGP es que crea una estructura en forma de arbol, es decir que si hay problemas en Internet, los Gateways solo saben que hay problemas en el Gateways exterior.

BGP-3 (Border Gateways Protocol)

---

El problema del protocolo EGP, fue el que impulso a diseñar e implementar el protocolo BGP.

El protocolo BGP es un protocolo interno de sistema autonomo. Un sistema autonomo puede contener multiples dominios de direccionamiento, cada uno con su propio protocolo interno de sistema autonomo, o IGP. Dentro de cada sistema autonomo pueden haber varios Gateways que se pueden comunicar con los Gateways de otros sistemas. Tambien se puede elegir un Gateways para lograr un informe de la información de direccionamiento para el sistema autonomo. En cualquier caso, un sistema autonomo aparece ante otro sistema autonomo como un direccionador consistente. Esto elimina la estructura de arbol del protocolo EGP.

GGP (Gateways-to-Gateways Protocol)

---

Los primeros Gateways de internet utilizaban un IGP llamado Gateways-to-Gateways Protocol , que fue el primer IGP utilizado. Usando GGP cada Gateways manda un mensaje a todos los otros Gateways de su grupo autonomo que contiene una tabla con las direcciones que el Gateways ha direccionado, con su vector de distancia asociado.

RIP (Routing Information Protocol)

---

El RIP es un IGP desarrollado bastante despues del GGP, y esta basado en el vector/distancia. Si un Gateways conoce varias rutas para llegar a un destino, asigna un coste a la ruta en funcion de los saltos de Gateways que deba realizar. (Cuantos mas Gateways tenga que cruzar, mas saltos debera realizar).

Cada 30 segundos envia un mensaje con su tabla de direccionamiento a los demas que actualizan sus tablas con los datos recibidos. (Esto produce un incremento del trafico de red).

Este algoritmo tiene algun fallo, como por ejemplo no detecta bucles en la transmision de la ruta. Esto daria un problema consistente en que dos rutas que se llamen entre ellas estarian emitiendo tablas de direccionamiento indefinidamente.

Otro error es que no obliga a la autentificacion de los intercambios, por lo que cualquier persona podria recibir información de las rutas enviadas por los Gateways.

Existen dos versiones RIP I y RIP II (Soporta mascaras de subred).

Hello Protocol

---

Un IGP similar al RIP es el Hello Protocol. La diferencia basica es que el RIP cuenta los saltos de Gateways, y el Hello mide la distancia por el tiempo transcurrido. Este protocolo tiene un problema asociado al vector de distancia. El problema tiene dos etapas. La primera etapa es cuando los Gateways descubren una ruta mas corta para llegar a un determinado destino. Esta ruta es mas corta y mas rapida, lo que provoca que el trafico de red pase a utilizar esta nueva ruta.

La segunda etapa empieza cuando los Gateways descubren que la nueva ruta es mas lenta que la ruta vieja, debido a que al desviar el trafico de red a la nueva ruta, esta se satura, y todos los usuarios vuelven a la ruta vieja.

OSPF (Open Shortest Path First)

---

Uno de los protocolos IGP mas nuevos es el OSPF. Este protocolo ofrece un mayor grado de sofisticacion con caracteristicas como: Rutas basadas en el tipo de servicio, la distancia, nivel de carga, etc.

El formato del mensaje OSPF es mas complejo que el RIP. Tiene una cabecera fija de 24 octetos, y una parte variable para especificar el tipo del mensaje. Existen cinco tipos de mensaje, como se puede ver en la Tabla 10.

4.1. UDP (User Datagram Protocol)

---

El protocolo UDP (User Datagram Protocol) proporciona aplicaciones con un tipo de sevicio de datagramas orientado a transacciones. El servicio es muy parecido al protocolo IP en el sentido de que no es fiable y no esta orientado a la conexión. El UDP es simple, eficiente e ideal para aplicaciones como el TFTP y el DNS. Una dirección IP sirve para dirigir el datagrama hacia una maquina en particular, y el numero de puerto de destino en la cabecera UDP se utiliza para dirigir el datagrama UDP a un proceso especifico localizado en la cabecera IP. La cabecera UDP tambien contiene un numero de puerto origen que permite al proceso recibido conocer como responder al datagrama.

Formato del mensaje. (Ver Figura 8)

El datagrama UDP contiene cuatro campos, que son Numero del Puerto de Origen, Numero del Puerto de Destino, Longitud del mensaje y Checksum.

Figura 8.
Formato del UDP

	Octet +0								Octet +1								Octet +2								Octet +3
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
+0	Source Port																Destination Port
+4	Message Length																Checksum
	UDP Data

Numeros de Puerto de Origen y Destino

Estos numeros, junto con las direcciones IP definen el punto final de la comunicacion. El numero del puerto de origen, puede tener valor cero si no se usa. El numero del puerto de destino solo tiene sentido en el contexto de un datagrama UDP y un a direccion IP en particular.

El numero de puerto de origen es un campo de 16 bits. El puerto de destino tiene la misma longitud.

Longitud del Mensaje

Este campo tiene una longitud de 16 bits y contiene el numero total de octetos que forman el datagrama, incluida la cabecera.

Checksum

El uso del checksum es opcional, y este campo debe ponerse a cero si no es utilizado. Mientras que el checksum del datagrama IP solo tiene en cuenta la cabecera del mensaje, el UDP tiene su propio checksum para garantizar la integridad de los datos. La longitud de este campo es de 16 bits, y esta formado por la suma de los campos del UDP, y algunos campos del IP.

Para incluir los campos del IP, se construye una pseudo cabecera UDP. Esta pseudo cabecera de 12 octetos se utiliza unicamente a efectos de calcular la suma. (Ver Figura 9)

Figura 9.
Pseudo-Cabecera UDP

	Octet +0								Octet +1								Octet +2								Octet +3
	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0	7	6	5	4	3	2	1	0
P s e u d o H e a d e r	Source IP Adress
	Destination IP Address
	Zero								Protocol ID								Length
	Source Port																Destination Port
	Message Length																Checksum
	UDP Data
	UDP Data								Zero

4.2. TCP (Transmission Control Protocol)

---

[Raro97] Controla la comunicación entre un equipo y otro. Conforma los paquetes IP que serán enviados por la capa inferior. Desencapsula los paquetes recibidos pasando a la capa superior la información dirigida a una aplicación.

5.1. IP (Internet Protocol) Versión 4

---

El Protocolo IP proporciona un sistema de distribucion que es poco fiable incluso en un base solida. El protocolo IP especifica que la unidad basica de transferencia de datos en el TCP/IP es el datagrama.[Tcpip2]

Los datagramas pueden ser retrasados, perdidos, duplicados, enviados en una secuencia incorrecta o fragmentados intencionadamente para permitir que un nodo con un buffer limitado pueda coger todo el datagrama. Es la responsabilidad del protocolo IP reensamblar los fragmentos del datagrama en el orden correcto. En algunas situaciones de error los datagramas son descartados sin mostrar ningun mensaje mientras que en otras situaciones los mensajes de error son recibidos por la maquina origen (esto lo hace el protocolo ICMP).

El protocolo IP tambien define cual sera la ruta inicial por la que seran mandados los datos.

Cuando los datagramas viajan de unos equipos a otros, es posible que atraviesen diferentes tipos de redes. El tamaño maximo de estos paquetes de datos puede variar de una red a otra, dependiendo del medio fisico que se emplee para su transmision. A este tamaño maximo se le denomina MTU (Maximum Transmission Unit), y ninguna red puede transmitir un paquete de tamaño mayor a esta MTU. El datagrama consiste en una cabecera y datos. (Ver Figura 12)

Longitud de la Cabecera

Este campo ocupa 4 bits, y representa el numero de octetos de la cabecera dividido por cuatro, lo que hace que este sea el numero de grupos de 4 octetos en la cabecera.

Versión

El campo versión ocupa 4 bits. Este campo hace que diferentes versiones del protocolo IP puedan operar en la Internet. En este caso se trata de la versión 4.

Tipo de servicio

Este campo ocupa un octeto de la cabecera IP, y especifica la precedencia y la prioridad del datagrama IP. Los tres primeros bits del octeto indican la precedencia. Los valores de la precedencia pueden ser de 0 a 7. Cero es la precedencia normal, y 7 esta reservado para control de red. Muchos Gateways ignoran este campo.

Los otros 4 bits definen el campo prioridad, que tiene un rango de 0 a 15. Las cuatro prioridades que estan asignadas son: 0, (por defecto, servicio normal), 1 (minimizar el coste monetario), 2 (maxima fiabilidad), 4 (Maximizaar la transferencia), 8 (El bit +4 igual a 1, define minimizar el retraso). Estos valores son utilizados por los routers para direccionar las solicitudes de los usuarios.

Longitud Total

Este campo se utiliza para identificar el numero de octetos en el datagrama total.

Identificacion

El valor del campo identificacion es un numero secuencial asignado por el Host origen. El campo ocupa dos octetos. Los numeros oscilan entre 0 y 65.535, que cuando se combinan con la direccion del Host forman un numero unico en la Internet. El numero se usa para ayudar en el reensamblaje de los fragmentos de datagramas.

Fragmentos Offset

Cuando el tamaño de un datagrama excede el MTU, este se segmenta.

El fragmento Offset representa el desplazamiento de este segmento desde en inicio del datagrama entero.

Flags

El campo flag ocupa 3 bits y contiene dos flags. El bit +5 del campo flags se utiliza para indicar el ultimo datagrama fragmentado cuando toma valor cero. El bit +7 lo utiliza el servidor origen para evitar la fragmentacion. Cuando este bit toma valor diferente de cero y la longitud de un datagrama excede el MTU, el datagrama es descartado y un mensaje de error es enviado al Host de origen por medio del protocolo ICMP.

Tiempo de Vida

El campo tiempo de vida ocupa un octeto. Representa el numero maximo de segundos que un datagrama puede existir en Internet, antes de ser descartado.Un Datagrama puede existir un maximo de 255 segundos. El numero recomendado para IP es 64.

El originador del datagrama manda un mensaje ICMP cuando el datagrama es descartado.

Protocolo

El campo protocolo se utiliza para identificar la capa de mayor nivel mas cercana usando el IP. Este es un campo de 0 bits, que normalmente identifica tanto la capa TCP (valor 6), como la capa UDP (valor 17) en el nivel de ransporte, pero puede identificar hasta 255 protocolos de la capa de transporte.

Checksum

El checksum proporciona la seguridad de que el datagrama no ha sido dañado ni modificado. Este campo tiene una longitud de 16 bits.

El checksum incluye todos los campos de todos los campos de la cabecera IP, incluido el mismo, cuyo valor es cero a efectos de calculo.

Un Gateways o nodo que efectue alguna modificacion en los campos de la cabecera (por ejemplo en el tiempo de vida), debe recalcular el valor del checksum antes de enviar el datagrama.

Los usuarios del IP deben proporcionar su propia integridad en los datos, ya que el checksum es solo para la cabecera.

Direccion de Origen

Este campo contiene un identificador de red (Netid) y un identificador de Host (Hostid). El campo tiene una longitud de 32 bits. La direccion puede ser de clase A, B, C. (ver Direcciones IP).

Direccion de Destino

Este campo contiene el Netid y el Hostid del destino. El campo tiene una longitud de 32 bits. La direccion puede ser de clase A, B, C o D (ver Direcciones IP).

Opciones

La existencia de este campo viene determinada por la longitud de la cabecera. Si esta es mayor de cinco, por lo menos existe una opcion.

Aunque un Host no esta obligado a poner opcciones, puede aceptar y procesar opciones recibidas en un datagrama. El campo Opciones es de longitud variable. Cada octeto esta formado por los campos Copia, Clase de Opcion y Numero de Opcion.

• El campo Copia sirve para que cuando un datagrama va a ser fragmentado y viaja a traves de nodos o Gateways. Cuando tiene valor 1, las opciones son las mismas para todos los fragmentos, pero si toma valor 0, las opciones son eliminadas.
• Clase de Opcion es un campo que cuando tiene valor 0, indica datagrama o control de red; Cuando tiene valor 2, indica depuracion o medida. Los valores 1 y 3 estan reservados para un uso futuro.
• El Numero de Opcion indica una accion especifica.

Padding

---

Cuando esta presente el campo Pad, consiste en 1 a 3 octetos puestos a cero, si es necesario, para hacer que el numero total de octetos en la cabecera sea divisible por cuatro.

Datos

---

El campo datos consiste en una cadena de octetos. Cada octeto tiene un valor entre 0 y 255. El tamaño de la cadena puede tener un minimo y un maximo, dependiendo del medio fisico. El tamaño maximo esta definido por la longitud total del datagrama. El tamaño del campo Datos en octetos es igual a:

Figura 12.
Formato del Datagrama IP

	msb							lsb
	7	6	5	4	3	2	1	0
I P H e a d e r	Version				Header Length				+0
	Type of Service								+1
	Total Length								+2
									+3
	Identification								+4
									+5
	Flags			Fragment Offset					+6
									+7
	Time to Live								+8
	Protocol								+9
	Header Checksum								+10
									+11
	Source Address of Originating Host								+12
									+13
									+14
									+15
	Destination Address of Target Host								+16
									+17
									+18
									+19
	Options								+20
									+21
									+22
	Padding								+23
	IP Data								+0
									+1
MSB									+n

5.2. Direcciones IP

---

Existen cinco clases de subredes, tal y como muestra la Figura 13. [Tcpip1]

Figura 13.
Clases de Direcciones IP

• La clase A contiene 7 bits para direcciones de red, con lo que permite tener hasta 128 redes, con 16.777.216 ordenadores cada una. Las direcciones estaran comprendidas entre 0.0.0.0. y 127.255.255.255., y la mascara de subred sera 255.0.0.0.
• La clase B contiene 14 bits para direcciones de red y 16 bits para direcciones de hosts. El numero maximo de redes es 16.536 redes, con 65.536 ordenadores por red. Las direcciones estaran comprendidas entre 128.0.0.0. y 191.255.255.255., y la mascara de subred sera 255.255.0.0.
• La clase C contiene 21 bits para direcciones de red y 8 para hosts, lo que permite tener un total de 2.097.142 redes, cada una de ellas con 256 ordenadores. Las direcciones estaran comprendidas entre 192.0.0.0. y 223.255.255.255., y la mascara de subred sera 255.255.255.0.
• La clase D se reserva todas las direcciones para multidestino (multicast), es decir, un ordenador transmite un mensaje a un grupo especifico de ordenadores de esta clase. Las direcciones estaran comprendidas entre 224.0.0.0. y 239.255.255.255.
• La clase E se utiliza exclusivamente para fines experimentales. Las direcciones estan comprendidas entre 240.0.0.0. y 247.255.255.255.

5.3. IP (Internet Protocol) Versión 6

---

[Tcpip4] Esta es una nueva versión del protocolo IP, llamada IPv6, aunque también es conocida como IPng (Internet Protocol Next Generation). Es la versión 6, debido a que la numero 5 no paso de la fase experimental. La compatibilidad con la versión 4 es prácticamente total, ya que se han incluido características de compatibilidad. Algunas de las modificaciones, estan encaminadas a mejorar la seguridad en la red, que apenas existia en la versión 4.

Formato de la cabecera. (Ver Figura 14)

Esta cabecera ocupa el doble que la anterior, pero se ha simplificado omitiendo algunos campos y haciendo que otros sean opcionales. De esta manera, los routers no tienen que procesar tanta imformación. Los campos son los siguientes:

• Versión: Este campo ocupa 4 bits, y contiene el numero de versión del IP, en este caso 6.
• Prioridad: Ocupa 4 bits, y indica la importancia del paquete que se esta enviando.
• Etiqueta de Flujo: Ocupa 24 bits. Indica que el paquete requiere un tratamiento especial por parte de los routers que lo soporten.
• Longitud: Ocupa 16 bits. Indica la longitud en bytes de los datos del mensaje
• Siguiente Cabecera: Ocupa 8 bits e indica a que protocolo corresponde la cabecera que esta a continuación de la actual.
• Tiempo de vida: Ocupa 8 bits y tiene la misma funcion que el la versión 4.
• Dirección de origen: Ocupa 128 bits (16 octetos), y es el numero de dirección del origen.
• Dirección de Destino: Ocupa 128 bits (16 octetos). Es el numero de dirección del destino.

5.4. Direcciones IP Versión 6

---

[Tcpip4] El cambio mas significativo en las direcciones ha sido, que ahora, se refieren a un interfaz y no a un nodo, aunque como cada interfaz pertenece a un nodo, es posible referirse a estos mediante su interfaz.

El numero de direcciones diferentes se ha multiplicado de una manera exagerada. Teoricamente, es posible tener 2¹²⁸ direcciones diferentes. Este numero quiere decir que se podrían llegar a tener mas de 665.000 trillones de direcciones por metro cuadrado, aunque si siguieran una jerarquia, este numero decrede hasta 1564 direcciones por metro cuadrado en el peor caso o tres trillones siendo optimistas.

En el IPv6 existen tres tipos basicos de direcciones:

• Direcciones unicast: Estan dirigidas a un unico interfaz en la red. Actualmente se dividen en varios grupos, y existe un grupo especial que facilita la compatibilidad con las direcciones de la versión 4.
• Direcciones anycast: Identifican a un conjunto de interfaces de red. El paquete se enviara a cualquier interfaz que forme parte del conjunto. En realidad son direcciones unicast que se encuentran asignadas a varios interfaces.
• Direcciones multicast: Identifican a un conjunto de interfaces de la red, de manera que cada paquete es enviado a cada uno de ellos individualmente.

6.1. ARP

---

6.2. RARP [Raro97]

---

El protocolo RARP (Reverse Address Resolution Protocol) es el encargado de asignar una direccion IP a una direccion fisica.

Formato del Mensaje RARP

[Raro97]
Jose Luis Raya, Victor Rodrigo (1997).Domine TCP/IP. ED RA-MA.

[Tcpip1]
Biblioteca de Represetación Gráfica de Mensajes para X-Window y Adaptación de Protocolo TCP para el Sistema Simple_Com en Ada95
http://cimmeria.uc3m.es/~tatou/proyecto/node1.html

[Tcpip2]
LA SUITE DE PROTOCOLOS TCPIP
http://minter.cieamer.conacyt.mx/internet/tcp_ip.html

[Tcpip3]
TEMA 9: PROTOCOLOS TCP/IP
http://infase.es/FORMACION/INTERNET/tcpip.html

[Tcpip4]
Funcionamiento de Internet
http://www.oocities.org/SiliconValley/Bay/8259/contenido.html

Si desea mas información puede consultar los siguientes Request For Comments

• RFC 768 User Datagram Protocol
• RFC 791 The Internet Protocol
• RFC 792 Internet Control Message Protocol
• RFC 793 TCP Transmission Control Protocol
• RFC 826 An Ethernet Address Resolution Protocol
• RFC 903 A Reverse Address Resolution Protocol
• RFC 1180 A TCP/IP Tutorial