UNIVERSIDAD GALILEO CEI CENTRAL - FISICC - IDEA Licenciatura en Informática y Administración de TelecomunicacionesCurso: Protocolos de TelecomunicacionesTutor: Lic. Noé Martínez Horario: Lunes 20:00 a 21:00

InvestigaciónICMP, Protocolo ARP y Encaminamiento

TRABAJO PARA SEMANA No. 8

INTEGRANTES DE GRUPO:Ronald Escobar, IDE1010777

Javier Piedrasanta, IDE06143222Jorge Polanco, IDE10370012José Mario Zúñiga, IDE1010524

Guatemala, 19 de agosto de 2013

Tabla de ContenidoTabla de Contenido________________________________________________________________2

Introducción_____________________________________________________________________3

El protocolo ICMP_______________________________________________________________4

Mensajes informativos___________________________________________________________5

Estructura de un segmento ICMP___________________________________________________5

Mensajes de error_______________________________________________________________6

El protocolo ARP________________________________________________________________7

Generación de paquetes ARP______________________________________________________9

Recepción de paquetes ARP______________________________________________________10

Proxy-ARP o subnetting transparente_______________________________________________11

Concepto de Proxy-ARP________________________________________________________11

Enrutamiento_________________________________________________________________12

Protocolos de Enrutamiento o Encaminamiento______________________________________14

Conclusiones____________________________________________________________________15

Enlaces_________________________________________________________________________16

Presentación____________________________________________________________________17

IntroducciónA continuación investigaremos sobre los temas de ICMP, protocolo ARP y Encaminamiento, estos son protocolos que forman parte de la familia de TCP/IP, que hoy en día es el más utilizado en las redes de comunicaciones de tecnología.

Este grupo de protocolos nos ha venido a ayudar con la transmisión no solamente de datos e información sino que ha contribuido enormemente en el tema de las telecomunicaciones y su avance tecnológico y es por eso que hoy tenemos la facilidad no solamente económica sino que también técnica de poder realizar llamadas internacionales a bajo costo y no digamos el tema de las video conferencias que cada día es más utilizado por las grandes empresas y corporaciones transnacionales ya que contribuyen en la reducción de costos que es parte de una buena administración de empresas y una buena utilización de las telecomunicaciones.

El protocolo ICMPEl Protocolo de Mensajes de Control y Error de Internet, ICMP, es de características similares a UDP, pero con un formato mucho más simple, y su utilidad no está en el transporte de datos de usuario, sino en controlar si un paquete no puede alcanzar su destino, si su vida ha expirado, si el encabezamiento lleva un valor no permitido, si es un paquete de eco o respuesta, etc. Es decir, se usa para manejar mensajes de error y de control necesarios para los sistemas de la red, informando con ellos a la fuente original para que evite o corrija el problema detectado. ICMP proporciona así una comunicación entre el software IP de una máquina y el mismo software en otra. El protocolo ICMP solamente informa de incidencias en la entrega de paquetes o de errores en la red en general, pero no toma decisión alguna al respecto. Esto es tarea de las capas superiores.

Internet Control Message Protocol (ICMP)

Familia Familia de protocolos de Internet

Función Control y notificación de errores del Protocolo de Internet

Ubicación en la pila de protocolos

Red ICMP

IP

Enlace Ethernet, Token Ring, FDDI, ...

Estándares

RFC 792 (1981)

Mensajes informativosEntre estos mensajes hay algunos de suma importancia, como los mensajes de petición de ECO (tipo 8) y los de respuesta de Eco (tipo 0). Las peticiones y respuestas de eco se usan en redes para comprobar si existe una comunicación entre dos host a nivel de capa de red, por lo que nos pueden servir para identificar fallos en este nivel, ya que verifican si las capas física (cableado), de enlace de datos (tarjeta de red) y red (configuración IP) se encuentran en buen estado y configuración.

Código Descripción0 Respuesta de Eco3 Destino Inaccesible4 Disminución del tráfico desde el origen5 Redireccionar – Cambio de ruta8 Solicitud de Eco11 Tiempo excedido para un datagrama12 Problema de parámetros13 Solicitud de marca de tiempo14 Respuesta de marca de tiempo15 Solicitud de información (obsoleto)16 Respuesta de información (obsoleto)17 Solicitud de máscara de dirección18 Respuesta de máscara de dirección

Estructura de un segmento ICMPEl ICMP inicia después de la cabecera IPv4 y se identifica con el protocolo número “1”.

Todos los paquetes ICMP tendrán una cabecera de 8 bytes y la sección de datos de tamaño variable. Los primero 4 bytes de la cabecera serán consistentes. El primer byte es reservado para el tipo de ICMP.

El segundo octeto es para el código de ICMP.

El tercer y cuarto byte es una suma de comprobación de todo el mensaje ICMP. El contenido de los restantes 4 bytes de la cabecera pueden variar dependiendo de la función del tipo y el código ICMP.

Los mensajes de error de este protocolo contienen una sección de datos que incluye todos los IP de cabecera más los 8 primeros bytes de los daros del paquete IP que ha originado el mensaje de error. El paquete ICMP es encapsulado en un nuevo paquete IP.

Bits 0-7, 8-15, 16-23 y 24-31

0 Tipo Código Checksum

32 Resto del encabezado

Tipo - Tipo de ICMP como se especifica a continuación.Código - Subtipo al tipo dado.Checksum - Datos comprobación de errores. Calculado a partir de la cabecera ICMP + datos, con un valor de 0 para este campo. El algoritmo de suma de comprobación se especifica en RFC 1071. Resto del Header - Cuatro campo byte. Puede variar en función del tipo y código ICMP.

Bit 0 7 Bit 8 15 Bit 16 23 Bit 24 31Tipo Código Suma de verificación

Datos (opcional)

Mensajes de errorEn el caso de obtener un mensaje ICMP de destino inalcanzable, con campo "tipo" de valor 3, el error concreto que se ha producido vendrá dado por el valor del campo "código", pudiendo presentar los siguientes valores que se muestran en la parte derecha.

Este tipo de mensajes se generan cuando el tiempo de vida del datagrama a llegado a cero mientras se encontraba en tránsito hacia el host destino (código=0), o porque, habiendo llegado al destino, el tiempo de reensamblado de los diferentes fragmentos expira antes de que lleguen todos los necesarios (código=1).

Los mensajes ICMP de tipo= 12 (problemas de parámetros) se originan por ejemplo cuando existe información inconsistente en alguno de los campos del datagrama, que hace que sea imposible procesar el mismo correctamente, cuando se envían datagramas de tamaño incorrecto o cuando falta algún campo obligatorio.

Por su parte, los mensajes de tipo=5 (mensajes de redirección) se suelen enviar cuando, existiendo dos o más routers

Código Descripción0 No se puede llegar a la red1 No se puede llegar al host o App de destino2 El destino no dispone del protocolo solicitado3 No se puede llegar al puerto de destino o la App de destino no está

libre4 Se necesita aplicar la fragmentación, pero el flag correspondiente

indica lo contrario5 La ruta de origen no es correcta6 No se conoce la red destino7 No se conoce el host destino8 El host origen está aislado9 La comunicación con la red destino está prohibida por razones

administrativas10 La comunicación con el host destino está prohibida por razones

administrativas11 No se puede llegar a la red destino debido al tipo de servicio12 No se puede llegar al host destino debido al tipo de servicio

diferentes en la misma red, el paquete se envía al router equivocado. En este caso, el router receptor devuelve el datagrama al host origen junto con un mensaje ICMP de redirección, lo que hará que éste actualice su tabla de enrutamiento y envíe el paquete al siguiente router.

El protocolo ARPEl protocolo ARP tiene un papel clave entre los protocolos de capa de Internet relacionados con el protocolo TCP/IP, ya que permite que se conozca la dirección física de una tarjeta de interfaz de red correspondiente a una dirección IP. Por eso se llama Protocolo de Resolución de Dirección (en inglés ARP significa Address Resolution Protocol).

Cada equipo conectado a la red cuenta con una MAC Address. Éste es un número único establecido en la fábrica en el momento de fabricación de la tarjeta. Sin embargo, la comunicación en Internet no utiliza directamente este número (ya que las direcciones de los equipos deberían cambiarse cada vez que se cambia la tarjeta de interfaz de red), sino que utiliza una dirección lógica asignada por un organismo: la dirección IP.

Para que las direcciones físicas se puedan conectar con las direcciones lógicas, el protocolo ARP interroga a los equipos de la red para averiguar sus direcciones físicas y luego crea una tabla de búsqueda entre las direcciones lógicas y físicas en una memoria caché.

Cuando un equipo debe comunicarse con otro, consulta la tabla de búsqueda. Si la dirección requerida no se encuentra en la tabla, el protocolo ARP envía una solicitud a la red. Todos los equipos en la red comparan esta dirección lógica con la suya. Si alguno de ellos se identifica con esta dirección, el equipo responderá al ARP, que almacenará el par de direcciones en la tabla de búsqueda, y, a continuación, podrá establecerse la comunicación.

Otros parámetros de ejecución de ARP

Generación de paquetes ARPSi una aplicación desea enviar datos a cierta dirección de destino IP, el mecanismo de enrutamiento IP primero determina la dirección IP del "próximo salto" del paquete (puede ser el propio host de destino, o un router) y el dispositivo hardware al cual se debería enviar. Si se trata de una red IEEE 802.3/4/5, el módulo ARP se debe consultar para hacer corresponder el <tipo de protocolo, la dirección del protocolo de destino> con una dirección física.

El módulo ARP intenta encontrar la dirección en esta caché ARP. Si encuentra la pareja correspondiente, devuelve la correspondiente dirección física de 48 bits al que lo llamó (el driver del dispositivo) que entonces transmite el paquete. Si no encuentra la pareja en su tabla, descarta el paquete (assumption is that a higher-level protocol will retransmit) y generates a network broadcast of an ARP request.

Donde:

Espacio de direcciones hardware

Especifica el tipo de hardware; ejemplo de ello son Ethernet o Red de Radio por Paquetes.

Espacio de direcciones del protocolo

Especifica el tipo de protocolo, igual que el campo EtherType en la cabecera IEEE 802 (IP o ARP).

Longitud de direcciones hardware

Especifica la longitud (en bytes) de las direcciones hardware en este paquete. Para IEEE 802.3 y IEEE 802.5 será 6.

Longitud de direcciones del protocolo

Especifica la longitud (en bytes) de las direcciones del protocolo en este paquete. Para IP será 4.

Código de operación

Especifica si es una petición ARP (1) o una respuesta (2).

Dirección hardware origen/destino

Contiene las direcciones hardware de red física. Para IEEE 802.3 son direcciones de 48 bits.

Dirección del protocolo origen/destino

Contiene las direcciones del protocolo. Para TCP/IP son direcciones de IP de 32 bits.

Para el paquete de petición ARP, la dirección hardware de destino es el único campo no definido en el paquete.

Recepción de paquetes ARPCuando un host recibe un paquete ARP (una petición de broadcast o una respuesta punto a punto), el driver del dispositivo receptor pasa el paquete al módulo ARP que lo trata como se muestra en la figura.

El host solicitante recibirá esta respuesta ARP y seguirá el mismo algoritmo para tratarlo. Como resultado de esto, se añadirá la tripleta <tipo de protocolo, dirección de protocolo, dirección hardware> para el host deseado a su tabla de búsqueda (caché ARP). La próxima vez que un protocolo de más alto nivel quiera enviar un paquete a ese host, el módulo ARP encontrará la dirección hardware de destino y se enviará el paquete a ese host.

Proxy-ARP o subnetting transparenteProxy-ARP se describe en el RFC 1027 - Usar ARP para Implementar Pasarelas de Subred Transparente, que es de hecho un subconjunto del método propuesto en el RFC 925 - Resolución de Direcciones Multi-LAN. Es otro método para construir subredes locales, sin necesidad de modificar el algoritmo de enrutamiento IP, pero modificando los routers, que interconectan las subredes.

Concepto de Proxy-ARPConsideremos una red IP, que está dividida en subredes, interconectada por routers. Usamos el algoritmo de enrutamiento IP "antiguo", que significa que ningún host conoce la existencia de múltiples redes físicas. Consideremos que los hosts A y B que están en diferentes redes físicas con la misma red IP y un router R entre las dos subredes como muestra la figura:

Cuando un host A quiere enviar un datagrama IP a un host B, primera tiene que determinar la dirección de red física del host B usando el protocolo ARP.

Como el host A no puede diferenciar entre las redes físicas, su algoritmo de enrutamiento IP piensa que el host B está en la red física local y envía una petición ARP de broadcast. El host B no recibe este broadcast, pero el router R sí. El router R entiende de subredes, esto es, ejecuta la versión "subnet" del algoritmo de enrutamiento IP y será capaz de ver que el destino de la petición ARP (del campo de dirección de protocolo destino) está en otra red física. Si las tablas de enrutamiento del router R especifican que el próximo salto a esa otra red se hace a través de un

dispositivo físico diferente, responderá a ARP como si fuera el host B, diciendo que la dirección de red del host B es la del mismo router R.

El host A recibe esta respuesta ARP, la pone en su caché y enviará futuros paquetes IP para el host B hacia el router R. El router enviará tales paquetes a la subred correcta.

El resultado es subnetting transparente:

Los hosts normales (tales como A y B) no saben subnetting, así que usan el algoritmo de enrutamiento IP "old".

Los routers entre subredes tienen que:

1. Usar el algoritmo IP "subnet".

2. Usar un módulo ARP modificado, que puede responder en beneficio de otro hosts.

EnrutamientoEnrutamiento es el proceso de dirigir un paquete a través de la red desde una máquina origen a otro destino. La idea es enviar los paquetes a algún sitio donde pueden tener más información de cómo llegar al destino deseado.

La información de enrutamiento se construye en una tabla de reglas del tipo:

[Red de Destino], [Mascara de Red de Destino], [Interfaz de Salida], con un costo de 1 salto.

Asimismo existe una ruta por defecto donde se envían todos los paquetes destinados a redes para las cuales no tenemos rutas explícitas.

La tabla de ruteo se recorre de lo más específico a lo más general. Si no hay ruta específica para dirigirse a un destino y no hay ruta por defecto, el sistema enviará un mensaje de "network unreacheable". Esta especificidad se determina por el largo de la máscara. Cuanto más cantidad de unos tenga la máscara, más específica será la ruta.

Desde el punto de vista del enrutamiento IP, toda la información necesaria se almacena en la tabla de ruteo. En el caso de las distribuciones Linux, el contenido de las tablas puede variar pero siempre mantendrá la información de enrutamiento necesaria.

En un FreeBSD, por ejemplo la salida resumida del comando netstat -rn sería:

# netstat -rnRouting tablesInternet:Destination Gateway Flags Refs Use Netif Expiredefault 164.73.224.28 UGSc 33 36932 ed1127.0.0.1 127.0.0.1 UH 16 45450 lo0.....164.73.224/25 link#1 UC 0 0164.73.224.1 8:0:2b:14:a1:21 UHLW 5 198078 ed1 1039164.73.224.40 48:54:e8:26:db:69 UHLW 1 1908914 lo0164.73.224.60 0:0:21:95:90:34 UHLW 4 0 ed1 840164.73.224.128 164.73.224.60 UGHD 0 2 ed1164.73.224.130 164.73.224.60 UGHD 0 801 ed1.....

En un Linux RedHat, por ejemplo la salida del comando netstat -rn sería de la forma:

17 ludmilla ~ >netstat -rnKernel IP routing tableDestination Gateway Genmask Flags MSS Window irtt Iface164.73.224.76 0.0.0.0 255.255.255.255 UH 0 0 0 eth0164.73.224.0 0.0.0.0 255.255.255.128 U 0 0 0 eth0127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo0.0.0.0 164.73.224.28 0.0.0.0 UG 0 0 0 eth0

Las rutas pueden ser estáticas o dinámicas. Las rutas estáticas se establecen manualmente con el comando route.Las rutas Dinámicas pueden modificarse a través de un demonio que se comunica con otros enrutadores intercambiándose información para actualizar las tablas.

Protocolos de Enrutamiento o EncaminamientoLos protocolos de enrutamiento son el lenguaje en que los demonios de ruteo intercambian información acerca de la red.Se clasifican en:

Protocolos de enrutamiento exterior (IGP) Protocolos de enrutamiento exterior (EGP)

Los IGP se usan al interior de lo que se llaman sistemas autónomos que son un conjunto de máquinas administradas por una autoridad común. Los EGP se usan entre sistemas autónomos. La diferencia es que los IGP tratan de optimizar el enrutamiento entre una red compleja con muchos caminos alternativos y los EGP tratan de optimizar el enrutamiento teniendo en cuenta que los caminos son normalmente pocos porque los sistemas autónomos se interconectan entre sí con pocos enlaces.

Los diferentes protocolos utilizan distintas métricas para estimar el costo de cada ruta. Los costos pueden medirse en saltos, retardo, etc. Los EGP en general no toman demasiado en cuenta los costos porque normalmente no hay demasiadas rutas alternativas pero si tratan de optimizar la posibilidad de alcanzar una determinada red.

Hay varios protocolos utilizados comúnmente. Algunos de ellos son:

RIP - Routing Information Protocol

OSPF - Open Shortest Path First

IGRP - Interior Gateway Routing Protocol

EGP - Exterior Gateway Protocol

BGP - Border Gateway Protocol

RIP es el protocolo usado por el demonio routed estándar en UNIX. El costo de las rutas se mide en saltos, donde cada salto es un enrutador por el cual pasan los paquetes. Hay dos versiones: la 1 no tiene soporte para máscaras y la 2 sí.

OSPF funciona bien en redes grandes y es más difícil de configurar. IGRP (Posteriormente EIGRP), es un protocolo propietario de Cisco previo al OSPF, el cual fue liberado por Cisco en febrero de éste año.

El estándar actual de EGP es el protocolo BGP en su versión 4.

ConclusionesComo se pudo observar en la investigación que se realizó sobre los temas tratados, podemos ver como se interrelacionan en cuanto a los protocolos que forman el protocolo TCP/IP, que no es más que la agrupación de varios para poder brindar los servicios de conexión y comunicación entre dispositivos que se pueden encontrar en una red de computadoras local o bien una red conectada a través de varios continentes, esto hoy en día es muy utilizado por compañías o empresas muy grandes o bien transnacionales.

Lo que la familia de protocolos TCP/IP busca es la mejor interconexión de equipos, con tiempo reducidos, pero no dejando a un lado la calidad en el servicio, conexión, transmisión entre otros, ya que por medio de esta familia hoy en día podemos trasladar información, video y multimedia, lo cual ha venido a contribuir en varios campos de la sociedad, porque no solamente se ha beneficiado el sector empresarial, sino que hay una infinidad de campos beneficiados entre los cuales se pueden mencionar la educación, la medicina, etc.

Enlaceshttp://personales.upv.es/rmartin/TcpIp/cap02s08.html

http://www4.uji.es/~al019803/tcpip/paginas/CapaFisica.htm

http://es.wikipedia.org/

Presentación