RFC 1812 (часть 2)

Please enter banners and links.

image_print

Часть 1

5. Уровень INTERNET – пересылка

5.1 Введение

В этом разделе рассматривается процесс пересылки пакетов в маршрутизаторах.

5.2 Функция пересылки пакетов

Для функции пересылки пакетов IP не существует отдельной спецификации. Процесс пересылки описан в спецификациях протокола IP ([INTERNET:1], [INTERNET:2], [INTERNET:3], [INTERNET:8], [ROUTE:11]).

5.2.1 Алгоритм пересылки

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

От реализаций не требуется точного следования алгоритмам, описанным в параграфах 5.2.1.1, 5.2.1.2 и 5.2.1.3. Многие разработчики программ в целях повышения производительности пересылки пакетов используют иные решения, которые в конечном итоге дают такой же результат, как описанный здесь алгоритм. Детали реализации алгоритма пересылки не рассматриваются в этом документе (в частности по той причине, что они могут сильно зависеть от архитектуры маршрутизатора). Вместо этого ниже приводятся общие требования к выполняемым при пересылке операциям с учетом их порядка.

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

  2. Обработка некоторых опций IP требует от маршрутизатора включения своего адреса IP в эту опцию. Как указано в параграфе 5.2.4, в опцию должен включаться адрес логического интерфейса, через который пакет передается, или значение router-id, если пакет передается через интерфейс, не имеющий адреса. Таким образом, обработка подобных опций не может быть завершена до принятия решения о выборе интерфейса для передачи пакета.

  3. Маршрутизатор не может проверять и уменьшать значение TTL до того, как он убедится, что пакет не адресован самому маршрутизатору (причины этого указаны в параграфе 4.2.2.9).

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

5.2.1.1 Общие вопросы

В этом параграфе рассматриваются принципы пересылки пакетов. Данный алгоритм применим ко всем типам пересылаемых пакетов – unicast (конкретный адресат), multicast (группа), broadcast (широковещательный пакет).

  1. Маршрутизатор получает пакет IP (вместе с дополнительной информацией о пакете, рассмотренной в параграфе 3.1), от канального уровня (Link Layer).

  2. Маршрутизатор проверяет корректность заголовка IP, как описано в параграфе 5.2.2. Отметим, что сборка фрагментов IP не выполняется за исключением тех случаев, когда пакет адресован самому маршрутизатору (см. п. (4) в предыдущем параграфе).

  3. Маршрутизатор выполняет большую часть операций по обработке опций IP. Как описано в параграфе 5.2.4, некоторые опции IP требуют дополнительной обработки после принятия решения о маршрутизации (выбора выходного интерфейса).

  4. Маршрутизатор проверяет IP-адрес получателя дейтаграммы, как описано в параграфе 5.2.3, чтобы определить, как должна происходить дальнейшая обработка дейтаграммы. Здесь возможны три варианта:

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

    • дейтаграмма не адресована маршрутизатору и ее следует поместить в очередь для пересылки;

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

5.2.1.2 Конкретный адресат (Unicast)

Поскольку локальная доставка хорошо описана в [INTRO:2], ниже предполагается, что дейтаграмма IP предназначена для пересылки. Если пакет направлен по индивидуальному адресу IP, выполяются перечисленные ниже этапы.

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

  2. Модуль пересылки проверяет допустимость пересылки пакета. Адреса отправителя и получателя должны быть корректны в соответствии с требованиями параграфов 5.3.7 и 5.3.4. Если маршрутизатор поддерживает административные ограничения на пересылку (типа описанных в параграфе 5.3.9), эти ограничения должны быть приняты во внимание.

  3. Модуль пересылки уменьшает (по крайней мере на 1) значение TTL в заголовке пакета и проверяет его, как описано в параграфе 5.3.1.

  4. Модуль пересылки выполняет все операции по обработке опций IP, которые не могли быть выполнены на этапе (3).

  5. Модуль пересылки при необходимости фрагментирует пакет, как описано в параграфе 4.2.2.7. Поскольку этот этап выполняется после выбора выходного интерфейса (этап 5), все фрагменты дейтаграммы будут передаваться через один интерфейс.

  6. Модуль пересылки определяет адрес канального уровня для следующего интервала. Механизм определения адреса зависит от используемого протокола канального уровня (см. раздел 3).

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

  8. Модуль пересылки при необходимости передает сообщение ICMP redirect, как описано в параграфе 4.3.3.2.

5.2.1.3 Группа (Multicast)

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

Основные различие между пересылкой индивидуальных и групповых дейтаграмм IP заключаются в следующем:

  • групповые дейтаграммы IP обычно пересылаются на основе адресов отправителя и получателя в заголовке IP;

  • для групповых дейтаграмм IP используется поиск по расширяющимся кругам;

  • групповые дейтаграммы IP пересылаются с использованием групповой адресации канального уровня;

  • сообщения ICMP об ошибках никогда не передаются в ответ на групповые дейтаграммы IP.

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

  1. На основе IP-адресов отправителя и получателей из заголовка дейтаграммы маршрутизатор определяет, следует ли принимать дейтаграмму через данный интерфейс для дальнейшей пересылки. При отрицательном ответе дейтаграмма отбрасывается без уведомления. Метод определения пригодного входного интерфейса зависит от используемого алгоритма групповой маршрутизации. В одном из простейших алгоритмов RPF1 пригоден будет тот интерфейс, который бы использовался для отправки индивидуальных пакетов по адресу отправителя дейтаграммы.

  2. На основе IP-адресов отправителя и получателей из заголовка дейтаграммы маршрутизатор определяет выходные интерфейсы для пересылки дейтаграммы. Для реализации поиска по расширяющимся кругам (см. [INTERNET:4]) каждому выходному интерфейсу ставится в соответствие минимальное значение TTL. Копия multicast-дейтаграммы пересылается через каждый из выходных интерфейсов, для которого минимальное значение TTL не превышает значение TTL в заголовке дейтаграммы. Этот этап выполняется раздельно для каждого интерфейса.

  3. Маршрутизатор уменьшает на 1 значение TTL в заголовке пакета.

  4. Модуль пересылки выполняет все операции по обработке опций IP, которые не могли быть выполнены на этапе (3).

  5. Модуль пересылки при необходимости выполняет фрагментацию дейтаграммы, как описано в параграфе 4.2.2.7.

  6. Модуль пересылки определяет адрес канального уровня для использования при инкапсуляции дейтаграммы в кадр канального уровня. Механизм определения адреса зависит от протокола канального уровня. В локальных сетях используется групповой или широковещательный адрес канального уровня для передачи групповых дейтаграмм IP. Более детальную информацию вы найдете в соответствующих спецификациях IP-over-xxx.

  7. Модуль пересылки инкапсулирует дейтаграмму IP (и каждый из ее фрагментов) в соответствующий кадр канального уровня и помещает в очереди соответствующих сетевых интерфейсов.

5.2.2 Проверка корректности заголовка IP

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

  1. Размер пакета, полученный от канального уровня, должен быть достаточным для размещения дейтаграммы IP минимального размера (20 байтов).

  2. Контрольная сумма в заголовке IP должны быть корректной.

  3. Поле IP version должно содержать значение 4. Если значение поля отличается от 4, пакет относится к другой версии протокола IP (например, IPng2 или ST-II).

  4. Поле IP header length должно иметь значение, достаточное для дейтаграммы IP минимального размера (20 байтов = 5 слов).

  5. Значение поля IP total length должно быть достаточно большим для включения заголовка дейтаграммы IP, размер которого указан в поле IP header length.

Для маршрутизаторов недопустимо наличие конфигурационных опций, позволяющих отключить любую из перечисленных выше проверок. Если пакет прошел тесты 2 и 3, значение поля IP header length не менее 4, а значения поля IP total length и размера пакета, сообщенного канальным уровнем, не менее 16, маршрутизатор может передать сообщение ICMP Parameter Problem с указателем на поле IP header length (если не прошел тест 4) или IP total length (если не прошел тест 5). Однако он по-прежнему должен отбросить такой пакет, а информацию об ошибке следует записать в системный журнал.

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

Реализация

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

  • отсечение части заголовка IP на канальном уровне;

  • использование в дейтаграмме версии протокола IP, отличающейся от стандартной (4);

  • повреждение заголовка IP в процессе передачи пакета;

  • некорректное создание заголовка IP отправителем.

Проверку заголовка желательно выполнять с соблюдением указанного выше порядка, поскольку этот порядок представляется наиболее удобным для определения причины ошибки. Для протоколирования ошибок может также оказаться полезной проверка принадлежности пакета к иным версиям протокола IP (в частности, IPng или ST-II); такие проверки нужно выполнять на основе соответствующих спецификаций.

В дополнение к перечисленным тестам следует проверять, что размер пакета, сообщенный канальным уровнем, достаточен для размещения дейтаграммы, размер которой указан в поле IP total length заголовка IP. Если окажется, что пакет был усечен по длине, такой пакет должен быть отброшен, информацию об ошибке следует записать в системный журнал, а маршрутизатору следует передать сообщение ICMP Parameter Problem с указателем на поле IP total length.

Обсуждение

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

Наконец, если адрес получателя в заголовке пакета не совпадает ни с одним из IP-адресов маршрутизатора, последнему следует убедиться в отсутствии в заголовке пакета опций Strict Source Route и Record Route. Если такая опция присутствует, маршрутизатору следует записать в системный журнал сообщение об ошибке и передать отправителю сообщение ICMP Parameter Problem с указателем на IP-адрес получателя.

Обсуждение

Некоторые люди считают, что маршрутизатору следует в таких случаях передавать сообщение Bad Source Route вместо Parameter Problem. Однако, если пакет не проходит указанную проверку, это обычно говорит о протокольной ошибке на предыдущем маршрутизаторе, тогда как сообщение Bad Source Route будет означать, что исходный отправитель задал несуществующий или недоступный путь через сеть.

5.2.3 Решение о локальной доставке

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

  1. Незавершенными считаются те опции source route, указатель которых не ссылается за последнюю запись в маршруте source route. Когда пакет содержит незавершенную опцию source route, указатель в этой опции ссылается вперед, если он не указывает на последний адрес в опции или следующий адрес не является одним из адресов самого маршрутизатора. В последнем (нормальном) случае пакет пересылается (и не доставляется локально) независимо от соответствия приведенным ниже правилам.

  2. Пакет доставляется локально и не пересылается в следующих случаях:

    • адрес получателя точно соответствует одному из IP-адресов маршрутизатора;

    • в поле получателя указан широковещательный адрес ограниченного действия ({-1, -1});

    • пакет направлен по групповому адресу IP, для которого пересылка никогда не выполняется (например, 224.0.0.1 или 224.0.0.2) и хотя бы один из логических интерфейсов, связанных с физическим интерфейсом, приняшим пакет, является членом данной multicast-группы.

  1. Пакет передается модулю пересылки и доставляется локально в следующих случаях:

    • в качестве адреса получателя указан широковещательный адрес IP, который соответствует хотя бы одному из логических интерфейсов маршрутизатора, но не соответствует адресам логических интерфейсов, связанных с физическим интерфейсом, через который был принят пакет;

    • пакет направлен по групповому адресу IP, который может использоваться для пересылки (в отличие от адресов 224.0.0.1 и 224.0.0.2), и по крайней мере один из логических интерфейсов, связанных с принявшим пакет физическим интерфейсом, является членом группы, которой пакет адресован.

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

  2. В остальных случаях пакет передается модулю пересылки.

Обсуждение

Требования последнего предложения п. 4 – обеспечение корректной обработки пакетов в случаях получения пакетов directed broadcast для другого префикса в той же физической сети. Обычно все работает в соответствии с ожиданиями – отправитель передает широковещательный пакет маршрутизатору с использованием unicast-адреса канального уровня. Маршрутизатор отмечает, что пакет получен, как unicast и, следовательно, должен быть направлен в другую сеть, нежели та, из которой он прибыл. Следовательно, маршрутизатор может без риска передать этот пакет с использованием широковещательного адреса канального уровня в ту же физическую сеть через тот же (физический) интерфейс, который принял пакет. Однако, если маршрутизатор не может определить, что пакет был получен, как unicast-кадр канального уровня, упомянутое требование позволяет маршрутизатору считать, что он выполняет безопасную, но некорректную пересылку (а не рискованную, но корректную).

Реализация

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

В некоторых случаях канальный уровень (в силу аппаратных особенностей или программного кода драйверов) может передавать маршрутизатору копии всех передаваемых в среде широковещательных и групповых кадров канального уровня. Описанный здесь подход позволяет упростить реализацию для тех случаев, когда пакет доставляется локально и передается модулю пересылки, поскольку пересылка пакета будет автоматически приводить к получению маршрутизатором копии пакета, которую он может использовать для локальной доставки. Однако в таких случаях нужно быть внимательным, чтобы предотвратить трактовку полученных «возвратных» (loop-back) пакетов, как обычных принятых пакетов (и применения к ним правил пересылки и т. п.).

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

5.2.4 Определение адреса следующего интервала

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

Ниже перечислены используемые в этом разделе термины и сокращения:

  • LSRR – опция IP Loose Source and Record Route;

  • SSRR – опция IP Strict Source and Record Route;

  • опция Source Route – LSRR или SSRR;

  • адрес окончательной доставки3 – точка, куда пакет в конце концов должен быть передан – последний адрес в заданном отправителем маршруте доставки пакета или IP-адрес получателя в заголовке пакета без опции source-route;

  • смежный – доступный без прохождения через маршрутизаторы IP;

  • адрес следующего интервала – IP-адрес смежного хоста или маршрутизатора, которому пакет будет передан на следующем интервале;

  • IP-адрес получателя – адрес окончательной доставки для случаев, когда не используется заданная отправителем маршрутизация (в этом случае адресом получателя служит следующий адрес, указанный в source route);

  • непосредственный получатель4 – узел, система, маршрутизатор или конечная система, указанная IP-адресом получателя.

5.2.4.1 IP-адрес получателя

Если выполняются перечисленные ниже условия:

  • адрес получателя в заголовке IP совпадает с одним из адресов маршрутизатора;

  • пакет содержит опцию Source Route;

  • указатель в опции Source Route не ссылается за пределы этой опции,

IP-адресом получателя является адрес, на который ссылается указатель опции Source Route. Если выполняются следующие условия:

  • адрес получателя в заголовке IP совпадает с одним из адресов маршрутизатора;

  • пакет содержит опцию Source Route;

  • указатель в опции Source Route ссылается за пределы этой опции,

сообщение адресовано системе, анализирующей его5.

Маршрутизатор должен использовать IP-адрес получателя, а не адрес окончательной доставки (последний адрес в опции source route) при определении режима обработки пакета.

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

5.2.4.2 Выбор между локальной доставкой и пересылкой

После того, как была определена необходимость пересылки пакета IP в соответствии с правилами, указанными в параграфе 5.2.3, должен использоваться описанный ниже алгоритм определения прямой доступности6 непосредственного получателя (см. [INTERNET:2]).

  1. Для каждого сетевого интерфейса, не имеющего адреса IP (безадресные линии обсуждаются в параграфе 2.2.7), сравнивается значение router-id на другой стороне соединения с IP-адресом получателя. При совпадении адресов пакет можно передавать через данный интерфейс.

Обсуждение

Иными словами, маршрутизатор или хост на другой стороне соединения является адресатом пакета или следующим интервалом заданного отправителем маршрута для пакета с опцией source route.

  1. Если на первом этапе сетевой интерфейс не был выбран, для каждого из IP-адресов маршрутизатора выполняются следующие операции:

    1. Выделяется сетевой префикс, используемый интерфейсом.

Реализация

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

    1. Выделяется соответствующий набор битов из IP-адреса получателя для пакета.

    2. Сравниваются полученные сетевые префиксы и при совпадении пакет может передаваться через соответствующий интерфейс.

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

В работе [ARCH:9, NRHP] рассматриваются некоторые специальные случаи (например, наличие множества (под)сетей IP в одной сети канального уровня). За исключением заданных политикой ограничений, хосты и маршрутизаторы, находящиеся в одной сети канального уровня, могут взаимодействовать между собой напрямую, даже если они находятся в разных (под)сетях IP, при наличии адекватной информации. Протокол NHRP7 позволяет узлам IP определять «оптимальный» адрес канального уровня для передачи пакетов через такую сеть канального уровня в направлении удаленного адресата.

  1. Если выбранный следующий интервал доступен через интерфейс, настроенный на использование NHRP, применимы перечисленные ниже дополнительные операции.

    1. Сравнивается IP-адрес получателя с адресами получателей в кэше NHRP. При обнаружении искомого адреса в кэше, дейтаграмма передается по соответствующему кэшированному адресу канального уровня.

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

    3. Сервер NHRP в ответ на запрос сообщит подходящий адрес канального уровня для передачи этой (и последующих) дейтаграммы адресату. Во время ожидания отклика от сервера NHRP система может передать дейтаграмму (дейтаграммы) «традиционному» маршрутизатору следующего интервала.

5.2.4.3 Адрес следующего интервала

Комментарии

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

Если пакет содержит SSRR, маршрутизатор должен отбросить пакет и передать его отправителю сообщение об ошибке ICMP Bad Source Route. В противном случае маршрутизатор ищет IP-адрес получателя в своей таблице маршрутизации для выбора следующего интервала пересылки.

Обсуждение

В соответствии со спецификацией протокола IP опция Strict Source Route должна содержать последовательность узлов, через которые должен проходить пакет (пакет передается от узла source route к следующему, проходя только через промежуточные сети). Таким образом, если маршрутизатор не является смежным со следующим узлом source route, заданный отправителем маршрут не может быть завершен. Следовательно, маршрутизатор будет отвергать такие пакеты, возвращая отправителю сообщение ICMP Bad Source Route.

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

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

При выборе для пакета следующего интервала маршрутизатор должен использовать приведенные ниже правила сокращения, за исключением правила 3 (Weak TOS). Если маршрутизатор использует значение TOS при выборе следующего интервала, правило 3 должно применяться с соблюдением приведенного здесь порядка. Эти правила должны быть (концептуально) применены к FIB в том порядке, как они представлены ниже (в силу исторических причин дополнительные правила сокращения и другой алгоритм выбора следующего интервала рассматриваются в приложении E.)

Обсуждение

Правило 3 является необязательным и в параграфе 5.3.2 сказано, что маршрутизатору лишь следует принимать во внимание значение TOS при выборе решения о пересылке.

  1. Базовое соответствие (Basic Match)

    Это правило отбрасывает все маршруты к адресату, отличающиеся от IP-адреса получателя для пакета. Например, если в пакете указан IP-адрес получателя 10.144.2.5, на этом этапе будет отброшен маршрут в сеть 128.12.0.0/16, но останутся любые маршруты в сети 10.0.0.0/8 и 10.144.0.0/16, а также принятые по умолчанию маршруты.

    Говоря более точно, мы предполагаем, что каждый маршрут имеет атрибут назначения (route.dest) и соответствующий ему размер префикса (route.length) для задания количества значимых битов в route.dest. IP-адрес получателя пересылаемого пакета – это ip.dest. Данное правило отбрасывает из набора кандидатов все маршруты, кроме тех, для которых route.length старших битов route.dest и ip.dest совпадают.

    Например, если IP-адрес получателя пакета 10.144.2.5 и имеются префиксы 10.144.1.0/24, 10.144.2.0/24 и 10.144.3.0/24, данное правило оставит только 10.144.2.0/24 (единственный маршрут, в котором 24 старших бита совпадают с 24 старшими битами IP-адреса получателя в пакете).

  2. Соответствие максимальной длины (Longest Match)

    Правило Longest Match является усовершенствованным вариантом правила Basic Match, описанного выше. После сокращения по правилу Basic Match, алгоритм проверяет оставшиеся маршруты для выбора пути с максимальным значением route.length. Все остальные маршруты отбрасываются.

    Например, если в пакете задан IP-адрес получателя 10.144.2.5 и остались префиксы 10.144.2.0/24, 10.144.0.0/16 и 10.0.0.0/8, среди них будет выбран префикс 10.144.2.0/24, поскольку для него длина соответствия является наибольшей.

  3. Наименьшие требования к TOS (Weak TOS)

    Каждый маршрут имеет атрибут типа обслуживания (route.tos), возможные значения которого совпадают со значениями, используемыми для поля TOS в заголовках IP. Протоколы маршрутизации, распространяющие информацию TOS, заполняют значения route.tos применительно к маршрутам, добавляемым в FIB. Маршруты от других протоколов маршрутизации трактуются как маршруты с принятым по умолчанию значением TOS (0000). Поле TOS в заголовке маршрутизируемого пакета будем обозначать ip.tos.

    Для набора кандидатов проверяется наличие среди них маршрутов, для которых route.tos = ip.tos. При наличии таких маршрутов все остальные маршруты отбрасываются. Если среди кандидатов такого маршрута нет, отбрасываются все маршруты, для которых значение route.tos отлично от нуля.

    Дополнительное обсуждение маршрутизации на базе правила Weak TOS можно найти в [ROUTE:11].

Обсуждение

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

  1. Наилучшая метрика (Best Metric)

    Каждый маршрут имеет атрибут метрики (route.metric) и идентификатор домена маршрутизации (route.domain). Каждый маршрут из множества кандидатов сравнивается с остальными маршрутами этого множества. Если для двух маршрутов значения route.domain совпадают, а значение route.metric для одного из маршрутов существенно «хуже», такой маршрут отбрасывается из числа кандидатов. Сравнение параметров метрики обычно сводится к простому арифметическому сравнению, хотя некоторые протоколы могут использовать структурированную метрику, требующую для сравнения более сложных операций.

  2. Политика производителя (Vendor Policy)

    Vendor Policy представляет собой «последний шанс» выбора маршрута, когда приведенные выше правила не позволили сделать такой выбор. Алгоритм сокращения Vendor Policy определяется производителем (см. параграф 5.2.4.4).

Описанный алгоритм имеет два существенных недостатка. Разработчики маршрутизаторов, по-видимому, смогут преодолеть эти недостатки и использовать свое решение как часть правила Vendor Policy.

  1. Классы маршрутов IS-IS и OSPF не обслуживаются напрямую.

  2. Отличные от типа обслуживания свойства пути (например, MTU) игнорируются.

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

Правила сокращения Basic Match и Longest Match выбирают маршруты с учетом их типа в том порядке, как показано ниже.

  1. Host Route (маршрут к хосту) – маршрут к указанной конечной системе.

  2. Hierarchical Network Prefix Routes (маршруты к иерархическим сетевым префиксам) – маршрут к отдельному сетевому префиксу. Отметим, что FIB может содержать несколько маршрутов к сетевым префиксам, которые являются частью других префиксов (один префикс представляет собой другой префикс, к которому добавлены биты). Эти префиксы выбираются в порядке уменьшения размера.

  3. Default Route (маршрут по умолчанию) – это путь во все сети, для которых не определено явных маршрутов. Такой маршрут можно определить как маршрут с префиксом нулевой длины.

Если после применения правил сокращения остается пустой набор маршрутов (ничего не найдено), пакет должен быть отброшен с передачей отправителю сообщения ICMP об ошибке (ICMP Bad Source Route, если IP-адрес получателя взят из опции source route, ICMP Destination Host Unreachable или Destination Network Unreachable в остальных случаях, в соответствии в правилами параграфа 4.3.3.1).

5.2.4.4 Административные предпочтения

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

Каждый маршрут получает уровень приоритета на основе различных атрибутов этого маршрута. Один из вариантов механизма установки уровней приоритета предложен ниже. Уровни приоритета выражаются целыми числами в диапазоне [0..255]. Значение 0 соответствует высшему приоритету, а 254 – низшему. Значение 255 устанавливается для маршрутов, которые никогда не следует использовать. На первом этапе правила сокращения Vendor Policy отбрасываются все маршруты, кроме тех, которые имеют высший приоритет. Маршруты с приоритетом 255 отбрасываются во всех случаях.

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

  • Address Match (соответствие адреса)

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

  • Route Class (класс маршрута)

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

  • Interface (интерфейс)

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

  • Source router (маршрутизатор-источник)

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

  • Originating AS (исходная АС)

    Для протоколов маршрутизации, обеспечивающих информацию об автономной системе, полезно иметь возможность установить одинаковый уровень предпочтения для всех маршрутов (полученных из одного домена маршрутизации), начинающихся из одного домена маршрутизации. Для маршрутов BGP исходная АС является первой автономной системой, указанной в атрибуте AS_PATH. Для внешних маршрутов OSPF в качестве исходной АС могут рассматриваться младшие 16 битов тега внешнего маршрута, если для тега установлен бит Automatic и значение Path Length отличается от 3.

  • External route tag (тег внешнего маршрута)

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

  • AS path (путь в АС)

    Полезно иметь возможность установить одинаковый уровень предпочтения для всех внешних маршрутов BGP (полученных из одного домена маршрутизации), для которых AS path «соответствует» любому набору заданных значений. Пока не ясно до конца, какой тип соответствия будет наиболее полезным. Простая опция позволяет выбирать все маршруты, где указанная АС присутствует (или, наоборот, отсутствует) в атрибуте AS_PATH. Более общий, но в некоторых случаях более сложный вариант, позволит выбирать все маршруты, для которых AS path соответствует заданному регулярному выражению.

5.2.4.5 Распределение нагрузки

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

5.2.5 Неиспользуемые биты заголовка IP – RFC 791, параграф 3.1

Заголовок IP включает несколько резервных битов в полях Type of Service и Flags. Для маршрутизаторов недопустимо отбрасывание пакетов на том лишь основании, что один или несколько резервных битов имеют ненулевое значение.

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

Обсуждение

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

5.2.6 Фрагментация и сборка – RFC 791, параграф 3.2

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

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

Обсуждение

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

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

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

5.2.7 Протокол ICMP

Общие требования для протокола ICMP были рассмотрены в главе 4.3. В последующих параграфах обсуждаются сообщения ICMP, которые передаются только маршрутизаторами.

5.2.7.1 Destination Unreachable

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

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

В документах [INTERNET:8] и [INTRO:2] определены перечисленные ниже коды ошибок.

0 = Network Unreachable (сеть недоступна) – генерируется маршрутизатором в тех случаях, когда путь в сеть адресата недоступен.

1 = Host Unreachable (хост недоступен) – генерируется маршрутизатором при недоступности маршрута к хосту сети, непосредственно подключенной к маршрутизатору (хост не отвечает на запросы ARP).

2 = Protocol Unreachable (протокол недоступен) – генерируется маршрутизатором в тех случаях, когда указанный в пакете транспортный протокол не поддерживается транспортным уровнем конечного получателя.

3 = Port Unreachable (порт недоступен) – генерируется маршрутизатором в тех случаях, когда указанный в заголовке пакета транспортный протокол (например, UDP) не способен демультиплексировать дейтаграмму на транспортный уровень конечного получателя и отсутствует протокольный механизм для информирования об этой ошибке отправителя.

4 = Fragmentation Needed and DF Set (требуется фрагментация, но установлен флаг DF) – генерируется маршрутизатором в тех случаях, когда ему требуется фрагментировать дейтаграмму, содержащую в заголовке флаг DF.

5 = Source Route Failed (невозможна указанная отправителем маршрутизация) – генерируется маршрутизатором в тех случаях, когда невозможно переслать пакет на следующий интервал, заданный опцией source route.

6 = Destination Network Unknown (неизвестна сеть адресата) – этот код не следует использовать в сообщениях, поскольку некоторые маршрутизаторы трактуют его как отсутствие сети адресата (взамен следует использовать код 0).

7 = Destination Host Unknown (получатель неизвестен) – генерируется только в тех случаях, когда маршрутизатор может определить (на канальном уровне), что хоста-адресата не существует.

11 = Network Unreachable For Type Of Service (сеть недоступна для заданного типа обслуживания) – генерируется маршрутизатором в тех случаях, когда путь в сеть адресата с запрошенным в заголовке или принятым по умолчанию значением TOS недоступен.

12 = Host Unreachable For Type Of Service (хост недоступен для заданного типа обслуживания) – генерируется маршрутизатором в тех случаях, когда отсутствует возможность пересылки пакета в результате того, что ни один из путей к адресату не соответствует указанному в пакете или принятому по умолчанию (0) значению TOS.

Здесь определяются несколько дополнительных кодов.

13 = Communication Administratively Prohibited (связь запрещена администратором) – генерируется в тех случаях, когда маршрутизатор не может переслать пакет по причине заданной администратором фильтрации.

14 = Host Precedence Violation (недопустимый уровень предпочтений) – передается первым маршрутизатором на пути доставки хосту-отправителю, чтобы показать недопустимость запрошенных предпочтений для данной комбинации «отправитель – получатель» (хосты или сети), протокола вышележащего уровня и порта отправителя/получателя.

15 = Precedence cutoff in effect (уровень предпочтений слишком низок) – сетевой оператор задал минимальный уровень предпочтений, а дейтаграмма была передана с более низким уровнем.

Примечание. В документе [INTRO:2] определен код 8 для изолированного хоста-отправителя. Маршрутизаторам не следует генерировать сообщения с кодом 8, взамен следует использовать код 0 (Network Unreachable) или 1 (Host Unreachable). В [INTRO:2] также определен код 9 (связь с сетью адресата запрещена административно) и 10 (связь с хостом-адресатом запрещена административно). Эти коды были предназначены для устройств сквозного шифрования, используемых в вооруженных силах США. Маршрутизаторам следует использовать определенный здесь код 13 (Communication Administratively Prohibited), если они фильтруют пакеты в соответствии с заданной администратором политикой.

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

Аналогично маршрутизаторы могут поддерживать конфигурационную опцию для запрета генерации сообщений с кодами 14 (Host Precedence Violation) и 15 (Precedence Cutoff in Effect). При включенной опции в ответ на пакеты с нарушением уровня предпочтений не будет передаваться никакого сообщения ICMP об ошибке.

Маршрутизаторы должны использовать код Host Unreachable или Destination Host Unknown, если другие хосты сети адресата продолжают быть доступными, поскольку в противном случае хост-отправитель может принять ошибочное решение о недоступности всей сети.

В документе [INTERNET:14] описана несколько отличающаяся модификация сообщений Destination Unreachable с кодом 4 (Fragmentation needed and DF set). При генерации сообщений Destination Unreachable с кодом 4 маршрутизатор должен использовать эту форму.

5.2.7.2 Redirect

Сообщения ICMP Redirect используются для того, чтобы сообщить локальному хосту о том, что ему следует использовать другой маршрутизатор next hop для определенного типа трафика.

Для маршрутизаторов недопустима генерация сообщений Redirect for Network или Redirect for Network and Type of Service (коды 0 и 2), описанных в [INTERNET:8]. Маршрутизаторы должны быть способны генерировать сообщения Redirect for Host (код 1) и следует также поддерживать генерацию сообщений Redirect for Type of Service and Host (код 3), описанных в [INTERNET:8].

Обсуждение

Если подключенная напрямую к маршрутизатору сеть не разделена на подсети (в классическом смысле), маршрутизатор может генерировать сообщения Network Redirect, применимые ко всем хостам заданной сети. Использование Network Redirect, а не Host Redirect может привести к некоторому снижению уровня трафика и занимаемого таблицей маршрутизации размера. Однако эта экономия невелика, а наличие подсетей порождает неоднозначность определения маски, используемой для интерпретации сообщений Network Redirect. В среде CIDR сложно точно указать случаи допустимости использования сообщений Network Redirect. Следовательно, маршрутизаторы должны передавать только сообщения Host (или Host and Type of Service) Redirect.

Сообщения с кодом 3 (Redirect for Host and Type of Service) генерируются в тех случаях, когда пакет, вызвавший перенаправление, имеет адресата, для которого путь, выбранный маршрутизатором, зависит (в частности) от запрошенного значения TOS.

Маршрутизаторы, генерирующие сообщения Redirect с кодом 3 (Host and Type of Service), должны иметь конфигурационную опцию (включенную по умолчанию), которая позволит генерировать сообщения с кодом 1 (Host) взамен сообщений с кодом 3. Маршрутизатор должен передавать сообщения Redirect с кодом 1 вместо сообщений Redirect с кодом 3, если конфигурация настроена соответствующим образом.

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

Для маршрутизаторов недопустима генерация сообщений Redirect, если не выполняются все перечисленные ниже условия:

  • пакет будет пересылаться в тот же физический интерфейс, через который он был принят;

  • IP-адрес отправителя в пакете относится к той же логической (под)сети, что и IP-адрес следующего интервала;

  • пакет не содержит опции IP source route.

Адрес отправителя в сообщениях ICMP Redirect должен относиться к той же логической (под)сети, что и адрес получателя.

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

Обсуждение

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

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

5.2.7.3 Time Exceeded

Маршрутизатор должен генерировать сообщения Time Exceeded с кодом 0 (In Transit), когда он отбрасывает дейтаграммы с истекшим временем жизни (поле TTL). Маршрутизатор может поддерживать для своих интерфейсов опции, отключающие генерацию таких сообщений на уровне интерфейса, но по умолчанию опции должны обеспечивать генерацию сообщений.

5.2.8 Протокол IGMP

Протокол IGMP [INTERNET:4] используется хостами и multicast-маршрутизаторами одной физической сети для включения хостов в группы и выхода из них. Multicast-маршрутизаторы используют сведения о принадлежности хостов к группам вместе с протоколами групповой маршрутизации для поддержки пересылки пакетов IP с групповой адресацией через Internet.

Маршрутизаторам следует реализовать связанную с multicast-маршрутизаторами часть протокола IGMP.

5.3 Конкретные вопросы

5.3.1 Время жизни

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

Когда маршрутизатор пересылает пакет, он должен уменьшить значение TTL по крайней мере на 1. Если обработка пакета занимает более 1 секунды, маршрутизатор может уменьшать значение TTL каждую секунду в процессе обработки.

Если значение TTL уменьшается до 0 (или меньше), пакет должен отбрасываться и, если пакет направлен не по групповому адресу, маршрутизатор должен генерировать сообщение ICMP Time Exceeded с кодом 0 (TTL Exceeded in Transit) для отправителя пакета. Отметим, что для маршрутизаторов недопустимо отбрасывание индивидуальных (unicast) или широковещательных (broadcast) пакетов IP с отличным от нуля значением TTL лишь на том основании, что данный маршрутизатор может предсказать завершение срока жизни пакета на другом маршрутизаторе по пути к конечному адресату. Однако маршрутизатор может отбрасывать пакеты, направленные по групповым адресам IP, с отличным от нуля временем жизни для более эффективной реализации алгоритма поиска по расширяющимся кольцам (см. [INTERNET:4]).

Обсуждение

Значение IP TTL используется (иной раз, шизофренически) в качестве ограничителя числа интервалов доставки и времени жизни пакета. Использование поля в качестве счетчика интервалов имеет важное значение для решения проблем маршрутизации, которые могут привести к утрате работоспособности сети при возникновении петли в маршрутизации. Функция ограничения времени жизни используется протоколами транспортного уровня (такими, как TCP), чтобы обеспечить гарантированную доставку данных. Многие современные реализации трактуют поле TTL исключительно как счетчик интервалов и часть сообщества Internet считает, что функции ограничения времени жизни пакетов должны быть реализованы в транспортных протоколах, которым такое ограничение требуется.

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

Категории групповой адресации IP (такие, как поиск по расширяющимся кругам) могут не работать в соответствии с ожиданиями, если значение TTL не будет трактоваться как счетчик интервалов. То же самое можно сказать о traceroute.

Сообщения ICMP Time Exceeded необходимы, поскольку диагностическая утилита traceroute не будет работать без них.

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

5.3.2 Тип обслуживания

Байт типа обслуживания (Type-of-Service или TOS) в заголовке IP делится на три части: поле предпочтений (Precedence – три старших бита), поле собственно TOS (следующие 4 бита) и резервное поле (младший бит). Правила обращения с резервным битом были описаны в параграфе 4.2.2.3. Поле предпочтений будет рассмотрено в параграфе 5.3.3. Более подробное обсуждение поля TOS и его использования можно найти в документе [ROUTE:11].

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

Маршрутизатор должен поддерживать значение TOS для каждого маршрута в своей таблице маршрутизации. Маршрутам, полученным от протоколов маршрутизации, которые не поддерживают TOS, должно присваиваться значение TOS=0 (принятое по умолчанию значение TOS).

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

  1. Найти в своей таблице маршрутизации все доступные пути к адресату (см. параграф 5.2.4).

  2. При отсутствии хотя бы одного пути отбросить пакет по причине недоступности адресата (см. параграф 5.2.4).

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

  4. При отсутствии таких маршрутов повторить п. 3 для поиска маршрутов с TOS = 0.

  5. Если на этапах 3 и 4 не было выбрано ни одного маршрута, пакет отбрасывается, поскольку адресат недоступен. Маршрутизатор возвращает отправителю сообщение об ошибке ICMP Destination Unreachable с соответствующим кодом – Network Unreachable with Type of Service (11) или Host Unreachable with Type of Service (12).

Обсуждение

Хотя поле TOS редко применялось в прошлом, сейчас его использование является обязательным в соответствии с требованиями к хостам документов [INTRO:2] и [INTRO:3]. Поддержка TOS в маршрутизаторах может стать обязательной в будущем, но ее следует реализовать уже сейчас.

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

  1. маршрутизатор может помещать пакеты с установленным битом Low Delay (малая задержка) впереди других пакетов в выходных очередях;

  2. маршрутизатор форсирует отбрасывание пакетов, что может предотвратить отбрасывание пакетов с установленным битом High Reliability.

Эти идеи более подробно рассматриваются в документе [INTERNET:17], но мы не имеем достаточного опыта для того, чтобы давать рекомендации по таким вопросам.

5.3.3 IP Precedence

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

Основным механизмом обработки уровня предпочтения в маршрутизаторах является преимущественное выделение ресурсов (включая управление очередями и контроль насыщения на основе уровня предпочтения) и выбор средств управления приоритизацией на канальном уровне. Маршрутизатор также выбирает уровень предпочтений для трафика протоколов маршрутизации, а также управления и контроля, порождаемого самим маршрутизатором. Более подробное рассмотрение параметров IP Precedence и реализации механизмов приводится в документе [FORWARD:6].

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

Обсуждение

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

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

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

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

5.3.3.1 Управление очередями на основе предпочтений

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

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

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

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

5.3.3.2 Отображение предпочтений нижележащего уровня

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

Маршрутизаторы, реализующие такое отображение:

  • должны быть способны отображать значение IP Precedence на приоритет канального уровня в тех случаях, когда последний поддерживает приоритизацию;

  • должны иметь конфигурационный параметр для выбора используемой по умолчанию трактовки приоритета канального уровня для всего трафика IP;

  • следует обеспечивать возможность настройки нестандартного отображения предпочтений IP на значения приоритета канального уровня для каждого интерфейса.

Обсуждение

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

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

Разработчики могут принимать во внимание, что корректное отображение предпочтений IP на приоритеты канального уровня требуется политикой DOD для систем TCP/IP, используемых в сетях Министерства обороны США. Поскольку эти требования были предназначены для поощрения (а не форсирования) использования механизма предпочтений в надежде на повышение качества сервиса Internet для всех пользователей, маршрутизаторам, поддерживающим управление очередями на основе предпочтений, следует по умолчанию обеспечивать строгое упорядочивание очередей на основе предпочтений, независимо от запрошенного типа обслуживания.

5.3.3.3 Обработка предпочтений для всех маршрутизаторов

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

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

  2. Могут реализовать фильтр для административного ограничения уровней предпочтения, используемых некоторыми источниками трафика. При наличии такого фильтра для него недопустима фильтрация сообщений ICMP об ошибках Destination Unreachable, Redirect, Time Exceeded и Parameter Problem. Для поддержки такого фильтра требуются также процедуры фильтрации пакетов по адресам.

Обсуждение

Фильтрацию по уровню предпочтения следует применять к заданным парам IP-адресов (отправитель-получатель), протоколам, портам и т. п.

Когда пакет отбрасывается фильтром, следует передавать отправителю сообщение ICMP Destination Unreachable с кодом 14, если генерация таких сообщений не отключена с помощью конфигурационных параметров.

  1. Могут реализовать функцию ограничения, которая позволяет установить на маршрутизаторе политику, отвергающую или отбрасывающую трафик с уровнем предпочтения ниже заданного. Эта функция может активизироваться административным путем или с помощью эвристических методов, но всегда должна поддерживаться опция для запрета всех эвристических механизмов, которые работают без участия человека. При отбрасывании пакетов функцией ограничения следует генерировать сообщения ICMP Destination Unreachable с кодом 15, если такая генерация не отключена с помощью конфигурационных параметров.

    Для маршрутизатора недопустимо отвергать пересылку дейтаграмм с полем предпочтения 6 (Internetwork Control) или 7 (Network Control) на основании лишь ограничения по уровню предпочтения. Однако в комбинации с другими критериями уровень предпочтения может использоваться для ограничения трафика даже с высокими уровнями предпочтения.

Обсуждение

Неограниченная фильтрация по уровню предпочтения может привести к отсечению трафика протоколов маршрутизации и сетевого управления. В общем случае для хостов следует ограничивать трафик по уровню предпочтения 5 (CRITIC/ECP) или ниже, но в некоторых системах такое требование может оказаться неприменимым.

  1. Недопустимо изменение уровня предпочтения для пакетов, источником которых данный маршрутизатор не является.

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

  3. Допускается настройка предпочтений для протоколов маршрутизации или управления независимо на каждом интерфейсе.

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

Обсуждение

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

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

Значение правил (5) и (6) (а также обсуждения IP Precedence в сообщениях ICMP в параграфе 4.3.2) состоит в том, что биты IP precedence следует устанавливать независимо от того, обрабатывает ли их данный маршрутизатор. Предполагается, что в будущих спецификациях протоколов маршрутизации и сетевого управления будут указаны требования по установке битов IP Precedence для сообщений, передаваемых с помощью этих протоколов.

Использование правила (7) зависит от протокола канального уровня. Обычно маршрутизатору следует прервать попытки передачи неприемлемого трафика для данного адресата на некоторый период и возвратить отправителю сообщение ICMP Destination Unreachable с кодом 15 (сервис недоступен для запрошенного уровня предпочтений). В течение некоторого времени также не следует пытаться восстановить прерванное соединение канального уровня.

5.3.4 Пересылка широковещательных пакетов канального уровня

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

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

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

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

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

5.3.5 Пересылка широковещательных пакетов уровня Internet (IP)

Существует два основных типа широковещательных адресов IP – limited broadcast (широковещание ограниченного действия) и directed broadcast (направленное широковещание). Кроме того, существуют три подтипа направленного широковещания – пакеты, направленные в сеть с указанным префиксом, пакеты, направленные в указанную подсеть, и пакеты во все подсети указанной сети. Отнесение маршрутизатором широковещательных пакетов к одной из перечисленных категорий зависит от самого широковещательного адреса и понимания маршрутизатором структуры (если таковая имеется) подсетей сети адресата. Один и тот же широковещательный пакет может по-разному классифицироваться различными маршрутизаторами.

IP-адрес ограниченного широковещания определяется как значение, состоящее только из единиц: { -1, -1 } или 255.255.255.255.

Адрес для широковещания в сеть с указанным префиксом состоит из префикса IP-сети, сопровождаемого локальной частью, содержащей только единицы, или { <Network-prefix>, -1 }. Например, широковещательный адрес для класса A будет иметь вид net.255.255.255, для класса B – net.net.255.255, а для класса C – net.net.net.255, где net задает байты префикса сети.

Направленное широковещание во все подсети (all-subnets-directed-broadcast) не определено в среде CIDR и использование таких адресов запрещено первой версией данного документа.

Как было сказано в параграфе 4.2.3.1, маршрутизатор может сталкиваться с нестандартной широковещательной адресацией IP:

  • 0.0.0.0 – устаревшая форма широковещательного адреса ограниченного действия;

  • { <Network-prefix>, 0 } – устаревшая форма широковещания, направленного в сеть с указанным префиксом (network-prefix-directed broadcast).

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

5.3.5.1 Широковещательная адресация ограниченного действия

Пакеты Limited broadcast недопустимо пересылать или отбрасывать. Пакеты Limited broadcast можно и следует передавать взамен directed broadcast, если ограниченного широковещания будет достаточно.

Обсуждение

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

5.3.5.2 Направленное широковещание

Маршрутизатор должен классифицировать, как направленные в указанную префиксом сеть широковещательные пакеты (Network-Prefix-Directed broadcast), все корректные пакеты directed broadcast, адресованные в удаленную сеть или непосредственно подключенную сеть, не разделенную на подсети. Отметим, что в CIDR такой адрес представляется адресом хоста в сети, заданной префиксом; мы устраняем проверку связанной с хостом части сетевого префикса. Поскольку задан маршрут и нет правил его отмены, маршрутизатор должен пересылать пакеты Network-Prefix-Directed broadcast. Маршрутизатор может передавать пакеты Network-Prefix-Directed broadcast.

Маршрутизатор может поддерживать опцию для запрета приема пакетов network-prefix-directed broadcast для интерфейса и должен иметь опцию для запрета пересылки пакетов network-prefix-directed broadcast. По умолчанию эти опции должны разрешать прием и пересылку широковещательных пакетов, адресованных в сеть с указанным префиксом9.

Обсуждение

Вопрос о пересылке или отказе от пересылки пакетов directed broadcast является в некоторой степени спорным. В данном документе решение о пересылке зависит от наличия у маршрутизатора информации о префиксе сети адресата. Маршрутизатор не может классифицировать сообщение как unicast или directed broadcast, если префикс сети не известен. Возникновение вопроса «пересылать – не пересылать» по определению возможно только на маршрутизаторе последнего интервала пересылки.

5.3.5.3 Широковещательные пакеты во все подсети (All-subnets-directed)

В первой версии этого документа описан алгоритм распределения пакетов directed broadcast во все подсети для классического10 номера сети. Сейчас такая рассылка считается «нарушением» и известны некоторые случаи отказов алгоритма.

В домене маршрутизации CIDR, где классические номера сетей IP не имеют смысла, концепция all-subnets-directed-broadcast (широковещательная передача во все подсети) также лишена смысла. По имеющейся у рабочей группы информации такой алгоритм рассылки ни разу не был реализован на практике и сейчас его можно рассматривать как достояние истории.

5.3.5.4 Широковещание, направленное в подсеть

В первой версии документа рассматривались процедуры обработки широковещательных пакетов, направленных в подсеть (subnet-directed-broadcast). В домене маршрутизации CIDR такие пакеты невозможно отличить от широковещательной передачи в сеть (net-drected-broadcast). Следовательно, такие пакеты должны трактоваться в соответствии с параграфом 5.3.5.2, как network-prefix directed broadcast.

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

Перегрузка в сети определяется как условия, когда запросы на выделение ресурсов (обычно полосы каналов или процессорного времени) превосходят реальные возможности. Механизмы предотвращения насыщения пытаются исключить возникновение таких ситуаций, а механизмы восстановления после перегрузки пытаются возобновить нормальную работу сети. Маршрутизаторы могут вносить свой вклад в работу обоих механизмов. На изучение проблем нехватки ресурсов было потрачено много сил. Рекомендуем читателям ознакомиться с документом [FORWARD:2], в котором приводится обзор работ в этом направлении. Важную информацию по вопросам насыщения содержат [FORWARD:3], [FORWARD:4], [FORWARD:5], [FORWARD:10], [FORWARD:11], [FORWARD:12], [FORWARD:13], [FORWARD:14], [INTERNET:10], а также ряд других работ.

Объем памяти, которая должна быть доступна на маршрутизаторе для обслуживания запросов при пиковой нагрузке, когда хосты используют подходящую политику контроля насыщения (например, описанную в [FORWARD:5]), является функцией от произведения полосы канала на величину задержки для использующего канал пути. Следовательно, объем памяти должен увеличиваться с ростом произведения Bandwidth*Delay. Точная функция, связывающая объем памяти с вероятностью отбрасывания пакетов при насыщении, неизвестна.

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

Маршрутизатор может отбросить только что полученный пакет – такое решение является простейшим, но отнюдь не лучшим. Идеальным решением будет выбор для отбрасывания пакета одной из наиболее загружающих канал сессий с учетом правил QoS11. Рекомендуемой политикой в среде дейтаграмм, использующей очереди FIFO, является отбрасывание пакетов, случайно выбранных из очереди (см. [FORWARD:5]). Эквивалентным алгоритмом для маршрутизаторов, использующих взвешенные очереди, будет выбор пакета из самой длинной очереди или той очереди, которая использует наибольшее виртуальное время (см. [FORWARD:13]). Маршрутизатор может использовать эти алгоритмы для выбора отбрасываемого пакета.

Если маршрутизатор использует политику отбрасывания (например, Random Drop12), в соответствии с которой он выбирает отбрасываемый пакет из некоторого пула подходящих пакетов:

  • при упорядочивании очереди по уровню предпочтений (см. параграф 5.3.3.1) для маршрутизатора недопустимо отбрасывание пакета, для которого уровень предпочтения в заголовке IP выше, чем у какого-либо из остающихся пакетов;

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

  • маршрутизатор может защитить от отбрасывания фрагментированные пакеты IP, основываясь на теории о том, что отбрасывание фрагмента дейтаграммы может повысить уровень перегрузки за счет того, что отправитель будет повторно передавать все фрагменты;

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

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

Как описано в параграфе 4.3.3.3, этот документ не рекомендует маршрутизаторам передавать сообщений Source Quench отправителям отброшенных пакетов. Механизм ICMP Source Quench весьма малоэффективен и нет нужды использовать его в маршрутизаторах, а хостам не следует активно применять этот механизм для индикации насыщения.

5.3.7 Фильтрация непригодных адресов

IP-адрес отправителя является непригодгым, если он относится к числу специальных адресов IP, указанных в параграфах 4.2.2.11 и 5.3.7, или не является индивидуальным адресом.

IP-адрес получателя является непригодгым, если он относится к тем адресам, которые указаны, как недопустимые для получателя в параграфе 4.2.3.1, или адресам класса E (за исключением 255.255.255.255).

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

Маршрутизатору не следует пересылать какие-либо пакеты, в которых указан непригодгым адрес получателя, или пакеты, направленные в сеть 0. Маршрутизатору не следует пересылать какие-либо пакеты, адресованные в сеть 127, за исключением пакетов, пересылаемых через интерфейс loopback. Маршрутизатор может иметь параметр, который позволяет администратору отключить такие проверки, но по умолчанию эти проверки должны выполняться.

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

5.3.8 Проверка адреса отправителя

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

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

Обсуждение

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

5.3.9 Фильтрация пакетов и списки доступа

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

Обсуждение

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

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

  • включенные (Include) – список определений, в соответствии с которым сообщения будут пересылаться;

  • исключенные (Exclude) – список определений, в соответствии с которым сообщения не будут пересылаться.

«Определение» в данном контексте включает префиксы адресов отправителей/получателей и может также включать другие параметры (например, тип протокола IP или номер порта TCP).

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

Для адресов отправителей/получателей должно поддерживаться значение (например, any – любой, адрес с маской, содержащей только нули, или префикс нулевой длины), которому будут соответствовать любые адреса.

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

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

Маршрутизаторам следует обеспечивать возможность передачи соответствующих сообщений ICMP о недоступности при отбрасывании пакетов. В сообщениях ICMP следует указывать Communication Administratively Prohibited (код 13) в качестве причины недоступности адресата.

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

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

5.3.10 Групповая маршрутизация

Маршрутизаторам IP следует поддерживать пересылку групповых пакетов IP на основе статических таблиц групповой маршрутизации или динамических маршрутов, полученных от протоколов групповой маршрутизации (например, DVMRP [ROUTE:9]). Маршрутизаторы, поддерживающие пересылку групповых пакетов IP, называют multicast-маршрутизаторами.

5.3.11 Управление пересылкой

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

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

  • недопустимо передавать пакеты через этот интерфейс за исключением пакетов, созданных самим маршрутизатором;

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

Обсуждение

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

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

5.3.12 Смена состояний

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

5.3.12.1 Прекращение пересылки

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

Обсуждение

Когда маршрутизатор прекращает пересылку, он перестает быть маршрутизатором. Продолжая оставаться хостом, он должен соответствовать требованиям документа Host Requirements [INTRO:2]. Однако маршрутизатор может оставаться пассивным участником одного или нескольких доменов маршрутизации. Поэтому маршрутизатор может продолжать поддержку базы данных о маршрутах, прослушивая другие маршрутизаторы в своем домене маршрутизации. Однако в таких случаях маршрутизатор не имеет права анонсировать какие-либо маршруты из своей таблицы, поскольку он не поддерживает пересылку пакетов. Единственным исключением из этого правила является анонсирование маршрута, который использует только другой маршрутизатор, по запросу последнего.

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

Обсуждение

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

5.3.12.2 Начало пересылки

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

5.3.12.3 Интерфейс отключен или произошел отказ

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

5.3.12.4 Интерфейс включен

При включении недоступного ранее интерфейса маршрутизатор должен заново включить все связанные с этим интерфейсом статические маршруты. Если маршруты, которые будут использовать этот интерфейс, становятся известны маршрутизатору, эти маршруты должны быть оценены в сравнении со всеми другими известными маршрутизатору путями и маршрутизатор должен принять решение о выборе пути для включения в свою таблицу маршрутизации. Разработчикам следует использовать рекомендации раздела «7. Прикладной уровень – протоколы маршрутизации» для реализации механизма выбора маршрута.

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

5.3.13 Опции IP

Некоторые опции (такие, как Record Route и Timestamp), включают «гнезда», куда маршрутизатор записывает свой адрес при пересылке пакета. Однако каждая такая опция имеет ограниченное пространство «гнезд» и маршрутизатор может столкнуться с проблемой отсутствия свободного места в опции для записи своего адреса. Ни одно из перечисленных ниже требований не следует трактовать как необходимость записи адреса в опцию при отсутствии в ней свободного места. В параграфе 5.2.5 обсуждается вопрос выбора маршрутизатором адреса для записи в опцию.

5.3.13.1 Неизвестные опции

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

5.3.13.2 Опция безопасности (Security)

Некоторые среды требуют наличия опции Security в каждом пакете, такие требования выходят за пределы данного документа и спецификации стандарта IP. Отметим однако, что опции безопасности, описанные в документах [INTERNET:1] и [INTERNET:16], устарели. В маршрутизаторах следует реализовать поддержку обновленной опции безопасности, которая описана в [INTERNET:5].

Обсуждение

Маршрутизаторы, предназначенные для использования в сетях со множеством уровней защиты, должны поддерживать фильтрацию пакетов на основе меток IPSO (RFC 1108). Для реализации этого маршрутизатор должен позволять администратору задавать нижний (например, Unclassified – не классифицируется) и верхний (например, Secret – секретно) предел для каждого интерфейса. Достаточно часто (но не всегда) значения пределов могут совпадать (например, интерфейс с одним уровнем). Пакеты, которые фильтр IPSO классифицировал, как выходящие за пределы заданного диапазона, следует отбрасывать без уведомления, следует также поддерживать счетчик таких отброшенных пакетов.

5.3.13.3 Опция идентификатора потока (Stream Identifier)

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

5.3.13.4 Опции Source Route

Маршрутизаторы должны реализовать поддержку опции source route в пересылаемых пакетах. Маршрутизатор может иметь конфигурационный параметр, включающий отбрасывание всех пакетов с опцией source route, однако недопустимо такое отбрасывание по умолчанию.

Обсуждение

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

Комментарии редактора

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

5.3.13.5 Опция записи маршрута (Record Route)

Маршрутизаторы должны поддерживать опцию записи маршрута (Record Route) для пересылаемых пакетов.

Маршрутизатор может поддерживать конфигурационный параметр, который будет заставлять маршрутизатор игнорировать опции Record Route в пересылаемых пакетах. При наличии такого параметра по умолчанию опция записи маршрута должна обрабатываться маршрутизатором. Этот параметр не должен оказывать влияния на обработку опций Record Route в пакетах, полученных самим маршрутизатором (в частности, опция Record Route в запросах ICMP echo должна по-прежнему обрабатываться в соответствии с параграфом 4.3.3.6).

Обсуждение

Некоторые люди полагают, что опция Record Route ведет к снижению уровня безопасности, поскольку она раскрывает информацию о топологии сети. Данный документ позволяет отключить на маршрутизаторе обработку опции.

5.3.13.6 Опция Timestamp

Маршрутизаторы должны поддерживать в пересылаемых пакетах опцию timestamp (временная метка). Значение метки должно соответствовать правилам, указанным в документе [INTRO:2].

Если поле флагов имеет значение 3 (timestamp и указанный заранее адрес), маршрутизатор должен добавить свою временную метку, если указанный следующим адрес соответствует какому-либо из IP-адресов маршрутизатора. Не обязательно совпадение указанного адреса с адресом получившего пакет интерфейса или интерфейса, через который пакет будет передаваться.

Реализация

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

Маршрутизатор может поддерживать конфигурационный параметр, который будет приводить к игнорированию опции Timestamp в пересылаемых дейтаграммах, когда слово флагов имеет значение 0 (только временная метка) или 1 (временная метка и зарегистрированный адрес IP). При поддержке маршрутизатором такого параметр последний должен быть отключен по умолчанию (т. е., маршрутизатор не должен игнорировать опцию timestamp). Этот параметр не должен влиять на обработку опций Timestamp в дейтаграммах, полученных самим маршрутизатором (в частности, опции Timestamp в адресованных маршрутизатору дейтаграммах и запросах ICMP будут по-прежнему обрабатываться в соответствии с параграфом 4.3.3.6).

Обсуждение

Подобно опции Record Route опция Timestamp может раскрывать информацию о топологии сети. Некоторые люди считают это небезопасным.

1Reverse path forwarding – пересылка по обратному пути. Прим. перев.

2IPv6 в современной терминологии. Прим. перев.

3Ultimate Destination Address.

4Immediate Destination.

5Данному маршрутизатору. Прим. перев.

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

7Next Hop Routing Protocol.

8Министерство обороны США.

9В RFC 2644 этот абзац выражен в иной формулировке: «Маршрутизатор может иметь опцию, разрешающую прием широковещательных пакетов для заданной префиксом сети (network-prefix-directed broadcast) на уровне интерфейсов и может иметь опцию для разрешения пересылки таких пакетов. Эти опции по умолчанию должны быть отключены, чтобы блокировать прием и передачу пакетов network-prefix-directed broadcast.» Прим. перев.

10Не CIDR. Прим. перев.

11Quality of Service – качество обслуживания.

12Случайный выбор пакета для отбрасывания.

Часть 3

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or