Protocolo de control de mensajes de Internet
Protocolo de mensajes de control de Internet | ||||||
---|---|---|---|---|---|---|
Familia | Familia de protocolos de Internet | |||||
Función | Control y notificación de errores del Protocolo de Internet | |||||
Puertos | 1 | |||||
Ubicación en la pila de protocolos | ||||||
| ||||||
Estándares | ||||||
RFC 792 (1981) | ||||||
[editar datos en Wikidata] |
El protocolo de mensajes de control de Internet (en inglés: Internet Control Message Protocol y conocido por sus siglas ICMP) es parte del conjunto de protocolos IP. Es utilizado para enviar mensajes de error e información operativa indicando, por ejemplo, que un host no puede ser localizado o que un servicio que se ha solicitado no está disponible. Estos mensajes del protocolo ICMP se envían a la dirección IP de origen del paquete.
Siendo un protocolo de la "Capa de Red" ICMP difiere de los protocolos de la "Capa de Transporte" (tales como TCP y UDP), en que no es generalmente usado para intercambiar información entre sistemas, ni tampoco por las aplicaciones de usuario (con excepción de algunas herramientas como ping y traceroute, que emplean mensajes ICMP con fines de diagnóstico).
Aspectos técnicos
Bit 0 7 | Bit 8 15 | Bit 16 23 | Bit 24 31 |
---|---|---|---|
Tipo | Código | Suma de verificación | |
Datos (opcional) |
Este protocolo es parte del conjunto de protocolos IP, y de esa manera se lo define en la RFC 792. Los mensajes ICMP son comúnmente empleados con fines de diagnóstico y control, o generados en respuesta a errores en las operaciones IP (como se especifica en el RFC 1122), y se envían a la dirección IP de origen del paquete que dio lugar a la generación del mensaje ICMP.
La versión de ICMP para IPv4 también es conocida como ICMPv4. IPv6 tiene su protocolo equivalente ICMPv6.
El protocolo se emplea cuando un host no puede ser alcanzado, cuando el tiempo de vida de un paquete ha expirado, cuando un servicio solicitado no está disponible, etc. Es decir, se usa para manejar mensajes de error y control necesarios en los sistemas de red informando a la fuente original para que evite o corrija el problema detectado.
A modo de ejemplo, cada router que reenvía un datagrama IP tiene que disminuir el campo de tiempo de vida (TTL) de la cabecera IP en una unidad; si el TTL llega a cero, un mensaje ICMP tipo 11 ("Tiempo excedido") es enviado al originador del datagrama.
Los mensajes ICMP son construidos en el nivel de la "Capa de Red". Así, IP encapsula el mensaje ICMP con una nueva cabecera (para obtener los mensajes de respuesta desde el host original), y transmite el datagrama resultante de la manera habitual. Cada mensaje ICMP es encapsulado en un solo datagrama IP, por lo que la entrega del mismo no está garantizada.
Si bien ICMP emplea el soporte básico de IP como si fuese un protocolo de más alto nivel es, en realidad, una parte integral de IP. A pesar de estar encapsulados en paquetes comunes, los mensajes ICMP habitualmente se procesan de forma especial recibiendo un tratamiento diferente al del procesamiento IP normal. En muchos casos es necesario analizar el contenido del mensaje ICMP para determinar el tipo de error apropiado que debe enviarse a la aplicación responsable de transmitir el paquete IP que solicitara el envío del mensaje ICMP.
Muchas de las utilidades de red comunes están basadas en los mensajes ICMP. El comando traceroute puede implementarse transmitiendo datagramas con valores especiales de TTL en la cabecera, y analizando luego los mensajes de "Destino inalcanzable" y "Tiempo excedido" (tipos 3 y 11) generados como respuesta. La herramienta ping está implementada utilizando los mensajes "Echo request" y "Echo reply" de ICMP.
Estructura de un segmento ICMP
El ICMP inicia después del IPv4 cabecera 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 primeros 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 datos del paquete IP que ha causado el mensaje de error. El paquete ICMP es encapsulado en un nuevo paquete IP.
Bits 0-7 8-15 16-23 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.
Mensajes de Control
Echo Reply
Un Echo Reply (Respuesta de Eco) en el protocolo ICMP es un mensaje generado como respuesta a un mensaje Echo Request (petición de Eco).
Formato del Mensaje:
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 0 | Código = 0 | Checksum | |||||||||||||||||||||||||||||
Identificador | Número de secuencia | ||||||||||||||||||||||||||||||
Datos ::: |
- El tipo y el código deben ser 0.
- El identificador y el número de secuencia pueden ser usados por el cliente para asociar cada Echo Request a cada Echo Reply.
- Los datos incluidos en el Echo Request deben estar siempre en los datos del Echo Reply.
Destination Unreachable
Destination Unreachable es un tipo de paquete ICMP cuya función es transportar un mensaje que es generado por un enrutador, y se envía al host de origen, que recibe el mensaje emitido por el enrutador.
El mensaje en sí significa que este router considera inalcanzable el destino al que quiere llegar el host.
Si se recibe de parte del host de destino, significa que el protocolo que se intentó acceder no está activo en aquel momento.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 3 | Código | Checksum | |||||||||||||||||||||||||||||
Identificador | Número de secuencia | ||||||||||||||||||||||||||||||
Datos ::: |
El campo Type tiene el valor 3. El campo código contendrá alguno de los siguientes valores:
Código | Descripción |
---|---|
0 | Network unreachable |
1 | Host unreachable |
2 | Protocol unreachable |
3 | Port unreachable |
4 | Fragmentation needed, but do not fragment bit set |
5 | Source route failed |
6 | Destination network unknown |
7 | Destination host unknown |
8 | Source host isolated error (military use only) |
9 | The destination network is administratively prohibited |
10 | The destination host is administratively prohibited |
11 | The network is unreachable for Type Of Service |
12 | The host is unreachable for Type Of Service |
13 | Communication administratively prohibited (administrative filtering prevents packet from being forwarded) |
14 | Host precedence violation (indicates the requested precedence is not permitted for the combination of host or network and port) |
15 | Precedence cutoff in effect (precedence of datagram is below the level set by the network administrators) |
Fuente Saciable
La Fuente Saciable: las peticiones que provienen del remitente disminuyen su velocidad sobre la base de los mensajes enviados a un host o router. Este mensaje se puede generar si un router o host esta deficiente en espacio de búfer para procesar esta solicitud, o puede ocurrir que el bufer del host o enrutador este llegando a su límite.
La información es enviada a una velocidad muy alta que parte de un anfitrión o de varios host al mismo tiempo hacia un enrutador en particular perteneciente a la red. Aunque un router tiene capacidades de almacenamiento en búfer, esta se limita dentro de un rango en específico. El enrutador no puede colocar más datos que se excedan de la capacidad de almacenamiento que provee el búfer. De esta forma, si la cola se llena, las informaciones se descartan hasta que la cola ya no este saturada. Pero como no hay mecanismos de confirmación está presente en la capa de red, el usuario no tiene conocimiento si la información ha llegado a su destino con éxito. De ahí algunas medidas correctivas deben ser tomadas por medio de la capa de red para prevenir estos tipos de situaciones. Estas medidas se refieren como fuente de amortiguación. En un mecanismo de enfriamiento fuente, el enrutador considera que la tasa de datos entrantes es más rápido que la velocidad de datos de salida, y envía un mensaje ICMP a los clientes, informándoles deben frenar su velocidad de transferencia de datos o esperar una cantidad de tiempo para enviar nuevamente datos. Al usuario recibir esta notificación automáticamente se desacelerara la velocidad de datos salientes o quedara en espera hasta que pase suficiente cantidad de tiempo lo que le permitirá al router vaciar la cola. Por lo tanto fuente saciar mensaje ICMP actos como el control de flujo en la capa de red.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 4 | Código = 0 | Encabezado | |||||||||||||||||||||||||||||
Sin Uso | |||||||||||||||||||||||||||||||
Cabecera de IP y 8 primeros bytes de datos del datagrama original |
Donde Tipo debe establecerse en 4 Código debe establecerse en 0 Encabezado IP y los datos adicionales es utilizado por el emisor para que coincida con la respuesta a la solicitud correspondiente
Redirecciones
Redirect solicita que los paquetes de datos se envíen en una ruta alternativa. ICMP Redirect es un mecanismo para enrutadores para transferir datos del router a los hosts. El mensaje informa al receptor (hosts) que actualice su información de enrutamiento. Si un anfitrión intenta enviar información a través del router 1 y el router 1 envía la información al router 2 y una ruta directa desde el host al router 2 está disponible (es decir, el anfitrión y el router 2 están en el mismo segmento de Ethernet), entonces el router 1 enviará una notificación de redirección para informar al host que el mejor trayecto para cumplir su destino es a través del router 2. Entonces el anfitrión debe enviar paquetes directamente al router 2. Y este intentará enviar el original datagrama al destino previsto. Sin embargo, si el datagrama contiene datos del enrutamiento, no se enviará esta notificación incluso si hay mejores caminos disponibles.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 5 | Código | Cabecera | |||||||||||||||||||||||||||||
Dirección IP | |||||||||||||||||||||||||||||||
IP cabecera y los primeros 8 bytes del datagrama original |
Donde:
- Tipo Establecerse en 5.
- Código Especifica el motivo de la redirección, puede ser uno de los siguientes:
Código Descripción 0 Redirección de la Red 1 Redirección para el Host 2 Redirección del Tipo de Servicio y de Red 3 Redirección para el Tipo de Servicio y el Host
- Dirección IP Es la dirección de 32 bits de la puerta de entrada a la de la dirección en la cual debe ser enviada.
- IP de Cabecera Son los datos adicionales que se incluyen para permitir que el host coincida con la respuesta a la solicitud de redirección.
Echo Request
El Echo Request (Petición eco) es un mensaje de control que se envía a un host con la expectativa de recibir de él un Echo Reply (Respuesta eco). Esto es conocido como Ping y es una utilidad del protocolo ICMP, subprotocolo de IP. Todo host debe responder a un Echo Request con un Echo Reply que contenga exactamente los mismos datos que el primero.
Formato del mensaje:
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo = 8 | Código = 0 | Checksum | |||||||||||||||||||||||||||||
Identificador | Número de secuencia | ||||||||||||||||||||||||||||||
Datos ::: |
- El tipo debe ser 8.
- El código debe ser 0.
- El identificador y el número de secuencia pueden ser usados por el cliente para asociar cada Echo Request a cada Echo Reply.
- Los datos incluidos en el Echo Request deben estar siempre en los datos del Echo Reply.
Tiempo Excedido
El Tiempo excedido se crea por una puerta de enlace para informar a la fuente de un datagrama debido al tiempo de vida de campo al llegar a cero. Un mensaje sobrepasando el tiempo también puede ser enviado por un host si no logra volver a montar una fragmentación de datagramas dentro de su límite de tiempo.
Los mensajes del tiempo excedido son utilizados por la Ruta de Seguimiento de utilidad para identificar las puertas de enlace en el cambio de los anfitriones.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 11 | Código | Cabecera | |||||||||||||||||||||||||||||
Sin uso. | |||||||||||||||||||||||||||||||
IP cabecera y los primeros 8 bytes del datagrama original |
Donde:
- Tipo debe establecerse en 11
- Código especifica la razón del mensaje de tiempo excedido, se incluyen los siguientes puntos:
Código Descripción 0 Tiempo de Vida Excedido en el tránsito 1 Tiempo excedido en el Fragmento re ensamblaje.
El IP cabecera y los primeros 64 bits de la carga original útil son utilizados por el host de origen para que coincida con el mensaje de tiempo excedido para el datagrama descartado. Para los protocolos de nivel superior, tales como UDP (Datagrama de Protocolo de Usuario) y TCP (Protocolo de Control de Transmisión) el bit de carga útil de 64 bits incluirá la fuente y puertos de destino del paquete descartado.
Timestamp
[1] Timestamp Es usada para la sincronización de tiempo. Consiste en el origen del timestamp
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 13 | Código= 0 | Cabecera | |||||||||||||||||||||||||||||
Identificador | Número de Secuencia | ||||||||||||||||||||||||||||||
Crea un timestamp |
Donde:
- Tipo debe establecerse en 13
- Código debe establecerse en 0
- Identificador y número de secuencia puede ser utilizado por el cliente para que coincida con la marca de tiempo respuesta a la solicitud de marca de hora.
- Crear un timestamp es el número de milisegundos desde la media noche Horario Universal (UT). Si una referencia UT no está disponible el bit más significativo se puede configurar para indicar un valor de tiempo no estándar.
Respuesta Timestamp
Respuesta a una timestamp del mensaje. Se compone de la timestamp originario enviado por el remitente del timestamp, así como una timestamp y así recibir una timestamp de la transmisión.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 14 | Código= 0 | cabecera | |||||||||||||||||||||||||||||
Identificador | Número de Secuencia | ||||||||||||||||||||||||||||||
Crea un timestamp | |||||||||||||||||||||||||||||||
Recibe un timestamp | |||||||||||||||||||||||||||||||
Transmite un timestamp |
Donde:
- Tipo Debe establecerse en 14
- Códigio De establecerse en 0
- Idenficador y Número de Secuencia puede ser utilizado por el cliente para que coincida con la respuesta a la solicitud que hizo.
- Crear un timestamp es la última vez que el remitente toco el mensaje antes de enviarlo.
- Recibe timestamp es el momento en el cual el generador de ecos recibió el mensaje de solicitud.
- Transmite un timestamp es el momento en el cual el generador de ecos tocó el mensaje por última vez antes de enviarlo.
Todos los timestamp son en unidades de milisegundos desde la medianoche UT. Si el tiempo no está disponible en milisegundos o no puede ser proporcionado con respecto a la medianoche UT entonces cualquier momento se puede insertar en una timestamp siempre y cuando que el bit de orden superior del timestamp también se establezca como indicador del valor estándar.
Solicitud de Dirección de Máscara
se envía normalmente por un host a un router con el fin de obtener una adecuada Máscara de Subred. Los remitentes deben responder este mensaje con una Solicitud de Dirección de Máscara.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 17 | Código= 0 | Checksum | |||||||||||||||||||||||||||||
Identificador | Número de Secuencia | ||||||||||||||||||||||||||||||
Dirección de Máscara |
Donde:
- Tipo debe establecerse en 17
- Código debe establecerse en 0
- Dirección de Máscara puede ajustarse en 0
ICMP Solicitud de Dirección de Máscara puede ser usada como parte de un proceso de reconocimiento para recabar información sobre la red de destino, por lo tanto, ICMP Solicitud de Dirección de Máscara está desactivando por defecto en Cisco IOS. [2]
Respuesta a la Dirección de Máscara
La Respuesta a la Dirección de Máscara se utiliza para responder a un mensaje de petición de dirección de máscara con una máscara de subred adecuada.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 18 | Código= 0 | Checksum | |||||||||||||||||||||||||||||
Identificador | Número de Secuencia | ||||||||||||||||||||||||||||||
Dirección de Máscara |
Donde:
- Tipo debe establecerse 18
- Código debe establecerse en 0
- Dirección de Máscara debe establecerse en la máscara de subred
Destino de Mensaje Inalcanzable
El Destino Inalcanzable se genera por el host o en la puerta de enlace entrante para informar al cliente de que el destino es inalcanzable por alguna razón. Un mensaje de destino inalcanzable se puede generar como resultado de un TCP, UDP o ICMP u otra transmisión. Los Puertos TCP inalcanzables sobre todo responden con TCP RST en lugar de un tipo de destino inalcanzable 3 como era de esperar.
El error no se génera si el datagrama original tiene un IP Multicast[3] de dirección de destino. Las razones para este mensaje pueden incluir: la conexión física con el host no existe (la distancia es infinita), el protocolo indicado o el puerto no está activo, los datos deben ser fragmentados pero el marcador "no fragmentar" está activo.
00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tipo= 3 | Código | Encabezado | |||||||||||||||||||||||||||||
Sin uso | Siguiente salto MTU | ||||||||||||||||||||||||||||||
IP cabecera y los 8 primeros bytes de datos del datagrama original. |
Donde:
- Tipo campo(bits 0-7) debe establecerse en 3
- Código campo(bits 8-15) es utilizado para especificar un tipo de error.
Encapsulación
[4]
Un mensaje ICMP se encapsula en IP:
Cabecera L2 | Cabecera IP | Cabecera ICMP | Datos....
Cabecera ICMP
ICMP se puede utilizar para transmitir diferentes tipos de mensajes de gestión, que se identifican principalmente por el tipo y el código correspondiente.
Bit del Mensaje:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Código | Cabecera de comprobación ICMP | Datos....
Formato del Protocolo
Lista de mensajes de control permitidos (incompleta):
- 0 - Echo Reply
- 1 - Reservado
- 2 - Reservado
- 3 - Destination Unreachable
- 4 - Source Quench
- 5 - Redirect Message
- 6 - Dirección Alterna de Host
- 7 - Reservado
- 8 - Echo Request (Ping)
- 9 - Anuncio de Router
- 10 - Solicitud de Router
- 11 - Tiempo Excedido
- 12 - Problema de Parámetro
- 13 - Marca de tiempo
- 14 - Respuesta de Marca de tiempo
- 15 - Petición de Información
- 16 - Respuesta de Información
- 17 - Petición de Máscara de Dirección
- 18 - Respuesta de Máscara de Dirección
- 19 - Reservado para seguridad
- 20-29 - Reservado para experimentos de robustez
- 30 - Traceroute
- 31 - Error de Conversión de Datagrama
- 32 - Redirección de Host Móvil
- 33 - IPv6
- 34 - IPv6
- 35 - Petición de Registro de Móvil
- 36 - Respuesta de registro de Móvil
- 37 - Petición de Nombre de Dominio
- 38 - Respuesta de Nombre de Dominio
- 39 - SKIP Protocolo de Algoritmo de Descubrimiento
- 40 - Photuris, Fallas de Seguridad
- 41 - Mensajes ICMP utilizados por protocolos de seguridad como Seamoby
- 42 - Extended Echo Request
- 43 - Extended Echo Reply
- 44-252 — Unassigned
(Fuente: IANA ICMP Parameters)
Referencias
- ↑ timestamp( http://en.wikipedia.org/wiki/Timestamp)
- ↑ «Cisco IOS IP Command Reference, Volume 1 of 4: Addressing and Services, Release 12.3 - IP Addressing and Services Commands: ip mask-reply through ip web-cache». Cisco Systems. Archivado desde el original el 2 de enero de 2013. Consultado el 7 de enero de 2013.
- ↑ Multicast( http://en.wikipedia.org/wiki/Multicast)
- ↑ it:ICMP(http://it.wikipedia.org/wiki/Internet_Control_Message_Protocol#Incapsulamento)
Enlaces externos
- RFC0792: Protocolo ICMP (en español)
Datos: Q13162
Multimedia: ICMPv4 / Q13162