1. ФрагментацияIp-пакетов

На пути пакета от отправителя к получателю могут встречаться локальные и глобальные сети разных типов с разными допустимыми размерами полей данных кадров канального уровня (Maximum Transfer Unit – MTU). Так, сетиEthernetмогут передавать кадры, несущие до 1500 байт данных, для сетей X.25 характерен размер поля данных кадра в 128 байт, сетиFDDIмогут передавать кадры размером в 4500 байт, в других сетях действуют свои ограничения. Протокол IP умеет передавать дейтаграммы, длина которых больше MTU промежуточной сети, за счет фрагментирования – разбиения “большого пакета” на некоторое количество частей (фрагментов), размер каждой из которых удовлетворяет промежуточную сеть. После того, как все фрагменты будут переданы через промежуточную сеть, они будут собраны на узле-получателе модулем протокола IP обратно в “большой пакет”. Отметим, что сборку пакета из фрагментов осуществляет только получатель, а не какой-либо из промежуточных маршрутизаторов. Маршрутизаторы могут только фрагментировать пакеты, но не собирать их. Это связано с тем, что разные фрагменты одного пакета не обязательно будут проходить через одни и те же маршрутизаторы.

Для того, чтобы не перепутать фрагменты разных пакетов, используется поле Идентификации, значение которого должно быть одинаковым для всех фрагментов одного пакета и не повторяться для разных пакетов, пока у обоих пакетов не истекло время жизни.

При делении данных пакета, размер всех фрагментов, кроме последнего, должен быть кратен 8 байтам. Это позволяет отвести меньше места в заголовке под поле Смещение фрагмента.

Второй бит поля Флаги (Morefragments), если равен единице, указывает на то, что данный фрагмент – не последний в пакете.

Если пакет отправляется без фрагментации, флаг “Morefragments” устанавливается в 0, а поле Смещение фрагмента – заполняется нулевыми битами.

Если первый бит поля Флаги (Don’tfragment) равен единице, то фрагментация пакета запрещена. Если этот пакет должен быть передан через сеть с недостаточнымMTU, то маршрутизатор вынужден будет его отбросить (и сообщить об этом отправителю посредством протоколаICMP). Этот флаг используется в случаях, когда отправителю известно, что у получателя нет достаточно ресурсов по восстановлению пакетов из фрагментов.

3. Протокол arp

Протокол ARP (Address Resolution Protocol, Протокол Разрешения Адресов) описан в RFC 826.

При передаче пакетов внутри локальных сетей протоколы канального уровня пользуются локальными адресами узлов, отправитель же может знать только IP-адрес получателя. Для того чтобы определить, какой локальный адрес (например, MAC-адрес в сети Ethernet) соответствует данному IP-адресу, применяется протокол ARP. Этот протокол разрабатывался специально для Ethernet-сетей, но может работать в любых сетях, поддерживающих широковещательную передачу.

Все узлы, поддерживающие протокол ARP, ведут ARP-таблицу, состоящую из записей <IP-адрес;MAC-адрес>.

Когда узлу нужно определить локальный адрес другого узла, его ARP-модуль сначала ищет его в ARP-таблице, и, если нужный адрес не найден, то передает широковещательное сообщение: “Знает ли кто-нибудь локальный адрес для IP 123.45.67.89? Я 123.45.67.90, мой MAC-адрес 10:20:30:40:50:60.”. Узел, которого разыскивают, отвечает (не широковещательно, а прямой передачей): “Да, 123.45.67.89 – это я. Мой MAC-адрес 10:20:30:40:50:61”. При этом он сохраняет пару <IP-адрес;MAC-адрес> искавшего его узла в своей ARP-таблице. Наконец, первый узел, получив ответ, заносит его в свою ARP-таблицу.

Как правило, записи в ARP-таблице имеют ограниченное время жизни (стандарт описывает возможные схемы ограничения времени жизни и тайм-аутов, но не требует их применения).

Формат сообщения ARP позволяет использовать этот протокол в сетях с разным размером адресов (до 256 бит).

Сообщения ARP не содержат IP-заголовка и непосредственно размещаются в поле данных кадра канального уровня.