1. 1 История tcpIP
 Скачать 340.83 Kb.
|
4.3 Proxy ARPПротокол ARP был разработан для использования устройствами в пределах одной локальной сети. Однако возможна ситуация, когда узлы находятся в разных физических сетях. В этом случае узлы из разных физических сетей не могут получать широковещательные ARP-запросы и отвечать на них. Если сеть разбита на подсети, и они соединены маршрутизатором, то он будет видеть ARP-запросы отправляемые узлами из одной подсети узлам в другой. Однако маршрутизаторы не пропускают широковещательный трафик и устройства, находящиеся в разных подсетях, не смогут выполнить разрешение адресов. Для решения этой проблемы используется метод Proxy ARP, описанный в RFC 1027. Этот механизм применяется в маршрутизаторах или коммутаторах L3, чтобы отвечать на ARP-запросы, предназначенные для другого устройства. Когда маршрутизатор (коммутатор L3) с активированной функцией Proxy ARP, получает ARP-запрос для разрешения IP-адреса, находящегося в другой подсети, он посылает ARP-ответ, содержащий его собственный MAC-адрес. Узел, получивший этот ответ, будет пересылать все пакеты, которые должны достигнуть требуемого адресата, на маршрутизатор (коммутатор L3). Так как маршрутизатору (коммутатору L3) известен путь к требуемому узлу, он будет перенаправлять ему все пакеты. Proxy ARP обычно используется в тех сетях, где на IPv4-узлах не настроен шлюз по умолчанию или они не обладают функциями маршрутизации. В настоящее время этот механизм практически не используется, так как содержит значительные недостатки. Он увеличивает объем широковещательного ARP-трафика, размеры ARP-таблиц устройств, может использоваться для атак ARP spoofing. Поэтому для передачи пакетов между различными подсетями, соединенных маршрутизирующим устройством, наилучшим решением является использование протоколов маршрутизации. 4.4 Разрешение адресов для IPv6Изменения, которые были сделаны в IPv6, коснулись не только самого протокола IP, но и всех протоколов стека TCP/IP. В IPv6 функция разрешения адресов, которую выполняет ARP, объединена с несколькими функциями, которые выполняются протоколом ICMP в оригинальном стеке TCP/IP, расширена дополнительными возможностями и реализована в протоколе Neighbor Discovery Protocol (NDP). Протокол NDP описан в RFC 4861. Базовая концепция разрешения адресов в IPv6 осталась прежней: разрешение адресов является динамическим и основано на использовании таблицы, связывающей между собой MAC- и IP-адреса. Когда устройство хочет отправить пакет IPv6 соседнему устройству в локальной сети, но не знает его физический адрес, оно инициирует процесс разрешения адресов, но посылает не широковещательный ARP-запрос, а сообщение Neighbor Solicitation протокола NDP. Если нижележащий протокол канального уровня поддерживает многоадресную (групповую) рассылку, как, например, Ethernet, сообщение Neighbor Solicitation не отправляется широковещательно. Оно отправляется на групповой адрес Solicited-Node того устройства, чей адрес IPv6 необходимо разрешить. При получении сообщения Neighbor Solicitation устройство назначения отправит назад устройству-отправителю сообщение Neighbor Advertisement (аналогично ARP Reply). Поскольку адрес Solicited-Node не является уникальным, то устройство-получатель должно убедиться, что оно является тем устройством, чей адрес пытается разрешить устройство-отправитель. Подробнее протокол NDP будет рассмотрен далее в нашем курсе. 5 Протокол ICMP Основным протоколом сетевого уровня является протокол IP, который позволяет доставлять данные в сетях TCP/IP между узлами составной сети. Протокол IP не гарантирует надежной доставки пакета до адресата. Другими словами, отправитель передает пакеты через составную сеть и не получает подтверждение доставки. Протокол IP не обладает механизмами отправки служебных сообщений, которые позволяли бы сообщать устройству-отправителю о проблемах, возникающих при передаче пакетов или осуществлять тестирование соединения. Поэтому недостающие в протоколе IP функции выполняются с помощью протокола Internet Control Message Protocol (ICMP). Протокол ICMP является неотъемлемой частью протокола IP и обеспечивает его поддержку в форме ICMP-сообщений, которые инкапсулируются в IP-пакеты. Первоначальный протокол ICMP был определен в RFC 792 одновременно с протоколом IP, описанным в RFC 791. В середине 1990-х появился протокол IPv6, для которого также надо было определить версию протокола ICMP. Таким образом, новую версию протокола ICMP назвали ICMPv6 (RFC 4443), а оригинальную версию ICMP стали называть ICMPv4. Сообщения ICMPv4 и ICMPv6 имеют одинаковый базовый формат (рис. 5.1). Структура сообщения может быть разделена на две части — общую и уникальную. Общая часть состоит из трех полей, размер которых одинаков для всех типов сообщений: Type (Тип) — определяет тип сообщения ICMP; Code (Код) — определяет подтип сообщения внутри ICMP-сообщения каждого типа; Checksum (Контрольная сумма) — вычисляется аналогично контрольной сумме заголовка IPv4. Уникальная часть содержит поля, определенные для каждого типа сообщения. Обе версии протокола ICMPv4 и ICMPv6 определяют общую систему передачи сообщений. В дополнение к сообщениям, определенным протоколом ICMP, другие протоколы также могут определять свои типы сообщений ICMP. Некоторые самые важные из них приведены в таблице 5.1. Таблица 5.1. Протоколы, определяющие сообщения ICMP
Протокол ICMP является простейшим протоколом стека TCP/IP и отличается от других его протоколов тем, что не выполняет определенных задач и алгоритмов. Он описывает механизм, с помощью которого могут передаваться и приниматься различные управляющие сообщения, обеспечивая выполнение разнообразных функций. Протокол ICMP определяет различные типы сообщений, которые позволяют устройствам обмениваться информацией. Однако он не определяет, как они используются. Это делают протоколы, использующие сообщения ICMP в своей работе. ICMP рассматривается как часть IP и использует IP для отправки сообщений. Сообщения отправляются на сетевой уровень принимающего устройства, как показано на рисунке 5.2. Предположим, что ПК1 отправляет IP-пакет серверу. Маршрутизатор R2 получает пакет и обнаруживает, что возникла проблема и пакет необходимо отбросить. Для этого маршрутизатор R2 отправляет назад ПК1 ICMP-сообщение с описанием проблемы. Обратите внимание, что R2 отправляет сообщение непосредственно ПК1, а не соседнему маршрутизатору R1. Протокол ICMP не использует номера портов, как протоколы TCP или UDP, для определения приложения сетевого узла, которому предназначено сообщение. Программное обеспечение стека протоколов TCP/IP, функционирующее на сетевом узле, самостоятельно распознает тип ICMP-сообщения и направляет его соответствующему приложению. 5.1 Классы, типы и коды сообщений ICMP Протокол ICMP определяет различные типы сообщений, которые позволяют устройствам обмениваться различной информацией. Сообщения ICMP делятся на два класса сообщения об ошибках — используются для оповещения устройства-отправителя о проблемах, возникших при передаче пакета. Обычно генерируются в ответ на какое-либо событие, возникшее при передаче пакета; информационные сообщения — используются для диагностики, тестирования, обмена информацией и других целей. Не содержат описания ошибок и обычно не отправляются при возникновении какого-либо события. Могут генерироваться соответствующим приложением или как ответ на другое информационное сообщение ICMP, либо на постоянной основе для предоставления информации другим устройствам. Каждому сообщению ICMP присваивается уникальное значение типа, которое указывается в 8-битном поле Type пакета ICMP. Для ICMPv4 и ICMPv6 может быть определено до 256 различных типов сообщений (отдельный набор для каждого протокола). В ICMPv4 значения типа назначаются последовательно для информационных сообщений и сообщений об ошибках. В ICMPv6 сообщениям об ошибках в поле Type присваиваются значения от 0 до 127, информационным сообщениям — от 128 до 255. Тип сообщения указывает на общее предназначение каждого ICMP-сообщения. Коды, указываемые в 8-битном поле Code пакета ICMP, вносят дополнительный уровень детализации. Каждый тип сообщения может иметь до 256 подтипов. В таблице 5.2 представлены основные типы ICMP-сообщений протоколов ICMPv4 и ICMPv6, показаны значения поля Type, названия сообщений и их краткое описание. Таблица 5.2. Классы и типы сообщений ICMP
Как видно из таблицы, несколько типов сообщений ICMPv4 и ICMPv6 в целом похожи, но имеют небольшие отличия. Например, сообщение Redirect в ICMPv4 рассматривается как сообщение об ошибке, а в ICMPv6 — как информационное сообщение. Способы использования сообщений также различны. Многие сообщения ICMPv6 используются протоколом NDP. 5.2 Правила генерации сообщений ICMP Информационные ICMP-сообщения генерируются в соответствии с правилами, установленными использующими их протоколами. ICMP-сообщения об ошибках генерируются в ответ на какое-либо событие, возникшее при передаче пакета. Может возникнуть ситуация, при которой узлы начнут отправлять сообщения об ошибках друг другу, что приведет к петлям или отправке множественных сообщений. Для предотвращения таких проблем, ICMP-сообщения об ошибках не должны генерироваться в ответ на: ICMP-сообщения об ошибках; IP-пакеты с широковещательным или групповым адресом, чтобы не вызывать перегрузку в сети («широковещательный шторм»); фрагменты IP-пакетов за исключением первого — при повреждении фрагментированного IP-пакета ICMP-сообщение отправляется только после получения первого поврежденного фрагмента, поскольку отправитель все равно повторит передачу всего IP-пакета целиком. Перечисленные правила относятся к сообщениям ICMPv4 и ICMPv6, однако в ICMPv6 определены некоторые исключения. В частности, ICMPv6-сообщение Packet Too Big может генерироваться в ответ на групповой адрес, так как это требуется для работы механизма Path MTU Discovery. Некоторые сообщения Parameter Problem также могут отправляться на широковещательные или групповые адреса. |