Приветствую, коллеги! Меня зовут @ProstoKirReal. 

В предыдущей статье я рассказывал про самые популярные заголовки на L2 уровне модели OSI. Сегодня я хотел бы поговорить с вами о значимых заголовках на уровне L3 (сетевом уровне) и уровне L4 (транспортном) модели OSI. 

Эта часть заключительная и является своего рода ‭«шпаргалкой», к которой можно было бы возвращаться снова и снова.

❯ Какие заголовки находятся в IP пакете на L3 уровне?

В этой статье я уже затрагивал данный уровень, зачем он нужен и какие функции выполняет.

Протоколы сетевого уровня

На сетевом уровне используются различные протоколы, каждый из которых имеет свой собственный формат заголовков. Наиболее распространенными протоколами являются IPv4, IPv6, ICMP, ARP, OSPF, GRE. 

❯ Заголовок IPv4

Одним из самых популярных заголовков является IPv4. Давайте подробно разберём его каждый заголовок:

1. Version (Версия) 4 бита

Это поле указывает версию IP-протокола. Для IPv4 значение равно 4. Это поле определяет, какой протокол используется в заголовке пакета. В IP-сетях также используется IPv6, который имеет значение версии 6 в этом поле.

2. Header Length (Длина заголовка) 4 бита

Это поле определяет длину заголовка IP-пакета в 32-битных словах. Минимальная длина заголовка — 5 слов (20 байт), что соответствует базовому заголовку без опций. Максимальная длина заголовка — 15 слов (60 байт), что позволяет включать дополнительные опции. Значение указывается в количестве 32-битных слов (например, значение 5 означает 5 × 4 = 20 байт).

3. Type of Service (Тип обслуживания) 8 бит

Это поле используется для указания желаемого качества обслуживания. В IPv4 это поле делится на несколько подполей:

Три бита приоритета (Precedence):

• Устанавливают приоритет пакета, начиная с 000 (наименьший приоритет) до 111 (наивысший приоритет). Это может использоваться для управления трафиком в сетях с высокой нагрузкой, например, для выделения приоритетных пакетов, таких как голосовые или видеозвонки, над обычным веб-трафиком.

Поле TOS:

• D (Delay): минимальная задержка (1 = минимальная задержка, 0 = нормальная задержка). Эта опция может быть полезна для приложений, чувствительных к задержкам, таких как онлайн-игры или видеоконференции, где минимальные задержки критичны для качества обслуживания.

• T (Throughput): высокая пропускная способность (1 = высокая пропускная способность, 0 = нормальная пропускная способность). Например, для передачи больших файлов или потокового видео можно указать этот тип обслуживания для обеспечения высокой пропускной способности.

• R (Reliability): высокая надежность (1 = высокая надежность, 0 = нормальная надежность). Используется в приложениях, где важна целостность данных, таких как финансовые транзакции или передача важных документов.

Два зарезервированных бита:

• Всегда устанавливается в 0.

Вместо зарезервированного бита может устанавливаться поле ECN.

Подробнее о ECN

Explicit Congestion Notification (ECN) — это механизм, используемый в сетевых протоколах для управления перегрузками в сети, позволяющий избежать потерь пакетов, вызванных переполнением буферов маршрутизаторов или коммутаторов. ECN был представлен в обновлениях протоколов IP и TCP и является расширением системы управления перегрузками.

Основные элементы ECN:

1. IP-заголовок: ECN реализуется в заголовках пакетов IP (как в IPv4, так и в IPv6). Он использует два бита в поле Type of Service (ToS) в IPv4 (или поле Traffic Class в IPv6), которые называются ECN-битами. Эти биты сигнализируют о текущем состоянии перегрузки на сетевых устройствах. В IPv4 это 8-битное поле ранее использовалось только для определения приоритетов трафика, а с введением ECN два из этих битов были выделены для обозначения состояния перегрузки. Четыре возможных значения этих битов:
   

   • 00: ECN не поддерживается (Non-ECN-Capable Transport, Not-ECT).

   • 01 или 10: поддерживается ECN, но перегрузка не обнаружена (ECN-Capable Transport, ECT).

   • 11: обнаружена перегрузка (Congestion Experienced, CE).

2. TCP-заголовок: TCP также должен поддерживать ECN, чтобы взаимодействовать с IP-заголовком. Для этого в TCP-заголовке есть специальные флаги:
   

   • ECN-Echo (ECE): используется получателем для уведомления отправителя о перегрузке, обнаруженной в сети.

   • Congestion Window Reduced (CWR): этот флаг отправляется отправителем, чтобы указать, что он получил сигнал о перегрузке и предпринял действия по снижению нагрузки (например, уменьшил окно перегрузки).

Как работает ECN:

1. Отправка пакета: отправитель устанавливает в IP-заголовке флаг ECN-Capable Transport (ECT) (01 или 10), что указывает на поддержку ECN.

2. Прохождение через сеть: если маршрутизатор или коммутатор обнаруживает, что его буфер начинает заполняться, вместо того чтобы отбрасывать пакеты, он устанавливает в ECN-битах значение 11 (CE), сигнализируя о перегрузке.

3. Получение пакета: получатель, получив пакет с установленным значением CE, устанавливает флаг ECE в TCP-заголовке следующего отправляемого пакета, чтобы уведомить отправителя о перегрузке.

4. Реакция отправителя: отправитель, получив сигнал о перегрузке через флаг ECE, уменьшает скорость передачи данных (например, сокращает размер окна перегрузки) и отправляет пакет с установленным флагом CWR для подтверждения того, что он принял меры по снижению перегрузки.

Преимущества ECN:

1. Снижение потерь пакетов: ECN позволяет избежать ситуаций, когда маршрутизаторы вынуждены отбрасывать пакеты при перегрузке. Это повышает эффективность сети и уменьшает задержки.

2. Мягкое управление трафиком: вместо того чтобы внезапно сбрасывать трафик, как в классических методах управления перегрузками (например, с использованием алгоритмов Drop Tail), ECN позволяет более плавно реагировать на перегрузки, что улучшает производительность приложений.

3. Поддержка современных протоколов: ECN интегрирован в современные сетевые протоколы (например, TCP, SCTP, DCCP) и является частью таких технологий, как управление качеством обслуживания (QoS).

Ограничения и требования:

1. Поддержка на всех устройствах: для работы ECN необходимо, чтобы его поддерживали как конечные устройства, так и маршрутизаторы или коммутаторы по пути передачи данных.

2. Совместимость: если какое-либо устройство в сети не поддерживает ECN, оно игнорирует эти биты, что может ограничить эффективность этого механизма.

3. Реализация в ОС и приложениях: для использования ECN также необходимо, чтобы операционные системы и сетевые приложения поддерживали этот механизм.

4. Total Length (Общая длина) 16 бит

Максимальная длина пакета ограничивается разрядностью соответствующего поля и составляет 65 535 байт. Однако такие большие пакеты редко используются в большинстве компьютеров и сетей. При передаче данных по различным сетям длина пакета подбирается с учетом максимальной длины пакета нижележащего протокола, который несет IP-пакеты. Если это Ethernet-кадры, то оптимальная длина пакета составляет 1500 байт, чтобы он уместился в поле данных Ethernet-кадра. В стандарте RFC 791 указано, что все хосты должны быть способны принимать пакеты длиной до 576 байт, независимо от того, приходят ли они целиком или фрагментами. Хостам рекомендуется отправлять пакеты размером более 576 байт только в том случае, если они уверены, что принимающий хост или промежуточная сеть смогут обработать такие пакеты.

5. Identification (Идентификатор пакета) 16 бит

Это поле используется для уникальной идентификации пакета при фрагментации (у каждого фрагмента один и тот же номер). Когда большой пакет разбивается на более мелкие фрагменты, это поле помогает собрать фрагменты вместе и определить, какой пакет они составляют.

 

6. Flags (Флаги) 3 бита

Это поле содержит управляющие флаги для обработки фрагментации:

• Зарезервированный (1 бит) — этот бит зарезервирован для будущего использования и всегда должен быть установлен в 0. Это обеспечивает совместимость с будущими версиями протокола.

• DF (Don't Fragment, не фрагментировать) — этот флаг указывает, что пакет не должен быть фрагментирован. Если маршрутизатор обнаруживает, что пакет слишком велик для передачи по следующему сегменту сети и установлен флаг DF, пакет будет отброшен и отправлено сообщение ICMP с ошибкой "Fragmentation Needed and DF Set".

• MF (More Fragments, больше фрагментов) (1 бит) — этот флаг указывает, что пакет состоит из нескольких фрагментов. Если этот бит установлен, это значит, что последующий фрагмент пакета будет передан. Если бит MF сброшен (равен 0), это означает, что данный фрагмент является последним в цепочке фрагментов.

Примеры использования флагов

1.     Зарезервированный бит (0) | DF (0) | MF (0)

Пакет может быть фрагментирован, и это последний или единственный фрагмент.

2.     Зарезервированный бит (0) | DF (0) | MF (1)

Пакет может быть фрагментирован, и за ним следуют дополнительные фрагменты.

3.     Зарезервированный бит (0) | DF (1) | MF (0)

Пакет не должен быть фрагментирован и является единственным или последним фрагментом.

4.     Зарезервированный бит (0) | DF (1) | MF (1)

Такая комбинация не используется, так как если установлен флаг DF, то фрагментация запрещена, и MF не имеет смысла.

7. Fragment Offset (Смещение фрагмента) 13 бит

Поле «Fragment Offset» указывает смещение фрагмента относительно начала исходной датаграммы (для пакета подвергнушегося фрагментации). Значение смещения измеряется в единицах по 8 байт (64 бита). Это поле играет ключевую роль в восстановлении порядка фрагментов при сборке пакета на принимающем узле.

Подробности:

• Смещение в единицах 8 байт. Поскольку смещение измеряется в единицах по 8 байт, значение в этом поле умножается на 8, чтобы получить реальное смещение в байтах. Например, если значение поля равно 1, то фактическое смещение составляет 8 байт.

• Восстановление порядка фрагментов. При передаче пакета, который был разбит на несколько фрагментов, каждый фрагмент получает смещение, соответствующее его месту в исходной датаграмме. Это позволяет принимающему узлу правильно собрать фрагменты в исходный пакет, независимо от порядка их получения.

• Максимальное значение смещения. Поскольку размер поля составляет 13 бит, максимальное значение смещения составляет 8191 единицу (или 65528 байт), что соответствует максимально возможному смещению в исходной датаграмме.

Примеры использования:

• Первый фрагмент. Для первого фрагмента смещение всегда равно 0, так как он начинается с начала исходной датаграммы.

• Последующие фрагменты. Для последующих фрагментов смещение указывает, с какого места в исходной датаграмме начинается данный фрагмент. Например, если первый фрагмент имеет длину 1000 байт, следующий фрагмент будет иметь смещение 125 (1000 байт / 8).

8. Time to Live (TTL, Время жизни) 8 бит

Это поле определяет максимальное количество узлов (маршрутизаторов), через которые пакет может пройти, прежде чем быть отброшенным. Оно используется для предотвращения зацикливания пакетов в сети. Каждый маршрутизатор, через который проходит пакет, уменьшает значение TTL на 1. Если TTL достигает 0, пакет удаляется.

9. Protocol (Протокол верхнего уровня) 8 бит

Поле «Protocol» указывает, какой протокол транспортного уровня используется для обработки данных, содержащихся в IP-пакете. Это поле помогает определить, как следует интерпретировать и обрабатывать полезную нагрузку пакета на принимающем узле. Примеры значений включают:

·     6: TCP (Transmission Control Protocol). Используется для надежной, соединительно-ориентированной передачи данных. TCP обеспечивает управление потоком, проверку целостности данных и повторную передачу потерянных пакетов.

·       17: UDP (User Datagram Protocol). Протокол без установления соединения, который используется для быстрой передачи данных без гарантии доставки. UDP подходит для приложений, где важна скорость и низкая задержка, таких как потоковое видео и онлайн-игры.

·       1: ICMP (Internet Control Message Protocol): Протокол для отправки сообщений об ошибках и других информационных сообщений. ICMP используется, например, в команде ping для проверки доступности узлов в сети.

Эти коды определены в документах IANA (Internet Assigned Numbers Authority).

10. Header Checksum (Контрольная сумма заголовка) 16 бит.

Поле "Header Checksum" содержит контрольную сумму, используемую для проверки целостности заголовка IP-пакета. Если значение контрольной суммы при проверке не совпадает с расчетным, это указывает на ошибку в заголовке.

Подробности:

• Вычисление контрольной суммы. Для вычисления контрольной суммы суммируются все 16-битные слова заголовка пакета. Результат суммирования инвертируется побитово, и полученное значение записывается в поле «Header Checksum». При проверке целостности этот процесс повторяется, и если контрольная сумма совпадает с вычисленной, заголовок считается корректным.

• Проверка целостности. При получении пакета принимающее устройство повторно вычисляет контрольную сумму заголовка. Если контрольная сумма в заголовке совпадает с вычисленной, это подтверждает, что заголовок не был поврежден при передаче. Если значения не совпадают, пакет считается поврежденным, и он может быть отброшен.

• Ограничение контроля данных. Контрольная сумма проверяет только заголовок пакета, но не его данные. Это означает, что ошибки в полезной нагрузке пакета не будут обнаружены с помощью контрольной суммы заголовка.

Примеры использования:

• Обнаружение ошибок. Контрольная сумма помогает обнаружить ошибки, возникающие при передаче пакетов через сеть, такие как случайные изменения битов из-за помех.

• Повышение надежности. Использование контрольной суммы повышает надежность сетевых коммуникаций, так как позволяет своевременно выявлять и обрабатывать поврежденные пакеты.

• Маршрутизаторы и конечные узлы. Контрольная сумма проверяется на каждом промежуточном маршрутизаторе и конечном узле, обеспечивая целостность заголовка на каждом этапе передачи.

Хотелось бы сделать еще одно важное замечание. Контрольная сумма заголовка считается от всего заголовка, а в заголовке есть поле Total Length (Общая длина). Из-за этого поля, для пакетов разной длины, будет разная контрольная сумма. В моей практике приходилось менять вручную некоторые поля заголовка, и из-за этого пришлось вручную считать контрольную сумму. 

11. Source IP Address (IP-адрес отправителя) 32 бита

Это поле содержит IP-адрес узла, который отправил пакет. Он используется для идентификации источника пакета и для маршрутизации ответа обратно к отправителю.

12. Destination IP Address (IP-адрес получателя) 32 бита

Это поле содержит IP-адрес узла, который должен получить пакет. Он используется для маршрутизации пакета к конечному получателю.

13. Options (Опции) 

Поле «Options» содержит дополнительные параметры, которые могут использоваться для различных целей, таких как безопасность, управление маршрутизацией или диагностика. Опции могут включать различные параметры, и их формат может изменяться. Это поле не всегда присутствует, и если его нет, заголовок заполняется нулями до кратности 32 битам.

Подробности:

• Переменная длина. Поле «Options» может иметь различную длину в зависимости от конкретных опций, используемых в пакете. Это делает поле гибким и позволяет добавлять разнообразные параметры для различных нужд.

• Дополнительные параметры. Опции могут включать такие параметры, как указания маршрута (Record Route), отметки времени (Timestamp), параметры для обеспечения безопасности, и другие специальные указания.

• Формат опций. Каждая опция имеет определенный формат, который может включать поля для типа опции, длины опции и данных опции. В зависимости от конкретной опции, эти поля могут иметь различное значение и структуру.

• Наличие опций. Поле «Options» не обязательно присутствует в каждом IP-пакете. Если опции не используются, поле отсутствует, а заголовок заполняется нулями, чтобы обеспечить кратность 32 битам (4 байтам). Это требование позволяет поддерживать правильное выравнивание заголовка IP-пакета.

Примеры использования

Управление маршрутизацией:

• Source Routing (маршрутизация по источнику). Опция позволяет отправителю указывать конкретные маршруты, по которым должен следовать пакет. Это может быть полезно в случае перегрузок на некоторых маршрутах или для обхода неисправных участков сети.

• Record Route (запись маршрута). Эта опция позволяет записывать IP-адреса маршрутизаторов, через которые проходит пакет. Таким образом, администраторы могут анализировать маршруты и производить оптимизацию сети.

Диагностика сети:

• Timestamp (отметки времени). Опция добавляет метки времени в пакет, когда он проходит через маршрутизаторы. Это позволяет измерять время прохождения пакета через каждый маршрутизатор, выявлять задержки и определять участки сети, требующие улучшения.

• Ping с опцией Record Route. Администраторы могут использовать утилиту ping с опцией записи маршрута для диагностики проблем в сети. Это позволяет увидеть, через какие узлы проходит пакет и где могут возникать проблемы.

Безопасность:

• IPsec (Internet Protocol Security). Использует специальные опции для шифрования данных и обеспечения аутентичности пакетов. Это помогает предотвратить прослушивание и подделку данных в процессе передачи.

• Опции аутентификации. Некоторые сетевые протоколы включают опции для аутентификации источников данных. Например, TCP может использовать опцию MD5 для защиты BGP сессий от несанкционированного вмешательства.

❯ Заголовок IPv6

Заголовок IPv6 имеет более простую и эффективную структуру по сравнению с IPv4:

1.  Версия (Version) 4 бита

Указывает версию IP-протокола. Для IPv6 значение равно 6. Это поле помогает различить пакеты IPv4 и IPv6.

2. Класс трафика (Traffic Class) 8 бит

Аналогично полю ToS в IPv4, используется для указания приоритета трафика и обеспечения качественного обслуживания (QoS). Это поле позволяет маршрутизаторам и конечным узлам обрабатывать пакеты в зависимости от их приоритета.

Пример использования

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

3. Метка потока (Flow Label) 20 бит

Используется для маркировки пакетов, принадлежащих одному потоку данных. Это поле помогает обеспечить надлежащее качество обслуживания (QoS) для пакетов, относящихся к определённым потокам.

Пример использования

В потоковых мультимедийных приложениях, таких как IPTV, метка потока позволяет маршрутизаторам идентифицировать и обрабатывать пакеты, принадлежащие к одному видеопотоку, обеспечивая плавное воспроизведение видео без задержек и потерь данных.

4.  Длина полезной нагрузки  (Payload Length) 16 бит

Определяет длину полезной нагрузки (данных) в пакете, исключая заголовок IPv6. Это поле помогает определить размер данных, передаваемых в пакете.

Пример использования 

Сетевые устройства и конечные узлы используют это поле для определения размера данных, что позволяет эффективно управлять буферизацией и обработкой пакетов, особенно при передаче больших объемов данных.

5. Следующий заголовок (Next Header) 8 бит

Идентифицирует тип заголовка, который следует сразу после заголовка IPv6. Это поле позволяет определить, какой протокол используется после заголовка IPv6 (например, TCP, UDP, ICMPv6).

Пример использования

В сетевых устройствах это поле используется для определения следующего протокола, что позволяет корректно обработать пакет в соответствии с требованиями конкретного протокола, будь то транспортный или прикладной уровень.

6. Предел переходов (Hop Limit) 8 бит

Указывает максимальное количество узлов, через которые может пройти пакет, прежде чем он будет отброшен. Это поле выполняет ту же функцию, что и TTL в IPv4, предотвращая зацикливание пакетов.

Пример использования

Это поле используется для предотвращения бесконечного движения пакетов по сети. Если пакет не может быть доставлен в течение указанного числа переходов, он будет отброшен, что предотвращает перегрузку сети.

7. Адрес источника (Source Address) 128 бит

IP-адрес узла, который отправил пакет. Это поле используется для маршрутизации ответа обратно к отправителю.

8. Адрес назначения (Destination Address) 128 бит

IP-адрес узла, который должен получить пакет. Это поле используется для маршрутизации пакета к конечному получателю.

❯ Заголовок ICMP

ICMP (Internet Control Message Protocol) используется для обмена контрольными сообщениями и диагностики. 

Поля заголовка ICMP:

1.     Тип (Type) 8 бит

Указывает тип ICMP сообщения. Примеры типов включают эхо-запрос (Type 8) и эхо-ответ (Type 0). Это поле помогает определить, как следует интерпретировать сообщение ICMP.

Пример использования

 Эхо-запросы и эхо-ответы (ping) используются для проверки доступности узлов в сети. Системные администраторы отправляют эхо-запросы к целевому узлу, чтобы проверить, отвечает ли он и какова задержка.

2.     Код (Code) 8 бит

Предоставляет дополнительную информацию о типе сообщения. Например, для сообщения о недостижимости назначения этот код указывает, какой тип ошибки произошёл (например, недостижимость сети или хоста).

Пример использования 

Когда узел получает ICMP сообщение о недостижимости назначения (Type 3), код может указать причину недостижимости, такую как недоступность сети (Code 0) или хоста (Code 1). Это помогает в диагностике проблем с маршрутизацией и доступностью узлов.

3.     Контрольная сумма (Checksum) 16 бит

Используется для проверки целостности заголовка и данных ICMP сообщения. Контрольная сумма вычисляется как побитовая инверсия суммы всех 16-битных слов в заголовке и данных.

Пример использования

При получении ICMP сообщения конечный узел вычисляет контрольную сумму и сравнивает её с полученной. Если значения не совпадают, сообщение считается поврежденным и отбрасывается, что помогает обеспечить целостность данных и защиту от ошибок.

4.     Остаток заголовка (Rest of header) (переменная длина)

В зависимости от типа и кода ICMP сообщения, это поле может включать дополнительные данные, такие как оригинальный IP заголовок и первые 8 байт оригинальной полезной нагрузки. Это поле позволяет включать дополнительную информацию, необходимую для диагностики.

Пример использования

В сообщениях о недостижимости назначения это поле содержит оригинальный IP заголовок и часть полезной нагрузки, что помогает отправителю идентифицировать, какой именно пакет вызвал ошибку. Это важно для устранения неполадок и корректировки маршрутизации.

❯ Заголовок ARP

ARP (Address Resolution Protocol) используется для определения MAC-адреса по известному IP-адресу.

Поля заголовка ARP:  

1.     Тип оборудования (Hardware type) 16 бит

Указывает тип оборудования, например, Ethernet (значение 1). Это поле помогает определить формат аппаратного адреса в сообщении ARP.

Пример использования

В сетях Ethernet значение этого поля всегда равно 1. Это позволяет узлам корректно интерпретировать формат аппаратных (MAC) адресов, используемых в сообщениях ARP. Когда узел получает ARP-запрос или ARP-ответ, он проверяет значение этого поля, чтобы убедиться, что сообщение предназначено для Ethernet-сети. Если значение не равно 1, сообщение игнорируется.

В сетях Wi-Fi (802.11) значение этого поля равно 1, как и в Ethernet (если используется стандартный MAC-адрес Ethernet).

В сетях FDDI (Fiber Distributed Data Interface) значение этого поля равно 6.

В сетях Infiniband значение этого поля равно 32.

В сетях, использующих технологии Frame Relay, значение этого равно 15.

2.     Тип протокола (Protocol type) 16 бит

Указывает тип протокола, для которого выполняется разрешение адресов.

Пример использования

В стандартных Ethernet-сетях значение этого поля для протокола IPv4 всегда равно 0x0800. Когда устройство отправляет ARP-запрос для определения MAC-адреса, связанного с IP-адресом, оно устанавливает значение этого поля в 0x0800.

Для IPv6 может использоваться значение 0x86DD.

В сетях MPLS (Multiprotocol Label Switching) значение поля ‭«Тип протокола‭» может быть 0x8847 для unicast-трафика или 0x8848 для multicast-трафика. Это помогает устройствам в сети понять, что ARP-запросы или ответы связаны с разрешением адресов в контексте MPLS.

3.     Длина аппаратного адреса (Hardware address length) 8 бит

Определяет длину аппаратного адреса, например, 6 байт для Ethernet.

Пример использования

В сетях Ethernet значение этого поля равно 6, что указывает на стандартную длину MAC-адреса (48 бит).

4.     Длина протокольного адреса (Protocol address length) 8 бит

Определяет длину протокольного адреса, например, 4 байта для IPv4. Это поле помогает определить размер IP-адреса.

Пример использования

Для протокола IPv4 значение этого поля равно 4, что указывает на стандартную длину IPv4-адреса (32 бита).

5.     Операция (Operation) 16 бит

Указывает тип ARP сообщения.

Пример использования

Когда устройство отправляет ARP-запрос, значение этого поля равно 1. Когда оно отвечает на запрос, значение равно 2. Это позволяет различать запросы и ответы.

6.     Аппаратный адрес отправителя (Sender hardware address) переменная длина

MAC-адрес отправителя сообщения ARP.

7.     Протокольный адрес отправителя (Sender protocol address) переменная длина

IP-адрес отправителя сообщения ARP.

8.     Аппаратный адрес получателя (Target hardware address) переменная длина

MAC-адрес получателя. В запросе ARP это поле заполнено нулями, поскольку адрес получателя ещё не известен.

9.     Протокольный адрес получателя (Target protocol address) переменная длина

IP-адрес получателя ARP запроса или ответа.

❯ Заголовок OSPF

OSPF (Open Shortest Path First) — это протокол маршрутизации, предназначенный для обмена информацией о маршрутах в IP-сетях. Поля заголовка OSPF включают важные данные для обеспечения правильной работы и аутентификации протокола. Вот подробное описание полей заголовка OSPF:

1.     Версия (Version) 8 бит

Указывает версию протокола OSPF, используемую в пакете. Это поле важно для обеспечения совместимости между различными версиями OSPF.

Пример использования

Версия 2 (значение 2) является самой распространенной и используется в большинстве сетевых устройств. Если поле содержит другую версию, например, 3, это указывает на использование OSPFv3, который поддерживает IPv6.

2.     Тип (Type) 8 бит

Указывает тип OSPF пакета, что позволяет узлам правильно интерпретировать и обработать полученные данные. Типы включают Hello (1), Database Description (2), Link State Request (3), Link State Update (4) и Link State Acknowledgment (5).

Пример использования

Пакет типа Hello используется для установления и поддержания соседства между маршрутизаторами. Пакеты типа Link State Update содержат обновления состояния ссылок, которые маршрутизаторы используют для построения своих маршрутизирующих таблиц.

3.     Длина пакета (Packet length) 16 бит

Указывает общую длину пакета OSPF, включая заголовок. Это поле помогает получателям правильно выделять память для обработки пакета.

Пример использования

Если длина пакета указана как 64 байта, это означает, что заголовок и данные OSPF занимают в сумме 64 байта. Это значение важно для правильного чтения и обработки всего пакета.

4.     ID маршрутизатора (Router ID) 32 бит

Уникальный идентификатор маршрутизатора, который отправил пакет. Это поле помогает идентифицировать источник пакета OSPF и различать маршрутизаторы в сети.

Пример использования

ID маршрутизатора может быть, например, 192.168.1.1. Это уникальное значение позволяет другим маршрутизаторам идентифицировать и связываться с источником пакета.

5.     ID области (Area ID) 32 бит

Идентифицирует область OSPF, к которой относится пакет. Это поле помогает разделять и организовывать сети OSPF на области для упрощения маршрутизации.

Пример использования

Если ID области имеет значение 0.0.0.0, это означает, что пакет относится к backbone области OSPF. Значение 1.0.0.1 может указывать на конкретную пользовательскую область в сети.

6.     Контрольная сумма (Checksum) 16 бит

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

Пример использования

Если контрольная сумма в пакете равна 0x1A2B, то получатели пакета могут вычислить свою контрольную сумму и сравнить её с этой значением, чтобы убедиться, что пакет не был поврежден в процессе передачи.

7.     Тип аутентификации (Authentication type) 16 бит

Указывает тип аутентификации, используемый для проверки подлинности пакета OSPF. Например, это может быть "None" для отсутствия аутентификации или ‭«Simple Password‭» для использования пароля.

Пример использования

Если значение поля равно 0, это указывает на отсутствие аутентификации. Если значение равно 1, это означает использование простого пароля, что может потребовать проверки пароля для безопасности.

8.     Аутентификация (Authentication) 64 бит

Содержит данные для аутентификации, если это предусмотрено типом аутентификации. Это поле используется для проверки подлинности пакета и защиты от несанкционированного доступа.

Пример использования

Если тип аутентификации установлен на ‭«Simple Password‭», это поле может содержать 64-битный пароль, который маршрутизаторы должны проверить для установления доверительных отношений. Если используется ‭«None‭», это поле будет заполнено нулями.

❯ Заголовок GRE 

GRE (Generic Routing Encapsulation) — это протокол, используемый для инкапсуляции различных сетевых протоколов в рамках одного сетевого соединения. Он позволяет создавать виртуальные туннели между узлами сети и передавать данные различных типов через этот туннель. Поля заголовка GRE помогают обеспечить правильную передачу данных и контроль за туннелем.

Original GRE packet header, описанный в RFC 1701 (Generic Routing Encapsulation (GRE)), был первым стандартом для GRE и заложил основу для инкапсуляции различных протоколов внутри IP-пакетов. Однако, на сегодняшний день RFC 1701 считается устаревшим.

Взамен его, используются более простые и эффективные версии, такие как те, что определены в RFC 2784 и RFC 2890. Эти новые стандарты обеспечивают совместимость и упрощают работу с GRE в современных сетевых приложениях.

Рассмотрим каждый из них отдельно.

RFC 2784 GRE:

• Это основной стандарт для GRE, который описывает базовую структуру заголовка GRE и его применение. Он является основой для всех других спецификаций GRE.

• RFC 2784 определяет минимальный заголовок GRE, который включает ключевые поля, такие как Protocol Type, позволяющее инкапсулировать различные типы протоколов внутри GRE.

Вот подробное описание полей данного заголовка GRE:

1. Флаги (Flag Bits) содержит различные управляющие биты, которые указывают на использование дополнительных функций или настроек. Значение 1 установлен, значение 0 не установлен. 

• Checksum Present  1 бит: этот флаг указывает, что в заголовке присутствует поле контрольной суммы (Checksum). Если установлен, значит после основного заголовка GRE следует поле контрольной суммы.

2. Зарезервировано 12 бит. Поле зарезервировано для будущих расширений и должно быть установлено в ноль.

3. Version : 3 бита. Поле, указывающее версию GRE. В настоящее время используется версия 0.

4. Тип протокола (Protocol Type) 2 байта.

Определяет тип протокола, который инкапсулируется в GRE-пакете. Например, для IP это значение будет 0x0800. Это поле позволяет идентифицировать, какой тип данных находится внутри GRE-пакета.

5.     Контрольная сумма (Checksum) 2 байта

Используется для проверки целостности данных в GRE-заголовке. Если флаг ‭«Checksum Present‭» установлен, это поле будет присутствовать. Контрольная сумма вычисляется на основе содержимого GRE-заголовка и данных, что позволяет обнаружить ошибки в передаче.

6. Зарезервировано 16 бит. Если установлен флаг Checksum Present, то данное поле присутствует и зарезервировано для будущих расширений и должно быть установлено в ноль.

7.  Инкапсулированный пакет (Data)

После заголовка GRE следует инкапсулированные данные. Эти данные могут быть любыми пакетами различных сетевых протоколов, которые инкапсулируются в GRE. Например, это могут быть IP-пакеты, Ethernet-кадры или другие типы данных.

RFC 2890 — ‭«Key and Sequence Number Extensions to GRE‭»:

• Этот документ является расширением RFC 2784 и добавляет поддержку для использования ключа (Key) и номера последовательности (Sequence Number) в заголовке GRE.

• Эти расширения позволяют обеспечивать уникальность туннелей, а также упорядоченность пакетов, что полезно для улучшения управления соединениями.
  

Вот подробное описание полей данного заголовка GRE:

1. Флаги (Flag Bits). Содержит различные управляющие биты, которые указывают на использование дополнительных функций или настроек. Значение 1 установлен, значение 0 не установлен.

• Checksum Present 1 бит: этот флаг указывает, что в заголовке присутствует поле контрольной суммы (Checksum). 

• Reserved 1 бит. В оригинальном GRE пакете (RFC 1701) присутствовал флаг Routing Present, в данном пакете данный флаг отсутствует, но место зарезервировано. 

• Key 1 бит: этот флаг указывает, что в заголовке присутствует поле ключа.

• Sequence number: этот флаг указывает, что в заголовке присутствует поле номер последовательности.

• Зарезервировано 9 бит. Поле зарезервировано для будущих расширений и должно быть установлено в ноль.

2. Version : 3 бита. Поле, указывающее версию GRE. В настоящее время используется версия 0.

   3. Тип протокола (Protocol Type) 2 байта

Определяет тип протокола, который инкапсулируется в GRE-пакете. Например, для IP это значение будет 0x0800. Это поле позволяет идентифицировать, какой тип данных находится внутри GRE-пакета.

4.     Контрольная сумма (Checksum) 2 байта

Используется для проверки целостности данных в GRE-заголовке. Если флаг «Checksum Present» установлен, это поле будет присутствовать. Контрольная сумма вычисляется на основе содержимого GRE-заголовка и данных, что позволяет обнаружить ошибки в передаче.

5.     Ключ (Key) 4 байта

Когда от одного отправителя передается несколько разных GRE туннелей, конечному получателю необходимо отличать какой туннель кому предназначен. Данное поле вводит уникальный индентификатор туннеля называемым ключом. 

6. Номер последовательности (Sequence Number) 4 байта.

7. Инкапсулированный пакет (Data)

После заголовка GRE следует инкапсулированные данные. Эти данные могут быть любыми пакетами различных сетевых протоколов, которые инкапсулируются в GRE. Например, это могут быть IP-пакеты, Ethernet-кадры или другие типы данных.

❯ Какие заголовки находятся в IP пакете на L4 уровне?

Давайте разберём заголовки протоколов 4 уровня (транспортного уровня), включая TCP, UDP, и SCTP. Каждый из этих протоколов имеет свои особенности и функции, отражённые в структуре их заголовков.

В этой статье я уже затрагивал данный уровень, зачем он нужен и какие функции выполняет.

❯ Заголовок TCP

TCP (Transmission Control Protocol) — это протокол транспортного уровня, который обеспечивает надежную, ориентированную на соединение передачу данных. Заголовок TCP содержит следующие поля:

1.     Порт источника (Source Port) 16 бит

Указывает номер порта источника, через который отправляются данные. Это поле помогает идентифицировать приложение или процесс на отправляющем узле, который инициировал передачу данных.

Пример использования

Если порт источника равен 80, это может указывать, что данные отправляются от веб-сервера, использующего HTTP.

2.     Порт назначения (Destination Port) 16 бит

Указывает номер порта назначения, на который должны быть отправлены данные. Это поле помогает направить данные к соответствующему приложению на стороне получателя.

Пример использования

Если порт назначения равен 25, это указывает на службу электронной почты (SMTP) на стороне получателя.

3.     Последовательный номер (Sequence Number) 32 бита

Указывает номер первого байта данных в сегменте TCP. Это поле используется для отслеживания порядка данных и их сборки в правильном порядке на стороне получателя.

Пример использования

Если последовательный номер равен 1001, это означает, что первый байт данных в этом сегменте имеет номер 1001.

4.     Номер подтверждения (Acknowledgment Number) 32 бита

Указывает следующий ожидаемый байт данных от отправителя. Это поле используется для подтверждения получения данных и управления потоком.

Пример использования

Если аккредитивный номер равен 2001, это означает, что получатель ожидает байт данных, начиная с номера 2001.

5.     Длина заголовка (Data offset) 4 бита

Указывает длину заголовка, измеряемую в 32-битных словах. Минимальный размер составляет 20 байт (пять 32-битных слов), а максимальный — 60 байт (пятнадцать 32-битных слов). Длина заголовка определяет смещение полезных данных относительно начала сегмента.

Пример использования

Значение Data offset, равное 1111_2, указывает, что заголовок занимает пятнадцать 32-битных слов (15 слов * 32 бита / 8 бит = 60 байт).

6.     Резерв (reserved) 3 бита

Зарезервировано для будущего использования (устанавливается в ноль).

7.     Флаги (flags) 9 бит

Содержит управляющие флаги, которые управляют состоянием соединения:

• NS (Nonce Sum): для защиты от атак, уточняет наличие изменений в данных.

• CWR (Congestion Window Reduced): сообщает о снижении окна перегрузки.

• ECE (ECN-Echo): сообщает о поддержке ECN (Explicit Congestion Notification).

• URG (Urgent): указывает на наличие срочных данных.

• ACK (Acknowledgment): указывает, что поле аккредитивного номера является действительным.

• PSH (Push): указывает, что данные должны быть немедленно переданы приложению.

• RST (Reset): используется для сброса соединения, если оно не может быть установлено или поддержано.

• SYN (Synchronize): инициирует соединение, синхронизируя начальные последовательные номера.

• FIN (Finish): завершает соединение, указывая на окончание передачи данных.

Пример использования

Если флаг SYN установлен, это указывает на начало установления соединения.

8.     Размер окна (Window size) 16 бит

Указывает размер окна приемника, который показывает, сколько данных может быть отправлено до получения подтверждения. Это поле управляет потоком данных и предотвращает переполнение буфера.

Пример использования

Если размер окна равен 4096, это означает, что получатель может принять до 4096 байт данных, прежде чем потребуется подтверждение.

9.     Контрольная сумма (Checksum) 16 бит

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

Пример использования

Если контрольная сумма обнаруживает несоответствия, пакет может быть отклонен, и данные будут повторно запрошены.

10.  Указатель срочных данных (Urgent Pointer) 16 бит

Указывает смещение до конца срочных данных, если установлен флаг URG. Это поле позволяет обработать срочные данные перед обычными данными.

Пример использования

Если указатель срочных данных равен 100, это означает, что срочные данные заканчиваются через 100 байт от начала сегмента.

11. Опции (Options) переменная длина

Используется для различных дополнительных параметров, таких как максимальный размер сегмента (MSS) и другие параметры, специфичные для TCP. Если опций нет, это поле может быть заполнено нулями.

Пример использования

Опция MSS может указать максимальный размер сегмента, который может быть принят без фрагментации.

12.  Заполнение (переменная длина)

• Описание: обеспечивает кратность длины заголовка 32 битам. Это поле используется только в случае, если длина заголовка не кратна 32 битам, и заполняется нулями.

• Пример использования: если заголовок TCP имеет длину 20 байт, и поле опций занимает 4 байта, то для кратности 32 битам может быть добавлено 4 байта заполнения.

❯ Заголовок UDP

UDP (User Datagram Protocol) — это протокол транспортного уровня, который обеспечивает передачу данных без установления соединения. Заголовок UDP содержит следующие поля:

1.     Порт источника (Source port) 16 бит

Указывает номер порта источника, который инициирует передачу данных. Это поле помогает идентифицировать приложение или процесс, отправляющий данные.

Пример использования

Если порт источника равен 53, это указывает на службу DNS.

2.     Порт назначения (Destination port) 16 бит

Указывает номер порта назначения, на который должны быть отправлены данные. Это поле помогает направить данные к соответствующему приложению на стороне получателя.

Пример использования 

Если порт назначения равен 67, это указывает на службу DHCP.

3.     Длина (Length) 16 бит

Указывает общую длину заголовка UDP и данных в байтах. Это поле помогает определить размер передаваемых данных и обеспечивает корректное чтение пакета.

Пример использования

Если длина равна 28 байт, это означает, что заголовок UDP и данные занимают 28 байт в сумме.

4.     Контрольная сумма (Checksum) 16 бит

Используется для проверки целостности заголовка и данных UDP. Контрольная сумма вычисляется для обеспечения отсутствия ошибок в передаче данных. Это поле является опциональным в некоторых реализациях, но рекомендуется для проверки.

Пример использования 

Если контрольная сумма равна 0, это может указывать на то, что проверка контрольной суммы не была выполнена, что может быть разрешено в некоторых сетевых конфигурациях.

❯ Заголовок SCTP

SCTP (Stream Control Transmission Protocol) — это протокол транспортного уровня, который обеспечивает передачу данных с поддержкой нескольких потоков и надежности. Заголовок SCTP содержит следующие поля:

1.     Порт источника (Source port) 16 бит

Указывает номер порта источника, через который отправляются данные. Это поле помогает идентифицировать приложение, которое инициировало передачу данных.

Пример использования

Если порт источника равен 5000, это может указывать на специфическое приложение, использующее SCTP для связи.

2.     Порт назначения (Destination port) 16 бит

• Описание: указывает номер порта назначения, на который должны быть отправлены данные. Это поле помогает направить данные к соответствующему приложению на стороне получателя.

• Пример использования: если порт назначения равен 6000, это может указывать на приложение, которое принимает данные через SCTP.

3.     Тег подтверждения (Verification tag) 32 бита

Поле Verification Tag используется для защиты от подделки соединений и обеспечения того, что только ожидаемые и авторизованные сообщения могут быть обработаны.

Пример использования

·  Установление соединения: когда клиент и сервер устанавливают соединение через SCTP, они обмениваются начальным сообщением, которое содержит Verification Tag. Этот тег используется для подтверждения того, что обе стороны согласны на установление соединения и что они являются теми, за кого себя выдают.

·  Аутентификация сообщений: Verification Tag также используется для проверки того, что приходящие сообщения действительно принадлежат текущему соединению. Это помогает предотвратить атаки типа «man-in-the-middle» и гарантирует, что сообщения не будут случайно или намеренно отправлены в неправильное соединение.

·  Смена Verification Tag: при установлении соединения Verification Tag выбирается случайным образом одной из сторон (например, сервером) и передается другой стороне (например, клиенту). Клиент должен вернуть этот тег обратно в своем ответном сообщении. Оба участника соединения используют этот тег для проверки целостности и принадлежности сообщений к установленному соединению.

4.     Данные чанка (Chunk Data) переменная длина

Каждое сообщение SCTP состоит из одного заголовка и одного или нескольких чанков (chunks). Чанки могут быть разных типов, включая:

• DATA: передает пользовательские данные.

• INIT: инициирует соединение.

• INIT ACK: подтверждает установление соединения.

• SACK (Selective Acknowledgment): используется для подтверждения получения данных.

• HEARTBEAT: проверяет доступность пути.

• HEARTBEAT ACK: подтверждает получение HEARTBEAT.

• ABORT: разрывает соединение.

• SHUTDOWN: завершает передачу данных.

Пример заголовка SCTP с чанком DATA:

Заголовок SCTP

1. Source Port: 16 бит

2. Destination Port: 16 бит

3. Verification Tag: 32 бита

4. Checksum: 32 бита

Чанк DATA

1. Тип (Type): 8 бит

2. Флаги (Flags): 8 бит

3. Длина (Length): 16 бит

4. Порядковый номер передачи (Transmission Sequence Number): 32 бита

5. Потоковый идентификатор (Stream Identifier): 16 бит

6. Порядковый номер в потоке (Stream Sequence Number): 16 бит

7. TSN (Payload Protocol Identifier): 32 бита

8. Данные (Data): переменная длина

Это структура одного из типов чанков. Другие типы чанков имеют свои собственные специфичные поля.

❯ Заключение

Заголовки на сетевом и транспортном уровнях модели OSI являются критически важными для обеспечения надежной и эффективной передачи данных в сетях. Понимание их структуры и функций позволяет сетевым администраторам и инженерам не только настраивать и оптимизировать сети, но и решать проблемы, связанные с производительностью и безопасностью. С учетом сложностей, таких как фрагментация, переход на IPv6 и уязвимости, важно постоянно обновлять знания и внедрять лучшие практики для поддержания эффективной и безопасной сетевой инфраструктуры. В будущем, с развитием технологий и появлением новых протоколов, наше понимание и подходы к работе с сетевыми заголовками будут продолжать эволюционировать, что потребует дальнейшего обучения и адаптации.

---

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

? Читайте также:

• ➤ Апгрейд мобильного компьютера паяльником;

• ➤ Ленточные накопители в домашнем ПК;

• ➤ Управляем проектом и его документацией при помощи Python;

• ➤ Как мы задумали небольшую выставку, а в итоге открыли два неизвестных советских компьютера;

• ➤ Как создавалась антология Риддика.