Esta capa
corresponde a las aplicaciones que estan disponibles para los usuarios, como
TELNET, FTP, SNMP.
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
Descripción
de los campos: (Ver Figura 1)
| 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. |
Figura
1.
Formato del mensaje BOOTP
|
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
|
Header
Type
|
H-Length
|
Hop
Count
|
Transaction
ID
|
Seconds
|
Zero
|
Client
IP Address
|
Response
IP Address
|
Server
IP Address
|
Gateways
IP Address
|
Client
Hardware Address (16 Octets)
|
Server
Host Name (64 Octets)
|
Boot
File Name (128 Octets)
|
Vendor-Specific
Area (64 Octets)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.2. DNS
(Domain Name Service)
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. |
Otro
elemento de datos del DNS es el SLIST. El SLIST es una estructura que describe
los servidores de nombres y la zona donde el el cliente esta intentando enviar
una solicitud actualmente.
Tabla
1.
Tipos de Resource Records
|
Valor
|
Codigo
|
Significado
|
1
|
A
|
La direccion de un Host
|
2
|
NS
|
Un servidor de nombres
autorizado
|
5
|
CNAME
|
El nombre canonico de un alias
|
6
|
SOA
|
Inicio de la zona de autoridad
|
11
|
WKS
|
Descripcion de un servicio
conocido
|
12
|
PTR
|
Un puntero de nombre de dominio
|
13
|
HINFO
|
Información de un Host
|
14
|
MINFO
|
Información del Mailbox o de
una lista de correo
|
15
|
MX
|
Intercambio de correo
|
16
|
TXT
|
Cadena de texto
|
22
|
NSAP
|
Cadena hacia un servicio de
transporte OSI
|
23
|
NSAP-PTR
|
Puntero de nombre de dominio
NSAP
|
252
|
AXFR
|
Solicitud de tranferencia de un
a zona entera
|
253
|
MAILB
|
Solicitud de los archivos del
Mailbox
|
255
|
|
Solicitud de todos los archivos
|
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. |
Figura
3.
Formato de la cabecera DNS
|
|
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
|
ID
|
QR
|
Opcode
|
A
|
T
|
RQ
|
RA
|
Z
|
Rcode
|
+4
|
QDCOUNT
|
ANCOUNT
|
+8
|
NSCOUNT
|
ARCOUNT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
El
servidor eco utiliza el puerto de UDP numero 7 para escuchar las solicitudes de
eco del cliente. El cliente utiliza un numero de puerto UDP libre para el numero
de puerto de origen y manda un mensaje por medio del UDP al servidor eco. El
servidor recibe la solicitud, intercambia las direcciones de origen y destino,
intercambia las identificaciones de puertos, y devuelve el mensaje al cliente.
3.4. NTP
(Network Time Protocol)
El
NTP se utiliza para sincronizar los servidores con una precisión de
nanosegundos.
Formato
del mensaje. (Ver Figura 4).
El
mensaje NTP esta formado por los siguientes campos:
| 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. |
Figura
4.
Formato del NTP
|
|
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
|
LI
|
VN
|
0
|
0
|
0
|
Statum
|
Poll
|
Precision
|
+4
|
Synchronizing
Distance
|
+8
|
Estimated
Drift rate
|
+12
|
Reference
clock Identifier
|
+16
|
Reference
clock Timestamp
|
+24
|
Originate
Timestamp
|
+32
|
Receive
Timestamp
|
+40
|
Transmit
Timestamp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.5. SNMP
(Simple Network Management Protocol)
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
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
Cada
Mensaje ICMP esta compuesto por los siguientes campos:
| Tipo (Ver Tabla
7) |
| Código |
| Checksum |
| Otras variables |
Tabla
7.
Tipos de mensaje ICMP
|
Tipo
|
Tipo
de Mensaje
|
0
|
Respuesta de Eco
|
3
|
Destino Inalcanzable
|
4
|
Origen saturado
|
5
|
Redireccion (cambiar ruta)
|
8
|
Solicitud de eco
|
11
|
Tiempo excedido para un
datagrama
|
13
|
Problema de parametros en un
datagrama
|
13
|
Solicitud de fecha y hora
|
14
|
Respuesta de fecha y hora
|
17
|
Solicitud de nascara de
direccion
|
18
|
Respuesta de mascara de
direccion
|
|
|
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).
Tabla
8.
Codigos de Inalcanzable
|
Codigo
|
Descripcion
|
0
|
Red no alcanzable
|
1
|
Host
no alcanzable
|
2
|
Protocolo no alcanzable
|
3
|
Puerto no alcanzable
|
4
|
Necesaria fragmentacion con la
opcion DF
|
5
|
Fallo de la ruta de origen
|
6
|
Red de Destino desconocida
|
7
|
Host
de Destino desconocido
|
8
|
Fallo del Host de Origen
|
9
|
Red prohibida
administrativamente
|
10
|
Host
prohibido administrativamente
|
11
|
Tipo de servicio de Red no
alcanzable
|
12
|
Tipo de servicio de Host
no alcanzable
|
|
|
Figura
6.
Formato del mensaje ICMP de destino inalcanzable
|
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
|
Internal
header plus 64 bits of datagram
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
El
formato del mensaje de control de flujo es identico al mensaje de inalcanzable,
excepto que el tipo es 4 y el codigo es 0.
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.
Tabla
9.
Codigos de Redireccion
|
Codigo
|
Razon
para la redireccion
|
1
|
Por el Host
|
2
|
Por el tipo de servicio y red
|
3
|
Por el tipo de servicio y Host
|
|
|
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
EL
IGMP (Internet Group Management Protocol) es un protocolo que funcion como una
extension del protocolo IP.
Se
utiliza exclusivamente por los miembros de una red multicast para mantener su
status de miembros, o para propagar información de direccionamiento.
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.
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 Adquisition Protocol se utiliza simplemente para establecer
comunicacion. Consta de una solicitud y una respuesta.
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.
Tabla
10.
Tipos de mensaje OSPF
|
Tipo
|
Significado
|
1
|
Hola (Utilizado para comprobar
la acesibilidad)
|
2
|
Descripcion de la Base de Datos
|
3
|
Solicitud del estado del enlace
|
4
|
Actualizacion del estado del
enlace
|
5
|
Reconocimiento del estado del
enlace
|
|
|
|