ICMP (Internet Control Message Protocol) – это протокол в компьютерных сетях, который используется для отправки сообщений об ошибках и для проверки доступности узлов в сети. В этой статье мы рассмотрим, что такое ICMP и как он работает на роутере.
ICMP предназначен для передачи сообщений об ошибках или различных событиях, происходящих в инфраструктуре сети. Он позволяет контролировать состояние сети, обнаруживать и устранять проблемы соединения.
Когда роутер получает пакет данных, он проверяет его на целостность и правильность доставки. Если пакет содержит ошибку или роутер не может доставить его по причинам сетевых проблем, то ICMP может сгенерировать и отправить сообщение об ошибке обратно отправителю.
Например, если вы пытаетесь получить доступ к веб-сайту, но не можете подключиться, ваш компьютер может отправить ICMP-сообщение об ошибке обратно вашему компьютеру, указывая, что сервер недоступен.
ICMP также используется для проверки доступности узлов в сети. Например, при отправке пинга на определенный IP-адрес, ваш компьютер отправляет ICMP-запрос на этот адрес. Если узел доступен, то он отправит ICMP-ответ обратно, указывая, что он доступен и готов к обмену данными.
Таким образом, ICMP играет важную роль в обнаружении и устранении проблем в компьютерных сетях, позволяя роутерам и хостам обмениваться информацией об ошибках и доступности узлов.
Содержание
- Что такое ICMP на роутере?
- Описание и сущность протокола ICMP
- Как работает ICMP на роутере?
- Основные принципы функционирования ICMP на роутерах
- Преимущества использования ICMP на роутере
Что такое ICMP на роутере?
ICMP используется для отправки различных типов сообщений, включая запросы эха (ping), сообщения о времени жизни (TTL) и маршрутных сообщений. Эти сообщения помогают роутерам и другим устройствам обнаруживать и исправлять ошибки в сети, проверять доступность узлов, определять оптимальный маршрут для передачи пакетов и другие функции.
ICMP на роутере работает следующим образом. Когда роутер получает пакет сетевых данных, он может проверить, доставлен ли пакет назначенному адресату, а также обнаружить, на каком этапе пакет может быть испорчен или потерян. Роутер может отправить ICMP-сообщение, содержащее информацию об ошибке, обратно отправителю пакета.
ICMP также используется для определения оптимального маршрута передачи пакетов. Роутеры могут обмениваться ICMP-сообщениями для обновления друг друга о изменении состояния сети, чтобы определить наилучший путь для доставки пакетов.
Тип сообщения | Описание |
---|---|
0 | Запрос эха (ping) |
3 | Сообщение об ошибке |
11 | Сообщение о времени жизни (TTL) |
30 | Маршрутное сообщение |
Таким образом, ICMP на роутере играет важную роль в обнаружении и устранении ошибок в сети, а также в определении наилучшего маршрута для передачи пакетов. Он обеспечивает более эффективное и надежное функционирование сети Интернет.
Описание и сущность протокола ICMP
ICMP используется для решения различных задач, включая проверку доступности узлов, определение маршрутов и передачу сообщений об ошибках.
Сообщения ICMP имеют фиксированную структуру, которая включает в себя заголовок ICMP и данные, содержащие дополнительную информацию.
Протокол ICMP широко используется при выполнении утилиты Ping для определения доступности узлов и оценки качества сетевого соединения. ICMP также используется для передачи сообщений об ошибках, таких как «Host Unreachable» или «Time Exceeded».
Протокол ICMP работает на сетевом уровне модели OSI и взаимодействует с другими протоколами, такими как IP (Internet Protocol).
Как работает ICMP на роутере?
Протокол ICMP работает на основе отправки и получения специальных контрольных сообщений, называемых ICMP-пакетами. На роутере, ICMP может выполнять следующие функции:
- Обнаружение недоступности узла: Если роутер пытается отправить пакет данных на определенный узел, но не получает ответа, он может отправить ICMP-сообщение, указывающее на недоступность этого узла. Это помогает определить проблемы в сети и маршрутизации.
- Перенаправление пакетов: Роутеры также могут использовать ICMP для отправки сообщений о необходимости изменить путь передачи пакетов. Если роутер обнаруживает, что сетевой путь для доставки пакетов не оптимален, он может отправить ICMP-сообщение с новым маршрутом.
- Определение MTU: Роутеры и устройства в сети могут использовать ICMP для определения максимального размера пакета, который может быть передан без фрагментации. Если роутер обнаруживает, что пакеты превышают максимально допустимый размер, он отправит ICMP-сообщение с требованием уменьшить размер пакета или включить фрагментацию данных.
- Тестирование связности: ICMP-пакеты также могут использоваться для тестирования связи между устройствами в сети. Например, при выполнении команды ping, роутер отправляет ICMP-пакет на указанный IP-адрес и ожидает ответа. Если получен ответ, это указывает на работоспособность связи.
Если роутер получает ICMP-сообщения, он может реагировать на них разными способами, включая отправку ICMP-ответов или принятие соответствующих действий согласно полученной информации.
Основные принципы функционирования ICMP на роутерах
В основе работы ICMP лежит отправка сообщений-запросов и получение ответов с целью проверки доступности узлов сети или уведомления об ошибке. Роутеры играют важную роль в обработке и пересылке этих сообщений.
Когда роутер принимает пакет данных, он может сгенерировать и отправить ICMP-сообщение, чтобы уведомить отправителя об ошибке или состоянии сети. Обычные типы ICMP-сообщений включают в себя эхо-запросы (ping) и эхо-ответы (pong), сообщения о недоступности хоста или сети, сообщения о превышении времени жизни пакета и другие.
ICMP также используется для обработки ошибок в IP-сети, таких как недоставляемые пакеты или недоступные маршруты. Роутеры могут отправлять ICMP-сообщения, чтобы уведомить отправителя об этих ошибках и помочь восстановить связь.
Роутеры также могут отвечать на входящие ICMP-сообщения, чтобы сообщить отправителю об успешной доставке пакетов или о других состояниях сети. Это помогает в установлении и поддержании связи между узлами сети.
В целом, ICMP на роутерах играет важную роль в обнаружении и устранении проблем сети, обмене информацией об ошибке и обеспечении надежной коммуникации между узлами сети.
Преимущества использования ICMP на роутере
1. Отслеживание доступности хостов: ICMP используется для отправки эхо-запросов (ping) с целью проверки доступности узлов в сети. Роутеры могут регулярно отправлять ICMP-запросы к определенным хостам для определения их доступности и в случае, если хост не отвечает, изменять маршруты или принимать другие действия для обеспечения непрерывной работы сети.
2. Разрешение проблем со сетью: ICMP также используется для отправки различных сообщений об ошибках, таких как сообщение «недостижимости сети». Роутеры могут использовать эти сообщения, чтобы идентифицировать и исправить проблемы в сети, такие как некорректные настройки маршрутизации или недоступность определенных узлов.
3. Поддержка межсетевых протоколов: ICMP предоставляет некоторые сервисы и функции, которые не доступны другим протоколам. Например, маршрутизаторы используют ICMP для отправки сообщений об ошибке, когда пакет не может быть доставлен. Это позволяет узлам на другом конце понять причины сбоев доставки и принять соответствующие меры.
4. Более эффективная маршрутизация: ICMP и его подпротоколы, такие как ICMP Redirect, используются для улучшения производительности и эффективности маршрутизации. ICMP Redirect-сообщения позволяют роутерам информировать хосты о лучших маршрутах, что позволяет избежать избыточных пересылок и повысить скорость и надежность доставки пакетов.
В целом, использование ICMP на роутере является важной составляющей сетевого протоколирования и обеспечивает более надежную и эффективную работу сети.
4 minute read
Internet Control Message Protocol или просто ICMP описан в RFC 792. Данный протокол определяет набор различных сообщений, целью которых является управление сетью.
ICMP сообщения могут классифицироваться как сообщения об ошибках, а также как сообщения типа “запрос — ответ”.
graph TD
C{ICMP}
C —> D[Error message]
C —> E[Query-Response]
Ниже представлен основной формат пакета ICMP
Пакеты ICMP определяются по их типу (Type), однако, большинство типов могут иметь более специфичные типы, они определяются по полю Code. RFC 1700 определяет все основные типы и коды для протокола ICMP.
В следующей таблице перечислены данные поля с их описанием
Тип | Код | Название |
---|---|---|
0 | 0 | Echo Reply |
3 | DESTINATION UNREACHABLE | |
0 | Network Unreachable | |
1 | Host Unreachable | |
2 | Protocol Unreachable | |
3 | Port Unreachable | |
4 | Fragmentation Needed and Don’t Fragment Flag Set | |
5 | Source Route Failed | |
6 | Destination Network Unknown | |
7 | Destination Host Unknown | |
8 | Source Host Isolated | |
9 | Destination Network Administratively Prohibited | |
10 | Destination Host Administratively Prohibited | |
11 | Destination Network Unreachable for Type of Service | |
12 | Destination Host Unreachable for Type of Service | |
4 | 0 | SOURCE QUENCH (deprecated) |
5 | REDIRECT | |
0 | Redirect Datagram for the Network (or Subnet) | |
1 | Redirect Datagram for the Host | |
2 | Redirect Datagram for the Network and Type of Service | |
3 | Redirect Datagram for the Host and Type of Service | |
6 | 0 | ALTERNATE HOST ADDRESS |
8 | 0 | ECHO |
9 | 0 | ROUTER ADVERTISEMENT |
10 | 0 | ROUTER SELECTION |
11 | TIME EXCEEDED | |
0 | Time to Live Exceeded in Transmit | |
1 | Fragment Reassembly Time Exceeded | |
12 | PARAMETER PROBLEM | |
0 | Pointer Indicates the Error | |
1 | Missing a Required Option | |
2 | Bad Length | |
13 | 0 | TIMESTAMP |
14 | 0 | TIMESTAMP REPLY |
15 | 0 | INFORMATION REQUEST (Obsolete) |
16 | 0 | INFORMATION REPLY (Obsolete) |
17 | 0 | ADDRESS MASK REQUEST (Near-Obsolete) |
18 | 0 | ADDRESS MASK REPLY (Near-Obsolete) |
30 | — | Traceroute |
Данную информацию не следует учить, как и другую представленную в статьях, главное научиться понимать что это и для чего используется, остальное приходит с опытом работы. Тем более, что вся представленная информация общедоступна каждому из нас бесплатно.
Одни из наиболее часто встречающихся примеров ICMP сообщений являются Echo
и Reply
. По ссылке можно скачать дамп, показывающий выполнение команды ping в сторону адреса 8.8.8.8. Ниже будут представлены вырезки Echo
и Reply
из данных дампов.
Далеко не все типы пакетов ICMP можно встретить сегодня в современных сетях, но некоторые из них имеют важное значение для функционала маршрутизации, например, редирект — ICMP Type 5.
Данный тип используется маршрутизаторами для уведомления других устройств о том, что для данного адреса назначения в текущей канальной среде следует использовать другой маршрутизатор.
Предположим, что в одной канальной среде с конечным устройством есть два маршрутизатора Router-London
и Router-Moscow
. Маршрутизатор Router-Moscow
является шлюзом по умолчанию для конечного устройства. Конечное устройство отправляет пакет на маршрутизатор Router-Moscow
, в свою очередь маршрутизатор Router-Moscow
имеет достижимость адреса на который отправил конечный хост через маршрутизатор Router-London
.
Получается, что маршрутизатор Router-Moscow
должен отправить пакет в тот же самый интерфейс на котором он получил изначальный пакет. Маршрутизатор Router-Moscow
отправляет пакет маршрутизатору Router-London
, а также отправляет сообщение ICMP Redirect конечному устройству, информируя его о том, что все следующие пакеты он должен отправлять непосредственно через маршрутизатор Router-London
(имеется в виду только до сети, куда был отправлен первый пакет, все пакеты до других сетей отправляются также на шлюз по умолчанию)
Практика
Рассмотрим пример с ICMP Redirect на практике. Имеется простая схема с двумя маршрутизаторами в одной канальной среде
Вся адресация представлена на схеме. В качестве простоты эксперимента рассмотрим ситуацию когда клиент будет отправлять пинг на адрес внешнего интерфейса маршрутизатора Router-London
, маршрутизатор Router-Moscow
является шлюзом для клиента.
На маршрутизаторе Router-Moscow
дополнительно настроен статический маршрут до сети 172.17.0.0/24 через адрес внутреннего интерфейса маршрутизатора Router-London
.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Router_Moscow# show ip route static Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is not set 172.17.0.0/24 is subnetted, 1 subnets S 172.17.0.0 [1/0] via 192.168.1.254 Router_Moscow#Включив дебаг на маршрутизаторе
Router-Moscow
с помощью командыdebug ip icmp
, можно заметить как данный маршрутизатор отправляет сообщение ICMP Redirect клиенту.
1 2 3 4 5 Router_Moscow# debug ip icmp ICMP packet debugging is on Router_Moscow# *Oct 9 11:46:43.504: ICMP: redirect sent to 192.168.1.100 for dest 172.17.0.254, use gw 192.168.1.254 Router_Moscow#При этом первый пакет на клиенте потеряется из-за того, что маршрутизатор
Router-London
не будет знать куда отправлять ответ на первый ICMP Request клиента, т.к. его кэш ARP будет пуст и ему придется отправить ARP Request чтобы узнать MAC-адрес клиента.
Потеря первого пакета при пинге клиента
Для того чтобы убедиться в правдивости моих слов предлагаю скачать дампы с двух интерфейсов маршрутизатора
Router-London
иRouter-Moscow
и посмотреть весь процесс самим.Помните: так как все устройства находятся в общей широковещательной среде, то все пакеты отправленные на широковещательный адрес
ffff.ffff.ffff
будут видны в каждом из дампов.Дамп с интерфейса gi0/0 маршрутизатора Router-Moscow
Дамп с интерфейса gi0/0 маршрутизатора Router-LondonПо умолчанию редирект включен на устройствах cisco. Данное поведение можно отключить на интерфейсе, выполнив команду
no ip redirects
P.S. вся информация представленная здесь используется исключительно в образовательных целях. Все совпадения с реальными объектами, адресами, именами и т.д. случайна и не несёт цели получить от этого выгоду или причинить кому-либо вред.
Back to top ↑
From Wikipedia, the free encyclopedia
This article is about the support protocol for IPv4 (ICMPv4). For ICMPv6, see ICMPv6.
Communication protocol | |
A general header for ICMPv4 |
|
Purpose | Auxiliary protocol for IPv4[1] |
---|---|
Developer(s) | DARPA |
Introduction | 1981 |
OSI layer | Network layer |
RFC(s) | RFC 792 |
The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address, for example, an error is indicated when a requested service is not available or that a host or router could not be reached.[2] ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications (with the exception of some diagnostic tools like ping and traceroute).
ICMP for IPv4 is defined in RFC 792. A separate ICMPv6, defined by RFC 4443, is used with IPv6.
Technical details[edit]
ICMP is part of the Internet protocol suite as defined in RFC 792. ICMP messages are typically used for diagnostic or control purposes or generated in response to errors in IP operations (as specified in RFC 1122). ICMP errors are directed to the source IP address of the originating packet.[2]
For example, every device (such as an intermediate router) forwarding an IP datagram first decrements the time to live (TTL) field in the IP header by one. If the resulting TTL is 0, the packet is discarded and an ICMP time exceeded in transit message is sent to the datagram’s source address.
Many commonly used network utilities are based on ICMP messages. The traceroute command can be implemented by transmitting IP datagrams with specially set IP TTL header fields, and looking for ICMP time exceeded in transit and Destination unreachable messages generated in response. The related ping utility is implemented using the ICMP echo request and echo reply messages.
ICMP uses the basic support of IP as if it were a higher-level protocol, however, ICMP is actually an integral part of IP. Although ICMP messages are contained within standard IP packets, ICMP messages are usually processed as a special case, distinguished from normal IP processing. In many cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the application responsible for transmitting the IP packet that prompted the ICMP message to be sent.
ICMP is a network-layer protocol, this makes it layer 3 protocol by the 7 layer OSI model. Based on the 4 layer TCP/IP model, ICMP is an internet-layer protocol, which makes it layer 2 protocol (internet standard RFC 1122 TCP/IP model with 4 layers) or layer 3 protocol based on modern 5 layer TCP/IP protocol definitions (by Kozierok, Comer, Tanenbaum, Forouzan, Kurose, Stallings).[citation needed] Forouzan and Kurose use network-layer instead of internet-layer in their TCP/IP model definition. These differences between models often lead to pointless and endless debates.[according to whom?]
There is no TCP or UDP port number associated with ICMP packets as these numbers are associated with the transport layer above.[3]
Datagram structure[edit]
The ICMP packet is encapsulated in an IPv4 packet.[2] The packet consists of header and data sections.
[edit]
The ICMP header starts after the IPv4 header and is identified by IP protocol number ‘1’.[4] All ICMP packets have an 8-byte header and variable-sized data section. The first 4 bytes of the header have fixed format, while the last 4 bytes depend on the type/code of that ICMP packet.[2]
Offsets | Octet | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octet | Bit | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
0 | 0 | Type | Code | Checksum | |||||||||||||||||||||||||||||
4 | 32 | Rest of header |
- Type
- ICMP type, see § Control messages.
- Code
- ICMP subtype, see § Control messages.
- Checksum
- Internet checksum (RFC 1071) for error checking, calculated from the ICMP header and data with value 0 substituted for this field.
- Rest of header
- Four-byte field, contents vary based on the ICMP type and code.
Data[edit]
ICMP error messages contain a data section that includes a copy of the entire IPv4 header, plus at least the first eight bytes of data from the IPv4 packet that caused the error message. The length of ICMP error messages should not exceed 576 bytes.[5] This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first eight bytes of the original datagram’s data.[6]
The variable size of the ICMP packet data section has been exploited. In the «Ping of death», large or fragmented ICMP packets are used for denial-of-service attacks. ICMP data can also be used to create covert channels for communication. These channels are known as ICMP tunnels.
Control messages[edit]
Control messages are identified by the value in the type field. The code field gives additional context information for the message. Some control messages have been deprecated since the protocol was first introduced.
Type | Code | Status | Description |
---|---|---|---|
0 – Echo Reply[6]: 14 | 0 | Echo reply (used to ping) | |
1 and 2 | unassigned | Reserved | |
3 – Destination Unreachable[6]: 4 [9] | 0 | Destination network unreachable | |
1 | Destination host unreachable | ||
2 | Destination protocol unreachable | ||
3 | Destination port unreachable | ||
4 | Fragmentation required, and DF flag set | ||
5 | Source route failed | ||
6 | Destination network unknown | ||
7 | Destination host unknown | ||
8 | Source host isolated | ||
9 | Network administratively prohibited | ||
10 | Host administratively prohibited | ||
11 | Network unreachable for ToS | ||
12 | Host unreachable for ToS | ||
13 | Communication administratively prohibited | ||
14 | Host Precedence Violation | ||
15 | Precedence cutoff in effect | ||
4 – Source Quench | 0 | deprecated | Source quench (congestion control) |
5 – Redirect Message | 0 | Redirect Datagram for the Network | |
1 | Redirect Datagram for the Host | ||
2 | Redirect Datagram for the ToS & network | ||
3 | Redirect Datagram for the ToS & host | ||
6 | deprecated | Alternate Host Address | |
7 | unassigned | Reserved | |
8 – Echo Request | 0 | Echo request (used to ping) | |
9 – Router Advertisement | 0 | Router Advertisement | |
10 – Router Solicitation | 0 | Router discovery/selection/solicitation | |
11 – Time Exceeded[6]: 6 | 0 | TTL expired in transit | |
1 | Fragment reassembly time exceeded | ||
12 – Parameter Problem: Bad IP header | 0 | Pointer indicates the error | |
1 | Missing a required option | ||
2 | Bad length | ||
13 – Timestamp | 0 | Timestamp | |
14 – Timestamp Reply | 0 | Timestamp reply | |
15 – Information Request | 0 | deprecated | Information Request |
16 – Information Reply | 0 | deprecated | Information Reply |
17 – Address Mask Request | 0 | deprecated | Address Mask Request |
18 – Address Mask Reply | 0 | deprecated | Address Mask Reply |
19 | reserved | Reserved for security | |
20 through 29 | reserved | Reserved for robustness experiment | |
30 – Traceroute | 0 | deprecated | Information Request |
31 | deprecated | Datagram Conversion Error | |
32 | deprecated | Mobile Host Redirect | |
33 | deprecated | Where-Are-You (originally meant for IPv6) | |
34 | deprecated | Here-I-Am (originally meant for IPv6) | |
35 | deprecated | Mobile Registration Request | |
36 | deprecated | Mobile Registration Reply | |
37 | deprecated | Domain Name Request | |
38 | deprecated | Domain Name Reply | |
39 | deprecated | SKIP Algorithm Discovery Protocol, Simple Key-Management for Internet Protocol | |
40 | Photuris, Security failures | ||
41 | Experimental | ICMP for experimental mobility protocols such as Seamoby [RFC4065] | |
42 – Extended Echo Request[10] | 0 | Request Extended Echo (XPing — see Extended Ping (Xping)) | |
43 – Extended Echo Reply[10] | 0 | No Error | |
1 | Malformed Query | ||
2 | No Such Interface | ||
3 | No Such Table Entry | ||
4 | Multiple Interfaces Satisfy Query | ||
44 through 252 | unassigned | Reserved | |
253 | Experimental | RFC3692-style Experiment 1 (RFC 4727) | |
254 | Experimental | RFC3692-style Experiment 2 (RFC 4727) | |
255 | reserved | Reserved |
Source quench[edit]
Source Quench requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request, or may occur if the router or host buffer is approaching its limit.
Data is sent at a very high speed from a host or from several hosts at the same time to a particular router on a network. Although a router has buffering capabilities, the buffering is limited to within a specified range. The router cannot queue any more data than the capacity of the limited buffering space. Thus if the queue gets filled up, incoming data is discarded until the queue is no longer full. But as no acknowledgement mechanism is present in the network layer, the client does not know whether the data has reached the destination successfully. Hence some remedial measures should be taken by the network layer to avoid these kind of situations. These measures are referred to as source quench.
In a source quench mechanism, the router sees that the incoming data rate is much faster than the outgoing data rate, and sends an ICMP message to the clients, informing them that they should slow down their data transfer speeds or wait for a certain amount of time before attempting to send more data. When a client receives this message, it automatically slows down the outgoing data rate or waits for a sufficient amount of time, which enables the router to empty the queue. Thus the source quench ICMP message acts as flow control in the network layer.
Since research suggested that «ICMP Source Quench [was] an ineffective (and unfair) antidote for congestion»,[11] routers’ creation of source quench messages was deprecated in 1995 by RFC 1812. Furthermore, forwarding of and any kind of reaction to (flow control actions) source quench messages was deprecated from 2012 by RFC 6633.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 4 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
unused | |||||||||||||||||||||||||||||||
IP header and first 8 bytes of original datagram’s data |
Where:
- Type must be set to 4
- Code must be set to 0
- IP header and additional data is used by the sender to match the reply with the associated request
Redirect[edit]
Redirect requests data packets be sent on an alternative route. ICMP Redirect is a mechanism for routers to convey routing information to hosts. The message informs a host to update its routing information (to send packets on an alternative route). If a host tries to send data through a router (R1) and R1 sends the data on another router (R2) and a direct path from the host to R2 is available (that is, the host and R2 are on the same subnetwork), then R1 will send a redirect message to inform the host that the best route for the destination is via R2. The host should then change its route information and send packets for that destination directly to R2. The router will still send the original datagram to the intended destination.[12] However, if the datagram contains routing information, this message will not be sent even if a better route is available. RFC 1122 states that redirects should only be sent by gateways and should not be sent by Internet hosts.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 5 | Code | Checksum | |||||||||||||||||||||||||||||
IP address | |||||||||||||||||||||||||||||||
IP header and first 8 bytes of original datagram’s data |
Where:
- Type must be set to 5.
- Code specifies the reason for the redirection, and may be one of the following:
-
-
Code Description 0 Redirect for Network 1 Redirect for Host 2 Redirect for Type of Service and Network 3 Redirect for Type of Service and Host
-
- IP address is the 32-bit address of the gateway to which the redirection should be sent.
- IP header and additional data is included to allow the host to match the reply with the request that caused the redirection reply.
Time exceeded[edit]
Time Exceeded is generated by a gateway to inform the source of a discarded datagram due to the time to live field reaching zero. A time exceeded message may also be sent by a host if it fails to reassemble a fragmented datagram within its time limit.
Time exceeded messages are used by the traceroute utility to identify gateways on the path between two hosts.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 11 | Code | Checksum | |||||||||||||||||||||||||||||
unused | |||||||||||||||||||||||||||||||
IP header and first 8 bytes of original datagram’s data |
Where:
- Type must be set to 11
- Code specifies the reason for the time exceeded message, include the following:
-
-
Code Description 0 Time-to-live exceeded in transit. 1 Fragment reassembly time exceeded.
-
- IP header and first 64 bits of the original payload are used by the source host to match the time exceeded message to the discarded datagram. For higher-level protocols such as UDP and TCP the 64-bit payload will include the source and destination ports of the discarded packet.
Timestamp[edit]
Timestamp is used for time synchronization. The originating timestamp is set to the time (in milliseconds since midnight) the sender last touched the packet. The receive and transmit timestamps are not used.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 13 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
Identifier | Sequence number | ||||||||||||||||||||||||||||||
Originate timestamp | |||||||||||||||||||||||||||||||
Receive timestamp | |||||||||||||||||||||||||||||||
Transmit timestamp |
Where:
- Type must be set to 13
- Code must be set to 0
- Identifier and Sequence Number can be used by the client to match the timestamp reply with the timestamp request.
- Originate timestamp is the number of milliseconds since midnight Universal Time (UT). If a UT reference is not available the most-significant bit can be set to indicate a non-standard time value.
Timestamp reply[edit]
Timestamp Reply replies to a Timestamp message. It consists of the originating timestamp sent by the sender of the Timestamp as well as a receive timestamp indicating when the Timestamp was received and a transmit timestamp indicating when the Timestamp reply was sent.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 14 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
Identifier | Sequence number | ||||||||||||||||||||||||||||||
Originate timestamp | |||||||||||||||||||||||||||||||
Receive timestamp | |||||||||||||||||||||||||||||||
Transmit timestamp |
Where:
- Type must be set to 14
- Code must be set to 0
- Identifier and Sequence number can be used by the client to match the reply with the request that caused the reply.
- Originate timestamp is the time the sender last touched the message before sending it.
- Receive timestamp is the time the echoer first touched it on receipt.
- Transmit timestamp is the time the echoer last touched the message on sending it.
- All timestamps are in units of milliseconds since midnight UT. If the time is not available in milliseconds or cannot be provided with respect to midnight UT then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value.
The use of Timestamp and Timestamp Reply messages to synchronize the clocks of Internet nodes has largely been replaced by the UDP-based Network Time Protocol and the Precision Time Protocol.[13]
Address mask request[edit]
Address mask request is normally sent by a host to a router in order to obtain an appropriate subnet mask.
Recipients should reply to this message with an Address mask reply message.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 17 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
Identifier | Sequence number | ||||||||||||||||||||||||||||||
Address mask |
Where:
- Type must be set to 17
- Code must be set to 0
- Address mask can be set to 0
ICMP Address Mask Request may be used as a part of reconnaissance attack to gather information on the target network, therefore ICMP Address Mask Reply is disabled by default on Cisco IOS.[14]
Address mask reply[edit]
Address mask reply is used to reply to an address mask request message with an appropriate subnet mask.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 18 | Code = 0 | Checksum | |||||||||||||||||||||||||||||
Identifier | Sequence number | ||||||||||||||||||||||||||||||
Address mask |
Where:
- Type must be set to 18
- Code must be set to 0
- Address mask should be set to the subnet mask
Destination unreachable[edit]
Destination unreachable is generated by the host or its inbound gateway[6] to inform the client that the destination is unreachable for some reason. Reasons for this message may include: the physical connection to the host does not exist (distance is infinite); the indicated protocol or port is not active; the data must be fragmented but the ‘don’t fragment’ flag is on. Unreachable TCP ports notably respond with TCP RST rather than a destination unreachable type 3 as might be expected. Destination unreachable is never reported for IP multicast transmissions.
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Type = 3 | Code | Checksum | |||||||||||||||||||||||||||||
unused | Next-hop MTU | ||||||||||||||||||||||||||||||
IP header and first 8 bytes of original datagram’s data |
Where:
- Type field (bits 0–7) must be set to 3
- Code field (bits 8–15) is used to specify the type of error, and can be any of the following:
-
-
Code Description 0 Network unreachable error. 1 Host unreachable error. 2 Protocol unreachable error (the designated transport protocol is not supported). 3 Port unreachable error (the designated protocol is unable to inform the host of the incoming message). 4 The datagram is too big. Packet fragmentation is required but the ‘don’t fragment’ (DF) flag is on. 5 Source route failed error. 6 Destination network unknown error. 7 Destination host unknown error. 8 Source host isolated error. 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).
-
- Next-hop MTU field (bits 48–63) contains the MTU of the next-hop network if a code 4 error occurs.[15]
- IP header and additional data is included to allow the client to match the reply with the request that caused the destination unreachable reply.
See also[edit]
- ICMP tunnel
- ICMP hole punching
- ICMP Router Discovery Protocol
- Pathping
- Path MTU Discovery
- Smurf attack
References[edit]
- ^ F. Baker (June 1995). Baker, F (ed.). Requirements for IP Version 4 Routers. p. 52. RFC 1812.
- ^ a b c d Forouzan, Behrouz A. (2007). Data Communications And Networking (Fourth ed.). Boston: McGraw-Hill. pp. 621–630. ISBN 978-0-07-296775-3.
- ^ «The OSI Model’s Seven Layers Defined and Functions Explained». Microsoft Support. Retrieved 2014-12-28.
- ^ «Protocol Numbers». Internet Assigned Numbers Authority. Retrieved 2011-06-23.
- ^ Requirements for IP Version 4 Routers. doi:10.17487/RFC1812. RFC 1812.
- ^ a b c d e f g h i j k Postel, J. (September 1981). Internet Control Message Protocol. IETF. doi:10.17487/RFC0792. RFC 792.
- ^ «IANA ICMP Parameters». Iana.org. 2012-09-21. Retrieved 2013-01-07.
- ^ Kurose, J.F; Ross, K.W. (2006). Computer Networking: A Top-Down Approach. World student series. Addison-Wesley. ISBN 9780321418494.
- ^ «Internet Control Message Protocol (ICMP) Parameters». www.iana.org. Retrieved 2023-09-13.
- ^ a b PROBE: A Utility for Probing Interfaces. doi:10.17487/RFC8335. RFC 8335.
- ^ RFC 6633
- ^ «When Are ICMP Redirects Sent?». Cisco Systems. 2008-06-28. Retrieved 2013-08-15.
- ^ D.L. Mills (September 1985). Network Time Protocol (NTP). doi:10.17487/RFC0958. RFC 958.
It is evolved from the Time Protocol and the ICMP Timestamp message and is a suitable replacement for both.
- ^ «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. Archived from the original on 2013-01-02. Retrieved 2013-01-07.
- ^ Extended ICMP to Support Multi-Part Messages. doi:10.17487/RFC4884. RFC 4884.
Sources[edit]
RFCs[edit]
- RFC 792, Internet Control Message Protocol
- RFC 950, Internet Standard Subnetting Procedure
- RFC 1016, Something a Host Could Do with Source Quench: The Source Quench Introduced Delay (SQuID)
- RFC 1122, Requirements for Internet Hosts – Communication Layers
- RFC 1716, Towards Requirements for IP Routers
- RFC 1812, Requirements for IP Version 4 Routers
- RFC 4884, Extended ICMP to Support Multi-Part Messages
External links[edit]
- IANA ICMP parameters
- IANA protocol numbers
- Explanation of ICMP Redirect Behavior at the Wayback Machine (archived 2015-01-10)
Протокол Internet Control Message Protocol (ICMP) является важным протоколом сетевого уровня в компьютерных сетях. Он обеспечивает стандартизированный механизм передачи сетевыми устройствами важной информации, такой как подключение и состояние сети. Все устройства, подключенные к сети, включая маршрутизаторы и конечные устройства, могут обрабатывать сообщения ICMP. ICMP адаптирован для работы как с IPv4, так и с IPv6.
Подробнее о компьютерных сетях »
Далее мы обсудим некоторые распространенные варианты использования ICMP.
Отчеты об ошибках
Сообщения об ошибках ICMP информируют о сетевых ошибках – например, о недоступных местах назначения, тайм-аутах или проблемах фрагментации. Сообщения особенно важны для протокола пользовательских дейтаграмм (UDP), который использует модель коммуникации без подключения.
UDP не обеспечивает надежную упорядоченную доставку пакетов. При отправке пакета UDP существует вероятность, что пакет может быть утерян или доставлен с ошибками, например с ошибками контрольной суммы. Если это происходит, получатель отправляет сообщения об ошибках ICMP отправителю, чтобы уведомить его о проблеме.
Диагностика
ICMP можно использовать для диагностики сети. Чаще всего он используется для команд ping и traceroute.
Команда ping проверяет доступность сетевых устройств, отправляя пакеты эхо-запроса ICMP на целевое устройство. Если устройство доступно, оно возвращает эхо-ответ ICMP. Благодаря этому надежно проверяется задержка в сети и обеспечивается доступность устройства.
Команда traceroute отслеживает путь пакетов от источника до места назначения. Для этого команда отправляет сообщения эхо-запроса и эхо-ответа в указанное место назначения.
Эхо-запросы содержат значение времени жизни (TTL), которое уменьшается на единицу при каждом прохождении пакета через маршрутизатор. Когда пакет достигает маршрутизатора с нулевым значением TTL, маршрутизатор отправляет сообщение ICMP обратно источнику.
В сообщении содержится информация о маршруте, пройденном пакетом. С помощью команды Traceroute можно узнать точный путь пакета, чтобы получить представление о производительности сети.
сетевая безопасность;
ICMP можно использовать для обнаружения несанкционированного сетевого трафика и разрешать только законный трафик в сети. Брандмауэры используют ICMP для разрешения или блокировки определенных типов трафика. Сетевые администраторы также используют инструменты мониторинга ICMP для отслеживания состояния и подключения сетевых устройств, а также обнаружения неизвестных устройств.
Вы также можете использовать протокол для выявления необычных схем трафика, которые могут указывать на несанкционированную активность.
Название: |
Internet Control Message Protocol |
---|---|
Уровень (по модели OSI): |
Сетевой |
Семейство: |
TCP/IP |
Спецификация: |
RFC 792 |
ICMP (англ. Internet Control Message Protocol — протокол межсетевых управляющих сообщений[1]) — сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. Также на ICMP возлагаются некоторые сервисные функции.
Содержание
- 1 Технические подробности
- 2 Использование ICMP-сообщений
- 3 Формат пакета ICMP
- 4 Правила генерации ICMP-пакетов
- 5 См. также
- 6 Примечания
- 7 Ссылки
[править] Технические подробности
Протокол ICMP описан в RFC 792 (с дополнениями в RFC 950) и является стандартом Интернета (входит в стандарт STD 5 вместе с IP). Хотя формально ICMP использует IP (ICMP-пакеты инкапсулируются в IP пакеты), он является неотъемлемой частью IP и обязателен при реализации стека TCP/IP. Текущая версия ICMP для IPv4 называется ICMPv4. В IPv6 существует аналогичный протокол ICMPv6.
ICMP-сообщение строится из IP-пакетов, сгенерировавших ICMP-ответ. IP инкапсулирует соответствующее ICMP-сообщение с новым заголовком IP (чтобы отправить ICMP-сообщение обратно отправителю) и передает полученные пакеты дальше.
Например, каждая машина (такая, как маршрутизатор), которая перенаправляет IP-пакеты, уменьшает Time to live (TTL) поля заголовка IP на единицу, если TTL достигает 0, ICMP-сообщение о превышении TTL отправляется на источник пакета.
Каждое ICMP-сообщение инкапсулируется непосредственно в пределах одного IP-пакета, и, таким образом, как и UDP, ICMP является ненадежным (надежным является TCP).
ICMP основан на протоколе IP. Его цели отличны от целей транспортных протоколов, таких как TCP и UDP: он, как правило, не используется для передачи и приема данных между конечными системами. ICMP не используется непосредственно в приложениях пользователей сети (исключение составляют инструменты Ping и Traceroute).
[править] Использование ICMP-сообщений
ICMP-сообщения (тип 12) генерируются при нахождении ошибок в заголовке IP-пакета (за исключением самих ICMP-пакетов, дабы не привести к бесконечно растущему потоку ICMP-сообщений об ICMP-сообщениях).
ICMP-сообщения (тип 3) генерируются маршрутизатором при отсутствии маршрута к адресату.
Утилита Ping, служащая для проверки возможности доставки IP-пакетов использует ICMP-сообщения с типом 8 (эхо-запрос) и 0 (эхо-ответ).
Утилита Traceroute, отображающая путь следования IP-пакетов, использует ICMP-сообщения с типом 11.
ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя.
ICMP-сообщения с типом 4 используются получателем (или маршрутизатором) для управления скоростью отправки сообщений отправителем.
[править] Формат пакета ICMP
Октет | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0—3 | Тип | Код | Контрольная сумма | |||||||||||||||||||||||||||||
… | Данные (формат зависит от значений полей «Код» и «Тип») |
Тип | Код | Сообщение | Данные (длина, бит) | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
0 | 0 | Эхо-ответ |
|
||||||||
1, 2 | Зарезервировано | ||||||||||
3 | Адресат недоступен |
|
|||||||||
0 | Сеть недостижима | ||||||||||
1 | Узел недостижим | ||||||||||
2 | Протокол недостижим | ||||||||||
3 | Порт недостижим | ||||||||||
4 | Необходима фрагментация, но установлен флаг ее запрета (DF) | ||||||||||
5 | Неверный маршрут от источника | ||||||||||
6 | Сеть назначения неизвестна | ||||||||||
7 | Узел назначения неизвестен | ||||||||||
8 | Узел источник изолирован | ||||||||||
9 | Сеть административно запрещена | ||||||||||
10 | Узел административно запрещён | ||||||||||
11 | Сеть недоступна для ToS | ||||||||||
12 | Узел недоступен для ToS | ||||||||||
13 | Коммуникации административно запрещены | ||||||||||
14 | Нарушение порядка предпочтения узлов | ||||||||||
15 | Активно отсечение порядка предпочтения | ||||||||||
4 | 0 | Сдерживание источника (отключение источника при переполнении очереди) | |||||||||
5 | Перенаправление |
|
|||||||||
0 | Перенаправление пакетов в сеть | ||||||||||
1 | Перенаправление пакетов к узлу | ||||||||||
2 | Перенаправление для каждого типа обслуживания (ToS) | ||||||||||
3 | Перенаправление пакета к узлу для каждого типа обслуживания | ||||||||||
6 | 0 | Альтернативный адрес узла | |||||||||
7 | Зарезервировано | ||||||||||
8 | 0 | Эхо-запрос |
|
||||||||
9 | 0 | Объявление маршрутизатора |
|
||||||||
10 | 0 | Запрос маршрутизатора |
Не используется (32) |
||||||||
11 | Время жизни дейтаграммы истекло |
|
|||||||||
0 | Время жизни пакета (TTL) истекло при транспортировке | ||||||||||
1 | Время жизни пакета истекло при сборке фрагментов | ||||||||||
12 | Неверный параметр (проблема с параметрами дейтаграммы: ошибка в IP-заголовке или отсутствует необходимая опция) | ||||||||||
0 | Указатель говорит об ошибке |
|
|||||||||
1 | Отсутствует требуемая опция |
|
|||||||||
2 | Некорректная длина | ||||||||||
13 | 0 | Запрос метки времени |
|
||||||||
14 | 0 | Ответ с меткой времени | |||||||||
15 | 0 | Информационный запрос |
|
||||||||
16 | 0 | Информационный ответ | |||||||||
17 | 0 | Запрос адресной маски |
|
||||||||
18 | 0 | Отклик на запрос адресной маски | |||||||||
19 | Зарезервировано (для обеспечения безопасности) | ||||||||||
20—29 | Зарезервировано (для экспериментов на устойчивость к ошибкам) | ||||||||||
30 | Трассировка маршрута |
|
|||||||||
0 | Исходящий пакет успешно отправлен | ||||||||||
1 | Путь для исходящего пакета не найден, пакет уничтожен | ||||||||||
31 | Ошибка преобразования датаграммы |
|
|||||||||
0 | Неизвестная или неуказанная ошибка | ||||||||||
1 | Невозможно конвертировать опцию | ||||||||||
2 | Неизвестная обязательная опция | ||||||||||
3 | Неподдерживаемая обязательная опция | ||||||||||
4 | Неподдеживаемый транспортный протокол | ||||||||||
5 | Превышена полная длина | ||||||||||
6 | Превышена длина заголовка IP | ||||||||||
7 | Номер транспортного протокола больше 255 | ||||||||||
8 | Номер порта вне допустимого диапазона | ||||||||||
9 | Превышена длина заголовка транспортного протокола | ||||||||||
10 | Переход через границу 32 бит и установлен бит ACK | ||||||||||
11 | Неизвестная обязательная опция транспортного протокола | ||||||||||
32 | Перенаправление для мобильного узла | ||||||||||
33 | IPv6 Where-Are-You (где вы находитесь) | ||||||||||
34 | IPv6 I-Am-Here (я здесь) | ||||||||||
35 | Запрос перенаправления для мобильного узла | ||||||||||
36 | Отклик на запрос перенаправления для мобильного узла | ||||||||||
37 | Запрос доменного имени | ||||||||||
38 | Ответ на запрос доменного имени | ||||||||||
39 | SKIP | ||||||||||
40 | Photuris | ||||||||||
0 | Зарезервировано | ||||||||||
1 | Неизвестный индекс параметров безопасности | ||||||||||
2 | Параметры безопасности верны, но произошла ошибка аутентификации | ||||||||||
3 | Параметры безопасности верны, но произошел сбой при расшифровке | ||||||||||
4 | Требуется проверка подлинности | ||||||||||
5 | Требуется авторизация | ||||||||||
41—255 | Зарезервировано |
[править] Правила генерации ICMP-пакетов
- При потере ICMP-пакета никогда не генерируется новый.
- ICMP-пакеты никогда не генерируются в ответ на IP-пакеты с широковещательным или групповым адресом, чтобы не вызывать перегрузку в сети (так называемый «широковещательный шторм»).
- При повреждении фрагментированного IP-пакета ICMP-сообщение отправляется только после получения первого повреждённого фрагмента, поскольку отправитель всё равно повторит передачу всего IP-пакета целиком.
[править] См. также
- ICMP туннель
[править] Примечания
- ↑ Протокол ICMP
[править] Ссылки
- RFC 792
- RFC 950
- RFC 1122 (дополнительные типы ICMP сообщений для существующих кодов)
- RFC 1393
- RFC 1256
- RFC 1475
- RFC 1812 (дополнительные типы ICMP сообщений для существующих кодов)
- RFC 4443 (ICMPv6)
- RFC 2463 (ICMPv6)
- RFC 1885 (ICMPv6)
- Навязывание хосту ложного маршрута с использованием протокола ICМР
Основные протоколы TCP/IP по уровням модели OSI (Список портов TCP и UDP) | |
---|---|
Физический |
Ethernet • RS-232 • EIA-422 • RS-449 • RS-485 |
Канальный |
Ethernet • PPPoE • PPP • L2F • 802.11 Wi-Fi • 802.16 WiMax • Token ring • ARCNET • FDDI • HDLC • SLIP • ATM • CAN • DTM • X.25 • Frame relay • SMDS • STP |
Сетевой |
IPv4 • IPv6 • IPsec • ICMP • IGMP • ARP • RARP • RIP2 • OSPF |
Транспортный |
TCP • UDP • SCTP • DCCP • RUDP • RTP • GRE |
Сеансовый |
ADSP • H.245 • iSNS • NetBIOS • PAP • RPC • L2TP • PPTP • RTCP • SMPP • SCP • ZIP • SDP |
Представления |
XDR • SSL • TLS |
Прикладной |
BGP • HTTP • HTTPS • DHCP • IRC • SNMP • DNS • DNSSEC • NNTP • XMPP • SIP • IPP • NTP • SNTP • Электронная почта (SMTP • POP3 • IMAP4) • Передача файлов (FTP • TFTP • SFTP) • Удалённый доступ (rlogin • Telnet • SSH • RDP) |
Другие прикладные |
OSCAR • CDDB • Multicast FTP • Multisource FTP • BitTorrent • Gnutella • Skype |