Энциклопедия сетевых протоколов

Статус документа

Этот документ является спецификацией стандарта Internet, предназначенного для сообщества Internet, и служит приглашением к дискуссии в целях развития протокола. Сведения о текущем состоянии стандартизации протокола можно найти в документе Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Аннотация

Этот документ отменяет RFC 2960 и RFC 3309. Документ описывает протокол управления потоковой передачей SCTP¹. Протокол SCTP предназначен для передачи сигнальных сообщений PSTN² через сети IP, но может использоваться и для других приложений.

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

передача пользовательских данных с корректировкой ошибок, подтверждением доставки и отсутствием дубликатов;
фрагментирование данных в соответствии с определенным для пути значением MTU³;
упорядоченная доставка пользовательских сообщений внутри множества потоков с возможностью управления порядком доставки отдельных пользовательских сообщений;
возможность группировки пользовательских сообщений в один пакет SCTP;
устойчивость к отказам на сетевом уровне за счёт поддержки многодомных хостов на обеих сторонах соединения.

Протокол SCTP включает механизмы предотвращения насыщения и устойчивости к атакам с использованием лавины пакетов (flooding) или маскированием адресов (masquerade).

1. Введение

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

Этот документ заменяет собой [RFC2960] и [RFC3309].

1.1. Мотивация

Протокол TCP [RFC793] обеспечивает, прежде всего, гарантированную доставку данных в сетях IP. Однако многие современные приложения сталкиваются с ограниченными возможностями TCP и вынуждены реализовать свои средства обеспечения гарантированной доставки на основе транспорта UDP [RFC768]. Ниже перечислены основные ограничения TCP, которые пользователи стремятся обойти.

Протокол TCP обеспечивает гарантию доставки данных с сохранением их порядка. Некоторым приложениям требуется лишь гарантированная доставка, независимо от порядка, а другим приложениям может быть достаточно частичного сохранения порядка доставки. Оба типа приложений не устраивают дополнительные задержки TCP, возникающие при нарушении порядка доставки пакетов в сети.
Потоковая природа протокола TCP зачастую не подходит для приложений, которым приходится вводить свои средства маркировки записей для делинеаризации передаваемых сообщений. Кроме того, приложениям приходиться явно использовать средства «выталкивания» данных (push) для того, чтобы сообщение было передано полностью за разумное время.
Ограниченные возможности сокетов TCP усложняют для приложений задачу обеспечения высокого уровня доступности при обмене данными за счёт использования многодомных⁴ хостов.
Протокол TCP достаточно слабо защищён от атак на службы⁵, в частности, от SYN-атак.

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

1.2. Архитектура SCTP

Протокол SCTP размещается в многоуровневой модели между уровнем пользовательских приложений SCTP и сетевым сервисом без организации явных соединений (например, IP). В остальной части этого документа предполагается, что SCTP работает «поверх» протокола IP. Основным типом сервиса, обеспечиваемого протоколом SCTP, является гарантированная передача сообщений между пользователями SCTP. Этот сервис обеспечивается в контексте ассоциаций между парами конечных точек SCTP. В параграфе 10 данного документа приводится схематическое рассмотрение интерфейса API, который должен существовать на границе между протоколом SCTP и пользовательскими приложениями SCTP.

Протокол SCTP работает на основе явных соединений⁶, но ассоциация SCTP представляет собой более широкое понятие, нежели соединение TCP. Протокол SCTP обеспечивает для каждой конечной точки SCTP (см. параграф 1.4) способ обеспечения другой конечной точки (в процессе создания ассоциации) списком транспортных адресов (т. е. множеством адресов IP в комбинации с номером порта SCTP), которые конечная точка может использовать для связи и откуда она будет получать пакеты SCTP. Ассоциация может передавать данные с использованием всех возможных пар адресов отправителя и получателя, которые могут быть созданы на основе списков адресов конечных точек.

_______ _ | Приложения | | Приложения | | SCTP | | SCTP | |————-| |————-| |Транспортный | |Транспортный | | сервис SCTP | | сервис SCTP | |————-| |————-| | Сетевой |Один или —- Один или | Сетевой | | сервис IP |несколько \/ несколько | сервис IP | | |адресов IP /\ адресов IP | | |_| —- |_______| SCTP-узел A |<——— Сетевой транспорт ——->| SCTP-узел B

Рисунок 1. SCTP-ассоциация.

1.3. Основные термины

Некоторые термины, используемые в контексте SCTP, уже были упомянуты в предыдущих параграфах. Здесь даются определения основных терминов, связанных с протоколом.

Active destination transport address — активный транспортный адрес получателя

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

Bundling — группировка

Дополнительная операция мультиплексирования, позволяющая передать в одном пакете несколько сообщений SCTP. Каждое пользовательское сообщение помещается в отдельный блок DATA.

Chunk — блок

Единица информации в пакете SCTP, содержащая заголовок блока (chunk header) и данные.

Congestion window (cwnd) — окно насыщения

Переменная SCTP, ограничивающая объем данных (число байтов), которые отправитель может передать в один активный адрес получателя до получения от последнего подтверждения.

Cumulative TSN Ack Point — указатель на кумулятивный номер Ack

Значение TSN для последнего блока DATA, подтверждённого с использованием поля Cumulative TSN Ack в SACK.

Idle destination address — неиспользуемый адрес получателя

Адрес, который не используется для передачи пользовательских сообщений в течение некоторого периода (обычно ≥ HEARTBEAT).

Inactive destination transport address — неактивный транспортный адрес получателя

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

Message = user message — пользовательское сообщение

Данные, полученные протоколом SCTP от протокола вышележащего уровня (Upper Layer Protocol или ULP).

Message Authentication Code (MAC) — код аутентификации сообщения

Механизм проверки целостности, основанный на криптографической хэш-функции с секретным ключом. Обычно коды аутентификации сообщений используются между партнёрами, использующими общий секретный ключ для проверки целостности информации, передаваемой между системами. В SCTP этот код применяется конечными точками для проверки информации State Cookie, полученной от удалённой стороны в блоке COOKIE ECHO. Термин MAC может иметь различные трактовки в разном контексте. В SCTP этот термин используется в том же значении, которое принято в [RFC2104].

Network Byte Order — сетевой порядок байтов

Порядок передачи байтов, при котором старший байт следует первым. Синоним Big Endian.

Ordered Message — упорядоченные сообщения

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

Outstanding TSN (at an SCTP endpoint)

Номер TSN (и связанный с ним блок DATA), который был передан конечной точкой, но его получение еще не подтверждено.

Path — путь

Маршрут, используемый пакетами SCTP, переданными одной конечной точкой SCTP по определённому транспортному адресу другой конечной точки SCTP. Передача пакетов по различным транспортным адресам удалённой точки не обязательно ведёт к изменению пути.

Primary Path — основной путь

Комбинация адресов отправителя и получателя которая будет помещаться в исходящие пакеты SCTP по умолчанию. Адрес отправителя включён в определение потому, что реализации протокола могут указывать оба адреса (получателя и отправителя) для обеспечения контроля пути возврата блоков с откликами и выбора интерфейса для передачи пакетов многодомными хостами.

Receiver Window (rwnd) — приёмное окно

Переменная SCTP, которую отправитель использует для хранения последнего рассчитанного значения размера окна приёма своего партнёра по ассоциации. Размер окна приёма задаётся количеством байтов. Значение размера позволяет отправителю определить величину свободного пространства в приёмном буфере получателя.

SCTP association — ассоциация SCTP

Протокольные отношения между конечными точками SCTP, включающие пару узлов SCTP и информацию о состоянии протокола (теги Verification, активные значения TSN и т. п.). Для уникальной идентификации ассоциаций SCTP могут использоваться пары транспортных адресов конечных точек ассоциации. Между любой парой конечных точек SCTP недопустимо одновременное существование нескольких ассоциаций.

SCTP endpoint — конечная точка SCTP

Логический приёмник/передатчик пакетов SCTP. Для многодомных хостов конечная точка SCTP представляется своему партнёру как комбинация набора допустимых транспортных адресов, по которым можно передавать пакеты SCTP и набора допустимых адресов транспортного уровня, с которых могут приниматься пакеты SCTP. Все транспортные адреса, используемые конечной точкой SCTP, должны быть связаны с одним номером порта, но могут иметь различные адреса IP. Транспортные адреса, используемые конечной точкой SCTP, недопустимо устанавливать для другой конечной точки SCTP (транспортный адрес каждой конечной точки SCTP должен быть уникальным).

SCTP packet (packet) — пакет SCTP

Элемент данных, передаваемый через интерфейс между SCTP и пакетной сетью без организации соединений (например, IP). Пакет SCTP включает общий заголовок SCTP, а также блок пользовательских данных (DATA chunk) и может включать блок управления SCTP.

SCTP user application (SCTP user) — пользовательское приложение SCTP (пользователь SCTP)

Логический объект вышележащего уровня, который использует сервис SCTP. Используется также термин Upper-layer Protocol (ULP) — протокол вышележащего уровня.

Slow-Start Threshold (ssthresh) — порог замедленного старта

Переменная SCTP, определяющая пороговое значение, по которому конечная точка будет определять необходимость использования для конкретного транспортного адреса процедуры slow start или congestion avoidance. Значение ssthresh указывается в байтах.

Stream — поток

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

Stream Sequence Number — порядковый номер в потоке

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

Tie-Tags

Два 32-битовых случайных значений, которые вместе образуют 64-битовое одноразовое значение nonce. Эти теги используются в State Cookie и TCB для связывания недавно перезапущенной ассоциации с её предшественником на конечной станции, которая не была перезагружена, но, тем не менее, не может найти тегов Verification существующей ассоциации.

Transmission Control Block (TCB) — блок управления передачей

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

Transmission Sequence Number (TSN)— порядковый номер при передаче

32-битовый порядковый номер, используемый протоколом SCTP для нумерации передаваемых блоков. Значение TSN связывается с каждым блоком, который содержит пользовательские данные, чтобы дать возможность конечной точке SCTP на приёмной стороне подтвердить приём блока и обнаружить дубликаты.

Transport address — транспортный адрес

Адрес транспортного уровня обычно определяется комбинацией адреса сетевого уровня, транспортным протоколом и номером порта на транспортном уровне. При использовании SCTP в сетях IP транспортный адрес представляет собой комбинацию адреса IP и номера порта SCTP (транспортным протоколом является SCTP).

Unacknowledged TSN (at an SCTP endpoint) — неподтвержденный TSN (в конечной точке SCTP)

Номер TSN (и связанный с ним блок DATA), который был получен конечной точкой, но приём этого блока еще не был подтверждён удалённой стороне. С точки зрения передающей стороны это случай, когда пакет был передан, но подтверждение еще не получено.

Unordered Message — неупорядоченные сообщения

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

User message — пользовательское сообщение

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

Verification Tag — тег верификации

32-битовое беззнаковое целое значение, которое обычно выбирается с использованием генератора случайных чисел. Verification Tag позволяет получателю проверить принадлежность полученного пакета SCTP к ассоциации и избавиться от старых пакетов из прежних ассоциаций.

1.4. Сокращения

MAC — Message Authentication Code [RFC2104] (код аутентификации сообщения).

RTO — Retransmission Timeout (тайм-аут повтора передачи).

RTT — Round-Trip Time (время кругового обхода).

RTTVAR — Round-Trip Time Variation (вариации времени кругового обхода).

SCTP — Stream Control Transmission Protocol (протокол управления потоковой передачей).

SRTT — Smoothed RTT (сглаженное значение RTT).

TCB — Transmission Control Block (блок управления передачей).

TLV — Type-Length-Value coding format (формат представления тип-размер-значение).

TSN — Transmission Sequence Number (порядковый номер при передаче).

ULP — Upper-Layer Protocol (протокол вышележащего уровня).

1.5. Функциональность SCTP

Транспортный сервис SCTP можно разделить на несколько функциональных групп, показанных на рисунке 2.

Пользовательские приложения SCTP —————————————————— _ | | | Упорядоченная | | Создание | | доставка в потоке | | | || | и | | | | разрыв | | Фрагментация польз. данных | | | || | ассоциаций | | | | | | Подтверждения | | | | и предотвращения | | | | насыщения | | | || | | | | | | | Связывание блоков | | | || | | | | | | | Проверка пакетов | | | || | | | | __________ | | | Управление путями | |_| |__________________________|

Рисунок 2. Функциональное представление сервиса SCTP.

1.5.1. Создание и разрыв ассоциаций

Ассоциации создаются по запросам пользователей SCTP (см. описание примитива ASSOCIATE на стр. 48 или SEND на стр. 49).

В процессе создания ассоциаций используется механизм cookie, подобный предложенному Кэрном (Karn) и Симпсоном (Simpson) в [RFC2522], для обеспечения защиты от атак на синхронизацию. Этот механизм использует четырехэтапное согласование (four-way handshake), в котором два последних этапа могут использоваться для передачи пользовательских данных в целях ускорения процедуры соединения. Стартовые последовательности описаны в главе 5 данного документа.

Протокол SCTP обеспечивает аккуратное завершение работы активных ассоциаций (shutdown) по запросу пользователя SCTP (см. описание примитива SHUTDOWN на стр. 49). Протокол SCTP позволяет также разрывать ассоциации (abort) по запросу пользователя (примитив ABORT) или в результате обнаружения ошибок на уровне SCTP. В главе 9 описаны оба варианта завершения работы ассоциаций.

Протокол SCTP не поддерживает полуоткрытых состояний (как в TCP), когда одна сторона может передавать данные после того, как другая сторона уже закрыла соединение. Когда любая из конечных точек выполняет процедуру завершения shutdown, на обеих сторонах ассоциации прекращается приём новых данных и доставляются лишь данные из очереди (см. главу 9).

1.5.2. Упорядоченная доставка в потоках

Термин «поток» (stream) используется в протоколе SCTP для обозначения последовательности пользовательских сообщений, которые доставляются протоколам вышележащих уровней в том же порядке, который сообщения имели в самом потоке. Это отличается от значения термина поток в контексте TCP, где потоком называют последовательности байтов (в этом документе предполагается, что размер байта составляет 8 битов).

Пользователь SCTP может во время создания ассоциации задать число потоков, поддерживаемых этой ассоциацией. Это значение согласуется с удалённой стороной (см. параграф 5.1.1). Пользовательские сообщения связываются с номерами потоков (см. примитивы SEND на стр. 49 и RECEIVE на стр. 50). Протокол SCTP присваивает порядковые номера в потоке каждому сообщению, полученному протоколом от пользователя SCTP. На приёмной стороне SCTP обеспечивает доставку сообщений пользователю с сохранением их последовательности в данном потоке. В силу того, что один поток может быть заблокирован ожиданием следующего по порядку пользовательского сообщения, в это время возможна доставка сообщений из других потоков.

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

1.5.3. Фрагментация пользовательских данных

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

1.5.4. Подтверждения и предотвращение насыщения

Протокол SCTP присваивает номер TSN каждому фрагменту и нефрагментированному пользовательскому сообщению. Нумерация TSN не зависит от порядковых номеров в потоках, присваиваемых на уровне потока. Принимающая сторона подтверждает все полученные TSN даже при обнаружении пропуска в номерах. Такой подход обеспечивает независимую функциональность для гарантии доставки и сохранения порядка сообщений.

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

1.5.5. Группировка блоков

Как описано в главе 3, пакет SCTP, передаваемый на нижележащий уровень, содержит общий заголовок, за которым следует один или несколько информационных блоков (chunk). Каждый блок может содержать пользовательские данные или управляющую информацию SCTP. Пользователь SCTP может запросить группировку нескольких сообщений в один пакет SCTP. Функция группировки блоков (chunk bundling) протокола SCTP отвечает за сборку таких пакетов и их последующую разборку на приёмной стороне.

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

1.5.6. Проверка пакетов

Обязательное поле Verification Tag и 32-битовая контрольная сумма (см. Приложение B, в котором приведено описание контрольных сумм CRC32c), передаются в общем заголовке SCTP. Значение Verification Tag выбирается каждой стороной в процессе создания ассоциации. Пакеты, полученные без ожидаемого значения Verification Tag, отбрасываются в целях защиты от атак вслепую с маскированием адресов и избавления от старых пакетов SCTP, оставшихся от предыдущей ассоциации. Контрольная сумма CRC32c помещается отправителем в каждый пакет SCTP для обеспечения дополнительной защиты от повреждения данных в сети. Получатель пакета SCTP с некорректной контрольной суммой CRC32c отбрасывает такие пакеты без уведомления.

1.5.7. Управление путями

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

При создании ассоциации определяется основной путь (primary path) для каждой конечной точки SCTP. Этот путь в дальнейшем используется при нормальных условиях работы.

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

Примечание. Функции Path Management и Packet Validation выполняются одновременно, хотя и описаны по отдельности (в реальности эти функции не могут выполняться независимо одна от другой).

1.6. Порядковые номера

Важно помнить, что пространство пространство порядковых номеров TSN ограничено, хотя и достаточно велико. Значения порядковых номеров могут находиться в диапазоне от 0 до 2³² — 1. Ввиду конечных размеров пространства номеров TSN все арифметические операции с такими номерами должны осуществляться по модулю 2³² — это обеспечит возможность после достижения максимального значения TSN снова перейти к номеру 0. При сравнении значений порядковых номеров следует принимать во внимание цикличность их изменения. Символ =< применительно к TSN означает «меньше или равно» (модуль 2³²).

При арифметических операциях и сравнении номеров TSN для протокола SCTP следует пользоваться арифметикой порядковых номеров, определённой в [RFC1982] для случая SERIAL_BITS = 32.

Конечным точкам не следует передавать блоки DATA со значением TSN, которое более чем на 2³¹ — 1 превышает начальное значение TSN для текущего окна передачи. Использование таких значений может привести к возникновению проблем при сравнении TSN.

Порядковые номера TSN сбрасываются в 0 при достижении границы 2³² — 1. Т. е., следующий блок DATA после блока с TSN = 2³² — 1 должен иметь TSN = 0.

Во всех арифметических операциях с порядковыми номерами в потоках (Stream Sequence Number) следует использовать арифметику порядковых номеров, определённую в [RFC1982] для случая SERIAL_BITS = 16. Все прочие операции с порядковыми номерами в данном документе используют обычную арифметику.

1.7. Отличия от RFC 2960

Протокол SCTP был изначально определён в [RFC2960], который данный документ отменяет. Читателям, интересующимся подробностями отличий, рекомендуется прочесть [RFC4460].

2. Соглашения о терминах

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с [RFC 2119].

3. Формат пакетов SCTP

Пакет SCTP состоит из общего заголовка и блоков (chunk), содержащих пользовательские сообщения или управляющую информацию.

Формат пакетов SCTP показан на рисунке.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Common Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | … | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
В одном пакете SCTP может содержаться множество блоков, пока размер пакета не превышает значение MTU. Исключение составляют блоки INIT, INIT ACK, и SHUTDOWN COMPLETE, которые недопустимо группировать с другими блоками в один пакет. Более подробное описание группировки блоков приводится в параграфе 6.10.

Если пользовательское сообщение не помещается в пакет SCTP, оно может быть разделено на фрагменты с использованием процедуры, описанной в параграфе 6.9.

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

3.1. Описание полей общего заголовка SCTP

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | Destination Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Verification Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Формат SCTP Common Header показан на рисунке.

Source Port Number — 16 битов (целое число без знака)

Номер порта SCTP, используемого отправителем. Это значение, вместе с IP-адресом отправителя, номером порта получателя и (возможно) IP-адресом получателя, может использоваться на приёмной стороне для идентификации ассоциации, к которой относится пакет. Значение 0 для номера порт недопустимо.

Destination Port Number — 16 битов (целое число без знака)

Номер порта SCTP, в который данный пакет адресован. На приёмной стороне это значение будет использоваться для демультиплексирования пакета SCTP соответствующей конечной точке или приложению. Значение 0 для номера порт недопустимо.

Verification Tag — 32 бита (целое число без знака)

Принимающая сторона использует тег Verification для проверки отправителя пакета SCTP. На передающей стороне значение поля Verification Tag должно устанавливаться в соответствии со значением Initiate Tag, полученным от партнёра при создании ассоциации, за исключением перечисленных ниже случаев.

В пакетах, содержащих блок INIT, тег Verification должен быть установлен в 0.
В пакетах, содержащих блок SHUTDOWN-COMPLETE с установленным флагом T, значение тега Verification должно копироваться из пакета с блоком SHUTDOWN-ACK.
В пакетах, содержащих блок ABORT, тег верификации может быть копией значения тега из пакета, вызвавшего передачу блока ABORT. Более подробное описание приведено в параграфах 8.4 и 8.5.

Блок INIT должен быть единственным блоком в пакете SCTP.

Checksum — 32 бита (целое число без знака)

Это поле содержит контрольную сумму для данного пакета SCTP. Расчёт контрольных сумм описан в параграфе 6.8. Протокол SCTP использует алгоритм CRC32c, описанный в Приложении B.

3.2. Описание поля Chunk

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
На рисунке показан формат блоков (chunk), передаваемых в пакетах SCTP. Каждый блок содержит поле Chunk Type, зависящие от типа флаги (Flags), поле размера Chunk Length и поле данных Value.

Chunk Type — 8 битов (целое число без знака)

Это поле указывает тип блока, содержащегося в поле Chunk Value. Поле типа может содержать значения от 0 до 254. Значение 255 зарезервировано для будущего использования в качестве расширения.

Значения идентификаторов типа приведены в таблице.

ID	Тип блока	ID	Тип блока
0	Пользовательские данные (DATA)	12	Зарезервировано для Explicit Congestion Notification Echo (ECNE)
1	Инициализация (INIT)	13	Зарезервировано для Congestion Window Reduced (CWR)
2	Подтверждение инициирования (INIT ACK)	14	Процедура окончания работы завершена (SHUTDOWN COMPLETE)
3	Выборочное подтверждение (SACK)	15 — 62	Доступны
4	Запрос Heartbeat (HEARTBEAT)	63	Резерв для определённых IETF расширений
5	Подтверждение Heartbeat (HEARTBEAT ACK)	64 — 126	Доступны
6	Прерывание (ABORT)	127	Резерв для определённых IETF расширений
7	Завершение работы (SHUTDOWN)	128 — 190	Доступны
8	Подтверждение завершения (SHUTDOWN ACK)	191	Резерв для определённых IETF расширений
9	Ошибка при операции (ERROR)	192 — 254	Доступны
10	State Cookie (COOKIE ECHO)	255	Резерв для определённых IETF расширений
11	Подтверждение Cookie (COOKIE ACK)

Коды Chunk Type выбраны таким образом, чтобы два старших бита определяли действие, которое следует предпринять конечной точке на приёмной стороне, если Chunk Type не удаётся распознать.

00 — прекратить обработку данного пакета SCTP и отбросить его, не выполняя никаких действий по отношению к содержащейся в нем информации

01 — прекратить обработку пакета SCTP и отбросить его без выполнения каких либо действий с содержащимися в пакете данными, указать неопознанный параметр в поле Unrecognized Parameter Type.

10 — пропустить данный блок и продолжить обработку пакета.

11 — пропустить данный блок и продолжить обработку пакета с генерацией блока ERROR, содержащего в поле Unrecognized Chunk Type сведения о причине ошибки.

Примечание. Типы типы ECNE и CWR зарезервированы для использования в будущем явных уведомлений о насыщении (ECN⁷), описанных в Приложении A.

Chunk Flags — 8 битов

Использование этих битов определяется типом блока, указанным в поле Chunk Type. Если в документе явно не указано иное, на передающей стороне все биты следует устанавливать в 0, а на приёмной — игнорировать.

Chunk Length — 16 битов (целое число без знака)

Это поле указывает размер блока в байтах с учётом полей Chunk Type, Chunk Flags, Chunk Length и Chunk Value. Следовательно, для блоков с пустым Chunk Value поле Length имеет значение 4. Байты заполнения в поле Chunk Length не учитываются.

Блоки (включая поля Type, Length и Value) дополняются отправителем нулями для выравнивания по 4-байтовой границе. Использовать заполнение размером более 3 байтов недопустимо. Значение поля Chunk Length не учитывает заполнение в конце блока. Однако в размере учитывается заполнение в любых параметрах переменного размера, за исключением последнего параметра в блоке. Получатель должен игнорировать заполнение.

Примечание. Отказоустойчивым реализациям следует воспринимать блоки даже в тех случаях, когда поле Chunk Length учитывает заполнение.

Chunk Value — переменный размер

Поле Chunk Value содержит передаваемую в этом блоке информацию. Формат этого поля и способы его использования зависят от значения Chunk Type.

Общий размер блока (включая поля Type, Length и Value) должен быть кратным 4. Если размер блока не кратен 4, отправитель должен дополнить блок байтами со значением 0, не учитывая эти байты в поле Chunk Length. Заполнение размером долее 3 байтов недопустимо. Получатель должен игнорировать байты заполнения.

Подробное описание используемых в SCTP блоков приводится в параграфе 3.3. Руководства для создания расширений, определяемых IETF, приведены в параграфе 14.1.

3.2.1. Необязательные параметры и поля переменного размера

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Parameter Type | Chunk Parameter Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Chunk Parameter Value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Блоки управления SCTP включают зависящий от типа блока заголовок с набором полей, за которым может следовать то или иное количество параметров. Необязательные параметры и поля переменной длины указываются в формате TLV⁸ как описано ниже.

Chunk Parameter Type — 16 битов (целое число без знака)

Поле Type содержит 16-битовый идентификатор типа параметра и может принимать значения от 0 до 65534.

Значение 65535 зарезервировано для определяемых IETF расширений. Все значения, кроме перечисленных в данном документе при описании конкретных блоков SCTP, зарезервированы для использования IETF.

Chunk Parameter Length — 16 битов (целое число без знака)

Поле Parameter Length указывает размер параметра в байтах с учётом полей Parameter Type, Parameter Length и Parameter Value. Следовательно, для параметров с полем Parameter Value данное поле имеет значение 4. Поле размера не учитывает байты заполнения.

Chunk Parameter Value — переменный размер

Поле Parameter Value содержит информацию, передаваемую с помощью данного параметра.

Общий размер параметра (включая поля Type, Length и Value) должен быть кратным 4. Если размер параметра не кратен 4, отправитель добавляет в конце (т. е. после Parameter Value) байты с нулевым значением. Байты заполнения не учитываются в поле размера. Для отправителя недопустимо использование более 3 байтов заполнения. Получатель должен игнорировать байты заполнения.

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

00 — прекращение обработки данного параметра и отказ от обработки других параметров данного блока.

01 — прекращение обработки данного параметра и отказ от обработки других параметров данного блока с генерацией сообщения об ошибке, указывающего нераспознанный параметр в поле Unrecognized Parameter, как описано в параграфе 3.2.2.

10 — пропуск параметра и продолжение обработки.

11 — пропуск параметра и продолжение обработки с генерацией сообщения об ошибке, указывающего нераспознанный параметр в поле Unrecognized Parameter, как описано в параграфе 3.2.2.

Следует отметить, что во всех 4 случаях передаётся блок INIT ACK или COOKIE ECHO. Для случаев 00 и 01 обработка параметров после неизвестного параметра не производится, но уже обработанные параметры не отбрасываются.

Реальные параметры SCTP определяются в параграфах, посвящённых конкретным блокам SCTP. Правила для определённых IETF расширений параметров определены в параграфе 14.2. Отметим, что тип параметра должен быть уникальным для всех блоков. Например, тип параметра 5 используется для представления адресов IPv4 (см. параграф 3.3.2.1). Значение 5 в этом случае резервируется во всех блоках для представления адресов IPv4 и недопустимо его использование в ином смысле в любом другом блоке.

3.2.2. Уведомления о неизвестных параметрах

Если получатель блока INIT обнаруживает неизвестные параметры и сообщает о них в соответствии с параграфом 3.2.1, он должен указать эти параметры в поле Unrecognized Parameter блока INIT ACK, передаваемого в ответ на INIT. Отметим, что если получатель блока INIT не организует ассоциацию (например, по причине нехватки ресурсов), поле Unrecognized Parameter не включается в блок ABORT, передаваемый в ответ на INIT.

Если получатель блока INIT ACK обнаруживает неизвестные параметры и сообщает о них в соответствии с параграфом 3.2.1, ему следует сгруппировать блок ERROR, содержащий поле Unrecognized Parameters с указанием причины ошибки, с блоком COOKIE ECHO, передаваемым в ответ на INIT ACK. Если получатель INIT ACK не группирует блок COOKIE ECHO с блоком ERROR, последний можно передать отдельно, но не раньше получения COOKIE ACK.

Примечание. В любом случае передачи в пакете блока COOKIE ECHO этот блок должен быть первым блоком.

3.3. Определения блоков SCTP

В этом разделе описываются форматы блоков SCTP различных типов.

3.3.1. Пользовательские данные (DATA) (0)

Для блоков DATA должен использоваться показанный на рисунке формат.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Reserved|U|B|E| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier S | Stream Sequence Number n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Protocol Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / User Data (последовательность n потока S) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved — 5 битов

Отправителю следует заполнить это поле нулями, а получатель — игнорировать его.

U — 1 бит

Флаг разупорядочивания, устанавливаемый для блоков DATA, которые могут передаваться без сохранения порядка. Для таких блоков значение поля Stream Sequence Number не устанавливается, следовательно, получатель должен его игнорировать.

После сборки (если она требуется) неупорядоченные блоки DATA должны диспетчеризоваться получателем на вышележащий уровень без попыток восстановления порядка, если флаг U имеет значение 1.

Если неупорядоченное пользовательское сообщение фрагментируется, для каждого фрагмента должен устанавливаться флаг U = 1.

B — 1 бит

Флаг первого фрагмента пользовательского сообщения.

E — 1 бит

Флаг последнего фрагмента пользовательского сообщения.

В нефрагментированных пользовательских сообщениях нужно устанавливать (1) оба флага B и E. Нулевые значения обоих флагов устанавливаются в средних (не первом и не последнем) фрагментах пакета.

Таблица 1. Состояния флагов B и E.

B	E	Описание
1	0	Первый фрагмент
0	0	Один из средних фрагментов
0	1	Последний фрагмент
1	1	Нефрагментированное сообщение

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

Length — 16 битов (целое число без знака)

Это поле показывает размер блока DATA от начала поля типа и до конца пользовательских данных (без учёта байтов заполнения). Для блока DATA с одним байтом пользовательских данных Length = 17 (17 байтов).

Блок DATA с полем User Data размера L будет иметь поле Length со значением (16 + L) и L должно быть больше 0.

TSN — 32 бита (целое число без знака)

Это поле содержит порядковый номер TSN для блока DATA. Значения номеров TSN могут находиться в диапазоне от 0 до 4294967295 (2³² — 1). После достижения TSN максимального значения 4294967295 нумерация продолжается с 0.

Stream Identifier S — 16 битов (целое число без знака)

Идентификатор потока, к которому относится блок данных.

Stream Sequence Number n — 16 битов (целое число без знака)

Это значение представляет порядковый номер пользовательских данных в потоке S. Допустимые значения лежат в диапазоне от 0 до 65535.

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

Payload Protocol Identifier — 32 бита (целое число без знака)

Это поле содержит заданный приложением (или вышележащим протоколом) идентификатор протокола. SCTP получает идентификатор от вышележащего уровня и передаёт его удалённому партнёру. Значение идентификатора не используется протоколом SCTP, но может быть использовано некоторыми сетевыми объектами и приложениями на удалённой стороне для идентификации типа информации, передаваемой в блоке DATA. Это поле должно передаваться даже для фрагментированных блоков DATA (чтобы обеспечить доступность информации для агентов в сети). Отметим, что реализации SCTP не работают с этим полем, поэтому в нем не требуется использовать порядок байтов big endian. За преобразования порядка байтов в этом поле отвечает вышележащий уровень.

Нулевое значение показывает что протокол вышележащего уровня не указал идентификатор протокола для этого блока.

User Data — переменный размер

Это поле переменной длины содержит пользовательскую информацию. Реализация протокола должна обеспечивать выравнивание размеров поля по 4-байтовой границе путём добавления от 1 до 3 байтов с нулевым значением. Недопустимо учитывать байты заполнения в поле размера блока. Для отправителя недопустимо использование более 3 байтов заполнения.

3.3.2. Инициализация (INIT) (1)

Этот блок используется для создания ассоциации SCTP между парой конечных точек. Формат блока INIT показан на рисунке.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Необязательные параметры и параметры переменной длины / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Блок INIT содержит перечисленные ниже параметры. Если явно не сказано иное, каждый параметр должен включаться в блок INIT в одном экземпляре.

Фиксированные параметры	Статус
Initiate Tag	Обязательный
Advertised Receiver Window Credit	Обязательный
Number of Outbound Streams	Обязательный
Number of Inbound Streams	Обязательный
Initial TSN	Обязательный

Переменные параметры	Статус	Тип
IPv4 Address⁹	Необязательный	5
IPv6 Address¹⁰	Необязательный	6
Cookie Preservative	Необязательный	9
Reserved for ECN Capable¹¹	Необязательный	32768 (0x8000)
Host Name Address¹²	Необязательный	11
Supported Address Types²	Необязательный	12

Примечание для разработчиков. Если принят блок INIT с известными параметрами, которые не являются опциональными для блока INIT, получателю следует обработать блок INIT и возвратить его отправителю INIT ACK. Получатель блока INIT может позднее сгруппировать блок ERROR с блоком COOKIE ACK. Однако реализация может возвратить блок ABORT в ответ на блок INIT.

Поле Chunk Flags в INIT является резервным и отправителю следует устанавливать все его биты в 0, а получателю — игнорировать их. Параметры блока INIT можно обрабатывать в любом порядке.

Initiate Tag — 32 бита (целое число без знака)

Получатель INIT (отвечающая сторона) записывает значение параметра Initiate Tag. Это значение должно включаться в поле Verification Tag каждого пакета SCTP, который получатель данного блока INIT будет передавать через эту ассоциацию.

Поле Initiate Tag может содержать любые значения кроме 0. Рекомендации по выбору значений этого тега приводятся в параграфе 5.3.1.

Если в принятом блоке INIT значение Initiate Tag = 0, получатель должен трактовать это как ошибку и закрывать ассоциацию, передавая ABORT.

Advertised Receiver Window Credit (a_rwnd) — 32 бита (целое число без знака)

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

Number of Outbound Streams (OS) — 16 битов (целое число без знака)

Указывает число исходящих потоков, которые отправитель блока INIT желает открыть для данной ассоциации. Для этого параметра недопустимо использование значения 0.

Примечание. Получателю блока INIT с OS = 0 следует прервать ассоциацию.

Number of Inbound Streams (MIS) — 16 битов (целое число без знака)

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

Примечание. Здесь не используется согласование числа потоков — каждая сторона просто выбирает меньшее из двух значений — предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

Примечание. Получателю блока INIT с MIS = 0 следует прервать ассоциацию.

Initial TSN (I-TSN) — 32 бита (целое число без знака)

Начальное значение TSN, которое будет использовать отправитель (диапазон допустимых значений — от 0 до 4294967295). В это поле можно помещать значение поля Initiate Tag.

3.3.2.1. Необязательные параметры и параметры переменного размера в блоке INIT

Перечисленные ниже параметры используют формат TLV, как описано в параграфе 3.2.1. Любые комбинации параметров TLV должны размещаться в блоке после параметров фиксированного размера, описанных в предыдущем параграфе.

Параметр IPv4 Address (5)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Address — 32 бита (целое число без знака)

Содержит адрес IPv4 передающей стороны в двоичном формате.

Параметр IPv6 Address (6)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 | Length = 20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Address — 128 битов (целое число без знака)

Содержит адрес IPv6 [RFC2460] передающей стороны в двоичном формате.

Примечание. Отправителю недопустимо использовать отображённые на IPv4 адреса IPv6 [RFC4291], вместо этого следует применять параметр IPv4 Address для адреса IPv4.

Вместе с параметром Source Port Number в общем заголовке SCTP адреса IPv4 и IPv6 определяют адрес транспортного уровня, который отправитель блока INIT будет поддерживать для создаваемой ассоциации. Т. е., этот IP-адрес в течении срока существования данной ассоциации может появляться в поле отправителя дейтаграмм IP, передаваемых отправителем данного блока INIT, и может использоваться в качестве IP-адреса получателя в дейтаграммах, передаваемых получателем данного блока INIT.

В блоке INIT можно указывать более одного адреса IP, если отправитель INIT является многодомным хостом. Более того, многодомные хосты могут быть подключены к разнотипным сетям и в блоках INIT могут указываться одновременно адреса IPv4 и IPv6.

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

Отметим, что отсутствие параметров IP address в блоках INIT и INIT ACK упрощает организацию ассоциаций при работе через устройства NAT.

Параметр Cookie Preservative (9)

Отправителю блока INIT следует использовать этот параметр для того, чтобы предложить получателю INIT увеличение срока жизни State Cookie.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suggested Cookie Life-span Increment (мсек.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Suggested Cookie Life-Span Increment — 32 бита (целое число без знака)

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

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

Параметр Host Name Address (11)

Отправитель блока INIT использует этот параметр для передачи партнёру своего имени (Host Name) взамен адреса IP. Преобразование имени осуществляется на приёмной стороне. Использование этого параметра может упростить создание ассоциаций через NAT.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Host Name / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Host Name — переменный размер

Это поле содержит имя хоста с использованием синтаксиса, определённого в параграфе 2.1 RFC1123 [RFC1123]. Метод преобразования имени в адрес выходит за пределы спецификации протокола SCTP.

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

Параметр Supported Address Types (12)

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

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 12 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Type #1 | Address Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | …… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Type — 16 битов (целое число без знака)

В этом поле указывается тип адреса из соответствующего TLV (например, IPv4 = 5, IPv6 = 6, Hostname = 11).

3.3.3. Подтверждение инициализации (INIT ACK) (2)

Блок INIT ACK используется для подтверждения инициирования ассоциации SCTP.

Параметры INIT ACK форматируются подобно параметрам блока INIT. Кроме того, блоки данного типа содержат два дополнительных параметра — State Cookie и Unrecognized Parameter.

Формат блока INIT ACK показан на рисунке.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiate Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Outbound Streams | Number of Inbound Streams | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initial TSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Необязательные параметры и параметры переменной длины / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Initiate Tag — 32 бита (целое число без знака)

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

Для поля Initiate Tag недопустимо использование значения 0. Выбор значений параметра Initiate Tag рассматривается в параграфе 5.3.1.

Если в полученном блоке INIT ACK параметр Initiate Tag = 0, приёмная сторона должна трактовать это как ошибку и прерывать ассоциацию, отбрасывая TCB. Получатель может передать блок ABORT для отладки.

Advertised Receiver Window Credit (a_rwnd) — 32 бита (целое число без знака)

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

Number of Outbound Streams (OS) — 16 битов (целое число без знака)

Определяет число исходящих потоков, которые отправитель INIT ACK желает создать для данной ассоциации. Недопустимо устанавливать для этого параметра значение 0, недопустимо также устанавливать для параметра значение, превышающее значение MIS, переданное в блоке INIT.

Примечание. Получателю блока INIT ACK с параметром OS = 0 следует закрыть ассоциацию, отбросив TCB.

Number of Inbound Streams (MIS) — 16 битов (целое число без знака)

Указывает максимальное число потоков, которые отправитель INIT ACK позволяет создать удалённому партнёру в данной ассоциации. Недопустимо использование нулевого значения для этого параметра.

Примечание. Здесь нет согласования числа потоков — каждая сторона просто выбирает меньшее из двух значений — предложенного и запрашиваемого. Более подробное описание приводится в параграфе 5.1.1.

Примечание. Получателю блока INIT ACK с параметром MIS = 0 следует разорвать ассоциацию, отбрасывая TCB.

Initial TSN (I-TSN) — 32 бита (целое число без знака)

Определяет начальный номер TSN, который отправитель INIT ACK будет использовать. Корректные значения лежат в диапазоне от 0 до 4294967295. Это поле может содержать значение параметра Initiate Tag.

Фиксированные параметры	Статус
Initiate Tag	Обязательный
Advertised Receiver Window Credit	Обязательный
Number of Outbound Streams	Обязательный
Number of Inbound Streams	Обязательный
Initial TSN	Обязательный

Переменные параметры	Статус	Тип
State Cookie	Обязательный	7
IPv4 Address¹³	Необязательный	5
IPv6 Address¹	Необязательный	6
Unrecognized Parameter	Необязательный	8
Reserved for ECN Capable¹⁴	Необязательный	32768 (0x8000)
Host Name Address¹⁵	Необязательный	11

Примечание для разработчиков. Реализации должны быть готовы к получению INIT ACK достаточно большого (более 1500 байтов) размера по причине переменного размера State Cookie и списка адресов. Например, если отвечающая на INIT сторона имеет 1000 адресов IPv4, по которым она желает принимать данные, для них потребуется не менее 8000 байтов в блоке INIT ACK.

Примечание для разработчиков. Если принят блок INIT ACK с известными параметрами, которые не являются опциональными для INIT ACK, получателю следует обработать блок INIT ACK и передать в ответ COOKIE ECHO. Получатель INIT ACK может группировать блок ERROR с блоком COOKIE ECHO. Однако ограниченные реализации могут передавать блок ABORT в ответ на INIT ACK.

Вместе с параметром Source Port Number в общем заголовке SCTP параметр IP Address в INIT ACK указывает получателю INIT ACK адрес транспортного уровня, который отправитель блока INIT ACK будет поддерживать в течение срока жизни создаваемой ассоциации.

Если INIT ACK содержит хотя бы один параметр IP Address, указанные в нем адреса вместе с адресом отправителя в заголовке дейтаграммы IP, содержащей INIT ACK, могут использоваться получателем INIT ACK блока в качестве адресов получателя для этой ассоциации. Если в INIT ACK нет параметра IP Address, получатель блока INIT ACK должен использовать адрес отправителя содержащей этот блок дейтаграммы IP в качестве единственного адреса получателя для этой ассоциации.

Параметры State Cookie и Unrecognized Parameters используют формат TLV в соответствии с определением параграфа 3.2.1 и описаны ниже.

Остальные поля соответствуют одноимённым полям блока INIT.

3.3.3.1. Необязательные параметры и параметры переменной длины

Параметр State Cookie (7)

Тип

Размер

Переменный, зависит от размера Cookie.

Значение

Значение этого параметра должно включать всю необходимую информацию о состоянии и параметрах, требуемую отправителю данного блока INIT ACK для создания ассоциации, а также код аутентификации сообщения (Message Authentication Code или MAC). Определение State Cookie дано в параграфе 5.1.3.

Параметр Unrecognized Parameter

Тип

Размер

Переменный.

Значение

Этот параметр возвращается отправителю блока INIT, если этот блок включает нераспознанный параметр, значение которого показывает, что следует уведомить отправителя. Значение этого поля включает нераспознанные параметры, копируемые из блока INIT (все 3 поля Type, Length и Value).

3.3.4. Селективное подтверждение (SACK) (3)

Этот блок передаётся партнёру для подтверждения приёма блоков DATA и информирования партнёра о пропусках в порядковых номерах блоков DATA, представленных в TSN.

Блок SACK должен включать поля Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks и Number of Duplicate TSNs.

По определению поле Cumulative TSN Ack содержит значение последнего номера TSN, полученного до того, как была нарушена последовательность принятых TSN, следующее за этим значение TSN (на 1 большее) еще не получено стороной, передающей SACK. Этот параметр, следовательно, подтверждает доставку всех TSN, номера которых не превышают значение поля.

Обработка a_rwnd получателем SACK рассмотрена в параграфе 6.2.1

SACK может также содержать параметры Gap Ack Block, каждый из которых подтверждает последовательность TSN, полученных после прерывания основной последовательности номеров TSN. По определению все TSN, подтверждённые с помощью Gap Ack Block, имеют значения, превышающие Cumulative TSN Ack.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 |Chunk Flags | Chunk Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertised Receiver Window Credit (a_rwnd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Gap Ack Blocks = N | Number of Duplicate TSNs = X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #1 Start | Gap Ack Block #1 End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ … \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gap Ack Block #N Start | Gap Ack Block #N End | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / \ … \ / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Duplicate TSN X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Заполняется нулями на передающей стороне и игнорируется на приёмной.

Cumulative TSN Ack — 32 бита (целое число без знака)

Этот параметр содержит значение TSN последнего блока DATA, который был принят до прерывания последовательности номеров. Если блоков DATA еще не получено, это поле содержит партнерское значение Initial TSN — 1.

Advertised Receiver Window Credit (a_rwnd) — 32 бита (целое число без знака)

Это поле показывает обновлённое значение размера (в байтах) приёмного буфера на стороне отправителя данного блока SACK (см. параграф 6.2.1).

Number of Gap Ack Blocks — 16 битов (целое число без знака)

Показывает число параметров Gap Ack Block, включённых в SACK.

Number of Duplicate TSNs — 16 битов

Это поле показывает число дубликатов TSN, полученных конечной точкой. Каждый дубликат TSN указывается в последующем списке Gap Ack Block.

Блоки Gap Ack

Эти поля содержат параметры Gap Ack Block, число которых задано значением поля Number of Gap Ack Blocks. Все блоки DATA с номерами TSN, большими или равными Cumulative TSN Ack + Gap Ack Block Start и меньшими или равными Cumulative TSN Ack + Gap Ack Block End из каждого предполагаются принятыми без ошибок.

Gap Ack Block Start — 16 битов (целое число без знака)

Показывает стартовое смещение TSN для данного Gap Ack Block. Для расчёта реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает первый номер TSN в данном Gap Ack Block, который был принят.

Gap Ack Block End — 16 битов (целое число без знака)

Показывает финишное смещение TSN для данного Gap Ack Block. Для расчёта реального номера TSN это смещение добавляется к значению параметра Cumulative TSN Ack. Рассчитанное таким способом значение TSN указывает последний номер TSN в данном Gap Ack Block для принятого блока DATA.

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

———- | TSN=17 | ———- | | <- не получен ———- | TSN=15 | ———- | TSN=14 | ———- | | <- не получен ———- | TSN=12 | ———- | TSN=11 | ———- | TSN=10 | ———-

Тогда часть блока SACK должна включать поля, показанные на следующем рисунке (предполагается, что новое значение a_rwnd = 4660).

+———————————+ | Cumulative TSN Ack = 12 | +———————————+ | a_rwnd = 4660 | +—————-+—————+ | num of block=2 | num of dup=0 | +—————-+—————+ |block #1 strt=2 |block #1 end=3 | +—————-+—————+ |block #2 strt=5 |block #2 end=5 | +—————-+—————+

Duplicate TSN — 32 бита (целое число без знака)

Показывает количество случаев, когда номер TSN был принят как дубликат, с момента передачи последнего блока SACK. При получении каждого дубликата TSN (до момента передачи SACK) этот дубликат добавляется в список. Счётчик дубликатов сбрасывается в 0 после отправки каждого блока SACK.

Например, если получатель принял TSN 19 трижды, номер 19 будет указан два раза в блоке SACK. После отправки SACK, если TSN 19 будет принят снова, он будет указан в списке нового блока SACK.

3.3.5. Запрос Heartbeat (HEARTBEAT) (4)

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

Поле Heartbeat Information имеет переменный размер и содержит структуру данных, понятную только отправителю.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 4 | Chunk Flags | Heartbeat Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Heartbeat Length — 16 битов (целое число без знака)

Задаёт размер блока в байтах с учётом заголовка и поля Heartbeat Information.

Heartbeat Information — переменный размер

Параметр переменного размера, который использует формат, описанный в параграфе 3.2.1.

Параметр	Статус	Тип
Heartbeat Info	Обязательный	1

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Info Type=1 | HB Info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Sender-Specific Heartbeat Info / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

В поле Sender-Specific Heartbeat Info обычно следует включать информацию о текущем времени отправителя на момент передачи данного блока HEARTBEAT и транспортный адрес получателя этого блока (см. параграф 8.3). Эта информация просто «отражается» получателем в его блоке HEARTBEAT ACK (см. параграф 3.3.6). Отметим также, что сообщения HEARTBEAT служат для проверки доступности и корректности пути (см. параграф 5.4). При использовании блока HEARTBEAT для проверки пути он должен включать 64-битовое случайное значение nonce.

3.3.6. Подтверждение Heartbeat (HEARTBEAT ACK) (5)

Конечной точке следует передавать такой блок в ответ на запрос HEARTBEAT (см. параграф 8.3). Блок HEARTBEAT ACK всегда передаётся по тому адресу IP, который был указан в заголовке дейтаграммы, содержавшей HEARTBEAT.

Поле параметра содержит «непрозрачную» структуру данных с переменным размером.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 5 | Chunk Flags | Heartbeat Ack Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Heartbeat Information TLV (переменный размер) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Heartbeat Length — 16 битов (целое число без знака)

Задаёт размер блока в байтах с учётом заголовка и поля Heartbeat Information.

Heartbeat Information — переменный размер

Это поле должно содержать параметр Heartbeat Information из запроса Heartbeat, на который отвечает данный блок Heartbeat Acknowledgement.

Параметр	Статус	Тип
Heartbeat Info	Обязательный	1

3.3.7. Разрыв ассоциации (ABORT) (6)

Блок ABORT передаётся партнёру для разрыва ассоциации. Блок ABORT может содержать параметры Error Cause, информирующие партнёра о причинах разрыва ассоциации. Недопустимо группировать блоки DATA с блоком ABORT. Блоки управления (кроме INIT, INIT ACK и SHUTDOWN COMPLETE) могут группироваться с ABORT, но эти блоки должны размещаться перед блоком ABORT в пакете SCTP, поскольку в противном случае получатель проигнорирует их.

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

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 6 |Reserved |T| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Причины ошибок (Error Cause) / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Reserved — 7 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

T — 1 бит

Бит T сбрасывается в 0, если отправитель заполнил поле Verification Tag, ожидаемое партнёром. Если в Verification Tag используется «отражённое» значение, должно устанавливаться T = 1. Отражение означает, что переданное значение Verification Tag совпадает с принятым.

Примечание. Для проверки этого типа блоков применяются специальные правила, описанные в параграфе 8.5.1.

Length — 16 битов (целое число без знака)

Указывает размер блока в байтах с учётом заголовка и всех полей Error Cause.

Определения причин ошибки (Error Cause) приведены в параграфе 3.3.10.

3.3.8. Завершение ассоциации (SHUTDOWN) (7)

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

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 7 | Chunk Flags | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative TSN Ack | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length — 16 битов (целое число без знака)

Показывает размер параметра и имеет значение 8.

Cumulative TSN Ack — 32 бита (целое число без знака)

Этот параметр содержит номер последнего TSN, принятого без пропусков в нумерации.

Примечание. Поскольку блок SHUTDOWN не содержит параметров Gap Ack Block, он не может служить подтверждением TSN, принятых с нарушением порядка. В блоках SACK отсутствие Gap Ack Block, которые были указаны в предыдущих сообщениях, показывает, что получатель данных отказался от соответствующих блоков DATA. Поскольку SHUTDOWN не содержит Gap Ack Block, получателю блока SHUTDOWN не следует интерпретировать отсутствие Gap Ack Block как отказ (см. параграф 6.2).

3.3.9. Подтверждение закрытия ассоциации (SHUTDOWN ACK) (8)

Этот блок должен использоваться для подтверждения приёма блока SHUTDOWN при завершении процесса закрытия, описанного в параграфе 9.2.

Блок SHUTDOWN ACK не содержит параметров.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.10. Ошибка при работе (ERROR) (9)

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 9 | Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / Одно или несколько полей Error Cause / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Конечные точки передают блоки этого типа для уведомления партнёра о некоторых типах ошибок. Блок содержит один или несколько кодов ошибок. Приём сообщения об ошибке не обязывает партнёра разрывать ассоциацию, однако такие блоки могут передаваться вместе с блоком ABORT в качестве отчёта о причине разрыва. Параметры блока описаны ниже.

Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length — 16 битов (целое число без знака)

Указывает размер блока в байтах с учётом заголовка и всех полей Error Cause.

Причины ошибок указываются как параметры переменного размера в соответствии с параграфом 3.2.1.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cause-Specific Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cause Code — 16 битов (целое число без знака)

Указывает код причины, которая вызвала передачу сообщения.

Код	Описание	Код	Описание
1	Некорректный идентификатор потока	8	Нераспознанные параметры
2	Отсутствие обязательного параметра	9	Отсутствие пользовательских данных
3	Ошибка Stale Cookie	10	Получение Cookie в процессе закрытия
4	Нехватка ресурсов	11	Перезапуск ассоциации с новыми адресами
5	Не удалось преобразовать адрес	12	Инициированный пользователем разрыв
6	Нераспознанный тип блока	13	Протокольное нарушение
7	Некорректный обязательный параметр

Cause Length — 16 битов (целое число без знака)

Указывает размер параметра в байтах с учётом полей Cause Code, Cause Length и Cause-Specific Information

Cause-Specific Information — переменный размер

В этом поле указываются сведения об ошибке.

Причины ошибок SCTP рассматриваются в параграфах 3.3.10.1 — 3.3.10.10. Рекомендации по определению новых типов ошибок для IETF даны в параграфе 14.3.

3.3.10.1. Неприемлемый идентификатор потока (1)

Причина ошибки

Invalid Stream Identifier

Показывает, что конечная точка получила блок DATA, переданный в несуществующий поток.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=1 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream Identifier | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Stream Identifier — 16 битов (целое число без знака)

Это поле содержит значение Stream Identifier из блока DATA, вызвавшего ошибку.

Reserved — 16 битов

Зарезервированное поле. Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.10.2. Отсутствует обязательный параметр (2)

Причина ошибки

Missing Mandatory Parameter

Говорит об отсутствии одного или нескольких обязательных параметров TLV в принятом блоке INIT или INIT ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=2 | Cause Length=8+N*2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of missing params=N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #1 | Missing Param Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Missing Param Type #N-1 | Missing Param Type #N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Number of Missing params — 32 бита (целое число без знака)

Это значение указывает число отсутствующих параметров, перечисленных в поле Cause-specific Information.

Missing Param Type — 16 битов (целое число без знака)

Каждое поле содержит пропущенный обязательный параметр.

3.3.10.3. Ошибка Stale Cookie (3)

Причина ошибки

Stale Cookie Error

Говорит о получении корректного значения State Cookie с истекшим сроком.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=3 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Measure of Staleness (мксек.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Measure of Staleness — 32 бита (целое число без знака)

Разница между текущим временем и временем окончания срока действия State Cookie (в микросекундах).

Отправитель этого сообщения может указать время, прошедшее после завершения срока действия State Cookie, отличным от нуля значением поля Measure of Staleness. Если отправитель не хочет передавать эти сведения, ему следует установить нулевое значение в поле Measure of Staleness.

3.3.10.4. Нехватка ресурсов (4)

Причина ошибки

Out of Resource

Указывает нехватку ресурсов у отправителя и передаётся обычно в комбинации с блоком ABORT или в нем.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=4 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.5. Не удалось преобразовать адрес (5)

Причина ошибки

Unresolvable Address

Говорит о том, что отправителю не удалось преобразовать указанный адресный параметр (например, отправитель не поддерживает этот тип адресов) и передаётся обычно в комбинации с блоком ABORT или просто в нем.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=5 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unresolvable Address / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unresolvable Address — переменный размер

Поле Unresolvable Address содержит полное значение параметра TLV, задающего адрес (или параметра Host Name) или имя хоста, которые не удалось преобразовать.

3.3.10.6. Не распознан тип блока (6)

Причина ошибки

Unrecognized Chunk Type

Эта информация передаётся отправителю блока, если получатель не смог определить тип блока и два старших бита поля Chunk Type имеют значение 01 или 11.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=6 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Chunk / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Unrecognized Chunk — переменный размер

Поле Unrecognized Chunk содержит нераспознанный блок из пакета SCTP, включая поля Chunk Type, Chunk Flags и Chunk Length.

3.3.10.7. Неприемлемый обязательный параметр (7)

Причина ошибки

Invalid Mandatory Parameter

Это сообщение передаётся отправителю блока INIT или INIT ACK, когда один или несколько обязательных параметров имеют некорректные значения.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=7 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.8. Нераспознанные параметры (8)

Причина ошибки

Unrecognized Parameters

Это сообщение возвращается отправителю блока INIT ACK, если получателю не удаётся распознать один или несколько необязательных параметров TLV в блоке INIT ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=8 | Cause Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Unrecognized Parameters / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Unrecognized Parameters — переменный размер

Поле Unrecognized Parameters содержит нераспознанные параметры, скопированные из блока INIT ACK полностью в форме TLV. Это сообщение обычно передаётся в блоках ERROR, объединённых с блоком COOKIE ECHO при отклике на INIT ACK, когда отправитель блока COOKIE ECHO желает сообщить о нераспознанных параметрах.

3.3.10.9. Нет пользовательских данных (9)

Причина ошибки

No User Data

Это сообщение передаётся отправителю блока DATA, если принятый блок не содержит пользовательских данных.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=9 | Cause Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / TSN value / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TSN value — 32 бита (целое число без знака)

Значение поля TSN из блока DATA, принятого без пользовательских данных.

Это сообщение обычно передаётся в блоке ABORT (см. параграф 6.2).

3.3.10.10. Получение Cookie во время процедуры закрытия (10)

Причина ошибки

Cookie Received While Shutting Down

Это сообщение говорит о приёме COOKIE ECHO в то время, когда конечная точка находилась в состоянии SHUTDOWN-ACK-SENT. Обычно этот код возвращается в блоке ERROR, сгруппированном с повторным блоком SHUTDOWN ACK.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=10 | Cause Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.10.11. Перезапуск ассоциации с новыми адресами (11)

Причина ошибки

Restart of an association with new addresses

Был получен блок INIT в существующей ассоциации и этот блок добавляет адреса, которые раньше не были частью данной ассоциации. Новые адреса указываются в коде ошибки. Этот сообщение обычно передаётся как часть блока ABORT, отвергающего INIT (см. параграф 5.2).

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=11 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / New Address TLVs / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Примечание. Каждый элемент New Address TLV является точной копией связанного с новым адресом TLV из блока INIT, включая Parameter Type и Parameter Length.

3.3.10.12. Разрыв по инициативе пользователя (12)

Причина ошибки

Эта причина ошибки может включаться в блоки ABORT, передаваемые по запросам вышележащего уровня. Этот уровень может указать значение Upper Layer Abort Reason, которое прозрачно передаётся протоколом SCTP и может быть доставлено протоколу прикладного уровня у партнёра.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3.10.13. Протокольное нарушение (13)

Причина ошибки

Эта причина ошибки может включаться в блоки ABORT передаваемые в результате обнаружения конечной точкой SCTP нарушение протокола партнёром., которое не может быть описано причинами, указанными в параграфах 3.3.10.1 — 3.3.10.12. Реализация может предоставить дополнительную информацию о нарушении протокола.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.3.11. Cookie Echo (COOKIE ECHO) (10)

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

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 10 |Chunk Flags | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Cookie / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

Length — 16 битов (целое число без знака)

Указывает размер блока в байтах, включая 4 байта заголовка блока и размер Cookie.

Cookie — переменный размер

Это поле должно содержать точную копию параметра State Cookie, полученного в предыдущем блоке INIT ACK.

Реализациям протокола следует стремиться к уменьшению размера cookie в целях обеспечения взаимодействия.

Примечание. Блок Cookie Echo не включает параметр State Cookie и данные из поля Parameter Value в State Cookie становятся Chunk Value в Cookie Echo. Это позволяет реализациям поменять лишь два первых байта параметра State Cookie, чтобы сделать из него блок COOKIE ECHO.

3.3.12. Подтверждение Cookie (COOKIE ACK) (11)

Этот тип блоков используется только при создании ассоциации и служит подтверждением приёма блока COOKIE ECHO. Данный блок должен предшествовать любому блоку DATA или SACK в данной ассоциации, но может группироваться с одним или несколькими блоками DATA или блоком SACK в одном пакете SCTP.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 11 |Chunk Flags | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags — 8 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

3.3.13. Закрытие ассоциации завершено (SHUTDOWN COMPLETE) (14)

Этот тип блоков должен использоваться для подтверждения приёма блока SHUTDOWN ACK при завершении ассоциации (см. параграф 9.2).

Блок SHUTDOWN COMPLETE не содержит параметров.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 14 |Reserved |T| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk Flags — 8 битов

Reserved — 7 битов

Устанавливается в 0 на передающей стороне и игнорируется на приёмной.

T — 1 бит

Примечание. Для проверки этого типа применяются специальные правила, описанные в параграфе 8.5.1.

4. Диаграмма состояний ассоциации SCTP

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

- вызовы пользовательских примитивов SCTP (например, [ASSOCIATE], [SHUTDOWN], [ABORT]);
- приём управляющих блоков INIT, COOKIE ECHO, ABORT, SHUTDOWN и т. п.;
- —— ——— (из любого состояния) / \ / rcv ABORT [ABORT] rcv INIT | | | ———- или ———- ————— | v v удалить TCB snd ABORT генерация Cookie \ +———+ удалить TCB и INIT ACK —| CLOSED | +———+ / \ [ASSOCIATE] / \ ————— | | создать TCB | | snd INIT | | запустить таймер init rcv корректн. | | COOKIE ECHO | v (1) —————- | +————+ создать TCB | | COOKIE-WAIT| (2) snd COOKIE ACK | +————+ | | | | rcv INIT ACK | | —————— | | snd COOKIE ECHO | | остановить таймер init | | запустить таймер cookie | v | +—————+ | | COOKIE-ECHOED| (3) | +—————+ | | | | rcv COOKIE ACK | | —————— | | остановить таймер cookie v v +—————+ | ESTABLISHED | +—————+

(продолжение рисунка на следующей странице)

тайм-ауты.

(только из состояния ESTABLISHED) | | /———+———\ [SHUTDOWN] / \ ——————-| | проверить оставшиеся | | блоки DATA | | v | +———+ | |SHUTDOWN-| | rcv SHUTDOWN/проверить |PENDING | | оставшиеся блоки DATA +———+ | ———————- | | нет оставшихся блоков| | ———————| | snd SHUTDOWN | | запустить таймер | | shutdown v v +———+ +————+ (4) |SHUTDOWN-| | SHUTDOWN- | (5,6) |SENT | | RECEIVED | +———+ +————+ | \ | (A) rcv SHUTDOWN ACK | \ | ———————-| \ | ост. таймер shutdown | \rcv:SHUTDOWN | send SHUTDOWN COMPLETE| \ (B) | удалить TCB | \ | | \ | нет оставшихся блоков | \ | —————— | \ | send SHUTDOWN ACK (B)rcv SHUTDOWN | \ | запустить таймер ———————-| \ | shutdown send SHUTDOWN ACK | \ | зап. таймер shutdown | \ | перейти в SHUTDOWN- | \ | ACK-SENT | | | | v | | +————+ | | SHUTDOWN- | (7) | | ACK-SENT | | +———-+- | | (C)rcv SHUTDOWN COMPLETE | |—————— | | запустить таймер shutdown | | удалить TCB | | | | (D)rcv SHUTDOWN ACK | |————— | | останов. таймер shutdown | | send SHUTDOWN COMPLETE | | удалить TCB | | \ +———+ / \—>| CLOSED |<—/ +———+

Рисунок 3. Диаграмма состояний протокола SCTP (продолжение).

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

Примечание. Имена блоков указаны заглавными буквами, а в именах параметров только первая буква является заглавной (например, блок COOKIE ECHO и параметр State Cookie). Если смену состояния могут вызвать несколько событий или сообщений, они помечаются (A), (B) и т. д.

Примечания.

Если параметр State Cookie в принятом блоке COOKIE ECHO не приемлем (например, не прошла проверка целостности), получатель должен отбросить пакет без уведомления. Если получен State Cookie с истекшим сроком (см. параграф 5.1.5), получатель должен оправить в ответ блок ERROR. В обоих случаях получатель остаётся в состоянии CLOSED.
Если истекло время по таймеру T1-init, конечная точка должна повторить передачу INIT и заново запустить таймер T1-init без смены своего состояния. Эти действия должны повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
Если истекло время по таймеру T1-cookie, конечная точка должна повторить передачу COOKIE ECHO и заново запустить таймер T1-cookie без смены состояния. Эта процедура должна повторяться до Max.Init.Retransmits раз, после чего конечная точка должна прервать процесс инициирования ассоциации и возвратить сообщение об ошибке пользователю SCTP.
В состоянии SHUTDOWN-SENT конечная точка должна подтверждать все принятые блоки DATA без задержек.
В состоянии SHUTDOWN-RECEIVED для конечной точки недопустимо принимать любые новые запросы на передачу от пользователя SCTP.
В состоянии SHUTDOWN-RECEIVED конечная точка должна передать (возможно повторно) данные и выйти из этого состояния после того, как будут переданы все данные из очереди.
В состоянии SHUTDOWN-ACK-SENT для конечной точки недопустимо принимать от пользователя SCTP любые новые запросы на передачу.

Состояние CLOSED на схеме используется для того, чтобы показать, что ассоциация еще не создана (т .е., не существует).

5. Создание ассоциации

До того, как сможет произойти передача первых данных от одной конечной точки SCTP («A») к другой («Z»), эти две точки должны выполнить полностью процесс создания ассоциации.

Пользователю SCTP в конечной точке следует применять примитив ASSOCIATE для создания ассоциации с другой конечной точкой SCTP.

Примечание для разработчиков. С точки зрения пользователя SCTP ассоциация может быть создана неявно без обращения к примитиву ASSOCIATE (см. параграф 10.1 B) просто путём передачи первых пользовательских данных удалённому адресату. Инициирующий ассоциацию узел SCTP будет задавать принятые по умолчанию значения для всех обязательных и дополнительных параметров INIT/INIT ACK.

После создания ассоциации организуются двухсторонние потоки данных для передачи информации в обоих направлениях (см. параграф 5.1.1).

5.1. Нормальное создание ассоциации

Процесс инициализации описан ниже в предположении, что конечная точка A пытается создать ассоциацию, а точка Z принимает вызов.

A сначала передаёт блок INIT точке Z. В блока INIT точка A должна указать свой Verification Tag (Tag_A) в поле Initiate Tag. Для Tag_A следует использовать случайное число из диапазона от 1 до 4294967295 (см. рекомендации по выбору значения тега в параграфе 5.3.1). После передачи блока INIT A запускает таймер T1-init и переходит в состояние COOKIE-WAIT.
Z следует сразу же ответить на запрос блоком INIT ACK. IP-адрес получателя в блоке INIT ACK должен совпадать с адресом отправителя блока INIT, для которого передаётся INIT ACK. Кроме заполнения других полей отклика точка Z должна скопировать в поле Verification Tag значение Tag_A, а также указать своё значение Verification Tag (Tag_Z) в поле Initiate Tag.
Кроме того, точка «Z» должна сгенерировать и передать с INIT ACK значение State Cookie (см. параграф 5.1.3).
При получении блока INIT ACK от Z точке A следует остановить таймер T1-init и выйти из состояния COOKIE-WAIT. Далее A следует передать значение State Cookie из принятого блока INIT ACK в ответном блоке COOKIE ECHO, запустить таймер T1-cookie и перейти в состояние COOKIE-ECHOED.
При получении блока COOKIE ECHO точка Z будет передавать блок COOKIE ACK после создания TCB и перехода в состояние ESTABLISHED. Блок COOKIE ACK может объединяться с любыми ожидающими передачи блоками DATA и/или SACK, но блок COOKIE ACK должен быть первым в пакете.
Примечание для разработчиков. Реализация протокола может передавать уведомление Communication Up пользователю SCTP при получении корректного блока COOKIE ECHO.
Приняв блок COOKIE ACK, точка A будет переходить из состояния COOKIE-ECHOED в состояние ESTABLISHED, останавливая таймер T1-cookie. Она может также уведомить ULP об успешном создании ассоциации с помощью Communication Up (см. раздел 10).
Примечание. Блок COOKIE ECHO может группироваться с любыми ожидающими передачи блоками DATA, но эти блоки должны размещаться в пакете после COOKIE ECHO. До получения ответного блока COOKIE ACK недопустима передача каких-быто ни было пакетов удалённому партнёру.
Примечание. Сразу после передачи INIT ACK с параметром State Cookie для Z недопустимо выделять какие-либо ресурсы или сохранять какие-либо состояния для новой ассоциации, поскольку это сделает точку Z уязвимой для атак на ресурсы системы.

Блоки INIT и INIT ACK недопустимо группировать с другими блоками. Такой блок должен быть единственным в содержащем его пакете SCTP.

Конечная точка должна передавать блок INIT ACK по адресу IP, с которого был передан блок INIT.

Примечание. Для таймеров T1-init и T1-cookie должны выполняться правила, описанные в параграфе 6.3.

Если конечная точка, получившая блок INIT, INIT ACK или COOKIE ECHO, решает не создавать новую ассоциацию по причине отсутствия обязательных параметров в блоке INIT или INIT ACK, неприемлемых значений параметров или нехватки локальных ресурсов, ей следует передать в ответ блок ABORT. Этой точке также следует указать причину отказа (тип отсутствующих обязательных параметров и т. п.), включив соответствующий параметр в блок ABORT. Поле Verification Tag в общем заголовке исходящего пакета SCTP, содержащего блок ABORT, должно содержать значение Initiate Tag, полученное от партнёра.

Отметим, что блок COOKIE ECHO без проверки целостности не рассматривается, как неприемлемый, и требует специальной обработки, описанной в параграфе 5.1.5.

После получения первого блока DATA в ассоциации конечная точка должна без промедления передать блок SACK для подтверждения приёма блока DATA. Последующие подтверждения передаются в соответствии с рекомендациями параграфа 6.2.

При создании TCB каждая точка должна установить для внутреннего параметра Cumulative TSN Ack Point значение переданного Initial TSN — 1.

Примечание для разработчиков. В качестве ключей поиска TCB для данного экземпляра SCTP обычно используются IP-адреса и номер порта SCTP.

5.1.1. Обработка параметров потока

В блоках INIT и INIT ACK отправитель должен указывать число исходящих потоков (OS), которые он желает поддерживать для данной ассоциации, а также максимальное число входящих потоков (MIS), которые он будет принимать от удалённого партнёра.

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

После того, как ассоциация инициализирована, приемлемые значения идентификаторов исходящих потоков для неё могут находиться в диапазоне [0 — min(local OS, remote MIS)-1].

5.1.2. Обработка адресов

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

Если в принятом блоке INIT или INIT ACK нет адресных параметров, следует взять адрес отправителя из заголовка пакета IP, в котором был доставлен блок, и сохранить этот адрес вместе с номером порта SCTP, использованным отправителем пакета, как единственный транспортный адрес партнёра.
Если в полученном блоке INIT или INIT ACK присутствует параметр Host Name, имя следует преобразовать в адрес (список адресов) IP и сохранить транспортные адреса партнёра, как комбинации полученных при преобразовании адресов IP и номера порта отправителя SCTP.Пока получатель блока INIT выполняет преобразование имени хоста в адрес, он подвержен потенциальному риску атак на SCTP. Если получатель INIT преобразует имя хоста в адрес при получении блока и используемый механизм преобразования может вносить достаточно большую задержку (например, запросы DNS), получатель может быть открыт для атаки на ресурсы в течение периода ожидания результатов преобразования имени до создания State Cookie и освобождения локальных ресурсов.Получателю INIT ACK всегда следует незамедлительно предпринять попытку преобразования имени после получения блока.Если не удаётся преобразовать имя, конечная точка должна незамедлительно передать своему партнёру блок ABORT с причиной ошибки Unresolvable Address. Блок ABORT следует отправлять по адресу IP из заголовка пакета, в котором был получен последний пакет от партнёра.
Если в принятом блоке INIT или INIT ACK присутствуют только адреса IPv4/IPv6, получателю следует выделить и записать все транспортные адреса из полученного блока и адреса отправителя в заголовке пакета IP, содержащего блок INIT или INIT ACK. Транспортные адреса представляют собой комбинацию номера порта SCTP (из общего заголовка) и адресов IP, переданных в блоке INIT или INIT ACK и заголовке пакета IP, доставившего блок. Получателю следует использовать только эти транспортные адреса для передачи последующих пакетов удалённому партнёру.
Блок INIT или INIT ACK должен трактоваться, как относящийся к организованной ранее (или организуемой сейчас) ассоциации, если использование любого из содержащихся в нем корректных адресных параметров уже зафиксировано в существующих TCB.
Для получателя INIT или INIT ACK недопустима передача пользовательских данных до преобразования имени хоста в адрес.
Следовательно, в тех случаях, когда преобразование имён может происходить достаточно долго, получатель INIT должен отложить процедуру преобразования до того, как будет получен блок COOKIE ECHO от партнёра. В таких случаях получателю INIT следует создать State Cookie с использованием полученного значения Host Name (вместо транспортного адреса получателя) и передать блок INIT ACK по адресу отправителя из заголовка IP в пакете, содержащем принятый блок INIT.
Конечная точка должна игнорировать все дополнительные параметры с IP-адресами, если они присутствуют в блоке INIT или INIT ACK.

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

После выделения транспортного адреса из блока INIT или INIT ACK с использованием описанных выше правил конечной точке следует выбрать один из таких адресов для организации первичного пути.

Примечание. Блок INIT ACK должен передаваться по адресу отправителя блока INIT.

Отправитель блока INIT может включить в этот блок параметр Supported Address Types, показывающий поддерживаемые типы адресов. При наличии такого параметра получатель блока INIT должен использовать один из указанных этим параметром типов адресов при передаче отклика на INIT или разорвать ассоциацию с помощью блока ABORT с причиной ошибки Unresolvable Address, если конечная точка не желает или не может использовать ни один из типов адресов, указанных партнёром.

Примечание для разработчиков. В тех случаях, когда получателю блока INIT ACK не удаётся выполнить преобразование адреса вследствие отсутствия поддержки указанного типа, попытка создания ассоциации может быть прервана, после чего предпринимается попытка повторной организации с использованием параметра Supported Address Types в новом блоке INIT для индикации предпочтительных типов адресов.

Примечание для разработчиков. Если конечная точка SCTP, поддерживающая только один из типов адресов (IPv4 или IPv6), получает адреса IPv4 и IPv6 в блоке INIT или INIT ACK от своего партнёра, она должна использовать все указанные партнёром. адреса, которые относятся к поддерживаемому типу. Не следует в таких случаях передавать какие-либо сообщения об ошибке.

Примечание для разработчиков. Если конечная точка SCTP указывает в параметре Supported Address Types только один из типов IPv4 и IPv6, но использует для передачи пакета с блоком INIT другой тип или перечисляет адрес другого типа в блоке INIT, адреса не указанного в параметре Supported Address Types типа получателю блока INIT также следует считать поддерживаемыми. Не следует в таких случаях передавать какие-либо сообщения об ошибке.

5.1.3. Генерация State Cookie

При передаче блока INIT ACK в ответ на INIT отправитель INIT ACK создаёт значение State Cookie и передаёт его в одноимённом параметре блока INIT ACK. В параметр State Cookie отправителю следует включить MAC (см., например, [RFC2104]), временную метку генерации State Cookie и время жизни параметра State Cookie, а также другую информацию, требуемую для создания ассоциации.

При генерации State Cookie следует выполнить перечисленные ниже операции.

Создать для ассоциации TCB с использованием информации из полученного блока INIT и передаваемого блока INIT ACK.
В TCB установить время создания по текущему времени суток, а для срока жизни использовать протокольный параметр Valid.Cookie.Life (см. раздел 15).
Из TCB выделить и сохранить минимальный набор информации, требуемой для повторного создания TCB, и создать MAC с использованием этого набора и секретного ключа (см. пример генерации MAC в [RFC2104]).
Создать State Cookie, объединив минимальный набор информации и полученное значение MAC.

После передачи блока INIT ACK с параметром State Cookie отправителю следует удалить TCB и все прочие локальные ресурсы, связанные с новой ассоциацией в целях предотвращения атак на ресурсы.

Метод хеширования, используемый для генерации MAC является приватным для получателя блока INIT. Использование MAC является обязательным с целью предотвращения атак на службы. В качестве секретного ключа следует использовать случайное значение (см. рекомендации [RFC4086]), которое следует менять достаточно часто. Для идентификации ключа, который будет использоваться для проверки MAC, может служить временная метка момента создания State Cookie.

Для обеспечения взаимодействия реализациям протокола следует минимизировать размер cookie.

5.1.4. Обработка State Cookie

Когда конечная точка (в состоянии COOKIE WAIT) получает блок INIT ACK с параметром State Cookie, она должна незамедлительно передать своему партнёру блок COOKIE ECHO с полученным значением State Cookie. Отправитель может также добавить в пакет ожидающие обработки блоки DATA после блока COOKIE ECHO.

Конечной точке следует также запустить таймер T1-cookie после передачи блока COOKIE ECHO. По истечении заданного для таймера периода конечной точке следует повторить передачу блока COOKIE ECHO и заново включить таймер T1-cookie. Эту процедуру следует повторять до получения блока COOKIE ACK или исчерпания числа попыток Max.Init.Retransmits (см. раздел 15). Если заданное число попыток не привело к успеху, партнёр помечается как недоступный (и ассоциация переводится в положение CLOSED).

5.1.5. Аутентификация State Cookie

Когда конечная точка получает блок COOKIE ECHO от другой конечной точки, с которой нет действующей ассоциации, ей следует выполнить перечисленные ниже операции.

Рассчитать MAC с использованием данных TCB, полученных в State Cookie, и секретного ключа (отметим, что для выбора секретного ключа может использоваться временная метка из State Cookie). Расчёт MAC можно выполнять в соответствии с рекомендациями [RFC2104].
Проверить State Cookie, сравнивая рассчитанное значение MAC с полученным в State Cookie. При наличии расхождений пакет SCTP, включающий COOKIE ECHO и любые блоки DATA, следует отбросить без уведомления отправителя.
Сравнить номера портов и Verification Tag в блоке COOKIE ECHO с реальными номерами портов и полем Verification Tag в общем заголовке SCTP принятого пакета. При наличии расхождений пакет должен быть отброшен без уведомления отправителя.
Сравнить временную метку в State Cookie с текущим временем локальной системы. Если разница превышает заданный срок существования State Cookie, пакет, содержащий COOKIE ECHO и любые блоки DATA, следует отбросить. Конечная точка в таком случае должна передать партнёру блок ERROR с причиной ошибки Stale Cookie.
Если значение State Cookie приемлемо, создать ассоциацию с отправителем COOKIE ECHO, создать TCB с использованием данных из блока COOKIE ECHO и перевести конечную точку в состояние ESTABLISHED.
Передать блок COOKIE ACK удалённому партнёру для подтверждения приёма COOKIE ECHO. Блок COOKIE ACK может группироваться с пользовательскими блоками DATA или блоком SACK, однако блок COOKIE ACK должен размещаться в пакете SCTP первым.
Незамедлительно подтвердить получение любых блоков DATA, сгруппированных с COOKIE ECHO, путём передачи блока SACK (подтверждения последовательных блоков DATA передаются с использованием правил, рассмотренных в параграфе 6.2). Как было отмечено в п. 6), блок SACK, группируемый с COOKIE ACK, должен размещаться в пакете SCTP после блока COOKIE ACK.

При получении блока COOKIE ECHO от конечной точки, с которой получатель имеет работающую ассоциацию, выполняются операции, рассмотренные в параграфе 5.2.

5.1.6. Пример нормального создания ассоциации

В показанном на рисунке примере точка A инициирует создание ассоциации и передаёт пользовательское сообщение точке Z, а Z, в свою очередь, передаёт точке A два пользовательских сообщения (предполагается отсутствие группировки и фрагментирования).

Точка A Точка Z {приложение создает ассоциацию с Z} (создание TCB) INIT [I-Tag=Tag_A и др. инфор.] ———\ (запуск таймера T1-init) \ (Переход в сост. COOKIE-WAIT) \—> (создание Cookie_Z) /— INIT ACK [Veri Tag=Tag_A, / I-Tag=Tag_Z, (Выкл. таймера T1-init)<———/ Cookie_Z и др. информ.] COOKIE ECHO [Cookie_Z] ——\ (Запуск таймера T1-cookie) \ (Переход в сост. COOKIE-ECHOED)\—> (создание TCB и переход в сост. ESTABLISHED) /—- COOKIE-ACK / (Выкл. тайм. T1-cookie,<——/ Переход в сост. ESTABLISHED) {прил. начинает перед. данных; strm 0} DATA [TSN=init TSN_A Strm=0,Seq=1 & user data]—\ (Запуск таймера T3-rtx) \ \-> /—— SACK [TSN Ack=init (Выкл. таймера T3-rtx)<——/ TSN_A,Block=0] … {прилож. шлет 2 сообщ.; strm 0} /—- DATA / [TSN=init TSN_Z <—/ Strm=0, Seq=1 & user data 1] SACK [TSN Ack=init TSN_Z, /—- DATA Block=0] ———\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=2 & user data 2] <——/\ \ \——>

Рисунок 4. Пример создания ассоциации.

Если закончилось время T1-init в точке A после передачи блока INIT или COOKIE ECHO, повторяется передача блока INIT или COOKIE ECHO с тем же значением Initiate Tag (т. е., Tag_A) или State Cookie и таймер запускается снова. Эта процедура повторяется до Max.Init.Retransmits раз после чего точка A принимает решение о недоступности Z и сообщает вышележащему уровню об ошибке (ассоциация переводится в состояние CLOSED).

При повторной передаче INIT конечная точка должна следовать правилам, описанным в параграфе 6.3, для определения подходящего значения таймера.

5.2. Обработка дубликатов и неожиданных установочных блоков

В течение срока жизни ассоциации (в одном из возможных состояний) конечная точка может получить от партнёра один из установочных блоков (INIT, INIT ACK, COOKIE ECHO, COOKIE ACK). Получателю следует трактовать такие блоки, как дубликаты и обрабатывать их в соответствии с приведёнными здесь рекомендациями.

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

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

Критическая ошибка на удалённой стороне с перезапуском партнёра и передачей нового блока INIT для восстановления ассоциации.
Обе стороны предприняли одновременные попытки создания ассоциации.
Блок был получен в старом пакете, который использовался для создания этой ассоциации или ассоциации, которой уже нет.
Блок является фальшивым (атака).
Партнёр не получил блок COOKIE ACK и повторно передаёт COOKIE ECHO.

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

5.2.1. Блок INIT получен в состоянии COOKIE-WAIT или COOKIE-ECHOED (п. B)

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

При получении блока INIT в состоянии COOKIE-WAIT конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag). Конечная точка должна передавать INIT ACK по тому же адресу, который использовался этой точкой при отправке исходного блока INIT.

При получении блока INIT в состоянии COOKIE-ECHOED конечная точка должна ответить блоком INIT ACK, используя те же параметры, которые она передавала в исходном блоке INIT (включая параметр Initiate Tag), чтобы в создаваемую ассоциацию не добавлялись новые адреса. Если блок INIT показывает добавление к ассоциации нового адреса, весь блок INIT должен быть отброшен и в существующую ассоциацию не следует вносить никаких изменений. В ответ следует передать блок ABORT, который может включать информацию об ошибке Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, которые были добавлены при перезапуске ассоциации.

При отклике INIT ACK в любом из состояний (COOKIE-WAIT или COOKIE-ECHOED) исходные параметры комбинируются с параметрами из полученного недавно блока INIT. Конечной точке следует также генерировать параметр State Cookie для блока INIT ACK, используя параметры, переданные ею в блоке INIT.

После этого для конечной точки недопустимо изменение своего состояния и удаление соответствующего TCB, таймеру T1-init следует продолжать отсчёт. Обычная процедура обработки State Cookies при наличии TCB позволит избавиться от дубликатов INIT в одной ассоциации.

Конечная точка, находящаяся в состоянии COOKIE-ECHOED при получении блока INIT должна заполнить поля Tie-Tags информацией из параметра Tag (своей или партнёра, как описано в параграфе 5.2.2).

5.2.2. Неожиданный блок INIT в состоянии, отличном от CLOSED, COOKIE-ECHOED, COOKIE-WAIT и SHUTDOWN-ACK-SENT

Если явно не указано иное, при получении блока INIT в таких случаях конечная точка должна генерировать блок INIT ACK с параметром State Cookie. Перед отправкой отклика конечная точка должна проверить, добавляет ли неожиданный блок INIT новые адреса для ассоциации. При наличии новых адресов конечная точка должна отвечать блоком ABORT, копируя Initiate Tag из неожиданного блока INIT в поле Verification Tag исходящего пакета с блоком ABORT. В блоке ABORT в качестве причины ошибки можно указать Restart of an association with new addresses (перезапуск ассоциации с новыми адресами). В информацию об ошибке следует включать список адресов, добавленных к заново ассоциации. Если новых адресов нет, в ответ на неожиданный блок INIT блоком INIT ACK конечная точка должна копировать своё текущие значения Tie-Tags в резервное пространство State Cookie и TCB этой ассоциации. Эти места внутри cookie по-прежнему обозначаются Peer’s-Tie-Tag и Local-Tie-Tag. Копии внутри TCB ассоциации будем обозначать Local Tag и Peer’s Tag. Исходящий пакет SCTP, содержащий этот блок INIT ACK, должен включать значение Verification Tag, совпадающее с Initiate Tag в неожиданном блоке INIT. Блок INIT ACK должен включать новое значение Initiate Tag (случайное, см. параграф 5.3.1). Остальные параметры для конечной точки (например, число исходящих потоков) следует скопировать из существующих параметров ассоциации в блок INIT ACK и cookie.

После передачи INIT ACK или ABORT конечной точке не следует предпринимать каких-либо действий, т. е., существующую ассоциацию, включая текущее состояние и соответствующее значение TCB изменять недопустимо.

Примечание. Значения Tie-Tags заполняются отличными от 0 значениями только в том случае, когда существует TCB и ассоциация не находится в состоянии COOKIE-WAIT или SHUTDOWN-ACK-SENT. При обычном создании ассоциации (конечная точка находится в состоянии CLOSED) параметр Tie-Tags должен быть установлен в 0 (это показывает отсутствие предыдущего TCB).

5.2.3. Неожиданный блок INIT ACK

При получении блока INIT ACK конечной точкой, находящейся в отличном от COOKIE-WAIT состоянии, этой точке следует отбросить блок INIT ACK. Неожиданные блоки INIT ACK обычно связаны с обработкой старых или дублированных блоков INIT.

5.2.4. Обработка COOKIE ECHO при наличии TCB

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

Рассчитать MAC в соответствии с рекомендациями п. 1 в параграфе 5.1.5,
Проверить State Cookie как описано в п. 2 параграфа 5.1.5 (случай C или D в начале параграфа 5.2).
Сравнить временную метку State Cookie с текущим временем. Если срок жизни State Cookie истёк и значение Verification Tag, содержащееся в State Cookie, не соответствует Verification Tag для текущей ассоциации, пакет вместе с входящими в него блоками COOKIE ECHO и DATA следует отбросить. Конечная точка должна также передать блок ERROR с причиной ошибки Stale Cookie своему партнёру (случай C или D в параграфе 5.2).
Если параметры Verification Tag в State Cookie и текущей ассоциации совпадают, следует считать параметр State Cookie приемлемым (случай E в параграфе 5.2) даже по истечении срока жизни.
При корректном значении State Cookie распаковать TCB во временный TCB.
Выполнить подходящее действие из таблицы 2.

Таблица 2. Обработка COOKIE ECHO при наличии TCB.

Local Tag	Peer’s Tag	Local-Tie-Tag	Peer’s-Tie-Tag	Действие
X	X	M	M	(A)
M	X	A	A	(B)
M	0	A	A	(B)
X	M	0	0	(C)
M	M	A	A	(D)

X — тег не соответствует существующему TCB

M — тег соответствует существующему TCB

0 — нет Tie-Tag в Cookie (неизвестно).

A — Все случаи (M, X, 0).

Для всех ситуаций, не рассмотренных в таблице 2, cookie следует отбрасывать без уведомления.

Примечание. Для всех ситуаций, не рассмотренных в таблице 2, cookie следует отбрасывать без уведомления.

Действия

Этот случай может быть связан с рестартом на удалённой стороне. Когда конечная точка распознает возможный “рестарт”, существующая сессия трактуется, как случай получения блока ABORT, за которым сразу же следовал новый блок COOKIE ECHO, с перечисленными ниже исключениями:
- любые блоки DATA могут быть сохранены (в зависимости от реализации протокола);
- протоколу вышележащего уровня следует передать уведомление RESTART взамен COMMUNICATION LOST.
Все параметры контроля насыщения (например, cwnd, ssthresh), связанные с этим партнёром., должны быть сброшены в исходное состояние (см. параграф 6.2.1).Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и определяет рестарт партнёра (п. A), для этой точки недопустимо создание новой ассоциации и следует передать своему партнёру блок SHUTDOWN ACK и ERROR с причиной ошибки Cookie Received while Shutting Down.
В этой ситуации обе стороны могут пытаться организовать ассоциацию одновременно, но удалённая точка передаст свой блок INIT уже после отклика на INIT от локальной точки. В результате новое значение Verification Tag не будет включать информацию из тега, переданного ранее той же конечной точкой. Конечной точке следует сохранить состояние ESTABLISHED или перейти в него, но она должна обновить значение Verification Tag из параметра State Cookie, остановить запущенные таймеры init и cookie и передать блок COOKIE ACK.
В этом случае информация cookie локальной точки поступает с опозданием. До этого локальная точка передала блок INIT и приняла INIT-ACK, а также передала блок COOKIE ECHO с тегом партнёра, а новый тег принадлежит локальной точке. Данные cookie следует отбросить без уведомления. Конечной точке не следует менять своё состояние и отключать запущенные таймеры.
Когда теги локальной и удалённой точки совпадают, конечной точке следует перейти в состояние ESTABLISHED, если она находится в состоянии COOKIE-ECHOED. Следует также остановить таймеры init и cookie и передать блок COOKIE ACK.
После этого конечной точке следует перейти в состояние ESTABLISHED.

Примечание. Verification Tag партнёра — это тег, полученный в поле Initiate Tag блока INIT или INIT ACK.

5.2.4.1. Пример перезапуска ассоциации

Точка A Точка Z <—————- Ассоциация организована ———————-> Tag=Tag_A Tag=Tag_Z <—————————————————————> {A выполняет рестарт после сбоя} {приложение организует ассоциацию с Z} (создание TCB) INIT [I-Tag=Tag_A’ и др. инф.] ———\ (Запуск таймера T1-init) \ (Переход в сост. COOKIE-WAIT) \—> (поиск существующего TCB создание врем. TCB и Cookie_Z с Tie-Tags для предыдущ. асс.) /— INIT ACK [Veri Tag=Tag_A’, / I-Tag=Tag_Z’, (Выкл. таймера T1-init)<——/ Cookie_Z[TieTags= Tag_A,Tag_Z и др. инф.] (удаление врем. TCB, возврат исходного) COOKIE ECHO [Veri=Tag_Z’, Cookie_Z Tie=Tag_A, Tag_Z]———-\ (Запуск таймера T1-init) \ (Перех. В сост. COOKIE-ECHOED) \—> (Найдена существ. ассоциация, Tie-Tags соотв. старым тегам, Теги не соотв. (случаи X X M M), анонсиров. рестарта ULP и сброс ассоциации). /—- COOKIE-ACK / (Выкл. таймера T1-init,<——/ переход в состояние ESTABLISHED) {прилож. начинает перед. польз. данные; strm 0} DATA [TSN=initial TSN_A Strm=0,Seq=1 & user data]—\ (Запуск таймера T3-init) \ \-> /—— SACK [TSN Ack=init TSN_A,Block=0] (Выкл. таймера T3-rtx)<——/

Рисунок 5. Пример перезапуска

В приведённом на рисунке 5 примере точка A инициирует ассоциацию после рестарта. Точка Z пока не знает о рестарте (т. е., Heartbeat еще не удалось обнаружить недоступность точки A). Предполагается отсутствие группировки и фрагментирования.

5.2.5. Обработка дубликатов COOKIE-ACK

Во всех состояниях, кроме COOKIE-ECHOED, конечной точке следует отбрасывать без уведомления блоки COOKIE ACK.

5.2.6. Обработка ошибок Stale COOKIE

Приём блока ERROR с причиной Stale Cookie может быть обусловлен одной из перечисленных ниже причин.

Создание ассоциации завершилось неудачей до того, как была выполнена обработка State Cookie.
После создания ассоциации обработана старая переменная State Cookie.
Получена старая переменная State Cookie от кого-то, с кем получатель не намерен создавать ассоциацию, но блок ABORT был утерян.

При обработке блока ERROR с причиной ошибки Stale Cookie конечной точке следует сначала проверить завершился ли процесс создания ассоциации (состояние отличается от COOKIE-ECHOED). Если ассоциация не находится в состоянии COOKIE-ECHOED, блок ERROR следует отбросить без уведомления.

Если ассоциация находится в состоянии COOKIE-ECHOED, конечная точка может выбрать один из перечисленных вариантов.

Передать новый блок INIT удалённой конечной точке для генерации нового значения State Cookie и повторить процедуру создания ассоциации.
Отбросить TCB и сообщить вышележащему уровню о невозможности создания ассоциации.
Передать новый блок INIT удалённой конечной точке, добавив в него параметр Cookie Preservative, запрашивающий продление срока жизни State Cookie. При расчёте дополнительного времени реализации протокола следует использовать данные RTT, полученные во время предыдущего обмена блоками COOKIE ECHO/ERROR. К полученному значению RTT следует добавить не более 1 секунды, поскольку увеличение срока жизни State Cookie подвергает конечную точку риску replay-атак.

5.3. Другие вопросы инициализации

5.3.1. Выбор значений тегов

Значения Initiate Tag следует выбирать из диапазона 1 — 2³²-1. Важно, чтобы значение Initiate Tag было случайным — это поможет в защите от атак man in the middle¹⁶ и sequence number¹⁷. Для создания случайных значений Initiate Tag можно использовать методы, описанные в [RFC4086]. Аккуратный подбор Initiate Tag позволяет также избавиться от появления дубликатов из предыдущих ассоциаций, которые могут быть ошибочно направлены в текущую ассоциацию.

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

5.4. Проверка пути

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

Любой адрес, переданный отправителю блока INIT его вышележащим уровнем, автоматически считается подтверждённым.
Для получателя COOKIE ECHO единственным подтверждённым. адресом является тот, по которому был передан блок INIT-ACK.
Все остальные адреса (кроме перечисленных в п. 1 и 2) считаются неподтвержденными и должны проверяться.

Для проверки адреса конечная точка передаёт блоки HEARTBEAT, включающее 64-битовое случайное значение nonce и индикатор пути (для идентификации адреса, по которому передаётся HEARTBEAT) в параметре HEARTBEAT.

При получении HEARTBEAT ACK проверяется значение nonce в параметре HEARTBEAT на предмет совпадения с адресом, переданным в параметре HEARTBEAT. При совпадении адрес, по которому был передан исходный блок HEARTBEAT считается подтверждённым. и может применяться для обычной передачи данных.

Эти процедуры проверки запускаются при переходе ассоциации в состояние ESTABLISHED и завершаются после проверки всех путей.

В каждый период RTO может быть отправлен пробный пакет для активного неподтвержденного пути в попытке перевести этот путь в состояние подтверждённого. Если в процессе проверки путь становится неактивным, скорость отправки проб снижается до обычной скорости отправки HEARTBEAT. По завершении отсчёта таймера RTO значения счётчика ошибок для протестированного, но не подтверждённого пути увеличивается на 1 и рассматривается вопрос отказа на этом пути (см. параграф 8.2). Однако при проверке неподтвержденных адресов значение общего счётчика ошибок в ассоциации не инкрементируется.

Число HEARTBEAT, передаваемых в течение RTO, следует ограничивать значением параметра HB.Max.Burst. Распределение HEARTBEAT по адресам партнёра при проверке путей реализация определяет самостоятельно.

При подтверждении пути вышележащему уровняю может передаваться уведомление.

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

Блоки HEARTBEAT, включающие nonce, можно передавать по неподтвержденным адресам.
Блоки HEARTBEAT ACK можно передавать по неподтвержденным адресам.
Блоки COOKIE ACK можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce. Реализациям, не поддерживающим группировку блоков, недопустимо передавать COOKIE ACK по неподтвержденным адресам..
Блоки COOKIE ECHO можно передавать по неподтвержденным адресам, но они должны группироваться с блоками HEARTBEAT, включающими nonce, и недопустимо использование пакетов с размером больше MTU на этом пути. Если реализация не поддерживает группировку блоков или после группировки COOKIE ECHO с HEARTBEAT (включающим nonce) размер пакета превысит MTU для пути, недопустимо передавать COOKIE ECHO по неподтвержденным адресам.

6. Передача пользовательских данных

Данные должны передаваться только в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Единственным исключением из этого правила является возможность включения блоков DATA в пакеты, содержащие блок COOKIE ECHO, в состоянии COOKIE-WAIT.

Блоки DATA должны приниматься только в соответствии с приведёнными ниже правилами в состояниях ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT. Блок DATA, полученный в состоянии CLOSED, следует обрабатывать в соответствии со специальными правилами, описанными в параграфе 8.4. Блоки DATA, полученные во всех прочих состояниях, следует отбрасывать.

Подтверждения SACK должны обрабатываться в состояниях ESTABLISHED, SHUTDOWN-PENDING и SHUTDOWN-RECEIVED. Входящий блок SACK может быть обработан ассоциацией в состоянии COOKIE-ECHOED. Подтверждения SACK в состоянии CLOSED следует обрабатывать в соответствии со специальными правилами, рассмотренными в параграфе 8.4. Во всех прочих состояниях блоки SACK следует отбрасывать.

Получатель SCTP должен быть способен принимать пакеты SCTP размером как минимум 1500 байтов. Это означает, что для конечной точки SCTP недопустимо указывать значение меньше 1500 в стартовом параметре a_rwnd, передаваемом в INIT или INIT ACK.

Для эффективной передачи трафика протокол SCTP поддерживает механизм группировки мелких пользовательских сообщений и фрагментации больших сообщений. На рисунке 6 показана схема обмена пользовательскими сообщениями в SCTP.

В этом параграфе термин «отправитель» (data sender) будет указывать конечную точку, которая передаёт блок DATA, а термин «получатель» (data receiver) — конечную точку, принимающую блок DATA. Получатель подтверждает приём данных блоком SACK.

+—————————-+ | Пользовательское сообщение | +—————————-+ Пользователь SCTP ^ | ==================|==|=================================== | v (1) +——————+ +———————-+ | Блоки SCTP DATA | |Блоки управления SCTP | +——————+ +———————-+ ^ | ^ | | v (2) | v (2) +—————————+ | Пакеты SCTP | +—————————+ SCTP ^ | =============================|==|======================== | v Пакетный сервис без организации соединений (например, IP)

Примечания.

При преобразовании пользовательских сообщений в блоки DATA конечная точка будет фрагментировать сообщения, размер которых превышает значение path MTU, в несколько блоков DATA. Получатель будет собирать принятые фрагменты из блоков DATA до передачи сообщения пользователю (см. параграф 6.9).
Множество блоков DATA и блоков управления может группироваться отправителем в один пакет SCTP, пока размер результирующего пакета не будет превышать значение path MTU. Получатель будет разбирать групповой пакет, выделяя из него отдельные блоки. Блоки управления должны размещаться в пакете перед блоками DATA.

Рисунок 6 Пример передачи пользовательских данных

Механизмы фрагментации и группировки, описанные в параграфах 6.9 и 6.10, являются необязательными для отправителя, но они должны быть реализованы на приёмной стороне (т. е., конечная точка должна принимать и обрабатывать фрагментированные и сгруппированные данные).

6.1. Передача блоков DATA

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

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

В любой момент для отправителя недопустимо передавать новые данные по любому транспортному адресу получателя, если значение rwnd, полученное от партнёра, говорит об отсутствии свободного пространства в буфере (т. е., rwnd = 0, см. параграф 6.2.1). Однако, независимо от значения rwnd (включая 0), отправитель может всегда держать один блок DATA в состоянии на пути к получателю, если позволяет cwnd (см. правило B). Это позволяет отправителю проверять изменение rwnd, о котором отправитель не знает по причине утери подтверждения SACK в процессе доставки от получателя.Если отправитель продолжает принимать новые пакеты от получателя во время проверки нулевого окна, отсутствие подтверждения проб не следует использовать для инкрементирования счётчика ошибок для ассоциации или каких-либо транспортных адресов партнёра. Это связано с тем, что получатель может держать своё окно закрытым в течение неопределённого времени. Поведение получателя, анонсирующего нулевое окно, описано в параграфе 6.2. Отправителю следует передавать первую пробу нулевого окна по истечении 1 RTO с момента обнаружения закрытия окна получателем, а также следует экспоненциально увеличивать интервал между проверками. Отметим также, что значение cwnd следует подстраивать в соответствии с параграфом 7.2.1. Проверки нулевого окна не оказывают влияния на расчёт cwnd.Однако, независимо от значения rwnd (включая 0), отправитель может всегда держать один блок DATA в состоянии на пути к получателю, если позволяет cwnd (см. правило B). Это позволяет отправителю проверять изменение rwnd, о котором отправитель не знает по причине утери подтверждения SACK в процессе доставки от получателя.
В любой момент времени для отправителя недопустимо передавать информацию по данному транспортному адресу, если имеется cwnd или более неподтвержденных байтов данных для этого адреса.
Когда приходит время отправителю передавать новые блоки DATA, перед их отправкой он должен сначала передать неподтвержденные блоки DATA, которые помечены для повтора (не более cwnd).
Когда приходит время отправителю передавать новые блоки DATA, следует использовать протокольный параметр Max.Burst для ограничения числа передаваемых пакетов. Ограничение может быть реализовано путём изменения cwndif((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize + Max.Burst*MTUили просто может быть ограничено число пакетов, выдаваемых модулем отправки.
Отправитель может передать столько новых блоков DATA, сколько позволяют правила A и B.
Отправитель должен также поддерживать алгоритм отправки новых блоков DATA, позволяющий предотвратить синдром SWS¹⁸, как описано в [RFC0813]. Алгоритм может быть похож на описанный в параграфе 4.2.3.4 [RFC1122].
Когда анонсированное получателем окно имеет нулевой размер, это называется «проверкой нулевого окна (zero window probe). Отметим, что такие пробы следует передавать только в тех случаях, когда все блоки DATA имеют кумулятивное подтверждение и нет находящихся «на лету» блоков DATA. Реализации должны поддерживать проверку нулевого окна.

Множество блоков DATA, подготовленных для передачи, можно сгруппировать в один пакет. Более того, передаваемые повторно блоки DATA можно группировать с новыми блоками DATA, пока размер результирующего пакета не превышает path MTU. Протокол вышележащего уровня (ULP) может запросить передачу сообщений без группировки, но это означает лишь отключение задержек, которые реализация SCTP может использовать для повышения эффективности группировки. Группировка может происходить и в этом случае (например, при перегрузках или повторе передачи).

До того, как конечная точка передаст блок DATA, отправителю следует создать блок SACK для всех неподтвержденных данных и сгруппировать его с передаваемыми блоками DATA, пока размер результирующего пакета не превышает значение MTU (см. параграф 6.2).

Примечание для разработчиков. При заполнении окна (передача запрещена правилом A и/или B), отправитель может по-прежнему принимать запросы на передачу от вышележащего протокола, но он должен остановить передачу блоков DATA, пока некоторые или все остающиеся блоки DATA не будут подтверждены и правила A и B не будут выполнены.

Когда передача или повтор передачи происходит по любому из адресов и таймер T3-rtx для этого адреса не включён, отправитель должен запустить этот таймер. Если таймер для данного адреса уже включён, отправитель должен сбросить и запустить его заново, если по этому адресу происходит повтор передачи передачи остающихся в очереди (т. е., с меньшим значением TSN) блоков данных. В остальных случаях перезапуск таймера недопустим.

При старте или перезапуске таймера T3-rtx его значение должно быть установлено в соответствии с правилами, приведёнными в параграфах 6.3.2 и 6.3.3.

Примечание. Отправителю не следует использовать значения TSN, которые превышают стартовое значение TSN для текущего окна более, чем на 2³¹ — 1.

6.2. Подтверждение приёма блоков DATA

Конечная точка SCTP всегда должна подтверждать получение каждого корректного блока DATA, когда этот блок приходит в окне приёма.

Когда получатель анонсирует размер окна 0, он должен отбрасывать все новые входящие блоки DATA со значением TSN, превышающим максимальное полученное до этого значение TSN. Если в новом входящем блоке DATA значение TSN меньше максимального из принятых до этого блоков, получателю следует отбросить наибольшее значение TSN, хранящееся для упорядочения, и воспринять новый блок DATA. В любом случае при отбрасывании блока DATA получатель должен незамедлительно вернуть блок SACK с текущим окном приёма, показывающим лишь блоки DATA, полученные и воспринятые к этому моменту. Отброшенные блоки DATA недопустимо включать в SACK, поскольку они не были восприняты. Получатель должен также иметь алгоритм анонсирования своего приёмного окна для предотвращения синдрома SWS, как описано в [RFC0813]. Это алгоритм может быть похож на описанный в параграфе 4.2.3.3 [RFC1122].

При передаче подтверждений следует придерживаться рекомендаций по использованию алгоритма отложенных подтверждений, описанного в параграфе 4.2 [RFC2581]. В частности, подтверждения следует генерировать по крайней мере по факту доставки каждого второго пакета (не обязательно с блоком DATA), а также следует в течение 200 мсек генерировать подтверждение для любого еще не подтверждённого блока DATA. В некоторых случаях для отправителя SCTP разумно быть более консервативным, нежели предлагает описанный в данном документе алгоритм подтверждения. Однако для отправителей SCTP недопустимо быть более агрессивными, нежели предлагает описанный ниже алгоритм.

Для отправителя SCTP недопустимо генерировать более 1 блока SACK для каждого входящего пакета, который не является обновлением предложенного размера окна при запросе приёмной стороной новых данных.

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

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

Подтверждения должны передаваться в блоках SACK до тех пор, пока со стороны ULP не поступит запроса на завершение ассоциации (в последнем случае подтверждение может быть передано в блоке SHUTDOWN). Блок SACK может использоваться для подтверждения доставки нескольких блоков DATA. Формат блоков SACK описан в параграфе 3.3.4. В частности, конечная точка SCTP должна заполнить поле Cumulative TSN Ack, чтобы показать последний номер TSN для полученных без пропусков корректных блоков DATA. Все принятые блоки DATA с номерами TSN, превышающими значение Cumulative TSN Ack, указываются в полях Gap Ack Block. Конечная точка SCTP должна включать столько Gap Ack Block, сколько можно поместить в один блок SACK с учётом текущего значения MTU для пути.

Примечание. Блок SHUTDOWN не включает поля Gap Ack Block. Поэтому конечной точке следует использовать SACK, а не SHUTDOWN для подтверждения доставки блоков DATA, принятых с нарушением порядка.

При получении пакета с дубликатом блока(ов) DATA, в котором нет нового блока(ов) DATA, конечная точка должна незамедлительно передать SACK. Если пакет с дубликатом(ами) DATA содержит также новый блоки(и) DATA, конечная точка может передать SACK незамедлительно. Обычно получение дублирующих блоков DATA связано с потерей исходного блока SACK и тайм-аутом RTO у партнёра. Номера TSN для дубликатов следует указывать в блоке SACK как дубликаты.

При получении блока SACK конечная точка может использовать информацию Duplicate TSN для обнаружения потери блоков SACK. Другие варианты использования этой информации требуют дальнейшего изучения.

Получатель данных отвечает за поддержку буферов приёма. Получателю следует своевременно уведомлять отправителя об изменении своих возможностей приёма данных. Способы управления приёмными буферами в реализации протокола зависят от множества факторов (например, от операционной системы, системы управления памятью, размера ОЗУ и т. п.). Однако описанная в параграфе 6.2.1 стратегия передачи основана на предположении, что получатель использует описанный ниже алгоритм.

При создании ассоциации конечная точка сообщает партнёру размер своего приёмного буфера для данной ассоциации в блоке INIT или INIT ACK. Переданное значение размера буфера устанавливается для переменной a_rwnd.
При получении и буферизации блоков DATA значение a_rwnd уменьшается на размер принятых и помещённых в буфер данных. Это по сути закрывает окно rwnd у отравителя и ограничивает количество данных, которые тот может передать.
Когда блоки DATA передаются ULP и буфер освобождается, значение a_rwnd увеличивается на размер данных, которые отправлены протоколу вышележащего уровня. Таким образом окно rwnd открывается снова, позволяя отправителю передавать новые данные. Получателю не следует увеличивать значение a_rwnd, пока данные не будут освобождены из буфера. Например, если получатель удерживает фрагментированные блоки DATA в очереди на сборку, ему не следует увеличивать значение a_rwnd.
При передаче блока SACK получателю данных следует поместить текущее значение переменной a_rwnd в поле a_rwnd передаваемого блока. Получателю данных следует принимать во внимание, что отправитель не будет повторять передачу блоков DATA, указанных в Cumulative TSN Ack (т. е., удалит их из очереди на повтор).

Возможны ситуации, когда получателю потребуется отбросить блоки DATA, которые были приняты, но еще не освобождены из приёмного буфера (т. е., не переданы ULP). Такие блоки DATA могут быть подтверждены в Gap Ack Block. Например, получатель может удерживать принятые данные в буфере для сборки фрагментов пользовательского сообщения, когда обнаружится нехватка буферного пространства. Получатель в этом случае может отбросить блоки DATA из буфера, несмотря на то, что они уже подтверждены в Gap Ack Block. Если получатель отбрасывает блоки DATA, их недопустимо включать в Gap Ack Block последующих блоков SACK, пока отброшенные блоки не будут получены снова в повторных пакетах. В дополнение к сказанному конечной точке следует принимать во внимание отброшенные блоки при расчёте значения a_rwnd.

Конечной точке не следует отзывать SACK и отбрасывать данные. Описанной процедурой следует пользоваться только в экстремальных ситуациях (например, при нехватке памяти). Получателю данных следует принимать во внимание, что отбрасывание данных, которые были подтверждены в Gap Ack Block, может привести к неоптимальной работе отправителя данных и снижению производительности.

Приведённый на рисунке 7 пример иллюстрирует использование отложенных подтверждений.

Точка A Точка Z {Приложение передает 3 сообщения; strm 0} DATA [TSN=7,Strm=0,Seq=3] ————> (отложенное подтверждение) (Запуск таймера T3-rtx) DATA [TSN=8,Strm=0,Seq=4] ————> (передача подтверждения) /——- SACK [TSN Ack=8,block=0] (Остан. таймера T3-rtx)<——/ DATA [TSN=9,Strm=0,Seq=5] ————> (отложенное подтверждение) (Запуск таймера T3-rtx) … {Прил. перед. 1 сообщ.; strm 1} (групп. SACK с DATA) /—— SACK [TSN Ack=9,block=0] \ / DATA [TSN=6,Strm=1,Seq=2] (Остан. таймера T3-rtx)<——/ (Запуск таймера T3-rtx) (отложенное подтверждение) (передача подтверждения) SACK [TSN Ack=6,block=0] ————-> (Остан. таймера T3-rtx)

Рисунок 7. Пример подтверждения с задержкой

Если конечная точка получает блок DATA без пользовательских данных (Length = 16), она должна передать блок ABORT с причиной ошибки No User Data.

Конечной точке не следует передавать блоков DATA без пользовательских данных.

6.2.1. Обработка подтверждений SACK

Каждый блок SACK, полученный конечной точкой, содержит значение a_rwnd. Это значение представляет объем свободного буферного пространства на приёмной стороне в момент передачи блока SACK, которое осталось от приёмного буфера, указанного в блоке INIT/INIT ACK. Используя значения a_rwnd, Cumulative TSN Ack и Gap Ack Block, отправитель может создать своё представление о буферном пространстве партнёра.

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

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

Конечной точке следует использовать приведённые ниже правила расчёта rwnd на основе значений a_rwnd, Cumulative TSN Ack и Gap Ack Block, полученных в блоке SACK.

При создании ассоциации конечная точка устанавливает rwnd = a_rwnd¹⁹ (указано партнёром. в блоке INIT или INIT ACK).
Всякий раз при передаче (или повторе) блока DATA партнёру конечная точка вычитает размер переданной информации из значения rwnd для этого партнёра.
Всякий раз, когда блок DATA помечается для повтора (по таймеру T3-rtx (параграф 6.3.3) или fast retransmit (параграф 7.2.4)), размер этого блока добавляется к значению rwnd.
Всякий раз при получении SACK конечная точка выполняет следующие операции.
Примечание. Если реализация поддерживает таймеры для каждого блока DATA, для повторной передачи помечаются только блоки DATA, для которых истекло заданное таймером время.

1. Если Cumulative TSN Ack < Cumulative TSN Ack Point, блок SACK отбрасывается. Поскольку Cumulative TSN Ack возрастает монотонно, блок SACK, в котором Cumulative TSN Ack < Cumulative TSN Ack Point говорит о нарушении порядка доставки SACK.
2. Для переменной rwnd устанавливается значение a_rwnd за вычетом числа байтов, остающихся не подтверждёнными, после обработки Cumulative TSN Ack и Gap Ack Block.
3. Если SACK является отсутствующим TSN, который был ранее подтверждён с использованием Gap Ack Block (например, получатель отказался от данных), соответствующий блок DATA помечается как доступный для повтора. Блок помечается, как отсутствующий, для быстрого повтора (параграф 7.2.4) и при отсутствии работающего таймера для адреса получателя, по которому блок DATA был передан изначально, для этого адреса запускается таймер T3-rtx.
4. Если Cumulative TSN Ack совпадает со значением для точки выхода из процедуры Fast Recovery (параграф 7.2.4) или превышает его, процедура Fast Recovery завершается.

6.3. Управление таймером повтора передачи

Конечная точка SCTP использует таймер повтора передачи T3-rtx для обеспечения доставки данных при отсутствии обратной связи с партнёром. Время этого таймера называют тайм-аутом повтора или RTO²⁰.

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

Расчёт и обслуживание RTO для протокола SCTP осуществляются так же, как это делается для таймера повтора передачи в TCP. Для расчёта текущего значения RTO конечная точка поддерживает две переменных состояния для каждого адреса получателя — SRTT²¹ и RTTVAR²².

6.3.1. Расчёт RTO

Ниже приводятся правила расчёта значений SRTT, RTTVAR и RTO.

До того, как будет измерено значение RTT для пакета, переданного по данному транспортному адресу, для RTO следует использовать параметр протокола RTO.Initial.
После того, как будет определено значение RTT (обозначим его R), следует установитьSRTT <- R RTTVAR <- R/2 RTO <- SRTT + 4 * RTTVAR
Когда будет получено для RTT новое значение R’, следует установитьRTTVAR <- (1 — RTO.Beta) * RTTVAR + RTO.Beta * |SRTT — R’| SRTT <- (1 — RTO.Alpha) * SRTT + RTO.Alpha * R’Примечание. Значение SRTT используемое для обновления RTTVAR представляет собой SRTT до обновления.
Когда данные находятся в процессе доставки и выполняется правило C5, для каждого кругового обхода должно быть выполнено новое измерение RTT. Новое измерение RTT следует проводить не более одного раза на круговой обход для данного транспортного адреса. Такое ограничение обусловлено 2 причинами. Во-первых, более частые измерения не имеют смысла, поскольку не дают заметных преимуществ [ALLMAN99], во-вторых, при частых измерениях значения RTO.Alpha и RTO.Beta в правиле C3 следует подбирать так, чтобы значения SRTT и RTTVAR рассчитывались примерно с такой же частотой (в терминах количества круговых обходов, при котором новые значения вступают в силу), как при одном измерении на круговой обход и с использованием RTO.Alpha и RTO.Beta в правиле C3. Однако точная процедура расчётов требует дополнительных исследований.
Алгоритм Karn — измерение RTT недопустимо выполнять с использованием передаваемых повторно пакетов, поскольку нет возможности различить, к какой из переданных копий относится полученный отклик.
Если после расчёта RTO получается значение меньше RTO.Min, устанавливается RTO = RTO.Min. Причина этого заключается в том, что использование слишком малых значений RTO будет приводить к возникновению неоправданных тайм-аутов [ALLMAN99].
Максимальное значение RTO составляет по крайней мере RTO.max секунд.
Примечание для разработчиков. Измерение RTT с использованием блока с TSN r следует выполнять лишь в тех случаях, когда нет блоков с номерами TSN меньшими или равными r, повторно переданными с момента первой передачи r.
После расчёта следует обновить RTO <- SRTT + 4 * RTTVAR.

К дискретности временных параметров (G) при измерении RTT и различных переменных состояния применяется единственное правило.

G1) Если при расчёте RTTVAR получено нулевое значение, следует установить RTTVAR <- G.

Опыт показывает [ALLMAN99], что предпочтительной является дискретность не более 100 мсек.

6.3.2. Правила для таймера повторной передачи

Ниже приведены правила управления таймером повтора передачи.

1. Каждый раз при передаче (включая повторы) блока DATA по любому из адресов следует запустить для этого адреса таймер T3-rtx (если он не работает) на время RTO. Используемое для таймера значение RTO удваивается после каждого тайм-аута предыдущего таймера T3-rtx, связанного с этим адресом, как указано ниже в правиле E2.
2. Точка A Точка Z {приложение начинает передачу} Data [TSN=7,Strm=0,Seq=3] ————> (задержка ack) (Пуск таймера T3-rtx) {Прил. перед. 1 сообщ.; strm 1} (группировка ACK и DATA) DATA [TSN=8,Strm=0,Seq=4] —-\ /— SACK [TSN Ack=7,Block=0] \ / DATA [TSN=6,Strm=1,Seq=2] \ / (Запуск таймера T3-rtx) \ / \ (Перезап. таймера T3-rtx)<——/ \—> (задержка ACK) (задержка ACK) {передача ACK} SACK [TSN Ack=6,Block=0] —————> (Остан. таймера T3-rtx) .. (передача ACK) (Остан. таймера T3-rtx) <————— SACK [TSN Ack=8,Block=0]

Рисунок 8. Пример правил для таймера

После подтверждения всех неподтвержденных для этого адреса данных таймер T3-rtx для данного адреса сбрасывается.
Всякий раз при получении SACK, подтверждающего блок DATA с неподтвержденным TSN для данного адреса, таймер T3-rtx для этого адреса запускается заново с текущим значением RTO (если для этого адреса есть неподтвержденные данные).
При получении SACK для отсутствующего TSN, который ранее был подтверждён с помощью Gap Ack Block, включается таймер T3-rtx для адреса получателя, по которому блок DATA был передан изначально (если этот таймер еще не запущен).

На рисунке 8 показан пример использования правил для таймера (предполагается, что получатель использует отложенные подтверждения).

6.3.3. Обработка завершения отсчёта T3-rtx

При завершении отсчёта T3-rtx для адреса получателя выполняются перечисленные ниже действия.

Для этого адреса изменяется значение ssthresh в соответствии с правилами, приведёнными в параграфе 7.2.3, и устанавливается cwnd <- MTU.
Для этого адреса устанавливается RTO <- RTO * 2. Максимальное значение для таймера рассматривается в приведённом выше правиле C7 (RTO.max). Это значение может служить верхней границей для операций удваивания.
Определяется количество более ранних (т. е., с меньшими номерами TSN) неподтвержденных блоков DATA для этого адреса, которые можно поместить в один пакет с учётом ограничений MTU на пути доставки по этому транспортному адресу (для разных путей могут быть разные значения MTU — см. параграф 6.4). Обозначим найденное число блоков K. Эти K блоков DATA группируются в один пакет и передаются удалённому партнёру по его транспортному адресу.
Запускается таймер повтора T3-rtx для адреса, по которому был передан повторный пакет, если приведённое выше правило R1 указывает это. Используемое для таймера значение RTO следует брать для одного из адресов, по которым передаётся повтор — в случае многодомного получателя значения могут различаться для разных адресов получателя (см. параграф 6.4 ).

После повтора передачи, когда будет проведено новое измерение RTT (это может случиться только в том случае, когда новые данные были переданы и подтверждены в соответствии с правилом C5, или измерение сделано на основе HEARTBEAT (см. параграф 8.3)), выполняется расчёт по правилу C3 (включая вычисление RTO), который может привести к «коллапсу» RTO (со снижением значения до начального уровня) после того, как это значение было удвоено (правило E2).

Примечание. Любые блоки DATA, переданные по адресу, для которого истекло время T3-rtx, но не был заполнен MTU (правило E3), следует пометить для повторной передачи и передать, как только позволит cwnd (обычно при получении SACK).

Заключительное правило управления таймером повтора передачи связано с переключением на другой адрес получателя (см. параграф 6.4.1).

Всякий раз, когда конечная точка переключается с текущего транспортного адреса получателя на другой транспортный адрес, текущий таймер повтора передачи продолжает работать. Как только конечная точка передаст пакет, содержащий блок(и) DATA, по новому транспортному адресу, запускается таймер для этого адреса с использованием значения RTO для адреса получателя, по которому были посланы данные, если правило R1 указывает, что это нужно сделать.

6.4. Многодомные точки SCTP

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

Протоколу вышележащего уровня (ULP) в конечной точке следует выбрать один из множества адресов многодомного партнёра в качестве основного пути (см. параграфы 5.1.2 и 10.1).

По умолчанию конечной точке следует всегда передавать данные по первичному пути, если пользователь SCTP явно не указал транспортный адрес получателя (возможно и транспортный адрес отправителя).

Конечной точке следует передавать блоки откликов (например, SACK, HEARTBEAT ACK и т. п.) по тому же транспортному адресу, с которого был получен блок DATA или управляющий блок, вызвавший передачу отклика. Этому правилу нужно следовать также в тех случаях, когда конечная точка объединяет с откликом блоки DATA.

Однако при подтверждении множества блоков DATA, полученных в пакетах с разных адресов, в одном SACK этот блок SACK может передаваться по одному из транспортных адресов, с которых были получены подтверждаемые блоки DATA или управляющие блоки.

Когда получатель дубликата блока DATA передаёт блок SACK многодомной конечной точке, он может воспользоваться выбором адреса получателя и не применять адрес отправителя блока DATA. Причина этого заключается в том, что получение дубликата от многодомной конечной точки может указывать на то, что путь возврата, указанный в поле отправителя блока DATA, может быть недоступен (разорван) для передачи SACK.

Конечной точке, имеющей многодомного партнёра, следует пытаться повторять передачу блока по активному транспортному адресу, отличающемуся от последнего адреса получателя, по которому был передан блок DATA.

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

6.4.1. Переключение с неактивного адреса получателя

Некоторые транспортные адреса многодомной конечной точки SCTP могут утратить активность в результате ошибок (см. параграф 8.2) или по желанию пользователя SCTP.

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

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

Примечание. Правила выбора максимально отличающейся пары зависят от реализации и не определяются данной спецификацией.

6.5. Идентификаторы и порядковые номера в потоке

Каждый блок DATA должен содержать приемлемый идентификатор потока. Если конечная точка принимает блок DATA с неприемлемым идентификатором, ей следует подтвердить получение данных в соответствии с обычной процедурой, незамедлительно передать блок ERROR с причиной ошибки Invalid Stream Identifier (неприемлемый идентификатор потока, см. параграф 3.3.10) и отбросить блок DATA. Конечная точка может группировать блок ERROR в один пакет с блоком SACK, если ERROR следует после SACK.

Порядковые номера во всех потоках должны начинаться с нуля при создании ассоциации. При достижении порядковым номером в потоке значения 65535 следующим номером снова должен быть 0.

6.6. Упорядоченная и неупорядоченная доставка

Внутри потока конечная точка должна доставлять блоки DATA, полученные с флагом U = 0, на вышележащий уровень в соответствии с порядковыми номерами блоков в потоке. Если блоки DATA поступают с нарушением порядка, конечная точка должна удерживать полученные блоки DATA от передачи ULP, пока не будет восстановлен порядок.

Однако конечная точка SCTP может запросить неупорядоченную доставку для определённого блока DATA, передаваемого в потоке, установив для этого блока флаг U = 1.

При получении конечной точкой блока DATA с флагом U = 1, этот блок должен обрабатываться в обход механизма упорядочивания и незамедлительно доставляться на вышележащий уровень (после сборки фрагментов, если отправитель фрагментировал блок).

Это обеспечивает эффективный способ передачи «дополнительных» (out-of-band) данных в потоке. Кроме того, весь поток можно сделать неупорядоченным, устанавливая флаг U = 1 для каждого блока DATA в этом потоке.

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

Поле Stream Sequence Number в блоке DATA с флагом U = 1 не имеет смысла. Отправитель может указывать в этом поле произвольное значение, а получатель должен игнорировать это поле.

Примечание. При передаче упорядоченных и неупорядоченных данных, конечная точка не увеличивает своё значение поля Stream Sequence Number, передавая блок DATA с флагом U = 1.

6.7. Информация о пропусках в порядковых номерах TSN блоков DATA

При получении нового блока DATA конечной точке следует проверить непрерывность порядковых номеров TSN. При обнаружении пропуска в порядковых номерах принятых блоков DATA конечной точке следует незамедлительно передать блок SACK с Gap Ack Block. Получатель продолжает передачу SACK после получения каждого пакета SCTP, который не закрывает пропуск в порядковых номерах.

На основе Gap Ack Block из полученного блока SACK конечная точка может определить пропущенные блоки DATA и принять решение о необходимости повторной передачи таких блоков (см. параграф 6.2.1).

В одном блоке SACK может передаваться информация о нескольких обнаруженных пропусках (см. параграф 3.3.4).

Если партнёр является многодомным, конечной точке SCTP всегда следует пытаться передать SACK по тому адресу, с которого был получен последний блок DATA.

При получении блока SACK конечная точка должна удалить из выходной очереди все блоки DATA, которые были подтверждены в Cumulative TSN Ack блока SACK. Конечная точка должна также трактовать все блоки DATA с номерами TSN, не включёнными в Gap Ack Block из блока SACK, как «отсутствующие». Число отчётов о «потерях» для каждого неподтвержденного блока DATA должно быть записано отправителем, чтобы принять решение о повторной передаче (см. параграф 7.2.4).

На рисунке 9 приведён пример использования SACK для передачи информации о пропуске порядковых номеров.

Точка A Точка Z {Приложение передало 3 сообщения; strm 0} DATA [TSN=6,Strm=0,Seq=2] —————> (задержка ack) (Запуск таймера T3-rtx) DATA [TSN=7,Strm=0,Seq=3] ———> X (lost) DATA [TSN=8,Strm=0,Seq=4] —————> (обнаружен пропуск, немедленно передаем ack) /—— SACK [TSN Ack=6,Block=1, / Strt=2,End=2] <——/ (удаляем 6 из выходной очереди и помечаем 7 как отчет о пропуске «1»)

Рисунок 9. Отчет о пропуске с использованием SACK

Максимальное число Gap Ack Block, которые могут быть включены в один блок SACK, ограничивается текущим значением MTU для пути. Когда в один блок SACK невозможно включить все Gap Ack Block, которые нужно передать, по причине ограничения MTU, конечная точка должна передать только один блок SACK, включающий все Gap Ack Block от младших номеров TSN к старшим, которые могут поместиться в блок, ограниченный значением MTU, и оставить старшие номера TSN неподтвержденными.

6.8. Расчёт контрольных сумм CRC32c

При передаче пакета SCTP конечная точка должна для обеспечения возможности контроля целостности данных включить в пакет значение контрольной суммы CRC32c в соответствии с приведённым ниже описанием.

После создания пакета (содержащего общий заголовок SCTP и один или несколько управляющих блоков или блоков DATA), отправитель должен выполнить перечисленные ниже операции.

Заполнить поле Verification Tag общего заголовка SCTP и установить нулевое значение в поле контрольной суммы.
Рассчитать контрольную сумму CRC32c с включением общего заголовка SCTP и всех блоков из пакета. Описание алгоритма CRC32c приводится в Приложении B.
Поместить полученное значение в поле контрольной суммы общего заголовка, не изменяя остальных битов.

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

Сохранить полученное в пакете значение контрольной суммы CRC32c.
Заменить 32-битовое поле контрольной суммы принятого пакета SCTP значением 0 и рассчитать контрольную сумму CRC32c для изменённого пакета.
Сравнить сохранённое значение (из пакета) CRC32c с контрольной суммой, полученной в результате расчёта. Если значения не совпадут, получатель должен трактовать принятый пакет как некорректный.

По умолчанию некорректные пакеты SCTP отбрасываются без уведомления.

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

6.9. Фрагментация и сборка

Конечная точка может поддерживать фрагментацию при передаче блоков DATA и должна поддерживать сборку фрагментов для принимаемых блоков DATA. Если конечная точка поддерживает фрагментацию, она должна фрагментировать пользовательские сообщения, когда их размер приводит к созданию пакетов SCTP, превышающих по своему размеру значение MTU. Если реализация не поддерживает фрагментацию, конечная точка должна возвращать вышележащему уровню код ошибки, не пытаясь передать сообщение избыточного размера.

Примечание. Если реализация поддерживает фрагментирование, и обеспечивает вышележащему уровняю возможность управления фрагментированием, она может позволить отключать его. Однако в таких случаях реализация должна реагировать подобно реализации, не поддерживающей фрагментирование (т. е., она должна отвергать передачу пакетов, размер которых превышает P-MTU²³).

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

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

Примечание. После фрагментации сообщения оно не может быть фрагментировано еще раз. Если же значение Path MTU уменьшилось, в таких случаях должна использоваться фрагментация IP. Определение значений Path MTU рассматривается в параграфе 7.3.

При решении вопроса о необходимости фрагментирования реализация SCTP должна принимать во внимание размер заголовка пакета SCTP и заголовков блоков DATA. Должен также приниматься во внимание размер блоков SACK, если они группируются с блоком DATA.

Фрагментация выполняется следующим образом.

Отправитель должен разбить пользовательское сообщение не несколько блоков DATA, чтобы размер каждого блока в сумме со служебной информацией SCTP не превышал размер поля данных дейтаграммы IP, которая по своему размеру равна или меньше значения Path MTU для ассоциации.
Отправитель должен выделить по порядку номера TSN для каждого из блоков DATA, содержащих фрагменты сообщения. Всем блокам DATA, содержащим фрагменты одного сообщения, присваиваются одинаковые номера SSN. Если пользователь указал, что сообщение доставляется без соблюдения порядка, для каждого блока DATA должен быть установлен флаг U = 1.
Отправитель должен также установить биты B/E блока DATA для всех фрагментов (10 для первого, 01 для последнего и 00 для всех остальных).

Конечная точка должна идентифицировать фрагментированные блоки DATA путём проверки битов B/E в каждом принятом блоке DATA и помещать фрагменты в очередь для сборки. После сборки пользовательского сообщения из фрагментов, протокол SCTP будет передавать собранное сообщение в конкретный поток для возможного упорядочивания и окончательной диспетчеризации.

Примечание. Если на передающей стороне недостаточно памяти для буферизации фрагментов в процессе ожидания их доставки, следует направить полученную часть входящего сообщения через API частичной доставки (см. главу 10) для освобождения буферного пространства.

6.10. Группировка блоков

Конечная точка группирует блоки путём простого включения множества блоков в один исходящий пакет SCTP. Суммарный размер получающейся в результате дейтаграммы IP (включая пакет SCTP и заголовок IP) должен быть не более текущего значения Path MTU.

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

При группировке управляющих блоков с блоками DATA конечная точка должна помещать управляющие блоки перед блоками данных. Отправитель должен передавать блоки DATA внутри пакета SCTP в соответствии с ростом номеров TSN.

Примечание. Поскольку управляющие блоки должны размещаться в пакете перед блоками DATA, а блоки DATA должны передаваться до управляющих блоков SHUTDOWN и SHUTDOWN ACK, блоки DATA не могут группироваться с блоками SHUTDOWN или SHUTDOWN ACK.

Недопустимо включение в пакет SCTP неполных блоков (Partial chunk). Неполным является блок, которым не помещается в пакет SCTP (пакет слишком мал для включения всех байтов блока, указанных в поле размера блока).

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

Недопустимо группировать блоки INIT, INIT ACK, SHUTDOWN COMPLETE с любыми другими блоками.

7. Контроль насыщения

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

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

Алгоритмы контроля насыщения протокола SCTP основаны на [RFC2581]. В этой главе описано, как алгоритмы, определённые в RFC2581, адаптированы для использования в SCTP. Сначала рассматриваются различия между протоколами TCP и SCTP, а после этого описывается схема контроля насыщения в SCTP. В описании используется та же терминология, которая принята для протокола TCP.

Контроль насыщения в SCTP всегда применяется ко всей ассоциации (соединению), а не к отдельным потокам.

7.1. Различия в контроле насыщения для SCTP и TCP

Gap Ack Block в SCTP SACK имеют такой же смысл, как TCP SACK. Протокол TCP рассматривает информацию в SACK только как консультативную. SCTP также рассматривает информацию, передаваемую в Gap Ack Blocks блоков SACK как консультативную. В SCTP любой блок DATA, подтверждённый с помощью SACK (включая блоки DATA, полученные на приёмной стороне с нарушением порядка), не рассматривается как доставленный окончательно, пока Cumulative TSN Ack Point не перейдёт значение TSN блока DATA (т. е., пока блок DATA не будет подтверждён полем Cumulative TSN Ack в SACK). Следовательно, значение параметра cwnd контролирует количество неподтвержденных данных, а не (как в случае TCP без SACK) верхнюю границу между максимальным подтверждённым. порядковым номером и последним блоком DATA, который может быть передан в окне насыщения. SCTP SACK обусловливает отличие реализации механизмов ускоренного повтора (fast-retransmit) и быстрого восстановления (fast-recovery) от случая TCP без SACK. Пример этого приведён в [FALL96].

Наиболее серьёзным различием между SCTP и TCP является поддержка в SCTP многодомных конечных точек. Протокол SCTP разработан для организации устойчивых соединений (ассоциаций) между конечными точками, каждая из которых может быть доступна с использованием множества транспортных адресов. Использование различных адресов может вести к организации разных путей между парой конечных точек и в идеальном случае для каждого пути могут применяться свои параметры контроля насыщения. Приведённая здесь трактовка контроля насыщения для многодомных получателей является новинкой протокола SCTP и может быть уточнена в будущем. Текущий алгоритм основан на приведённых ниже допущениях.

Отправитель обычно не меняет адрес получателя, пока не получит запрос на такую замену от протокола вышележащего уровня. Однако SCTP может переключиться на другой адрес получателя, если прежний адрес был помечен, как неактивный (см. параграф 8.2). Кроме того, SCTP может повторять передачу пакетов по адресам, отличающимся от тех, которые использовались для передачи исходного пакета.
Отправитель сохраняет отдельный набор параметров контроля насыщения для каждого адреса получателя, по которому он может передавать данные (не для каждой пары адресов «отправитель-получатель», а для каждого адреса получателя). Параметры следует отбрасывать, если адрес не используется достаточно долго.
Для каждого адреса получателя конечная точка выполняет процедуру замедленного старта (slow-start) в начале передачи данных по этому адресу.

Примечание. TCP гарантирует упорядоченную доставку данных протоколу вышележащего уровня в рамках одной сессии TCP. Это означает, что при получении протоколом TCP информации о пропуске в порядковых номерах он будет ждать заполнения пропуска и только после этого передаст данные вышележащему уровню. SCTP может доставлять данные на вышележащий уровень даже при наличии пропусков в порядковых номерах TSN, если порядковые номера в потоке (Stream Sequence Number) упорядочены в рамках данного потока (т. е., пропущенный блок DATA относится к другому потоку) или при запросе неупорядоченной доставки. Это различие не оказывает влияния на cwnd, но может влиять на расчёт rwnd.

7.2. Процедуры Slow-Start и Congestion Avoidance

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

Подобно TCP, конечная точка SCTP использует три перечисленных ниже переменных для управления скоростью передачи.

Анонсируемый получателем размер окна приёма (rwnd²⁴, в байтах) устанавливается получателем данных с учётом возможностей выделения буферов для принимаемых пакетов.
Окно контроля насыщения (cwnd²⁵, в байтах) устанавливается отправителем с учётом условий в сети.
Порог замедленного старта (ssthresh²⁶, в байтах) используется отправителем для принятия решения о выборе используемого алгоритма контроля насыщения (slow start или congestion) на данной фазе.
Примечание. Эта переменная поддерживается для каждого адреса получателя.
Примечание. Эта переменная поддерживается для каждого адреса получателя.
Примечание. Эта переменная имеет общее значение для всей ассоциации.

Протокол SCTP использует также одну дополнительную переменную — partial_bytes_acked, которая применяется в фазе предотвращения перегрузки для упрощения расчёта значения cwnd.

В отличие от TCP, отправитель SCTP должен хранить набор из трёх переменных (cwnd, ssthresh и partial_bytes_acked) для каждого адреса получателя на удалённой стороне (если партнёр является многодомным). Только переменная rwnd имеет общее значение для всей ассоциации (независимо от того, является ли партнёр многодомным).

7.2.1. Замедленный старт

Начиная передачу данных в сеть с неизвестными условиями или возобновляя передачу после достаточно долгого простоя, протокол SCTP должен проверить сеть на предмет пропускной способности. Для этих целей используется алгоритм slow start на начальной стадии передачи или при восстановлении потерь, обнаруженных по таймеру повтора передачи.

В качестве стартового значения cwnd до передачи блоков DATA или после достаточно долгого бездействия должно выбираться значение min(4*MTU, max (2*MTU, 4380 байта).
Начальное значение cwnd после тайм-аута для повтора передачи должно быть не более 1*MTU.
Начальное значение ssthresh может быть произвольно большим (например, реализация может просто установить для этого параметра значение размера окна приёма, анонсируемого получателем).
При положительном значении cwnd конечная точка может иметь cwnd ожидающих подтверждения байтов данных для этого транспортного адреса.
Если cwnd не больше ssthresh, конечная точка SCTP должна использовать алгоритм slow-start для увеличения размера cwnd только в том случае, когда текущее окно насыщения полностью использовано, входящих блок SACK указывает за пределы Cumulative TSN Ack Point и отправитель данных не находится в состоянии Fast Recovery. Размер окна cwnd можно увеличивать только при выполнении всех трёх условий, в противном случае он не должен увеличиваться. Если все три условия выполнены, значение cwnd должно увеличиваться не более чем на меньшее из двух значений — 1) общий размер подтверждённых блоков DATA или 2) значение path MTU для данного адресата. Такой подход обеспечивает защиту от атаки ACK-Splitting, описанной в [SAVAGE99].

В случаях, когда партнёр является многодомным и конечная точка получает подтверждение SACK, указывающее за пределы Cumulative TSN Ack Point, ей следует обновить значение cwnd (или несколько значений cwnd) для адреса получателя, по которому были переданы подтверждённые данные. Однако, если принятое подтверждение SACK не указывает вперёд Cumulative TSN Ack Point, для конечной точки недопустимо менять значение cwnd для любого из адресов получателя.

Поскольку значение cwnd для конечной точки не связано с Cumulative TSN Ack Point для неё, при получении дубликата SACK (даже если он не указывает за пределы Cumulative TSN Ack Point), конечная точка может продолжать использование этого подтверждения для синхронизации отправки новых данных. Т. е., данные, подтверждённые последним SACK уменьшают количество данных, находящихся в пути до значения меньше cwnd и даже неизменное значение cwnd позволяет передать новую порцию данных в сеть. С другой стороны, увеличение cwnd должно быть связано с подтверждением сверх Cumulative TSN Ack Point, как было сказано выше. В противном случае дубликат SACK будет не только разрешать передачу в сеть новых данных, но и увеличивать количество данных, которые можно передать, не дожидаясь подтверждения, хотя в это время сеть может оказаться перегруженной.

Когда конечная точка не передаёт данных по какому-либо транспортному адресу, в качестве значения cwnd для этого адреса следует установить max(cwnd/2, 4*MTU) в расчёте на RTO.

7.2.2. Предотвращение перегрузки

При cwnd > ssthresh, значение cwnd следует увеличивать на 1*MTU за каждый период RTT, если у отправителя имеется не менее cwnd байтов неподтвержденных данных для соответствующего транспортного адреса.

На практике эта процедура может быть реализована описанным ниже способом.

Устанавливается partial_bytes_acked = 0.
Если cwnd > ssthresh, всякий раз при получении SACK, указывающего за пределы Cumulative TSN Ack Point, значение partial_bytes_acked увеличивается на число байтов во всех блоках, подтверждённых этим SACK, включая блоки, подтверждённые новым значением Cumulative TSN Ack и Gap Ack Block.
Когда значение partial_bytes_acked становится равным cwnd или превышает его и до прибытия SACK у отправителя имеется не менее cwnd неподтвержденных данных (т. е., до прибытия SACK, объем переданных, но еще не подтверждённых данных больше или равен размеру окна cwnd), значение cwnd увеличивается на MTU, а значение partial_bytes_acked уменьшается на cwnd.
Как и при замедленном старте в качестве значения cwnd для адреса получателя следует установить max(cwnd/2, 4*MTU) в расчёте на RTO, если отправитель не передаёт блоков DATA по данному адресу.
Когда все переданные отправителем данные подтверждены получателем, устанавливается partial_bytes_acked = 0.

7.2.3. Контроль насыщения

При обнаружении потери пакета из подтверждения SACK (см. параграф 7.2.4), конечной точке следует установить значения

ssthresh = max(cwnd/2, 4*MTU) cwnd = ssthresh partial_bytes_acked = 0

Обычно потеря пакета приводит к уменьшению cwnd вдвое.

Когда завершается отсчёт. по таймеру T3-rtx для этого адреса, SCTP следует выполнить процедуру замедленного старта, установив

ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU

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

7.2.4. Ускоренный повтор при пропуске

При отсутствии потерь данных конечная точка может использовать подтверждение с задержкой. Однако при обнаружении пропуска в порядковых номерах TSN следует начать передачу подтверждений SACK незамедлительно после доставки каждого пакета пока пропуск в порядковых номерах не будет заполнен.

Всякий раз при получении SACK, указывающего на пропуск некоторых номеров TSN, конечной точке следует дождаться 2 последующих индикаций потери (в следующих подтверждениях SACK) для тех же номеров, прежде, чем начать реализацию механизма ускоренного повтора (Fast Retransmit).

Для индикации пропусков следует применять алгоритм HTNA²⁷. Для каждого входящего блока SACK значение счётчика индикации пропуска увеличивается только для пропущенных TSN до максимального значения TSN, недавно подтверждённого в SACK. Недавно подтверждённым. блоком DATA считается блок, который не был ранее указан в SACK. Если конечная точка находится в состоянии Fast Recovery и получает блок SACK, указывающий за пределы Cumulative TSN Ack Point, значения индикации пропуска увеличиваются для всех TSN, пропуск которых указывает этот блок SACK.

Когда отсутствующие номера TSN указаны в 3 последовательных подтверждениях SACK, отправителю следует выполнить перечисленные ниже действия.

Пометить указанные блоки DATA для повторной передачи.
Если не введён режим Fast Recovery, изменить значения ssthresh и cwnd для адреса (или нескольких адресов) получателя, по которому были переданы утерянные данные в последний раз, согласно выражениям, приведённым в параграфе 7.2.3.
Определить, сколько наиболее ранних (т. е., с меньшими номерами TSN) блоков DATA может быть включено в один пакет с учётом значения path MTU для транспортного адреса получателя, по которому будут передаваться данные (обозначим это количество буквой K). Повторно передать эти K блоков DATA в одном пакете. В режиме Fast Retransmit отправителю следует игнорировать значение cwnd и не следует задерживать повтор передачи для одного данного пакета.
Заново запустить таймер T3-rtx, если последнее подтверждение SACK относится к меньшему из неподтвержденных номеров TSN для данного адреса получателя или конечная точка повторяет передачу первого из неподтвержденных блоков DATA, переданных по этому адресу.
Пометить блок(и) DATA, как ускоренно повторённый и не приемлемый для последующего режима Fast Retransmit. Эти TSN маркируются для повторной передачи по причине того, что алгоритм Fast-Retransmit не подходит для дейтаграммы, содержащей K других TSN, которые также отмечены не приемлемыми для последующего ускоренного повтора. Однако в результате их маркировки для повтора эти номера будут переданы заново, как только позволит cwnd.
Перейти в режим Fast Recovery (если он еще не введён) и указать старший неподтвержденный номер TSN в качестве точки выхода из режима быстрого восстановления. Когда блок SACK подтвердит все TSN, вплоть до указанной точки выхода, режим быстрого восстановления завершается. В режиме Fast Recovery значения ssthresh и cwnd не следует менять для каких-либо получателей по причине последующей процедуры быстрого восстановления (т. е., не следует снижать значение cwnd в результате последующего ускоренного повтора).

Примечание. Если полученный блок SACK также подтверждает новые блоки DATA за пределами Cumulative TSN AckPoint, перед выполнением перечисленных в пп. 1 — 6 операций нужно сначала изменить значение cwnd в соответствии с правилами, приведёнными в параграфах 7.2.1 и 7.2.2.

Корректная реализация приведённых выше правил будет подсчитывать все пропуски TSN, о которых сообщалось в SACK. Значение счётчика увеличивается для каждого последующего подтверждения SACK, указывающего на пропуск TSN. После того, как значение счётчика достигнет 3 и будет начата процедура ускоренного повтора передачи, значение счётчика сбрасывается в 0.

Поскольку значение cwnd в SCTP опосредованно ограничивает количество неподтвержденных TSN, механизм быстрого восстановления TCP (Fast Recovery) реализуется автоматически без изменения размера окна контроля насыщения.

7.3. Определение MTU для пути

В [RFC4821], [RFC1981] и [RFC1191] описан алгоритм определения MTU для путей с коммутацией пакетов (Packetization Layer Path MTU Discovery), позволяющий конечным точкам оценить максимальный размер передаваемого блока (MTU²⁸) для данного пути через Internet и воздерживаться от передачи по этому пути пакетов, размер которых превышает MTU, без использования методов зондирования с целью определения изменений Path MTU (PMTU). В [RFC4821] подробно рассмотрен механизм определения MTU и стратегия установки сквозного значения MTU для пути, а также детектирования изменений MTU.

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

При определении значения MTU для протокола SCTP существуют несколько отличий:

Ассоциация SCTP может включать множество адресов. Конечная точка должна поддерживать отдельную оценку значения MTU для каждого из адресов своего партнёра.
Отправителю следует контролировать значение PMTU для ассоциации в целом, выбирая для этого минимальное из значений PMTU для путей ко всем адресам партнёра. При фрагментации сообщений значение PMTU для ассоциации в целом следует использовать для определении размера фрагментов. Такой подход позволит передавать фрагменты по любому из возможных путей без дополнительной фрагментации на уровне IP.

8. Контроль отказов

8.1. Обнаружение отказов конечных точек

Конечной точке следует подсчитывать общее количество последовательных повторов передачи своему партнёру (включая повторы по всем адресам для многодомных партнёров.) с учётом неподтвержденных блоков HEARTBEAT. Если значение этого счётчика превысит порог, указанный параметром протокола Association.Max.Retrans²⁹, конечной точке следует рассмотреть вопрос о доступности партнёра и прекращении передачи ему каких-либо данных (т. е., перевода ассоциации в состояние CLOSED). Кроме того, конечная точка может передать информацию об отказе (и, возможно, об оставшихся в выходной очереди данных) протоколу вышележащего уровня. Ассоциация автоматически закрывается, когда удалённый партнёр становится недоступным.

Счётчик повторов следует сбрасывать всякий раз, когда переданный партнёру блок DATA подтверждается с помощью SACK или от удалённого партнёра принимается HEARTBEAT ACK.

8.2. Обнаружение сбоев в пути

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

Каждый раз, когда завершается отсчёт. таймера T3-rtx для любого из адресов или передача HEARTBEAT по бездействующему адресу не подтверждается в течение RTO, значение счётчика ошибок для соответствующего адреса будет увеличиваться на 1. Когда значение счётчика превысит значение параметра протокола Path.Max.Retrans³⁰‘ для данного адреса, конечной точке следует пометить этот адрес как неактивный, а также следует передать уведомление об этом протоколу вышележащего уровня.

Когда остающиеся в сети номера TSN подтверждаются или блок HEARTBEAT, переданный по бездействующему адресу, подтверждается блоком HEARTBEAT ACK, конечная точка должна сбрасывать счётчик ошибок для транспортного адреса получателя, по которому был отправлен последний блок DATA (или блок HEARTBEAT). Если партнёр является многодомным и последний блок был передан ему в качестве повтора с изменением адреса получателя, возникает неоднозначность в выборе адреса, для которого следует учитывать полученное подтверждение. Однако эта неоднозначность не оказывает существенного влияния на дальнейшее поведение SCTP. Если такие неоднозначности нежелательны, отправитель может не сбрасывать счётчик ошибок, когда последний блок передавался повторно.

Примечание. При настройке конфигурации конечной точки SCTP следует избегать установки для параметра Association.Max.Retrans значения, превышающего любое из значений Path.Max.Retrans для адресов удалённой конечной точки. В противном случае все адреса удалённого партнёра могут стать неактивными, а данная точка будет по-прежнему считать этого партнёра доступным. При возникновении такой ситуации поведение протокола SCTP будет зависеть от конкретной реализации.

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

8.3. Проверка жизнеспособности пути

По умолчанию конечной точке SCTP следует вести мониторинг доступности бездействующих транспортных адресов своего партнёра путём периодической отправки по таким адресам блоков HEARTBEAT. Передача HEARTBEAT может начинаться с момента перехода в состояние ESTABLISHED и завершаться после отправки блока SHUTDOWN или SHUTDOWN-ACK. Получатель блока должен отвечать на него блоком HEARTBEAT-ACK после перехода в состояние COOKIE-ECHOED (отправитель INIT) или ESTABLISHED (получатель INIT), пока не перейдёт в состояние SHUTDOWN-SENT (отправитель SHUTDOWN) или SHUTDOWN-ACK-SENT (получатель SHUTDOWN).

Транспортный адрес рассматривается как бездействующий (idle), если нет новых блоков, которые могут использоваться для обновления периода RTT для пути (обычно, к таким блокам относятся DATA, INIT, COOKIE ECHO, HEARTBEAT и т. п.), и в течение текущего периода «проверки пульса»³¹ по этому адресу не было передано блоков HEARTBEAT. Эта трактовка относится как к активным адресам, так и к неактивным.

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

запрет HEARTBEAT для определённого транспортного адреса в рамках данной ассоциации;
изменение интервала HB.interval;
восстановление передачи HEARTBEAT для указанного адреса в данной ассоциации;
запрос на передачу HEARTBEAT по указанному адресу в данной ассоциации.

Конечной точке следует увеличивать значение соответствующего счётчика ошибок для транспортного адреса партнёра всякий раз, когда переданный по этому адресу блок HEARTBEAT не был подтверждён в течение периода RTO.

Когда значение счётчика достигает значения протокольного параметра Path.Max.Retrans, конечной точке следует пометить соответствующий адрес получателя как неактивный (если он еще не помечен). Кроме того, конечная точка может сообщить вышележащему уровню об изменении состояния доступности для данного адреса получателя. После этого конечной точке следует продолжать передачу блоков HEARTBEAT по этому адресу, но без дальнейшего увеличения значения счётчика ошибок.

Отправителю блока HEARTBEAT следует включать в поле Heartbeat Information этого блока текущее время в момент передачи пакета.

Примечание для разработчиков. Для увеличения значений счётчиков может использоваться иной механизм, при котором значение счётчика увеличивается при передаче каждого блока HEARTBEAT. В таких случаях по прибытию подтверждения HEARTBEAT ACK следует сбрасывать счётчик для того адреса, по которому был передан подтверждённый блок HEARTBEAT. Такое уменьшение будет компенсировать рост значения счётчика при передаче каждого блока, а также сбрасывать результаты увеличения счётчика вследствие других ошибок.

Получателю блока HEARTBEAT следует незамедлительно передать в ответ подтверждение HEARTBEAT ACK, содержащее Heartbeat Information из полученного блока HEARTBEAT.

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

Получателю HEARTBEAT ACK следует также выполнить определение RTT для транспортного адреса партнёра, используя значение времени из блока HEARTBEAT ACK.

Для бездействующего транспортного адреса, которому разрешено передавать блоки HEARTBEAT, рекомендуется передавать один блок в каждый период RTO для данного адреса получателя + HB.interval с вариациями ± 50% от RTO и экспоненциальным снижением RTO, если доставка предыдущего блока HEARTBEAT не подтверждена.

Для пользователей SCTP обеспечивается примитив, позволяющий изменять значение HB.interval и включать/выключать передачу блоков HEARTBEAT для данного адреса. Интервал передачи HEARTBEAT, устанавливаемый пользователем SCTP, добавляется к RTO для данного адресата (с учётом экспоненциального снижения RTO). Следует передавать только один блок HEARTBEAT в течение каждого периода отсчёта heartbeat-таймера (если бездействует множество адресов). Разработчики вольны определить способ выбора кандидата для передачи блока при наличии множества бездействующих адресов.

Примечание. При подстройке интервала heartbeat может возникать побочный эффект, который следует принимать во внимание. Когда этот интервал возрастает (блоки HEARTBEAT передаются реже), детектирование потери сообщений ABORT также замедляется. Если партнёр прервёт (ABORT) ассоциацию по какой-либо причине и блок ABORT будет потерян, локальная точка обнаружит прерывание ассоциации только при передаче блока DATA или HEARTBEAT (это вынудит партнёра передать блок ABORT повторно). Такой эффект следует учитывать при установке значения для таймера HEARTBEAT. Если передача HEARTBEAT запрещена, потеря блока ABORT будет обнаружена только после передачи блока DATA.

8.4. Обработка неожиданных пакетов

Пакет SCTP называется пакетом неожиданным (OOTB³²), если он правильно сформирован (т. е., включает корректное значение контрольной суммы CRC32c, описанной в параграфе 6.8), но получатель не может идентифицировать ассоциацию, к которой этот пакет относится.

Получатель пакета OOTB должен выполнить перечисленные ниже операции с соблюдением их порядка.

Если в пакете OOTB указан отличный от индивидуального (non-unicast) адрес отправителя или получателя, такой пакет следует отбрасывать без уведомления.
Если пакет OOTB содержит блок ABORT, получатель должен отбросить такой пакет без уведомления и выполнения каких-либо дополнительных действий.
Если пакет содержит блок INIT с полем Verification Tag = 0, он обрабатывается, как описано в параграфе 5.1. Если по той или иной причине нормальная обработка INIT не возможна и в ответ передаётся блок ABORT, поле Verification Tag в пакете, содержащем блок ABORT должно иметь значение Initiate Tag из полученного блока INIT, а бит T в блоке ABORT должен быть сброшен (0) для индикации того, что значение Verification Tag не отражено.
Если пакет содержит COOKIE ECHO в первом блоке, обработка пакета выполняется в соответствии с параграфом 5.1.
Eсли пакет содержит блок SHUTDOWN ACK, получателю следует передать отправителю пакета OOTB блок SHUTDOWN COMPLETE. При передаче блока SHUTDOWN COMPLETE получатель пакета OOTB должен заполнить поле Verification Tag, скопировав в него значение Verification Tag из блока SHUTDOWN ACK, и установить бит T в поле флагов блока для индикации отражения Verification Tag.
Если пакет содержит блок SHUTDOWN COMPLETE, получателю следует отбросить пакет без уведомления и выполнения каких-либо дополнительных действий.
Если пакет содержит Stale cookie ERROR или блок COOKIE ACK, пакет SCTP следует отбросить без уведомления.
В остальных случаях получателю следует ответить отправителю пакета OOTB пакетом с блоком ABORT. При передаче блока ABORT получатель пакета OOTB должен указать в поле Verification Tag значение Verification Tag из пакета OOTB и установить бит T в поле флагов для индикации отражения Verification Tag. После передачи блока ABORT получатель пакета OOTB должен отбросить этот пакет, не выполняя каких-либо дополнительных действий.

8.5. Тег верификации

Правила Verification Tag, определённые в этом параграфе, применяются для передачи и приёма пакетов SCTP, не содержащих блоков INIT, SHUTDOWN COMPLETE, COOKIE ECHO (см. параграф 5.1), ABORT или SHUTDOWN ACK. Для перечисленных блоков правила рассмотрены отдельно в параграфе 8.5.1.

При передаче пакета SCTP конечная точка должна заполнить поле Verification Tag, указав в нем значение параметра Initiate Tag из полученного от партнёра блока INIT или INIT ACK.

При получении пакета SCTP конечная точка должна проверить соответствие полученного значения Verification Tag своему значению тега. Если полученное значение Verification Tag не соответствует тегу локальной точки, получателю следует отбросить пакет без уведомления и не выполнять каких-либо дополнительных операций за исключением случаев, описанных в параграфе 8.5.1.

8.5.1. Исключения из правил для Verification Tag

Правила для пакетов с блоками INIT.

Отправитель должен установить Verification Tag = 0.
Когда конечная точка получает пакет SCTP с Verification Tag = 0, ей следует убедиться, что пакет содержит только блок INIT. В противном случае пакет должен быть отброшен без уведомления.

Правила для пакетов с блоками ABORT.

Конечная точка всегда должна указывать в поле Verification Tag передаваемых пакетов значение тега адресата, если этот тег известен.
Если блок ABORT передаётся в ответ на пакет OOTB, конечная точка должна выполнить процедуру, описанную в параграфе 8.4.
Получатель блока ABORT должен воспринять пакет, если значение Verification Tag соответствует его собственному тегу или тегу партнёра. В противном случае пакет должен отбрасываться без уведомления и выполнения каких-либо других действий.

Правила для пакетов с блоками SHUTDOWN COMPLETE.

При передаче блока SHUTDOWN COMPLETE, если получатель блока SHUTDOWN ACK имеет значение TCB, в поле верификации должен использоваться тег адресата, а установка флага T недопустима. При отсутствии TCB отправителю следует использовать значение Verification Tag из блока SHUTDOWN ACK и он должен установить флаг T.
Получатель SHUTDOWN COMPLETE должен воспринять пакет, если поле Verification Tag соответствует его собственному тегу и в поле флагов бит T не установлен или поле соответствует тегу партнёра и бит T установлен. В противном случае получатель должен отбрасывать пакет без уведомления и выполнения каких-либо иных действий. Конечная точка должна игнорировать SHUTDOWN COMPLETE, если она не находится в состоянии SHUTDOWN-ACK-SENT.

Правила для пакетов с блоками COOKIE ECHO.

При передаче COOKIE ECHO конечная точка должна использовать значение Initial Tag из принятого блока INIT ACK.
Получателю COOKIE ECHO следует выполнить процедуры, описанные в разделе 5.

Правило для пакетов с блоками SHUTDOWN ACK.
1. Если получатель находится в состоянии COOKIE-ECHOED или COOKIE-WAIT, следует выполнить процедуры, описанные в параграфе 8.4 (т. е., пакет должен трактоваться как OOTB).

9. Прекращение работы ассоциации

Конечной точке следует прерывать ассоциацию, когда сервис более не требуется. Ассоциация может быть прервана путём разрыва (abort) или завершения (shutdown). Разрыв ассоциации представляет собой прекращение всякой передачи данных с отбрасыванием всех оставшихся не доставленными данных. Завершение ассоциации представляет собой процесс контролируемого прекращения обмена данными с доставкой партнёру всех данных, остающихся в очередях. Однако в случае завершения (shutdown) протокол SCTP не поддерживает полуоткрытых состояний (как в TCP), когда одна сторона может продолжать передачу данных в то время, как другая уже закрыла ассоциацию. Когда конечная точка выполняет процедуру завершения, обе стороны ассоциации будут прекращать приём новых данных от пользователя и доставлять только данные, которые находились в очередях на момент приёма или передачи блока SHUTDOWN.

9.1. Разрыв ассоциации (Abort)

Когда конечная точка принимает решение о разрыве существующей ассоциации, она должна передать своему партнёру блок ABORT. Отправитель должен включить значение Verification Tag своего партнёра в исходящий пакет. Недопустимо группировать блок ABORT с блоками DATA. Если ассоциация прерывается по запросу вышележащего уровня, в блоке ABORT следует указать причину User-Initiated Abort (по инициативе пользователя, см. параграф 3.3.10.12).

Для конечной точки недопустима передача откликов на любой принятый пакет, содержащий блок ABORT (см. также параграф 8.4).

Конечная точка, получившая блок ABORT, должна выполнить специальную проверку Verification Tag в соответствии с правилами параграфа 8.5.1.

После проверки Verification Tag принявшая блок конечная точка должна удалить ассоциацию из своих записей и ей следует также сообщить о разрыве ассоциации на вышележащий уровень. Если в блоке ABORT указана причина User-Initiated Abort, её следует сделать доступной вышележащему уровню.

9.2. Завершение ассоциации (Shutdown)

Используя примитив SHUTDOWN (параграф 10.1), вышележащий уровень конечной точки ассоциации может выполнить аккуратное завершение работы ассоциации. В этом случае все остающиеся блоки DATA от партнёра, инициировавшего завершение ассоциации, будут доставлены до завершения работы.

При получении от вышележащего уровня примитива SHUTDOWN конечная точка переходит в состояние SHUTDOWN-PENDING и продолжает находиться в этом состоянии, пока все остающиеся данные не будут подтверждены партнёром. Конечная точка не принимает новых данных от вышележащего уровня, но будет повторять передачу данных удалённому партнёру, если в этом возникает необходимость (заполнение пропуска в порядковых номерах).

После того, как все остающиеся в сети данные будут подтверждены партнёром., конечная точка должна передать своему партнёру блок SHUTDOWN, содержащий в поле Cumulative TSN Ack последний порядковый номер TSN, полученный от партнёра. После этого конечная точка должна запустить таймер T2-shutdown и перейти в состояние SHUTDOWN-SENT. По завершении отсчёта таймера конечная точка должна повторно передать блок SHUTDOWN с обновлённым значением последнего порядкового номера TSN, полученного от партнёра.

Должны быть выполнены правила параграфа 6.3 для определения корректного значения таймера T2-shutdown. Для индикации пропусков в порядковых номерах TSN конечная точка может группировать SACK и блок SHUTDOWN в одном пакете SCTP.

Конечной точке следует ограничивать число повторов передачи блока SHUTDOWN с помощью протокольного параметра Association.Max.Retrans. После превышения этого порога конечной точке следует уничтожить TCB и она должна передать информацию о недоступности партнёра на вышележащий уровень (тем самым ассоциация переводится в состояние CLOSED). При получении любых пакетов от партнёра (блоки DATA из очереди) следует сбрасывать счётчик повтора передачи и заново запускать таймер T2-Shutdown, давая партнёру дополнительную возможность передачи всех остающихся блоков DATA из его очередей.

При получении блока SHUTDOWN конечная точка должна:

перейти в состояние SHUTDOWN-RECEIVED;
прекратить приём новых данных от своего пользователя SCTP;
убедиться путём проверки поля Cumulative TSN Ack, что все блоки DATA приняты отправителем блока SHUTDOWN.

После перехода конечной точки в состояние SHUTDOWN-RECEIVED для неё недопустимо передавать SHUTDOWN в ответ на запрос ULP и следует отбрасывать последующие блоки SHUTDOWN.

При наличии остающихся блоков DATA получатель SHUTDOWN должен продолжать нормальные процедуры передачи, описанные в главе 6, пока все остающиеся блоки DATA не будут подтверждены; однако для получателя блока SHUTDOWN недопустимо принимать новые данные от своего пользователя SCTP.

Находясь в состоянии SHUTDOWN-SENT, отправитель блока SHUTDOWN должен незамедлительно передавать в ответ на каждый принятый пакет, содержащий хотя бы один блок DATA, подтверждение SACK и блок SHUTDOWN, а также заново запускать таймер T2-shutdown. Если блок SHUTDOWN сам по себе не может подтвердить все принятые блоки DATA (т. е., имеются номера TSN, которые могут быть подтверждены, но превышают кумулятивное значение TSN и в последовательности TSN возникает пропуск) или получены дубликаты TSN, должен передаваться также блок SACK.

Отправитель блока SHUTDOWN может также запустить таймер T5-shutdown-guard для ограничения общей продолжительности процедуры завершения ассоциации. По завершению отсчёта этого таймера отправителю следует разорвать ассоциацию передачей блока ABORT. При использовании таймера T5-shutdown-guard для него следует устанавливать рекомендуемое значение 5 * RTO.Max.

Если у получателя блока SHUTDOWN больше не остаётся блоков DATA, он должен передать блок SHUTDOWN ACK и запустить таймер T2-shutdown, перейдя в состояние SHUTDOWN-ACK-SENT. По завершению отсчёта таймера конечная точка должна повторить передачу SHUTDOWN ACK.

Отправителю SHUTDOWN ACK следует ограничивать число повторов передачи SHUTDOWN ACK с помощью протокольного параметра Association.Max.Retrans. После превышения заданного порога конечной точке следует уничтожить TCB и можно сообщить вышележащему уровню о недоступности партнёра (тем самым ассоциация переводится в состояние CLOSED).

При получении блока SHUTDOWN ACK отправитель SHUTDOWN должен остановить таймер T2-shutdown, передать своему партнёру блок SHUTDOWN COMPLETE и удалить все записи для данной ассоциации.

При получении блока SHUTDOWN COMPLETE конечная точка будет проверять, что она находится в состоянии SHUTDOWN-ACK-SENT и отбрасывать полученный блок, если состояние отличается от указанного. Если же конечная точка находится в состоянии SHUTDOWN-ACK-SENT, ей следует остановить таймер T2-shutdown и удалить все связанные с ассоциацией записи (тем самым ассоциация переводится в состояние CLOSED).

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

Конечной точке, находящейся в состоянии SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED или SHUTDOWN-ACK-SENT, следует отвергать все новые запросы данных от вышележащего уровня.

Если конечная точка, находящаяся в состоянии SHUTDOWN-ACK-SENT, получает блок INIT (например, при утере блока SHUTDOWN COMPLETE) с транспортными адресами отправителя и получателя (в заголовке IP или блоке INIT), относящимися к данной ассоциации, ей следует отбросить блок INIT и повторить передачу блока SHUTDOWN ACK.

Примечание. Получение блока INIT с совпадающими адресами IP, но другим номером порта говорит о попытке создания новой ассоциации.

Отправителю блока INIT или COOKIE ECHO следует отвечать на получение блока SHUTDOWN-ACK пакетом SCTP, содержащим только блок SHUTDOWN COMPLETE, а в поле Verification Tag общего заголовка следует включать значение тега из полученного пакета SHUTDOWN ACK. Такой пакет рассматривается, как OOTB (см. параграф 8.4). Отправитель INIT оставляет работать свой таймер T1-init и сохраняет состояние COOKIE-WAIT или COOKIE-ECHOED. Завершение отсчёта таймера T1-init будет приводить к повтору передачи блока INIT или COOKIE и последующему созданию новой ассоциации.

Если получатель блока SHUTDOWN находится в состоянии COOKIE WAIT или COOKIE ECHOED, блок SHUTDOWN следует отбрасывать без уведомления.

Если конечная точка находится в состоянии SHUTDOWN-SENT и получает от своего партнёра блок SHUTDOWN, ей следует незамедлительно ответить блоком SHUTDOWN ACK и перейти в состояние SHUTDOWN-ACK-SENT с перезапуском своего таймера T2-shutdown.

Если конечная точка находится в состоянии SHUTDOWN-ACK-SENT и получает от партнёра блок SHUTDOWN ACK, она должна остановить таймер T2-shutdown, передать партнёру блок SHUTDOWN COMPLETE и удалить все связанные с ассоциацией записи.

10. Интерфейс с вышележащим уровнем

Протоколы вышележащих уровней (ULP) должны запрашивать сервис путём передачи примитивов протоколу SCTP и получать уведомления о различных событиях от SCTP.

Примитивы и уведомления, описанные в этом разделе, следует рассматривать, как рекомендации для разработчиков SCTP. Приведённое ниже функциональное описание примитивов интерфейса с ULP служит для иллюстрации. Различные реализации протокола SCTP могут использовать разные интерфейсы с ULP. Однако все реализации SCTP должны обеспечивать некий минимальный сервис, гарантирующий что все реализации SCTP могут поддерживать одинаковую иерархию протоколов.

10.1. ULP -> SCTP

В последующих параграфах приведены функциональные характеристики интерфейса ULP-SCTP. Используемая при описании нотация похожа на описания вызовов процедур или функций в большинстве языков высокого уровня.

Примитивы ULP, описанные ниже, задают базовые функции, которые протокол SCTP должен выполнять для поддержки обмена данными между процессами. Та или иная реализация протокола может определять свой формат и поддерживать комбинации или подмножества базовых функций в одном вызове.

A) Initialize — инициализация

Формат

INITIALIZE ([local port], [local eligible address list]) -> имя локального экземпляра SCTP

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

SCTP будет возвращать ULP имя локального экземпляра SCTP.

Обязательные атрибуты

Нет.

Необязательные атрибуты

С примитивом могут передаваться следующие типы атрибутов:

local port — номер порта SCTP, если ULP хочет задать порт;
local eligible address list — список адресов, с которыми следует связать локальную точку SCTP. По умолчанию при отсутствии списка локальная точка связывается со всеми адресами IP, присвоенными данному хосту.

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

B) Associate — создать ассоциацию

Формат

ASSOCIATE(local SCTP instance name, destination transport addr, outbound stream count) -> association id [,destination transport addr list] [,outbound stream count]

Этот примитив позволяет инициировать создание ассоциации с указанным партнёром.

Конечная точка партнёра по создаваемой ассоциации должна указываться одним из транспортных адресов данной точки (см. параграф 1.3). Если локальный экземпляр SCTP еще не был инициализирована, вызов ASSOCIATE рассматривается как ошибка.

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

При создании ассоциации могут возвращаться другие параметры ассоциации, включая полные транспортные адреса партнёра, а также счётчик исходящих потоков локальной точки. Один из транспортных адресов удалённого партнёра выбирается локальной точкой в качестве первичного (используемого по умолчанию) транспортного адреса для передачи пакетов этому партнёру. Возвращаемый список транспортных адресов партнёра (destination transport addr list) может использоваться ULP для смены первичного пути или задания передачи по определённому транспортному адресу партнёра.

Примечание для разработчиков. Если примитив ASSOCIATE реализован, как блокируемый вызов функции, он может возвращать кроме идентификатора ассоциации дополнительные параметры. Если примитив ASSOCIATE реализован как неблокируемый вызов, возвращается только идентификатор ассоциации, а параметры созданной ассоциации передаются с использованием уведомления COMMUNICATION UP.

Обязательные атрибуты

local SCTP instance name — возвращается операцией INITIALIZE.
destination transport addr — содержит один из транспортных адресов партнёра, с которым создаётся ассоциация.
outbound stream count — число исходящих потоков, которые ULP будет открывать для обмена данными с удаленным партнёром.

Необязательные атрибуты

Нет.

C) Shutdown — завершение ассоциации

Формат

SHUTDOWN(association id) -> результат

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP.

Необязательные атрибуты

Нет.

D) Abort — разрыв ассоциации

Формат

ABORT(association id [, cause code]) -> результат

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP.

Необязательные атрибуты

Upper Layer Abort Reason — причина разрыва ассоциации, передаваемая партнёру.

E) Send — передача данных

Формат

SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unorder flag] [,no-bundle flag] [,payload protocol-id] ) -> результат

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
buffer address — адрес, по которому сохраняется передаваемое пользовательское сообщение;
byte count — размер пользовательских данных в байтах.

Необязательные атрибуты

context — необязательное 32-битовое целое число, которое будет передаваться в уведомлении об отказе протоколу ULP, если при передаче пользовательского сообщения произойдёт ошибка;
stream id — идентификатор потока, используемого для передачи данных (по умолчанию используется поток 0);
life time — задаёт время жизни пользовательских данных. По истечении заданного времени SCTP уже не будет пытаться передавать эти данные. Параметр может использоваться для предотвращения передачи устаревших пользовательских сообщений. SCTP уведомляет ULP, если данные не удаётся передать с помощью SCTP в течение заданного этой переменной времени. Однако пользовательские данные будут передаваться, если протокол SCTP начал попытки передачи блока данных до истечения заданного времени.

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

destination transport address — задаёт один из транспортных адресов получателя, по которому пакет должен передаваться. По возможности протоколу SCTP следует использовать заданный адрес получателя вместо адреса первичного пути.
unorder flag — этот флаг указывает что пользовательские данные доставляются партнёру без соблюдения порядка (т. е., устанавливается флаг U = 1 во всех блоках DATA, содержащих это сообщение).
no-bundle flag — указывает протоколу SCTP, что эти данные не должны группироваться с другими передаваемыми блоками DATA. SCTP может выполнять в целях предотвращения перегрузки группировку блоков, игнорируя этот флаг.
payload protocol-id — 32-битовое целое число без знака, которое будет передаваться партнёру для индикации типа передаваемых данных. Это значение передаётся не обрабатывается протоколом SCTP.

F) Set Primary — выбор основного пути

Формат

SETPRIMARY(association id, destination transport address, [source transport address] ) -> результат

Задаёт для локальной точки SCTP использование указанного транспортного адреса в качестве первичного пути передачи пакетов.

Примитив должен возвращать результат попытки задания первичного пути. Если заданного адреса нет в списке destination transport address list, возвращённом ранее командой создания ассоциации или уведомлением COMMUNICATION UP, должен возвращаться код ошибки.

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
destination transport address — задаёт один из транспортных адресов партнёра для использования в качестве основного пути передачи пакетов. Это значение заменяет собой адрес первичного пути, поддерживавшегося до этого локальной точкой SCTP.

Необязательные атрибуты

source transport address — некоторые реализации могут поддерживать задание адреса отправителя, который будет по умолчанию включаться во все исходящие дейтаграммы IP.

G) Receive — приём данных

Формат

RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]

Этот примитив должен считывать первое пользовательское сообщение из входной очереди SCTP в буфер, указанный ULP, если такой буфер имеется. После выполнения команды возвращается размер прочитанных данных в байтах. В зависимости от реализации может также возвращаться такая информация, как адрес отправителя, идентификатор потока, из которого получены данные, сведения о наличии дополнительных данных для прочтения и т. п. Для упорядоченных сообщений может также возвращаться порядковый номер в потоке (Stream Sequence Number).

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
buffer address — адрес в памяти, указанный ULP для считывания сообщения;
buffer size — максимальный размер считываемых данных в байтах.

Необязательные атрибуты

stream id — для индикации потока, из которого были получены данные.
Stream Sequence Number — порядковый номер в потоке, присвоенный передающим партнёром. SCTP.
partial flag — наличие этого флага говорит о том, что данный вызов Receive возвращает часть данных из сообщения. Установка данного флага должна сопровождаться возвратом идентификатора потока и порядкового номера в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных³³.
payload protocol-id — 32-битовое целое число без знака, полученное от партнёра и указывающее тип данных в принятом сообщении. Значение этого параметра передаётся не обрабатывается протоколом SCTP.

H) Status — статус

Формат

STATUS(association id) -> данные о состоянии

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

состояние соединения для ассоциации;
список адресов транспортного уровня для получателя;
состояния доступности транспортных адресов получателя;
текущий размер окна приёма;
текущий размер окна насыщения;
число неподтвержденных блоков DATA;
число блоков DATA ожидающих приёма;
основной путь;
самое новое значение SRTT на основном пути;
значение RTO для основного пути;
значения SRTT и RTO для других путей и т. п.

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP.

Необязательные атрибуты

Нет.

I) Change Heartbeat — смена режима HeartBeat

Формат

CHANGEHEARTBEAT(association id, destination transport address, new state [,interval]) -> результат

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

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
destination transport address — один из транспортных адресов партнёра;
new state — новое состояние heartbeat для данного транспортного адреса (enabled или disabled).

Необязательные атрибуты

interval — этот параметр определяет частоту передачи heartbeat, если эта функция включена для транспортного адреса партнёра. Значение параметра добавляется к RTO транспортного адреса. Данный параметр действует для всех транспортных адресов получателя.

J) Request HeartBeat — запрос на выполнение HeartBeat

Формат

REQUESTHEARTBEAT(association id, destination transport address) -> результат

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
destination transport address — транспортный адрес, для которого запрашивается передача блока HEARTBEAT.

K) Get SRTT Report — запрос значения SRTT

Формат

GETSRTTREPORT(association id, destination transport address) -> результат srtt

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

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
destination transport address — транспортный адрес партнёра в данной ассоциации, для которого определяется значение SRTT.

L) Set Failure Threshold — задать порог детектирования отказа

Формат

SETFAILURETHRESHOLD(association id, destination transport address, failure threshold) -> результат

Этот примитив позволяет локальному модулю SCTP задать значение порога детектирования отказа Path.Max.Retrans для заданного транспортного адреса.

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
destination transport address — транспортный адрес партнёра в данной ассоциации, для которого задаётся порог;
failure threshold — новое значение параметра Path.Max.Retrans для заданного транспортного адреса.

M) Set Protocol Parameters — установить параметры протокола

Формат

SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list) -> результат

Этот примитив позволяет локальному модулю установить параметры протокола SCTP.

Обязательные атрибуты

association id — локальный идентификатор ассоциации SCTP;
protocol parameter list — список имён и значений протокольных параметров (например, Association.Max.Retrans), которые будут установлены для протокола SCTP (см. раздел 15).

Необязательные атрибуты

destination transport address — некоторые параметры протокола могут независимо устанавливаться для каждого транспортного адреса партнёра.

N) Receive unsent message — получить неотправленное сообщение

Формат

RECEIVE_UNSENT(data retrieval id, buffer address, buffer size [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

data retrieval id — идентификатор, передаваемый ULP в уведомлении об отказе.
buffer address — адрес буфера, указанный ULP для записи полученного сообщения.
buffer size — максимальный размер принимаемых данных в байтах.

Необязательные атрибуты

stream id — это возвращаемое значение указывает идентификатор потока, в который были переданы данные.
Stream Sequence Number — это возвращаемое значение указывает порядковый номер в потоке, связанный с сообщением.
partial flag — этот возвращаемый флаг указывает на частичную доставку сообщения. При установке этого флага должны также возвращаться идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных.
payload protocol-id — это 32-битовое целое число без знака, которое было передано для идентификации типа полученных данных.

O) Receive Unacknowledged Message — получить неподтвержденное сообщение

Формат

RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])

data retrieval id — идентификатор, передаваемый ULP в уведомлении об отказе.
buffer address — адрес буфера, указанный ULP для записи полученного сообщения.
buffer size — максимальный размер принимаемых данных в байтах.

Необязательные атрибуты

stream id — это возвращаемое значение указывает идентификатор потока, в который были переданы данные.
Stream Sequence Number — это возвращаемое значение указывает порядковый номер в потоке, связанный с сообщением.
partial flag — этот возвращаемый флаг указывает на частичную доставку сообщения. При установке этого флага должны также возвращаться идентификатор потока и порядковый номер в потоке. Нулевое значение флага показывает, что для данного порядкового номера в потоке больше не будет доставлено данных.
payload protocol-id — это 32-битовое целое число без знака, которое было передано для идентификации типа полученных данных.

P) Destroy SCTP instance — уничтожить экземпляр SCTP

Формат

DESTROY(local SCTP instance name)

local SCTP instance name — значение, переданное приложению из примитива инициализации; указывает уничтожаемый экземпляр SCTP.

10.2. SCTP -> ULP

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

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

A) уведомление DATA ARRIVE

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

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

association id — локальный идентификатор ассоциации SCTP;
stream id — идентификатор потока, в котором были получены данные.

B) уведомление SEND FAILURE

Если сообщение не может быть доставлено, протокол SCTP должен передать это уведомление ULP.

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

association id — локальный идентификатор ассоциации SCTP;
data retrieval id — идентификатор, используемый для считывание неотправленных или неподтвержденных данных;
cause code — указывает причину отказа (например, слишком большой размер сообщения, завершение срока жизни сообщения и т. п.);
context — дополнительная информация, связанная с сообщением (см. D в параграфе 10.1).

C) уведомление NETWORK STATUS CHANGE

Когда транспортный адрес получателя помечается, как неактивный (например, при детектировании отказа) или, наоборот, становится активным (например, при детектировании восстановления), протоколу SCTP следует передать такое уведомление ULP.

В уведомлении должна содержаться следующая информация:

association id — локальный идентификатор ассоциации SCTP;
destination transport address — указывает транспортный адрес партнёра для которого зафиксировано изменение состояния;
new-status — указывает новое состояние.

D) уведомление COMMUNICATION UP

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

Примечание для разработчиков. Если примитив ASSOCIATE реализован, как блокируемый вызов функции, параметры ассоциации возвращаются самим примитивом ASSOCIATE. В таких случаях на стороне инициатора ассоциации уведомления COMMUNICATION UP становятся необязательными.

В уведомлении должна содержаться следующая информация:

association id — локальный идентификатор ассоциации SCTP;
status — указывает тип события, с которым связано уведомление;
destination transport address list — полный набор транспортных адресов партнёра;
outbound stream count — максимальное число исходящих потоков, которые ULP может использовать в данной ассоциации;
inbound stream count — число потоков, запрошенных партнёром. (это значение может отличаться от outbound stream count).

E) уведомление COMMUNICATION LOST

Это уведомление должно передаваться протоколом SCTP в случае полной утраты связи с удалённой точкой (например, обнаруженной с помощью Heartbeat) или выполнения удалённой точкой операции прерывания ассоциации (abort).

В уведомлении должна содержаться следующая информация:

association id — локальный идентификатор ассоциации SCTP;
status — указывает тип события, с которым связано уведомление; этот параметр может говорить об отказе или обычном прекращении работы ассоциации с помощью запроса shutdown или abort.

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

data retrieval id — идентификатор, используемый для считывание неотправленных или неподтвержденных данных;
last-acked — последний номер TSN, подтверждённый партнёром.;
last-sent — последний номер TSN, переданный партнёру.
Upper Layer Abort Reason — причина прерывания указывается в случае разрыва по инициативе пользователя.

F) уведомление COMMUNICATION ERROR

Когда SCTP получает блок ERROR от своего партнёра и решает уведомить об ошибке ULP, этот тип служит для передачи уведомления.

Уведомление может включать следующие параметры:

association id — локальный идентификатор ассоциации SCTP;
error info — указывает тип ошибки и может содержать дополнительную информацию из блока ERROR.

G) уведомление RESTART

При обнаружении рестарта на стороне партнёра SCTP может использовать этот тип для передачи уведомления ULP.

Уведомление может включать следующие параметры:

association id — локальный идентификатор ассоциации SCTP.

H) уведомление SHUTDOWN COMPLETE

Это уведомление SCTP передаёт на вышележащий уровень при завершении процедуры (параграф 9.2).

Уведомление может включать следующие параметры:

association id — локальный идентификатор ассоциации SCTP.

11. Вопросы безопасности

11.1. Цели защиты

Для протокола транспортного уровня общего назначения, разработанных для гарантированной доставки чувствительной к задержкам информации (например, сигнальных сообщений телефонных систем или данных билинга) между парами точек сети важны следующие аспекты, связанные с безопасностью:

доступность сервиса с гарантией своевременной доставки;
целостность пользовательской информации, передаваемой через SCTP.

11.2. Реакция SCTP на потенциальные угрозы

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

Операторам систем, использующих SCTP следует использовать [RFC2196] в качестве руководства по обеспечению безопасности своего сайта.

11.2.1. Учёт возможности атак изнутри

Следует использовать принципы, изложенные в [RFC2196] для минимизации риска утечки информации или саботажа со стороны сотрудников. Такие процедуры включают публикацию политики безопасности, контроль доступа к оборудованию, программам и сети, а также разделение служб.

11.2.2. Защита от повреждения данных в сети

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

Можно использовать расширение SCTP-AUTH³⁴ [RFC4895], если среда с угрозами требует сильной защиты целостности, не требуя защиты конфиденциальности.

11.2.3. Защита конфиденциальности

В большинстве случаев вопросы конфиденциальности относятся к данным, передающим сигнальную информацию, а не к заголовкам SCTP или протоколов нижележащих уровней. В этом случае можно ограничиться шифрованием пользовательских данных SCTP. Как и дополнительные контрольные суммы, шифрование данных может выполняться пользовательским приложением SCTP. В дополнение к этому пользовательское приложение может использовать специфические для реализации API для запроса сервиса IP ESP³⁵ [RFC4303], обеспечивающего конфиденциальность и целостность.

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

При использовании ESP шифрование данных на прикладном уровне в общем случае не требуется.

Независимо от способа обеспечения конфиденциальности следует использовать механизмы IKEv2³⁶ [RFC4306] для управления ключами.

Операторам следует обратиться к [RFC4301] для получения дополнительной информации по средствам обеспечения безопасности непосредственно поверх уровня IP.

11.2.4. Защита от атак на службы вслепую (Blind DoS)

Атака вслепую представляет собой случай, когда атакующий не может перехватывать и просматривать содержимое потока данных, передаваемых узлу SCTP или от него. Атаки вслепую на службы могут иметь форму лавинной рассылки (flooding), маскирования (masquerade) или недозволенного монопольного захвата сервиса.

11.2.4.1. Лавинная атака (Flooding)

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

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

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

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

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

Механизмы IP AH и ESP могут также оказаться полезными для снижения риска при некоторых типах атак на службы.

Параметр Host Name в блоках INIT можно использовать для лавинной атаки на сервер DNS. Большое количество backlog-запросов к DNS для преобразования Host Name из блоков INIT в IP-адреса может быть вызвано передачей множества запросов INIT в один домен. Кроме того, атакующий может воспользоваться Host Name для непрямой атаки на сторонний сервер, рассылая большое число блоков INIT с именем хоста-жертвы по случайно выбранным адресам. Помимо увеличения нагрузки на DNS, такая атака может привести к генерации и передаче большого числа блоков INIT ACK по адресу атакуемого хоста. Одним из способов защиты от этого типа атак является проверка наличия в числе адресов IP, полученных от DNS, IP-адреса отправителя исходного блока INIT. Если список адресов IP, полученных от сервера DNS, не включает IP-адрес отправителя INIT, конечная точка может отбрасывать блок INIT без уведомления. Отметим, что эта мера не защищает от атак на DNS.

11.2.4.2. Слепое маскирование

Маскирование (Masquerade) может использоваться для атак на службы несколькими способами:

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

SCTP снижает риск атак с помощью слепого маскирования с подменой адресов (IP spoofing) за счёт использования четырехэтапного согласования при старте ассоциации. Маскирование с человеком в центре (Man-in-the-middle masquerade attack) рассматривается ниже в параграфе 11.3. Поскольку начальный обмен не запоминается, при атаках с маскированием вслепую нет возможности использования механизмов захвата. Кроме того, подтверждение INIT ACK, содержащее State Cookie, передаётся по адресу IP, с которого был получен блок INIT. Таким образом атакующий не получит блок INIT ACK, содержащий State Cookie. SCTP обеспечивает защиту от вставки дополнительных пакетов в поток данных существующей ассоциации за счёт использования тегов верификации (Verification Tag).

Протоколирование полученных запросов INIT и аномалий типа неожиданных блоков INIT ACK может быть полезно в целях обнаружения враждебных действий. Однако пользу от такого протоколирования нужно сопоставить с усложнением обработки при старте ассоциации SCTP, которое к тому же делает узел SCTP более уязвимым к лавинным атакам. Протоколирование не имеет смысла без создания рабочих процедур повседневного просмотра и анализа журнальных файлов.

11.2.4.3. Неправомерная монополизация

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

Следует вводить административные ограничения на число ассоциаций, создаваемых узлами. Пользовательским приложениям SCTP следует обеспечивать возможность детектирования передачи больших объёмов информации или сообщений no-op в данной ассоциации, а также другие механизмы протоколирования и разрыва ассоциаций в соответствии с принятой локальной политикой.

11.3. Взаимодействие SCTP с межсетевыми экранами

Для некоторых межсетевых экранов будет полезна возможность проверки первого фрагмента фрагментированного пакета SCTP и однозначного определения его соответствия блоку INIT (см. дополнительную информацию в [RFC1858]). Поэтому еще раз подчёркиваются требования, приведённые в параграфе 3.1, — (1) блок INIT недопустимо группировать с каким-либо другим блоком в одном пакете, (2) пакет с блоком INIT должен иметь Verification Tag = 0. Кроме того, проверка выполнения этих правил должна быть реализована на приёмной стороне с отбрасыванием блоков INIT, сгруппированных с другими блоками, или имеющих отличный от нуля тег верификации.

11.4. Защита хостов, не поддерживающих SCTP

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

Когда стек SCTP получает пакет, содержащий множество блоков (управление и DATA) и обработка такого пакета требует передачи в ответ множества блоков, отправителю этих блоков недопустимо передавать их более, чем в одном пакете. Если группировка блоков не поддерживается, отправителю недопустимо передавать более одного блока-отклика, а остальные он должен отбросить. Отметим, что это правило не применимо к блокам SACK, поскольку эти блоки сами по себе являются откликами на блоки DATA и SACK не требует передачи в ответ блоков DATA.

Реализациям SCTP следует прерывать ассоциацию при получении блока SACK с подтверждением номера TSN, который не был передан.

Реализация SCTP, получающая блок INIT, для отклика на который требуется большой пакет по причине включения в него множества параметров ERROR, может (по своему усмотрению) опустить часть или все параметры ERROR для снижения размера INIT ACK. С учётом размера параметра COOKIE и множества адресов, которые получатель INIT может указывать своему партнёру, размер блока INIT ACK может превышать размер исходного блока INIT. Реализациям SCTP следует предпринимать попытку максимального снижения размера блоков INIT ACK для снижения возможности организации «атак с усилением» (byte amplification attack).

12. Вопросы управления сетью

Модуль MIB для протокола SCTP, определённый в [RFC3873], применим для описанной здесь версии протокола.

13. Рекомендуемые параметры TCB

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

13.1. Параметры, требуемые для экземпляра SCTP

Associations — ассоциации

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

Secret Key — секретный ключ

Секретный ключ используется данной конечной точкой для расчёта MAC. В качестве ключа следует использовать случайное число криптографического качества и достаточной длины. Для выбора ключей могут быть полезны рекомендации RFC 4086.

Address List — список адресов

Список адресов IP, с которыми связан данный экземпляр. Эта информация передаётся партнёру в блоках INIT и INIT ACK.

SCTP Port — номер порта

Локальный номер порта, с которым связана конечная точка SCTP.

13.2. Параметры, требуемые для ассоциации в целом (например, TCB)

Peer Verification Tag

Значение тега партнёра, передаваемое в каждом пакете и полученное из блока INIT или INIT ACK.

My Verification Tag

Значение тега, ожидаемое в каждом входящем пакете и передаваемое партнёру в блоке INIT или INIT ACK.

State

Переменная, показывающая в каком состоянии находится ассоциация (COOKIE-WAIT, COOKIE-ECHOED, ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-SENT, SHUTDOWN-RECEIVED, SHUTDOWN-ACK-SENT).

Примечание. состояние CLOSED не указано в списке, поскольку для ассоциации в этом состоянии порядковый номер TCB следует удалять.

Peer Transport Address List

Список транспортных адресов SCTP, с которыми связан партнёр. Эта информация извлекается из блоков INIT или INIT ACK и используется для связывания входящих пакетов с данной ассоциацией. Обычно эта информация хэшируется или индексируется (keyed) для быстрого поиска и доступа к TCB.

Primary Path

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

Overall Error Count

Общий счётчик ошибок для всей ассоциации.

Overall Error Threshold

Значение количества ошибок для ассоциации, при достижении которого данная ассоциация будет разорвана.

Peer Rwnd

Текущее значение окна приёма (rwnd), рассчитанное для партнёра.

Next TSN

Значение следующего номера TSN, которое будет присвоено новому блоку DATA. Начальный номер передаётся партнёру в блоке INIT или INIT ACK и далее номер увеличивается каждый раз, когда блоку DATA выделяется значение TSN (обычно непосредственно перед передачей или в процессе фрагментации).

Last Rcvd TSN

Последний номер TSN, полученный с сохранением порядка. Начальное значение устанавливается на основе параметра Initial TSN, полученного от партнёра в блоке INIT или INIT ACK, путём вычитания 1 из полученного значения.

Mapping Array

Массив битов или байтов, показывающий, какие упорядоченных номеров TSN были получены (относительно Last Rcvd TSN). При отсутствии пропусков (т. е., все пакеты получены с сохранением порядка доставки), этот массив может содержать только нулевые значения. Эта структура может иметь форму кольцевого буфера или битового массива.

Ack State

Этот флаг показывает, будет ли передано подтверждение SACK при получении следующего пакета. Начальное значение равно 0. При получении пакета значение увеличивается на 1. При достижении значения 2 или более в ответ на получение пакета передаётся подтверждение SACK и значение снова сбрасывается в 0. Отметим, что описанный механизм используется лишь при отсутствии нарушений в порядке доставки блоков DATA. Если имеется нарушение порядка доставки DATA, подтверждения SACK не задерживаются (см. раздел 6).

Inbound Streams

Массив структур для отслеживания входящих потоков. Обычно данные о потоках включают следующий (ожидаемый) порядковый номер и могут включать номер потока.

Outbound Streams

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

Reasm Queue

Очередь сборки фрагментов.

Local Transport Address List

Список локальных адресов IP, связанных с данной ассоциацией.

Association PMTU

Наименьшее значение PMTU среди всех путей к партнёру.

13.3. Данные для каждого транспортного адреса

Для каждого транспортного адреса партнёра из списка, полученного в блоке INIT или INIT ACK, поддерживается группа параметров, включающая перечисленные ниже параметры.

Error count

Текущее значение счётчика ошибок для данного транспортного адреса.

Error Threshold

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

cwnd

Текущий размер окна насыщения.

ssthresh

Текущее значение порога Slow Start (ssthresh).

RTO

Текущее значение тайм-аута для повтора передачи.

SRTT

Текущее значение среднего времени кругового обхода.

RTTVAR

Изменение текущего значения RTT.

partial bytes acked

Метод слежения, используемый для увеличения размера cwnd в режиме предотвращения перегрузки (congestion avoidance, см. параграф 6.2.2).

state

Текущее состояние адресата (DOWN, UP, ALLOW-HB, NO-HEARTBEAT и т. п.).

PMTU

Текущее известное значение MTU для пути.

Per Destination Timer

Таймер, используемый для каждого адреса получателя.

RTO-Pending

Флаг, указывающий на то, что один из блоков DATA, переданных по этому адресу, в данный момент используется для расчёта RTT. Если флаг сброшен (0), ближайший блок DATA, отправляемый по этому адресу, следует использовать для расчёта RTT и установить данный флаг. При завершении расчёта RTT (получение подтверждения SACK для блока DATA) флаг сбрасывается.

last-time

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

13.4. Требуемые параметры общего назначения

Out Queue

Очередь исходящих блоков DATA.

In Queue

Очередь входящих блоков DATA.

14. Согласование с IANA

SCTP определяет три реестра, поддерживаемых агентством IANA:

типы блоков;
типы параметров;
коды причины ошибки в блоках ERROR.

Протокол SCTP требует создания в реестре IANA Port Numbers записи для порта SCTP, как описано в параграфе 14.5. Запросы на выделение номера порта SCTP поддержаны выделенным IESG экспертом.

14.1. Расширения для блоков, определяемые IETF

Выделение новых кодов для блоков SCTP (chunk type code) осуществляется в соответствии с процедурой IETF Consensus, определённой в [RFC2434]. Документация для блока должна включать:

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

Максимальный номер типа (255) зарезервирован для будущих расширений.

14.2. Определяемые IETF расширения для параметров блоков

Выделение новых кодов для параметров блоков SCTP (chunk parameter type code) осуществляется в соответствии с процедурой IETF Consensus, определённой в [RFC2434]. Документация для параметров блока должна включать:

полное и сокращённое имя типа параметра;
подробное описание структуры поля параметра, которое должно соответствовать базовому форматы TLV, определённому в параграфе 3.2.1;
подробное описание каждой компоненты значения параметра;
подробное описание предполагаемого использования этого типа параметра и возможности присутствия в одном блоке множества экземпляров данного параметра;
каждый тип параметров должен быть уникальным для всех блоков.

14.3. Определяемые IETF дополнительные коды причин ошибок

Дополнительные значения кодов ошибок могут выделяться из диапазона от 11 до 65535 в соответствии с процедурой Specification Required, определённой в [RFC2434]. Представляемая документация должна включать:

имя ошибки;
подробное описание условий, при которых конечной точке SCTP следует генерировать блок ERROR (или ABORT) с этим кодом ошибки;
ожидаемые действия конечной точки SCTP при получении блока ERROR (или ABORT) с этим кодом ошибки;
подробное описание структуры и содержимого полей данных, сопровождающих этот код.

Первое слово кода причина (32 бита) должно соответствовать формату, определённому в параграфе 3.3.10:

первые 2 байта содержат значение кода причины ошибки;
последние два байта указывают размер связанных с этим кодом параметров.

14.4. Идентификаторы протоколов (Payload)

За исключением значения 0, зарезервированного в SCTP для индикации неуказанного протокола в блоке DATA, протокол SCTP не отвечает за стандартизацию или проверку идентификаторов протоколов. SCTP просто получает идентификатор от вышележащего протокола и передаёт их с соответствующими элементами данных.

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

14.5. Реестр номеров портов

Службы SCTP могут использовать контактные номера портов для предоставления услуг незнакомым абонентам, как это делается в TCP и UDP. Следовательно, у агентства IANA запрашивается открытие существующего реестра Port Numbers для протокола SCTP с использованием приведённых ниже правил, которые предполагается согласовать с существующими процедурами регистрации номеров портов. Назначенные IESG эксперты поддерживают запрос в IANA на выделение портов SCTP в соответствии с процедурами, описанными в [RFC2434].

Номера портов делятся на три основных группы — общеизвестные порты (Well Known Port) используют номера от 0 до 1023, зарегистрированные порты (Registered Port) — от 1024 до 49151, а порты для динамического распределения и частного использования (Dynamic and/or Private Port) получают номера от 49152 до 65535. Общеизвестные и зарегистрированные порты предназначены для использования в серверных приложениях, где желательно иметь принятые по умолчанию точки контакта. В большинстве систем порты группы Well Known могут использоваться только системными (или root) процессами и программами, исполняемыми от имени привилегированных пользователей, а порты Registered могут использоваться обычными пользовательскими процессами и программами. Порты Dynamic и Private предназначены для временного использования (включая порты на клиентской стороне, согласованные по отдельным каналам порты и тестовые приложения до регистрации выделенных значений) и регистрировать их недопустимо.

Для реестра Port Numbers следует принимать запросы на регистрацию номеров из диапазонов Well Known и Registered. Такие номера портов не следует использовать без регистрации. Однако в некоторых случаях (например, при переносе приложений TCP на протокол SCTP) может оказаться разумным использование порта SCTP до завершения регистрации, но следует принимать во внимание, что IANA не гарантирует регистрацию конкретного номера порта. Следует начинать процедуру регистрации как можно раньше.

При каждой регистрации порта нужно представить перечисленные ниже сведения.

Краткое имя порта, состоящее целиком из букв (A-Z и a-z), цифр (0-9) и специальных символов «-_+./*» (без кавычек).
Запрашиваемый номер порта.
Краткое описание назначения порта на английском языке.
Имя и контактные данные ответственного за регистрация, а также (по возможности) ссылка на документ, определяющий использование порта. При регистрации от рабочих групп IETF достаточно просто указать название группы, но рекомендуется предоставлять и контактные данные.

Лицам, выполняющим процедуру регистрации нужно следовать приведённым ниже рекомендациям.

Одно имя порта не следует регистрировать для нескольких номеров портов SCTP.
Имя, зарегистрированное для протокола TCP, можно регистрировать и для SCTP. При таких регистрациях следует использовать тот же номер порта, который уже выделен для TCP.
Конкретное назначение порта следует определять до начала регистрации. Например, не следует регистрировать используемые в TCP номера портов заранее с целью какого-либо использования их в SCTP.

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

discard 9/sctp Discard # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Служба discard, которая воспринимает соединения SCTP на порту 9, отбрасывая все входящие данные приложений и не передавая ничего в ответ. Таким образом, порт SCTP discard является аналогом порта TCP discard и может применяться для проверки работоспособности стека SCTP. ftp-data 20/sctp FTP # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] ftp 21/sctp FTP # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Порты переноса данных (20) и управления (21) для протокола FTP. ssh 22/sctp SSH # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Служба защищённого удалённого доступа (SSH), которая обеспечивает защищённый вход в систему удалённых пользователей. http 80/sctp HTTP # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Протокол «всемирной паутины» (HTTP) на основе SCTP. bgp 179/sctp BGP # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Протокол внешней маршрутизации (BGP) на основе SCTP. https 443/sctp HTTPS # IETF TSVWG # Randall Stewart <rrs@cisco.com> # [RFC4960] Защищённый протокол «всемирной паутины» (HTTP поверх TLS/SSL) на основе SCTP.

15. Предлагаемые параметры протокола SCTP

Рекомендуется использовать следующие значения параметров протокола:

RTO.Initial — 3 секунды

RTO.Min — 1 секунда

RTO.Max — 60 секунд

Max.Burst — 4

RTO.Alpha — 1/8

RTO.Beta — 1/4

Valid.Cookie.Life — 60 секунд

Association.Max.Retrans — 10 попыток

Path.Max.Retrans — 5 попыток (для каждого адреса получателя)

Max.Init.Retransmits — 8 попыток

HB.interval — 30 секунд

HB.Max.Burst — 1

Примечание для разработчиков. Реализация SCTP может разрешать ULP изменение некоторых параметров протокола (см. раздел 10).

Примечание. Для RTO.Min следует использовать приведённое выше значение.

16. Благодарности

Представленный в этом документе протокол является серьёзным достижением, основанным на результатах работы авторов исходного RFC 2960 — Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson.

Кроме того, следует отметить всех, кто внес вклад в создание исходного RFC — Mark Allman, R.J. Atkinson, Richard Band, Scott Bradner, Steve Bellovin, Peter Butler, Ram Dantu, R. Ezhirpavai, Mike Fisk, Sally Floyd, Atsushi Fukumoto, Matt Holdrege, Henry Houh, Christian Huitema, Gary Lehecka, Jonathan Lee, David Lehmann, John Loughney, Daniel Luan, Barry Nagelberg, Thomas Narten, Erik Nordmark, Lyndon Ong, Shyamal Prasad, Kelvin Porter, Heinz Prantner, Jarno Rajahalme, Raymond E. Reeves, Renee Revis, Ivan Arias Rodriguez, A. Sankar, Greg Sidebottom, Brian Wyld, La Monte Yarroll и многие другие, кто дал свои значимые комментарии.

Добавим в этот список автором рекомендаций для разработчиков SCTP — I. Arias-Rodriguez, K. Poon, A. Caro и M. Tuexen.

Отметим усилия участников всех семи проверок интероперабельности SCTP и тех, кто представил комментарии к RFC 4460, как отмечено в этом документе — Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani и Ronnie Sellar.

Отдельная благодарность Mark Allman, который реально должен был стать соавтором работы по max-burst, но сумел уклониться по причине занятости. Благодарим также Lyndon Ong и Phil Conrad за их полезный вклад в работу.

Отметим также комментарии к заключительной версии документа от Alfred Hoenes и Ronnie Sellars.

Благодарность в адрес участников кодирования, тестирования и обновления документа непросто выразить словами. Спасибо Вам!

Randall Stewart — редактор.

Приложение A. Явное уведомление о перегрузке

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

Negotiation

[RFC3168] описывает согласование ECN на этапах SYN и SYN-ACK организации соединения TCP. Отправитель SYN устанавливает два бита в поле флагов TCP, а отправитель SYN-ACK — только 1 бит. Это сделано для того, чтобы убедиться в поддержке ECN на обеих сторонах соединения. Для протокола SCTP этого не требуется. Для индикации поддержки механизма ECN конечной точке следует добавить в блок INIT или INIT ACK структуру TLV, зарезервированную для ECN. TLV не включает параметров и имеет формат, показанный на рисунке.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter Type = 32768 | Parameter Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo

В соответствии с [RFC3168] получатель пакета устанавливает в передаваемом подтверждении специальный бит, который уведомляет отправителя CE³⁷ о получении информации. Для SCTP подобная индикация осуществляется с путем включения специального блока ECNE. Этот блок содержит единственный элемент данных — минимальный номер TSN, связанный с дейтаграммой IP, промаркированной битом CE, как показано на рисунке.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=12 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Примечание. ECNE рассматривается как управляющий блок (Control chunk).

CWR

В соответствии с [RFC3168] отправитель устанавливает специальный бит CWR³⁸ в заголовке следующего исходящего сегмента TCP для индикации снижения размера окна насыщения. Для SCTP такая индикация может обеспечиваться включением блока CWR. Этот блок содержит единственный элемент данных — номер TSN, который был передан в блоке ECNE. Этот элемент представляет наименьший номер TSN в дейтаграмме, которая была изначально помечена битом CE.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Chunk Type=13 | Flags=00000000| Chunk Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lowest TSN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Примечание. Блок CWR относится к числу управляющих блоков.

Приложение B. Расчет контрольной суммы CRC32c

Мы определяем «отраженное значение», как значение с порядком битов, обратным по отношению к используемому в машине. 32-битовое значение CRC³⁹ рассчитывается, как описано для CRC32c и использует полиномиальный код 0x11EDC6F41 (Castagnoli93) или x³²+x²⁸+x²⁷+x²⁶+x²⁵+x²³+x²²+x²⁰+x¹⁹+x¹⁸+x¹⁴+x¹³+x¹¹+x¹⁰+x⁹+x⁸+x⁶+x⁰. Значение CRC рассчитывается с помощью процедуры, похожей на ETHERNET CRC [ITU32], которая изменена с учетом применения на транспортном уровне.

Расчет CRC использует полиномиальное деление. Битовая строка сообщения (M) преобразуется в полином M(X) и значение CRC рассчитывается по M(X) с использованием полиномиальной арифметики.

При использовании CRC на канальном уровне полином строится с использованием естественного порядка битов — первый бит сигнала в линии является коэффициентов старшего порядка. Поскольку SCTP является протоколом транспортного уровня, он не может знать порядка передачи битов в физическую среду. Более того, на разных участках пути между конечными точками SCTP может на канальном уровне применяться разный порядок битов.

Следовательно, требуется соглашение для отображения транспортных сообщений SCTP на полиномы с целью расчета CRC. При отображении сообщений SCTP на полиномы сначала берется старший байт, но в каждом байте биты берутся, начиная с младшего. Первый байт сообщения обеспечивает восемь старших коэффициентов. В каждом байте младший бит SCTP дает самый старший коэффициент полинома в рамках данного байта, а старший бит SCTP — младший коэффициент в рамках байта (такой порядок иногда называют отраженным — mirrored или reflected [WILLIAMS93]). Полиномы CRC преобразуются обратно в значения байтов транспортного уровня SCTP с помощью соответствующего отображения.

Значение CRC для транспортного уровня SCTP следует рассчитывать в соответствии с приведенным ниже описанием.

Входными данными CRC является поток байтов с номерами 0 — N-1.
Байтовый поток транспортного уровня отображается на полиномиальное значение. PDU размером N байтов с номерами j от 0 до N-1 рассматривается, как коэффициенты полинома M(x) порядка 8N-1 и бит 0 байта j будет коэффициентом x^(8(N-j)-8), а бит 7 этого байта — x^(8(N-j)-1).
Оставшаяся часть регистра CRC заполняется единицами и рассчитывается значение CRC с помощью умножения на x³² и деления на полином CRC.
Полином умножается на x³² и делится на G(x), что порождает полином степени не более 31, образующий оставшуюся часть R(x).
Коэффициенты R(x) рассматриваются, как 32-битовая последовательность.
Последовательность битов дополняется и результат является полиномом CRC.
Полином CRC отображается обратно на байты транспортного уровня SCTP. Коэффициент x³¹ дает значение биты 7 в байте SCTP 0, а коэффициент x²⁴ дает значение бита 0 в байте 0. Коэффициент x⁷ дает значение бита 7 в байте 3, а коэффициент x⁰ — значение бита 0 в байте 3. Результирующая 4-байтовая последовательность является последовательностью транспортного уровня для 32-битовой контрольной суммы SCTP.

Примечание для разработчиков. В стандартах, книгах и литературе от производителей для CRC зачастую приводятся иные формулировки, где используется регистр для хранения остатка алгоритма деления long-division, инициализируемый нулями, а не 1 и первые 32 бита сообщения дополняются. Алгоритм long-division, используемый в нашей формулировке совмещает начальное умножение на 2³² и «длинное деление» в одной операции. Для таких алгоритмов и сообщений, размер которых превышает 64 бита, две спецификации полностью эквивалентны. Обеспечение эквивалентности является одной из целей данного документа.

Следует предупредить разработчиков SCTP о том, что в литературе можно найти обе спецификации и иногда без ограничений для алгоритма long-division. Выбор формулировки в этом документе обусловлен возможностью применения не только для SCTP, когда тот же алгоритм CRC может применяться для сообщений меньше 64 битов.

Можно несколько снизить вычислительные издержки, проверяя ассоциацию по значению Verification Tag до расчета контрольной суммы, чтобы не рассчитывать контрольные суммы для пакетов с некорректными тегами. Исключением из этого правила являются блоки INIT и некоторые обмены SHUTDOWN-COMPLETE, а также устаревшие блоки COOKIE ECHO. Однако в этих случаях пакеты достаточно малы и расчет контрольных сумм не требует значительных ресурсов.

Приложение C. Обработка ICMP

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

Реализация может игнорировать все сообщения ICMPv4, где поле типа отлично от Destination Unreachable.
Реализация может игнорировать все сообщения ICMPv6, где поле типа отлично от Destination Unreachable, Parameter Problem, и Packet Too Big.
Реализация может игнорировать все сообщения ICMPv4, где код отличается от Protocol Unreachable и Fragmentation Needed.
Реализация может игнорировать все сообщения ICMPv6 типа Parameter Problem, если код отличен от Unrecognized Next Header Type Encountered.
Реализация должна использовать данные из сообщений ICMP (v4 или v6) для определения ассоциации, отправившей сообщение, в ответ на которое получен отклик ICMP. Если такой ассоциации не найдено, сообщение ICMP следует игнорировать.
Реализация должна удостовериться, что значение Verification Tag в сообщении ICMP соответствует верификационному тегу партнера. Если значение Verification отлично от нуля и не совпадает с тегом партнера, сообщение ICMP отбрасывается. Если тег имеет значение 0 и сообщение ICMP содержит достаточно байтов для проверки того, что блок имел тип INIT и значение Initiate Tag соответствует тегу партнера, выполняется п. ICMP7. Если сообщение ICMP слишком коротко, тип блока иной или значение Initiate Tag не совпадает, пакет отбрасывается без уведомления.
Если сообщение ICMP является v6 Packet Too Big или v4 Fragmentation Needed, реализация может обработать информацию, как указано для определения PATH MTU.
Если код ICMP указывает Unrecognized Next Header Type Encountered или Protocol Unreachable, реализация должна трактовать такое сообщение, как разрыв ассоциации с установленным флагом T, если оно не содержит блок INIT. Если блок INIT включен и ассоциация находится в состоянии COOKIE-WAIT, сообщение ICMP обрабатывается подобно блоку ABORT.
Если сообщение ICMPv6 имеет код Destination Unreachable, реализация может пометить адресата, как недоступного, а также увеличить значение счетчика ошибок для пути.

Отметим, что эти процедуры отличаются от [RFC1122] и приведенных там требований к обработке сообщений о недоступности порта, а также требования о том, что реализация должна прерывать ассоциацию в ответ на сообщение о недоступности протокола (protocol unreachable). Сообщения о недоступности портов не обрабатываются, поскольку реализации будут передавать блок ABORT, а не сообщение о недоступности порта. Более строгая обработка сообщений о недоступности протокола обусловлена вопросами защиты для хостов, не поддерживающих SCTP.

Ниже приведен (ненормативный) пример кода, заимствованный из генератора CRC с открытым кодом [WILLIAMS93], использующего метод «отражения» и таблицу для SCTP CRC32c с 256 записями по 32 бита в каждой. Этот метод не слишком быстрый и не слишком медленный по сравнению с поиском в таблицах CRC, но его преиуществом является возможность работы с процессами, использующими порядок big-endian и little-endian, при просмотре общих таблиц (с хост-порядком), а также использование лишь предопределенных операций ntohl() и htonl(). Код несколько отличается от [WILLIAMS93] для обеспечения переносимости между архитектурами big-endian и little-endian (отметим, что в тех случаях, когда известно, что целевая архитектура использует порядок little-endian, финальные операции bit-reversal и byte-reversal могут быть объединены).

/*************************************************************/ /* Для генератора таблиц Ross Williams устанавливаются */ /* значения TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */ /* Для прямого расчета Mr. Williams используются значения */ /* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */ /* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */ /*************************************************************/ /* Пример файла с таблицей crc */ #ifndef __crc32cr_table_h__ #define __crc32cr_table_h__ #define CRC32C_POLY 0x1EDC6F41 #define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF]) unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L, 0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L, 0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, }; #endif /* Пример программы построения таблицы */ #include <stdio.h> #include <stdlib.h> #define OUTPUT_FILE «crc32cr.h» #define CRC32C_POLY 0x1EDC6F41L FILE *tf; unsigned long reflect_32 (unsigned long b) { int i; unsigned long rw = 0L; for (i = 0; i < 32; i++){ if (b & 1) rw |= 1 << (31 — i); b >>= 1; } return (rw); } unsigned long build_crc_table (int index) { int i; unsigned long rb; rb = reflect_32 (index); for (i = 0; i < 8; i++){ if (rb & 0x80000000L) rb = (rb << 1) ^ CRC32C_POLY; else rb <<= 1; } return (reflect_32 (rb)); } main () { int i; printf («\nGenerating CRC-32c table file <%s>\n», OUTPUT_FILE); if ((tf = fopen (OUTPUT_FILE, «w»)) == NULL){ printf («Unable to open %s\n», OUTPUT_FILE); exit (1); } fprintf (tf, «#ifndef __crc32cr_table_h__\n»); fprintf (tf, «#define __crc32cr_table_h__\n\n»); fprintf (tf, «#define CRC32C_POLY 0x%08lX\n», CRC32C_POLY); fprintf (tf, «#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n»); fprintf (tf, «\nunsigned long crc_c[256] =\n{\n»); for (i = 0; i < 256; i++){ fprintf (tf, «0x%08lXL, «, build_crc_table (i)); if ((i & 3) == 3) fprintf (tf, «\n»); } fprintf (tf, «};\n\n#endif\n»); if (fclose (tf) != 0) printf («Unable to close <%s>.» OUTPUT_FILE); else printf («\nThe CRC-32c table has been written to <%s>.\n», OUTPUT_FILE); } /* Пример вставки crc */ #include «crc32cr.h» unsigned long generate_crc32c(unsigned char *buffer, unsigned int length) { unsigned int i; unsigned long crc32 = ~0L; unsigned long result; unsigned char byte0,byte1,byte2,byte3; for (i = 0; i < length; i++){ CRC32C(crc32, buffer[i]); } result = ~crc32; /* в result храниться «негативный» остаток полинома, * поскольку таблица и алгоритм являются «зеркальными [williams95]. * Т. е., result имеет такое же значение, как будто мы отобразили сообщение * на полином, рассчитали остаток полинома для хостового порядка битов * выполнили финальную смену знака (negation) и сквозное обращение битов. * Отметим, что 32-битовое обращение битов идентично 4 восьмибитовым обращениям * с последующим обращением порядка байтов. На машинах little-endian * такое обращение байтов и финальная операция ntohl cancel не нужны. */ byte0 = result & 0xff; byte1 = (result>>8) & 0xff; byte2 = (result>>16) & 0xff; byte3 = (result>>24) & 0xff; crc32 = ((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | byte3); return ( crc32 ); } int insert_crc32(unsigned char *buffer, unsigned int length) { SCTP_message *message; unsigned long crc32; message = (SCTP_message *) buffer; message->common_header.checksum = 0L; crc32 = generate_crc32c(buffer,length); /* and insert it into the message */ message->common_header.checksum = htonl(crc32); return 1; } int validate_crc32(unsigned char *buffer, unsigned int length) { SCTP_message *message; unsigned int i; unsigned long original_crc32; unsigned long crc32 = ~0L; /* сохраним и обнулим контрольную сумму */ message = (SCTP_message *) buffer; original_crc32 = ntohl(message->common_header.checksum); message->common_header.checksum = 0L; crc32 = generate_crc32c(buffer,length); return ((original_crc32 == crc32)? 1 : -1); }

Литература

Нормативные документы

[ITU32] «ITU-T Recommendation V.42, «Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion».», ITU-T section 8.1.1.6.2.

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC1123] Braden, R., Ed., «Requirements for Internet Hosts — Application and Support», STD 3, RFC 1123, October 1989.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC1982] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, August 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC2581] Allman, M., Paxson, V., and W. Stevens, «TCP Congestion Control», RFC 2581, April 1999.

[RFC3873] Pastor, J. and M. Belinchon, «Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)», RFC 3873, September 2004.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4306] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC4821] Mathis, M. and J. Heffner, «Packetization Layer Path MTU Discovery», RFC 4821, March 2007.

Дополнительная литература

[FALL96] Fall, K. and S. Floyd, «Simulation-based Comparisons of Tahoe, Reno, and SACK TCP», SIGCOMM’99 V. 26 N. 3 pp 5-21, July 1996.

[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, «TCP Congestion Control with a Misbehaving Receiver», ACM Computer Communications Review 29(5), October 1999.

[ALLMAN99] Allman, M. and V. Paxson, «On Estimating End-to-End Network Path Properties», SIGCOMM’99 , 1999.

[WILLIAMS93] Williams, R., «A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS», Internet publication, http://www.geocities.com/SiliconValley/Pines/8659/crc.htm, August 1993.

[RFC0813] Clark, D., «Window and Acknowledgement Strategy in TCP», RFC 813, July 1982.

[RFC1858] Ziemba, G., Reed, D., and P. Traina, «Security Considerations for IP Fragment Filtering», RFC 1858, October 1995.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[RFC2196] Fraser, B., «Site Security Handbook», FYI 8, RFC 2196, September 1997.

[RFC2522] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, March 1999.

[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, «Stream Control Transmission Protocol», RFC 2960, October 2000.

[RFC3309] Stone, J., Stewart, R., and D. Otis, «Stream Control Transmission Protocol (SCTP) Checksum Change», RFC 3309, September 2002.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, «Stream Control Transmission Protocol (SCTP) Specification Errata and Issues», RFC 4460, April 2006.

[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, «Authenticated Chunks for Stream Control Transmission Protocol (SCTP)», RFC 4895, August 2007.

Адрес редактора

Randall R. Stewart

4875 Forest Drive

Suite 200

Columbia, SC 29206

EMail: rrs@cisco.com

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

1Stream Control Transmission Protocol.

2Public Switched Telephone Network — коммутируемая телефонная сеть общего пользования. Прим. перев.

3Максимальный размер передаваемых пакетов. Прим. перев.

4Имеющих множество сетевых интерфейсов. Прим. перев.

5Denial of service attack.

6Connection-oriented.

7Explicit Congestion Notification.

8Type-Length-Value — Тип-Размер-Значение.

9Блоки INIT могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

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

11Поле ECN capable зарезервировано для будущего использования с ECN.

12Недопустимо включение в блок INIT более 1 параметра Host Name Address. Более того, для отправителя блока INIT недопустимо комбинировать в блоке INIT любые другие типы адресов с Host Name Address. Получатель блока INIT должен игнорировать адреса всех остальных типов при наличии в блоке INIT параметра Host Name Address.

13Блоки INIT ACK могут содержать множество адресов IPv4 и/или IPv6 в произвольных комбинациях.

14Поле ECN capable зарезервировано для будущего использования с ECN.

15Недопустимо включение в блок INIT ACK более 1 параметра Host Name Address. Более того, для отправителя блока INIT ACK недопустимо комбинировать в блоке INIT ACK любые другие типы адресов с Host Name Address. Получатель блока INIT должен игнорировать адреса всех остальных типов при наличии в блоке INIT ACK параметра Host Name Address.

16Человек в центре атаки — тип атак, в которых используются интеллектуальные средства перехвата и подмены пакетов. Прим. перев.

17Атаки с подменой порядковых номеров.

18Silly window syndrome — синдром неразумного окна.

19Advertised Receiver Window Credit — анонсированное окно приема.

20Retransmission timeout — тайм-аут для повтора.

21Smoothed round-trip time — усредненное время кругового обхода.

22Round-trip time variation — вариации времени кругового обхода.

23Path MTU.

24Receiver advertised window size.

25Congestion control window. Для краткости будем называть его просто окном насыщения. Прим. перев.

26Slow-start threshold.

27Highest TSN Newly Acknowledged — максимальный недавно подтвержденный номер.

28Maximum transmission unit.

29Максимальное число повторов передачи для ассоциации.

30Максимальное число повторов для пути.

31Heartbeat period.

32Out of the blue — совершенно неожиданный.

33Сообщение прочитано целиком. Прим. перев.

34SCTP Authentication — аутентификация SCTP.

35Encapsulating Security Payload.

36Internet Key Exchange.

37Congestion Experienced.

38Congestion Window Reduced — окно насыщения уменьшено.

39Cyclic Redundancy Check.

Рубрика: RFC | Комментарии отключены

RFC 4861 Neighbor Discovery for IP version 6 (IPv6)

Опубликовано 30.09.2007 автором Nikolai Malykh

Network Working Group                                          T. Narten
Request for Comments: 4861                                           IBM
Obsoletes: 2461                                              E. Nordmark
Category: Standards Track                               Sun Microsystems
                                                              W. Simpson
                                                              Daydreamer
                                                              H. Soliman
                                                    Elevate Technologies
                                                          September 2007

Обнаружение соседей IPv6

Neighbor Discovery for IP version 6 (IPv6)

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.

Аннотация

Этот документ задаёт протокол обнаружения соседей (Neighbor Discovery) для IP версии 6. Узлы IPv6 на одном канале используют Neighbor Discovery для обнаружения присутствия других узлов, определения их адресов канального уровня, поиска маршрутизаторов и поддержки информации о доступности путей к активным соседям.

1. Введение

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

Если не указано иное (в документе, описывающем работу IP на конкретном типе каналов), этот документ применим ко всем типам каналов. Однако, поскольку ND использует групповую адресацию канального уровня для некоторых своих служб, возможно, что для некоторых типов каналов (например, NBMA²) будут заданы дополнительные протоколы или механизмы, реализации этих услуг (в документе, описывающем работу IP на конкретном типе каналов). Описанные в документе службы, которые не зависят напрямую от групповой адресации (типа Redirect, определения Next-hop, Neighbor Unreachability Detection и т. п), предполагаются соответствующими этому документу. Детали использования ND на каналах NBMA рассмотрены в [IPv6-NBMA]. В дополнение к этому в [IPv6-3GPP] и [IPv6-CELL] рассмотрено использование протокола на некоторых каналах сотовой связи, которые относятся к типу NBMA.

2. Терминология

2.1. Общие термины

Протокол IP версии 6. В тех случаях, когда требуется различать версии, применяются обозначения IPv4 и IPv6.

ICMP

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

node — узел

Устройство, реализующее протокол IP.

router — маршрутизатор

Узел, которые пересылает пакеты, не адресованные явно ему.

host — хост

Любой узел, не являющийся маршрутизатором.

upper layer — вышележащий уровень

Протокольный уровень, расположенный непосредственно над IP. Примерами могут служить транспортные протоколы типа TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации типа OSPF, а также протоколы уровня Internet (или ниже) «туннелируемые» через IP (т. е. инкапсулируемые в IP) типа IPX³, AppleTalk или самого IP.

link — канал, соединение

Линия связи или среда, через которую узлы могут взаимодействовать на канальном уровне (уровень, непосредственно ниже IP). Примерами являются Ethernet (простая сеть или с мостами), Token Ring, каналы PPP, сети X.25, Frame Relay или ATM, туннели уровня Internet (или выше) типа туннелей IPv4 или IPv6.

interface — интерфейс

Подключение узла к каналу.

neighbor — сосед

Узел, подключенный к тому же каналу.

address — адрес

Идентификатор уровня IP для интерфейса или набора интерфейсов.

anycast address

Идентификатор для множества интерфейсов (обычно относящихся к разным узлам). Пакет, переданный по адресу anycast доставляется одному из интерфейсов, указанных этим адресом («ближайшему» в соответствии с мерой удалённости протокола маршрутизации). См. [ADDR-ARCH].

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

prefix — префикс

Начальные биты адреса или набор адресов IP, начальные биты которых совпадают.

link-layer address — адрес канального уровня

Идентификатор интерфейса на канальном уровне. Примеры включают адреса IEEE 802 для каналов Ethernet.

on-link — подключён к каналу

Адрес, назначенный интерфейсу на конкретном канале. Узел считается подключённым к каналу (on-link), при выполнении любого из условий:

- адрес входит в один из префиксов канала (например, как указано флагом on-link в опции Prefix Information);
- соседний маршрутизатор указывает адрес в качестве получателя сообщения Redirect;
- получено сообщение Neighbor Advertisement для (целевого) адреса;
- получено любое сообщение Neighbor Discovery с этого адреса.

off-link — не подключён к каналу

Антитеза on-link. Адрес, не назначенный какому-либо из интерфейсов заданного канала.

longest prefix match — максимальное соответствие префикса

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

reachability — доступность, достижимость

Наличие (или отсутствие) корректно работающего одностороннего пути «пересылки» к соседу. В частности, доступность означает, что переданный соседу пакет доставляется на уровень IP соседней машины и соответствующим образом обрабатывается принимающим уровнем IP. Для соседнего маршрутизатора доступность означает, что пакеты, переданные IP-уровнем узла доставляются уровню IP маршрутизатора и маршрутизатор действительно пересылает пакеты (т. е. настроен как маршрутизатор, а не хост). Для хостов доступность означает, что пакеты, отправленные IP-уровнем узла доставляются IP-уровню соседнего хоста.

packet — пакет

Заголовок IP и данные (payload).

link MTU — MTU для канала

Максимальный размер блока (пакета), который может быть в один приём передан через канал (в октетах).

target — цель

Адрес, для которого отыскивается информация о преобразовании, или адрес который будет новым первым интервалом пересылки при перенаправлении.

proxy — прокси, посредник

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

ICMP destination unreachable indication — индикация ICMP о недоступности получателя

Индикация ошибки, возвращённая исходному отправителю пакета, который не удалось доставить по причинам, указанным в [ICMPv6]. Если ошибка возникает на узле, не являющемся инициатором пакета, генерируется сообщение ICMP об ошибке. Если ошибка возникает на узле-инициаторе, генерация и отправка сообщения ICMP об ошибке источнику не требуется, если отправитель вышележащего уровня уведомляется с помощью другого подходящего механизма (например, возврат кода ошибки вызванной процедурой). Следует отметить, что реализация может счёт удобным в некоторых случаях возвращать ошибку отправителю, беря вызвавший ошибку пакет, генерируя сообщение ICMP и затем доставляя его (локально) с использованием базовых процедур обработки ошибок.

random delay — случайная задержка

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

random delay seed — «затравка» для случайной задержки

Если при расчёте случайной задержки используется генератор псевдослучайных чисел, этот генератор следует инициализировать с использованием уникальной «затравки» (seed) до начала использования. Отметим, что использования в качестве значения затравки идентификатора интерфейса не достаточно, поскольку эти идентификаторы не всегда уникальны. Для снижения вероятности использования одинаковой затравки её значение должно определяться на основе данных из разных источников (например, компонент машины), которые с большой вероятностью будут различаться в разных устройствах. Например, затравку можно создавать из комбинации серийного номера CPU и идентификатора интерфейса. Дополнительную информацию о генерации случайных значений можно найти в [RAND].

2.2. Типы каналов

Свойства разных канальных уровней различаются. Ниже перечислены свойства, связанные с Neighbor Discovery.

multicast capable — поддержка групповой адресации

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

point-to-point — «точка-точка»

Канал, соединяющий лишь два интерфейса. Предполагается, что канал «точка-точка» поддерживает групповую адресацию и имеет локальный (link-local) адрес.

non-broadcast multi-access (NBMA) — множественный доступ без широковещания

Канал, к которому может быть подключено два и более интерфейсов, но не поддерживается естественное широковещание или групповая адресация (например, X.25, ATM, Frame Relay и т. п.). Предполагается, что все типы каналов (включая NBMA) поддерживают услуги групповой адресации для приложений, которым это нужно (например, с помощью multicast-серверов). Однако до конца не решён вопрос, следует ли ND использовать такие возможности или дополнительные механизмы, обеспечивающие эквивалентную поддержку групповой адресации для ND.

shared media — общая среда

Канал, который обеспечивает возможность прямых коммуникаций между множеством устройств, но подключённые узлы настроены так, что они не имеют полной информации о префиксах всех подключённых к каналу адресатов. Т. е. на уровне IP узлы одного канала могут не знать, что они являются соседями и по умолчанию связываются между собой через маршрутизатор. Примерами являются большие (коммутируемые) сети передачи данных общего пользования типа SMDS⁴ и B-ISDN⁵. Такие сети называют также «большими облаками» (large cloud, см. [SH-MEDIA]).

variable MTU — переменный размер MTU

Канал, для которого нет общеизвестного значения MTU (например, IEEE 802.5 Token Ring). Многие каналы (например, Ethernet) имеют стандартное значение MTU, определяемое протоколом канального уровня, или отдельным документом, определяющим работу IP на основе данного канального уровня.

asymmetric reachability — асимметричная доступность

Канал, в котором несимметричная и/или непереходная доступность (связность) является нормальным состоянием. Асимметрия доступности означает, что пакеты проходят от A к B, но не проходят в обратном направлении. Непереходная доступность означает, что пакеты проходят от A к B и от B к C, но не проходят от A к C. Такими свойствами отличаются радиоканалы.

2.3. Адреса

При обнаружении соседей используется множество разных адресов, определённых в [ADDR-ARCH], включая перечисленные ниже.

Групповой адрес all-nodes

Адрес с локальной значимостью для доступа ко всем узлам — FF02::1.

Групповой адрес all-routers

Адрес с локальной значимостью для доступа ко всем маршрутизаторам — FF02::2.

Групповой адрес solicited-node

Групповой адрес с локальной значимостью, который определяется как функция адреса запрошенной цели. Функция описана в [ADDR-ARCH] и выбирается так, что адреса IP, различающиеся только старшими битами (например, при наличии множества префиксов от разных провайдеров), будут отображаться на один адрес solicited-node, что снижает число групповых адресов, которые узел должен присоединить на канальном уровне.

Адрес link-local (локальный)

Индивидуальный адрес с локальной значимостью, который может использоваться для доступа к соседям. Все интерфейсы маршрутизаторов должны иметь адреса link-local. Документ [ADDRCONF] требует наличия таких адресов и у интерфейсов хоста.

Незаданный адрес

Зарезервированное значение, которое указывает отсутствие адреса (например, он не известен). Это значение никогда не используется в качестве адреса получателя, но может служить адресом отправителя, если тот (ещё) не знает своего адреса (например, при проверке незанятости адреса при автоматической настройке конфигурации без учёта состояния [ADDRCONF]). Этот адрес имеет значение 0:0:0:0:0:0:0:0.

Отметим, что данная спецификация не следует строго требованиям согласованности [ADDR-SEL] для области действия адресов получателя и отправителя. В некоторых случаях хосты могут использовать адрес отправителя с большей областью действия, чем у адреса получателя в заголовке IPv6.

2.4. Требования

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [KEYWORDS].

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

3. Обзор протокола

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

Router Discovery — обнаружение маршрутизаторов

Способ обнаружения хостом маршрутизаторов, подключённых к каналу.

Prefix Discovery — обнаружение префиксов

Способ обнаружения хостом набора префиксов, определяющего адреса на подключённом канале (on-link). Узлы применяют префиксы, чтобы отличить адресатов на канале от доступных лишь через маршрутизатор.

Parameter Discovery — определение параметров

Способ определения узлом параметров канала (типа MTU) или Internet (типа значения hop limit) для учёта в исходящих пакетах.

Address Autoconfiguration — автоматическая настройка адресов

Механизмы, требуемые для того, чтобы позволить узлам настраивать адрес для интерфейса без учёта состояния. Спецификация автоматической настройки без учёта состояния приведена в [ADDRCONF].

Address resolution — распознавание адресов

Определение адреса канального уровня для получателя на том же канале (например, соседа) по его IP-адресу.

Next-hop determination — определение следующего интервала

Алгоритм отображения IP-адреса получателя на IP-адрес соседа, которому следует пересылать трафик для получателя. Следующим интервалом (next-hop) может быть маршрутизатор или сам получатель.

Neighbor Unreachability Detection (NUD) — обнаружение недоступности соседа

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

Duplicate Address Detection (DAD) — детектирование дубликатов адресов

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

Redirect — перенаправление

Способ информирования маршрутизатором хоста о лучшем первом интервале пересылки (first-hop) для определённого адресата.

Neighbor Discovery определяет 5 различных типов пакетов ICMP — пары Router Solicitation и Router Advertisement, Neighbor Solicitation и Neighbor Advertisement, а также Redirect.

Router Solicitation (RS) — запрос маршрутизатора

Когда интерфейс включается, хост может передавать сообщения Router Solicitation, запрашивающие у маршрутизаторов генерацию анонса RA раньше запланированного времени.

Router Advertisement (RA) — анонс маршрутизатора

Маршрутизаторы анонсируют своё присутствие вместе с различными параметрами каналов и Internet периодически или в ответ на сообщение Router Solicitation. Сообщения RA содержат префиксы, которые используются для проверки, использует ли другой адрес тот же канал (определение on-link) и/или конфигурацию адреса, определения предложенного значения hop limit и т. п..

Neighbor Solicitation (NS) — запрос соседства

Передаётся узлом для определения соседского адреса канального уровня или проверки доступности соседа по кэшированному адресу канального уровня. Сообщения NS служат также для обнаружения дубликатов адресов (Duplicate Address Detection или DAD).

Neighbor Advertisement (NA) — анонс соседа

Отклик на сообщение Neighbor Solicitation. Узел может также передавать незапрошенные сообщения Neighbor Advertisement для анонсирования смены адреса канального уровня.

Redirect — перенаправление

Используется маршрутизаторами для информирования хостов о наилучшем первом интервале пересылки для адресата.

На каналах с поддержкой групповой адресации каждый маршрутизатор периодически отправляет групповой пакет RA, анонсирующий его доступность. Хост, получивший RA от всех маршрутизаторов, создаёт список используемых по умолчанию маршрутизаторов. Маршрутизаторы генерируют RA достаточно часто, чтобы хосты узнавали о присутствии маршрутизатора в течение нескольких минут, но недостаточно часто для детектирования отказов по отсутствию анонсов. Для обнаружения отказов применяется специальный алгоритм обнаружения недоступности соседа (NUD).

Анонс маршрутизатора содержит список префиксов, используемых для определения принадлежности к каналу и/или автономной настройки адресов. Связанные с префиксом флаги задают предполагаемое использование конкретного префикса. Хосты применяют анонсированные для канала префиксы для создания и поддержки списка, применяемого при решении вопроса о присутствии адресата на данном канале или за маршрутизатором. Отметим, что адресат может относиться к данному каналу даже в случае, когда анонсируемый префикс не включает его. В таких случаях маршрутизатор может передать Redirect для информирования отправителя о том, что адресат является соседом.

Анонсы маршрутизаторов и флаги префиксов в них позволяют маршрутизаторам информировать хосты о способах автоматической настройки адресов (Address Autoconfiguration). Например, маршрутизатор может указывать хостам использование DHCPv6 и/или автономную настройку адресов (без учёта состояния).

Сообщение RA содержит также параметры Internet, такие как максимальное число интервалов пересылки (hop limit), которое хосту следует указывать в исходящих пакетах, и (необязательно) параметры канала, такие как MTU. Это упрощает централизованное администрирование важных параметров, которые маршрутизаторы могут задавать и распространять автоматически всем подключённым хостам.

Узлы распознают адреса путём групповой передачи сообщений NS, запрашивающих у соседей их адреса канального уровня. Сообщения NS передаются по групповому адресу solicited-node целевых узлов. Эти узлы возвращают свои адреса канального уровня в сообщениях NA. Одной пары пакетов «запрос-отклик» инициатору и цели достаточно для того, чтобы узнать адрес канального уровня другой стороны. Инициатор включает свой адрес канального уровня в сообщение NS. Сообщения NS могут также применяться для обнаружения дубликатов индивидуальных адресов, как описано в [ADDRCONF].

Механизм NUD обнаруживает отказы соседей или пути пересылки к ним. Для этого требуются подтверждения доставки пакетов соседу и их подобающей обработки уровнем IP у этого соседа. NUD использует подтверждения из двух источников. Когда это возможно, протоколы вышележащих уровней подтверждают, что соединение обеспечивает пересылку (forward progress), т. е. отправленные данные были корректно доставлены, например, отправляя подтверждения о доставке пакетов. Когда подтверждений через такие «подсказки» нет, узел передаёт индивидуальные сообщения NS, которые запрашивают отправку NA в качестве подтверждения доступности от следующего узла пересылки (next hop). Для снижения уровня трафика пробные сообщения передаются лишь соседям, которым узел активно передаёт пакеты.

Помимо решения отмеченных выше задач ND обслуживает перечисленные ниже ситуации.

Смена адреса канального уровня

Узел, знающий о смене своего адреса канального уровня может передать несколько (незапрошенных) групповых пакетов NA всем узлам для быстрого обновления кэшированного адреса, который изменился. Отметим, что отправка незапрошенных анонсов служит лишь повышению производительности (не является надёжной), а алгоритм NUD обеспечивает надёжное обнаружение нового адреса, хотя задержка может быть больше.

Балансировка нагрузки на входе

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

ND позволяет маршрутизатору распределять нагрузку для адресованного ему трафика, разрешая опускать адрес отправителя на канальном уровне в пакетах RA, что вынуждает использовать сообщения NS для определения адресов маршрутизаторов на канальном уровне. Возвращаемые сообщения NA могут тогда содержать адреса канального уровня, которые различаются, например, в зависимости от инициатора запроса. Эта спецификация не задаёт механизмов, позволяющих хостам распределять нагрузку для входящих пакетов (см. [LD-SHRE]).

Anycast-адреса

Anycast-адрес указывает один из набора узлов, обеспечивающих эквивалентные услуги или настраиваемых так, что они способны распознаваться по одному anycast-адресу. ND обрабатывает anycast в предположении получения множества NA для одной цели. Все анонсы anycast-адресов помечаются как non-Override (без переопределения) и не обновляют (не заменяют) информацию, переданную в других анонсах. Эти анонсы далее обсуждаются в контексте сообщений NA. Это вызывают определённые правила для выбора используемых анонсов из числа имеющихся.

Прокси-анонсы

Узел, желающий воспринимать пакеты от имени целевого адреса, не способного отвечать на сообщения NS, может выдавать NA без переопределения. Прокси-анонсы применяются домашними агентами Mobile IPv6 для защиты адреса мобильного устройства при его уходе с канала. Однако это не предназначено для использования в качестве механизма общего назначения, для обработки узлов, которые, например, не реализуют этот протокол.

3.1. Сравнение с IPv4

Протокол обнаружения соседей IPv6 ND соответствует комбинации протоколов IPv4 ARP⁶ [ARP], ICMP Router Discovery [RDISC] и ICMP Redirect [ICMPv4]. В IPv4 нет единого протокола или механизма обнаружения недоступности соседа (NUD), хотя в документе Hosts Requirements [HR-CL] указаны возможные алгоритмы обнаружения «мёртвых» шлюзов (Dead Gateway Detection), решающего часть этих задач.

Протокол обнаружения соседей обеспечивает множество улучшений по сравнению с набором протоколов IPv4.

Router Discovery является частью базового протокола и хостам не нужно «влезать» в протоколы маршрутизации.

Сообщения RA содержат адрес канального уровня и не требуется дополнительного обмена пакетами для определения адреса маршрутизатора на канальном уровне.

Сообщения RA содержат префикс для канала, поэтому не нужен отдельный механизм настройки маски сети.

Сообщения RA позволяют автоматически настраивать адреса (Address Autoconfiguration).

Маршрутизаторы могут анонсировать хостам значение MTU на канале, что позволяет всем узлам использовать одно значение MTU на каналах без чётко заданного MTU.

Групповые рассылки распознавания адресов «разбросаны» по 16 миллионам (2²⁴) групповых адресов, что существенно сокращает связанные с распознаванием адресов прерывания на узлах, не являющихся целью. Кроме того, машины, не относящиеся к IPv6 не получают таких прерывания совсем.

Сообщения Redirect включают адрес канального уровня для нового первого узла пересылки (first hop) и не требуется специально распознавать адрес.

С одним каналом может быть связано множество префиксов. По умолчанию хост узнает все префиксы на канале из сообщений RA. Однако на маршрутизаторах можно задать исключение части или всех префиксов из RA. В таких случаях хосты предполагают, что адресаты находятся вне канала (off-link) и передают трафик маршрутизаторам. При необходимости маршрутизатор может выдавать сообщения Redirect.

В отличие от IPv4, получатель IPv6 Redirect предполагает, что новый следующий узел пересылки (next-hop) находятся на канале. В IPv4 хост игнорирует перенаправления, задающие next-hop вне канала, в соответствии с настроенной для канала маской сети. Механизм перенаправления в IPv6 похож на функцию Xredirect, заданную в [SH-MEDIA]. Предполагается, что он будет полезен на каналах с общей средой без широковещания, где узлам нежелательно или невозможно знать все префиксы, находящихся на канале адресатов.

Обнаружение недоступности соседей является частью базового протокола, что значительно повышает надёжность доставки пакетов в случае отказов маршрутизаторов, частичных отказов или разделения каналов и смены узлами адресов канального уровня. Например, мобильные узлы могут уходить с канала без потери связности в результате устаревания кэша ARP.

В отличие от ARP, протокол ND обнаруживает отказы «полуканалов» (с помощью NUD) и позволяет избежать отправки трафика соседям, с которыми нет двухсторонней связности.

Поле предпочтений в RA не требуется для работы с маршрутизаторами, различающимися «стабильностью»; NUD обнаружит «мёртвые» маршрутизаторы и переключит на работающие.

Использование адресов link-local для однозначной идентификации маршрутизаторов (в сообщениях RA и Redirect) позволяет хостам поддерживать связь с маршрутизаторами в случаях смены сайтом глобального префикса.

Установка Hop Limit 255 делает ND защищённым от отправителей вне канала (off-link), случайно или преднамеренно передающих сообщения ND. В IPv4 такие отправители могут передавать сообщения ICMP Redirect и RA.

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

3.2. Поддерживаемые типы каналов

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

Соединения «точка-точка»

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

Групповая адресация

ND работает по каналам с поддержкой групповой адресации в соответствии с этим декрементом.

Каналы с множественным доступом без широковещания (NBMA)

Redirect, NUD и определение next-hop следует реализовать в соответствии с этим документом. Распознавание адресов и механизмы доставки сообщений RS и RA на каналах NBMA не заданы в этом документе. Отметим, что хост с возможностью настройки вручную списка используемых по умолчанию маршрутизаторов может динамически получать адреса канального уровня своих соседей из сообщений Redirect.

Общая среда

Сообщение Redirect создано на основе XRedirect в [SH-MEDIA] для упрощения использования протокола на каналах с общим доступом. Эта спецификация не решает для сред с общим доступом вопросов, связанных с маршрутизаторами:

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

Протокол является расширяемым (новые опции) и в будущем могут быть предложены новые решения.

Переменное значение MTU

ND позволяет маршрутизаторам задавать значение MTU для канала, которое будут применять узлы. Для корректной работы групповой рассылки все узлы на канале должны использовать одно значение MTU (или MRU⁷), иначе отправитель, который может не знать, какие узлы получат пакет, не сможет определить размер пакета, который способны обработать все получатели (MRU).

Асимметричная доступность

ND обнаруживает отсутствие симметричной доступности и узел будет избегать пути к соседу, с которым у него нет двухсторонней связности. Механизм NUD обычно будет обнаруживать такие «полусоединения» и узел сможет воздержаться от их использования. Предполагается, что в будущем протокол может быть расширен для поиска жизнеспособных путей в средах без возвратной и переходной связности.

3.3. Защита сообщений Neighbor Discovery

Сообщения ND нужны для решения разных задач. Некоторые функции предназначены для обеспечения хостам возможности заявлять о владении адресом или сопоставлением адреса канального уровня с адресом IP. Связанные с ND уязвимости рассмотрены в параграфе 11.1. Общее решение по защите ND выходит за рамки этой спецификации и рассмотрено в [SEND]. Однако в параграфе 11.2 рассматривается возможность применения протоколов IPsec Authentication Header (AH) и Encapsulating Security Payload (ESP) для защиты Neighbor Discovery.

4. Формат сообщений

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

4.1. Формат сообщения RS

Хост передаёт сообщения с запросом маршрутизатора (Router Solicitation или RS), приглашающие маршрутизаторы быстро создать свои анонсы (Router Advertisement или RA).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

IP-адрес передающего интерфейса или незаданный (unspecified) адрес при отсутствии адреса на интерфейсе.

Destination Address

Обычно групповой адрес all-routers (все маршрутизаторы).

Hop Limit

255

Поля ICMP

Type

133

Code

Checksum

Контрольная сумма ICMP [ICMPv6].

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Допустимые опции

Source link-layer address

Адрес отправителя на канальном уровне, если он известен. Этот адрес недопустимо включать, если в поле Source Address содержится неуказанный адрес. В остальных случаях поле следует включать для канальных уровней с адресами.

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

4.2. Формат сообщения RA

Маршрутизаторы передают свои анонсы (Router Advertisement или RA) периодически и в ответ на запросы RS.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reachable Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Retrans Timer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Опции ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

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

Destination Address

Обычно это поле Source Address из соответствующего сообщения RS или групповой адрес all-nodes.

Hop Limit

255

Поля ICMP

Type

134

Code

Checksum

Контрольная сумма ICMP [ICMPv6].

Cur Hop Limit

8-битовое целое число без знака, указывающее принятое по умолчанию значение, которое следует помещать в поле Hop Count заголовка IP исходящих пакетов. 0 соответствует незаданному (этим маршрутизатором) значению.

Флаг управляемой настройки адресов, установка которого указывает, что адреса доступны по протоколу DHCP [DHCPv6]. При установленном флаге M флаг O становится избыточным и может игнорироваться, поскольку DHCPv6 будут возвращать все доступные данные конфигурации.

Флаг дополнительной конфигурации, установка которого указывает доступность по протоколу DHCPv6 других конфигурационных данных. Примерами таких данных являются сведения о DNS или других серверах в сети.

Примечание. Если оба флага M и O сброшены, это говорит о недоступности данных по протоколу DHCPv6.

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Router Lifetime

16-битовое целое число без знака, указывающее срок действия принятого по умолчанию маршрутизатора в секундах. Поле может содержать значение до 65535 и получателям следует обрабатывать любые значения, хотя правила отправки в разделе 6 ограничивают срок действия 9000 секунд. Значение 0 указывает, что маршрутизатор не используется по умолчанию и его не следует включать в соответствующий список. Значение Router Lifetime указывает лишь применимость маршрутизатора по умолчанию и не относится к данным, содержащимся в других полях и опциях сообщения. Опции с ограниченным сроком действия имеют свои поля срока действия.

Reachable Time

32-битовое целое число без знака, указывающее срок, в течение которого сосед считается доступным после приёма подтверждения доступности (в миллисекундах). Значение применяется алгоритмом NUD (7.3. Алгоритм NUD). 0 указывает, что значение не задано этим маршрутизатором.

Retrans Timer

32-битовое целое число без знака, указывающее интервал между сообщениями NS в миллисекундах, используемый алгоритмом NUD (см. 7.2. Распознавание адресов и 7.3. Алгоритм NUD). 0 указывает, что значение не задано этим маршрутизатором.

Возможные опции

Source link-layer address

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

MTU

Следует передавать для каналов с переменным MTU (как указано в документе, описывающем применение IP для канального уровня). Может передаваться в другие каналы.

Prefix Information

Задаёт префиксы, относящиеся к каналу и,или используемые для автоматической настройки адресов без учёта состояния. Маршрутизатору следует включать все свои префиксы on-link (за исключением префикса link-local), чтобы многодомные хосты имели полные сведения об адресатах, связанных с каналом, куда они подключены. При отсутствии полной информации хост с несколькими интерфейсами не сможет корректно выбрать выходной интерфейс для передачи трафика своим соседям.

4.3. Формат сообщения NS

Узлы передают запросы соседства (Neighbor Solicitation или NS) для получения адреса канального уровня целевого узла, а также указания тому своего адреса на канальном уровне. Сообщения NS являются групповыми, когда узлу нужно распознать адрес, и индивидуальными при проверке узлом доступности соседа.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Target Address                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Опции ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

Адрес передающего сообщение интерфейса или незаданный адрес (при использовании DAD [ADDRCONF]).

Destination Address

Групповой адрес solicited-node, соответствующий адресу цели, или адрес самой цели.

Hop Limit

255

Поля ICMP

Type

135

Code

Checksum

Контрольная сумма ICMP [ICMPv6].

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Target Address

IP-адрес цели запроса. Указание группового адреса недопустимо.

Возможные опции

Source link-layer address

Адрес канального уровня для отправителя. Опцию недопустимо включать, если IP-адрес отправителя не задан. В иных случаях при наличии адресов канального уровня эта опция должна включаться в групповые запросы и её следует включать в индивидуальные запросы.

4.4. Формат сообщения NA

Узел передаёт анонсы соседства (Neighbor Advertisement или NA) в ответ на сообщения NS, а также передаёт незапрошенные NA для быстрого распространения новой информации (без гарантии).

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O|                     Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Target Address                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

Адрес передающего сообщение интерфейса.

Destination Address

Для запрошенных анонсов — Source Address из соответствующего сообщения NS или групповой адрес all-nodes, если в Source Address содержится неуказанный адрес. Для незапрошенных анонсов — обычно групповой адрес all-nodes.

Hop Limit

255

Поля ICMP

Type

136

Code

Checksum

Контрольная сумма ICMP [ICMPv6].

Флаг, установка которого говорит, что отправитель является маршрутизатором. Флаг R применяет механизм NUD для обнаружения перехода маршрутизатора в статус хоста.

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

Флаг переопределения, установка которого указывает, что анонсу следует переопределить имеющуюся кэш-запись и обновить кэшированный адрес канального уровня. При сброшенном флаге анонс не будет обновлять кэшированный адрес канального уровня, но обновит имеющуюся запись NCE⁸, для которой известен адрес канального уровня. Флаг не следует устанавливать в запрошенных анонсах для адресов anycast и в запрошенных прокси-анонсах, в остальных случаях флаг следует устанавливать.

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Target Address

Для запрошенных анонсов это поле Target Address из соответствующего NS, для незапрошенных — адрес, для которого изменился адрес канального уровня. В поле Target Address недопустимо указывать групповой адрес.

Возможные опции

Target link-layer address

Адрес канального уровня для цели, т. е. отправителя анонса. Эта опция должна включаться для канальных уровней с адресацией при отклике на групповые запросы, а также следует включать её в отклики на индивидуальные NS. Опция должна включаться для групповых запросов во избежание «бесконечной» рекурсии NS, когда у партнерского узла нет кэшированной записи для возврата в сообщении NA. При откликах на индивидуальные запросы опцию можно опускать, поскольку у отправителя запроса имеется корректный адрес канального уровня (без него тот не смог бы отправить индивидуальный запрос). Однако включение адреса канального уровня в таких случаях не ведёт к чрезмерным издержкам и избавляет от возможных проблем при удалении отправителем кэшированного адреса канального уровня до получения отклика на запрос.

4.5. Формат сообщения Redirect

Маршрутизаторы передают сообщения Redirect для информирования хоста о лучшем первом узле пересылки (first-hop) на пути к адресату. Хосты могут перенаправляться на более подходящий маршрутизатор или получать сведения о том, что адресат является соседом. Последнее обеспечивается установкой в поле ICMP Target Address значения ICMP Destination Address.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Target Address                          +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                     Destination Address                       +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

Поля IP

Source Address

Должно содержать адрес link-local, назначенный передающему сообщение интерфейсу.

Destination Address

Source Address из пакета, вызвавшего сообщение о перенаправлении.

Hop Limit

255

Поля ICMP

Type

137

Code

Checksum

Контрольная сумма ICMP [ICMPv6].

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Target Address

IP-адрес лучшего следующего узла пересылки для использования в ICMP Destination Address. Если целью является фактическая конечная точка (адресат является соседом), поле должно содержать значение, поля ICMP Destination Address. В иных случаях целью является наиболее подходящий маршрутизатор first-hop и поле должно содержать адрес link-local этого маршрутизатора, по которому хост может однозначно идентифицировать его.

Destination Address

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

Возможные опции

Target link-layer address

Адрес канального уровня для цели, который следует включать (если он известен). Отметим, что на каналах NBMA хосты могут применять опцию Target Link-Layer Address в сообщениях Redirect как способ определения адреса соседа на канальном уровне. В таких случаях опция должна включаться в сообщения Redirect.

Redirected Header

Максимально возможная часть пакета IP, вызвавшего отправку Redirect, без превышения перенаправленным пакетом минимального значения MTU, заданного в [IPv6].

4.6. Формат опций

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                              ...                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

8-битовый идентификатор типа опции. Определённые в этом документе опции приведены в таблице.

Имя опции	Тип
Source Link-Layer Address	1
Target Link-Layer Address	2
Prefix Information	3
Redirected Header	4
MTU	5

Length

8-битовое целое число без знака, указывающее размер опции (все поля) в 8-октетных словах. Значение 0 недействительно и узлы должны отбрасывать без уведомления отправителя пакеты ND с опцией размера 0.

4.6.1. Адрес канального уровня отправителя или цели

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |    Link-Layer Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1 для Source Link-layer Address, 2 для Target Link-layer Address.

Length

Размер опции (все поля) в 8-октетных словах. Например, размер адреса IEEE 802 составляет 1 [IPv6-ETHER].

Link-Layer Address

Поле переменного размера с адресом канального уровня. Содержимое поля, включая порядок битов и байтов, задано в документах, описывающих IPv6 для соответствующего канального уровня, например, [IPv6-ETHER].

Опция Source Link-Layer Address содержит адрес канального уровня для отправителя пакета и применяется в пакетах NS, RS и RA. Опция Target Link-Layer Address содержит адрес канального уровня для цели и применяется в пакетах NA и Redirect. В остальных сообщениях ND эти опции должны игнорироваться.

4.6.2. Информация о префиксе

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     | Prefix Length |L|A| Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Valid Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Preferred Lifetime                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved2                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                            Prefix                             +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Prefix Length

8-битовое целое число без знака, указывающее число действительных начальных битов поля Prefix (0 — 128). Это поле обеспечивает сведения для определения принадлежности к каналу (в комбинации с флагом L), а также помогает при автоматической настройке адресов [ADDRCONF], где могут быть ограничения на размер префикса.

Флаг присутствия на канале, указывающий, что этот префикс может служить для определения принадлежности к каналу. При сброшенном флаге анонс ничего не говорит о принадлежности префикса к каналу. Иными словами, если флаг L сброшен, хосту недопустимо считать, что выведенный из префикса адрес не относится к каналу (off-link), т. е. недопустимо обновлять прежнюю индикацию принадлежности адреса к каналу (on-link).

Флаг автономной настройки адреса, установка которого указывает возможность применения префикса для настройки адресов без учёта состояния, как задано в [ADDRCONF].

Reserved1

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Valid Lifetime

32-битовое целое число без знака, указывающее срок действия префикса для определения принадлежности к каналу (в секундах с момента отправки пакета). Значение, содержащее только 1 (0xffffffff), указывает неограниченный срок действия. Значение Valid Lifetime используется также в [ADDRCONF].

Preferred Lifetime

32-битовое целое число без знака, указывающее срок (в секундах с момента отправки пакета), в течение которого адрес, созданный из префикса процедурой автоматической настройки адресов без учёта состояния [ADDRCONF], остаётся предпочтительным. Значение, содержащее только 1 (0xffffffff), указывает неограниченный срок. В этом поле недопустимы значения больше Valid Lifetime, чтобы недействительный адрес на стал предпочтительным.

Reserved2

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

Prefix

IP-адрес или префикс IP. Поле Prefix Length указывает число действительных начальных битов префикса. Биты, расположенные после, должны устанавливаться в 0 отправителем и игнорироваться получателем. Маршрутизатору не следует передавать префикс для link-local, а хостам следует игнорировать такие опции.

Опция Prefix Information предоставляет хостам относящиеся к каналу префиксы и префиксы для автоматической настройки адресов. Опция применяется в пакетах RA и должна игнорироваться в других сообщениях.

4.6.3. Заголовок перенаправления

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       IP header + data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Размер опции в 8-октетных словах.

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

IP header + data

Исходный пакет, усечённый так, чтобы размер перенаправленного сообщения не превышал минимальное значение MTU требуемое для поддержки IPv6 [IPv6].

Опция Redirected Header применяется в сообщениях Redirect и содержит весь или часть пакета, который перенаправляется. Опция должна игнорироваться в других сообщениях ND.

4.6.4. MTU

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              MTU                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Reserved

Резервное поле, которое должно устанавливаться отправителем в 0, а получатель должен игнорировать поле.

MTU

32-битовое целое число без знака, указывающее рекомендуемое для канала значение MTU.

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

В конфигурациях, где с помощью мостов собраны разнородные технологии, максимальное значение MTU может меняться от сегмента к сегменту. Если мосты не создают сообщений ICMP Packet Too Big, взаимодействующие узлы не смогут применять Path MTU для динамического определения подходящего MTU по каждому соседу. В таких случаях можно настроить маршрутизаторы на использование опции MTU для задания максимального значения MTU, поддерживаемого всеми сегментами.

5. Концептуальная модель хоста

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

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

5.1. Концептуальные структуры данных

Хост будет поддерживать для каждого интерфейса указанную ниже информацию.

Neighbor Cache — кэш соседей

Набор записей об отдельных соседях, которым недавно передавался трафик. Записи привязаны к относящимся к каналу индивидуальным IP-адресам соседа и содержат такие данные, как адрес канального уровня, флаг, указывающий, является сосед маршрутизатором или хостом (IsRouter в этом документе), указатель на пакеты в очереди, ожидающие распознавания адреса и т. п. Запись NCE может также включать сведения, используемые алгоритмом NUD, включая статус доступности, число безответных проб и время, но которое запланировано следующее событие NUD.

Destination Cache — кэш адресатов

набор записей об адресатах, которым недавно отправлялся трафик. Записи относятся к адресатам на канале и вне его и обеспечивают уровень косвенных обращений к кэшу соседей — кэш адресатов сопоставляет IP-адреса получателей с IP-адресами соседа next-hop. Этот кэш обновляется сведениями из сообщений Redirect. Разработчики могут счесть удобным размещение в кэше дополнительных данных, не связанных напрямую с ND, например Path MTU (PMTU) и время кругового обхода от транспортных протоколов.

Prefix List — список префиксов

Список префиксов, определяющих набор адресов на канале. Записи списка создаются из данных в сообщениях RA и каждая из них имеет таймер аннулирования (извлекается из анонса RA), используемый для объявления префикса недействительным по завершении срока действия. Специальное значение infinity указывает неограниченный срок действия префикса, пока не будет получено новое (конечное) значение в другом анонсе.

Префиксы link-local считаются включёнными в список с бесконечным сроком действия независимо от анонсирования этих префиксов маршрутизаторами. Полученным анонсам RA не следует менять значение таймера аннулирования для префиксов link-local.

Default Router List — список заданных по умолчанию маршрутизаторов

Список маршрутизаторов, которым могут передаваться пакеты. Записи списка указывают записи в кэше соседей. Алгоритм выбора принятого по умолчанию маршрутизатора отдаёт предпочтение маршрутизаторам, которые были доступны, по отношению к тем, чья доступность вызывает сомнения. Каждая запись имеет время аннулирования (извлекается из анонса), используемое для удаления записей, которые больше не анонсируются.

Отметим, что упомянутые выше концептуальные структуры данных можно реализовать разными способами. Одним из возможных вариантов является использование одной таблицы маршрутизации по максимальному совпадению для всех указанных структур. Независимо от конкретной реализации очень важно, чтобы запись Neighbor Cache для маршрутизатора совместно использовалась всеми записями Destination Cache, использующими этот маршрутизатор, для предотвращения избыточных проб NUD.

Концептуальные структуры данных могут добавлять и другие протоколы (например, Mobile IPv6). Реализация свободна в выборе и организации таких структур. Например, можно объединить все концептуальные структуры в одну таблицу маршрутизации.

Neighbor Cache содержит сведения, поддерживаемые алгоритмом NUD. Важнейшей частью сведений является состояние доступности соседа, которое может принимать одно из 5 значений, кратко описанных ниже и формально определённых в параграфе 7.3.2.

INCOMPLETE

Происходит распознавание адреса и адрес соседа на канальном уровне ещё не определён.

REACHABLE

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

STALE

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

DELAY

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

PROBE

О доступности соседа больше не известно и ему передано индивидуальное сообщение NS для проверки.

5.2. Концептуальный алгоритм передачи

При отправке пакета адресату узел использует комбинацию Destination Cache, Prefix List и Default Router List для определения IP-адреса следующего узла (операция next-hop determination). Когда IP-адрес следующего узла определён выполняется обращение к Neighbor Cache для определения адреса канального уровня.

Для определения следующего узла отправитель выполняет поиск по максимальному совпадению префиксов в Prefix List, чтобы понять, находится ли получатель пакета на канале. Если получатель подключён к каналу, адресом next-hop будет адрес самого получателя, иначе отправитель выбирает маршрутизатор из списка Default Router List, следуя правилам параграфа 6.3.6. Выбор принятого по умолчанию маршрутизатора.

Из соображений эффективности определение next-hop не происходит для каждого передаваемого пакета и вместо этого результат поиска сохраняется в Destination Cache (кэш включает также обновления из сообщений Redirect). Когда у отправителя есть пакет для передачи, он сначала проверяет Destination Cache и лишь при отсутствии кэшированных данных вызывает процедуру определения next-hop для создания записи в Destination Cache.

Когда IP-адрес next-hop известен, отправитель проверяет Neighbor Cache для поиска адреса соседа на канальном уровне. Если записи нет, отправитель создаёт запись с состоянием INCOMPLETE, инициирует распознавание адреса и помещает пакет данных в очередь ожидания адреса. Для интерфейсов с поддержкой групповой адресации распознавание адреса состоит из отправки сообщения NS и ожидания отклика NA. При получении NA адрес канального уровня включается в NCE и пакет из очереди передаётся. Механизм распознавание адресов описан в параграфе 7.2.

Для групповых пакетов next-hop всегда является (групповым) адресом получателя и считается находящимся на канале. Процедуры определения адреса канального уровня, соответствующего групповому адресу IP, описаны в отдельных документах, посвящённых работе IP с конкретными канальными уровнями (например, [IPv6-ETHER]).

При каждом обращении к NCE для передачи индивидуального пакета отправитель проверяет данные о доступности соседа по алгоритму NUD (7.3. Алгоритм NUD). Результатом такой проверки может стать передача отправителем индивидуального сообщения NS для проверки доступности соседа.

Определение next-hop выполняется при первой отправке трафика адресату. Пока связь с этим адресатом продолжается успешно, применяется запись Destination Cache. Если в какой-то момент связь прерывается по данным алгоритма NUD, процедуру определения next-hop потребуется повторить. Например, трафик через отказавший маршрутизатор придётся перенести на другой маршрут. Точно также может перенаправляться трафик мобильного узла к другому «агенту мобильности». При повторном определении next-hop узлом не требуется полностью отбрасывать запись Destination Cache. Обычно полезно сохранять такие сведения, как PMTU и значения таймера кругового обхода.

Маршрутизаторы и многодомные хосты имеют несколько интерфейсов. Далее в документе предполагается, что все передаваемые и принимаемые сообщения ND относятся к контексту соответствующего интерфейса. Например, при ответе на RS сообщение RA передаётся через интерфейс, принявший запрос.

5.3. Сборка мусора и тайм-ауты

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

Для ограничения размеров хранилища кэшей адресатов и соседей узлу может потребоваться сборщик мусора. Однако следует позаботиться о наличии в хранилище места для хранения рабочего набора активных записей. Слишком малый размер кэша может приводить к отправке избыточного числа сообщений ND, если записи приходится часто отбрасывать и восстанавливать. Любая политика на основе LRU⁹, восстанавливающая лишь записи, которые не использовались некоторое время (например, 10 минут и более), обеспечит адекватный сбор мусора.

Узлу следует сохранять записи в Default Router List и Prefix List до истечения срока действия, однако возможна упреждающая сборка мусора при нехватке памяти. Если не все маршрутизаторы хранятся в списке Default Router, узлу следует сохранять по меньшей мере 2 записи в Default Router List (предпочтительно больше) для обеспечения отказоустойчивой связности с узлами вне канала (off-link).

При удалении записи из Prefix List не требуется удалять какие-либо записи в кэше адресатов или соседей, NUD эффективно очищает все недействительные записи. Однако при удалении записи из Default Router List для всех записей Destination Cache, включающих соответствующий маршрутизатор, придётся повторить определение next-hop для выбора нового маршрутизатора, используемого по умолчанию.

6. Обнаружение маршрутизаторов и префиксов

В этом разделе описано поведение маршрутизаторов и хостов, связанное с обнаружением маршрутизаторов (Router Discovery) в ND. Обнаружение маршрутизаторов служит для отыскания соседних маршрутизаторов, а также выяснения префиксов и параметров конфигурации, связанных с автоматической настройкой адресов без учёта состояния.

Процесс обнаружения префиксов (Prefix Discovery) позволяет хостам узнать диапазоны адресов IP, относящихся к каналу и доступных напрямую без маршрутизаторов. Маршрутизаторы передают сообщения RA, указывающие, что их отправитель готов служить принятым по умолчанию маршрутизатором. Эти сообщения также включают опции Prefix Information со списком префиксов для адресов IP на канале (on-link).

Для автоматической настройка адресов без учёта состояния (Stateless Address Autoconfiguration) также нужны префиксы подсетей. Хотя используемые для автоматической настройки адресов префиксы логически отличаются от применяемых для определения принадлежности к каналу, данные для автоматической настройки адресов также включаются в сообщения Router Discovery для снижения объёма трафика. На самом деле одни и те же префиксы могут анонсироваться для определения принадлежности к каналу и автоматической настройки адресов путём установки соответствующих флагов в опциях Prefix Information. Автоматическая настройка адресов описана в [ADDRCONF].

6.1. Проверка сообщений

6.1.1. Проверка сообщения RS

Хосты должны отбрасывать без уведомления все принятые сообщения RS. Маршрутизаторы должны отбрасывать без уведомления все принятые сообщения RS, которые не соответствуют всем приведённым ниже требованиям:

поле IP Hop Limit имеет значение 255, т. е. пакет не может пересылаться маршрутизатором;
поле ICMP Checksum действительно;
ICMP Code = 0;
размер ICMP (выводится из размера IP) не менее 8 октетов;
все включённые опции имеют ненулевой размер;
если IP-адресом отправителя является незаданный адрес, в сообщении нет адреса отправителя на канальном уровне.

Поле Reserved и все нераспознанные опции должны игнорироваться. Будущие совместимые изменения протокола могут задавать иное применение поля Reserved и новые опции, в несовместимых изменениях может применяться другое значение Code. Содержимое любых опций, для которых не указано включение в сообщения RS, должно игнорироваться с сохранением обычной обработки сообщения. В настоящее время для RS указана лишь опция Source Link-Layer Address. Прошедшие проверку запросы считаются действительными (valid solicitation).

6.1.2. Проверка сообщений RA

Узел должен отбрасывать без уведомления все принятые сообщения RA, не соответствующие всем приведённым ниже требованиям:

IP Source Address указывает адрес link-local; маршрутизаторы должны использовать свой адрес link-local в поле отправителя для сообщений RA и Redirect, чтобы хосты могли однозначно распознать маршрутизатор;
поле IP Hop Limit имеет значение 255, т. е. пакет не может пересылаться маршрутизатором;
поле ICMP Checksum действительно;
ICMP Code = 0;
размер ICMP (выводится из размера IP) не менее 16 октетов;
все включённые опции имеют ненулевой размер.

Поле Reserved и все нераспознанные опции должны игнорироваться. Будущие совместимые изменения протокола могут задавать иное применение поля Reserved и новые опции, в несовместимых изменениях может применяться другое значение Code. Содержимое любых опций, для которых не указано включение в сообщения RS, должно игнорироваться с сохранением обычной обработки сообщения. В настоящее время для RA указаны опции Source Link-Layer Address, Prefix Information и MTU. Прошедшие проверку анонсы считаются действительными (valid advertisement).

6.2. Сообщение RS

6.2.1. Переменные конфигурации маршрутизатора

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

IsRouter

Флаг, указывающий включение маршрутизации на интерфейсе, позволяющее пересылать пакеты через него. По умолчанию FALSE.

AdvSendAdvertisements

Флаг, указывающий передачу маршрутизатором периодических сообщений RA и откликов на RS. По умолчанию FALSE. Отметим, что по умолчанию должно устанавливаться AdvSendAdvertisements = FALSE, чтобы узел не мог случайно выступить в качестве маршрутизатора без явной настройки через систему управления для передачи RA.

MaxRtrAdvInterval

Максимальный интервал между отправкой групповых незапрошенных сообщений RA с этого интерфейса (в секундах). Интервал должен быть не меньше 4 и не больше 1800 секунд, по умолчанию 600 секунд.

MinRtrAdvInterval

Минимальный интервал между отправкой групповых незапрошенных сообщений RA с этого интерфейса (в секундах). Интервал должен быть не меньше 3 секунд и не больше 0,75 * MaxRtrAdvInterval. По умолчанию 0,33 * MaxRtrAdvInterval, если MaxRtrAdvInterval ≥ 9, иначе 0,75 * MaxRtrAdvInterval¹⁰.

AdvManagedFlag

Флаг (TRUE или FALSE) для включения в поле Managed address configuration сообщений RA (см. [ADDRCONF]). По умолчанию FALSE.

AdvOtherConfigFlag

Флаг (TRUE или FALSE) для включения в поле Other configuration сообщений RA (см. [ADDRCONF]). По умолчанию FALSE.

AdvLinkMTU

Значение для включения в передаваемые маршрутизатором опции MTU. 0 указывает, что опции MTU не передаются. По умолчанию 0.

AdvReachableTime

Значение для включения в поле Reachable Time передаваемых маршрутизатором сообщений RA. Значение 0 указывает, что маршрутизатор не задаёт поле. Значение поля должно быть не больше 3600000 мсек (1 час). По умолчанию 0.

AdvRetransTimer

Значение для включения в поле Retrans Timer передаваемых маршрутизатором сообщений RA. Значение 0 указывает, что маршрутизатор не задаёт поле. По умолчанию 0.

AdvCurHopLimit

Принятое по умолчанию значение поля Cur Hop Limit в передаваемых маршрутизатором сообщениях RA. В поле следует помещать текущий диаметр Internet. Значение 0 указывает, что маршрутизатор не задаёт поле. По умолчанию используется значение из Assigned Numbers [ASSIGNED] на момент реализации.

AdvDefaultLifetime

Значение для включения в поле Router Lifetime передаваемых с этого интерфейса сообщений RA (в секундах). Это должно быть значение из интервала от MaxRtrAdvInterval до 9000 секунд или 0. Нулевое значение указывает, что маршрутизатор не применяется по умолчанию. Ограничения могут переопределяться документами, задающими работу IPv6 с конкретными канальными уровнями. Например, на каналах «точка-точка» у партнёров может достаточно сведений о числе и состоянии устройств на другой стороне, что позволит реже передавать анонсы. По умолчанию 3 * MaxRtrAdvInterval.

AdvPrefixList

Список префиксов, помещаемых в опции Prefix Information сообщений RA, передаваемых с интерфейса. По умолчанию это все префиксы, анонсируемые через протоколы маршрутизации, как относящиеся к каналу для передающего анонсы интерфейса. Префикс link-local не следует включать в список анонсируемых префиксов. Каждый префикс включает указанные ниже сведения.

AdvValidLifetime

Значение, помещаемое в поле Valid Lifetime опции Prefix Information (в секундах). Значение, содержащее лишь 1 (0xffffffff) задаёт неограниченный срок. Реализации могут указывать AdvValidLifetime двумя способами:

значение, декрементируемое в реальном масштабе времени, что приводит к Lifetime = 0 в заданное время в будущем;
фиксированный момент, не меняющийся в последующих анонсах.

По умолчанию принято фиксированное значение 2592000 секунд (30 дней).

AdvOnLinkFlag

Значение помещаемое во флаг L опции Prefix Information. По умолчанию TRUE.

Для автоматической настройки адресов без учёта состояния [ADDRCONF] с каждым префиксом указываются дополнительные сведения.

AdvPreferredLifetime

Значение, помещаемое в поле Preferred Lifetime опции Prefix Information (в секундах). Значение, содержащее лишь 1 (0xffffffff) задаёт неограниченный срок. Использование этого значения описано в [ADDRCONF]. Реализации могут указывать AdvPreferredLifetime двумя способами:

значение, декрементируемое в реальном масштабе времени, что приводит к Lifetime = 0 в заданное время в будущем;
фиксированный момент, не меняющийся в последующих анонсах.

По умолчанию принято фиксированное значение 604800 секунд (7 дней). Этому значению недопустимо быть больше AdvValidLifetime.

AdvAutonomousFlag

Значение, помещаемое в поле Autonomous Flag опции Prefix Information (см. [ADDRCONF]). По умолчанию TRUE.

Упомянутые выше переменные включают сведения, включаемые в исходящие сообщения RA. Хосты применяют полученные данные для инициализации набора аналогичных переменных, управляющих их внешним поведением (см. параграф 6.3.2). Некоторые из таких переменных хоста (например, CurHopLimit, RetransTimer, ReachableTime) применимы ко всем узлам, включая маршрутизаторы. На деле эти переменные могут отсутствовать в маршрутизаторах, поскольку их можно вывести из описанных выше переменных. Однако внешнее поведение маршрутизатора должно совпадать с поведением хоста в части этих переменных. В частности, это включает выполняемую иногда рандомизацию ReachableTime, как описано в параграфе 6.3.2. Переменные хоста.

Константы протокола указаны в разделе 10.

6.2.2. Переход интерфейса в состояние анонсирующего

Анонсирующим считается любой включенный и работающий интерфейс, имеющий хотя бы один индивидуальный адрес IP, для которого соответствующий флаг AdvSendAdvertisements имеет значение TRUE. Маршрутизатору недопустимо передавать сообщения RA с интерфейсов, которые не являются анонсирующими.

Интерфейс может стать анонсирующим не только при запуске системы. Например,

при смене флага AdvSendAdvertisements для включённого интерфейса с FALSE на TRUE;
при административном включении отключённого ранее интерфейса с AdvSendAdvertisements = TRUE;
включение пересылки IP (например, хоста становится маршрутизатором ) при AdvSendAdvertisements = TRUE.

Маршрутизатор должен связать групповой адрес all-routers с анонсирующим интерфейсом. Маршрутизаторы отвечают на запросы RS, переданные по адресу all-routers, и проверяют согласованность RA, переданных соседями.

6.2.3. Содержимое сообщения RA

Маршрутизатор передаёт периодические и запрошенные сообщения RA через свои анонсирующие интерфейсы. Исходящие RA заполняются указанными ниже значениями, в соответствии с форматом, указанным в параграфе 4.2.

В поле Router Lifetime указывается заданное для интерфейса значение AdvDefaultLifetime.
Флаги M и O в соответствии с заданными для интерфейса AdvManagedFlag и AdvOtherConfigFlag.
В поле Cur Hop Limit указывается заданное для интерфейса значение AdvCurHopLimit¹¹.
В поле Reachable Time указывается заданное для интерфейса значение AdvReachableTime.
В поле Retrans Timer указывается заданное для интерфейса значение AdvRetransTimer.
Опции включаются в соответствии с приведёнными ниже правилами.
- В опции Source Link-Layer Address указывается адрес канального уровня передающего интерфейса. Опцию можно опустить для упрощения балансировки на входе между реплицированными интерфейсами.
- В опции MTU указывается значение AdvLinkMTU, если оно отлично от 0. При AdvLinkMTU = 0 опция MTU не передаётся.
- В опции Prefix Information для каждого префикса из списка AdvPrefixList указываются поля записи AdvPrefixList:
  - для флага on-link (L) устанавливается значение AdvOnLinkFlag;
  - в поле Valid Lifetime помещается значение AdvValidLifetime;
  - для флага Autonomous address configuration (A) устанавливается значение AdvAutonomousFlag;
  - в поле Preferred Lifetime помещается значение AdvPreferredLifetime.

Маршрутизатор может передавать RA без анонсирования себя как принятого по умолчанию маршрутизатора. Например, маршрутизатор может анонсировать префиксы для автоматической настройки адресов без учёта состояния, не желая пересылать пакеты. Такой маршрутизатор указывает в исходящих анонсах Router Lifetime = 0.

Маршрутизатор может не включать некоторые опции в незапрошенные RA. Например, если срок действия префикса много больше AdvDefaultLifetime, достаточно его включения в каждые несколько анонсов. Однако при ответе на RS или отправке нескольких первых незапрошенных анонсов маршрутизатору следует включать все опции для быстрого распространения всех данных (например, префиксов) в процессе инициализации системы.

Если включение опций ведёт к превышению MTU на канале, можно передать несколько анонсов с частью опций в каждом.

6.2.4. Отправка незапрошенных сообщений RA

Хостам недопустимо передавать сообщения RA.

Незапрошенные RA не являются строго периодическими, интервал между отправкой меняется случайным образом для предотвращения синхронизации анонсов от разных маршрутизаторов на одном канале [SYNC]. У каждого анонсирующего интерфейса есть свой таймер, для которого при каждой отправке с интерфейса группового анонса устанавливается случайное значение (с однородным распределением) из заданного для интерфейса интервала MinRtrAdvInterval — MaxRtrAdvInterval. По завершении заданного интервала передаётся следующий анонс и для таймера выбирается новое случайное значение.

Для нескольких первых анонсов (до MAX_INITIAL_RTR_ADVERTISEMENTS), передаваемых с интерфейса, ставшего аносирующим, в случае выбора случайного значения больше MAX_INITIAL_RTR_ADVERT_INTERVAL для таймера следует установить значение MAX_INITIAL_RTR_ADVERT_INTERVAL. Использование меньшего интервала для начальных анонсов повышает вероятность быстрого обнаружения маршрутизатора, когда он становится доступным, при наличии потери пакетов.

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

6.2.5. Утрата интерфейсом статуса анонсирующего

Интерфейс может утратить статус анонсирующего в результате действий системы управления:

смена значения флага AdvSendAdvertisements для включённого интерфейса с TRUE на FALSE;
административное отключение интерфейса;
отключение системы (shutdown).

В таких случаях маршрутизатору следует передать хотя бы одно (но не более MAX_FINAL_RTR_ADVERTISEMENTS) финальное групповое сообщение RA через интерфейс с установкой Router Lifetime = 0. Если маршрутизатор становится хостом, системе следует также выйти из группы all-routers на всех интерфейсах, где поддерживается групповая адресация IP (независимо от того, были ли они анонсирующими). Кроме того, хост должен обеспечить в последующих сообщениях NA с данного интерфейса сброс флага маршрутизации R.

Отметим, что система управления может отключить на маршрутизаторе пересылку IP (например, переведя его в статус хоста), но это может не менять для интерфейсов статус анонсирования. В таких случаях последующие анонсы RA должны указывать Router Lifetime = 0.

6.2.6. Обработка сообщений RS

Хост должен отбрасывать без уведомления все полученные сообщения RS.

Кроме отправки незапрошенных анонсов маршрутизаторы передают анонсы в ответ на запросы, полученные на анонсирующем интерфейсе. Маршрутизатор может передавать индивидуальные отклики напрямую отправителям запросов (если запрос не отправлен с неуказанного адреса), но обычно анонсы передаются по групповому адресу all-nodes. В этом случае для таймера интервалов на интерфейсе устанавливается новое случайное значение, как это делается при отправке незапрошенных анонсов (6.2.4. Отправка незапрошенных сообщений RA).

Во всех случаях анонсы RA, передаваемые в ответ на RS, должны задерживаться на случайное время от 0 до MAX_RA_DELAY_TIME секунд (при отправке анонса в ответ на несколько запросов задержка отсчитывается от первого запроса). Кроме того, для последовательных RA по групповому адресу all-nodes должна быть ограничена частота отправки — не более 1 анонса каждые MIN_DELAY_BETWEEN_RAS секунд.

Маршрутизатор может обрабатывать сообщения RS, как указано ниже.

После приёма RS рассчитывается случайное значение из диапазона 0 — MAX_RA_DELAY_TIME. Если рассчитанное значение указывает время после запланированной отправки следующего группового сообщения RA, случайная задержка игнорируется и сообщение передаётся в запланированное время.
Если маршрутизатор передал групповое сообщение RA (запрошенное или незапрошенное) в последние MIN_DELAY_BETWEEN_RAS секунд, планируется отправка анонса через MIN_DELAY_BETWEEN_RAS секунд с дополнительной случайной задержкой после передачи предыдущего анонса. Это обеспечивает ограничение частоты отправки групповых RA.
В остальных случаях планируется отправка RA в заданное случайным значением время.

Отметим, что маршрутизаторам разрешено передавать групповые RA чаще, чем указано в переменной конфигурации MinRtrAdvInterval, если более частые анонсы являются откликами на RS. Однако во всех случаях незапрошенные групповые анонсы недопустимо передавать чаще, чем указывает MinRtrAdvInterval.

По запросам RS, где Source Address содержит неуказанный адрес, недопустимо обновляет Neighbor Cache в маршрутизаторе, а запросы с подходящим адресом отправителя обновляют кэш соседей, как описано ниже. Если у маршрутизатора уже есть в кэше соседей запись для отправителя запроса, запрос содержит опцию Source Link-Layer Address и полученный адрес канального уровня отличается от сохранённого в кэше, следует обновить адрес канального уровня в соответствующей записи Neighbor Cache, а для состояния доступности в ней должно быть установлено значение STALE. Если в кэше нет записи для отправителя запроса, в кэш заносится адрес канального уровня и устанавливается состояние доступности STALE, как указано в параграфе 7.3.3. Если в Neighbor Cache нет записи и в сообщении нет опции Source Link-Layer Address, маршрутизатор может ответить групповым или индивидуальным сообщением RA. Независимо от наличия опции Source Link-Layer Address, если в кэше соседей имеется (или создаётся) запись для отправителя запроса, флаг IsRouter в этой записи должен получить значение FALSE.

6.2.7. Согласованность RA

Маршрутизаторам следует просматривать действительные анонсы RA от других маршрутизаторов и проверять согласованность анонсируемых сведений в канале. Найденные несоответствия указывают, что один или несколько маршрутизаторов могут быть настроены некорректно и следует записывать такие события в системный журнал или систему управления сетью. Минимальный набор проверок указан ниже.

Значения Cur Hop Limit (за исключением значения 0 несоответствия следует фиксировать в журнале системы управления сетью).
Значения флагов M и O.
Значения Reachable Time (за исключением значения 0).
Значения Retrans Timer (за исключением значения 0).
Значения в опциях MTU.
Значения Preferred Lifetime и Valid Lifetime для одного префикса. Если AdvPreferredLifetime и/или AdvValidLifetime уменьшаются в реальном масштабе времени, как указано в параграфе 6.2.1, сравнение сроков действия в полях сообщений невозможно по значениям полей в RA, и вместо этого должно сравниваться время, когда префикс становится устаревшим или недействительным. Из-за задержек в канале и, возможно, слабо синхронизированных часов в маршрутизаторах при таком сравнении следует учитывать некоторую погрешность.

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

Другие действия при получении маршрутизатором анонсов RA выходят за рамки этой спецификации.

6.2.8. Смена адреса канального уровня

Адресу link-local у маршрутизатора следует меняться редко или не меняться совсем. Узлы, получающие сообщения ND, используют адрес источника для идентификации отправителя. Если множество пакетов от одного маршрутизатора содержит разные адреса отправителя, узлы отнесут их к разным маршрутизаторам, что приведёт к нежелательному поведению. Например, узел будет игнорировать сообщения Redirect, которые он сочтёт отправленными не тем маршрутизатором, который сейчас служит первым узлом пересылки (first-hop). Поэтому адрес отправителя в RA от конкретного маршрутизатора должен совпадать с адресом цели в сообщении Redirect с перенаправлением на этот маршрутизатор.

Использование адреса link-local для однозначной идентификации маршрутизаторов на канале имеет то преимущество, что при смене адресов на сайте этот адрес менять не требуется.

Если маршрутизатор меняет адрес link-local на одном из интерфейсов, ему следует уведомить об этом хосты. Маршрутизатору следует передать несколько групповых RA со старого адреса link-local с Router Lifetime = 0, а также несколько групповых RA с нового адреса. Результат будет таким же как при утрате статуса анонсирующего одним интерфейсом и получении этого статуса другим.

6.3. Спецификация хоста

6.3.1. Переменные конфигурации хоста

Нет.

6.3.2. Переменные хоста

Хосты поддерживают некоторые связанные с ND переменные в дополнение к структурам данных, определенным в параграфе 5.1. Приведённые ниже имена переменных заданы лишь для удобства и реализация может выбрать свои имена, если обеспечивается описанное в этом документе внешнее поведение.

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

LinkMTU

MTU для канала. Принятое по умолчанию значение определяется документом, задающим работу IPv6 с конкретным канальным уровнем (например, [IPv6-ETHER]).

CurHopLimit

Принятое по умолчанию ограничение числа интервалов пересылки при отправке пакетов IP. Принятое по умолчанию значение определяется Assigned Numbers [ASSIGNED] на момент реализации.

BaseReachableTime

Базовое значение для расчёта случайного значения ReachableTime. По умолчанию REACHABLE_TIME мсек.

ReachableTime

Время с момента приёма последнего подтверждения доступности, в течение которого хост считается доступным. Это должно быть случайное значение с однородным распределением из интервала MIN_RANDOM_FACTOR -MAX_RANDOM_FACTOR, умноженное на BaseReachableTime (в мсек). Следует рассчитывать новое случайное значение при изменении BaseReachableTime (в RA) или каждые несколько часов даже при отсутствии RA.

RetransTimer

Время между повторами сообщений NS соседу при распознавании адресов или проверке доступности соседа. По умолчанию RETRANS_TIMER мсек.

6.3.3. Инициализация интерфейса

На интерфейсах с поддержкой групповой адресации хост присоединяется к группе all-nodes.

6.3.4. Обработка полученных сообщений RA

При наличии нескольких маршрутизаторов сведения, анонсируемые ими коллективно, могут быть надмножеством данных одного сообщения RA. Более того, информация может также поступать от иных динамических источников, таких как DHCPv6. Хост воспринимает объединение всей полученной информации и сообщению RA недопустимо аннулировать все сведения, полученные в предыдущем анонсе или из иных источников. Однако при получении данных для конкретного параметра (например, Link MTU) или опции (например, Lifetime для конкретного префикса), отличающихся от ранее полученной информации используется более свежее значение, если параметр или опция не поддерживает одновременно несколько значений.

Поля RA (например, Cur Hop Limit, Reachable Time, Retrans Timer) могут содержать значение, указывающее, что поле фактически не задано. В таких случаях поле следует игнорировать и хосту следует продолжать использование прежнего значения. В частности, хосту недопустимо интерпретировать незаданное значение как возврат к принятому по умолчанию до получения первого анонса RA. Это правило предотвращает безостановочную смену внутренней переменной, когда один маршрутизатор анонсирует конкретное значение, другой — незаданное.

При получении действительного RA хост извлекает из пакета адрес отправителя и выполняет следующие операции:

если адреса ещё нет в списке хоста Default Router List, а в анонсе указано ненулевое значение Router Lifetime, в список вносится новая запись и для таймера аннулирования устанавливается значение поля Router Lifetime;
если адрес уже включён в Default Router List из прежних анонсов, для таймера аннулирования устанавливается значение поля Router Lifetime из последнего анонса;
если адрес уже включён в Default Router List и Router Lifetime = 0, для записи незамедлительно задаётся тайм-аут, как указано в параграфе 6.3.5.

Для ограничения объёма памяти на хранение Default Router List хост может хранить не все адреса маршрутизаторов, полученные в анонсах. Однако хост должен сохранять адреса по меньшей мере 2 маршрутизаторов и следует сохранять больше. Выбор принятого по умолчанию маршрутизатора происходит всякий раз, когда возникает отказ связи с адресатом. Таким образом, большее число маршрутизаторов в списке позволяет быстрее найти другой рабочий маршрут (без ожидания приёма следующего анонса RA).

Если принятое значение Cur Hop Limit не равно 0, хосту следует установить это значение в переменной CurHopLimit.

Если принятое значение Reachable Time отлично от 0, хосту следует установить его в переменной BaseReachableTime. Если новое значение отличается от прежнего, хосту следует рассчитать новое значение ReachableTime, как случайное число с однородным распределением из интервала MIN_RANDOM_FACTOR — MAX_RANDOM_FACTOR, умноженное на BaseReachableTime. Использование случайного значения позволяет избежать синхронизации сообщений NUD. Во многих случаях анонсируемое значение Reachable Time будет совпадать в последовательных сообщениях RA и значение BaseReachableTime на хосте будет меняться редко. В таких случаях реализации следует обеспечивать расчёт нового случайного значение не реже 1 раза каждые несколько часов.

Значение переменной RetransTimer следует копировать из поля Retrans Timer, если оно отлично от 0.

После извлечения данных из фиксированной части RA анонс сканируется на предмет действительных опций. Если в анонсе имеется опция Source Link-Layer Address, адрес канального уровня следует записать в Neighbor Cache (создать запись при необходимости), а для флага IsRouter в NCE должно быть установлено значение TRUE. Если опция Source Link-Layer Address не включена, но имеется соответствующая запись NCE, для флага IsRouter в этой записи должно быть установлено значение TRUE. Флаг IsRouter используется NUD для определения перехода маршрутизатора в статус хоста (т. е. прекращение пересылки пакетов). Если создаётся запись NCE для маршрутизатора, для неё должно быть установлено состояние доступности STALE, как указано в параграфе 7.3.3. Для имеющейся записи, в которой обновляется адрес канального уровня, также должно устанавливаться состояние доступности STALE.

При наличии опции MTU хосту следует скопировать её значение в LinkMTU при условии, что оно не меньше минимального MTU для канала [IPv6] и не больше максимального LinkMTU, заданного соответствующим канальному уровню документом (например, [IPv6-ETHER]).

Опции Prefix Information с установленным флагом on-link (L) указывают префикс, определяющий диапазон адресов, которые следует считать относящимися к каналу. Отметим однако, что опция Prefix Information со сброшенным флагом L не содержит сведений о принадлежности к каналу и её недопустимо считать индикацией того, что префикс не относится к каналу. Единственным способом отменить прежнюю индикацию принадлежности префикса к каналу является анонсирование префикса с установленным флагом L и Lifetime = 0. Принятое по умолчанию (5.2. Концептуальный алгоритм передачи) поведение при отправке пакета по адресу, для которого нет сведений о принадлежности к каналу, заключается в пересылке пакета заданному по умолчанию маршрутизатору. Получение опции Prefix Information со сброшенным флагом L не меняет этого поведения. Причины того, что адрес считается относящимся к каналу, указаны в определении on-link в параграфе 2.1. Префиксы со сброшенным флагом L обычно имеют флаг A и используются [ADDRCONF].

Для каждой опции Prefix Information с установленным флагом L хост выполняет перечисленные ниже действий.

Если префикс является link-local, опция Prefix Information игнорируется.
Если префикса ещё нет в Prefix List и в опции Prefix Information поле Valid Lifetime отлично от 0, создаётся новая запись для префикса и для таймера аннулирования устанавливается значение Valid Lifetime из опции.
Если префикс уже включён в Prefix List прежним анонсом, для таймера аннулирования устанавливается значение Valid Lifetime из опции Prefix Information. Если новое значение Lifetime = 0, префикс сразу же считается устаревшим (см. 6.3.5. Тайм-ауты для префиксов и принятых по умолчанию маршрутизаторов).
Если в опции Prefix Information поле Valid Lifetime = 0 и префикса нет в Prefix List хоста, опция игнорируется.

Для автоматической настройки адресов [ADDRCONF] в некоторых случаях могут применяться большие значения Valid Lifetime или поле может игнорироваться для предотвращения некоторых DoS¹²-атак. Однако влияние таких атак на список относящихся к каналу префиксов не является катастрофическим (хосты будут отправлять пакеты принятому по умолчанию маршрутизатору вместо передачи соседу напрямую), поэтому протокол ND не задаёт проверки срока действия префикса. [ADDRCONF] может вносить ограничения на размер префиксов для автоматической настройки адресов, поэтому префикс может отвергаться реализацией [ADDRCONF] на хосте. Однако размер префикса остаётся действительным для определения принадлежности к каналу в комбинации с другими флагами опции Prefix Information.

Примечание. Реализации могут обрабатывать аспекты принадлежности префикса к каналу независимо от аспектов автоматической настройки адресов без учёта состояния, например, передавая копию каждого действительного сообщения RA обеим функциям on-link и addrconf, каждая из которых работает автономно с префиксами, для которых установлен соответствующий флаг.

6.3.5. Тайм-ауты для префиксов и принятых по умолчанию маршрутизаторов

По завершении отсчёта таймера аннулирования для записи Prefix List эта запись отбрасывается, однако имеющиеся записи Destination Cache не требуется обновлять. Если возникает проблема доступности для имеющейся записи NCE, алгоритм NUD будет выполнять требуемое восстановление.

По истечении Lifetime для записи в Default Router List эта запись отбрасывается. При удалении маршрутизатора из списка Default Router узел должен обновить Destination Cache, чтобы для всех записей, включающих этот маршрутизатор, была выполнена процедура определения next-hop и трафик не направлялся этому маршрутизатору.

6.3.6. Выбор принятого по умолчанию маршрутизатора

Выбор маршрутизатора отчасти зависит о наличии сведений о его доступности. Детали отслеживания узлом статуса доступности соседа описаны в параграфе 7.3. Алгоритм выбора принятого по умолчанию маршрутизатора вызывается при определении next-hop, когда в Destination Cache нет записи для адресата вне канала (off-link) или связь через имеющийся маршрутизатор представляется отказавшей. В нормальных условиях маршрутизатор выбирается при первой передаче трафика адресату, а для последующего трафика используется маршрутизатор, указанный в Destination Cache с учётом изменений кэша, вызванных сообщениями Redirect. Правила выбора маршрутизатора из Default Router List приведены ниже

Следует предпочитать маршрутизаторы, которые доступны или могут быть доступны (т. е. состояние отличается от INCOMPLETE), маршрутизаторам, доступность которых неизвестна или кажется сомнительной (т. е. состояние INCOMPLETE или отсутствие записи в Neighbor Cache). Дополнительные рекомендации по выбору принятого по умолчанию маршрутизатора приведены в [LD-SHRE].
Если в списке нет маршрутизаторов, которые доступны или могут быть доступны, маршрутизаторы следует перебирать по кругу (round-robin), чтобы последующие запросы для принятого по умолчанию маршрутизатора не возвращали тот же маршрутизатор, пока не будут проверены все остальные. Циклический перебор обеспечивает активную проверку всех маршрутизаторов алгоритмом NUD. Запрос принятого по умолчанию маршрутизатора выполняется вместе с отправкой пакета маршрутизатору и проверка доступности маршрутизатора выполняется как побочный эффект.

6.3.7. Отправка сообщений RS

При включении интерфейса хост может не захотеть ждать следующего незапрошенного сообщения RA для получения принятых по умолчанию маршрутизаторов и определения префиксов. Для быстрого получения RA хосту следует передать до MAX_RTR_SOLICITATIONS сообщений RS с интервалом не менее RTR_SOLICITATION_INTERVAL секунд. Сообщение RS можно передавать после любого из перечисленных ниже событий:

инициализация интерфейса при старте системы;
повторная инициализация интерфейса после его временного отказа или запрета системой управления;
переход маршрутизатора в статус хоста с отключением пересылки IP системой управления;
первое подключение хоста к каналу;
повторное подключение хоста после временного отключения от канала.

Хост передаёт сообщения RS по групповому адресу all-routers. В поле IP-адреса отправителя указывается индивидуальный адрес одного из интерфейсов или незаданный адрес (unspecified). В опции Source Link-Layer Address следует указывать адрес хоста на канальном уровне, если IP-адрес не является незаданным.

Перед отправкой первоначального запросу хосту следует ввести случайную задержку из диапазона от 0 до MAX_RTR_SOLICITATION_DELAY. Это позволяет снизить нагрузку при одновременном запуске множества хостов на канале, что может происходить при восстановлении после отказа по питанию. Если хост уже использовал случайную задержку после своего (повторного) включения (например, как часть DAD [ADDRCONF]), новая задержка перед отправкой первого RS не требуется.

В некоторых случаях случайную задержку можно не вносить. Например, мобильному узлу, использующему [MIPv6], при переходе на новый канал нужно как можно быстрее обнаружить такой переход для минимизации числа пакетов, потерянных в результате изменения топологии. Сообщения RS обеспечивают полезный механизм детектирования перемещения в Mobile IPv6, поскольку они позволяют мобильному узлу видеть переключение на другой канал. Поэтому при получении мобильным узлом сведений канального уровня, говорящих о возможном переключении, он может передать сообщение RS без дополнительной случайной задержки. Надёжность такой индикации должна оценивать реализация мобильного узла в зависимости от уровня достоверности сведений от канального уровня, но это выходит за рамки спецификации. Отметим, что ненадлежащее применение механизма (например, на основе слабой или временной индикации) может приводить к пикам отправки RS. Кроме того, одновременное перемещение большого числа мобильных устройств, использующих механизм, может создавать множество одновременных запросов RS.

После отправки RS и получения действительного RA с отличным от 0 Router Lifetime хост должен прекратить отправку дополнительных запросов с этого интерфейса, пока снова не произойдёт одно из указанных выше событий. Хосту следует передать хотя бы 1 запрос даже при получении анонса до запроса. Отклики на запросы могут включать больше информации по сравнению с незапрошенными анонсами.

Если хост передал MAX_RTR_SOLICITATIONS запросов и не получил RA в течении MAX_RTR_SOLICITATION_DELAY секунд с момента отправки последнего запроса, он считает, что на канале нет маршрутизаторов для [ADDRCONF]. Однако хост будет получать и обрабатывать сообщения RA при появлении маршрутизаторов на канале.

7. Распознавание адресов и NUD

В этом разделе описаны функции, связанные с сообщениями NS и NA, а также описаны алгоритмы распознавания адресов и обнаружения недоступности соседей (NUD). Сообщения NS и NA применяются также для обнаружения дубликатов адресов (DAD), заданного в [ADDRCONF]. В частности, механизм DAD передаёт сообщения NS с неуказанным адресом источника, нацеленные на его «предварительный» адрес. Такие сообщения инициируют на узлах, уже использующих этот адрес, отправку групповых NA, указывающих, что адрес уже занят.

7.1. Проверка сообщений

7.1.1. Проверка NS

Узел должен без уведомления отбрасывать сообщения NS, на соответствующие приведённым ниже условиям:

поле IP Hop Limit = 255, т. е. пакет не может пересылаться маршрутизаторами;
значение ICMP Checksum корректно;
ICMP Code = 0;
размер ICMP (выводится из размера IP) составляет не менее 24 октетов;
Target Address не является групповым адресом;
все включённые опции имеют ненулевой размер;
если IP-адрес отправителя не задан, IP-адрес получателя является групповым адресом solicited-node;
если IP-адрес отправителя не задан, в сообщении нет опции Source Link-Layer Address.

Содержимое поля Reserved и все нераспознанные опции должны игнорироваться. Будущие совместимые изменения протокола могут менять содержимое поля Reserved или добавлять опции, несовместимые изменения могут использовать другие значения Code.

Содержимое опций, не указанных для сообщений NS, должно игнорироваться с продолжением обычной обработки пакета. В настоящее время для сообщений определена лишь опция Source Link-Layer Address.

Сообщения NS, прошедшие проверку, считаются действительными запросами (valid solicitation).

7.1.2. Проверка NA

Узел должен без уведомления отбрасывать сообщения NA, на соответствующие приведённым ниже условиям:

поле IP Hop Limit = 255, т. е. пакет не может пересылаться маршрутизаторами;
значение ICMP Checksum корректно;
ICMP Code = 0;
размер ICMP (выводится из размера IP) составляет не менее 24 октетов;
Target Address не является групповым адресом;
если IP Destination Address содержит групповой адрес, флаг Solicited сброшен (0);
все включённые опции имеют ненулевой размер.

Содержимое опций, не указанных для сообщений NA, должно игнорироваться с продолжением обычной обработки пакета. В настоящее время для сообщений определена лишь опция Target Link-Layer Address.

Сообщения NA, прошедшие проверку, считаются действительными анонсами (valid advertisement).

7.2. Распознавание адресов

Процесс распознавания адресов служит для определения узлом адреса канального уровня у соседа по его адресу IP. Распознавание выполняется лишь для относящихся к каналу (on-link) адресов, для которых отправитель не знает адрес на канальном уровне (см. 5.2. Концептуальный алгоритм передачи) и не применяется для групповых адресов.

Хост может получить запрос, анонс маршрутизатора или сообщение Redirect без опции с адресом канального уровня. По таким сообщениям недопустимо создавать или обновлять записи в кэше соседей, за исключением флага IsRouter в них, как указано в параграфах 6.3.4 и 7.2.5. Если для отправителя такого сообщения нет записи в Neighbor Cache, требуется выполнить распознавание адреса до начала взаимодействия с ним по индивидуальному адресу. Это относится, в частности, к индивидуальным откликам на запросы, где нужен обмен дополнительными пакетами для доставки анонса.

7.2.1. Инициализация интерфейса

При включении интерфейса, поддерживающего групповую адресацию узел должен присоединить к этому интерфейсу групповой адрес all-nodes, а также групповой адрес solicited-node, соответствующий каждому IP-адресу интерфейса.

Набор назначенных интерфейсу адресов может меняться с течением времени, т. е. адреса могут добавляться и удаляться с помощью [ADDRCONF]. В таких случаях узел должен присоединяться или покидать группу solicited-node, соответствующую адресу. Присоединение группового адреса solicited-node выполняется с использованием обнаружения «групповых слушателей» (Multicast Listener Discovery), такого как протокол [MLD] или [MLDv2]. Отметим, что одному групповому адресу solicited-node может соответствовать несколько индивидуальных адресов и узлу недопустимо выходить из группы solicited-node, пока остаётся хотя бы один индивидуальный адрес, соответствующий этой группе.

7.2.2. Отправка сообщений NS

Когда узел имеет индивидуальный пакет для отправки соседу, но не знает его адрес на канальном уровне, он выполняет распознавание адресов. Для интерфейсов с поддержкой групповой адресации это влечёт создание записи Neighbor Cache со статусом INCOMPLETE и передаст сообщения NS, направленного соседу по групповому адресу solicited-node, соответствующему адресу цели.

Если адрес отправителя в пакет, вызывающем запрос, совпадает с одним из адресов передающего интерфейса, этот адрес следует поместить в поле IP Source Address исходящего запроса. В иных случаях можно указывать любой из адресов интерфейса. Использование адреса отправителя вызвавшего запрос пакета обеспечивает включение получателем сообщения NS в свой Neighbor Cache адреса IP, который с большой вероятностью будет применяться в последующем обмене трафиком, связанном с вызвавшим «соединение» пакетом.

Если запрос передаётся по групповому адресу solicited-node, отправитель должен передать свой адрес канального уровня (при наличии) в опции Source Link-Layer Address. В иных случае отправителю следует передать свой адрес канального уровня (при наличии) в опции Source Link-Layer Address. Включение адреса отправителя на канальном уровне в групповой запрос нужно для того, чтобы получатель мог передать сообщение NA. При индивидуальном запросе реализация может не включать опцию Source Link-Layer Address. Здесь предполагается, что при наличии в кэше отправителя партнерского адреса канального уровня высока вероятность того, что у партнёра также кэширован адрес отправителя, поэтому его можно не передавать.

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

В процессе ожидания отклика отправителю следует повторять сообщения NS примерно каждые RetransTimer мсек, даже если нет другого трафика для соседа. Частота повтора должна быть ограничена — не более 1 запроса в течение RetransTimer мсек.

Если не было получено сообщения NA после MAX_MULTICAST_SOLICIT запросов, распознавание адреса считается неудачным и отправитель должен вернуть сообщение ICMP о недоступности адресата с кодом 3 (Address Unreachable) для каждого пакета из очереди распознавания адресов.

7.2.3. Приём сообщений NS

Действительные запросы NS, не соответствующие ни одному из приведённых ниже требований, должны отбрасываться без уведомления отправителя.

Target Address является «корректным» индивидуальным адресом принимающего интерфейса [ADDRCONF];
в Target Address указан индивидуальный или anycast-адрес, для которого узел обеспечивает услуги прокси;
Target Address содержит «предварительный» адрес, для которого выполняется процедура DAD [ADDRCONF].

Если Target Address является предварительным, запрос NS следует обрабатывать в соответствии с [ADDRCONF], в иных случаях применяется описанная ниже процедура. Если Source Address не является незаданным (unspecified) и на канальных уровнях с адресацией запрос включает опцию Source Link-Layer Address, получателю следует создать или обновить запись Neighbor Cache для IP Source Address из запроса. Если записи нет, узлу следует создать её и установить статус STALE, как указано в параграфе 7.3.3. Если запись имеется и содержит другой адрес канального уровня (не совпадает с опцией Source Link-Layer Address), запись следует обновить, поместив полученный в опции адрес, а для статуса доступности в записи должно быть установлено значение STALE.

При создании NCЕ для флага IsRouter следует устанавливать значение FALSE даже при получении NS от маршрутизатора, поскольку сообщения NS не указывают, является ли отправитель маршрутизатором. Если запрос отправлен маршрутизатором, следующие сообщения NA или RA установят верное значение IsRouter. При наличии записи NCЕ менять в ней флаг IsRouter недопустимо.

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

После обновления Neighbor Cache узел передаёт анонс NA, как указано в следующем параграфе.

7.2.4. Отправка запрошенных сообщений NA

Узел передаёт анонс NA в ответ на действительный запрос NS для одного из адресов узла. Target Address в анонсе копируется из одноимённого поля запроса. Если IP Destination Address в запросе не является групповым адресом, опцию Target Link-Layer Address можно не включать, поскольку кэшированное соседом значение должно совпадать с текущим адресом, чтобы запрос был получен. Если IP Destination Address в запросе содержит групповой адрес, в анонс должна включаться опция Target Link-Layer. Если узел является маршрутизатором, он должен установить флаг Router, который в противном случае должен быть сброшен.

Если Target Address является anycast-адресом или индивидуальным адресом, для которого узел служит посредником, или опция Target Link-Layer Address не включена, флаг Override следует сбросить (0), в иных случаях флаг O следует установить (1). Корректный флаг O гарантирует предпочтение прямых не прокси) анонсов, а также «выиграет» первый анонса для anycast-адреса.

Если запрос отправлен с неуказанного адреса, узел должен сбросить флаг Solicited и передать анонс по групповому адресу all-nodes. В иных случаях узел должен установить флаг Solicited и передать индивидуальных анонс по Source Address из запроса.

Если Target Address содержит anycast-адрес, отправителю следует задержать передачу отклика на случайное время от 0 до MAX_ANYCAST_DELAY_TIME секунд.

Поскольку в индивидуальные NS не требуется включать опцию Source Link-Layer Address, в Neighbor Cache узла, передающего запрошенный анонс NA, может не оказаться соответствующего адреса канального уровня. В таких случаях узлу придётся сначала выполнить процедуру ND для определения адреса соседа на канальном уровне (отправка группового сообщения NS).

7.2.5. Приём сообщений NA

При получении действительного анонса NA (запрошенного или незапрошенного) выполняется поиск в Neighbor Cache записи для цели. Если запись имеется, анонс следует отбросить без уведомления. Если записи нет, создавать её не требуется, поскольку отправитель видимо ни инициировал взаимодействия с целью.

После нахождения подходящей NCE действия зависят от статуса этой записи, флагов анонса и представленного адреса канального уровня. Если NCE для цели имеет статус INCOMPLETE при получении анонса, возможны 2 варианта. Если канальный уровень использует адреса и опция Target Link-Layer Address в анонсе отсутствует, принимающему узлу следует просто отбросить полученный анонс. В иных случаях выполняются указанные ниже шаги:

адрес канального уровня записывается в NCE;
если в анонсе установлен флаг Solicited, запись переходит в состояние REACHABLE, иначе — в STALE;
в записи устанавливается флаг IsRouter в соответствии с флагом Router из анонса;
передаются пакеты из очереди, ожидающие распознавания адреса сосед.

Флаг Override игнорируется, если запись имеет состояние INCOMPLETE.

Если состояние NCE при получении анонса отличается от INCOMPLETE, выполняются указанные ниже действия.

Если флаг Override сброшен и полученный адрес канального уровня отличается от кэшированного, есть 2 варианта:
1. запись со статусом REACHABLE переводится в STALE без внесений других изменений;
2. в иных случаях полученный анонс игнорируется, а обновление кэше недопустимо.
Если флаг Override установлен и полученный адрес канального уровня совпадает с кэшированным или опция Target Link-Layer Address не включена, полученный анонс должен обновлять NCE, как показано ниже.

- Адрес канального уровня из Target Link-Layer Address должен быть помещён в кэш (если он указан и отличается от кэшированного.
- Если установлен флаг Solicited, для записи должно быть установлено состояние REACHABLE. Если флаг Solicited сброшен и адрес канального уровня изменён, должно быть установлено состояние STALE. В иных случаях запись не изменяется.
  
  Флаг Solicited в анонсах следует устанавливать лишь при отклике на NS. Поскольку запросы NUD передаются по кэшированным адресам канального уровня, получение запрошенного анонса указывает, что путь пересылки работает. Приём незапрошенного анонса может указывать наличие у соседа важной информации (например, о смене адреса канального уровня). Если важная информация указывает смену используемых узлом параметров, следует проверить доступность (нового) пути при передаче следующего пакета. Не требуется обновлять состояние по незапрошенным анонсам, не меняющим содержимое кэша.
- Флаг IsRouter в кэше должен устанавливаться в соответствии с флагом Router в полученном анонсе. При смене флага IsRouter с TRUE на FALSE в результате обновления узел должен удалить маршрутизатор из Default Router List и обновить записи Destination Cache для всех адресатов, использовавших этого соседа как маршрутизатор, в соответствии с параграфом 7.3.3. Этот нужно для фиксации перехода маршрутизатора в состояние хоста, когда он прекращает пересылать пакеты.

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

7.2.6. Передача незапрошенных сообщений NA

В некоторых случаях узел способен заметить смену своего адреса на канальном уровне (например, «горячее» переключение сетевого адаптера) и может быстро информировать своих соседей об этом. В таких случаях узел может передать до MAX_NEIGHBOR_ADVERTISEMENT незапрошенных анонсов NA по групповому адресу all-nodes. Интервал между этими анонсами должен быть не меньше RetransTimer секунд.

В поле Target Address незапрошенных анонсов следует указывать IP-адрес интерфейса, а в опции Target Link-Layer Address — новый адрес канального уровня. Флаг Solicited должен быть сброшен для предотвращения путаницы с алгоритмом NUD. Если узел является маршрутизатором, он должен установить флаг Router, иначе файл должен быть сброшен. Флаг Override может иметь любое значение. В любом случае соседние узлы будут сразу же менять статус своих записей NCE для Target Address на STALE, предлагая проверить доступность пути. Если флаг Override установлен, соседи будут помещать новый адрес канального уровня в свой кэш, в ином случае новый адрес будет игнорироваться с проверкой кэшированного адреса.

Узел с несколькими адресами IP на интерфейсе может передать групповые анонсы NA для каждого адреса и в этом случае между анонсами должна задаваться небольшая задержка во избежание потери пакетов от перегрузки.

Прокси может передать групповые анонсы NA при смене у него адреса канального уровня или при настройке (системой управления или иным механизмом) на нем функции посредника для адреса. При наличии нескольких прокси им следует предоставлять механизм, препятствующий одновременному групповому анонсированию одного набора адресов разными посредниками для снижения риска избыточного группового трафика. Это требование для других протоколов, которым нужен посредник для NA. Примером узла с прокси-анонсами служит Home Agent из [MIPv6].

Узел, относящийся к anycast-адресу, может передавать незапрошенные групповые NA для адреса anycast при смене своего адреса на канальном уровне.

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

7.2.7. Anycast-сообщения NA

С точки зрения ND адреса anycast трактуются в большинстве случаев как индивидуальные адреса. Поскольку синтаксически они не отличимы, узлы, выполняющие распознавание адресов или NUD для адреса anycast работают с ним как с индивидуальным адресом. Узлы с адресами anycast на интерфейсах трактуют их как индивидуальные с двумя исключениями. Во-первых, анонсы NA, передаваемые в ответ на NS, следует задерживать на случайное время из интервала 0 — MAX_ANYCAST_DELAY_TIME для снижения вероятности перегрузки сети. Во-вторых, флаг Override в анонсах NA следует сбрасывать, поэтому при получении нескольких анонсов будет использоваться первый.

Как и для индивидуальных адресов, NUD обеспечивает быстрое обнаружение недействительности привязки anycast.

7.2.8. Proxy NA

В ограниченных случаях маршрутизатор может выполнять функции посредника для одного или множества других узлов, указывая через анонсы NA своё желание воспринимать пакеты, не адресованные явно ему. Например, маршрутизатор может воспринимать пакеты от имени мобильного узла, покинувшего канал. Механизмы, применяемые прокси, по сути не отличаются от механизмов, используемых с адресами anycast. Прокси должен присоединить групповые адреса solicited-node, соответствующие адресам IP узлов, для которых предоставляются функции посредника. Это следует делать с использованием протокола обнаружения групповых слушателей, такого как [MLD] или [MLDv2].

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

При отправке прокси-анонсов в ответ на запросы NS отправителю следует задерживать отклик на время от 0 до MAX_ANYCAST_DELAY_TIME секунд во избежание конфликтов нескольких откликов от разных прокси. Однако в некоторых случаях (например, Mobile IPv6), где имеется лишь один посредник, такая задержка не требуется.

7.3. Алгоритм NUD

Связь с соседом или через него может сталкиваться с отказами по многим причинам, включая отказы оборудования, «горячую» перестановку сетевых интерфейсов и т. п. Если отказ произошёл у адресата, восстановление невозможно и связь теряется, но если отказ возникает в пути, восстановление может оказаться возможным. Таким образом, узел активно отслеживает «состояние» доступности соседей, которым от передаёт пакеты.

NUD применяется на всех путях между хостом и его соседями, включая взаимодействия «хост-хост», «маршрутизатор-хост» и «хост-маршрутизатор», а также может использоваться между маршрутизаторами, но в этом случае не требуется, если имеется эквивалентный механизм, например, в протоколе маршрутизации.

Когда представляется, что путь к соседу не работает, конкретная процедура восстановления зависит от способа использования соседа. Если тот является конечным получателем, можно, например, повторить процедуру распознавания адреса. Если сосед служит маршрутизатором, можно попытаться перейти на другой маршрутизатор. Конкретное восстановление охватывается определением next-hop и NUD указывает необходимость такого определения, удаляя NCE. Процедура NUD выполняется лишь для соседей, которым передаются индивидуальные пакеты, и не используется при передаче по групповым адресам.

7.3.1. Подтверждение доступности

Сосед считается достижимым, если у узла имеется недавнее подтверждение доставки отправленных тому пакетов IP-уровню соседа. Подтверждения могут приходить двумя способами — «подсказки» от вышележащего протокола о «продвижении соединения» (forward progress) и сообщения NA в ответ на запросы NS.

Соединение «продвигается», если пакеты от удалённого партнёра могут приходить лишь в результате фактического получения тем недавно отправленных ему пакетов. Например, в TCP получение (нового) подтверждения указывает, что отправленные ранее данные достигли партнёра, а поступление от партнёра новых данных (не дубликатов) указывает, что прежние подтверждения были доставлены ему. Если пакеты поступили к партнёру, они также должны достигнуть next-hop-соседа отправителя, поэтому «продвижение соединения» подтверждает доступность соседа next-hop. Для адресатов вне канала (off-link) такое «продвижение» предполагает доступность маршрутизатора first-hop. По возможности следует использовать эту информацию вышележащего уровня.

В некоторых случаях (например, протоколы на основе UDP и маршрутизаторы, пересылающие пакеты хостам) информация о достижимости от протоколов вышележащего уровня может быть недоступна. Когда нет доступных подсказок и узел передаёт пакеты соседу, он активно зондирует его, используя индивидуальные пакеты NS для проверки работоспособности пути пересылки. Получение запрошенного анонса NA служит подтверждением доступности, поскольку анонсы с установленным флагом Solicited передаются лишь в ответ на запросы NS.

Приём других сообщений ND, например, анонсов RA или NA со сброшенным флагом Solicited недопустимо считать подтверждением доступности. Незапрошенные сообщения подтверждают лишь односторонний путь от передающего узла к принявшему. В отличие от этого NUD требует отслеживания узлом доступности прямого пути к соседу со своей (а не соседа) точки зрения. Получение запрошенного анонса указывает, что путь работает в обоих направлениях. Запрос должен попасть к соседу и инициировать отправку отклика, а получение анонса подтверждает работу обратного пути. Однако последнее известно лишь получателю анонса, а у отправителя нет способа узнать напрямую о доставке соседу отправленного анонса. С точки зрения NUD интересная лишь доступность прямого пути.

7.3.2. Состояния NCE

Запись NCE может иметь одно из приведённых ниже пяти состояний.

INCOMPLETE

Для записи происходит распознавание адреса, в частности, отправлен запрос NS по групповому адресу solicited-node для цели, но ответный анонс NA ещё не получен.

REACHABLE

В течение последних ReachableTime мсек получено подтверждение корректной работы пути к соседу. В состоянии REACHABLE для передачи пакетов не требуется каких-либо специальных действий.

STALE

Прошло более ReachableTime мсек с момента последнего подтверждения корректной работы пути к соседу. Для передачи пакетов не требуется каких-либо специальных действий. Переход в состояние STALE происходит при получении незапрошенного сообщения ND, обновляющего кэшированный адрес канального уровня. Такое сообщение не подтверждает доступность, а переход в состояние STALE обеспечивает быструю проверку доступности при фактическом использовании записи, однако без этого доступность не проверяется.

DELAY

Прошло более ReachableTime мсек с момента последнего подтверждения корректной работы пути к соседу и в последние DELAY_FIRST_PROBE_TIME секунд соседу был отправлен пакет. Если не было получено подтверждения в течение DELAY_FIRST_PROBE_TIME секунд после перехода в состояние DELAY, соседу отправляется запрос NS, а состояние меняется на PROBE.

Состояние DELAY обеспечивает протоколам вышележащих уровней время для предоставления сведений о доступности в тех случаях, когда прошло ReachableTime мсек с последнего подтверждения из-за отсутствия трафика. Без такой оптимизации создание соединения TCP после приостановки трафика привело бы к зондирования даже в случае подтверждения доступности трехэтапным согласованием практически сразу.

PROBE

Запрашивается подтверждение доступности путём отправки NS каждые RetransTimer мсек до получения ответа.

7.3.3. Поведение узла

NUD работает параллельно с отправкой пакетов соседу. Заново подтверждая доступность соседа, узел продолжает передавать тому пакеты по кэшированному адресу канального уровня. Если трафик соседу не передаётся, не отправляются и пакеты-зонды.

Когда узлу нужно распознать адрес соседа, он создаёт запись со статусом INCOMPLETE и запускает распознавание, как указано в параграфе 7.2. Если распознать адрес не удалось, запись следует удалить, чтобы последующий трафик к соседу снова вызвал процедуру поиска next-hop, обеспечивающую попытку использовать другие маршрутизаторы.

При получении подтверждения доступности (от вышележащего уровня или анонса NA) состояние записи меняется на REACHABLE. Однако сведения от вышележащего уровня не влияют на записи со статусом INCOMPLETE (например, на те, для которых нет кэшированного адреса канального уровня).

По истечении ReachableTime мсек с момент приёма последнего подтверждения доступности соседа состояние NCE для него меняется с REACHABLE на STALE.

Примечание. Реализация может отложить смену статуса REACHABLE на STALE до отправки пакета соседу, т. е. не требуется явный тайм-аут, связанный с ReachableTime.

При первой отправке пакета соседу, запись для которого имеет статус STALE отправителю следует сменить состояние записи на DELAY и установить для таймера значение DELAY_FIRST_PROBE_TIME секунд. Если запись сохранить состояние DELAY по завершении отсчёта таймера, её состояние меняется на PROBE, если же приходит подтверждение доступности, состояние меняется на REACHABLE.

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

Отметим, что для каждого соседа частота отправки NS ограничивается независимо. Узлу недопустимо передавать NS одному соседу чаще 1 раза в течение RetransTimer мсек.

NCE переходит в состояние STALE при создании записи в результате приёма пакета, отличного от запрошенного NA (RS, RA, Redirect, NS). Эти пакеты содержат адрес канального уровня отправителя или (в случае Redirect) цели перенаправления. Однако получение такого адреса канального уровня не подтверждает доступность пути к этому узлу. Размещение новой NCE, для которой известен адрес канального уровня, в состоянии STALE обеспечивает быстрое обнаружение отказов на пути. Кроме того при смене адреса канального уровня в результате приёма одного из указанных выше сообщений для записи также следует устанавливать статус STALE для быстрой проверки доступности пути к новому адресу канального уровня.

Для правильного определения перехода маршрутизатора в статус хоста (например, в результате отключения системой управления пересылки IP) узел должен сравнивать флаг Router в полученных анонсах NA с флагом IsRouter в NCE. При обнаружении перехода соседнего маршрутизатора в статус хоста узле должен удалить этот маршрутизатор из списка Default Router List и обновить Destination Cache, как указано в параграфе 6.3.5. Отметим, что маршрутизатора может не быть в Default Router List даже при его указании в Destination Cache (например, хост был перенаправлен на него). В таких случаях для записей Destination Cache, содержащих этот (бывший) маршрутизатор, должна быть выполнена процедура определения next-hop до использования записи.

В некоторых случаях данные канального уровня могут сообщать об отказе на пути к соседу (например, сброс виртуального канала) и эти сведения можно использовать для очистки NCE до того, как это сделает алгоритм NUD. Однако данные канального уровне недопустимо применять для подтверждения доступности сосед, поскольку они не содержат сведений о сквозной связности между уровнями IP соседей.

8. Функция перенаправления

В этом разделе рассматривается передача и обработка сообщений Redirect. Эти сообщения передаются лишь маршрутизаторами хостам для указания лучшего первого маршрутизатора на пути к адресату или информирования о том, что адресат является соседом (на канале). Указание обеспечивается значением ICMP Target Address совпадающим с ICMP Destination Address.

Маршрутизатор должен быть способен определить адрес link-local для каждого из соседний маршрутизаторов, чтобы гарантировать идентификацию адресом цели в сообщении Redirect соседнего маршрутизатора по его адресу link-local. При статической маршрутизации это предполагает, что адрес next-hop следует указывать адресом link-local для маршрутизатора, при динамической — обмен всеми протоколами маршрутизации IPv6 сведениями об адресах link-local для соседних маршрутизаторов.

8.1. Проверка сообщений Redirect

Хост должен без уведомления отбрасывать сообщения Redirect, не соответствующие всем указанным ниже условиям.

IP Source Address содержит адрес link-local. Маршрутизаторы могут использовать свои адреса в поле отправителя сообщений RA и Redirect так, что хосты могут однозначно распознать маршрутизатор.
Поле IP Hop Limit имеет значение 255, препятствующее пересылке пакетов маршрутизатором.
Поле ICMP Checksum корректно.
ICMP Code = 0.
Размер ICMP (выводится из размера IP) не менее 40 октетов.
IP-адрес отправителя Redirect совпадает с адресом первого маршрутизатора для ICMP Destination Address.
Поле ICMP Destination Address в сообщении не содержит групповой адрес.
ICMP Target Address является адресом link-local (при перенаправлении на маршрутизатор) или совпадает с ICMP Destination Address (при перенаправлении получателю на канале).
Размер всех включённых опций отличается от 0.

Содержимое опций, не указанных для сообщений Redirect, должно игнорироваться с продолжением обычной обработки пакета. В настоящее время для Redirect определены опции Target Link-Layer Address и Redirected Header.

Хосту недопустимо считать перенаправление негодным лишь на основании того, что Target Address не принадлежит одному из префиксов канала. Частью семантики Redirect является то, что Target Address относится к каналу.

Сообщения Redirect, прошедшие проверку, считаются действительными перенаправлениями (valid redirect).

8.2. Указание маршрутизатора

Маршрутизатору следует передавать сообщения Redirect с учётом ограничения скорости при каждой пересылке пакета, который явно не адресован ему (не задан source-route через маршрутизатор), когда выполняются все условия:

поле Source Address в пакете указывает соседа;
маршрутизатор определил (не заданными этой спецификацией способами), что лучший маршрутизатор для Destination Address в пересылаемом пакете расположен на одном канале с передающим узлом;
Destination Address в пакете не содержит групповой адрес.

Переданный пакет перенаправления содержит в соответствии с форматом, заданным в параграфе 4.5:

поле Target Address с адресом, куда следует отправлять последующие пакеты для получателя; если целью является маршрутизатор, должен применяться адрес link-local, для хоста адрес цели должен совпадать с полем Destination Address;
поле Destination Address содержит адрес получателя из исходного пакета IP.
опции:
- Target Link-Layer Address содержит адрес канального уровня для цели (если он известен);
- Redirected Header содержит часть пересылаемого пакета, которую можно включить без превышения минимального MTU, требуемого для поддержки IPv6, в соответствии с [IPv6].

Маршрутизатор должен ограничивать частоту передачи Redirect для снижения расхода полосы и ресурсов на обработку в случаях, когда отправитель не реагирует корректно или игнорирует неаутентифицированные сообщения. Дополнительная информация об ограничении частоты отправки сообщений ICMP об ошибках приведена в [ICMPv6].

Маршрутизаторам недопустимо обновлять свои таблицы маршрутизации на основании сообщений Redirect.

8.3. Указание хоста

Получив действительное сообщение Redirect, хосту следует обновить Destination Cache, чтобы последующий трафик шёл к указанной цели. Если в Destination Cache нет записи для адресата, реализации следует создать такую запись.

Если Redirect включает опцию Target Link-Layer Address, хост создаёт или обновляет NCE для цели. В обоих случаях адрес канального уровня копируется из опции Target Link-Layer Address. При создании NCE для цели в ней должен указываться статус STALE, как указано в параграфе 7.3.3. При обновлении адреса канального уровня в имеющейся записи она должна переводиться в состояние STALE. Если же адрес канального уровня для записи не меняется, её статус остаётся прежним.

Если Target Address совпадает с Destination Addresses, хост должен считать, что Target находится на канале (on-link). Если адреса различаются, хост должен установить для цели IsRouter = TRUE. Однако совпадение адресов Target и Destination не позволяет достоверно считать, что Target Address указывает маршрутизатор. Поэтому для создаваемой вновь NCE хосту следует установить IsRouter = FALSE, но в имеющихся записях флаг не меняется. Если Target является маршрутизатором, последующие сообщения NA или RA установят верный флаг IsRouter.

Сообщения Redirect применимы ко всем потокам в адрес данного получателя, т. е. после получения Redirect для Destination Address все записи Destination Cache для этого адреса следует обновить, указав в них заданный next-hop, независимо от поля Flow Label в заголовке Redirected Header.

Хостам недопустимо передавать сообщения Redirect.

9. Расширяемость в части обработки опций

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

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

Зависимость опции от наличия или отсутствия других опций недопустима. Семантику опции следует основывать лишь на содержимом фиксированной части пакета ND и самой опции.

Соблюдение этого правила обеспечивает ряд преимуществ.

Получатели могут обрабатывать опции независимо. Например, реализация может обработать опцию Prefix Information из анонса RA пользовательским процессом, а опцию Link-Layer Address из того же сообщения — подпрограммой ядра.
Если число опций ведёт к превышению MTU на канале, их можно разделить по пакетам, сохраняя семантику.
Отправитель может передать опции в разных пакетах. Например, если Valid Lifetime и Preferred Lifetime для префикса достаточно велики, включение опции Prefix Information в каждый анонс RA может не требоваться. Кроме того, разные маршрутизаторы могут передавать свой набор опций. Поэтому получателю недопустимо связывать какое-либо действие с отсутствием опции в пакете. Этот протокол задаёт для получателей действия лишь на основании таймеров и сведений, полученных в пакетах.

Опции в пакетах ND могут указываться в любом порядке и получатель должен быть готов обрабатывать их независимо. Сообщение может также включать несколько экземпляров опции (например, Prefix Information).

Если опции в RA ведут к превышению MTU для канала, маршрутизатор может передать несколько анонсов, разделив опции между ними. Объем данных в опции Redirected Header должен ограничиваться, чтобы размер пакета не превышал минимальное значение MTU, требуемое для поддержки IPv6, как указано в [IPv6].

Размер всех опций кратен 8 октетам, что обеспечивает их выравнивание без заполнения. Поля опций (а также поля пакетов ND) определены с учётом выравнивания по естественным границам (например, 16-битовое поле выравнивается по 16-битовой границе), за исключением 128-битовых адресов и префиксов IP, выравниваемых по 64-битовой границе. Поля адресов канального уровня содержат неинтерпретируемые строки октетов и выравниваются по 8-битовой границе. Размер пакета ND вместе с заголовком IP ограничен MTU для канала. При добавлении опций в пакет ND недопустимо превышение MTU для канала.

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

10. Константы протокола

Константы маршрутизаторов

MAX_INITIAL_RTR_ADVERT_INTERVAL

16 секунд

MAX_INITIAL_RTR_ADVERTISEMENTS

3 передачи

MAX_FINAL_RTR_ADVERTISEMENTS

3 передачи

MIN_DELAY_BETWEEN_RAS

3 секунды

MAX_RA_DELAY_TIME

0,5 секунды

Константы хостов

MAX_RTR_SOLICITATION_DELAY

1 секунда

RTR_SOLICITATION_INTERVAL

4 секунды

MAX_RTR_SOLICITATIONS

3 передачи

Константы всех узлов

MAX_MULTICAST_SOLICIT

3 передачи

MAX_UNICAST_SOLICIT

3 передачи

MAX_ANYCAST_DELAY_TIME

1 секунда

MAX_NEIGHBOR_ADVERTISEMENT

3 передачи

REACHABLE_TIME

30 000 мсек

RETRANS_TIMER

1,000 мсек

DELAY_FIRST_PROBE_TIME

5 секунд

MIN_RANDOM_FACTOR

0,5

MAX_RANDOM_FACTOR

1,5

В разделе 4 определены форматы сообщений с дополнительными константами протокола. Любые константы могут измениться в будущих версиях протокола. Заданные спецификацией константы могут быть переопределены документами, описывающими работу IPv6 на конкретных канальных уровнях. Это правило позволяет ND работать на каналах с различными характеристиками.

11. Вопросы безопасности

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

11.1. Анализ угроз

В этом параграфе рассмотрены основные угрозы, связанные с ND, а более подробный анализ приведён в [PSREQ]. Основные уязвимости протоколы делятся на 3 категории: атаки на отказ в обслуживании (Denial-of-Service или DoS), атаки с подменой адресов и атаки с подменой маршрутизаторов.

Примером DoS-атаки является возможность находящегося на канале узла передавать пакеты с произвольным IP-адресом отправителя, анонсирующие узел как принятый по умолчанию маршрутизатор, а также отправлять поддельные анонсы RA, немедленно прекращающие срок действия всех других принятых по умолчанию маршрутизаторов на канале, а также всех префиксов. Злоумышленник может добиться этого, передавая множество RA, по ложному для каждого легитимного маршрутизатора, с адресом другого маршрутизатора в поле отправителя, Router Lifetime = 0, и нулевыми значениями Preferred Lifetime и Valid Lifetime для всех префиксов. Такая атака заставит все пакеты для получателей на канале и вне его проходить через обманный маршрутизатор, который может просматривать, менять или отбрасывать любые пакеты. Алгоритм NUD не увидит такую «чёрную дыру», пока обманный маршрутизатор корректно отвечает на зонды NUD анонсами NA с установленным флагом R.

Любой хост может организовать DoS-атаку на другой хост, препятствуя настройке адреса с помощью [ADDRCONF]. Протокол не позволяет хостам проверить, является ли отправитель NA действительным владельцем включённого в сообщение адреса IP.

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

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

В протоколе нет механизма управления полномочиями соседе передавать определённые типы сообщений (например, RA) и любой сосед (предположительно даже при наличии аутентификации) может передать анонсы RA, вызывающие отказ в обслуживании. Кроме того, любой сосед может передавать proxy NA, а также незапрошенные анонсы NA для организации DoS-атаки.

Многие канальные уровни также подвержены DoS-атакам, таким как постоянно занятый канал в сети CSMA/CD (детектирование несущей с обнаружением конфликтов) путём беспрерывной отправки пакетов DoS-атак, вставки в канал сигналов конфликта или порождения пакетов с чем-либо иным, нежели MAC-адрес отправителя с целью запутать, например, коммутаторы Ethernet. С другой стороны, многие из упомянутых здесь угроз менее эффективны или отсутствуют на каналах «точка-точка» и в сотовых сетях, где на канале имеется лишь один сосед, служащий принятым по умолчанию маршрутизатором.

11.2. Защита сообщений ND

Протокол снижает подверженность упомянутым выше атака при отсутствии аутентификации за счёт игнорирования пакетов ND от узлов вне канала. Поле Hop Limit во всех пакетах сравнивается с максимально допустимым значением 255. Поскольку маршрутизаторы декрементируют поле Hop Limit во всех пересылаемых пакетах, значение 255 говорит, что пакет получен от соседа.

Криптографическая защита ND выходит за рамки этого документа и описана в [SEND]. Можно также использовать IPsec для аутентификации на уровне IP [IPv6-SA]. Обмен ключами IKE (Internet Key Exchange) не подходит для создания защищённых связей, которые можно применить для защиты распознавания адресов или сообщений о запросе соседства, как указано в [ICMPIKE].

В некоторых случаях можно применить статические защищённые связи [IPv6-AUTH] или [IPv6-ESP] для защиты сообщений ND. Однако важно отметить, что статически заданные защищённые связи не расширяются (особенно на каналах с групповой адресацией), поэтому ограничены лишь небольшими сетями с известными хостами. В любом случае при использовании [IPv6-AUTH] или [IPv6-ESP] пакеты ND должны проверяться на предмет подлинности и не прошедшие проверку пакеты должны отбрасываться без уведомления.

12. Смена адресов

Протокол ND вместе с автоматической настройкой адресов IPv6 [ADDRCONF] помогает при смене адресов, позволяя ввести новые префиксы и адреса взамен прежних. Отказоустойчивость этих механизмов основана на том, что все узлы на канале своевременно получают анонсы RA. Однако хост может быть отключён или недоступен достаточно должно (например, несколько месяцев). В таких случаях можно обеспечить надёжную смену адресов, но это вносит ограничения на продолжительность анонсирования префиксов.

Рассмотрим пример, где префиксы анонсированы со сроком действия 2 месяца, но 1 августа принято решение о смене префикса 1 сентября. Это можно сделать путём снижения анонсируемого срока действия до 1 недели, начиная с 1 августа и постепенного снижения срока до анонсирование 1 сентября нулевого срока действия для префикса. Если один или несколько узлов были отключены от канала раньше 1 сентября, они могут считать, что срок действия префикса по-прежнему составляет 2 месяца. Таким образом, узел, отключенный 31 июля, будет считать, что префикс действует до 30 сентября. Единственным способом прекратить использование префикса, объявленного ранее с большим сроком действия, является получение узлом анонса, сокращающего срок действия префикса. В приведённом примере решение простое — анонсировать префикс с нулевым сроком действия в период с 1 сентября до 1 октября.

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

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

Администраторам следует серьёзно подумать о применении сравнительно коротких сроков действия (не более нескольких недель). Хотя может казаться, что долгий срок действия помогает обеспечить отказоустойчивость, на деле хост не сможет взаимодействовать с сетью без корректно работающих маршрутизаторов. Такие маршрутизаторы будут передавать анонсы RA с подходящим (и текущим) префиксом. Хост, подключенный к сети без работающих маршрутизаторов, очевидно столкнётся с более существенными проблемами, чем отсутствие действительного префикса и адреса.

Приведённые рассуждения относятся как к Preferred Lifetime, так и к Valid Lifetime. На практике вероятно будет достаточно отслеживать Preferred Lifetime, поскольку этот срок не выходит за пределы Valid Lifetime.

13. Взаимодействие с IANA

Этот документ не требует выделения новых типов или кодов ICMPv6, однако в имеющихся типах ссылка на RFC 2461 заменена ссылкой на этот документ. Процедура выделения значений для ICMPv6 описана в разделе 6 [ICMPv6].

Этот документ использует указанные ниже типы сообщений ICMPv6, определённые в RFC 2461 и выделенные IANA.

Имя	ICMPv6 Type
Router Solicitation	133
Router Advertisement	134
Neighbor Solicitation	135
Neighbor Advertisement	136
Redirect	137

Этот документ использует указанные ниже типы опций ND, которые определены в RFC 2461 и выделены IANA.

Имя	Тип
Source Link-Layer Address	1
Target Link-Layer Address	2
Prefix Information	3
Redirected Header	4
MTU	5

Правила выделения типов опций ND указаны ниже.

IANA следует выделять и регистрировать (постоянно) новые типы опций из IETF RFC, включая Standards Track, Informational и Experimental, исходящих от IETF и одобренных для публикации IESG.
При согласии рабочих групп IETF и одобрении руководителя направления можно запросить в IANA отзыв выделенного значения для типа опции ND. IANA будет помечать значение как reclaimable in future и такая пометка будет удаляться при публикации RFC с протоколом, как указано в п. 1). Это сделает назначение постоянным и обновит ссылку на Web-сайте IANA.

При использовании 85% пространства опций IETF будет пересматривать значения со статусом reclaimable in the future и информировать IANA о необходимости переназначения конкретных типов.
Запросы на выделение новых типов извне процессов IETF все равно выполняются путём публикации документа IETF, как указано в п. 1). Отметим, что документы, опубликованные как RFC Editor contributions [RFC3667], не считаются документами IETF.

14. Литература

14.1. Нормативные документы

[ADDR-ARCH] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006.

[IPv6] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460 ¹³, December 1998.

[KEYWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

14.2. Дополнительная литература

[ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, «IPv6 Stateless Address Autoconfiguration», RFC 4862, September 2007.

[ADDR-SEL] Draves, R., «Default Address Selection for Internet Protocol version 6 (IPv6)», RFC 3484, February 2003.

[ARP] Plummer, D., «Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware», STD 37, RFC 826, November 1982.

[ASSIGNED] Reynolds, J., Ed., «Assigned Numbers: RFC 1700 is Replaced by an On-line Database», RFC 3232, January 2002.

[DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

[HR-CL] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[ICMPIKE] Arkko, J., «Effects of ICMPv6 on IKE», Work in Progress, March 2003.

[ICMPv4] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, September 1981.

[IPv6-3GPP] Wasserman, M., Ed., «Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards», RFC 3314, September 2002.

[IPv6-CELL] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, «Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts», RFC 3316, April 2003.

[IPv6-ETHER] Crawford, M., «Transmission of IPv6 Packets over Ethernet Networks», RFC 2464, December 1998.

[IPv6-SA] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[IPv6-AUTH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[IPv6-ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M., and G. Harter, «IPv6 over Non-Broadcast Multiple Access (NBMA) networks», RFC 2491, January 1999.

[LD-SHRE] Hinden, R. and D. Thaler, «IPv6 Host-to-Router Load Sharing», RFC 4311, November 2005.

[MIPv6] Johnson, D., Perkins, C., and J. Arkko, «Mobility Support in IPv6», RFC 3775, June 2004.

[MLD] Deering, S., Fenner, W., and B. Haberman, «Multicast Listener Discovery (MLD) for IPv6», RFC 2710, October 1999.

[MLDv2] Vida, R., Ed., and L. Costa, Ed., «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, June 2004.

[PSREQ] Nikander, P., Ed., Kempf, J., and E. Nordmark, «IPv6 Neighbor Discovery (ND) Trust Models and Threats», RFC 3756, May 2004.

[RAND] Eastlake, D., 3rd, Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[RDISC] Deering, S., Ed., «ICMP Router Discovery Messages», RFC 1256, September 1991.

[RFC3667] Bradner, S., «IETF Rights in Contributions», RFC 3667, February 2004.

[RTSEL] Draves, R. and D. Thaler, «Default Router Preferences and More-Specific Routes», RFC 4191, November 2005.

[SH-MEDIA] Braden, B., Postel, J., and Y. Rekhter, «Internet Architecture Extensions for Shared Media», RFC 1620, May 1994.

[SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, «SEcure Neighbor Discovery (SEND)», RFC 3971, March 2005.

[SYNC] S. Floyd, V. Jacobson, «The Synchronization of Periodic Routing Messages», IEEE/ACM Transactions on Networking, April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z

Приложение A. Многодомные хосты

При использовании ND хостами с множеством интерфейсов возникает ряд осложнений. В этом разделе не предпринимается попыток определить подобающую работу многодомных хостов в части обнаружения соседей, а лишь отмечены проблемы, требующие дальнейшего изучения. Разработчикам рекомендуется поэкспериментировать с различными подходами к ND на многодомных хостах и поделиться своим опытом. Дополнительное рассмотрение этого вопроса приведено в [RTSEL].

Если многодомный хост получает анонсы RA на всех интерфейсах, он (вероятно) узнает на каждом канале префиксы относящихся к тому адресов. Однако при пересылке пакета через маршрутизатор выбор «неверного» маршрутизатора может привести на неоптимальных или неработающий путь. Следует рассмотреть приведённые ниже вопросы.

Чтобы маршрутизатор передал Redirect, он должен определить, что пересылаемый им пакет исходит от соседа. Стандартной проверкой в этом случае является сравнение адреса отправителя в пакете со списком префиксов на связанном с интерфейсом канале, откуда был принят пакет. Если хост-источник является многодомным, использованный адрес отправителя может относиться не к тому интерфейсу, который передал пакет. В этом случае маршрутизатор может не передать сообщений Redirect и вероятная неоптимальная маршрутизация. Для перенаправления передающий хост должен всегда отправлять пакеты с интерфейса, соответствующего адресу отправителя. Отметим, что этой проблемы не возникает на хостах с одним интерфейсом. Дополнительное обсуждение этого вопроса приведено в параграфе 3.3.4.2 RFC 1122.
Если выбранный первый маршрутизатор (first-hop) не имеет пути к адресату, он не сможет доставить пакет. Однако адресат может быть доступен через другой маршрутизатор на другом интерфейсе. В ND этот вопрос не решается, поскольку он не возникает на хостах с одним интерфейсом.
Даже при наличии у первого маршрутизатора пути к адресату, через другой интерфейс может существовать лучший путь. Для многодомных хостов нет механизма обнаружения такого маршрута.

Если многодомный хост не сможет получить анонсы RA на одном или нескольких интерфейсах, он не будет знать(при отсутствии настройки), какие получатели будут на канале соответствующего интерфейса. В результате возникает проблема — если RA получены на некоторых, но не всех интерфейсах, многодомный хост сможет отправлять пакеты лишь с интерфейсов, принявших RA. Принятое здесь важное допущение состоит в том, что маршрутизаторы для этих интерфейсов могут переслать пакеты конечному адресату, даже если этот адресат находится в подсети отправителя, но не имеет информации о префиксе on-link. Если это допущение не выполняется (FALSE) связи будет невозможна. Но даже при соблюдении этого условия путь пакетов будет неоптимальным.

Приложение B. Возможные расширения

Ниже перечислены вопросы для возможного расширения в будущем.

Использование динамических таймеров для работы на каналах с сильно меняющейся задержкой. Однако измерение времени кругового обхода требует подтверждений и порядковых номеров для сопоставления откликов NA с вызвавшими их запросами NS. Разработчики, желающие провести эксперименты с этим, могли бы сделать это совместимым путём, определив новую опцию с соответствующими данными. Узлы, не понимающие опцию, будут просто игнорировать её.
Добавление возможностей для облегчения работы по каналам, которые сейчас требуют от хостов регистрации на сервере распознавания адресов. Это может, например, позволить маршрутизаторам запрашивать у хостов периодическую отправку незапрошенных анонсов. Это тоже можно реализовать добавлением опции в RA.
Добавление дополнительных процедур для каналов в асимметричной и непереходной доступностью в обычный рабочий процесс. Такие процедуры могут позволить хостам и маршрутизаторам находить подходящие пути (например, радиоканалы.

Приложение C: Конечный автомат для статуса доступности

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

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

Состояние	Событие	Действие	Новое состояние
—	Пакет для передачи	Создание записи, отправка группового NS, запуск таймера повтора	INCOMPLETE
INCOMPLETE	Тайм-аут повтора, меньше N повторов	Повтор NS, запуск таймера повтора	INCOMPLETE
INCOMPLETE	Тайм-аут повтора, N или больше повторов	Отбрасывание записи, передача сообщения ICMP об ошибке	—
INCOMPLETE	NA, Solicited=0, Override=any	Запись адреса канального уровня, отправка пакетов из очереди	STALE
INCOMPLETE	NA, Solicited=1, Override=any	Запись адреса канального уровня, отправка пакетов из очереди	REACHABLE
INCOMPLETE	NA, Solicited=any, Override=any, нет адреса канального уровня	Обновление флага IsRouter	Не меняется
—	NS, RS, Redirect, нет адреса канального уровня	—	—
!INCOMPLETE	NA, Solicited=1, Override=0, в кэше тот же адрес канального уровня	—	REACHABLE
!INCOMPLETE	NA, Solicited=any, Override=any, нет адреса канального уровня	Обновление флага IsRouter	Не меняется
REACHABLE	NA, Solicited=1, Override=0, в кэше другой адрес канального уровня	—	STALE
STALE, PROBE или DELAY	NA, Solicited=1, Override=0, в кэше другой адрес канального уровня	—	Не меняется
!INCOMPLETE	NA, Solicited=1, Override=1	Запись адреса канального уровня (если он другой)	REACHABLE
!INCOMPLETE	NA, Solicited=0, Override=0	—	Не меняется
!INCOMPLETE	NA, Solicited=0, Override=1, в кэше тот же адрес канального уровня	—	Не меняется
!INCOMPLETE	NA, Solicited=0, Override=1, в кэше другой адрес канального уровня	Запись адреса канального уровня	STALE
!INCOMPLETE	Подтверждение доступности от вышележащего уровня	—	REACHABLE
REACHABLE	Тайм-аут, более N секунд после подтверждения доступности	—	STALE
STALE	Передача пакет	Запуск таймера задержки	DELAY
DELAY	Тайм-аут задержки	Передача индивидуального NS, запуск таймера повтора	PROBE
PROBE	Тайм-аут повтора, меньше N повторов	Повтор NS	PROBE
PROBE	Тайм-аут повтора, не меньше N повторов	Отбрасывание записи	—

Смена состояний при получении незапрошенных данных, отличных от NA, применяется к источнику пакета (для сообщений NS, RS и RA) или целевому адресу (для Redirect), как показано ниже.

Состояние	Событие	Действие	Новое состояние
—	NS, RS, RA, Redirect	Создание записи	STALE
INCOMPLETE	NS, RS, RA, Redirect	Запись адреса канального уровня, отправка пакета из очереди	STALE
!INCOMPLETE	NS, RS, RA, Redirect с отличающимся от кэшированного адресом канального уровня	Обновление адреса канального уровня	STALE
INCOMPLETE	NS, RS без адреса канального уровня	—	Не меняется
!INCOMPLETE	NS, RS, RA, Redirect с кэшированным адресом канального уровня	—	Не меняется

Приложение D. Сводка правил для IsRouter

В этом приложении приведена сводка правил поддержки флага IsRouter в соответствии с этим документом. Правила основаны на явном или неявном присутствии в сообщениях ND сведений о роли отправителя (или Target Address) — хост или маршрутизатор.

Отправитель анонса RA неявно считается маршрутизатором.
Запросы NS не содержат явного или неявного указания типа отправителя, их могут передавать хосты и маршрутизаторы.
Анонсы NA содержат явный флаг IsRouter (бит R).
Целью перенаправления, когда она не совпадает с адресом получателя в пакете для перенаправления, неявно считается маршрутизатором. Это естественное допущение, поскольку предполагается способность узла переслать пакеты в направлении получателя.
Цель перенаправления, совпадающая с адресом получателя, не содержит информации, является цель хостом или маршрутизатором. Известно лишь, что получатель (цель) находится на канале (on-link).

Правила установки флага IsRouter основаны на приведённой выше информации. Если сообщение ND содержит явное или неявное указание, приём такого сообщения вызовет обновление флага IsRouter. Однако при отсутствии в ND сведений (маршрутизатор или хост) недопустимо менять флаг IsRouter на основании сообщения. При создании записи Neighbor Cache в результате приёма сообщения данные документ задаёт для флага IsRouter значение FALSE. Корректное значение флага IsRouter в таких случаях определяет последующее сообщение NA или RA.

Приложение E. Вопросы реализации

E.1. Подтверждение доступности

Для механизма NUD требуется явное подтверждение доступности прямого пути к соседу. Для избавления от необходимости отправки пробных сообщений NS протоколам вышележащего уровня следует обеспечивать такую индикацию, когда затраты на это невелики. Ориентированные на соединения протоколы с гарантией доставки, такие как TCP, обычно знают о работоспособности прямого пути. Например, при передаче или приёме данных TCP обновляется окно порядковых номеров, запускаются и сбрасываются таймеры повтора и т. п. Ниже указаны конкретные примеры, где обычно указывается корректная работа прямого пути.

Приём подтверждения, включающего порядковый номер (например, данные), который ещё не был подтверждён, говорит о нормальной работе прямого пути в момент отправки данных.
Завершение трехэтапного согласования является частным случаем приведённого выше правила. Хотя при согласовании данные не передаются, флаги SYN с точки зрения порядковых номеров служат данными. Это относится как к SYN+ACK для активной стороны соединения, так и к ACK для пассивной.
Приём новых (т. е. не полученных ранее) данных указывает нормальную работу прямого пути в момент отправки подтверждения, которое привело к сдвигу окна передачи, позволившему отправить новые данные.

Для минимизации расходов на передачу сведений о доступности между уровнями TCP и IP реализация может ограничить частоту отправки подтверждений доступности. Одним из вариантов является обработка данных о доступности через несколько пакетов. Например, можно обновлять сведения о доступности 1 раз за период кругового обхода. Для реализаций, поддерживающих Destination Cache с блоками управления, возможно обновление записей NCE напрямую (т. е. без дорогостоящего поиска) по демультиплексированию пакета TCP в соответствующий блок управления. Для других реализаций может быть возможна привязка подтверждения доступности к представлению уровню IP следующего пакета при условии, что реализация принимает меры против устаревания привязанных подтверждений, когда пакеты не передаются уровню IP достаточно долго.

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

Для приложений UDP (RPC¹⁴, DNS) относительно просто заставить клиента передавать подтверждение доступности при получении пакета с откликом. Сложнее, а в некоторых случаях невозможно генерировать такие подтверждения при отсутствии управления потоком, когда сервер не может определить, указывает ли полученный запрос приём предыдущего отклика.

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

Приложение F. Отличия от RFC 2461

Удалены ссылки на IPsec AH и ESP для защиты сообщений и проверки полученных сообщений.
Добавлен параграф 3.3.
Обновлён раздел 11 включением подробного обсуждения угроз, ограничений IPsec и применения SEND.
Исключено допущение принадлежности к каналу в параграфе 5.2 в соответствии с 4943¹⁵ «IPv6 Neighbor Discovery On-Link Assumption Considered Harmful».
Разъяснено определение поля Router Lifetime в параграфе 4.2.
Обновлён текст параграфов 4.6.2 и 6.2.1 указанием на то, что значение Preferred Lifetime должно быть не больше Valid Lifetime.
Ссылка на настройку с учётом состояния заменена ссылкой на DHCPv6.
В параграф 6.2.1 добавлено определение флага IsRouter, позволяющего выступать хостом или маршрутизатором.
Мобильным узлам разрешено не вносить случайную задержку при отправке RS в процессе перехода (handover).
Обновлено определение размера префикса в опции Prefix.
Обновлены сведения о применимости к каналам NBMA во введении и добавлены ссылки на 3GPP RFC.
Указано, что распределение нагрузки доступно лишь на маршрутизаторах.
Разъяснено поведение маршрутизатора при получении RS без опции Source Link-Layer Address Option (SLLAO).
Отмечено, что проверка несогласованности CurHopLimit выполняется лишь при ненулевых значениях.
Изменён параграф 7.2.5 для прояснения и описания обработки NA в состоянии INCOMPLETE.
В параграф 7.2 добавлено разъяснение по части реагирования узлов на сообщения без опции SLLAO.
Добавлен раздел о взаимодействии с IANA.
Редакторские правки.

Благодарности

Авторы RFC 2461 хотели бы поблагодарить участников рабочей группы IPV6, в частности, (в алфавитном порядке) Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, Matt Thomas, Susan Thomson.

Редактор этого документа (Hesham Soliman) хотел бы поблагодарить рабочую группу IPV6 за большой вклад в этот документ, в частности, (в алфавитном порядке), Greg Daley, Elwyn Davies, Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola, Fred Templin, Christian Vogt.

Адреса авторов

Thomas Narten

IBM Corporation

P.O. Box 12195

Research Triangle Park, NC 27709-2195

USA

Phone: +1 919 254 7798

EMail: narten@us.ibm.com

Erik Nordmark

Sun Microsystems, Inc.

17 Network Circle

Menlo Park, CA 94025

USA

Phone: +1 650 786 2921

Fax: +1 650 786 5896

EMail: erik.nordmark@sun.com

William Allen Simpson

Daydreamer

Computer Systems Consulting Services

1384 Fontaine

Madison Heights, Michigan 48071

USA

EMail: william.allen.simpson@gmail.com

Hesham Soliman

Elevate Technologies

EMail: hesham@elevatemobile.com

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

Copyright (C) The IETF Trust (2007).

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Neighbor Discovery.

2Non-Broadcast Multi-Access — множественный доступ без широковещания.

3Internetwork Packet Exchange — межсетевой обмен пакетами.

4Switched Multimegabit Data Service — коммутируемые услуги передачи данных со скоростью во много Мбит/с.

5Broadband Integrated Services Digital Network — широкополосная цифровая сети с интеграцией услуг.

6Address Resolution Protocol — протокол распознавания адресов.

7Maximum Receive Unit — максимальный размер принимаемого блока.

8Neighbor Cache entry — кэш-запись для соседа.

9Least Recently Used — наиболее давно использовавшийся.

10В оригинале допущена ошибка, см. https://www.rfc-editor.org/errata/eid3154. Прим. перев.

11В оригинале ошибочно указано CurHopLimit, см. https://www.rfc-editor.org/errata/eid4461. Прим. перев.

12Denial-of-service — отказ в обслуживании.

13Заменен RFC 8200. Прим. перев.

14Remote Procedure Call — удаленный вызов процедуры.

15В оригинале ошибочно сказано RFC 4942, см. https://www.rfc-editor.org/errata/eid1317. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 5065 Autonomous System Confederations for BGP

Опубликовано 10.08.2007 автором Nikolai Malykh

Network Working Group                                      P. Traina
Request for Comments: 5065                        Blissfully Retired
Obsoletes: 3065                                         D. McPherson
Category: Standards Track                             Arbor Networks
                                                          J. Scudder
                                                    Juniper Networks
                                                         August 2007

Конфедерации автономных систем в BGP

Autonomous System Confederations for BGP

Статус документа

В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Аннотация

Протокол BGP (Border Gateway Protocol) представляет собой протокол маршрутизации между автономными системами, разработанный для сетей TCP/IP (Transmission Control Protocol/Internet Protocol). BGP требует, чтобы все узлы BGP в одной автономной системе (АС) были связаны между собой (fully meshed — каждый с каждым). Это требование порождает серьезные проблемы масштабирования, отмеченные в многочисленных документах.

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

Данный документ отменяет RFC 3065.

Оглавление

Исключено из версии HTML

1. Введение

В соответствии со спецификацией протокол BGP требует¹, чтобы каждый узел BGP в АС имел соединения со всеми другими узлами BGP в этой автономной системе (fully meshed). Результатом этого является необходимость поддержки каждым узлом BGP (в автономной системе с числом узлов n) n*(n-1)/2 уникальных сессий IBGP². Это требование полносвязности создает проблемы масштабирования для АС с большим числом узлов IBGP, обычным для многих современных сетей.

Эта проблема масштабирования описана во множестве документов и существует целый ряд предложений по ослаблению проблемы [RFC2796, RFC1863³]. В этом документе предлагается дополнительный способ ослабления проблемы полносвязности, известный как Autonomous System Confederations for BGP или просто BGP Confederations⁴. Можно также сказать, что конфедерации BGP могут повышать эффективность управления политикой маршрутизации.

Этот документ является пересмотром [RFC3065], который, в свою очередь пересматривает и отменяет [RFC1965]. Документ включает редакторские правки, разъяснения терминов и более явные спецификации протокола, основанные на опыте развертывания конфедераций BGP.

1.1. Спецификация требований

1.2. Терминология

AS Confederation — конфедерация АС

Группа автономных систем, анонсируемых с общим номером AS узлам BGP, не входящим в данную конфедерацию.

AS Confederation Identifier — идентификатор конфедерации АС

Видимый снаружи номер автономной системы, идентифицирующий конфедерацию в целом.

Member Autonomous System (Member-AS) — АС — член конфедерации

Автономная система, включенная в данную конфедерацию AS. Отметим, что термины Member Autonomous System и Member-AS в данном документе используются как синонимы.

Member-AS Number — номер АС — члена конфедерации

Номер автономной системы, видимый только членам данной конфедерации BGP и используемый для представления Member-AS внутри конфедерации.

2. Обсуждение

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

Кроме потенциального повышения уровня контроля за политикой маршрутизации (если не используются методы типа описанного здесь или в [RFC4456]) спецификация [BGP-4] требует, чтобы все узлы BGP одной автономной системы организовали полносвязную (full mesh) систему соединений TCP со всеми другими узлами для обмена внешней маршрутной информацией. В автономных системах число внутридоменных соединений, которые должен поддерживать каждый граничный маршрутизатор, может становиться весьма значительным.

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

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

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

Однако обычно не возникает необходимости в раскрытии внутренней топологии таких поделенных на части автономных систем и это означает, что возможно представление множества автономных систем с единым администрированием как единого объекта или АС с точки зрения находящихся за пределами данной конфедерации автономных систем.

3. Расширение AS_CONFED для типа сегмента

В действующей спецификации BGP сказано, что атрибут AS_PATH является общеизвестным обязательным атрибутом, состоящим из последовательности сегментов пути (AS path segment). Каждый сегмент пути представляется триплетом <path segment type, path segment length, path segment value>.

В [BGP-4] тип сегмента пути задается однооктетным полем, для которого определены следующие значения:

Значение	Имя	Описание
1	AS_SET	Неупорядоченный набор АС, через которые проходит маршрут из сообщения UPDATE.
2	AS_SEQUENCE	Упорядоченный набор АС, через которые проходит маршрут из сообщения UPDATE.

В настоящем документе определены два дополнительных типа сегментов пути:

Значение	Имя	Описание
3	AS_CONFED_SEQUENCE	Упорядоченный набор номеров Member AS в локальной конфедерации, через которые передается сообщение UPDATE.
4	AS_CONFED_SET	Неупорядоченный набор номеров Member AS в локальной конфедерации, через которые передается сообщение UPDATE.

4. Принцип работы

Член конфедерации BGP должен использовать свое значение AS Confederation ID во всех транзакциях с партнерами, которые не являются членами данной конфедерации. Этот идентификатор конфедерации рассматривается как видимый извне номер AS, который используется в сообщениях OPEN и анонсируется в атрибуте AS_PATH.

Член конфедерации BGP должен использовать свое значение Member-AS Number во всех транзакциях с партнерами, входящими в данную конфедерацию.

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

Узлу BGP, получившему атрибут AS_PATH с сегментами AS_CONFED_SEQUENCE или AS_CONFED_SET, содержащими его Member-AS Number, следует трактовать путь так же, как это делается для путей, содержащих номер AS данного узла.

4.1. Правила изменения AS_PATH

При реализации конфедераций BGP параграф 5.1.2 документа [BGP-4] заменяется приведенным ниже текстом.

AS_PATH представляет собой общеизвестный обязательный атрибут. Этот атрибут идентифицирует автономные системы, через которые передается маршрутная информация в данном сообщении UPDATE. Компонентами этого списка могут быть AS_SET, AS_SEQUENCE, AS_CONFED_SET и AS_CONFED_SEQUENCE.

Когда узел BGP распространяет маршрут, который был получен в сообщении UPDATE от другого узла BGP, он изменяет атрибут AS_PATH с учетом размещения узла BGP, которому передается маршрут:

Когда данный узел BGP анонсирует маршрут другому узлу BGP, расположенному в его Member-AS, анонсирующему узлу не следует изменять связанный с этим маршрутом атрибут AS_PATH.
Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, являющейся членом локальной конфедерации, анонсирующему узлу следует изменить атрибут AS_PATH как показано ниже.

Если первый сегмент AS_PATH имеет тип AS_CONFED_SEQUENCE, локальной системе следует поместить свой номер Member-AS, как последний элемент списка (в крайнюю левую позицию протокольного сообщения). Если при этом будет возникать переполнение сегмента AS_PATH (более 255 номеров АС), узлу следует добавить (prepend) новый сегмент типа AS_CONFED_SEQUENCE и поместить свой номер АС в этот сегмент.

Если первый сегмент AS_PATH имеет тип, отличный от AS_CONFED_SEQUENCE, локальная система помещает (prepend) новый сегмент типа AS_CONFED_SEQUENCE в путь AS_PATH, включив свой номер Member-AS в этот сегмент.

Если значение AS_PATH пусто, локальная система создает сегмент пути типа AS_CONFED_SEQUENCE, включает в него свой номер Member-AS и помещает этот сегмент в AS_PATH.

Когда данный узел BGP анонсирует маршрут узлу BGP, расположенному в соседней автономной системе, которая не входит в локальную конфедерацию, анонсирующему узлу следует изменить атрибут AS_PATH как показано ниже.

Если любые сегменты AS_PATH имеет тип AS_CONFED_SEQUENCE или AS_CONFED_SET, эти сегменты должны удаляться из атрибута AS_PATH и после этого для атрибута выполняется этап 2, 3 или 4 (см. ниже).

Если первый оставшийся сегмент AS_PATH имеет тип AS_SEQUENCE, локальная система добавляет (prepend) свой идентификатор конфедерации (AS Confederation Identifier) в качестве последнего элемента последовательности (в крайнюю левую позицию протокольного сообщения). Если при этом будет возникать переполнение сегмента AS_PATH (более 255 номеров АС), узлу следует добавить (prepend) новый сегмент типа AS_SEQUENCE и поместить свой номер АС в этот сегмент.

Если первый сегмент оставшейся части AS_PATH имеет тип AS_SET, локальная система добавляет (prepend) в AS_PATH новый сегмент типа AS_SET, включая в него свой идентификатор конфедерации.

Если оставшаяся часть AS_PATH пуста, локальная система создает сегмент пути типа AS_SEQUENCE, включает в него свой идентификатор конфедерации и помещает этот сегмент в AS_PATH.

Когда узел BGP является источником маршрута, этот узел:

включает свой идентификатор конфедерации АС в сегмент пути типа AS_SEQUENCE атрибутов AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в соседних АС, не являющихся членами локальной конфедерации; в этом случае идентификатор конфедерации автономной системы источника маршрута будет единственной записью в сегменте пути, а этот сегмент будет единственным в атрибуте AS_PATH;
включает ской номер Member-AS в сегмент пути типа AS_CONFED_SEQUENCE атрибутов AS_PATH всех сообщений UPDATE, передаваемых узлам BGP в соседних AS, являющихся членами локальной конфедерации; в этом случае Member-AS Number автономной системы источника маршрута будет единственной записью в сегменте пути, а этот сегмент будет единственным в атрибуте AS_PATH;
включает номер пустой атрибут AS_PATH во все сообщения UPDATE, передаваемые узлам BGP в той Member-AS (пустой атрибут AS_PATH содержит нулевое значение в поле размера).

Локальная система может включать/добавлять в начало более одного экземпляра идентификатора конфедерации или номера Member-AS в атрибут AS_PATH. Количество экземпляров задается локальной конфигурацией.

5. Обработка ошибок

Для узла BGP недопустимо передавать обновления, содержащие атрибуты AS_CONFED_SET или AS_CONFED_SEQUENCE, партнерам, которые не входят в локальную конфедерацию.

Получение узлом BGP сообщения UPDATE с атрибутом AS_PATH, включающим сегменты AS_CONFED_SEQUENCE или AS_CONFED_SET от соседа, не относящегося к той же конфедерации, является ошибкой. Если узел BGP получает такое сообщение UPDATE, следует трактовать его, как сообщение с некорректным атрибутом AS_PATH в соответствии с процедурами [BGP-4] (параграф 6.3 «Обработка ошибок в сообщениях UPDATE»).

Ошибкой является получение узлом BGP обновления от партнера по конфедерации, не относящегося к той же Member-AS, в котором нет AS_CONFED_SEQUENCE в качестве первого сегмента. Если узел BGP получает такое сообщения UPDATE, следует трактовать его, как сообщение с некорректным атрибутом AS_PATH в соответствии с процедурами [BGP-4] (параграф 6.3 «Обработка ошибок в сообщениях UPDATE»).

5.1. Общие вопросы администрирования

Для АС, являющихся членами конфедерации, разумно в рамках конфедерации использовать единое администрирование и информацию IGP⁵. Разумно также для каждой Member-AS использовать независимый протокол IGP. В последнем случае может потребоваться установка NEXT_HOP с использованием политики (по умолчанию это значение не меняется).

5.2. Обработка MED и LOCAL_PREF

Узлам BGP следует разрешить анонсирование без изменения атрибутов NEXT_HOP и MULTI_EXIT_DISC (MED) партнерам из соседних Member-AS, входящих в ту же конфедерацию.

Значения MED двух маршрутов следует сравнивать только в случаях совпадения первой АС в первом сегменте AS_SEQUENCE обоих маршрутов (т. е., все АС в AS_CONFED_SET и AS_CONFED_SEQUENCE пропускаются). Реализация может обеспечивать возможность настройки выбора пути таким образом, чтобы значения MED двух маршрутов были сравнимы, если первые АС в атрибутах AS_PATH совпадают, независимо от сегментов AS_SEQUENCE или AS_CONFED_SEQUENCE в AS_PATH.

Реализация может сравнивать значения MED, полученные из Member-AS через множество путей. Реализация может сравнивать значения MED из различных АС, относящихся к одной конфедерации.

В дополнение к этому отменяется ограничение на передачу атрибута LOCAL_PREF партнерам из соседних AS своей конфедерации.

5.3. AS_PATH и выбор пути

Критерии выбора пути для информации, полученной от членов конфедерации, должны следовать тем же правилам, которые используются для информации, полученной от партнеров в своей АС, как задано в [BGP-4].

В дополнение к этому следует применять перечисленные ниже правила:

если AS_PATH является внутренним по отношению к локальной конфедерации (т. е., содержит только сегменты AS_CONFED_*), соседняя АС рассматривается, как локальная АС;
в остальных случаях, если первый сегмент пути не относится к типу AS_CONFED_SEQUENCE или AS_CONFED_SET является AS_SEQUENCE, соседняя АС рассматривается, как самая левая в списке AS_SEQUENCE;
при сравнении маршрутов по длине AS_PATH сегменты CONFED_SEQUENCE и CONFED_SET не следует учитывать;
при сравнении маршрутов с использованием внутренних (полученных от IBGP) и внешних (от EBGP) данных, маршрут, полученный от партнера в той же конфедерации (не обязательно в той же Member-AS), трактуется как «внутренний».

6. Вопросы совместимости

Все включенные в конфедерацию узлы BGP должны распознавать расширения типа сегмента AS_CONFED_SET и AS_CONFED_SEQUENCE в атрибутах AS_PATH.

Любой узел BGP, не поддерживающий эти расширения, будет генерировать сообщение NOTIFICATION с кодом ошибки UPDATE Message Error и субкодом Malformed AS_PATH.

Перечисленные выше проблемы совместимости требуют от всех включаемых в конфедерацию узлов BGP поддержки данного расширения (BGP confederations). Однако от узлов BGP за пределами конфедерации такой поддержки не требуется.

7. Развертывание конфедераций

Конфедерации BGP широко распространены в сети Internet уже много лет и поддерживаются множеством производителей.

Некорректная настройка конфедерации BGP может приводить к ненужному дублированию маршрутной информации внутри AS. Такое дублирование будет отнимать системные ресурсы, приводить к ненужным переключениям маршрутов (flap) и увеличивать задержку схождения (convergence).

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

В [RFC3345] показано, что конфедерации (как и рефлекторы маршрутов), исключая из рассмотрения информацию о доступности в различных точках конфедерации, могут вызывать постоянные осцилляции между маршрутами-кандидатами при использовании правил «развязывания узлов» (tie breaking), требуемых спецификацией [BGP-4]. Следует с осторожностью относиться к выбору значений MED и правилам tie breaking для предотвращения проблем.

Одним из способов предотвращения проблем является установка для метрики inter-Member-AS IGP⁶ значения большего, нежели для метрики intra-Member-AS IGP⁷, и/или использование иных правил tie breaking для предотвращения выбора маршрутов BGP на основе несравнимых MED.

8. Вопросы безопасности

Это расширение не оказывает влияния на вопросы безопасности протокола BGP, рассмотренные в [RFC2385] и [BGP-VULN].

9. Благодарности

Общая концепция конфедераций BGP была заимствована из Routing Domain Confederations для IDRP [ISO10747]. Часть вводного текста этого документа была заимствована из [RFC2796].

Авторы выражают свою признательность Jeffrey Haas за многочисленные отзывы. Мы также благодарим Bruce Cole, Srihari Ramachandra, Alex Zinin, Naresh Kumar Paliwal, Jeffrey Haas, Cengiz Alaettinoglu, Mike Hollyman и Bruno Rijsman за их отзывы и предложения.

Авторы также выражают свою признательность Ravi Chandra и Yakov Rekhter за конструктивные и полезные замечания в процессе работы с ранними версиями этого документа.

10. Литература

10.1. Нормативные документы

[BGP-4] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1965] Traina, P., «Autonomous System Confederations for BGP», RFC 1965, June 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 3065, February 2001.

10.2. Дополнительная литература

[ISO10747] Kunzinger, C., Editor, «Inter-Domain Routing Protocol», ISO/IEC 10747, October 1993.

[RFC1863] Haskin, D., «A BGP/IDRP Route Server alternative to a full mesh routing», RFC 1863, October 1995.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, «Border Gateway Protocol (BGP) Persistent Route Oscillation Condition», RFC 3345, August 2002.

[RFC4223] Savola, P., «Reclassification of RFC 1863 to Historic», RFC 4223, October 2005.

[RFC4272] Murphy, S., «BGP Security Vulnerabilities Analysis», RFC 4272, January 2006.

[RFC4456] Bates, T., Chen, E., and R. Chandra, «BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)», RFC 4456, April 2006.

Приложение A. Агрегирование маршрутной информации

Как практическая задача, агрегирование, рассмотренное в [BGP-4] (параграф 9.2.2.2), в общем случае нечасто используется с конфедерациями. Однако при использовании такого агрегирования в конфедерации, следует выполнять правила [BGP-4] с заменой AS_SET на AS_CONFED_SET и AS_SEQUENCE на AS_CONFED_SEQUENCE. Относящиеся к конфедерациям сегменты (AS_CONFED_SET и AS_CONFED_SEQUENCE) должны сохраняться отдельно от не связанных с конфедерациями сегментов (AS_SET и AS_SEQUENCE). Реализация может также выюрать форму агрегирования, при которой не связанные с конфедерациями сегменты агрегируются в соответствии с [BGP-4] (параграф 9.2.2.2), а относящиеся к конфедерациям сегменты не агрегируются.

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

Приложение B. Отличия от RFC 3065

Основной причиной обновления RFC 3065 послужили вопросы, связанные с обработкой сегментов пути, — в частности, взаимодействие с внешними по отношению к конфедерации партнерами BGP и предотвращение анонсирования сегментов типа AS_CONFED_[SET|SEQUENCE] за пределы конфедерации.

В связи с этим был добавлен раздел 5. Обработка ошибок, относящийся ко всем узлам BGP, а не только к членам конфедерации.

К числу других изменений относятся некоторое разъяснение и уточнение терминологии и указание того, что обработку сегментов типа AS_CONFED_[SET|SEQUENCE] следует выполнять в соответствии с базовой спецификацией [BGP-4].

Адреса авторов

Paul Traina

Blissfully Retired

Email: bgp-confederations@st04.pst.org

Danny McPherson

Arbor Networks

EMail: danny@arbor.net

John G. Scudder

Juniper Networks

EMail: jgs@juniper.net

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

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

2Internal BGP — внутренний (по отношению к АС) протокол BGP.

3RFC 4223 перевел этот документ в состояние historic (достояние истории).

4Конфедерации автономных систем для BGP или просто BGP-конфедерации

5Interior Gateway Protocol — протокол внутренней маршрутизации.

6Протокол внутренней маршрутизации между членами конфедерации.

7Протокол внутренней маршрутизации для входящих в конфедерацию AS.

Рубрика: RFC | Оставить комментарий

RFC 4995 The RObust Header Compression (ROHC) Framework

Опубликовано 05.07.2007 автором Nikolai Malykh

Заменен RFC 5795.

Рубрика: RFC | Комментарии отключены

RFC 4893 BGP Support for Four-octet AS Number Space

Опубликовано 09.05.2007 автором Nikolai Malykh

Network Working Group                                       Q. Vohra
Request for Comments: 4893                          Juniper Networks
Category: Standards Track                                    E. Chen
                                                       Cisco Systems
                                                            May 2007

Поддержка 4-октетных номеров AS в BGP

BGP Support for Four-octet AS Number Space

Статус документа

В этом документе содержится проект стандарта Internet, предложенного сообществу Internet, и запрос обсуждения с целью развития предложенного протокола. Текущее состояние стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Аннотация

В настоящее время автономные системы (AS¹) в протоколе BGP представляются 2-октетными значениями. В этом документе рассматривается расширение протокола BGP, позволяющее использовать четырехоктетные номера AS.

1. Введение

В настоящее время автономные системы (AS) в протоколе BGP [BGP] представляются 2-октетными значениями. Для решения проблемы нехватки двухоктетных номеров AS в этом документе предлагается расширение протокола BGP, позволяющее использовать 4-октетные номера AS.

Говоря точнее, этот документ определяет новую возможность протокола BGP — Four-octet AS Number Capability, которая может использоваться узлом BGP для индикации поддержки этим узлом четырехоктетных номеров AS. Для реализации новой возможности добавляются два новых атрибута AS4_PATH и AS4_AGGREGATOR, которые могут использоваться для распространения 4-октетных номеров AS в атрибутах пути между узлами BGP, которые не поддерживают этого расширения. В документе также предложен механизм представления информации о путях с использованием атрибутов AS_PATH и AS4_PATH.

Предложенное в этом документе расширение протокола обеспечивает возможность постепенного перехода к использованию 4-октетных номеров AS.

2. Уровни требований

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [RFC2119].

3. Расширение протокола

В этом документе узлы BGP, не поддерживающие 4-октетные номера AS, будет называться старыми узлами BGP, а поддерживающие расширение узлы — новыми узлами BGP.

BGP передает номера автономных систем в поле My Autonomous System сообщений OPEN, а также в атрибутах AS_PATH и AGGREGATOR сообщений UPDATE. Кроме того, номера автономных систем BGP включаются в атрибуты BGP Communities.

Новые узлы BGP используют BGP Capability Advertisement [RFC2842] для анонсирования своим соседям (внутренним или внешним) поддержки 4-октетных номеров AS, описанной в данном документе.

Возможность (Capability), используемая узлом BGP для передачи другим узлам BGP информации о поддержке 4-октетных номеров AS, также использует передачу 4-октетного номера AS данного узла в поле Capability Value дополнительного параметра (Capability Optional Parameter). Поле Capability Length для Capability имеет значение 4.

Новые узлы BGP передают информацию о пути в виде 4-октетных номеров AS с использованием существующего атрибута AS_PATH, но каждый номер AS в таком атрибуте представляется 4-октетным значением вместо 2-октетного. Для атрибута AGGREGATOR новые узлы BGP также используют 4-октетные номера AS вместо 2-октетных.

Для передачи информации о пути через старые узлы BGP в данном документе определен новый атрибута пути — AS4_PATH. Этот дополнительный переходный атрибут содержит значение AS path, представленное 4-октетными номерами AS. Атрибут AS4_PATH семантически не отличается от атрибута AS_PATH, но относится к числу дополнительных переходных атрибутов и использует 4-октетные номера AS.

Для предотвращения возможности распространения внутренних сегментов путей конфедераций за пределы этих конфедераций, типы сегментов пути AS_CONFED_SEQUENCE и AS_CONFED_SET [RFC3065] для атрибута AS4_PATH считаются некорректными.

Для выполняющих агрегирование новых узлов BGP в документе определен дополнительный переходный атрибут AS4_AGGREGATOR. Семантика атрибутов AS4_AGGREGATOR и AGGREGATOR одинакова, но первый использует 4-октетный номер AS.

Выделенные к настоящему времени 2-октетные номера AS преобразуются в 4-октетные номера AS путем установки в 0 двух старших октетов номера. Такие 4-октетные номера AS могут быть отображены на 2-октетные номера AS.

Для представления 4-октетных номеров AS с отличными от 0 старшими октетами (такие номера не отображаются на 2-октетные) в информации AS path, содержащей 2-октетные номера AS, в настоящем документе резервируется специальный 2-октетный номер AS. Этот специальный номер AS в остальной части спецификации будет обозначаться AS_TRANS. Этот номер также включается в поле «My Autonomous System» сообщений OPEN, инициируемых новым узлом BGP, если последний не имеет уникального в глобальном масштабе 2-октетного номера AS.

4. Операции

4.1. Взаимодействие между новыми узлами BGP

Узлам BGP, поддерживающим 4-октетные номера AS, следует анонсировать эту возможность с использованием BGP Capability Advertisement. Узел BGP, который анонсировал тому или иному партнеру такую возможность и получил от партнера аналогичный анонс, должен использовать 4-октетные номера AS в атрибутах AS_PATH и AGGREGATOR обновлений, передаваемых этому партнеру, а в принятых от того обновлениях должен рассматривать эти атрибуты, как содержащие 4-октетные номера AS.

Новые атрибуты AS4_PATH и AS4_AGGREGATOR не следует передавать в сообщениях UPDATE между новыми узлами BGP. Новому узлу BGP, получившему атрибуты AS4_PATH или AS4_AGGREGATOR в сообщении UPDATE от нового узла BGP, следует отбросить эти атрибуты и продолжить обработку сообщения UPDATE.

4.2. Взаимодействие между новыми и старыми узлами BGP

4.2.1. Партнерство BGP

Отметим, что партнерские отношения между новым и старым узлами BGP возможны только в том случае, когда новый узел BGP имеет 2-октетный номер AS. Однако в этом документе не предполагается, что каждому новому узлу BGP требуется выделить уникальный 2-октетный номер AS — вместо этого предлагается специальный номер AS_TRANS, который может использоваться множеством AS.

4.2.2. Генерация обновлений

При взаимодействии со старыми узлами BGP новый узел должен передавать информацию о пути в атрибутах AS_PATH с 2-октетными номерами AS. Новый узел должен также передавать информацию о пути в атрибутах AS4_PATH (с 4-октетными номерами AS) за исключением тех случаев, когда вся информация о пути представлена 2-октетными номерами AS. В последнем случае новому узлу BGP не следует передавать атрибут AS4_PATH.

В атрибуте AS_PATH с 2-октетными номерами AS, неотображаемые на 2 октета 4-октетные номера AS представляются общеизвестным 2-октетным номером AS_TRANS. Это позволяет сохранить размер пути и помогает обновить информацию о пути полученную новым узлом BGP от старого узла, как описано в следующем параграфе.

Новый узел BGP создает атрибут AS4_PATH из информации, содержащейся в атрибуте AS_PATH. В случаях, когда атрибут AS_PATH содержит сегменты пути AS_CONFED_SEQUENCE или AS_CONFED_SET, новый узел BGP при создании атрибута AS4_PATH из AS_PATH должен исключить такие сегменты пути. Атрибут AS4_PATH будет передаваться через старые узлы BGP без изменения и поможет корректно восстановить 4-октетные номера AS в информации о пути.

Подобно этому, если новый узел передает атрибут AGGREGATOR и агрегирующая система имеет 4-октетный номер, узел создает AS4_AGGREGATOR, беря размер и значение атрибута AGGREGATOR, помещает их в атрибут AS4_AGGREGATOR и устанавливает в поле номера AS атрибута AGGREGATOR зарезервированное значение AS_TRANS. Отметим, что для 2-октетного номера AS использовать атрибут AS4_AGGREGATOR не следует.

4.2.3. Обработка полученных обновлений

Когда новый узел BGP получает обновление от старого узла, ему следует быть готовым к обработке атрибутов AS4_PATH, наряду с AS_PATH. При наличии AS4_PATH оба атрибута будут использоваться для восстановления точной информации о пути и, следовательно, информация из обоих типов атрибутов будет приниматься во внимание при определении петель.

Отметим, что маршрут может проходить через последовательность автономных систем с 2-октетными номерами, в которых используются только старые узлы BGP. В этом случае, если маршрут содержит атрибут AS4_PATH, этот атрибут должен сохраняться в неизменном виде после того, как маршрут покинет последний новый узел BGP. Последующая информация о пути (представляющая автономные системы с 2-октетными номерами AS и только старыми узлами BGP) содержится только в текущем атрибуте AS_PATH (начальная часть атрибута AS_PATH).

При некоторых условиях восстановление полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда два или более маршрута, содержащие атрибут AS4_PATH, агрегируются старым узлом BGP, а атрибут AS4_PATH по крайней мере одного из таких маршрутов содержит по крайней мере один 4-октетный номер AS (в противоположность 2-октетному номеру AS, представленному 4 октетами). В зависимости от реализации при агрегировании может быть потерян атрибут AS4_PATH или оба атрибута AS_PATH и AS4_PATH будут содержать корректную частичную информацию, которая не может быть объединена без разрывов, приводящих к неполноте информации о пути.

Новому узлу BGP следует также быть готовым к получению от старого узла BGP атрибута AS4_AGGREGATOR вместе с атрибутом AGGREGATOR. При получении обоих атрибутов, если номер AS в атрибуте AGGREGATOR не совпадает с AS_TRANS:

атрибуты AS4_AGGREGATOR и AS4_PATH следует игнорировать;
атрибут AGGREGATOR следует трактовать как информацию об агрегирующем узле;
атрибут AS_PATH следует трактовать как информацию о пути.

В остальных случаях:

атрибут AGGREGATOR следует игнорировать;
атрибут AS4_AGGREGATOR следует трактовать как информацию об агрегирующем узле;
информацию о пути следует конструировать как во всех остальных случаях.

Для конструирования информации о пути необходимо сначала рассчитать номера AS в атрибутах AS_PATH и AS4_PATH с использованием метода, описанного в параграфе 9.1.2.2 документа [BGP] и документе [RFC3065] для выбора маршрута.

Если число номеров AS в атрибуте AS_PATH меньше числа номеров AS в AS4_PATH, атрибут AS4_PATH следует игнорировать, а атрибут AS_PATH следует трактовать как информацию о пути.

Если число номеров AS в атрибуте AS_PATH больше или равно числу номеров AS в AS4_PATH, информацию о пути следует восстанавливать, принимая столько номеров AS и сегментов пути из атрибута AS_PATH, сколько требуется и добавляя их в начало (prepend) атрибута AS4_PATH так, чтобы в результате число номеров AS в информации о пути совпадало с числом номеров AS в атрибуте AS_PATH. Отметим, что перед корректными сегментами пути AS_CONFED_SEQUENCE или AS_CONFED_SET следует добавлять (prepend) информацию, если сегмент является первым в пути или смежным с сегментом, перед которым добавляется информация.

5. Обслуживание групп BGP

Как отмечено в [RFC1997], два старших октета атрибута группы (community attribute) не могут принимать значения 0x0000 или 0xffff, в этих двух октетах указывается номер AS. Понятно, что это условие не будет работать для узлов BGP, которые используют 4-октетные номера AS. Таким узлам BGP следует использовать специальное расширение Four-octet AS Specific Extended Communities [AS-EXT-COM] .

6. Переход

Описанная в этом документе схема обеспечивает возможность постепенного перехода от 2-октетных номеров AS к 4-октетным номерам. Каждая AS или узел BGP могут переходить к 4-октетным номерам независимо.

Для упрощения перехода в этом документе предполагается, что автономная система может начать использование 4-октетного номера только после того, как все узлы BGP в этой AS будут готовы к поддержке 4-октетных номеров AS.

Старым узлам BGP недопустимо использовать значение AS_TRANS в качестве своего номера AS.

Неотображаемый 4-октетный номер AS не может использоваться как «Member AS Number» в конфедерации BGP, пока все узлы BGP в масштабе этой конфедерации не будут готовы к поддержке 4-октетных номеров AS.

В среде, где автономная система со старыми узлами BGP имеет партнерские отношения по крайней мере с двумя автономными системами, где имеются новые узлы BGP и используется значение AS_TRANS (взамен уникального номера AS), применение атрибутов Multi-Exit Discriminator автономной системой со старыми узлами может приводить к возникновению ситуаций, когда атрибут MED будет влиять на выбор маршрута среди маршрутов, полученных из разных соседних AS.

В некоторых условиях реконструирование полной информации о пути из атрибутов AS_PATH и AS4_PATH может оказаться невозможным. Это происходит в тех случаях, когда по крайней мере два маршрута, передающих атрибут AS4_PATH, агрегируются старым узлом BGP и атрибут AS4_PATH по крайней мере одного из таких маршрутов содержит хотя бы один 4-октетный номер AS (в противоположность 2-октетным номерам, представленным 4 октетами). Когда такое агрегирование приводит к созданию маршрута, являющегося менее специфичным, чем любая из компонент агрегирования (значение NLRI агрегированного маршрута покрывает NLRI всех компонент), потеря информации о пути не создает риска возникновения петли. В остальных случаях потеря информации о пути может приводить к возникновению петли.

7. Взаимодействие с IANA

Этот документ расширяет пространство номеров AS с 0 — 65535 до 0 — 4294967295. Распределение номеров AS фиксируется в реестре IANA Autonomous System Numbers. Кроме расширения пространства номеров AS в данном документе не предлагается каких-либо изменений существующих правил и процедур распределения номеров AS.

Этот документ использует код BGP Capability для индикации поддержки узлом BGP 4-октетных номеров AS. Выделенное IANA в соответствии с RFC 2842 значение кода равно 65.

Кроме того, в этом документе определены два новых дополнительных переходных атрибута BGP, коды которых согласуются с IANA. Для атрибута AS4_PATH выделено значение 17, которое используется для передачи информации AS path с 4-октетными номерами AS через старые системы BGP. Для второго атрибута AS4_AGGREGATOR выделено значение 18. Этот атрибут используется подобно AGGREGATOR, но содержит 4-октетный номер AS.

В этом документе резервируется также 2-октетный номер AS — AS_TRANS. Для AS_TRANS агентством IANA выделено значение 23456.

8. Вопросы безопасности

Расширение BGP не меняет состояния безопасности существующего протокола BGP за исключением указанного ниже.

Несогласованность атрибутов AS_PATH и AS4_PATH может приводить к возникновению петель в информации AS path и, потенциально, в маршрутах, как отмечено выше. Эта особенность может быть использована для организации атак.

9. Благодарности

Авторы благодарят Yakov Rekhter, Chaitanya Kodeboyina и Jeffrey Haas за плодотворные дискуссии при подготовке документа.

10. Нормативные документы

[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC1997] Chandra, R., Traina, P., and T. Li, «BGP Communities Attribute», RFC 1997, August 1996.

[RFC3392] Chandra, R. and J. Scudder, «Capabilities Advertisement with BGP-4», RFC 3392 ², November 2002.

[RFC3065] Traina, P., McPherson, D., and J. Scudder, «Autonomous System Confederations for BGP», RFC 3065³, February 2001.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

11. Дополнительные ссылки

[AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, «Four-octet AS Specific BGP Extended Community», Work in Progress⁴, April 2007.

Адреса авторов

Quaizar Vohra

Juniper Networks

1194 N.Mathilda Ave

Sunnyvale, CA 94089

EMail: quaizar.vohra@gmail.com

Enke Chen

Cisco Systems, Inc.

170 W. Tasman Dr.

San Jose, CA 95134

EMail: enkechen@cisco.com

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.

1Autonomous System — автономная система.

2Этот документ заменен RFC 5492. Прим. перев.

3Этот документ заменен RFC 5065. Прим. перев.

4Работа опубликована в RFC 5668. Прим. перев.

Сохранить

Рубрика: RFC | Оставить комментарий

RFC4833 Timezone Options for DHCP

Опубликовано 25.04.2007 автором Nikolai Malykh

Network Working Group                                            E. Lear
Request for Comments: 4833                            Cisco Systems GmbH
Updates: 2132                                                  P. Eggert
Category: Standards Track                                           UCLA
                                                              April 2007

Опции часового пояса для DHCP

Timezone Options for DHCP

Статус документа

Авторские права

Аннотация

Двумя основными способами обмена информацией о часовых поясах являются строки POSIX 1003.1 timezone и имена в базе данных timezone. Этот документ задает опции DHCP для каждого из этих методов. Использование опции DHCPv4 time offset прекращается.

1. Введение

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

POSIX-строка TZ;
ссылка на имя записи для часового пояса в базе данных TZ.

Стандарт POSIX [1] обеспечивает способ представления часового пояса в форме строки. Использование таких строк позволяет осуществлять точный переход между летним и зимним временем (DST¹), а также другие случаи перевода часов, которые происходят регулярно (например, во второе воскресенье марта в 02:00 по местному времени). Однако для переходов с более длительными периодами, которые включают изменение правил перехода на летнее время, я также для нерегулярных переходов требуются другие механизмы.

База данных TZ [7], используемая во многих операционных системах, обеспечивает совместимость со старыми версиями, а также требуемую точность перехода для большинства мест планеты и времени с 1970 года. База данных TZ также пытается обеспечить понятный для человека набор идентификаторов часовых поясов. Кроме того, многие системы уже используют базу данных TZ и имена часовых поясов стали фактически стандартными. Поскольку база данных TZ содержит больше информации, можно эвристически вывести информацию POSIX из идентификатора TZ (см., например, [10]), но не наоборот.

1.1. Смежные работы

Протокол DHCP² [3] обеспечивает хостам возможность получения конфигурационной информации, относящейся к конкретному местоположению в сети IP версии 4. Аналогично поддерживается и настройка хостов IP версии 6 [5]. В RFC 2132 [4] задана опция для предоставления клиенту информации о часовом поясе в форме смещения относительно времени UTC в секундах. Предоставляемой этой опцией информации не достаточно для определения клиентом настроек летнего времени и перехода между летним и зимним временем. Для того, чтобы клиент мог точно установить местное время, серверам DHCP следует учитывать переход DST при определении срока действия аренды.

Кроме того, смещения недостаточно для определения реального часового пояса, к которому относится клиент, и в результате нет возможности получить понятное человеку обозначение часового пояса типа EST или EDT.

В спецификации iCalendar [9] определены элементы VTIMEZONE. При полном задании они обеспечивают уровень точности, схожий с базой данных TZ. Однако по причине отсутствия глобального реестра VTIMEZONE TZID (хотя один из возможных реестров предложен в [8]) для точного указания часового пояса требуется указать запись полностью. Для обеспечения нужной информации потребуется не менее 300 октетов, а верхней границы просто нет. Кроме того, на момент подготовки этого документа авторам не было известно ни одной операционной системы, изначально использующей записи VTIMEZONE. Можно включить опцию для TZURL. Однако при «холодном старте» это будет сильно нагружать серверы DHCP и другие компоненты.

2. Новые опции часового пояса для DHCPv4

Ниже показаны две новых опции, определенные для протокола DHCPv4.

            PCode  Len   TZ-POSIX String
           +-----+-----+------------------------------+
           | 100 |  N  | Строка IEEE 1003.1           |
           +-----+-----+------------------------------+

            TCode  Len   TZ-Database String
           +-----+-----+------------------------------+
           | 101 |  N  | Ссылка на TZ Database        |
           +-----+-----+------------------------------+

В соответствии с RFC 2939 [6] агентство IANA выделило значения PCode (100) и TCode (101).

Поле Len содержит 1-октетное значение, которое указывает размер следующей за полем строки в каждой из опций.

Значения строк, следующих за полем Len описаны ниже. Отметим, что они не завершаются символом ASCII NULL.

3. Новые опции часового пояса для DHCPv6

Семантика и содержимое представления этих опций в DHCPv6 в точности совпадают с описанными для DHCPv4 с учетом различий в способах кодирования опций DHCPv4 и DHCPv6.

Представление новых опций часового пояса в DHCPv6 показано ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_POSIX_TIMEZONE    |         option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      TZ POSIX String                          |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_NEW_POSIX_TIMEZONE(41)

option-length

Число октетов TZ POSIX String, описанной ниже.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_TZDB_TIMEZONE    |          option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          TZ Name                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_NEW_TZDB_TIMEZONE(42)

option-length

Число октетов TZ Database String, описанной ниже.

4. POSIX-строка TZ

POSIX-строка TZ представляет собой строку, подходящую для переменной TZ, в соответствии с параграфом 8.3 [1] за исключением того, что эта строка не должна начинаться с двоеточия (:). Строка не завершается символом ASCII NULL. Пример строки приведен ниже.

   EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

Эта строка описывает часовой пояс, отстающий от UTC на 5 часов в обычный период (зимой) и на 4 в период DST (летом), который начинается во второе воскресенье марта в 02:00 по местному времени и заканчивается в первое воскресенье ноября в 02:00 по местному времени. В обычный период этот часовой пояс обозначается EST, а в период DST — EDT.

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

5. TZ Name

TZ Name представляет собой имя записи Zone в базе данных, которую обычно называют базой данных TZ. В частности, при текстовом формате базы данных строка указывает поле name в строке часового пояса. Для использования этой опции у клиента должна быть копия базы данных. Строка не завершается символом ASCII NULL.

Примером может служить строка Europe/Zurich.

Для использования этой опции у клиента уже должна быть копия TZ Database. Конфигурация базы данных выходит за рамки этого документа. Клиентам, поддерживающим эту опцию, следует предпочитать ее строке POSIX, если он распознает возвращенную строку TZ Name. Если строка TZ Name не распознана, клиент должен игнорировать опцию.

6. Использование строк, возвращенных сервером

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

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

От клиентов не требуется реализация обоих вариантов, а серверу, поддерживающему одну из этих опций, следует реализовать и другую. Связь между опциями может быть организована администратором системы. Базовый сервер может передавать клиентам значения опций без их анализа и проверки пригодности. Более функциональный сервер может иметь копию базы данных TZ и сравнивать значения TZ name с имеющейся копией или эвристически выводить POSIX-строки TZ из строк TZ name для упрощения администрирования.

На практике клиент будет применять полученную информацию по своему усмотрению для настройки часового пояса, в котором он размещен.

Сервер DHCP должен периодически обновлять строки часовых поясов с учетом административных изменений местных правовых актов (например, округов штата Indiana). Хотя авторы и не предполагают, что это будет нижней границей срока аренды в подавляющем большинстве случаев, возможны ситуации, когда ожидание изменений будет требовать осмотрительности, поскольку некоторые регуляторы не дают уведомлений совсем или дают их мало.

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

7. Новая опция Timezone и время аренды

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

8. Отмена опции Time Offset

Поскольку эта опция обеспечивает надмножество функциональности прежней опции IPv4 time offset (тег 2) и для поддержки согласованности между реализациями IPv4 и IPv6 использование прежней опции отменяется. Имеющимся реализациям, которые поддерживают опцию time offset IPv4, следует реализовать также новую опцию. Другим реализациям следует поддерживать эту опцию и недопустимо реализовать опцию time offset IPv4. В процессе перехода клиенты, которые уже пользуются опцией time offset, могут запрашивать опции time offset и timezone.

9. Вопросы безопасности

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

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

Клиентам, использующим опцию POSIX, следует также с подозрением относиться к установкам часового пояса, задающим смещение от UTC более 25 часов (ограничение POSIX с учетом использования летнего времени). На момент подготовки этого документа максимальное смещение от UTC на практике составляло 14 часов, но в будущем это смещение может быть увеличено.

10. Взаимодействие с IANA

Агентство IANA выделило коды опций DHCPv4 и DHCPv6 для указания часового пояса со ссылками на этот документ.

Агентство IANA анонсировало отмену опции time offset IPv4 (тег 2) со ссылкой на этот документ.

11. Благодарности

Этот документ задает способ обмена информацией о часовых поясах. Сложно было собрать изменения различных баз данных из расположенных по всему миру источников. Многие добровольцы делали эту работу на протяжении нескольких лет через список рассылки tz@elsie.nci.nih.gov. Спасибо также Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas и Simon Vaillancourt за их вклад в улучшение этой работы.

12. Литература

12.1. Нормативные документы

[1] «Standard for Information Technology — Portable Operating System Interface (POSIX) — Base Definitions», IEEE Std 1003.1-2004, December 2004.

[2] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[3] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[4] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

[6] Droms, R., «Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types», BCP 43, RFC 2939, September 2000.

[7] Eggert, P. and A. Olson, «Sources for Time Zone and Daylight Saving Time Data», <http://www.twinsun.com/tz/tz-link.htm>.

12.2. Дополнительная литература

[8] Vaillancourt, S., «Calconnect.org TC Timezone Technical Committee: Timezone Registry and Service Recommendations», April 2006.

[9] Dawson, F. and Stenerson, D., «Internet Calendaring and Scheduling Core Object Specification (iCalendar)», RFC 2445, November 1998.

[10] Eggert, P. and E. Reingold, «cal-dst.el — calendar functions for daylight savings rules», <http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.

Адреса авторов

Eliot Lear

Cisco Systems GmbH

Glatt-com

Glattzentrum, ZH CH-8301

Switzerland

Phone: +41 1 878 9200

EMail: lear@cisco.com

Paul Eggert

UCLA

Computer Science Department

4532J Boelter Hall

Los Angeles, CA 90095

USA

Phone: +1 310 825 3886

EMail: eggert@cs.ucla.edu

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Полное заявление авторских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Daylight saving time.

2Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации.

Рубрика: RFC | Комментарии отключены

RFC 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Опубликовано 23.04.2007 автором Nikolai Malykh

Network Working Group                                           E. Beili
Request for Comments: 4836                              Actelis Networks
Obsoletes: 3636                                               April 2007
Category: Standards Track

Определения управляемых объектов для IEEE 802.3 MAU

Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Статус документа

Авторские права

Аннотация

Этот документ определяет часть MIB¹ для использования с протоколами сетевого управления в сообществе Internet. В частности, определены объекты для управления модулями подключения IEEE 802.3 MAU². Этот документ служит заменой RFC 3636. Он меняет указанную спецификацию путем переноса определений OBJECT-IDENTITY и относящихся к ним текстовых соглашений в отдельный модуль MIB, администрируемый агентством IANA³. Кроме того, добавлена информация для поддержки MAU типов EFM и 10GBASE-CX4⁴.

1. Введение

Этот документ определяет часть MIB для использования с протоколами сетевого управления в сообществе Internet. В частности, определены объекты для управления модулями подключения IEEE 802.3 MAU.

Предыдущая версия документа — RFC 3636 [RFC3636] — определяла один модуль MIB. Данный документ разделил исходный модуль MIB на два, поместив часто обновляемые объекты и текстовые соглашения в отдельный модуль, администрируемый IANA, для того, чтобы не нужно было менять базовый модуль MAU MIB.

Первая версия администрируемого IANA модуля MIB была расширена списком объектов управления для поддержки интерфейсов EFM и 10GBASE-CX4.

Технология Ethernet, определенная рабочей группой IEEE 802.3, продолжает развиваться с ростом скорости, добавлением новых типов кабелей и интерфейсов, а также новых возможностей. Это развитие может потребовать изменения управляемых объектов с учетом новых функций. Данный документ, наряду с другими документами рабочей группы, отражает определенный этап развития технологии Ethernet. В будущем этот документ может быть пересмотрен или рабочая группа Ethernet Interfaces and Hub MIB может выпустить новый документ для Ethernet.

2. Стандартная модель управления Internet

Подробный обзор документов, описывающих текущую модель стандартного сетевого управления Internet, приведен в разделе 7 RFC 3410 [RFC3410].

Доступ к управляемым объектам осуществляется через виртуальные хранилища информации, называемые MIB. Доступ к объектам MIB обычно происходит с использованием простого протокола сетевого управления SNMP⁵. Объекты в MIB определяются с использованием механизмов SMI⁶. Этот документ задает модуль MIB, соответствующий спецификации SMIv2, описанной в STD 58 RFC 2578 [RFC2578], STD 58 RFC 2579 [RFC2579] и STD 58 RFC 2580 [RFC2580].

3. Обзор

Экземпляры объектов этих типов представляют атрибуты IEEE 802.3 MAU. Некоторые типы MAU определены в стандарте IEEE 802.3 CSMA/CD [IEEE802.3]. Эти MAU могут подключаться к повторителям или интерфейсам 802.3 (типа Ethernet). Для удобства в этом документе они называются MAU повторителей и MAU интерфейсов.

Представленные здесь определения основаны на параграфах 30.5 «Layer Management for 10 Mb/s, 100 Mb/s, 1000 Mb/s, and 10 Gb/s Medium Attachment Units (MAUs)», 30.6 «Management for link Auto-Negotiation» и Приложении 30A «GDMO Specifications for 802.3 managed object classes» стандарта IEEE Std. 802.3-2005 [IEEE802.3]. Данная спецификация предназначена для управления всеми типами Ethernet/802.3 MAU.

3.1. Связь с RFC 3636

Определения управляемых объектов в этом документе включают в себя определения RFC 3636 [RFC3636].

Для снижения потребности в обновлении базового модуля MAU MIB в результате добавления новых типов MAU, состояний Media Available, возможностей Auto Negotiation и/или типов разъемов (Jack) все относящиеся к делу объекты и текстовые соглашения перенесены в отдельный модуль MIB (IANA-MAU-MIB), администрируемый IANA, первая версия которого определена в этом документе. Таким образом, при добавлении MAU, состояния доступности среды, возможностей автосогласования и/или типов разъемов, определенных рабочей группой IEEE 802.3, потребуется пересмотр лишь поддерживаемого IANA модуля, а заданный в этом документе базовый модуль MAU-MIB сохранится.

В дополнение к этому добавлены определения в администрируемый IANA модуль MIB для поддержки интерфейсов EFM и 10GBASE-CX4, определенных в IEEE Std 802.3ah-2004 [IEEE802.3ah] и IEEE Std 802.3ak-2004 [IEEE802.3ak], соответственно, которые сейчас являются частью IEEE Std 802.3-2005 [IEEE802.3].

Следует отметить, что внесенные здесь изменения не полностью совместимы с модулями MIB, импортирующими в данный момент дескрипторы объектов типа MAU из MAU-MIB. Такие модули требуют пересмотра с импортом соответствующих дескрипторов из IANA-MAU-MIB. Всем управляющим приложениям, обрабатывающим такие объекты (например, выводящим пользователю текст DESCRIPTION), нужно брать определения из IANA-MAU-MIB, а не MAU-MIB. Хотя очевидно, что изменения, требующие таких корректировок, не соответствуют правилам SMIv2 для пересмотра модулей MIB (см. раздел 10 в [RFC2578]), в данном случае значительные издержки, связанные с отказом от этих изменений, являются достаточным основанием для отхода от правил. Следует подчеркнуть, что рабочая группа не смогла найти модулей MIB или управляющих приложений, для которых эти изменения имели негативное влияние.

3.2. Связи с другими MIB

Предполагается, что агенты, реализующие MAU-MIB, будут также реализовать (по меньшей мере) группу system, определенную в SNMPv2 MIB [RFC3418]. В следующих параграфах рассмотрены другие MIB, которые агенту следует реализовать.

3.2.1. Связь с Interfaces MIB

Параграфы этого документа, определяющие связанные с MAU объекты для интерфейсов, задают расширение Interfaces MIB [RFC2863]. Агент, реализующий относящийся к MAU интерфейса объект, должен также реализовать относящиеся к нему группы ifCompliance3 MODULE-COMPLIANCE из Interface MIB. Значение объекта ifMauIfIndex совпадает со значением ifIndex, используемым для создания экземпляра интерфейса, к которому подключен MAU.

От агентов требуется реализация объектов, связанных с MAU интерфейсов, в соответствии с заявлением dot3Compliance2 MODULE-COMPLIANCE в Interface MIB [RFC3635] для интерфейсов типа Ethernet. Кроме того, при использовании связанных с MAU объектов, используемых для управления 10GBASE-W PHY (т. е. когда ifMauType имеет значение dot3MauType10GigBaseW или иного варианта 10GBASE-W), агент должен также поддерживать Ethernet WAN Interface Sublayer (WIS) MIB [RFC3637] и должен следовать заданной там модели уровней для интерфейса. В данном случае значение объекта ifMauIfIndex совпадает со значением ifIndex для верхнего уровня стека, т. е. для записи ifTable, имеющей ifType = ethernetCsmacd(6). Если относящиеся к MAU интерфейса объекты используются для управления PHY, позволяющим динамически менять тип MAU, агенту нужно создать элементы ifTable, ifStackTable и ifInvStackTable, относящиеся к WIS, при замене ifMauDefaultType на вариант 10GBASE-W (т. е. dot3MauType10GigBaseW, dot3MauType10GigBaseEW, dot3MauType10GigBaseLW или dot3MauType10GigBaseSW) с другого типа и удалять относящиеся к WIS элементы при смене ifMauDefaultType на тип, не являющийся 10GBASE-W. Агенту нужно также изменить значения ifConnectorPresent и ifHighSpeed в записи ifTable с индексом ifMauIfIndex, как указано в [RFC3635] и [RFC3637] при таких манипуляциях с ifMauDefaultType, но не нужно делать этого при иных изменениях.

(Отметим, что порты повторителей не представляются интерфейсами в Interface MIB.)

3.2.2. Связь с модулем 802.3 Repeater MIB

Параграф этого документа, определяющий связанные с MAU повторителя объекты, задает расширение 802.3 Repeater MIB, определенного в [RFC2108]. Агент, реализующий такие объекты, должен также соответствовать заявлению snmpRptrModCompl в модуле 802.3 Repeater MIB.

Значения rpMauGroupIndex и rpMauPortIndex, используемые для создания экземпляра переменной MAU повторителя нужно делать совпадающими с rptrPortGroupIndex и rptrPortIndex, использованными для создания экземпляра порта, к которому присоединен данный MAU.

3.3. Управление встроенными MAU

В некоторых случаях MAU может быть «внутренним», т. е. вся функциональность будет реализована в самом устройстве. Например, управляемый повторитель может содержать внутренний MAU повторителя и/или интерфейса, через который проходят управляющие коммуникации, исходящие от одного из внешних портов повторителя для связи с агентом управления. Такие внутренние MAU могут (но не обязаны) быть управляемыми. Для управляемых MAU объекты, описывающие их атрибуты, должны присутствовать в подходящем субдереве MIB — dot3RpMauBasicGroup для внутренних MAU повторителя и dot3IfMauBasicGroup для внутренних MAU интерфейса.

3.4. Отображение управляемых объектов IEEE 802.3

В этом параграфе показано сопоставление объектов управления (атрибутов), определенных в разделе 30 [IEEE802.3], с объектами управления, определенными в этом документе.

Таблица 1. Сопоставление с объектами IEEE 802.3.

Управляемые объекты IEEE 802.3	Соответствующие объекты SNMP
oMAU
.aMAUID	rpMauIndex or ifMauIndex или broadMauIndex
.aMAUType	rpMauType или ifMauType
.aMAUTypeList	ifMauTypeListBits
.aMediaAvailable	rpMauMediaAvailable или ifMauMediaAvailable
.aLoseMediaCounter	rpMauMediaAvailableStateExits или ifMauMediaAvailableStateExits
.aJabber	rpMauJabberState и rpMauJabberingStateEnters или ifMauJabberState и ifMauJabberingStateEnters
.aMAUAdminState	rpMauStatus или ifMauStatus
.aBbMAUXmitRcvSplitType	broadMauXmtRcvSplitType
.aBroadbandFrequencies	broadMauXmtCarrierFreq и broadMauTranslationFreq
.aFalseCarriers	rpMauFalseCarriers или ifMauFalseCarriers
.acResetMAU	rpMauStatus или ifMauStatus
.acMAUAdminControl	rpMauStatus или ifMauStatus
.nJabber	rpMauJabberTrap или ifMauJabberTrap
oAutoNegotiation
.aAutoNegID	ifMauIndex
.aAutoNegAdminState	ifMauAutoNegAdminStatus
.aAutoNegRemoteSignalling	ifMauAutoNegRemoteSignalling
.aAutoNegAutoConfig	ifMauAutoNegConfig
.aAutoNegLocalTechnologyAbility	ifMauAutoNegCapabilityBits
.aAutoNegAdvertisedTechnologyAbility	ifMauAutoNegAdvertisedBits и ifMauAutoNegRemoteFaultAdvertised
.aAutoNegReceivedTechnologyAbility	ifMauAutoNegReceivedBits и ifMauAutoNegRemoteFaultReceived
.acAutoNegRestartAutoConfig	ifMauAutoNegRestart
.acAutoNegAdminControl	ifMauAutoNegAdminStatus

Ниже приведены управляемые объекты IEEE 802.3, которые не включены в MAU-MIB, с указанием причин исключения.

Таблица 2. Объекты управления IEEE 802.3, не включенные в MAU-MIB.

Управляемые объекты IEEE 802.3	Причина исключения
oMAU
.aIdleErrorCount	Полезно лишь для 100BaseT2, не получивших широкого распространения.
oAutoNegotiation
.aAutoNegLocalSelectorAbility	Требуется лишь для поддержки isoethernet (802.9a), не включенного в MAU-MIB.
.aAutoNegAdvertisedSelectorAbility
.aAutoNegReceivedSelectorAbility

3.5. Добавление новых типов MAU

3.5.1. dot3MauType

Идентификатор dot3MauType OBJECT IDENTIFIER и его определения OBJECT-IDENTITY перенесены из MAU-MIB в поддерживаемый IANA модуль IANA-MAU-MIB, первая версия которого опубликована в этом документе.

При определении нового IEEE 802.3 MAU агентство IANA может выпустить новую версию IANA-MAU-MIB с новым dot3MauType OBJECT-IDENTITY, соответствующим текстовым соглашением IANAifMauTypeListBits и, возможно, новыми значениями IANAifMauMediaAvailable, IANAifMauAutoNegCapBits и/или IANAifJackType.

Для добавления новых MAU, состояний Media Available, возможностей Auto Negotiation и/или разъемов (Jack) требуется процедура Expert Review, как указано в RFC 2434 [RFC2434].

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

3.5.2. IANAifMauTypeListBits

Синтаксис ifMauTypeListBits преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauTypeListBits и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.3. IANAifMauMediaAvailable

Синтаксис ifMauMediaAvailable и rpMauMediaAvailable преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauMediaAvailable и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.4. IANAifMauAutoNegCapBits

Синтаксис ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits и ifMauAutoNegCapReceivedBits преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauAutoNegCapBits и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.5. JackType

Текстовое соглашение JackType было заменено IANAifJackType, определенным в поддерживаемом IANA модуле MIB, что позволяет добавлять новые типы разъемов (при их добавлении в IEEE 802.3) без смены версии этого документа.

4. Определение MAU MIB

   MAU-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       Counter32, Integer32, Counter64,
       OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2
         FROM SNMPv2-SMI         -- RFC 2578
       TruthValue, AutonomousType, TEXTUAL-CONVENTION
         FROM SNMPv2-TC          -- RFC 2579
       OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
         FROM SNMPv2-CONF        -- RFC 2580
       InterfaceIndex
         FROM IF-MIB             -- RFC 2863
       IANAifMauTypeListBits, IANAifMauMediaAvailable,
       IANAifMauAutoNegCapBits, IANAifJackType
         FROM IANA-MAU-MIB
                          -- http://www.iana.org/assignments/ianamau-mib 
       ;

     mauMod MODULE-IDENTITY
       LAST-UPDATED "200704210000Z"  -- 21 апреля 2007 г.
       ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group"
       CONTACT-INFO
         "WG charter:
           http://www.ietf.org/html.charters/hubmib-charter.html 

         Mailing Lists:
           General Discussion: hubmib@ietf.org
           To Subscribe: hubmib-request@ietf.org
           In Body: subscribe your_email_address

          Chair: Bert Wijnen
         Postal: Alcatel-Lucent
                 Schagen 33
                 3461 GL Linschoten
                 Netherlands
          Phone: +31-348-407-775
          EMail: bwijnen@alcatel-lucent.com

         Editor: Edward Beili
         Postal: Actelis Networks Inc.
                 25 Bazel St., P.O.B. 10173
                 Petach-Tikva 10173
                 Israel
            Tel: +972-3-924-3491
          EMail: edward.beili@actelis.com"

       DESCRIPTION
         "Управляющая информация для 802.3 MAU.

         Ниже перечислены документы, упоминаемые в этом модуле MIB.

         [IEEE802.3] 
            IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information
            technology - Telecommunications and information exchange
            between systems - Local and metropolitan area networks -
            Specific requirements - Part 3: Carrier sense multiple
            access with collision detection (CSMA/CD) access method and
            physical layer specifications'.

            Особый интерес представляет раздел 30, 'Management'.

         Copyright (C) The IETF Trust (2007).
         Эта версия модуля MIB является частью RFC 4836, где правовые
         вопросы рассмотрены более полно."

       REVISION    "200704210000Z"  -- 21 апреля 2007 г.
       DESCRIPTION "Обновлены ссылки на поддерживаемые IANA текстовые
                   соглашения для типов MAU, состояния доступности среды,
                   возможностей автосогласования и типов разъемов вместо
                   использования внутренних определений.

                   Эта версия опубликована в RFC 4836."

       REVISION    "200309190000Z"  -- 19 сентября 2003 г.
       DESCRIPTION "Добавлена поддержка MAU 10 Гбит/с, которая
                   потребовала пересмотра.
                   - добавлены OBJECT-IDENTITY для MAU 10 Гбит/с;
                   - добавлен тип разъемов fiberLC в JackType;
                   - расширен набор ifMauTypeListBits для MAU 10 Гбит/с;
                   - добавлены значения в ifMauMediaAvailable и
                     обновлено описание с учетом поведения при 10 Гбит/с;
                   - добавлена 64-битовая версия ifMauFalseCarriers и
                     группа mauIfGrpHCStats;
                   - mauModIfCompl2 заменено на mauModIfCompl3 с новой группой.

                   Эта версия опубликована в RFC 3636."

       REVISION    "199908240400Z" — 24 августа 1999 г.
       DESCRIPTION "Эта версия опубликована в RFC 2668. Добавлена поддержка
                   MAU 1000 Мбит/с и согласование управления потоком данных."

       REVISION    "199710310000Z" — 31 октября 1997 г.
       DESCRIPTION "Эта версия опубликована в RFC 2239."

       REVISION    "199309300000Z" — 30 сентября 1993 г.
       DESCRIPTION "Исходная версия, опубликованная в RFC 1515."

       ::= { snmpDot3MauMgt 6 }

      snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 }

      -- Текстовые соглашения

      JackType ::= TEXTUAL-CONVENTION
        STATUS      deprecated
        DESCRIPTION "********* Отменено **********

                    Это TC было отменено с заменой на IANAifJackType.

                    Общие перечисляемые значения для типов разъемов
                    в MAU повторителей и интерфейсов."
        SYNTAX      INTEGER {
                              other(1),
                              rj45(2),
                              rj45S(3), -- rj45 с экраном
                              db9(4),
                              bnc(5),
                              fAUI(6),  -- розетка aui
                              mAUI(7),  -- вилка aui
                              fiberSC(8),
                              fiberMIC(9),
                              fiberST(10),
                              telco(11),
                              mtrj(12),  -- оптика MT-RJ
                              hssdc(13), -- оптический канал style-2
                              fiberLC(14)
                          }

      dot3RpMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 }
      dot3IfMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 }
      dot3BroadMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 }

      -- OID в приведенной ниже ветви зарезервирован для
      -- IANA-MAU-MIB при назначении новых типов MAU:
      --                        { snmpDot3MauMgt 4 }

      dot3IfMauAutoNegGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 }

      -- следующий OID является значением MODULE-IDENTITY 
      -- для этого модуля MIB:   { snmpDot3MauMgt 6 }

      --
      -- Таблица Basic Repeater MAU
      --

      rpMauTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF RpMauEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION "Таблица с описанием и данными состояния для
                    MAU, подключенных к порту повторителя."
        ::= { dot3RpMauBasicGroup 1 }

      rpMauEntry OBJECT-TYPE
        SYNTAX      RpMauEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION "Запись в таблице с данными для одного MAU."
        INDEX       { rpMauGroupIndex,
                      rpMauPortIndex,
                      rpMauIndex
                    }
        ::= { rpMauTable 1 }

      RpMauEntry ::=
        SEQUENCE {
            rpMauGroupIndex                     Integer32,
            rpMauPortIndex                      Integer32,
            rpMauIndex                          Integer32,
            rpMauType                           AutonomousType,
            rpMauStatus                         INTEGER,
            rpMauMediaAvailable                 IANAifMauMediaAvailable,
            rpMauMediaAvailableStateExits       Counter32,
            rpMauJabberState                    INTEGER,
            rpMauJabberingStateEnters           Counter32,
            rpMauFalseCarriers                  Counter32
      }

      rpMauGroupIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION "Уникальный идентификатор группы, содержащей порт,
                    к которому подключен описываемый записью MAU.

                    Примечание. На практике группа обычно будет 
                    представлять сменный модуль (плата, карта),
                    который устанавливается в шасси физической системы
                    и номер группы будет соответствовать номеру гнезда.

                    Группа, указанная конкретным значением этого объекта,
                    совпадает с группой с тем же значением в rptrGroupIndex."
        REFERENCE   "RFC 2108, rptrGroupIndex."
        ::= { rpMauEntry 1 }

      rpMauPortIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION "Эта переменная однозначно указывает порт повторителя
                    в группе rpMauGroupIndex, к которому подключен MAU,
                    описываемый этой записью."
        REFERENCE   "RFC 2108, rptrPortIndex."
        ::= { rpMauEntry 2 }

      rpMauIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION " Эта переменная однозначно указывает MAU, описываемый
                    этой записью среди других MAU, подключенных к тому же
                    порту (rpMauPortIndex)."
        REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
        ::= { rpMauEntry 3 }

      rpMauType OBJECT-TYPE
        SYNTAX      AutonomousType
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "Этот объект указывает типа MAU. Значения для стандартных
                    типов IEEE 802.3 MAU определены в поддерживаемом IANA
                    модуле IANA-MAU-MIB как OBJECT-IDENTITY типа dot3MauType.
                    Если тип MAU не известен, возвращается идентификатор
                    объекта zeroDotZero."
        REFERENCE   "[IEEE802.3], 30.5.1.1.2, aMAUType."
        ::= { rpMauEntry 4 }

      rpMauStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          operational(3),
                          standby(4),
                          shutdown(5),
                          reset(6)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Текущее состояние MAU. Этот объект МОЖЕТ реализоваться
                      как read-only теми агентами и MAU, которые не поддерживают
                      программное управления состоянием MAU. Некоторые агенты могут 
                      не поддерживать установку для этого объекта некоторых
                      перечисляемых значения.

                      Значение other(1) возвращается, если MAU находится в
                      состоянии, отличном от 2 - 6.

                      Значение unknown(2) возвращается, когда состояние MAU
                      не известно (например, при инициализации).

                      MAU в состоянии operational(3) находится в рабочем
                      состоянии и передает сигналы подключенному DTE или
                      повторителю в соответствии со спецификацией.

                      MAU в состоянии standby(4) форсирует для DI и CI 
                      состояние idle, а для приемопередатчика idle или fault,
                      если они поддерживаются. Режим standby(4) применим лишь
                      для MAU канального типа. Состояние rpMauMediaAvailable 
                      не изменяется.

                      Для MAU в состоянии shutdown(5) предполагаются такие же
                      условия для DI, CI и приемопередатчика, как при 
                      отключении питания или отсоединении. MAU МОЖЕТ
                      возвращать значение other(1) для объектов
                      rpMauJabberState и rpMauMediaAvailable, когда
                      он находится в этом состоянии. Для AUI это
                      состояние будет отключать питание AUI.

                      Установка для этой переменной значения reset(6)
                      сбрасывает MAU как при отключении питания по 
                      меньшей мере на полсекунды с последующим включением.
                      От агента не требуется возврат значений reset(6).

                      Установка для этой переменной значения operational(3),
                      standby(4) или shutdown(5) приводит MAU в соответствующее
                      состояние, за исключением того, что перевод комбинированного 
                      MAU или AUI в состояние standby(4) будет выключать MAU."
          REFERENCE   "[IEEE802.3], 30.5.1.1.7, aMAUAdminState,
                      30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
                      acResetMAU."
          ::= { rpMauEntry 5 }

      rpMauMediaAvailable OBJECT-TYPE
          SYNTAX      IANAifMauMediaAvailable
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект указывает состояние Media Available в MAU,
                      дополнительно к rpMauStatus. Значения для стандартных
                      состояний IEEE 802.3 Media Available определены в
                      поддерживаемом IANA модуле IANA-MAU-MIB как 
                      IANAifMauMediaAvailable TC."
          REFERENCE   "[IEEE802.3], 30.5.1.1.4, aMediaAvailable."
          ::= { rpMauEntry 6 }

      rpMauMediaAvailableStateExits OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда rpMauMediaAvailable для экземпляра 
                      MAU выходило из состояния available(3).

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 7 }

      rpMauJabberState OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          noJabber(3),
                          jabbering(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение other(1) возвращается, если состояние jabber
                      отличается от 2, 3 или 4. Агент всегда ДОЛЖЕН возвращать
                      other(1) для MAU типа dot3MauTypeAUI.

                      Значение unknown(2) возвращается, если точное состояние
                      MAU не известно (например, при инициализации).

                      Если MAU не поддерживает jabbering, агент возвращает
                      noJabber(3). Это «нормальное» состояние.

                      Если MAU находится в состоянии jabber, агент возвращает 
                      значение jabbering(4)."
          REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag."
          ::= { rpMauEntry 8 }

      rpMauJabberingStateEnters OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда mauJabberState для этого экземпляра 
                      MAU было в состоянии jabbering(4). Для MAU типов
                      dot3MauTypeAUI, dot3MauType100BaseT4,
                      dot3MauType100BaseTX, dot3MauType100BaseFX и всех
                      типов 1000 Мбит/с этот счетчик всегда показывает 0.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 9 }

      rpMauFalseCarriers OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X. Этот счетчик не 
                      инкрементируется со скоростью символов. Он может
                      увеличиваться после корректной установки несущей с
                      максимальной скоростью 1 раз за 100 мсек до следующего
                      события, связанного с несущей.

                      Счетчик инкрементируется только для MAU типов 
                      dot3MauType100BaseT4, dot3MauType100BaseTX,
                      dot3MauType100BaseFX и всех типов 1000 Мбит/с.

                      Для остальных типов MAU счетчик всегда показывает 0.

                      Приблизительное минимальное время заполнения (rollover) 
                      счетчика составляет 7,4 часа.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 10 }

      -- rpJackTable применяется к MAU, подключенным к повторителям, имеющим
      -- один или несколько внешних разъемов.

      rpJackTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF RpJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Информация о внешних разъемах, подключенных к
                      MAU, присоединенным к портам повторителя."
          ::= { dot3RpMauBasicGroup 2 }

      rpJackEntry OBJECT-TYPE
          SYNTAX      RpJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись с информацией о конкретном разъеме."
          INDEX       { rpMauGroupIndex,
                        rpMauPortIndex,
                        rpMauIndex,
                        rpJackIndex
                      }
          ::= { rpJackTable 1 }

      RpJackEntry ::=
          SEQUENCE {
              rpJackIndex                         Integer32,
              rpJackType                          IANAifJackType
          }

      rpJackIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает разъем, 
                      описанный данной записью, среди других разъемов
                      того же MAU (rpMauIndex)."
          ::= { rpJackEntry 1 }

      rpJackType OBJECT-TYPE
          SYNTAX      IANAifJackType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Тип разъема с внешней точки зрения."
          ::= { rpJackEntry 2 }

      --
      -- Таблица Basic Interface MAU
      --

      ifMauTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfMauEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Таблица с описаниями и статусом MAU, 
                      подключенных к интерфейсу."
          ::= { dot3IfMauBasicGroup 1 }

      ifMauEntry OBJECT-TYPE
          SYNTAX      IfMauEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Таблица с информацией об отдельном MAU."
          INDEX       { ifMauIfIndex,
                        ifMauIndex
                      }
          ::= { ifMauTable 1 }

      IfMauEntry ::=
          SEQUENCE {
              ifMauIfIndex                      InterfaceIndex,
              ifMauIndex                        Integer32,
              ifMauType                         AutonomousType,
              ifMauStatus                       INTEGER,
              ifMauMediaAvailable               IANAifMauMediaAvailable,
              ifMauMediaAvailableStateExits     Counter32,
              ifMauJabberState                  INTEGER,
              ifMauJabberingStateEnters         Counter32,
              ifMauFalseCarriers                Counter32,
              ifMauTypeList                     Integer32,
              ifMauDefaultType                  AutonomousType,
              ifMauAutoNegSupported             TruthValue,
              ifMauTypeListBits                 IANAifMauTypeListBits,
              ifMauHCFalseCarriers              Counter64
          }

      ifMauIfIndex OBJECT-TYPE
          SYNTAX      InterfaceIndex
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает интерфейс, к
                      которому подключен описываемый записью MAU."
          REFERENCE   "RFC 2863, ifIndex"
          ::= { ifMauEntry 1 }

      ifMauIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      current
          DESCRIPTION "Переменная однозначно указывает MAU, описываемый
                      данной записью, среди других MAU того же
                      интерфейса (ifMauIfIndex)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
          ::= { ifMauEntry 2 }

      ifMauType OBJECT-TYPE
        SYNTAX      AutonomousType
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "Этот объект указывает тип MAU. Значения для стандартных
                    типов IEEE 802.3 MAU определены в поддерживаемом IANA
                    модуле IANA-MAU-MIB как OBJECT-IDENTITY для dot3MauType.
                    Если тип MAU не известен, возвращается zeroDotZero.

                    Этот объект представляет операционный тип MAU, как определено 
                    1) результатом функции автосогласования или 2) значением
                    ifMauDefaultType, если автосогласование не реализовано 
                    или отключено для этого MAU. В случае 2) установка объекта
                    ifMauDefaultType будет переводить MAU в другой режим."
        REFERENCE   "[IEEE802.3], 30.5.1.1.2, aMAUType."
        ::= { ifMauEntry 3 }

      ifMauStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          operational(3),
                          standby(4),
                          shutdown(5),
                          reset(6)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Текущее состояние MAU. Этот объект МОЖЕТ быть
                      открыт лишь для чтения теми агентами и MAU,
                      которые не поддерживают программного контроля
                      состояния MAU. Некоторые агенты могут не поддерживать
                      для этого объекта установку перечисляемых значений.

                      Значение other(1) возвращается, если состояние MAU 
                      отличается 2 - 6.

                      Значение unknown(2) возвращается, если точное состояние
                      MAU не известно (например, при инициализации).

                      MAU в состоянии operational(3) полностью работоспособен;
                      он функционирует и передает сигналы своему подключенному
                      DTE или порту повторителя в соответствии со спецификацией.

                      MAU в состоянии standby(4) переводит DI и CI в бездействие,
                      а приемопередатчик в бездействие или отказ, если это
                      поддерживается. Режим standby(4) применим лишь к MAU
                      канального типа. Состояние ifMauMediaAvailable не меняется.

                      MAU в состоянии shutdown(5) предполагает для DI, CI и 
                      приемопередатчика такие же условия, как при отключении
                      питания или отсоединении. MAU МОЖЕТ возвращать значение 
                      other(1) для объектов ifMauJabberState и ifMauMediaAvailable 
                      в таком состоянии. Для AUI это состояние будет отключать
                      удаленное питание от AUI.

                      Установка значения reset(6) сбрасывает MAU как при выключении
                      и последующем включении с задержкой не менее полсекунды. Агент
                      не обязан возвращать значение reset(6).

                      Установка значения operational(3), standby(4) или shutdown(5)
                      переводит MAU в соответствующее состояние, за исключением
                      установки комбинированных MAU или AUI в состояние
                      standby(4), переводящей MAU в состояние shutdown."
          REFERENCE   "[IEEE802.3], 30.5.1.1.7, aMAUAdminState,
                      30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
                      acResetMAU."
          ::= { ifMauEntry 4 }

      ifMauMediaAvailable OBJECT-TYPE
          SYNTAX      IANAifMauMediaAvailable
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект указывает состояние Media Available для
                      MAU в дополнение к ifMauStatus. Значения для 
                      стандартных состояний IEEE 802.3 Media Available 
                      определены в поддерживаемом IANA модуле IANA-MAU-MIB
                      как IANAifMauMediaAvailable TC."
          REFERENCE   "[IEEE802.3], 30.5.1.1.4, aMediaAvailable."
          ::= { ifMauEntry 5 }

      ifMauMediaAvailableStateExits OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев выхода ifMauMediaAvailable для
                      данного экземпляра MAU из состояния available(3).

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 6 }

      ifMauJabberState OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          noJabber(3),
                          jabbering(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение other(1) возвращается, если jabber
                      находится не в состоянии 2, 3 или 4. Агент ДОЛЖЕН
                      всегда возвращать other(1) для MAU типа dot3MauTypeAUI.

                      Значение unknown(2) возвращается, когда точное состояние 
                      MAU не известно (например, при инициализации).

                      Если MAU не поддерживает jabbering, агент возвращает
                      noJabber(3). Это «нормальное» состояние.

                      Если MAU находится в состоянии jabber, агент возвращает 
                      значение jabbering(4)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag."
          ::= { ifMauEntry 7 }

      ifMauJabberingStateEnters OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда mauJabberState для этого экземпляра 
                      MAU было в состоянии jabbering(4). Этот счетчик всегда
                      показывает 0 для MAU типа dot3MauTypeAUI и всех типов
                      со скоростями выше 10 Мбит/с.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 8 }

      ifMauFalseCarriers OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X и 1000BASE-X. 
                     
                      Для остальных типов MAU счетчик всегда показывает 0. 
                      Счетчик не инкрементируется со скоростью символов.

			  Счетчик может увеличиваться после корректной установки 
                      несущей с максимальной скоростью 1 раз за 100 мсек до 
                      следующего события CarrierEvent.

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

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 9 }

      ifMauTypeList OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу ifMauTypeListBits.

                      Значение, однозначно указывающее набор возможных типов
                      IEEE 802.3 для данного MAU. Значение представляет собой
                      сумму, начальное значение которой равно 0. Затем 
                      для каждого типа возможности этого MAU, 2 возводится 
                      в степень, показанную ниже и добавляется к сумме.
                      Например, MAU с поддержкой лишь 10BASE-T будет иметь
                      значение 512 (2⁹). MAU с поддержкой 10Base-T 
			  (полнодуплексный) и 100BASE-TX (полнодуплексный) будет
                      иметь значение 67584 (2¹¹ + 2¹⁶).

                      Степени 2 для разных возможностей приведены ниже.

                      Степень  Возможность
                        0      прочие или неизвестные
                        1      AUI
                        2      10BASE-5
                        3      FOIRL
                        4      10BASE-2
                        5      10BASE-T, режим дуплекса не известен
                        6      10BASE-FP
                        7      10BASE-FB
                        8      10BASE-FL, режим дуплекса не известен
                        9      10BROAD36
                       10      10BASE-T, полудуплексный
                       11      10BASE-T, полнодуплексный
                       12      10BASE-FL, полудуплексный
                       13      10BASE-FL, полнодуплексный
                       14      100BASE-T4
                       15      100BASE-TX, полудуплексный
                       16      100BASE-TX, полнодуплексный
                       17      100BASE-FX, полудуплексный
                       18      100BASE-FX, полнодуплексный
                       19      100BASE-T2, полудуплексный
                       20      100BASE-T2, полнодуплексный

                      При наличии в MAU автосогласования этот объект
                      будет отображаться на ifMauAutoNegCapability."
          ::= { ifMauEntry 10 }

      ifMauDefaultType OBJECT-TYPE
          SYNTAX      AutonomousType
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Этот объект указывает принятый по умолчанию 
                      административный тип baseband MAU, используемый вместе 
                      с операционным типом MAU, указанным ifMauType.

                      Набор возможных значений этого объекта совпадает с
                      набором значения, определенных для ifMauType.

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

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

                      Примечание для разработчиков. Может потребоваться
                      реализация для оборудования, которое не точно
                      соответствует описанному выше поведению. В частности,
                      при выключении ifMauAutoNegAdminStatus реализация
                      агента ДОЛЖНА обеспечить корректную смену рабочего
                      типа MAU (указывается ifMauType) к заданному этим
                      объектом вместо продолжения работы в прежнем режиме, 
                      определенном автоматически."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID, and 22.2.4.1.4."
          ::= { ifMauEntry 11 }

      ifMauAutoNegSupported OBJECT-TYPE
          SYNTAX      TruthValue
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект показывает поддержку автосогласования в MAU."
          ::= { ifMauEntry 12 }

      ifMauTypeListBits OBJECT-TYPE
          SYNTAX      IANAifMauTypeListBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможных
                      типов IEEE 802.3, которые может иметь MAU. При
                      наличии автосогласования на MAU этот объект 
                      будет отображаться на ifMauAutoNegCapabilityBits.

                      Отметим, что MAU может оказаться способным работать 
                      как MAU, тип которого отсутствует в этом MIB. Это
  			  указывается возвратом бита bOther в дополнение к 
                      битам стандартных возможностей, перечисленным в 
                      IANAifMauTypeListBits TC."
          ::= { ifMauEntry 13 }

      ifMauHCFalseCarriers OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X и 1000BASE-X.

                      Для остальных типов MAU счетчик всегда показывает 0. 
                      Счетчик не инкрементируется со скоростью символов.

                      Этот счетчик является 64-битовой версией счетчика
                      ifMauFalseCarriers. Поскольку 32-битовый счетчик 
                      может переполняться достаточно быстро, станциям
                      управления рекомендуется опрашивать 64-битовый 
                      счетчик для предотвращения потери данных.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 14 }

      -- ifJackTable применяется к MAU, подключенных к интерфейсам с одним или
      -- несколькими внешними разъемами.

      ifJackTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Информация о внешних разъемах MAU, подключенных к интерфейсу."
          ::= { dot3IfMauBasicGroup 2 }

      ifJackEntry OBJECT-TYPE
          SYNTAX      IfJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись с информацией о конкретном разъеме."
          INDEX       { ifMauIfIndex,
                        ifMauIndex,
                        ifJackIndex
                      }
          ::= { ifJackTable 1 }

      IfJackEntry ::=
          SEQUENCE {
              ifJackIndex                         Integer32,
              ifJackType                          IANAifJackType
          }

      ifJackIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает описываемый
                      записью разъем среди других разъемов того же MAU."
          ::= { ifJackEntry 1 }

      ifJackType OBJECT-TYPE
          SYNTAX      IANAifJackType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Тип разъема с внешней точки зрения."
          ::= { ifJackEntry 2 }

      --
      -- Таблица автосогласования MAU
      --

      ifMauAutoNegTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfMauAutoNegEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Объекты конфигурации и состояния для функции
                      автосогласования MAU, подключенных к интерфейсам.

                      ifMauAutoNegTable применяется к системам, в которых
                      автосогласование поддерживается на одном или множестве
                      MAU, подключенных к интерфейсам. Отметим, что при 
                      имеющемся и включенном автосогласовании объект
                      ifMauType отражает результат функции согласования."
          ::= { dot3IfMauAutoNegGroup 1 }

      ifMauAutoNegEntry OBJECT-TYPE
          SYNTAX      IfMauAutoNegEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись таблицы с данными конфигурации и состояния 
                      для функции автосогласования отдельного MAU."
          INDEX       { ifMauIfIndex,
                        ifMauIndex
                      }
          ::= { ifMauAutoNegTable 1 }

      IfMauAutoNegEntry ::=
          SEQUENCE {
              ifMauAutoNegAdminStatus           INTEGER,
              ifMauAutoNegRemoteSignaling       INTEGER,
              ifMauAutoNegConfig                INTEGER,
              ifMauAutoNegCapability            Integer32,
              ifMauAutoNegCapAdvertised         Integer32,
              ifMauAutoNegCapReceived           Integer32,
              ifMauAutoNegRestart               INTEGER,
              ifMauAutoNegCapabilityBits        IANAifMauAutoNegCapBits,
              ifMauAutoNegCapAdvertisedBits     IANAifMauAutoNegCapBits,
              ifMauAutoNegCapReceivedBits       IANAifMauAutoNegCapBits,
              ifMauAutoNegRemoteFaultAdvertised INTEGER,
              ifMauAutoNegRemoteFaultReceived   INTEGER
          }

      ifMauAutoNegAdminStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          enabled(1),
                          disabled(2)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Установка значения enabled(1) будет включать
                      автосогласование на поддерживающем его интерфейсе.

                      При значении disabled(2) интерфейс будет работать 
                      как при отсутствии сигналов автосогласования. В
                      таких условиях IEEE 802.3 MAU будет незамедлительно
                      переходить в состояние, заданное ifMauDefaultType.

                      Примечание для разработчиков. При переходе
                      ifMauAutoNegAdminStatus из включенного состояния в
                      выключенное реализация агента ДОЛЖНА обеспечить
                      переключение рабочего типа MAU (указываемого в
                      ifMauType) к значению, заданному ifMauDefaultType,
                      вместо продолжения работы в прежнем режиме, 
                      определенном автоматически."
          REFERENCE   "[IEEE802.3], 30.6.1.1.2, aAutoNegAdminState,
                      and 30.6.1.2.2, acAutoNegAdminControl."
          ::= { ifMauAutoNegEntry 1 }

      ifMauAutoNegRemoteSignaling OBJECT-TYPE
          SYNTAX      INTEGER {
                          detected(1),
                          notdetected(2)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, которое показывает, используются ли на
                      удаленной стороне сигналы автосогласования. Переменная
                      принимает значение detected(1) тогда и только тогда,
                      когда при предыдущем согласовании канала были приняты 
                      сигналы FLP Burst."
          REFERENCE   "[IEEE802.3], 30.6.1.1.3,
                      aAutoNegRemoteSignaling."
          ::= { ifMauAutoNegEntry 2 }

      ifMauAutoNegConfig OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          configuring(2),
                          complete(3),
                          disabled(4),
                          parallelDetectFail(5)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, показывающее текущий статус процесса
                      автосогласования. Значение parallelDetectFail(5) 
                      отображается на отказ при параллельном детектировании, 
                      как определено в параграфе 28.2.3.1 [IEEE802.3]."
          REFERENCE   "[IEEE802.3], 30.6.1.1.4, aAutoNegAutoConfig."
          ::= { ifMauAutoNegEntry 4 }

      ifMauAutoNegCapability OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу 
                      ifMauAutoNegCapabilityBits.

                      Значение, однозначно указывающее набор возможностей
                      локального элемента автосогласования. Значение 
                      является суммой, которая исходно равна 0. Далее для
                      каждой поддерживаемой интерфейсом возможности число 2
                      возводится в соответствующую степень и добавляется к
                      сумме. Например, интерфейс, поддерживающий лишь 
                      полнодуплексный режим 100Base-TX, будет иметь значение
                      32768 (2¹⁵). Аналогичный интерфейс, поддерживающий 
                      полудуплексный и полнодуплексный режим 100Base-TX,
                      будет иметь значение 98304 (2¹⁵ + 2¹⁶).

                      Степени 2 для возможностей перечислены ниже.

                      Степень   Возможность
                        0       прочие и неизвестные 
                       (1-9)    (резерв)
                       10       10BASE-T, полудуплексный режим
                       11       10BASE-T, полнодуплексный режим
                       12       (резерв)
                       13       (резерв)
                       14       100BASE-T4
                       15       100BASE-TX, полудуплексный режим
                       16       100BASE-TX, полнодуплексный режим
                       17       (резерв)
                       18       (резерв)
                       19       100BASE-T2, полудуплексный режим
                       20       100BASE-T2, полнодуплексный режим

                      Отметим, что поддерживающие MIB интерфейсы могут
                      иметь возможности, выходящие за рамки этого MIB."
          REFERENCE   "[IEEE802.3], 30.6.1.1.5,
                      aAutoNegLocalTechnologyAbility."
          ::= { ifMauAutoNegEntry 5 }

      ifMauAutoNegCapAdvertised OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-write
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу 
                      ifMauAutoNegCapAdvertisedBits.

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

                      Возможности из этого объекта, не указанные в 
                      ifMauAutoNegCapability, не могут быть включены."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 6 }

      ifMauAutoNegCapReceived OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу
                      ifMauAutoNegCapReceivedBits.

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

                      Отметим, что интерфейсы, поддерживающие этот MIB,
                      могут быть подключены к удаленным элементам 
                      автосогласования, возможности которых выходят 
                      за рамки этого MIB."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 7 }

      ifMauAutoNegRestart OBJECT-TYPE
          SYNTAX      INTEGER {
                          restart(1),
                          norestart(2)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Если этот объект имеет значение restart(1), это
                      будет форсировать начало повторного автосогласования
                      для канала. Если сигналы автосогласования отключены,
                      значение этого объекта не играет роли. 
                      Установка значения norestart(2) не дает эффекта."
          REFERENCE   "[IEEE802.3], 30.6.1.2.1, acAutoNegRestartAutoConfig."
          ::= { ifMauAutoNegEntry 8 }

      ifMauAutoNegCapabilityBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей
                      локального элемента автосогласования. Отметим, что
                      интерфейсы, поддерживающие этот MIB, могут иметь
                      возможности, выходящие за рамки этого MIB.

                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.5, aAutoNegLocalTechnologyAbility."
          ::= { ifMauAutoNegEntry 9 }

      ifMauAutoNegCapAdvertisedBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей,
                      анонсируемый локальным элементом автосогласования.
                      Возможные значения этого объекта приведены в 
                      описании ifMauAutoNegCapability.

                      Возможности из этого объекта, не указанные в 
                      ifMauAutoNegCapabilityBits, не могут быть включены.

                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 10 }

      ifMauAutoNegCapReceivedBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей,
                      полученный от удаленного элемента автосогласования.
                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 11 }

      ifMauAutoNegRemoteFaultAdvertised OBJECT-TYPE
          SYNTAX      INTEGER {
                          noError(1),
                          offline(2),
                          linkFailure(3),
                          autoNegError(4)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Значение, указывающее все индикации локальных 
                      отказов, которые данный MAU обнаружил и будет 
                      анонсировать при следующем автосогласовании для 
                      MAU 1000 Мбит/с."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 12 }

      ifMauAutoNegRemoteFaultReceived OBJECT-TYPE
          SYNTAX      INTEGER {
                          noError(1),
                          offline(2),
                          linkFailure(3),
                          autoNegError(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, указывающее все индикации, принятые
                      от удаленной стороны канала локальным элементом
                      автосогласования для MAU 1000 Мбит/с."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 13 }

      --
      -- Таблица базовых Broadband MAU
      --

      broadMauBasicTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF BroadMauBasicEntry
          MAX-ACCESS  not-accessible
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Эта таблица отменена полностью. Реализаций таблицы
                      не было известно и не очевидно, что они были. IEEE
                      рекомендует не применять эти типы MAU в новых сетях.

                      Таблица описаний и данных состояния для broadband 
                      MAU, присоединенных к интерфейсам."
          ::= { dot3BroadMauBasicGroup 1 }

      broadMauBasicEntry OBJECT-TYPE
          SYNTAX      BroadMauBasicEntry
          MAX-ACCESS  not-accessible
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Запись таблицы с информацией об одном broadband MAU."
          INDEX       { broadMauIfIndex,
                        broadMauIndex
                      }
          ::= { broadMauBasicTable 1 }

      BroadMauBasicEntry ::=
          SEQUENCE {
              broadMauIfIndex                     InterfaceIndex,
              broadMauIndex                       Integer32,
              broadMauXmtRcvSplitType             INTEGER,
              broadMauXmtCarrierFreq              Integer32,
              broadMauTranslationFreq             Integer32
          }

      broadMauIfIndex OBJECT-TYPE
          SYNTAX      InterfaceIndex
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Однозначно указывает интерфейс, с которым соединен
                      описываемый этой записью MAU."
          REFERENCE   "RFC 2863, ifIndex."
          ::= { broadMauBasicEntry 1 }

      broadMauIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Однозначно указывает MAU, подключенный к интерфейсу
                      broadMauIfIndex описываемому этой записью."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
          ::= { broadMauBasicEntry 2 }

      broadMauXmtRcvSplitType OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          single(2),
                          dual(3)
                      }
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Указывает тип частотного мультиплексирования/
                      кабельной системы, используемый для разделения
                      путей передачи и приема 10BROAD36 MAU.

                      Значение other(1) возвращается в случаях, когда 
                      тип разделения не является ни single, ни dual.

                      Значение single(2) указывает систему с одним кабелем,
                      dual(3) — систему с двумя кабелями (смещение обычно 0)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.8, aBbMAUXmitRcvSplitType."
          ::= { broadMauBasicEntry 3 }

      broadMauXmtCarrierFreq OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Эта переменная указывает частоту передатчика 
                      10BROAD36 MAU в ¼ МГц (т. е. 250 КГц)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.9,
                      aBroadbandFrequencies.xmitCarrierFrequency."
          ::= { broadMauBasicEntry 4 }

      broadMauTranslationFreq OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Эта переменная указывает смещение частоты приемника 
                      10BROAD36 MAU в ¼ МГц (т. е. 250 Кгц)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.9,
                      aBroadbandFrequencies.translationFrequency."
          ::= { broadMauBasicEntry 5 }

      -- Уведомления для использования 802.3 MAU

      snmpDot3MauTraps OBJECT IDENTIFIER ::= { snmpDot3MauMgt 0 }

      rpMauJabberTrap NOTIFICATION-TYPE
          OBJECTS     { rpMauJabberState }
          STATUS      current
          DESCRIPTION "Это уведомление передается при переходе
                      управляемого MAU повторителя в состояние jabber.

                      Агент ДОЛЖЕН тормозить (дросселировать) генерацию 
                      последовательных rpMauJabberTraps так, чтобы интервал
                      между ними был не менее 5 секунд."
          REFERENCE   "[IEEE802.3], 30.5.1.3.1, nJabber notification."
          ::= { snmpDot3MauTraps 1 }

      ifMauJabberTrap NOTIFICATION-TYPE
          OBJECTS     { ifMauJabberState }
          STATUS      current
          DESCRIPTION "Это уведомление передается при переходе
                      управляемого MAU повторителя в состояние jabber.

                      Агент ДОЛЖЕН тормозить (дросселировать) генерацию 
                      последовательных ifMauJabberTraps так, чтобы интервал
                      между ними был не менее 5 секунд."

          REFERENCE   "[IEEE802.3], 30.5.1.3.1, nJabber notification."
          ::= { snmpDot3MauTraps 2 }

      -- Информация о соответствии

      mauModConf
              OBJECT IDENTIFIER ::= { mauMod 1 }
        mauModCompls
              OBJECT IDENTIFIER ::= { mauModConf 1 }
        mauModObjGrps
              OBJECT IDENTIFIER ::= { mauModConf 2 }
        mauModNotGrps
              OBJECT IDENTIFIER ::= { mauModConf 3 }

      -- Группа объектов

      mauRpGrpBasic OBJECT-GROUP
          OBJECTS     { rpMauGroupIndex,
                        rpMauPortIndex,
                        rpMauIndex,
                        rpMauType,
                        rpMauStatus,
                        rpMauMediaAvailable,
                        rpMauMediaAvailableStateExits,
                        rpMauJabberState,
                        rpMauJabberingStateEnters
                      }
          STATUS      current
          DESCRIPTION "Базовая группа соответствия для MAU, подключенных
                      к портам повторителя. Эта группа служит также
                      спецификацией соответствия для реализаций RFC 1515."
          ::= { mauModObjGrps 1 }

      mauRpGrp100Mbs OBJECT-GROUP
          OBJECTS     { rpMauFalseCarriers }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к портам
                      повторителя со скоростью не менее 100 Мбит/с."
          ::= { mauModObjGrps 2 }

      mauRpGrpJack OBJECT-GROUP
          OBJECTS     { rpJackType }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к портам
                      повторителя, с возможностью выбора разъема."
          ::= { mauModObjGrps 3 }

      mauIfGrpBasic OBJECT-GROUP
          OBJECTS     { ifMauIfIndex,
                        ifMauIndex,
                        ifMauType,
                        ifMauStatus,
                        ifMauMediaAvailable,
                        ifMauMediaAvailableStateExits,
                        ifMauJabberState,
                        ifMauJabberingStateEnters
                      }
          STATUS      current
          DESCRIPTION "Базовая группа соответствия для MAU, подключенных
                      к интерфейсам. Interfaces. Эта группа служит также
                      спецификацией соответствия для реализаций RFC 1515."
          ::= { mauModObjGrps 4 }

      mauIfGrp100Mbs OBJECT-GROUP
          OBJECTS     { ifMauFalseCarriers,
                        ifMauTypeList,
                        ifMauDefaultType,
                        ifMauAutoNegSupported
                      }

          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Группа соответствия для MAU, подключенных к
                      интерфейсам, поддерживающим 100 Мбит/с.

                      От этой группы отказались в пользу 
                      mauIfGrpHighCapacity."
          ::= { mauModObjGrps 5 }

      mauIfGrpJack OBJECT-GROUP
          OBJECTS     { ifJackType }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к
                      интерфейсам с возможностью выбора разъема."
          ::= { mauModObjGrps 6 }

      mauIfGrpAutoNeg OBJECT-GROUP
          OBJECTS     { ifMauAutoNegAdminStatus,
                        ifMauAutoNegRemoteSignaling,
                        ifMauAutoNegConfig,
                        ifMauAutoNegCapability,
                        ifMauAutoNegCapAdvertised,
                        ifMauAutoNegCapReceived,
                        ifMauAutoNegRestart
                      }
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Группа соответствия для MAU, подключенных
                      к интерфейсам с управляемым автосогласованием.

                      От этой группы отказались в пользу 
                      mauIfGrpAutoNeg2."
          ::= { mauModObjGrps 7 }

      mauBroadBasic OBJECT-GROUP
          OBJECTS     { broadMauIfIndex,
                        broadMauIndex,
                        broadMauXmtRcvSplitType,
                        broadMauXmtCarrierFreq,
                        broadMauTranslationFreq
                      }
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********
                      Группа соответствия для broadband MAU, подключенных
                      К интерфейсам.

                      Эта группа отменена. О реализациях ее ничего не
                      известно, а реализация в будущем не очевидна."
          ::= { mauModObjGrps 8 }

      mauIfGrpHighCapacity OBJECT-GROUP
          OBJECTS     { ifMauFalseCarriers,
                        ifMauTypeListBits,
                        ifMauDefaultType,
                        ifMauAutoNegSupported
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, присоединенных к 
                      интерфейсу с поддержкой не менее 100 Мбит/с."
          ::= { mauModObjGrps 9 }

      mauIfGrpAutoNeg2 OBJECT-GROUP
          OBJECTS     { ifMauAutoNegAdminStatus,
                        ifMauAutoNegRemoteSignaling,
                        ifMauAutoNegConfig,
                        ifMauAutoNegCapabilityBits,
                        ifMauAutoNegCapAdvertisedBits,
                        ifMauAutoNegCapReceivedBits,
                        ifMauAutoNegRestart
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, присоединенных к 
                      интерфейсу с поддержкой управляемого автосогласования."
          ::= { mauModObjGrps 10 }

      mauIfGrpAutoNeg1000Mbps OBJECT-GROUP
          OBJECTS     { ifMauAutoNegRemoteFaultAdvertised,
                        ifMauAutoNegRemoteFaultReceived
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU 1000 Мбит/с, присоединенных к 
                      интерфейсу с поддержкой управляемого автосогласования."
          ::= { mauModObjGrps 11 }

      mauIfGrpHCStats OBJECT-GROUP
          OBJECTS     { ifMauHCFalseCarriers }
          STATUS      current
          DESCRIPTION "Соответствие для высокоскоростной статистики 
                      MAU, присоединенных к интерфейсам."
          ::= { mauModObjGrps 12 }

      -- Группа уведомлений

      rpMauNotifications NOTIFICATION-GROUP
          NOTIFICATIONS { rpMauJabberTrap }
          STATUS      current
          DESCRIPTION "Уведомления для MAU повторителя."
          ::= { mauModNotGrps 1 }

      ifMauNotifications NOTIFICATION-GROUP
          NOTIFICATIONS { ifMauJabberTrap }
          STATUS      current
          DESCRIPTION "Уведомления для MAU интерфейса."
          ::= { mauModNotGrps 2 }

      -- Compliances

      mauModRpCompl MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********
                      Соответствие для MAU, подключенных к портам
                      повторителя.

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

          MODULE — данный модуль
              MANDATORY-GROUPS { mauRpGrpBasic }

              GROUP       mauRpGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauRpGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       rpMauNotifications
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU, подключенных к портам повторителя."
          ::= { mauModCompls 1 }

      mauModIfCompl MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********

                      Соответствие для MAU, подключенных к интерфейсам.
                      Этот соответствие отменено с заменой на mauModIfCompl2."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauBroadBasic
              DESCRIPTION "Реализация этой группы обязательна для
                          broadband MAUs."

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU, подключенных к интерфейсам."
          ::= { mauModCompls 2 }

      mauModIfCompl2 MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********

                      Соответствие для MAU, подключенных к интерфейсам.

                      Этот соответствие отменено с заменой на mauModIfCompl3."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrpHighCapacity
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpJack

              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой скорости 100 Мбит/с и выше, а также
                          управляемого автосогласования.

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой группы рекомендуется
                          для MAU, подключенных к интерфейсам."

              OBJECT      ifMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 3 }

      mauModRpCompl2 MODULE-COMPLIANCE
          STATUS      current
          DESCRIPTION "Соответствие для MAU, подключенных к портам повторителя.

                      Отметим, что это требует соответствия заявлению
                      snmpRptrModCompl MODULE-COMPLIANCE в
                      SNMP-REPEATER-MIB (RFC 2108)."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauRpGrpBasic }

              GROUP       mauRpGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauRpGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       rpMauNotifications

              DESCRIPTION "Реализация этой группы рекомендуется
                          для MAU, подключенных к портам повторителя."

              OBJECT      rpMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 4 }

      mauModIfCompl3 MODULE-COMPLIANCE
          STATUS      current
          DESCRIPTION "Соответствие для MAU, подключенных к интерфейсам.

                      Отметим, что это требует соответствия заявлению
                      ifCompliance3 MODULE-COMPLIANCE в IF-MIB (RFC 2863)
                      и dot3Compliance2 MODULE-COMPLIANCE в
                      EtherLike-MIB (RFC3635)."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrpHighCapacity
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpHCStats
              DESCRIPTION "Реализация этой группы обязательна рекомендуется
                          для MAU с поддержкой скорости 1000 Мбит/с и
                          рекомендуется для 100 Мбит/с.

              GROUP       mauIfGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой скорости 1000 Мбит/с и выше, а также
                          управляемого автосогласования"

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой группы рекомендуется для
                          MAU, подключенных к интерфейсам."

              OBJECT      ifMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 5 }

   END

5. Администрируемые IANA определения MAU TC

   IANA-MAU-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY, mib-2
         FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
         FROM SNMPv2-TC
       ;

     ianaMauMIB MODULE-IDENTITY
       LAST-UPDATED "200704210000Z"  -- 21 апреля 2007 г.
       ORGANIZATION "IANA"
       CONTACT-INFO "        Internet Assigned Numbers Authority

                     Postal: ICANN
                             4676 Admiralty Way, Suite 330
                             Marina del Rey, CA 90292

                        Tel: +1-310-823-9358
                      EMail: iana@iana.org"

       DESCRIPTION
         "Этот модуль MIB определяет dot3MauType OBJECT-IDENTITY и
         текстовые соглашения IANAifMauListBits, IANAifMauMediaAvailable,
         IANAifMauAutoNegCapBits и IANAifJackType, задающие перечисляемые
         значения объектов ifMauTypeListBits, ifMauMediaAvailable/
         rpMauMediaAvailable, ifMauAutoNegCapabilityBits/
         ifMauAutoNegCapAdvertisedBits/ifMauAutoNegCapReceivedBits и
         ifJackType/rpJackType, соответственно, определенные в MAU-MIB.

         Предполагается, что каждый новый тип MAU, состояние Media 
         Availability, возможность Auto Negotiation и/или тип Jack, 
         определенные рабочей группой IEEE 802.3 и одобренные для
         публикации в IEEE Std 802.3, будут добавляться в этот модуль
         MIB, в предположении, что они будут управляться базовыми
         объектами MAU-MIB. Для таких дополнений нужна процедура
         Expert Review, определенная в RFC 2434 [RFC2434].

         Ниже приведены ссылки, используемые в данном модуле MIB.

         [IEEE802.3]
            IEEE Std 802.3, 2005 Edition: 'IEEE Standard for
            Information technology - Telecommunications and information
            exchange between systems - Local and metropolitan area
            networks - Specific requirements -
            Part 3: Carrier sense multiple access with collision
            detection (CSMA/CD) access method and physical layer
            specifications'.

         Эту ссылку следует обновлять при добавлении в модуль новых
         типов MAU, состояний Media Availability, возможностей Auto 
         Negotiation и/или типов Jack.

         Copyright (C) The IETF Trust (2007).
         Исходная версия этого модуля MIB опубликована в RFC 4836, 
         где правовые вопросы рассмотрены более подробно. 
         Дополнительная информация доступна по ссылке
         http://www.ietf.org/copyrights/ianamib.html" 

       REVISION     "200704210000Z"  -- 21 апреля 2007 г.
       DESCRIPTION  "Исходная версия этого модуля опубликована в RFC 4836."
       ::= { mib-2 154 }

     -- Текстовые соглашения

     IANAifMauTypeListBits ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных используется в качестве синтаксиса объектов 
         ifMauTypeListBits в (обновленном) определении MAU-MIB ifMauTable.

         Актуальный вариант этого текстового соглашения доступен в версии
         этого модуля MIB на сайте IANA.

         Запросы новых значений следует отправлять в IANA п адресу
         iana@iana.org. 

         Отметим, что изменения этого текстового соглашения НУЖНО 
         согласовывать с соответствующими изменениями dot3MauType
         OBJECT-IDENTITY."
       REFERENCE
         "[IEEE802.3], Section 30.5.1.1.2"
       SYNTAX       BITS {
              bOther(0),          -- другие и неизвестные
              bAUI(1),            -- AUI
              b10base5(2),        -- 10BASE-5
              bFoirl(3),          -- FOIRL

              b10base2(4),        -- 10BASE-2
              b10baseT(5),        -- 10BASE-T, режим дуплекса не известен
              b10baseFP(6),       -- 10BASE-FP
              b10baseFB(7),       -- 10BASE-FB
              b10baseFL(8),       -- 10BASE-FL, режим дуплекса не известен
              b10broad36(9),      -- 10BROAD36
              b10baseTHD(10),     -- 10BASE-T, полудуплексный
              b10baseTFD(11),     -- 10BASE-T, полнодуплексный
              b10baseFLHD(12),    -- 10BASE-FL, полудуплексный
              b10baseFLFD(13),    -- 10BASE-FL, полнодуплексный
              b100baseT4(14),     -- 100BASE-T4
              b100baseTXHD(15),   -- 100BASE-TX, полудуплексный
              b100baseTXFD(16),   -- 100BASE-TX, полнодуплексный
              b100baseFXHD(17),   -- 100BASE-FX, полудуплексный
              b100baseFXFD(18),   -- 100BASE-FX, полнодуплексный
              b100baseT2HD(19),   -- 100BASE-T2, полудуплексный
              b100baseT2FD(20),   -- 100BASE-T2, полнодуплексный

              b1000baseXHD(21),   -- 1000BASE-X, полудуплексный
              b1000baseXFD(22),   -- 1000BASE-X, полнодуплексный
              b1000baseLXHD(23),  -- 1000BASE-LX, полудуплексный
              b1000baseLXFD(24),  -- 1000BASE-LX, полнодуплексный
              b1000baseSXHD(25),  -- 1000BASE-SX, полудуплексный
              b1000baseSXFD(26),  -- 1000BASE-SX, полнодуплексный
              b1000baseCXHD(27),  -- 1000BASE-CX, полудуплексный
              b1000baseCXFD(28),  -- 1000BASE-CX, полнодуплексный
              b1000baseTHD(29),   -- 1000BASE-T, полудуплексный
              b1000baseTFD(30),   -- 1000BASE-T, полнодуплексный

              b10GbaseX(31),      -- 10GBASE-X
              b10GbaseLX4(32),    -- 10GBASE-LX4
              b10GbaseR(33),      -- 10GBASE-R
              b10GbaseER(34),     -- 10GBASE-ER
              b10GbaseLR(35),     -- 10GBASE-LR
              b10GbaseSR(36),     -- 10GBASE-SR
              b10GbaseW(37),      -- 10GBASE-W
              b10GbaseEW(38),     -- 10GBASE-EW
              b10GbaseLW(39),     -- 10GBASE-LW
              b10GbaseSW(40),     -- 10GBASE-SW
              --  новые, после RFC 3636
              b10GbaseCX4(41),    -- 10GBASE-CX4
              b2BaseTL(42),       -- 2BASE-TL
              b10PassTS(43),      -- 10PASS-TS
              b100BaseBX10D(44),  -- 100BASE-BX10D
              b100BaseBX10U(45),  -- 100BASE-BX10U
              b100BaseLX10(46),   -- 100BASE-LX10
              b1000BaseBX10D(47), -- 1000BASE-BX10D
              b1000BaseBX10U(48), -- 1000BASE-BX10U
              b1000BaseLX10(49),  -- 1000BASE-LX10
              b1000BasePX10D(50), -- 1000BASE-PX10D
              b1000BasePX10U(51), -- 1000BASE-PX10U
              b1000BasePX20D(52), -- 1000BASE-PX20D
              b1000BasePX20U(53)  -- 1000BASE-PX20U
         }

     IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных используется в качестве синтаксиса объектов
         ifMauMediaAvailable и rpMauMediaAvailable в (обновленном)
         определении MAU-MIB ifMauTable и rpMauTable, соответственно.

         Возможные значения:
           other(1)             - не определен (не относится к указанным ниже)
           unknown(2)           - реальное состояние MAU не известно (например,
                                  в процессе инициализации)
           available(3)         - link, light или loopback в обычном состоянии
           notAvailable(4)      - link loss, low light или no loopback
           remoteFault(5)       - обнаружен отказ на удаленной стороне канала;
                                  это значение применимо к 10BASE-FB и 100BASE-T4 
                                  Far End Fault Indication, а также другим отказам
                                  на удаленной стороне в системах с автосогласованием
           invalidSignal(6)     - получен непригодный сигнал от другой стороны
                                  (только 10BASE-FB)
           remoteJabber(7)      - отказ на удаленной стороне, jabber
           remoteLinkLoss(8)    - отказ на удаленной стороне, потеря связи
           remoteTest(9)        - отказ на удаленной стороне, тест
           offline(10)          - отключен (только Auto-Negotiation, п. 37)
           autoNegError(11)     - ошибка автосогласования 
                                  (только Auto-Negotiation, п. 37)
           pmdLinkFault(12)     - отказ приема PMA/PMD; в случае PAF 
                                  (2BASE-TL/10PASS-TS PHY) отказ канала 
                                  на всех PME в группе
           wisFrameLoss(13)     - потеря кадра WIS, только 10GBASE-W
           wisSignalLoss(14)    - потеря сигнала WIS, только 10GBASE-W
           pcsLinkFault(15)     - отказ PCS на приемном канале
           excessiveBER(16)     - монитор PCS Bit Error Ratio указал
                                  слишком много ошибок
           dxsLinkFault(17)     - отказ DTE XGXS на приемном канале, только XAUI
           pxsLinkFault(18)     - отказ PHY XGXS на приемном канале, только XAUI
           availableReduced(19) — нормальный канал, снижение скорости, только
                                  2BASE-TL/10PASS-TS
           ready(20)            - по крайней мере один канал в группе PME 
                                  детектировал сигналы согласования, только
                                  2BASE-TL/10PASS-TS.

         Если MAU относится к каналу 10 Мбит/с или оптическому типу 
         (FOIRL, 10BASE-T, 10BASE-F), это эквивалентно функции проверки отказа 
         при тесте/малого уровня оптического сигнала. Для AUI, 10BASE2, 10BASE5 
         или 10BROAD36 это показывает обнаружение петли (loopback) на устройстве
         DI. Значение этого атрибута сохраняется от пакета к пакету для MAU
         типов AUI, 10BASE5, 10BASE2, 10BROAD36 и 10BASEFP.

         При включении питания или Media Available принимает значение
         unknown(2) для AUI, 10BASE5, 10BASE2, 10BROAD36 и 10BASE-FP.
         Для таких MAU будет выполняться шлейфовый (loopback) тест при
         каждой передаче в течение которой не было обнаружен конфликтов.
         Если DI принимает данные, когда DO возвращено в IDL после
         передачи, при которой не возникло конфликтов, петля будет 
         обнаружена. Состояние Media Available будет меняться лишь в 
         процессе передачи без конфликтов для AUI, 10BASE2, 10BASE5, 
         10BROAD36 и 10BASE-FP.

         Для 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX,
         100BASE-LX10 и 100BASE-BX10 PHY перечисляемые значения
         соответствуют состояниям диаграммы целостности канала.
         Все MAU, реализующие раздел 28 [IEEE802.3] (Auto-Negotiation), 
         будут отображать индикацию удаленного отказа на remoteFault(5).

         Все MAU, реализующие раздел 37 Auto-Negotiation, будут 
         отображать принятые биты RF1 и RF2 следующим образом:
         Offline отображается на offline(10), Link_Failure - на
         remoteFault(5), Auto-Negotiation Error — на autoNegError(11).

         Значение remoteFault(5) применяется к индикации удаленного 
         отказа 10BASE-FB, индикации отказа 100BASE-X на удаленной стороне 
         и неизвестного удаленного отказа в системах, поддерживающий 
         Auto-Negotiation (раздел 28).

         Значения remoteJabber(7), remoteLinkLoss(8) или remoteTest(9)
         СЛЕДУЕТ применять вместо remoteFault(5), когда причина отказа
         указана протоколом сигнализации.
         При наличии MII (раздел 22) или GMII (раздел 35) значение 1
         бита удаленных отказов отображается на значение remoteFault(5),
         а 0 — на notAvailable(4). Значение notAvailable(4) имеет 
         преимущество перед remoteFault(5).

         Для 2BASE-TL и 10PASS-TS PHY значение unknown(2) отображается
         на условие инициализации PHY (PCS с подключенными PME), 
         ready(20) отображается на отключенный интерфейс с хотя бы одним
         PME в группе агрегирования, готовым к согласованию, available(3) 
         отображается на условие, когда все PME в группе агрегирования
         активны, notAvailable(4) — на условие, когда все PME в группе
         выключены и нет сигналов согласования, availableReduced(19) - 
         на условие, когда интерфейс активен и обнаружен отказ канала
         в приемном направлении одним или несколькими PME в группе
         агрегирования и хотя бы один PME активен, а pmdLinkFault(12) 
         отображается на условие обнаружения отказа в приемном направлении
         всеми PME в группе агрегирования.

         Для 10 Гбит/с перечисляемые значения отображаются на переменную 
         link_fault диаграммы состояний Link Fault Signaling - значение
         OK отображается на available(3), Local Fault — на notAvailable(4),
         а Remote Fault — на remoteFault(5). Значение pmdLinkFault(12), 
         wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), 
         excessiveBER(16) или dxsLinkFault(17) СЛЕДУЕТ применять вместо
         notAvailable(4) в тех случаях, когда причину состояния Local Fault
         можно указать с использованием интерфейса MDIO (раздел 45). При
         наличии множества причин состояния Local Fault СЛЕДУЕТ выбирать
         ошибку с высшим приоритетом, из приведенного списка по убыванию:
           pxsLinkFault
           pmdLinkFault
           wisFrameLoss
           wisSignalLoss
           pcsLinkFault
           excessiveBER
           dxsLinkFault.

         При наличии интерфейса MDIO (раздел 45) 0 в бите состояния
         PMA/PMD Receive ([IEEE802.3] параграф 45.2.1.2.2) отображается 
         на значение pmdLinkFault(12), 1 в бите состояния LOF (параграф
         45.2.2.10.4) — на wisFrameLoss(13), 1 в бите состояния LOS
         (параграф 45.2.2.10.5) — на wisSignalLoss, 0 в бите состояния 
         PCS Receive link (параграф 45.2.3.2.2) — на pcsLinkFault(15),
         1 в бите состояния 10GBASE-R PCS Latched high BER (параграф
         45.2.3.12.2) — на excessiveBER, 0 в бите состояния DTE XS 
         приемного канала (параграф 45.2.5.2.2) — на dxsLinkFault(17),
         а 0 в бите состояния PHY XS передающего канала (параграф
         45.2.4.2.2) — на pxsLinkFault(18).

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)." 
       REFERENCE
         "[IEEE802.3], Section 30.5.1.1.4"
       SYNTAX       INTEGER {
              other(1),
              unknown(2),
              available(3),
              notAvailable(4),
              remoteFault(5),
              invalidSignal(6),
              remoteJabber(7),
              remoteLinkLoss(8),
              remoteTest(9),
              offline(10),
              autoNegError(11),
              pmdLinkFault(12),
              wisFrameLoss(13),
              wisSignalLoss(14),
              pcsLinkFault(15),
              excessiveBER(16),
              dxsLinkFault(17),
              pxsLinkFault(18),
              availableReduced(19),
              ready(20)
         }

     IANAifMauAutoNegCapBits ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных служит в качестве синтаксиса объектов
         ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits и
         ifMauAutoNegCapReceivedBits в (обновленном) определении
         ifMauAutoNegTable в модуле MAU-MIB.

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)."
       REFERENCE	"[IEEE802.3], Section 30.6.1.1.5"
       SYNTAX       BITS {
              bOther(0),          -- прочие или неизвестные
              b10baseT(1),        -- 10BASE-T, полудуплексный режим
              b10baseTFD(2),      -- 10BASE-T, полнодуплексный режим
              b100baseT4(3),      -- 100BASE-T4
              b100baseTX(4),      -- 100BASE-TX, полудуплексный режим
              b100baseTXFD(5),    -- 100BASE-TX, полнодуплексный режим
              b100baseT2(6),      -- 100BASE-T2, полудуплексный режим
              b100baseT2FD(7),    -- 100BASE-T2, полнодуплексный режим
              bFdxPause(8),       -- PAUSE для полнодуплексных каналов
              bFdxAPause(9),      -- Asymmetric PAUSE для полнодуплексных
                                  --     каналов
              bFdxSPause(10),     -- Symmetric PAUSE для полнодуплексных
                                  --     каналов
              bFdxBPause(11),     -- Asymmetric и Symmetric PAUSE для
                                  --     полнодуплексных каналов
              b1000baseX(12),     -- 1000BASE-X, -LX, -SX, -CX,
                                  --     полудуплексный режим
              b1000baseXFD(13),   -- 1000BASE-X, -LX, -SX, -CX,
                                  --     полнодуплексный режим
              b1000baseT(14),     -- 1000BASE-T, полудуплексный режим
              b1000baseTFD(15)    -- 1000BASE-T, полнодуплексный режим
         }

     IANAifJackType ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Общие перечисляемые значения для типов разъемов в MAU интерфейсов
         и повторителей. Этот тип данных служит синтаксисом для объектов
         ifJackType и rpJackType в (обновленных) определениях MAU-MIB
         ifJackTable и rpJackTable, соответственно.

         Возможные значения указаны ниже.
              other(1)          - не определен или не известен
              rj45(2)           - RJ45
              rj45S(3)          - RJ45 с экраном
              db9(4)            - DB9
              bnc(5)            - BNC
              fAUI(6)           - розетка AUI
              mAUI(7)           - вилка AUI 
              fiberSC(8)        - оптика SC
              fiberMIC(9)       - оптика MIC 
              fiberST(10)       - оптика ST 
              telco(11)         - Telco
              mtrj(12)          - оптика MT-RJ 
              hssdc(13)         - оптический канал style-2
              fiberLC(14)       - оптика LC 
              cx4(15)           - IB4X для 10GBASE-CX4

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)."
       SYNTAX       INTEGER {
              other(1),
              rj45(2),
              rj45S(3),
              db9(4),
              bnc(5),
              fAUI(6),
              mAUI(7),
              fiberSC(8),
              fiberMIC(9),
              fiberST(10),
              telco(11),
              mtrj(12),
              hssdc(13),
              fiberLC(14),
              -- добавлено в RFC 3636
              cx4(15)
         }

     -- OBJECT IDENTITY для типов MAU 
     -- (см. rpMauType и ifMauType в MAU-MIB, где описано применение)
     -- Приведенные ниже определения были перемещены из RFC 3636 и
     -- не будут включаться в новые выпуски.

     dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 }

     dot3MauTypeAUI OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Нет внутреннего MAU, виден через AUI"
       REFERENCE   "[IEEE802.3], Section 7"
       ::= { dot3MauType 1 }

     dot3MauType10Base5 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для толстого коаксиала"
       REFERENCE   "[IEEE802.3], Section 7"
       ::= { dot3MauType 2 }

     dot3MauTypeFoirl OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "FOIRL MAU"
       REFERENCE   "[IEEE802.3], Section 9.9"
       ::= { dot3MauType 3 }

     dot3MauType10Base2 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для тонкого коаксиала"
       REFERENCE   "[IEEE802.3], Section 10"
       ::= { dot3MauType 4 }

     dot3MauType10BaseT OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU.
                   Отметим, что агентам настоятельно рекомендуется
                   возвращать значение dot3MauType10BaseTHD или
                   dot3MauType10BaseTFD при известном режиме дуплекса.
                   Однако программам управления следует быть готовыми
                   получать это значение типа MAU от старых агентов."
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 5 }

     dot3MauType10BaseFP OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для пассивной оптики"
       REFERENCE   "[IEEE802.3], Section 16"
       ::= { dot3MauType 6 }

     dot3MauType10BaseFB OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для синхронной оптики"
       REFERENCE   "[IEEE802.3], Section 17"
       ::= { dot3MauType 7 }

     dot3MauType10BaseFL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для асинхронной оптики.
                   Отметим, что агентам настоятельно рекомендуется
                   возвращать значение dot3MauType10BaseFLHD или
                   dot3MauType10BaseFLFD при известном режиме дуплекса.
                   Однако программам управления следует быть готовыми
                   получать это значение типа MAU от старых агентов."
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 8 }

     dot3MauType10Broad36 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для широкополосного DTE.
                   Отметим, что 10BROAD36 MAU могут подключаться к
                   интерфейсам, но не к повторителям."
       REFERENCE   "[IEEE802.3], Section 11"
       ::= { dot3MauType 9 }

     ------ добавлены в RFC 1515
     dot3MauType10BaseTHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 10 }

     dot3MauType10BaseTFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 11 }

     dot3MauType10BaseFLHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "async fiber MAU, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 12 }

     dot3MauType10BaseFLFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "async fiber MAU, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 13 }

     dot3MauType100BaseT4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 3"
       REFERENCE   "[IEEE802.3], Section 23"
       ::= { dot3MauType 14 }

     dot3MauType100BaseTXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 5, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 25"
       ::= { dot3MauType 15 }

     dot3MauType100BaseTXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 5, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 25"
       ::= { dot3MauType 16 }

     dot3MauType100BaseFXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно на основе PMT, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 26"
       ::= { dot3MauType 17 }

     dot3MauType100BaseFXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно на основе PMT, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 26"
       ::= { dot3MauType 18 }

     dot3MauType100BaseT2HD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 3, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 32"
       ::= { dot3MauType 19 }

     dot3MauType100BaseT2FD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 3, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 32"
       ::= { dot3MauType 20 }

     ------ добавлены в RFC 2239:
     dot3MauType1000BaseXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "PCS/PMA, неизвестный PMD, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 36"
       ::= { dot3MauType 21 }

     dot3MauType1000BaseXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "PCS/PMA, неизвестный PMD, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 36"
       ::= { dot3MauType 22 }

     dot3MauType1000BaseLXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с длинноволновым лазером, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 23 }

     dot3MauType1000BaseLXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с длинноволновым лазером, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 24 }

     dot3MauType1000BaseSXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с коротковолновым лазером, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 25 }

     dot3MauType1000BaseSXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с коротковолновым лазером, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 26 }

     dot3MauType1000BaseCXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "150-омный сбалансированный кабель, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 39"
       ::= { dot3MauType 27 }

     dot3MauType1000BaseCXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "150-омный сбалансированный кабель, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 39"
       ::= { dot3MauType 28 }

     dot3MauType1000BaseTHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 5, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 40"
       ::= { dot3MauType 29 }

     dot3MauType1000BaseTFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 5, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 40"
       ::= { dot3MauType 30 }

     ------ добавлены в RFC 2668:
     dot3MauType10GigBaseX OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 48"
       ::= { dot3MauType 31 }

     dot3MauType10GigBaseLX4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно с WWDM"
       REFERENCE   "[IEEE802.3], Section 53"
       ::= { dot3MauType 32 }

     dot3MauType10GigBaseR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 49"
       ::= { dot3MauType 33 }

     dot3MauType10GigBaseER OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 1550 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 34 }

     dot3MauType10GigBaseLR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 1310 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 35 }

     dot3MauType10GigBaseSR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 850 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 36 }

     dot3MauType10GigBaseW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 49 and 50"
       ::= { dot3MauType 37 }

     dot3MauType10GigBaseEW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 1550 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 38 }

     dot3MauType10GigBaseLW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 1310 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 39 }

     dot3MauType10GigBaseSW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 850 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 40 }

     ------ добавлено в RFC 3636:
     dot3MauType10GigBaseCX4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "8-парный сбалансированный кабель 100 Ом"
       REFERENCE   "[IEEE802.3], Section 54"
       ::= { dot3MauType 41 }

     dot3MauType2BaseTL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Телефонный кабель UTP до 2700 м, необязательный PAF"
       REFERENCE   "[IEEE802.3], Sections 61 and 63"
       ::= { dot3MauType 42 }

     dot3MauType10PassTS OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Телефонный кабель UTP до 750 м, необязательный PAF"
       REFERENCE   "[IEEE802.3], Sections 61 and 62"
       ::= { dot3MauType 43 }

     dot3MauType100BaseBX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одно волокно OLT, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 44 }

     dot3MauType100BaseBX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно ONU, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 45 }

     dot3MauType100BaseLX10 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 одномодовых волокна, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 46 }

     dot3MauType1000BaseBX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно OLT, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 47 }

     dot3MauType1000BaseBX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно ONU, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 48 }

     dot3MauType1000BaseLX10 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 одномодовых волокна, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 49 }

     dot3MauType1000BasePX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON OLT, 10 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 50 }

     dot3MauType1000BasePX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON ONU, 10 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 51 }

     dot3MauType1000BasePX20D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON OLT, 20 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 52 }

     dot3MauType1000BasePX20U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON ONU, 20 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 53 }

   END

6. Вопросы безопасности

IANA-MAU-MIB не определяет каких-либо объектов управления. Вместо этого модуль определяет набор текстовых соглашений, используемых MAU-MIB, которые могут также применяться в других модулях MIB для определения объектов управления. Значимое рассмотрение вопросов безопасности может быть проведено лишь для модулей MIB, определяющих объекты управления.

Для множества объектов, определенных в MAU-MIB, установлено MAX-ACCESS для чтения и записи (read-write). Установка таких объектов может существенно влиять на работу сети, включая:

отключение и включение MAU;
смена принятого по умолчанию типа MAU;
включение, отключение или перезапуск автосогласования;
изменение возможностей, анонсируемых MAU при автосогласовании.

Такие объекты могут быть уязвимы в некоторых сетевых средах. Поддержка операций SET в небезопасной среде без подобающей защиты может негативно повлиять на работу сети.

Некоторые из доступных для чтения объектов данного модуля MIB (т. е. объекты, у которых MAX-ACCESS отличается от not-accessible) могут быть уязвимы в некоторых сетевых средах. В некоторых средах может оказаться нежелательным доступ неуполномоченных сторон к статистике работы отдельных каналов. Поэтому важно контролировать доступ GET и/или NOTIFY к таким объектам и по возможности шифровать объекты при передаче через сеть по протоколу SNMP.

Протокол SNMP до версии SNMPv3 не обеспечивает адекватной защиты. Даже в защищенной сети (например, с помощью IPSec) нет возможности персонально контролировать доступ GET/SET (чтение, изменение, создание, удаление) к объектам модуля MAU-MIB.

Разработчикам рекомендуется рассмотреть функции защиты, обеспечиваемые SNMPv3 (см. раздел 8 [RFC3410]), включая полную поддержку криптографических механизмов SNMPv3 (для аутентификации и конфиденциальности).

Более того, развертывание версий SNMP до SNMPv3 не рекомендуется. Вместо этого рекомендуется использовать SNMPv3 и включать криптографическую защиту. Тогда на абонентов/операторов ложится ответственность за обеспечение того, чтобы объект SNMP, предоставляющий доступ к экземпляру этого модуля MIB, был правильно настроен для предоставления доступа к объектам лишь тем элементам (пользователям), которые имеют легитимные права выполнять операции GET или SET (изменить, создать, удалить).

7. Взаимодействие с IANA

Этот документ определяет первую версию администрируемого IANA модуля IANA-MAU-MIB. Предполагается, что каждый новый тип MAU, состояние Media Available, возможность Auto Negotiation и/или тип разъема, определенные рабочей группой IEEE 802.3 и одобренные для включения в IEEE Std 802.3, будут добавляться в поддерживаемый IANA модуль MIB при условии, что он может управляться базовыми объектами из модуля MAU-MIB.

При добавлении каждого нового типа MAU следует давать краткое описание технологии MAU и, по возможности, ссылку на публично доступную спецификацию. Для каждого изменения требуется процедура Expert Review, определенная в RFC 2434 [RFC2434].

8. Благодарности

Этот документ подготовлен рабочей группой IETF Ethernet Interfaces and Hub MIB, в которой следует особо подчеркнуть усилия Mike Heard, John Flick и Dan Romascanu.

Документ основан на предложенном стандарте MAU MIB, RFC 3636 [RFC3636] под редакцией John Flick из Hewlett-Packard, подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ расширен путем переноса отождествлений объектов и текстовых соглашений для типов MAU в поддерживаемый IANA модуль MIB. Кроме того, обеспечивается поддержка EFM и 10GBASE-CX4 MAU, определенных в [IEEE802.3ah] и [IEEE802.3ak], соответственно.

RFC 3636 был основан на предложенном стандарте MAU MIB, RFC 2668 [RFC2668] под редакцией John Flick из Hewlett-Packard и Andrew Smith (тогда Extreme Networks), подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ был расширен путем добавления поддержки MAU 10 Гбит/с, определенных в [IEEE802.3ae].

RFC 2668 был основан на предложенном стандарте MAU MIB, RFC 2239 [RFC2239] под редакцией Kathryn de Graaf (тогда 3Com) и Dan Romascanu (тогда Madge Networks), подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ был расширен путем добавления поддержки MAU 1000 Мбит/с, согласования PAUSE и статуса удаленных отказов, как определено в [IEEE802.3].

RFC 2239 был основан на предложенном стандарте MAU MIB, RFC 1515 [RFC1515] под редакцией Donna McMaster (тогда SynOptics Communications), Keith McCloghrie (тогда Hughes LAN Systems) и Sam Roberts (тогда Farallon Computing), подготовленном рабочей группой Hub MIB. Документ был расширен путем добавления поддержки MAU 100 Мбит/с, полнодуплексных MAU, автосогласования и управления разъемами, как определено в [IEEE802.3].

9. Литература

9.1. Нормативные документы

[IEEE802.3] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications», IEEE Std 802.3-2005, December 2005.

[IEEE802.3ae] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control (MAC) Parameters, Physical Layer and Management Parameters for 10 Gb/s Operation», IEEE Std 802.3ae-2002, August 2002.

[IEEE802.3ah] IEEE, «Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks», IEEE Std 802.3ah-2004, September 2004.

[IEEE802.3ak] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Physical Layer and Management Parameters for 10Gb/s Operation, Type 10GBASE-CX4», IEEE Std 802.3ak-2004, March 2004.

[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, «Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2», RFC 2108, February 1997.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[RFC3635] Flick, J., «Definitions of Managed Objects for the Ethernet-like Interface Types», RFC 3635, September 2003.

9.2. Дополнительная литература

[RFC1515] McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 1515, September 1993.

[RFC2239] de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2», RFC 2239, November 1997.

[RFC2668] Smith, A., Flick, J., de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 2668, August 1999.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

[RFC3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, December 2002.

[RFC3636] Flick, J., «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 3636, September 2003.

[RFC3637] Heard, C., «Definitions of Managed Objects for the Ethernet WAN Interface Sublayer», RFC 3637, September 2003.

Адрес автора

Edward Beili

Actelis Networks

Bazel 25

Petach-Tikva

Israel

Phone: +972-3-924-3491

EMail: edward.beili@actelis.com

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Management Information Base — база информации для управления.

2Medium Attachment Unit — модуль подключения к среде передачи.

3Internet Assigned Number Authority

4Ethernet in the First Mile — Ethernet на первой миле.

5Simple Network Management Protocol.

6Structure of Management Information — структура информации управления.

Рубрика: RFC | Комментарии отключены

RFC 4884 Extended ICMP to Support Multi-Part Messages

Опубликовано 09.04.2007 автором Nikolai Malykh

Network Working Group                                      R. Bonica
Request for Comments: 4884                          Juniper Networks
Updates: 792, 4443                                            D. Gan
Category: Standards Track                                 Consultant
                                                           D. Tappan
                                                          Consultant
                                                        C. Pignataro
                                                 Cisco Systems, Inc.
                                                          April 2007

Расширенный протокол ICMP для поддержки сообщений из нескольких частей

Extended ICMP to Support Multi-Part Messages

Статус документа

В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа Internet Official Protocol Standards (STD 1). Документ может распространяться без ограничений.

Авторские права

Аннотация

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

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

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

Предложенные модификации меняют требования совместимости для ICMP. Влияние этих изменений на соответствующие требованиям спецификации реализации протокола рассматривается в этом документе. Приведены также требования к будущим реализациям.

Этот документ является обновлением RFC 792 и RFC 4443.

Оглавление

Исключено из версии HTML

1. Введение

В этом документе заново определены сообщения ICMPv4 [RFC0792] и ICMPv6 [RFC4443] для включения структуры расширения и атрибута размера. Структура расширения поддерживает многокомпонентные операции ICMP. Разработчики протоколов могут создавать сообщения ICMP, передающие дополнительную информацию, которая представляется с помощью структуры расширения.

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

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

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

В этом документе не определяются объекты расширения ICMP. Определен только заголовок расширения и заголовок, используемый всеми объектами. В работах [UNNUMBERED], [ROUTING-INST] и [MPLS-ICMP] описаны примеры применения объектов расширения ICMP.

Упомянутые выше документы имеют ряд общих характеристик. Они добавляют информацию к сообщениям ICMP Time Expired для программ трассировки (TRACEROUTE). В этом случае, как и во многих других, добавление информации к существующему сообщению ICMP Time Expired более предпочтительно, чем определение нового сообщения и генерация двух сообщений вместо одного при отбрасывании пакетов по причине обнуления TTL.

2. Используемые в документе соглашения

3. Список изменений ICMP

Ниже приводится список изменений в ICMP, вносимых данным документом.

ICMP Extension Structure может добавляться в конец сообщений ICMPv4 Destination Unreachable, Time Exceeded и Parameter Problem.

ICMP Extension Structure может добавляться в конец сообщений ICMPv6 Destination Unreachable и Time Exceeded.

Перечисленные выше сообщения включают поле «исходной дейтаграммы» и формат сообщений обновлен с добавлением атрибута размера поля «исходной дейтаграммы».

При добавлении структуры расширения ICMP в конец сообщения ICMP, содержащего поле «исходной дейтаграммы», это поле должно содержать не менее 128 октетов.

При добавлении структуры расширения ICMP в конец сообщения ICMPv4, содержащего поле «исходной дейтаграммы», это поле должно быть дополнено нулями для выравнивания по ближайшей 32-битовой границе.

При добавлении структуры расширения ICMP в конец сообщения ICMPv6, содержащего поле «исходной дейтаграммы», это поле должно быть дополнено нулями для выравнивания по ближайшей 64-битовой границе.

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

4. Расширяемость ICMP

RFC 792 определяет следующие типы сообщений ICMPv4:

Destination Unreachable — адресат недоступен;
Time Exceeded — время жизни истекло;
Parameter Problem — проблема с параметрами;
Source Quench — слишком большая скорость передачи;
Redirect — перенаправление;
Echo Request/Reply — запрос/отклик эхо;
Timestamp/Timestamp Reply — временная метка и отклик с временной сеткой;
Information Request/Information Reply — информационный запрос/отклик.

[RFC1191] резервирует биты для поля Next-Hop MTU в сообщениях Destination Unreachable.

RFC 4443 определяет следующие типы сообщений ICMPv6:

Destination Unreachable — адресат недоступен;
Packet Too Big — слишком большой пакет;
Time Exceeded — время жизни истекло;
Parameter Problem — проблема с параметрами;
Echo Request/Reply — запрос/отклик эхо.

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

Однако ряд сообщений ICMP в соответствии с текущими определениями не поддерживает расширений:

ICMPv4 Destination Unreachable (type = 3);
ICMPv4 Time Exceeded (type = 11);
ICMPv4 Parameter Problem (type = 12);
ICMPv6 Destination Unreachable (type = 1);
ICMPv6 Packet Too Big (type = 2);
ICMPv6 Time Exceeded (type = 3);
ICMPv6 Parameter Problem (type = 4).

Эти сообщения содержат поле «исходной дейтаграммы», которое включает начальные октеты дейтаграммы, вызвавшей сообщение ICMP. RFC 792 определяет поле «исходной дейтаграммы» для сообщений ICMPv4. В RFC 792 поле «исходной дейтаграммы» включает заголовок IP и следующие за ним 8 октетов исходной дейтаграммы. [RFC1812] расширяет поле «исходной дейтаграммы», позволяя включать в него любое число октетов при условии, что размер сообщения ICMP не будет превышать минимальный размер буфера сборки IPv4 (т. е., 576 октета). RFC 4443 определяет поле «исходной дейтаграммы» для сообщений ICMPv6. В RFC 4443 поле «исходной дейтаграммы» всегда содержит столько октетов, сколько можно включить без превышения сообщением ICMP минимального размера IPv6 MTU (т. е., 1280 октетов).

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

Для решения этой проблемы в настоящем документе вводится 8-битовый атрибут размера для следующих сообщений ICMPv4:

Destination Unreachable (type = 3);
Time Exceeded (type = 11);
Parameter Problem (type = 12).

Такой же 8-битовый атрибут размера добавляется в сообщения ICMPv6:

Destination Unreachable (type = 1);
Time Exceeded (type = 3).

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

Атрибут размера показывает размер поля «исходной дейтаграммы». Пространство для атрибута размера берется из резервных октетов, которые раньше были определены с нулевым значением.

Для сообщения ICMPv4 атрибут размера показывает число 32-битовых слов. При наличии атрибута размера поле «исходной дейтаграммы» должно дополняться нулями для выравнивания по ближайшей 32-битовой границе. Поскольку в каждом из затрагиваемых изменениями типов сообщений ICMPv4 был зарезервирован шестой октет, этот октет был выбран для размещения атрибута размера в сообщениях ICMPv4.

Для сообщения ICMPv6 атрибут размера показывает количество 64-битовых слов. При наличии атрибута размера поле «исходной дейтаграммы» должно дополняться нулями для выравнивания по ближайшей 64-битовой границе. Поскольку в каждом из затрагиваемых типов сообщений ICMPv6 шестой октет был резервным, этот октет был выбран для размещения атрибута размера в ICMPv6.

Для обеспечения совместимости с более ранними версиями при добавлении в конец сообщения ICMP Extension Structure и наличии поля «исходной дейтаграммы» последнее должно содержать не менее 128 октетов. Если в исходной дейтаграмме менее 128, поле «исходной дейтаграммы» должно дополняться нулями до 128 октетов (обоснование этого приведено в параграфе 5.1).

В следующих параграфах описан атрибут размера в сообщениях ICMP.

4.1. ICMPv4 Destination Unreachable

Рисунок 1 показывает формат сообщения ICMPv4 Destination Unreachable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|не используется|    Length     |         Next-Hop MTU*         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. ICMPv4 Destination Unreachable

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 792, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 32-битовых словах.

Поле Next-Hop MTU требуется не во всех случаях. Оно показано лишь в качестве демонстрации того, что эти биты заняты для данного типа сообщений и их невозможно выделить для целей настоящего документа.

4.2. ICMPv4 Time Exceeded

Рисунок 2 показывает формат сообщения ICMPv4 Time Exceeded.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|не используется|    Length     |        не используется        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. ICMPv4 Time Exceeded

4.3. ICMPv4 Parameter Problem

Рисунок 3 показывает формат сообщения ICMPv4 Parameter Problem.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Pointer    |    Length     |        не используется        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. ICMPv4 Parameter Problem

4.4. ICMPv6 Destination Unreachable

Рисунок 4 показывает формат сообщения ICMPv6 Destination Unreachable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Length     |                не используется                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Максимально возможное число октетов               |
+           вызвавшего сообщение ICMPv6 пакета, без             +
|          превышения минимального IPv6 MTU [RFC4443]           |

Рисунок 4. ICMPv6 Destination Unreachable

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 4443, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 64-битовых словах.

4.5. ICMPv6 Time Exceeded

Рисунок 5 показывает формат сообщения ICMPv6 Time Exceeded.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Length     |                не используется                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Максимально возможное число октетов               |
+           вызвавшего сообщение ICMPv6 пакета, без             +
|          превышения минимального IPv6 MTU [RFC4443]           |

Рисунок 5. ICMPv6 Time Exceeded

4.6. Сообщения ICMP, которые могут быть расширены

Структура расширения ICMP может добавляться в конец сообщений следующих типов:

ICMPv4 Destination Unreachable;
ICMPv4 Time Exceeded;
ICMPv4 Parameter Problem;
ICMPv6 Destination Unreachable;
ICMPv6 Time Exceeded.

ICMP Extension Structure недопустимо добавлять в прочие сообщения ICMP, упомянутые в разделе 4. Расширения не были определены для сообщений ICMPv6 Packet Too Big и Parameter Problem по причине отсутствия в этих типах сообщения пространства для размещения атрибута размера.

5. Совместимость с предыдущими версиями

Сообщения ICMP можно разделить на несколько категорий:

сообщения без расширений ICMP;
сообщения с несовместимыми с данной спецификацией расширениями ICMP;
сообщения с совместимыми расширениями ICMP.

Все реализации ICMP могут передавать сообщения без расширений. Реализации ICMP до 1999 г. просто не знают о расширениях ICMP.

Некоторые реализации ICMP, выпущенные между 1999 г. и публикацией этого документа могут передавать не соответствующие этой спецификации варианты расширений ICMP. В частности, такие реализации могут добавлять структуру расширения ICMP в конец сообщений Time Exceeded и Destination Unreachable. В таких случаях реализации передают ровно 128 октетов, представляющих исходную дейтаграмму, дополняя ее, при необходимости, нулями. Расчет контрольной суммы такие реализации выполняют в соответствии с приведенным здесь описанием. Однако они не задают атрибут размера для поля «исходной дейтаграммы».

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

Приложения, принимающие сообщения ICMP также можно разделить по категориям:

классические приложения;
несовместимые приложения;
совместимые приложения.

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

Несовместимые реализации разбирают определенные здесь расширения, но только для сообщений Time Expired и Destination Unreachable. Они требуют, чтобы поле «исходной дейтаграммы» имело размер 128 октетов и не понимают атрибута размера, связанного с этим полем. Несовместимые реализации выпускались с 1999 г. до момента публикации этого документа.

Совместимые реализаци полностью соответствуют данной спецификации.

Таблица 1.

	Нет расширений	Несовместимые расширения	Совместимые расширения
Классические приложения	—	Параграф 5.1	Параграф 5.1
Несовместимые приложения	Параграф 5.2	—	Параграф 5.3
Совместимые приложения	Параграф 5.4	Параграф 5.5	—

Таблица 1 показывает, как приложения каждой категории будут относится к разборке сообщений ICMP всех категорий.

Прочерк в ячейке таблицы говорит о нормальной ситуации, которая не требует разъяснений. В последующих параграфах предполагается, что сообщения ICMP относятся к типу Time Exceeded.

5.1. Классическое приложение получает сообщение ICMP с расширениями

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

Некоторые варианты стека TCP при получении сообщения ICMP проверяют контрольную сумму поля «исходной дейтаграммы» [ATTACKS]. Если эта сумма некорректна, стек TCP отбрасывает сообщение ICMP по соображениям безопасности. Если завершающие октеты поля «исходной дейтаграммы» переписаны расширением ICMP, такой стек TCP будет отбрасывать сообщения ICMP, которые не были бы отброшены в обычных условиях. Негативное влияние такого отбрасывания считается минимальным, поскольку множество сообщений ICMP отбрасывается по другим причинам (например, фильтрация ICMP, перегрузка в сети, некорректная контрольная сумма в результате «усекновения» исходной дейтаграммы).

Другой, теоретически возможный, но весьма маловероятный случай возникает, когда расширения ICMP переписывают часть поля «исходной дейтаграммы», которая представляет заголовок TCP, что приводит стек TCP к работе с некорректным соединением TCP. Такие случаи маловероятны, поскольку для их возникновения нужно, чтобы заголовок TCP выходил за пределы первых 128 октетов поля «исходной дейтаграммы», а расширение напоминало бы корректный заголовок TCP.

5.2. Несовместимое приложение получает сообщение ICMP без расширений

Когда несовместимое приложение ICMPv4 получает сообщение без расширений, оно проверяет общий размер сообщения ICMPv4. Если этот размер меньше размера заголовка IP в сообщении + 144 октета, приложение корректно определяет отсутствие расширений.

Значение 144 включает 8 октетов двух первых слов сообщения ICMPv4 Time Exceeded, 128 октетов поля «исходной дейтаграммы», 4 октета заголовка расширения ICMP и 4 октета одного заголовка объекта ICMP. Все перечисленные октеты требуются при использовании расширений.

Если данные ICMPv4 включают не менее 144 октетов, приложение должно проверить октет 137 для определения наличия корректного заголовка ICMPv4 Extension. Корректный заголовок расширения должен содержать корректный номер версии и контрольную сумму. Если это не выполняется, приложение корректно считает, что в сообщении не содержится расширений.

Несовместимые приложения предполагают, что структура расширения ICMPv4 начинается с октета 137 сообщения Time Exceeded после поля «исходной дейтаграммы» размером 128 октетов.

В перечисленных ниже случаях возможен некорректный анализ несовместимым приложением сообщения ICMPv4:

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

Такие случаи возможны, но маловероятны.

Аналогичный анализ можно провести для ICMPv6 с соответствующим изменением числовых констант.

5.3. Несовместимое приложение получает сообщение ICMP с совместимым расширением

Когда несовместимое приложение получает сообщение с совместимым расширением ICMP, оно сможет корректно разобрать такое сообщение лишь в тех случаях, когда размер поля «исходной дейтаграммы» в точности равен 128 октетам. Это обусловлено тем, что несовместимые приложения не понимают атрибута размера поля «исходной дейтаграммы» (они предполагают этот размер равным 128 октетам).

За исключением ограничения на размер сообщения ICMP в целом (не более размера минимального буфера сборки — 576 октетов для ICMPv4 и 1280 октетов для ICMPv6), не вводится ограничений на размер поля «исходной дейтаграммы». Однако каждая реализация сама решает, сколько октетов исходной дейтаграммы следует включать в сообщение. Для обеспечения совместимости с несовместимыми с данной спецификацией реализациями TRACEROUTE включается в точности 128 октетов исходной дейтаграммы. Если такая совместимость не требуется, можно включать большее число октетов исходной дейтаграммы.

5.4. Совместимое приложение получает сообщение ICMP без расширений

5.5. Совместимое приложение получает сообщение ICMP с несовместимым расширением

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

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

6. Взаимодействие с трансляцией адресов

Расширения ICMP, определенные в этом документе, не конфликтуют с системами трансляции адресов (NAT²). [RFC3022] разрешает традиционным устройствам NAT изменять отдельные поля сообщений ICMP. К числу таких полей относится и упоминаемое здесь поле «исходной дейтаграммы». Однако, если устройство NAT меняет поле «исходной дейтаграммы», изменять следует только начальные поля этого поля, представляющие внешний заголовок IP. Поскольку внешний заголовок IP гарантированно располагается в первых 128 октетах поля «исходной дейтаграммы», расширения ICMP и NAT не нарушают работу друг друга.

Понятно, что реализация NAT может пренебречь ограничениями RFC 3022 и переписать определенное в этом документе поле атрибута размера. Если реализация NAT будет заполнять это поле нулями, полученный в результате пакет будет неотличим от пакетов, генерируемых несовместимыми реализациями ICMP. Вопросы совместимости для таких случаев рассмотрены в параграфе 5.5.

7. Структура расширения ICMP

В этом документе предлагается опциональная структура расширения (ICMP Extension Structure), которая может добавляться в конец сообщений ICMP, перечисленных в параграфе 4.6 этого документа.

Extension Structure содержит один заголовок расширения (Extension Header), за которым следует один или несколько объектов. Получив сообщение ICMP с расширениями, прикладная программа может обработать часть объектов, игнорируя остальные. Наличие в сообщении нераспознанных объектов не является показателем некорректного формата сообщения ICMP.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|      (Reserved)       |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Заголовок расширения ICMP

Как сказано выше, общий размер сообщения ICMP, включая расширения, не должен превышать минимальный размер буфера сборки. Рисунок 6 показывает формат ICMP Extension Header.

Заголовок расширения ICMP имеет следующие поля:

Version — версия (4 бита)

Номер версии расширения ICMP. Данный документ задает версию 2.

Reserved — резерв (12 битов)

Резервное поле, которое должно иметь нулевое значение.

Checksum — контрольная сумма (16 битов)

Дополнение до 1 суммы дополнений до 1 октетов структуры данных. При расчете контрольной суммы значение поля предполагается нулевым. Равное нулю поле контрольной суммы говорит об отсутствии последней. Использование поля контрольной суммы в заголовке расширения описано в параграфе 5.2.

8. Объекты расширения ICMP

Каждый объект расширения содержит по крайней мере одно 32-битовое слово, представляющее заголовок и и данные объекта расширения. Все заголовки объектов используют общий формат. Рисунок 7 показывает формат заголовка и данных объекта.

  0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |   Class-Num   |   C-Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   // (данные объекта) //                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Заголовок и данные объекта расширения

Заголовок объекта включает следующие поля:

Length — размер (16 битов)

Размер объекта в октетах с учетом заголовка и данных.

Class-Num (8 битов)

Идентификатор класса объекта.

C-Type (8 битов)

Идентификатор субтипа объекта.

9. Вопросы безопасности

При получении сообщения ICMP прикладная программа должна проверить его синтаксическую корректность. Должна проверяться также контрольная сумма расширения. Некорректно заданные атрибуты размера и другие синтаксические проблемы могут приводить к переполнению буфера.

В этом документе не задаются условия, при которых маршрутизаторы передают сообщения ICMP. Следовательно, не возникает возможностей для организации новых атак на службы (DoS³). Маршрутизаторы могут ограничивать скорость передачи сообщения ICMP.

10. Согласование с IANA

Заголовок ICMP Extension Object содержит два 8-битовых поля — Class-Num идентифицирует класс объекта, а C-Type — субтип класса. Значения субтипов определяются для каждого класса объектов.

Агенство IANA организовало и поддерживает реестр классов объектов расширения ICMP и субтипов для этих классов. В настоящем документе не задается каких-либо значений для этих реестров. Классы объектов 0xF7 — 0xFF резервируются для частных применений. Значения идентификаторов класса выделяются в порядке поступления заявок (first-come-first-serve). Правила выделения значений субтипов должны задаваться в документах, определяющих класс.

11. Благодарности

Спасибо Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt и Sharon за их комментарии к документу.

12. Литература

12.1. Нормативные документы

[RFC0792] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, September 1981.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1812] Baker, F., «Requirements for IP Version 4 Routers», RFC 1812, June 1995.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006.

12.2. Дополнительная литература

[UNNUMBERED] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E. Chen, «ICMP Extensions for Unnumbered Interfaces», Work in Progress, March 2007.

[MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, «ICMP Extensions for MultiProtocol Label Switching», Work in Progress⁵, January 2007.

[ATTACKS] Gont, F., «ICMP attacks against TCP», Work in Progress, October 2006.

[ROUTING-INST] Shen, N. and E. Chen, «ICMP Extensions for Routing Instances», Work in Progress, November 2006.

[RFC3022] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, January 2001.

Адреса авторов

Ronald P. Bonica

Juniper Networks

2251 Corporate Park Drive

Herndon, VA 20171

EMail: rbonica@juniper.net

Der-Hwa Gan

Consultant

EMail: derhwagan@yahoo.com

Daniel C. Tappan

Consultant

EMail: Dan.Tappan@gmail.com

Carlos Pignataro

Cisco Systems, Inc.

7025 Kit Creek Road

Research Triangle Park, NC 27709

EMail: cpignata@cisco.com

Перевод на русский язык

Николай Малых

Полное заявление автоских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Далее для удобства будет называть такие сообщения многокомпонентными. Прим. перев.

2Network Address Translation.

3Denial-of-service attack – атака на отказ служб.

5Работа завершена и опубликована в RFC 4950. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Опубликовано 08.04.2007 автором Nikolai Malykh

Network Working Group                                      V. Manral
Request for Comments: 4835                          IP Infusion Inc.
Obsoletes: 4305                                           April 2007
Category: Standards Track

Требования к реализациям криптографических алгоритмов для ESP и AH

Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа Internet Official Protocol Standards (STD 1). Допускается свободное распространение документа.

Авторские права

Аннотация

Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения услуг защиты. Протоколы ESP¹ и AH²) обеспечивают два механизма защиты данных, передаваемых через IPsec SA³. Для обеспечения совместимости требуется задать набор обязательных для реализации алгоритмов, чтобы гарантировать поддержку всеми реализациями хотя одного алгоритма. В этом документе определяется набор обязательных для реализации в протоколах ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут быть отнесены в будущем к числу обязательных.

1. Введение

Протоколы ESP и AH обеспечивают два механизма для защиты данных, передаваемых через IPsec SA [RFC4301], [RFC4302]. Для обеспечения совместимости требуется задать набор обязательных для реализации алгоритмов, чтобы гарантировать поддержку всеми реализациями хотя одного алгоритма. В этом документе определяется набор обязательных для реализации в протоколах ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут быть отнесены в будущем к числу обязательных.

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

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

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

2. Уровни требований

Кроме того, здесь определено несколько дополнительных уровней.

SHOULD+

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

SHOULD-

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

MUST-

Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным.

3. Выбор алгоритма

Для обеспечения совместимости реализаций IPsec требуется поддержка по крайней мере одного общего алгоритма защиты. В этом разделе приведены требования по реализации алгоритмов защиты для соответствующих спецификации реализаций протоколов ESP и AH. Алгоритмы защиты, реально используемые любой конкретной защищенной связью ESP или AH, определяются механизмом согласования (таким, как IKE⁴ [RFC2409], [RFC4306]) или задаются при организации соединения.

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

3.1. Протокол ESP

Требования в поддержке алгоритмов защиты для соответствующих спецификации реализаций протокола ESP приведены ниже. Определения уровней требований (колонка Требования) содержатся в разделе 2.

3.1.1. Алгоритмы шифрования и аутентификации для ESP

В приведенных ниже таблицах указаны требования к алгоритмам шифрования и аутентификации для протокола IPsec ESP.

Требования	Алгоритм шифрования
MUST — обязательно	NULL [RFC2410]⁵
MUST — обязательно	AES-CBC со 128-битовыми ключами [RFC3602]
MUST- — обязательно , но может утратить статус	TripleDES-CBC [RFC2451]
SHOULD — следует	AES-CTR [RFC3686]
SHOULD NOT — не следует	DES-CBC [RFC2405]⁶

Требования	Алгоритм аутентификации
MUST — обязательно	HMAC-SHA1-96 [RFC2404]⁷
SHOULD+ — следует, но может стать обязательным	AES-XCBC-MAC-96 [RFC3566]
MAY — возможно	NULL²
MAY — возможно	HMAC-MD5-96 [RFC2403]⁸

3.1.2. Комбинированные алгоритмы для ESP

Как указано в [RFC4303], протокол поддерживает использование комбинированных алгоритмов, которые обеспечивают услуги конфиденциальности и аутентификации. Поддержка таких алгоритмов требует соответствующего структурирования реализации ESP. Во многих ситуациях комбинированные алгоритмы обеспечивают значительные преимущества в части эффективности и пропускной способности. Хотя в настоящее время не указывается предлагаемых или обязательных к реализации комбинированных алгоритмов, предполагается, что в ближайшем будущем представят интерес алгоритмы AES-CCM [RFC4309] и AES-GCM [RFC4106]. Алгоритм AES-CCM принят в качестве предпочтительного для IEEE 802.11 [802.11i], а AES- GCM — для IEEE 802.1ae [802.1ae].

3.2. Протокол AH

Ниже приведены требования к реализации алгоритмов защиты в соответствующих спецификации реализациях протокола AH. Определения уровней требований (колонка Требования) приведены в разделе 2. Как вы понимаете, все перечисленные алгоритмы относятся к числу алгоритмов аутентификации.

Требования	Алгоритм аутентификации
MUST — обязательно	HMAC-SHA1-96 [RFC2404]⁹
SHOULD+ — следует, но может стать обязательным	AES-XCBC-MAC-96 [RFC3566]
MAY — возможно	HMAC-MD5-96 [RFC2403]¹⁰

4. Вопросы безопасности

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

Этот документ посвящен выбору криптографических алгоритмов для использования с протоколами ESP и AH и, в частности, обязательных для реализации алгоритмов. Алгоритмы, которые в соответствии с этой спецификацией требуется (MUST) или следует (SHOULD) реализовать, не имеют в данный момент известных фактов взлома и выполненные криптографические исследования позволяют надеяться, что эти алгоритмы останутся безопасными в обозримом будущем. Однако, такое положение дел не обязательно сохранится. Мы, следовательно, предполагаем появление новых версий этого документа, отражающих накопленный в сфере защиты опыт.

5. Благодарности

Значительная часть этого документа перенесена из RFC 4305, являющегося предшественником данного документа. Сам RFC 4305 заимствует часть текста из документа Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 [RFC4307], подготовленного Jeffrey I. Schiller.

Спасибо перечисленным здесь людям, которые указали ошибки в RFC 4305 или ответили на сообщения об их обнаружении: Paul Hoffman, Stephen Kent, Paul Koning и Lars Volker. Полезные комментарии были получены от Russ Housley, Elwyn Davies, Nicolas Williams и Alfred Hoenes.

6. Отличия RFC 2402 и RFC 2406 от RFC 4305

[RFC2402] и [RFC2406] определяли протоколы IPsec AH и IPsec ESP. Каждый из этих документов содержал требования к криптографическим алгоритмам для соответствующего протокола. В настоящее время эти спецификации заменены документами [RFC4302] и [RFC4303], которые не содержат требований к реализации криптографических алгоритмов. В данном документе указаны такие требования для обоих протоколов — [RFC4302] и [RFC4303].

Сравнение требований приведено ниже.

Старое требование	Старый RFC	Новое требование	Алгоритм
MUST — требуется	2406	SHOULD NOT — не следует	DES-CBC [RFC2405]¹¹
MUST — требуется	2402, 2406	MAY — возможно	HMAC-MD5-96 [RFC2403]
MUST — требуется	2402, 2406	MUST — требуется	HMAC-SHA1-96 [RFC2404]

7. Отличия от RFC 4305

Этот документ является заменой [RFC4305]. Документ меняет требование по поддержке алгоритма аутентификации NULL с MUST (требуется) на MAY (возможно). Это изменение внесено для обеспечения согласованности с [RFC4301]. Добавлен текст об атаках с использованием конфликтов SHA-1, а также отмечены, как предполагаемые для использования в будущем, алгоритмы AES-GCM и AES-CCM.

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

Старое требование	Старый RFC	Новое требование	Алгоритм
MUST — требуется	2406	MAY — возможно	Аутентификация NULL
MUST — требуется	2406	MUST — требуется	Шифрование NULL
SHOULD+ — следует с возможностью перехода в должно	4305	MUST — требуется	Шифрование AES-CBC

8. Литература

8.1. Нормативные документы

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP14, RFC2119, March 1997.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[RFC2405] Madson, C. and N. Doraswamy, «The ESP DES-CBC Cipher Algorithm With Explicit IV», RFC 2405, November 1998.

[RFC2410] Glenn, R. and S. Kent, «The NULL Encryption Algorithm and Its Use With IPsec», RFC 2410, November 1998.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC3566] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[RFC3686] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4305] Eastlake, D., «Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 4305, December 2005.

8.2. Дополнительная литература

[802.11i] «LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications», IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.11i, June 2004.

[802.1ae] «Media Access Control (MAC) Security», IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.1ae, June 2006.

[DES-WDRAW] «Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments», FIPS Notice Docket No. 040602169-4169-01, July 2004.

[MD5-COLL] Klima, V., «Finding MD5 Collisions — a Toy For a Notebook», Cryptology ePrint Archive Medium Report 2005/075, March 2005.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[RFC4106] Viega, J. and D. McGrew, «The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)», RFC 4106, June 2005.

[RFC4306] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC4307] Schiller, J., «Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)», RFC 4307, December 2005.

[RFC4309] Housley, R., «Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)», RFC 4309, December 2005.

[SHA1-COLL] Rijmen, V. and E. Oswald, «Update on SHA-1», Cryptology ePrint Archive Report 2005/010, January 2005.

Адрес автора

Vishwas Manral

IP Infusion Inc.

Bamankhola, Bansgali,

Almora, Uttarakhand 263601

India

Phone: +91-98456-61911

EMail: vishwas@ipinfusion.com

Перевод на русский язык

Николай Малых

Полное заявление авторских прав

Интеллектуальная собственность

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).

1Encapsulating Security Payload — инкапсуляция защищенных данных.

2Authentication Header — заголовок аутентификации.

3Security Association — защищенная связь.

4Internet Key Exchange — обмен ключами в Internet.

5Поскольку шифрование в ESP является необязательными, поддержка алгоритма NULL требуется для обеспечения совместимости со способом согласования услуг. Отметим, что, несмотря на возможность использования алгоритма NULL и для аутентификации, недопустимо использование NULL для обоих алгоритмов сразу [RFC4301].

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

7В алгоритме SHA-1 проявились слабые стороны [SHA1-COLL], однако это не должно влиять на использование SHA1 с HMAC.

8В алгоритме MD5 проявились слабые стороны [MD5-COLL], однако это не должно влиять на использование MD5 с HMAC.

9В алгоритме SHA-1 проявились слабые стороны [SHA1-COLL], однако это не должно влиять на использование SHA1 с HMAC.

10В алгоритме MD5 проявились слабые стороны [MD5-COLL], однако это не должно влиять на использование MD5 с HMAC.

11IETF запрещает самостоятельное использование DES уже много лет и не включает этот алгоритм в новые стандарты в течение достаточного времени (см. комментарий IESG на первой странице [RFC2407]). [RFC4305] является первым проектом стандарта, в котором указано, что реализациям не следует использовать алгоритм DES самостоятельно (не в комбинации с другими, прим. перев.). Институт стандартов и технологий США (NIST) формально признал слабость DES при самостоятельном использовании в документе [DES-WDRAW], призывая прекратить использование этого алгоритма в качестве Государственного стандарта США. Алгоритм Triple DES по прежнему признается как IETF, так и NIST.

13Этот документ признан устаревшим и заменен RFC 5996, а затем RFC 7296. Прим. перев.

Рубрика: RFC | Оставить комментарий

RFC 4821 Packetization Layer Path MTU Discovery

Опубликовано 18.03.2007 автором Nikolai Malykh

Network Working Group                                          M. Mathis
Request for Comments: 4821                                    J. Heffner
Category: Standards Track                                            PSC
                                                              March 2007

Определение Path MTU на уровне пакетизации

Packetization Layer Path MTU Discovery

Статус документа

Авторские права

Аннотация

Этот документ описывает отказоустойчивый метод определения MTU для пути (PMTUD¹), который основывается на TCP или каком-либо ином уровне пакетизации (Packetization Layer) для зондирования пути через Internet с помощью прогрессивно увеличивающихся в размере пакетов. Метод описывается, как расширение RFC 1191 и RFC 1981, в которых определен основанный на ICMP метод определения Path MTU для протокола IP версий 4 и 6, соответственно.

1. Введение

Этот документ описывает метод PLPMTUD², являющийся расширением методов определения Path MTU, описанных в [RFC1191] и [RFC1981]. В отсутствие сообщений ICMP корректное определение MTU начинается с передачи мелких пакетов и последующих попыток увеличения их размера. Основная часть алгоритма реализована над уровнем IP, в транспортном уровне (например, TCP) или другом «протоколе пакетизации», отвечающем за определение границ пакетов.

Этот документ не является обновлением RFC 1191 и RFC 1981, однако он позволяет корректно определять MTU без ICMP, что неявно ослабляет некоторые требования к алгоритмам, заданным этими документами.

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

Для большей ясности при описании отдается предпочтение терминологии TCP и IPv6. В разделе, посвященном терминам, представлены аналогичные термины IPv4 и концепции для терминов IPv6. В некоторых ситуациях конкретные детали описаны раздельно для IPv4 и IPv6.

Документ является результатом работы группы Path MTU Discovery (PMTUD) под эгидой IETF и в значительной мере является наследником RFC 1191 и RFC 1981 в части терминологии, идей и отдельных фрагментов текста.

2. Обзор

PLPMTUD представляет собой метод динамического определения MTU для пути в TCP или других протоколах пакетизации путем зондирования с помощью постепенно увеличивающихся пакетов. Наибольшая эффективность метода обеспечивается при использования вместе с механизмом Path MTU Discovery на основе ICMP, описанным в RFC 1191 и RFC 1981, но этот метод решает множество проблем отказоустойчивости, поскольку он не зависит от доставки сообщений ICMP.

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

Общей стратегией для уровня пакетизации является определение подходящего значения Path MTU путем зондирования пути постепенно увеличивающимися в размере пакетами. Если пробный пакет доставляется получателю, эффективное значение Path MTU увеличивается до размера пробного пакета.

Потеря отдельного пробного пакета (с получением ICMP Packet Too Big или без него) трактуется, как предел MTU, а не индикатор перегрузки. Только в этом случае протоколу пакетизации разрешается повторно передать пропущенные данные без изменения размера окна насыщения.

При возникновении тайм-аута или потери дополнительных пакетов в процессе зондирования, проба считается неубедительной (например, потеря пробного пакета не обязательно говорит о превышении Path MTU). Кроме того, потери трактуются подобно другим индикаторам перегрузки — изменение окна или скорости является обязательным в соответствующих стандартах контроля насыщения [RFC2914]. Зондирование может быть возобновлено после задержки, определяемой природой обнаруженного сбоя.

PLPMTUD использует метод поиска для определения Path MTU. Каждый последующий пробный пакет сужает диапазон поиска MTU путем повышения нижнего порога при успешном зондировании или снижения верхнего порога при неудаче, постепенно приходя к верному значению Path MTU. Для большинства транспортных уровней поиск следует останавливать после того, как диапазон поиска будет достаточно сужен, чтобы преимущества от повышения эффективного значения Path MTU еще превышали издержки, связанные с дальнейшим поиском.

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

Можно использовать дополнительную проверку для обнаружения ситуаций, когда повышение MTU увеличивает скорость потери пакетов. Например, если канал организован через множество физических соединений с несогласованными значениями MTU, возможны ситуации, когда пробные пакеты будут доставляться даже в в случае превышения максимального размера пакетов на отдельных физических линиях. В таких случаях увеличение Path MTU до размера пробного пакета будет повышать частоту потери пакетов и значительной потере производительности. После увеличения MTU новый размер можно проверить, наблюдая частоту потерь.

Механизм PLPMTUD обеспечивает дополнительную гибкость реализациям классического метода Path MTU Discovery. Его можно настроить только на восстановление «черных дыр» ICMP с целью повышения отказоустойчивости Path MTU Discovery или, в качестве другой крайности, полностью отменить обработку ICMP и применять PLPMTUD взамен Path MTU Discovery.

Классический механизм Path MTU Discovery подвержен протокольным отказам («зависание» соединений), если сообщения ICMP Packet Too Big (PTB) не доставляются или не обрабатываются по той или иной причине [RFC2923]. С помощью PLPMTUD классический механизм Path MTU Discovery можно изменить путем включения дополнительной проверки согласованности без повышения риска повисания соединений в результате паразитного отказа при дополнительных проверках. Такие изменения классического Path MTU Discovery выходят за рамки этого документа.

В предельном случае все сообщения ICMP PTB могут безусловно игнорироваться, а PLPMTUD может использоваться в качестве единственного метода определения Path MTU. В такой конфигурации PLPMTUD работает параллельно с контролем перегрузок. Сквозной транспортный протокол подстраивает свойства потока данных (размер окна или пакетов), а потеря пакетов используется для определения приемлемости корректировки. Этот метод представляется более согласованным со «сквозным принципом» Internet, нежели использование сообщений ICMP, содержащих переписанные заголовки протоколов разных уровней.

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

Большая часть описанных здесь деталей реализации представляет собой рекомендации, основанные на опыте использования более ранних версий Path MTU Discovery. Эти рекомендации обусловлены желанием максимально повысить отказоустойчивость PLPMTUD в неидеальных условиях сетей.

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

В разделе 3 представлен глоссарий используемых терминов.

В разделе 4 описаны детали PLPMTUD, оказывающие влияние на взаимодействие с другими стандартами и протоколами Internet.

В разделе 5 рассмотрено деление PLPMTUD на уровни и управление кэшем информации о путях на уровне IP.

В разделе 6 описаны общие свойства уровня пакетизации (Packetization Layer) и требуемые для PLPMTUD свойства.

В разделе 7 описано применение пробных пакетов для определения Path MTU.

Раздел 8 рекомендует использовать фрагментацию IPv4 в конфигурации, имитирующей функциональность IPv6, для минимизации будущих проблем при переходе на IPv6.

В разделе 9 описан программный интерфейс для реализации PLPMTUD в приложениях, которые самостоятельно определяют границы пакетов, а также средствах диагностики проблем, которые могут конфликтовать с Path MTU Discovery.

В разделе 10 рассмотрены детали реализации для конкретных протоколов, включая TCP.

3. Терминология

Ниже приведены определения используемых в документе терминов.

IPv4 [RFC0791] или IPv6 [RFC2460].

Node — узел

Устройство, реализующее IP.

Upper layer — вышележащий уровень

Протокольный уровень, расположенный непосредственно над IP. Примерами являются транспортные протоколы типа TCP и UDP, протоколы управления типа ICMP, протоколы маршрутизации типа OSPF, а также IP или протоколы нижележащего уровня, «туннелируемые» (инкапсулированные) в IP, типа IPX, AppleTalk или самого IP.

Link — канал

Коммуникационное устройство или среда, через которую узлы могут взаимодействовать на канальном уровне (т. е., уровне, расположенном непосредственно под IP). Примерами могут служить Ethernet (плоская сеть или сеть с мостами), каналы PPP, сети X.25, Frame Relay или ATM³, а также IP (и вышележащие) и другие «туннелируемые» протоколы типа туннелей через IPv4 или IPv6. Иногда для обозначения всего перечисленного используется более общий термин «нижележащий уровень» (lower layer).

Interface — интерфейс

Точка присоединения узла к каналу.

Address — адрес

Идентификатор уровня IP для интерфейса или группы интерфейсов.

Packet — пакет

Заголовок IP в комбинации с данными (payload).

MTU — максимальный передаваемый блок

Размер (в байтах) наибольшего пакета IP (заголовок и данные), который может быть передан по каналу или пути. Отметим, что более корректно было бы говорить IP MTU, поскольку аббревиатуру MTU уже используют в других стандартах.

Link MTU — MTU для канала

Размер (в байтах) наибольшего пакета IP, который может быть целиком (без деления на части) передан через канал. Следует отметить, что это определение отличается от определений, используемых другим органами стандартизации.

MTU для канала в документах IETF определяется, как IP MTU для этого канала. Размер учитывает заголовок IP, но не включает заголовки канального уровня и другое кадрирование, которое не является частью IP или данными IP.

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

Path — путь

Множество каналов, через которые пакет проходит от отправителя до получателя.

Path MTU, PMTU — MTU для пути

Минимальное значение link MTU среди всех каналов на пути между отправителем и получателем.

Classical Path MTU Discovery — классический метод определения MTU для пути

Процесс, описанный в RFC 1191 и RFC 1981, для определения MTU на пути с помощью сообщений ICMP PTB⁴.

Packetization Layer — уровень пакетизации

Уровень стека сетевых протоколов, на котором данные сегментируются в пакеты.

Effective PMTU — эффективное значение MTU для пути

Текущее значение PMTU, используемое уровнем пакетизации для сегментирования.

PLPMTUD

Определение MTU для пути на уровне пакетизации (Packetization Layer Path MTU Discovery) — метод, описанный в этом документе и являющийся расширением классического механизма PMTU Discovery.

PTB (Packet Too Big) message — сообщение PTB

Сообщение ICMP, указывающее, что пакет IP слишком велик для пересылки. Это термин IPv6, соответствующий сообщению IPv4 ICMP «Fragmentation Needed and DF Set».

Flow – поток

Контекст, в котором могут вызываться алгоритмы MTU Discovery. Это, естественно, экземпляр протокола пакетизации, например, одна сторона соединения TCP.

MSS

Максимальный размер сегмента TCP⁵ [RFC0793] — максимальный размер блока данных, доступный для уровня TCP. Обычно это Path MTU за вычетом размера заголовков IP и TCP.

Probe packet — пробный пакет, зонд

Пакет, который будет применяться для тестирования пути на предмет большего MTU.

Probe size — размер зонда

Размер пакета, который будет использоваться для тестирования пути с целью определения MTU (включая заголовок IP).

Probe gap — пропуск пробных пакетов

Данные, которые были потеряны и должны быть переданы повторно, если пробный пакет не доставлен.

Leading window — ведущее окно

Любые неподтвержденные данные в потоке на момент передачи пробного пакета.

Trailing window — трейлерное (ведомое) окно

Любые данные в потоке после передачи пробного пакета, но до подтверждения его получения.

Search strategy — стратегия поиска

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

Full-stop timeout — тайм-аут полной остановки

Тайм-аут, когда ни один из переданных после некого события пакетов (включая повторы), не подтвержден получателем. Это принимается в качестве индикации того или иного отказа в сети (например изменение маршрутизации с переходом на канал с меньшим MTU). Более подробное описание приведено в параграфе 7.7.

4. Требования

Для всех каналов должно обеспечиваться соответствие своим MTU — при недетерминированном получении каналом пакета с размером больше установленного для канала MTU такие пакеты должны отбрасываться.

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

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

Приведенные ниже требования относятся только к реализациям, включающим PLPMTUD.

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

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

Подавление контроля перегрузок должно быть ограничено по частоте так, чтобы оно происходило реже чем худшие случаи потери пакетов для контроля перегрузок TCP при сравнимой скорости передачи данных по тому же пути (т. е., меньше, чем частота потерь TCP-friendly [tcp-friendly]). Это следует исполнять посредством требования минимального продвижения между корректировкой подавленного контроля перегрузок (по причине отказа пробы) и следующей попыткой зондирования, которое равно одному периоду кругового обхода для каждого пакета, разрешенного окном контроля насыщения. Этот вопрос дополнительно рассмотрен в параграфе 7.6.2.

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

При снижении MTU (например, после обработки сообщений ICMP PTB) переменные состояния для насыщения следует масштабировать заново, чтобы не увеличивать размер окна в пакетах.

Если PLPMTUD обновляет MTU для определенного пути, все сессии уровня пакетизации, использующие этот путь (см. параграф 5.2), следует уведомить об использовании нового MTU и выполнении требуемой корректировки контроля перегрузок.

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

Реализации могут пользоваться той или иной эвристикой при выборе начального эффективного значения Path MTU для каждого протокола. Протоколам без организации соединений и протоколам, не поддерживающим PLPMTUD, следует поддерживать свое значение, используемое по умолчанию в качестве начального эффективного Path MTU, которое может быть более консервативным (меньшим) по сравнению с начальным значением, используемым TCP и другими протоколами, подходящими для PLPMTUD. Следует задавать пределы начального эффективного Path MTU (eff_pmtu) по протоколам и маршрутам, а также верхний предел поиска (search_high). Дополнительная информация представлена в параграфе 7.2.

5. Уровни

Механизм Path MTU Discovery уровня пакетизации проще всего реализовать, разделив его функции между уровнями. Уровень IP лучше всего подходит для хранения общего состояния, сбора сообщений ICMP, отслеживания размера заголовков IP и управления информацией MTU, предоставляемой интерфейсами канального уровня. Однако процедуры, используемые PLPMTUD для зондирования и проверки Path MTU, весьма тесно связаны с функциями уровня пакетизации типа механизмов восстановления данных и состояний контроля перегрузок.

Отметим, что такая многоуровневая модель является прямым расширением рекомендаций текущих спецификаций PMTUD в RFC 1191 и RFC 1981.

5.1. Учет размера заголовков

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

5.2. Хранение информации PMTU

В этом документе используется концепция потока для определения области действия алгоритма Path MTU Discovery. Для многих реализаций поток будет естественным способом соответствовать экземпляру каждого протокола (т. е., каждому соединению или сессии). В таких реализациях описанные в этом документе алгоритмы выполняются в рамках каждой сессии каждого протокола. Наблюдаемое значение PMTU (eff_pmtu в параграфе 7.1) может использоваться разными потоками, проходящими через одно представление пути.

Кроме того, PLPMTUD можно реализовать так, что полное состояние будет связано с представлением пути. Такие реализации могут использовать множество соединений или сессий для каждой последовательности проб. Очевидно, что в некоторых средах такая модель обеспечит гораздо более быстрое схождение, особенно в случаях использования множеством приложений большого числа мелких соединений, каждое из которых слишком мало для полной поддержки процесса Path MTU Discovery.

В рамках одной реализации разные протоколы могут применять любую из этих двух моделей. По причине различий в протоколах по части генерации проб (параграф 6.2) и алгоритмов поиска MTU (параграф 7.3) может оказаться нежелательным совместное использование разными уровнями пакетизации общего состояния PLPMTUD. Это позволяет предположить, что некоторые протоколы смогут совместно использовать состояние зондирования, а другие смогут использовать совместно лишь найденное значение PMTU. В таких случаях разные протоколы будут иметь разные свойства в части схождения PMTU.

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

Реализация может использовать адрес получателя в качестве локального представления пути. Значение PMTU, связанное с получателем, будет меньшим из числа PMTU определенных для всего набора путей к этому получателю. Предполагается, что множество активных путей к данному получателю будет достаточно мало и во многих случаях путь окажется единственным. Такой подход обеспечивает использование пакетов оптимального размера для каждого получателя и хорошо интегрируется с концептуальной моделью хоста, описанной в [RFC2461], — значение PMTU будет храниться вместе с соответствующей записью в кэше адресатов. Поскольку трансляторы NAT⁶ и другие промежуточные устройства могут одновременно показывать разные значения PMTU для одного адреса IP, сохранять следует минимальное значение.

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

Для пакетов с заданным отправителем маршрутом (source-routed), которые включают заголовок маршрутизации IPv6, опции IPv4 Loose Source и Record Route (LSRR) или Strict Source и Record Route (SSRR), такой маршрут может использоваться для локального представления пути. Реализация может использовать заданный отправителем маршрут в качестве локального представления пути.

Если применяются потоки IPv6, реализация может использовать триплет из метки потока (Flow label) и адресов отправителя и получателя [RFC2460][RFC3697] в качестве локального представления пути. Такая модель теоретически ведет к оптимальному выбору размера пакетов для потока, обеспечивая более тонкую детализацию значений MTU, нежели это делается на уровне получателей.

5.3. Трактовка IPsec

В этом документе не учитывается «уровень» IP Security (IPsec) [RFC2401], который логически размещается между IP и уровнем пакетизации. Реализации PLPMTUD могут трактовать IPsec как часть IP или уровня пакетизации, пока это не вступает в противоречие с реализацией. Если IPsec принимается как часть уровня IP, для каждой защищенной связи с удаленной точкой может ее трактовка как отдельного пути. Если IPsec считается частью уровня пакетизации, заголовок IPsec должен включаться при расчете размера заголовка уровня пакетизации.

5.4. Групповая адресация

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

По минимуму реализация может поддерживать одно значение MTU для всех групповых пакетов, исходящих от узла. Это значение следует делать достаточно малым, чтобы оно не превысило минимальное значение Path MTU на всех ветвях multicast-дерева. Если значение Path MTU, определенное традиционными для индивидуальных пакетов методами, меньше установленного для групповых пакетов MTU, значение MTU для групповых пакетов может быть уменьшено до этого значения. Ясно, что эта модель приведет к использованию на многих путях размера пакетов меньше оптимального.

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

6. Общие свойства пакетизации

В этом разделе описаны общие свойства уровня пакетизации и характеристики, требуемые для реализации PLPMTUD. Описаны также некоторые общие вопросы реализации, относящиеся ко всем уровням пакетизации.

6.1. Механизм обнаружения потерь

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

Лучше всего, если уровень пакетизации использует явный механизм детектирования потерь типа «табло» SACK⁷ [RFC3517] или ACK Vector [RFC4340] для того, чтобы отличить реальные потери от нарушения порядка, хотя достаточно и неявных механизмов типа TCP Reno.

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

6.2. Генерация проб

Есть несколько способов изменения уровня пакетизации с целью генерации пробных пакетов. Разные методы вносят свои накладные расходы, которые можно разделить на три группы — сложность генерации пробных пакетов (рост сложности реализации Packetization Layer и дополнительные операции с данными), расход пропускной способности сети на передачу пробных пакетов и восстановление после отказов при пробах (издержки сети и протокола).

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

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

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

В некоторых случаях может не найтись подходящего механизма для генерации проб в самом протоколе уровня пакетизации. В таких случаях остается полагаться на дополнительный протокол типа ICMP ECHO (ping). Более подробно это описано в параграфе 10.3.

7. Метод зондирования

В этом разделе описаны детали метода зондирования MTU, включая передачу пробных пакетов и обработку индикации ошибок для определения Path MTU.

7.1. Диапазоны размеров пакетов

В этом документе описан метод зондирования с использованием трех переменных состояния.

search_low

Наименьший полезный размер зонда минус 1. Предполагается, что сеть способна доставлять пакеты размера search_low.

search_high

Наибольший полезный размер зонда. Предполагается, что пакеты размером search_high слишком велики для доставки через сеть.

eff_pmtu

Эффективное значение PMTU для данного потока. Это размер наибольшего пакета (не зонда), разрешаемый PLPMTUD для данного пути.

    search_low          eff_pmtu         search_high
        |                   |                  |
...------------------------->

    размеры обычных пакетов
        <-------------------------------------->
                 размеры пробных пакетов

Рисунок 1.

При передаче обычных пакетов (не зондов) уровню пакетизации следует создавать пакеты размером не более eff_pmtu.

При передаче проб уровень пакетизации должен выбирать размер проб, который превышает search_low и не превышает search_high.

При зондировании с увеличением размера eff_pmtu всегда совпадает с search_low. В других состояниях (типа начальных условий) после обработки сообщения ICMP PTB или следующего PLPMTUD в другом потоке, проходящем по тому же пути, eff_pmtu может отличаться от search_low. Обычно eff_pmtu будет не меньше search_low и меньше search_high. Обычно предполагается, но не требуется размер проб, превышающий eff_pmtu.

Для начальных условий, где еще нет информации о пути, значение eff_pmtu может превышать search_low. Начальное значение search_low следует выбирать достаточно малым, по производительность измерения может возрастать при выборе большего значения eff_pmtu (см. параграф 7.2).

Если eff_pmtu > search_low, это явно разрешает передавать не являющиеся пробами пакеты размером больше search_low. Когда такой пакет подтверждается, он эффективно служит «неявной пробей» и значение search_low следует увеличивать до размера подтвержденного пакета. Однако при потере «неявной пробы» недопустимо считать это потерей пробного пакета. Если значение eff_pmtu слишком велико, это условие может быть обнаружено только через сообщения ICMP PTB или детектирование «черной дыры» (см. параграф 7.7).

7.2. Выбор начальных значений

Начальное значение search_high следует делать равным размеру наибольшего пакета, который может поддерживаться потоком. Это значение может быть ограничено величиной MTU локального интерфейса, явным механизмом протокола типа опции TCP MSS или внутренним ограничением типа размера поля длины пакета. Кроме того, начальное значение search_high может быть ограничено конфигурационной опцией для предотвращения слишком большого размера пробных пакетов. Очевидно, что search_high будет совпадать с начальным значением Path MTU, рассчитанным с помощью классического алгоритма Path MTU Discovery.

Рекомендуется в качестве начального значения search_low устанавливать значение MTU, что очевидно будет работать в большинстве сред. Для современных технологий значение 1024 байта является достаточно безопасным. Начальное значение search_low следует делать настраиваемым.

Корректная работа механизма Path MTU Discovery очень важна для обеспечения отказоустойчивости и эффективной работы сети Internet. Любое серьезное изменение (например, описанное здесь) может оказывать негативное влияние, если оно вызывает неожиданные изменения в поведении протоколов. Выбор начального значения eff_pmtu определяет, в какой степени поведение реализации PLPMTUD соответствует классическому PMTUD в тех случаях, когда классического метода достаточно.

Консервативный подход заключается в установке значения eff_pmtu для search_high и использовании сообщений ICMP PTB для установки приемлемо низкого значения eff_pmtu. В такой конфигурации классический механизм PMTUD обеспечивает полную функциональность, а PLPMTUD вызывается лишь для восстановления при возникновении «черных дыр» ICMP с помощью процедуры, описанной в параграфе 7.7.

В некоторых случаях, когда известно, что классический механизм PMTUD столкнется с отказом (например, когда сообщения ICMP PTB административно запрещены из соображений безопасности), использование малых начальных значений eff_pmtu позволит предотвратить долгое ожидание, требуемое для детектирования «черной дыры». С другой стороны, использование слишком малого начального значения eff_pmtu может приводить к снижению производительности.

Отметим, что в качестве начального значения eff_pmtu может быть выбрано любое число из интервала search_low — search_high. Начальное значение eff_pmtu = 1400 байтов может быть хорошим выбором, поскольку оно безопасно почти для всех туннелей в сетях общего пользования и достаточно близко к оптимальному MTU на большинстве путей в современной сети Internet. Более эффективный выбор может обеспечить использование статистики недавних потоков — например, в качестве начального eff_pmtu для потока можно установить средний (медианный) размер пробных пакетов из всех успешных проб.

Поскольку стоимость PLPMTUD обусловлена, прежде всего, специфическими для протокола издержками на генерацию и обработку пробных пакетов, может оказаться целесообразным использование для каждого протокола своей эвристики выбора начального значения eff_pmtu. Для протоколов без организации соединений и других протоколов, которые могут не получать четкой индикации «черных дыр» ICMP, очень важно использовать более консервативные (меньшие) начальные значение eff_pmtu, как описано в параграфе 10.3.

Следует устанавливать конфигурационные опции на уровне протокола и маршрута для замены начальных значений eff_pmtu и других переменных состояния PLPMTUD.

7.3. Выбор размера пробы

Пробный пакет может иметь любой размер из описанного выше «диапазона размеров проб». Однако на выбор подходящего размера влияет множество факторов. В качестве простой стратегии выбора может использоваться двоичный поиск в уменьшением вдвое размера диапазона после каждой пробы. Однако для некоторых протоколов (типа TCP) отказы обходятся «дороже» успешных проб, поскольку данные в столкнувшейся с отказом пробе требуется передать заново. Для таких протоколов стратегия незначительного увеличения размера каждой следующей пробы может обеспечивать меньшие издержки. Для многих протоколов на уровне пакетизации и выше его преимущества в результате роста MTU могут расти ступенчато, поэтому из некоторых поддиапазонов размер проб выбирать просто не имеет смысла.

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

Некоторые протоколы могут использовать другие механизмы определения размера проб. Например, протоколы, с неким естественным размером блока данных могут просто собирать сообщение из множества таких блоков, пока общий размер меньше search_high и возможно больше search_low.

Каждый протокол пакетизации должен определять схождение проб, т. е., размер проб уже достаточно мал и дальнейшее зондирование не уменьшит его. Когда зондирование сходится, следует устанавливать таймер. По завершении отсчета этого таймера search_high следует сбросить в начальное значение (см. выше), чтобы зондирование можно было восстановить. Таким образом, при изменении пути с ростом Path MTU это преимущество может быть использовано. Для таймера недопустимо устанавливать значение меньше 5 минут и рекомендуется задавать 10 минут в соответствии с RFC 1981.

7.4. Условия зондирования

Прежде, чем передавать пробы, для потока должны быть выполнены по крайней мере перечисленные ниже условия:

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

Кроме того, с алгоритмами своевременного обнаружения потерь в большинстве протоколов связаны предварительные условия, которые следует выполнить до отправки зонда. Например, TCP Fast Retransmit не обеспечивает надежных результатов пока вслед за зондом не будет передано достаточное число сегментов, поэтому отправителю следует сначала набрать достаточный объем данных в очереди и достаточно большое окно приема для отправки зонда и не менее Tcprexmtthresh [RFC2760] дополнительных сегментов. Это условие может препятствовать зондированию при некоторых состояниях протокола (например, незадолго до завершения работы соединения или при слишком малом окне).

Протоколы могут задерживать отправку не являющихся зондами пакетов для того, чтобы набрать объем данных, требуемый условиями зондирования. Следует применять алгоритм отложенной передачи, использующий тот или иной метод самомасштабирования для ограничения времени задержки отправки данных. Например, возврат ACK можно использовать для того. Чтобы предотвратить снижение размера окна сверх требуемого для отправки зонда значения.

7.5. Выполнение зондирования

После выбора размера зондов и выполнения перечисленных выше условий уровень пакетизации (Packetization Layer) может начать зондирование. Для этого он создает пробные пакеты так, чтобы их размер, с учетом всех заголовков IP, был равен размеру зонда. После отправки зонда происходит ожидание отклика, которое может закончиться одним из перечисленных ниже результатов:

Успех. Получение пробного пакета было подтверждено удаленным хостом.

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

Тайм-аут. Протокольный механизм указал на потерю пробы, в предшествующем окне потерь не было и нет возможности определить наличие потери пакетов в последующем окне. Например, потеря была обнаружена по тайм-ауту и использована повторная передача go-back-n.

Незавершенность. Проба была потеряна наряду с другими пакетами в предыдущем или следующем окне.

7.6. Реакция на результат зондирования

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

7.6.1. Успешная проба

Доставка пробного пакета говорит о том, что Path MTU не меньше размера этого пакета. Размер пробы устанавливается в качестве search_low. Если размер пробы превышает eff_pmtu, увеличивается значение eff_pmtu до размера пробы. Размер пробного пакета может оказаться меньше eff_pmtu, если поток не использовал полного MTU для пути в силу тех или иных ограничения (например, объем доступных данных в интерактивной сессии).

Отметим, что при маршрутизации пакетов потока по разным путям или путям с недетерминированным значением MTU, доставка одного пробного пакета не говорит о доставке остальных пакетов того же размера. В таких случаях для получения надежного результата уровню пакетизации следует проверять значение MTU, как описано в параграфе 7.8.

7.6.2. Неудачная проба

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

При отсутствии других индикаторов установите для search_high значение размера зонда минус 1. Значение eff_pmtu может быть больше размера зонда, если поток не использовал полное значение MTU для пути, поскольку здесь применяются иные ограничения типа доступности данных в интерактивном сеансе. Если eff_pmtu превышает размер зонда, значение eff_pmtu должно быть уменьшено так, чтобы оно не превышало search_high и следует уменьшать его до search_low, поскольку была обнаружена некорректность eff_pmtu, как после тайм-аута full-stop (параграф 7.7).

Если полученное сообщение ICMP PTB соответствует пробному пакету, для search_high и eff_pmtu можно установить значение MTU, указанное в этом сообщении. Отметим, что сообщение ICMP может быть получено до или после индикации потери протоколом.

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

7.6.3. Тайм-аут для пробы

Если потеря была обнаружена по тайм-ауту и восстановлена с помощью повторной передачи go-back-n, необходимо уменьшить окно насыщения. Относительно высокая цена пробу в этом случае может «заслуживать» увеличения интервала перед отправкой следующего зонда. Рекомендуется интервал, превышающий в 5 раз время для случая отказа без тайм-аута параграф 7.6.2).

7.6.4. Незавершенная проба

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

7.7. Тайм-аут полной остановки

При любых условиях тайм-аут полной остановки (full-stop timeout, иногда persistent timeout) следует считать указанием некого значимого разрушительного события в сети, такого как отказ маршрутизатора или смена маршрутизации на путь с меньшим MTU. Для TCP это возникает при наступлении порога тайм-аута R1, описанного в [RFC1122].

При возникновении тайм-аута полной остановки и отсутствии сообщения ICMP (PTB, Net unreachable и т. п. или сообщение ICMP проигнорировано по иной причине) с указанием причины рекомендуемым первым действием по восстановлению является трактовка этого события как обнаружение «черной дыры» ICMP, описанной в [RFC2923].

Отклик на обнаружение черной дыры зависит от текущих значений search_low и eff_pmtu. Если eff_pmtu > search_low, устанавливается eff_pmtu = search_low. В противном случае для eff_pmtu и search_low устанавливается начальное значение search_low. При дополнительных последующих тайм-аутах значение search_low и eff_pmtu следует уменьшать вдвое с нижней границей 68 байтов для IPv4 и 1280 байтов для IPv6. Можно устанавливать и более низкие значения для поддержки ограниченной работы по каналам связи с MTU меньше разрешенных спецификациями IP значений.

7.8. Проверка MTU

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

При отказе доставки ICMP, прерывающем PMTUD, соединение будет полагаться только на PLPMTUD. В этом случае PLPMTUD также может давать отказ, поскольку предполагает прохождение потока по пути с одним MTU. Проба с размером между минимальным и максимальным Path MTU может быть успешной. Однако при увеличении эффективного PMTU потока частота потерь значительно возрастет. Поток может все еще сохраняться, но результирующий уровень потерь вероятно станет неприемлемым. Например, при использовании двухстороннего циклического чередования может отбрасываться 50% полноразмерных пакетов.

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

Рекомендуемой стратегией является запись значения eff_pmtu перед его увеличением. Затем, если частота потерь за интервал времени превышает порог (например, больше 10% за несколько интервалов RTO⁸), новое значение MTU считается непригодным. Следует восстановить сохраненное значение eff_pmtu и установить сниженное как при отказе пробы значение search_high. Реализациям PLPMTUD следует поддерживать проверку MTU.

8. Фрагментация на хосте

Уровням пакетизации следует избегать передачи сообщений, которые будут требовать фрагментирования [Kent87] [frag-errors]. Однако полностью предотвратить фрагментацию не всегда удается. Некоторые уровни пакетизации, такие как приложения UDP вне ядра, могут быть не в состоянии менять размер передаваемых сообщений и в результате размер дейтаграмм превысит Path MTU.

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

Реализациям IPv4 рекомендуется использовать стратегию, имитирующую функциональность IPv6. Когда приложение передает дейтаграммы размером больше эффективного Path MTU, их следует фрагментировать до Path MTU на IP-уровне хоста, даже если размер меньше MTU на первом канале, напрямую подключенном к хосту. Для фрагментов следует установить бит DF, чтобы они снова не были фрагментированы в сети. Это будет минимизировать вероятность того, что приложения будут полагаться на фрагментацию IPv4 таким способом, который не может быть реализован в IPv6. По меньшей мере одна из основных операционных систем уже применяет такую стратегию. В разделе 9 описаны некоторые исключения из этого правила, когда приложения передают большие пакеты для зондирования или диагностики.

Поскольку протоколы, не реализующие PLPMTUD, все еще подвержены проблемам в результате возникновения черных дыр ICMP, может оказаться желательным ограничение таких протоколов «безопасным» MTU, с которым вероятно можно будет работать на любом пути (например, 1280). реализующим PLPMTUD протоколам можно работать с полным диапазоном, поддерживаемым нижним уровнем.

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

9. Зондирование из приложений

Все реализации должны включать механизм, позволяющий приложениям, которые используют протоколы без организации соединений, передавать свои пробы. Это необходимо для реализации PLPMTUD в прикладном протоколе, как описано в параграфе 10.4, или для реализации диагностических средств отладки PMTUD. Должен быть механизм, позволяющий приложению передавать дейтаграммы размером больше eff_pmtu (оценка операционной системой значения Path MTU) без фрагментации. В пакетах IPv4 должен быть установлен флаг DF.

В настоящее время большинство операционных систем поддерживает два режима отправки дейтаграмм, один из которых «молча» фрагментирует слишком большие пакеты, а другой отвергает их. Ни один из этих режимов не подходит для реализации PLPMTUD в приложениях или диагностики проблем Path MTU Discovery. Требуется третий режим, который будет передавать дейтаграммы даже при размерах более текущей оценки Path MTU.

Реализация PLPMTUD в приложении также требует механизма, с помощью которого приложение может информировать операционную систему о результатах проб, как описано в параграфе 7.6, или напрямую обновлять search_low, search_high и eff_pmtu, описанные в параграфе 7.1.

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

10. Конкретные уровни пакетизации

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

10.1. Метод зондирования с использованием TCP

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

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


             Порядковый номер TCP

в   <---->
р
е         <-------->           (проба)
м                   <---->
я
              .
              .                (потеря пробы)
              .

          <---->               (повтор probe gap)
                <-->

Рисунок 2.

Другим вариантом является такое перекрытие последующих данных с пробой, что пропуск пробы (probe gap) составит текущий размер MSS. При успешной пробе это увеличивает издержки, поскольку некоторые данные передаются дважды, но повторно будет передаваться лишь один сегмент после потери пробы. Когда проба успешна, вероятна будет генерация дубликатов подтверждений в результате передачи дубликатов данных. Важно, чтобы эти дубликаты не вызывали режим ускоренного повтора (Fast Retransmit). Поэтому применяющей такой подход реализации следует ограничивать размер проб трехкратным значением текущего MSS (что может вызвать не более 2 дубликатов подтверждений) или подобающим образом настроить порог дублирования подтверждений для данных сразу после успешной пробы.

             Порядковый номер TCP

в   <---->
р         <-------->           (проба)
е               <---->
м
я                     <---->

              .
              .                (потеря пробы)
              .

          <---->               (повтор probe gap)
                <-->

Рисунок 3.

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

10.2. Метод зондирования с использованием SCTP

В протоколе SCTP⁹ [RFC2960] приложение пишет в SCTP сообщения, которые делят данные на небольшие блоки (chunk), подходящие для передачи через сеть. Каждому блоку назначается порядковый номер TSN¹⁰. После передачи TSN протокол SCTP не может изменить размер блока. Поддержка в SCTP множества путей обычно требует от протокола выбирать размер блока так, чтобы сообщения помещались в наименьший PMTU среди всех путей. Хотя это не требуется, реализация может собрать множество блоков в более крупные пакеты IP для отправки по путям с большим PMTU. Отметим, что в SCTP пробы PMTU должны выполняться на каждом пути к партнеру.

Рекомендуемым методом генерации проб является добавление блока, содержащего лишь заполнение, к сообщению SCTP. Для создания пробы блок PAD, определенный в [RFC4820], следует присоединять к блоку HEARTBEAT (HB) минимального размера. Этот метод полностью совместим и современными реализациями SCTP.

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

10.3. Метод зондирования для фрагментации IP

Имеется несколько протоколов и приложений, которые обычно передают большие дейтаграммы и полагаются для их доставки на фрагментацию IP. Давно известно, что это имеет некоторые нежелательные последствия [Kent87]. Недавно стало ясно, что фрагментация IPv4 недостаточно отказоустойчива для общего применения в современной сети Internet. 16-битовое поле идентификации IP недостаточно велико для предотвращения частого ошибочного связывания фрагментов IP, а контрольных сумм TCP и UDP недостаточно для предотвращения доставки полученных в результате поврежденных данных вышележащим протоколам [frag-errors].

Как упомянуто в разделе 8, протоколы дейтаграмм (такие как UDP) могут полагаться на фрагментацию IP как уровень пакетизации. Однако применение фрагментации IP для реализации PLPMTUD проблематично, поскольку на уровне IP нет механизма для определения доставки пакетов конечному получателю без прямого участия приложения.

Для поддержки фрагментации IP в качестве уровня пакетизации без необходимости изменять приложения реализации следует полагаться на совместное использование Path MTU, описанное в параграфе 5.2, а также дополнительный протокол для проб Path MTU. Имеется множество пригодных для этого протоколов, таких как ICMP ECHO и ECHO REPLY или дейтаграммы UDP в стиле traceroute, которые вызывают сообщения ICMP. Использование ICMP ECHO и ECHO REPLY будет проверять прямой и обратный путь, поэтому отправитель сможет лишь воспользоваться преимуществом меньшего из двух. Другие методы проверяют только прямой пути и поэтому более предпочтительны.

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

Однако имеются и более серьезные отказы, например вызываемые промежуточными устройствами или маршрутизаторами, которые выбирают разные пути для различных протоколов или сессий. В таких средах вспомогательные протоколы могут корректно получать другие значения Path MTU, нежели основной протокол. Если вспомогательный протокол найдет большее значение MTU, чем будет у основного протокола, PLPMTUD может выбрать MTU, которое не подойдет для основного протокола. Хотя эта проблема потенциально серьезна, такая ситуация будет скорей всего восприниматься как некорректная многочисленными наблюдателями, которые постараются исправить ситуацию.

Поскольку протоколы без организации соединений могут не сохранять состояния, достаточного для эффективной диагностики черных дыр MTU, большую устойчивость к ошибкам обеспечило бы использование небольшого начального MTU (например, 1 Кбайт или меньше) до начала проверки пути с целью определения MTU. По этой причине реализациям, применяющим фрагментацию IP, следует использовать начальное значение eff_pmtu, выбранное в соответствии с параграфом 7.2, за исключением отдельного глобального управления для принятого по умолчанию начального eff_mtu в протоколах без организации соединений.

Протоколы без организации соединений создают также дополнительную проблему поддержки кэша с информацией о пути, поскольку здесь нет событий, соответствующих организации или разрыву соединения, которые могли бы служить для управления кэшем. Естественным решением будет сохранение в кэше неизменной записи для default path, которая имеет в качестве eff_pmtu фиксированное начальное значение для протокола без организации соединений. Вспомогательный протокол Path MTU Discovery будет вызываться один, как только число фрагментированных дейтаграмм для любого конкретного адресата достигнет настраиваемого порога (например, 5). Новые записи в кэше будут создаваться при обновлении вспомогательным протоколом значений eff_pmtu и удаляться по таймеру или алгоритму замены записей LRU¹¹.

10.4. Метод зондирования для приложений

Недостатки, связанные с фрагментацией IP и добавочным протоколом для выполнения Path MTU Discovery, можно устранить реализацией Path MTU Discovery в самом приложении, с использованием прикладного протокола. Приложение должно иметь тот или иной подходящий метод генерации проб и механизм своевременного обнаружения потери пробных пакетов.

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

Для протоколов, которые не могут реализовать PLPMTUD с помощью «эхо и заполнения», имеются другие методы генерации проб. Например, протокол может иметь эхо-сигнал переменного размера для эффективного измерения минимального MTU на прямом и обратном пути или может иметь способ добавлять заполнение в обычные сообщения с реальными данными приложений. Могут быть и другие способы сегментирования данных приложения для создания проб или, в крайнем случае, может быть целесообразно расширить протокол новыми типами сообщений для поддержки определения MTU.

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

Все методы зондирования требуют возможности передавать сообщения размером больше текущего значения eff_pmtu, описанного в разделе 9.

11. Вопросы безопасности

При любых условиях описанные в этом документе процедуры PLPMTUD защищены по меньшей мере в такой же степени, как современные стандартные процедуры Path MTU Discovery, описанные в RFC 1191 и RFC 1981.

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

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

12. Литература

12.1. Нормативные документы

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, «IPv6 Flow Label Specification», RFC 3697, March 2004.

[RFC4820] Tuexen, M., Stewart, R., and P. Lei, «Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)», RFC 4820, March 2007.

12.2. Дополнительная литература

[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott, K., and J. Semke, «Ongoing TCP Research Related to Satellites», RFC 2760, February 2000.

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC2923] Lahey, K., «TCP Problems with Path MTU Discovery», RFC 2923, September 2000.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401 ¹³, November 1998.

[RFC2914] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, September 2000.

[RFC2461] Narten, T., Nordmark, E., and W. Simpson, «Neighbor Discovery for IP Version 6 (IPv6)», RFC 2461, December 1998.

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517, April 2003.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, March 2006.

[Kent87] Kent, C. and J. Mogul, «Fragmentation considered harmful», Proc. SIGCOMM ’87 vol. 17, No. 5, October 1987.

[tcp-friendly] Mahdavi, J. and S. Floyd, «TCP-Friendly Unicast Rate-Based Flow Control», Technical note sent to the end2end-interest mailing list , January 1997, <http://www.psc.edu/networking/papers/tcp_friendly.html>.

[frag-errors] Heffner, J., «IPv4 Reassembly Errors at High Data Rates», Work in Progress¹⁴, December 2007.

Приложение A. Благодарности

Многие идеи и даже часть текста этого документа заимствованы из RFC 1191 и RFC 1981.

В подготовку документа внесло свой вклад множество людей, включая Randall Stewart (текст для SCTP), Michael Richardson (материал из ранних идентификаторов туннелей, которые игнорируют DF, Stanislav Shalunov (идея о том, что чистый механизм PLPMTUD работает параллельно контролю перегрузок), Matt Zekauskas (за поддержку обсуждений при встречах). Спасибо первоначальным разработчикам Kevin Lahey, John Heffner и Rao Shoaib, которые предоставили конкретные отклики о недостатках ранних версий. Спасибо также всем, кто внес конструктивные замечания на встречах рабочей группы и в почтовой конференции. Авторы уверены, сто этот список достойных людей неполон.

Работа Matt Mathis и John Heffner была поддержана грантом компании Cisco Systems, Inc.

Адреса авторов

Matt Mathis

Pittsburgh Supercomputing Center

4400 Fifth Avenue

Pittsburgh, PA 15213

USA

Phone: 412-268-3319

EMail: mathis@psc.edu

John W. Heffner

Pittsburgh Supercomputing Center

4400 Fifth Avenue

Pittsburgh, PA 15213

Phone: 412-268-2329

EMail: jheffner@psc.edu

Перевод на русский язык

Николай Малых