RFC 1812 (часть 3)

Please enter banners and links.

image_print

Часть 2

6. Транспортный уровень

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

6.1 Протокол UDP

Спецификация протокола UDP сдержится в документе [TRANS:1].

Маршрутизатор, поддерживающий протокол UDP, должен быть совместимым со спецификацией и следует делать маршрутизаторы безусловно совместимыми с требованиями [INTRO:2], за исключением перечисленных ниже случаев.

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

  • В отличие от требований документа [INTRO:2] приложениям не следует отключать генерацию контрольных сумм UDP.

Обсуждение

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

6.2 Протокол TCP

Спецификация протокола TCP содержится в документе [TRANS:2].

Маршрутизатор, поддерживающий протокол TCP, должен быть совместимым со спецификацией и следует делать маршрутизаторы безусловно совместимыми с требованиями [INTRO:2], за исключением перечисленных ниже случаев.

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

    Использование флага Push – RFC 793, параграф 2.8

    Передача полученного флага PSH на прикладной уровень является необязательной.

    Urgent Pointer – RFC 793, параграф 3.1

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

TCP Connection Failures (отказы в соединениях)

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

TCP Multihoming (многодомные хосты)

Если приложение на многодомном хосте не задает локальный адрес IP при активном открытии соединения TCP, уровень TCP должен запросить у уровня IP выбор локального адреса IP до передачи (первого) пакета SYN. См. описание функции GET_SRCADDR() в параграфе 3.4 документа [INTRO:2].

Опции IP

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

  • По аналогичным причинам от маршрутизаторов не требуется соответствия любому из требований [INTRO:2].

  • Требования, касающиеся опции Maximum Segment Size в [INTRO:2], следует трактовать следующим образом: маршрутизатор, поддерживающий связанную с хостами часть MTU (см. параграф 4.2.3.3 настоящего документа), использует по умолчанию SendMSS=536 только в тех случаях, когда неизвестно значение path MTU, при известном path MTU значение SendMSS = path MTU – 40.

  • Требования, касающиеся опции Maximum Segment Size в [INTRO:2], следует трактовать следующим образом: сообщения ICMP Destination Unreachable с кодами 11 и 12 указывают на дополнительные программные ошибки. Поэтому такие сообщения недопустимо использовать в качестве причины для разрыва соединений TCP.

    Обсуждение

    Следует отметить, что реализация TCP в маршрутизаторах должна соответствовать следующим требованиям [INTRO:2]:

  • обеспечивать настраиваемое значение TTL [Time to Live: RFC 793, параграф 3.9];

  • обеспечивать интерфейс для настройки поведения keep-alive (если пакеты keep-alive применяются [TCP Keep-Alive];

  • обеспечивать механизм передачи сообщений об ошибках и возможность управления этим механизмом [Asynchronous Reports];

  • обеспечивать возможность выбора типа обслуживания [Type-of-Service].

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

7. Прикладной уровень – протоколы маршрутизации

7.1 Введение

В силу технических, административных и политических причин система маршрутизации Internet состоит из двух компонент – внутренняя и внешняя маршрутизация. Концепция автономной системы (AS), как определено в параграфе 2.2.4, играет ключевую роль в разделении внутренней и внешней маршрутизации. Эта концепция позволяет обозначить набор маршрутизаторов, где происходит переход от внутренней маршрутизации к внешней. Дейтаграмма IP может проходить через маршрутизаторы двух и более AS на пути к адресату и автономные системы должны обеспечивать друг друга топологической информацией, позволяющей организовать пересылку дейтаграмм. Протоколы внутренней маршрутизации (Interior gateway protocol или IGP) служат для распространения маршрутной информации внутри AS (для маршрутизации внутри AS), а протоколы внешней маршрутизации (Exterior gateway protocol или или EGP) служат для обмена маршрутной информацией между AS (маршрутизации между автономными системами).

7.1.1 Вопросы безопасности маршрутизации

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

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

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

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

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

7.1.2 Предпочтения

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

Обсуждение

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

7.1.3 Проверка корректности сообщений

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

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

Обсуждение

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

7.2 Протоколы внутренней маршрутизации

7.2.1 Введение

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

  1. быстрая реакция на изменения внутренней топологии AS;

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

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

  4. минимальный расход полосы;

  5. поддержка равноценных маршрутов для распределения нагрузки;

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

Используемые сегодня протоколы IGP можно разделить на протоколы, основанные на алгоритмах distance-vector (вектор удаленности) и link-state (состояние канала).

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

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

7.2.2 Протокол OSPF

Протоколы маршрутизации на основе выбора кратчайшего пути (Shortest Path First или SPF) представляют собой класс алгоритмов выбора пути с учетом состояния каналов, основанных на алгоритме Dijkstra. Хотя протоколы на основе SPF использовались еще в сети ARPANET, они лишь сравнительно недавно приобрели популярность в средах IP и OSI. В системах на основе SPF каждый маршрутизатор получает полную информацию о топологии в процессе лавинной рассылки, обеспечивающей гарантированную доставку данных. После получения информации каждый маршрутизатор использует алгоритм SPF для построения таблицы маршрутизации IP. Протокол маршрутизации OSPF является одной из реализаций алгоритма SPF. Современная версия протокола OSPF v2 описана в документе [ROUTE:1]. Отметим, что документ RFC 1131, в котором содержится спецификация первой версии протокола OSPF, утратил силу.

Отметим, что для выполнения требований параграфа 8.3 маршрутизаторы, поддерживающие протокол OSPF, должны поддерживать также OSPF MIB [MGT:14].

7.2.3 Протокол обмена между промежуточными системами – DUAL IS-IS

Комитет ANSI1 X3S3.3 разработал протокол внутридоменной маршрутизации, получивший название Intermediate System to Intermediate System Routeing Exchange Protocol2.

Применение этого протокола в сетях IP описано в документе [ROUTE:2], где протокол назван Dual IS-IS (иногда его называют Integrated IS-IS). Протокол IS-IS основан на алгоритме SPF и обладает всеми преимуществами этого класса протоколов.

7.3 Протоколы внешней маршрутизации

7.3.1 Введение

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

Сфера применения таких протоколов является предметом изучения IETF. Протокол EGP (Exterior Gateway Protocol), описанный в Приложении F.1 традиционно использовался для обмена маршрутной информацией между AS, но сейчас он стал достоянием истории. Протокол BGP3 лишен множества ограничений и недостатков EGP и быстро приобретает популярность. От маршрутизаторов не требуется реализации протоколов маршрутизации между AS. Однако, если маршрутизатор поддерживает EGP, он также должен поддерживать протокол BGP. Хотя протокол RIP (см. параграф Приложение F.24) и не предназначен для внешней маршрутизации, он иногда используется в качестве протокола маршрутизации между AS.

7.3.2 Протокол граничного шлюза BGP

7.3.2.1 Введение

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

Протокол BGP определен в документе [ROUTE:4]. Документ [ROUTE:5] описывает использование BGP в Internet и содержит рекомендации для разработчиков. В документах [ROUTE:12] и [ROUTE:13] можно найти дополнительную информацию о протоколе.

В соответствии с требованиями параграфа 8.3 маршрутизатор, поддерживающий протокол BGP, должен также поддерживать BGP MIB [MGT:15].

Чтобы охарактеризовать набор решений в части политики, которые могут быть приняты с использованием BGP, следует сфокусироваться на правиле, по которому AS анонсирует в соседние AS только те маршруты, которые данная AS использует сама. Это правило отражает парадигму поэтапной маршрутизации, используемую в сети Internet. Отметим, что некоторые правила могут не поддерживаться этой парадигмой и будут требовать использования иных механизмов (например, задаваемой отправителем маршрутизации – source routing). В частности, BGP не позволяет AS передавать в соседнюю AS трафик в предположении, что та будет пересылать этот трафик по маршруту, отличающемуся от пути для трафика, происходящего из данной AS. С другой стороны, BGP может поддерживать любые правила, согласующиеся с парадигмой поэтапной маршрутизации.

Разработчикам BGP настоятельно рекомендуется строго следовать рекомендациям, приведенным в главе 6 документа [ROUTE:5].

7.3.2.2 Протокол Walk-through

Хотя протокол BGP позволяет реализовать достаточно сложные варианты политики маршрутизации (см., например, параграф 4.2 в [ROUTE:5]), поддержка сложной политики не требуется от всех реализаций BGP. Однако любая реализация BGP должна удовлетворять приведенным ниже требованиям.

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

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

  3. Следует позволять AS игнорировать маршруты с некоторыми AS в атрибуте AS_PATH. Такая функция может быть реализована с использованием метода, указанного в п. (2), когда нежелательным AS присваивается бесконечный вес. Процесс выбора маршрута должен игнорировать пути с бесконечным весом.

7.3.3 Маршрутизация между AS без использования протоколов EGP

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

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

7.4 Статическая маршрутизация

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

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

  • TOS;

  • маски подсетей;

  • размеры префиксов;

  • метрику протокола маршрутизации, который может импортировать маршрут.

Обсуждение

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

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

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

      route 10.0.0.0/8 via 192.0.2.3 rip metric 3
      route 10.21.0.0/16 via 192.0.2.4 ospf inter-area metric 27
      route 10.22.0.0/16 via 192.0.2.5 egp 123 metric 99

Обсуждение

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

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

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

  1. базовое соответствие (Basic match);

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

  3. минимальное значение TOS (если TOS поддерживается);

  4. лучшая метрика (метрика зависит от реализации).

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

7.5 Фильтрация маршрутной информации

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

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

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

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

Приведенные здесь требования к фильтрации относятся только к протоколам, не использующим SPF, и никак не связаны с маршрутизаторами, которые не используют протоколы типа distance vector.

7.5.1 Проверка маршрута

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

7.5.2 Базовая фильтрация маршрутов

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

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

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

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

  • другие маршрутизаторы, от которых будет приниматься маршрутная информация.

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

7.5.3 Расширенная фильтрация маршрутов

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

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

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

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

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

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

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

Обсуждение

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

Данные для маршрутов, которые маршрутизатор не использует (информация от маршрутизатора S в предыдущем примере) недопустимо передавать другим маршрутизаторам.

7.6 Обмен информацией протоколов внешней маршрутизации

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

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

Обсуждение

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

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

Двухсторонний обмен маршрутной информацией может представлять опасность при отсутствии механизма контроля за обратной связью. Это та же проблема, которая возникает в протоколах на основе «вектора удаленности» и решается с помощью «расщепления горизонта» (split horizon), а в протоколах EGP – с помощью правила «третьих рук». Маршрутные петли можно предотвратить явно за счет использования таблиц или списков разрешенных/запрещенных маршрутов или неявно с помощью использования split horizon, отказа от информации из «третьих рук» или установки меток для маршрутов. Разработчикам рекомендуется применять неявные механизмы, позволяющие упростить администрирование для сетевых операторов.

8. Прикладной уровень – протоколы управления сетью

Этот раздел содержит требования, которые являются более важными по сравнению с требованиями раздела REMOTE MANAGEMENT6 в документе [INTRO:3].

8.1 Протокол SNMP

8.1.1 Элементы протокола SNMP

Маршрутизаторы должны поддерживать управление по протоколу SNMP [MGT:3]. Протокол SNMP должен работать с использованием UDP/IP в качестве протоколов транспортного и сетевого уровня. Возможна поддержка других протоколов управления (см., например, [MGT:25, MGT:26, MGT:27, and MGT:28]). Управление по протоколу SNMP должно работать так, будто протокол SNMP реализован в самом маршрутизаторе. В частности, должно обеспечиваться воздействие на работу системы управления путем передачи запросов SNMP по любому из адресов IP, присвоенных интерфейсам маршрутизатора. Реальное управление может выполняться маршрутизатором или прокси-агентом для маршрутизатора.

Обсуждение

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

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

Должны быть реализованы все операции SNMP (get, get-next, get-response, set и trap).

Маршрутизаторы должны обеспечивать механизм ограничения скорости генерации сообщений SNMP trap. Маршрутизаторы могут обеспечивать такой механизм с помощью алгоритма асинхронной передачи сигналов управления, описанного в [MGT:5].

Обсуждение

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

8.2 Таблица групп

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

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

Обсуждение

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

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

Маршрутизаторы должны позволять пользователю вручную (т. е., без использования SNMP) проверять, добавлять, удалять и изменять записи в таблице групп SNMP. Пользователю должна обеспечиваться возможность установки имени группы или создания представления MIB. Пользователю должна предоставляться возможность настройки группы как read-only (не допускаются операции SET) или read-write (допускаются операции SET).

Пользователю должна обеспечиваться возможность определить хотя бы один адрес IP, по которому будут передаваться уведомления для каждой группы или представления MIB, если используется механизм trap. Эти адреса следует задавать независимо для групп SNMP или представлений MIB. Следует обеспечить возможность включения и выключения передачи уведомлений для группы или представления MIB.

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

Обсуждение

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

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

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

Обсуждение

По умолчанию генерация сообщений trap для группы public отключена. Trap PDU передаются по индивидуальным адресам IP. Эти адреса должны настраиваться в маршрутизаторе. До того, как адрес будет задан администратором, сообщения trap посылать просто некуда. Следовательно, передача сообщений trap для группы public по умолчанию должна быть отключена. Естественно, что администратор может включить генерацию таких сообщений при настройке маршрутизатора.

8.3 Стандартные MIB

В маршрутизаторах реализуются все MIB, относящиеся к маршрутизаторам:

  • должны быть реализованы группы MIB-II [MGT:2] System, Interface, IP, ICMP и UDP;

  • требуется реализация Interface Extensions MIB [MGT:18];

  • требуется реализация IP Forwarding Table MIB [MGT:20];

  • если маршрутизатор реализует TCP (например, для Telnet), требуется реализация группы MIB-II [MGT:2] TCP.;

  • если маршрутизатор реализует EGP, требуется реализация группы MIB-II [MGT:2] EGP;

  • если маршрутизатор поддерживает OSPF, требуется реализация OSPF MIB [MGT:14];

  • если маршрутизатор поддерживает BGP, требуется реализация BGP MIB [MGT:15];

  • если маршрутизатор имеет интерфейс Ethernet, 802.3 или StarLan, требуется реализация Ethernet-Like MIB [MGT:6];

  • если маршрутизатор имеет интерфейс 802.4, требуется реализация 802.4 MIB [MGT:7];

  • если маршрутизатор имеет интерфейс 802.5, требуется реализация 802.5 MIB [MGT:8];

  • если маршрутизатор имеет интерфейс FDDI, который реализует ANSI SMT 7.3, требуется реализация FDDI MIB [MGT:9];

  • если маршрутизатор имеет интерфейс FDDI, который реализует ANSI SMT 6.2, требуется реализация FDDI MIB [MGT:29];

  • если маршрутизатор имеет интерфейс, который использует сигнализацию V.24 (например, RS-232, V.10, V.11, V.35, V.36 или RS-422/423/449), требуется реализация RS-232 MIB [MGT:10];

  • если маршрутизатор имеет интерфейс T1/DS1, требуется реализация T1/DS1 MIB [MGT:16];

  • если маршрутизатор имеет интерфейс T3/DS3, требуется реализация T3/DS3 MIB [MGT:17];

  • если маршрутизатор имеет интерфейс SMDS, требуется реализация SMDS Interface Protocol MIB [MGT:19];

  • если маршрутизатор поддерживает протокол PPP на любом из своих интерфейсов, требуется реализация PPP MIB [MGT:11], [MGT:12] и [MGT:13];

  • если маршрутизатор поддерживает протокол RIP версии 2, требуется реализация RIP Version 2 MIB [MGT:21];

  • если маршрутизатор поддерживает протокол X.25 на любом из своих интерфейсов, требуется реализация X.25 MIB [MGT:22, MGT:23 и MGT:24].

8.4 MIB от производителей

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

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

Обсуждение

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

Производителям следует обеспечивать спецификации для всех переменных Vendor Specific MIB. Эти спецификации должны соответствовать SMI [MGT:1], а описания должны быть выполнены в формате, указанном в документе [MGT:4].

Обсуждение

Доступность Vendor Specific MIB для пользователей является насущной необходимостью. Без такой информации пользователи не смогут настроить свои системы сетевого управления для использования параметров фирменных расширений MIB и параметры останутся бесполезными.

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

8.5 Сохранение изменений

Параметры, измененные с помощью SNMP, могут сохраняться в энергонезависимой памяти.

Обсуждение

Причины того, что это требование имеет уровень «могут», следующие:

  • Физическая природа энергонезависимой памяти не задается данным документом. Следовательно, параметры могут сохраняться в микросхемах NVRAM/EEPROM, на локальных дисках (съемных или фиксированных), в файлах на серверах TFTP, BOOTP и т. п. Предположим, что информация хранится в файле, доступном по протоколу TFTP. В этом случае изменение конфигурационных параметров на маршрутизаторе будет требовать копирования этих параметров на сервер. Возможно также редактирование конфигурационного файла на сервере с последующим копированием его на маршрутизатор. Решение этой проблемы не представляется очевидным.

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

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

9. Прикладной уровень – прочие протоколы

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

9.1 BOOTP

9.1.1 Введение

Протокол BOOTP7 работает на основе UDP/IP и позволяет при загрузке хостов получать конфигурационные параметры с сервера без участия оператора. BOOTP обеспечивает для хоста уведомление о выделенном ему адресе IP, адресе сервера загрузки и имени файла для загрузки в память хоста и последующего исполнения ([APPL:1]). С помощью протокола BOOTP возможна также установка для хоста других конфигурационных параметров, включая локальный размер сетевого префикса или маску подсети, локальное время, адреса используемых по умолчанию маршрутизаторов и адреса различных серверов Internet ([APPL:2]).

9.1.2 Агенты BOOTP Relay

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

Обсуждение

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

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

Маршрутизатор может выполнять функции транслятора BOOTP. Если такие функции реализованы, маршрутизатор должен соответствовать требованиям спецификации [APPL:3].

В параграфе 5.2.3 рассматривалась ситуация, когда пакет доставляется локально (маршрутизатору). Все локально доставляемые пакеты UDP, адресованные в порт BOOTPS (67), передаются для специальной обработки логическому транслятору BOOTP в маршрутизаторе.

В параграфах 4.2.2.11 и 5.3.7 обсуждались непригодные IP-адреса отправителей. Согласно приведенным правилам, для маршрутизатора недопустима пересылка дейтаграмм IP с адресом отправителя 0.0.0.0. Однако маршрутизаторы, поддерживающие функции транслятора BOOTP, должны принимать для локальной доставки сообщения BOOTREQUEST с IP-адресом отправителя 0.0.0.0.

10. Эксплуатация и обслуживание

Приведенные в этом разделе требования имеют более высокий приоритет для маршрутизаторов, нежели требования, документа [INTRO:3], относящиеся к расширению модуля IP.

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

10.1 Введение

Операции O&M для маршрутизаторов включают:

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

  • установку нового оборудования;

  • инсталляцию новых программ;

  • перезагрузку маршрутизатора после аварий;

  • настройку маршрутизатора и изменение его конфигурации;

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

  • изменение топологии сети – временное (например, на период решения проблем) или постоянное;

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

  • сбор статистики трафика для ее использования при планировании сети;

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

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

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

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

Обсуждаемые здесь функции O&M являются лишь частью большой и сложной задачи управления Internet. В управление вовлечено не только множество организаций, но и протоколы различных уровней. Например, на современном этапе развития архитектуры Internet существует сильная зависимость между реализациями TCP на хостах и возможным насыщением на уровне IP в системах маршрутизации [OPER:1]. Следовательно, диагностика проблем насыщения будет в некоторых случаях требовать мониторинга статистики TCP на хостах. В настоящее время ведутся интенсивные исследования по вопросам управления Internet и, в частности, функций O&M в маршрутизаторах. Эти исследования уже привели к разработке стандартов для O&M в маршрутизаторах. В этой сфере может оказаться весьма значительным также вклад разработчиков.

10.2 Инициализация маршрутизатора

10.2.1 Начальная настройка маршрутизатора

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

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

  2. маршрутизатор знает, что данный интерфейс является безадресным (unnumbered) и известен адрес router-id.

Для этих параметров должны явно выполняться следующие требования:

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

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

Обсуждение

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

10.2.2 Инициализация адреса и префикса

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

Маршрутизатор может получать свои IP-адреса и соответствующие им маски динамически в процессе инициализации системы (см. параграф 10.2.3).

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

Как было сказано в параграфе 4.2.2.11, адреса IP не должны иметь значение 0 или -1 в полях <Номер хоста> и <Префикс сети>. Поэтому маршрутизаторам не следует позволять установку таких адресов или масок, которые нарушали бы данное правило.

Обсуждение

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

Маршрутизатору следует выполнять перечисленные здесь проверки для всех задаваемых масок:

  • маска не должна состоять только из единиц или только из нулей (префикс сети не может иметь размер 0 или 32);

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

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

Обсуждение

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

10.2.3 Загрузка через сеть с использованием протоколов BOOTP и TFTP

Было много дискуссий о том, как можно и следует загружать маршрутизаторы через сеть. Эти дискуссии велись в основном о протоколах BOOTP и TFTP. Сегодня существуют маршрутизаторы, использующие протокол TFTP для загрузки через сеть. Нет причин, которые не позволяли бы использовать протокол BOOTP для поиска сервера, с которого следует взять загрузочный образ.

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

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

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

10.3 Эксплуатация и обслуживание

10.3.1 Введение

Существует множество моделей реализации функций O&M в маршрутизаторах. Один из полярных вариантов обеспечивает лишь возможность локального выполнения функций O&M (например, с помощью терминала, подключенного к маршрутизатору). Другим крайним случаем является модель, поддерживающая лишь удаленный режим с минимальном набором функций, которые должны быть выполнены локально (например, инициирование загрузки), и полным набором функций O&M, выполняемых из NOC. Существуют также промежуточные модели, в которых персонал NOC может подключиться к маршрутизатору, как к хосту, используя протокол Telnet, для выполнения функций, которые доступны также локально. Модель, обеспечивающая только локальный доступ, может подходить для сетей с небольшим числом маршрутизаторов, но обычно маршрутизаторы обслуживаются удаленно из NOC и поэтому для большинства маршрутизаторов требуется обеспечение удаленного доступа к функциям O&M.

Удаленный доступ к функциям O&M может осуществляться с помощью программных агентов управления. В прямом варианте маршрутизатор будет поддерживать функции O&M удаленно напрямую из NOC с использованием стандартных протоколов Internet (например, SNMP, UDP или TCP), в опосредованном варианте эти протоколы будут поддерживаться агентом управления, который обеспечивает контроль за маршрутизатором с помощью фирменных протоколов. Прямой вариант является более предпочтительным, хотя возможны и другие варианты. Использование специального оборудования и/или программ, существенно повышающих стоимость маршрутизаторов, не рекомендуется, однако некоторые производители могут предлагать агент управления как встроенную компоненту сети, частью которой являются маршрутизаторы. В таких случаях требуется возможность доступа к агентам управления с удаленных сайтов на основе стандартных протоколов Internet, а также обеспечение функциональности, эквивалентной локальному доступу к агентам.

Желательно, чтобы агент управления и все программные инструменты для NOC, которые обеспечивает производитель, работали как пользовательские программы в стандартных операционных системах. Использование стандартных протоколов Internet (UDP и TCP) для связи с маршрутизаторами упрощает эту задачу.

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

10.3.2 Доступ по отдельному каналу (Out Of Band)

Маршрутизаторы должны поддерживать доступ по отдельному каналу (Out-Of-Band или OOB). Для OOB-доступа следует поддерживать такую же функциональность, как для доступа по основному каналу (in-band). Для этого варианта доступа следует реализовать систему контроля доступа с целью предотвращения несанкционированного подключения к маршрутизатору.

Обсуждение

Доступ по отдельному каналу будет предоставлять NOC возможность подключения к маршрутизатору в период его недоступности через сеть.

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

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

10.3.2 Функции O&M в маршрутизаторах

10.3.2.1 Обслуживание диагностика оборудования

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

10.3.2.2 Контроль запись содержимого памяти и перезагрузка

Маршрутизатор должен поддерживать для режимов in-band и out-of-band механизмы, позволяющие администратору перезагружать маршрутизатор, останавливать и возобновлять его работу. Маршрутизаторам следует также поддерживать механизм (например, watchdog-таймер), который будет автоматически перезагружать маршрутизатор при его «зависании» в результате аппаратных или программных отказов.

Маршрутизатору следует поддерживать механизм записи содержимого памяти (dump) и другой полезной информации при возникновении критических ошибок в работе. Эти данные следует записывать на стабильный локальный носитель или передавать на другой хост с использованием таких механизмов, как TFTP (см. [OPER:2], [INTRO:3]).

10.3.2.3 Контроль настройка конфигурации

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

Следует обеспечивать возможность настройки конфигурации маршрутизатора через сеть в ручном или автоматическом режиме. Маршрутизатору следует поддерживать возможность загрузки параметров с другого хоста или маршрутизатора. Это означает, что следует обеспечить прикладную программу или функцию маршрутизатора для преобразования формата конфигурационного файла, понятного человеку, в формат, используемый программой управления конфигурацией маршрутизатора. Маршрутизатору следует поддерживать стабильную среду хранения информации для записи конфигурационных параметров. Не следует полагаться при хранении конфигурации на такие механизмы, как RARP, ICMP Address Mask Reply, можно не полагаться и на BOOTP.

Обсуждение

Необходимо отметить, что в будущем RARP, ICMP Address Mask Reply, BOOTP и другие механизмы могут потребоваться для поддержки автоматической настройки конфигурации маршрутизаторов. Хотя в будущем маршрутизаторы смогут поддерживать автоматическую настройку конфигурации, не следует применять ее в рабочих сетях до тех пор, пока системы автоматической настройки не будут подобающим образом протестированы. Это не означает полного отказа от использования автоматических средств настройки конфигурации. В тех случаях, когда предполагается автоматическая настройка, может оказаться разумным позволить маршрутизатору выполнить операции по автоматической настройке конфигурации, а потом проигнорировать заданные автоматически параметры.

10.3.2.4 Загрузка системных программ через сеть

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

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

Обсуждение

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

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

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

10.3.2.5 Обнаружение и обработка конфигурационных ошибок

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

Обсуждение

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

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

Обсуждение

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

10.3.2.6 Минимизация «разрушений»

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

Обсуждение

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

10.3.2.7 Контроль – поиск неисправностей
  1. Маршрутизатор должен обеспечивать доступ через сеть (in-band) для управления, но (за исключением случаев, указанных в параграфе 8.2) из соображений безопасности по умолчанию такой доступ следует отключать. Производители должны указывать в документации установленное по умолчанию состояние для любого доступа в режиме in-band. Для такого доступа следует обеспечивать средства контроля, позволяющие предотвратить несанкционированный доступ.

Обсуждение

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

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

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

  1. Маршрутизатор должен обеспечивать возможность инициирования передачи запросов ICMP. Следует реализовать перечисленные ниже опции:

    • выбор шаблона (pattern) для поля данных;

    • выбор размера пакетов;

    • запись маршрута (Record route).

Дополнительно могут быть реализованы следующие опции:

    • Loose source route;

    • Strict source route;

    • Timestamp.

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

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

10.4 Вопросы безопасности

10.4.1 Аудит и журналы аудита

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

  1. Изменения конфигурации

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

Обсуждение

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

  1. Учет пакетов

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

Обсуждение

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

  1. Аудит безопасности

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

    • отказы при проверке полномочий: некорректные пароли, недопустимые группы SNMP, непригодные маркеры;

    • нарушения правил доступа: запрещенные маршруты Source Route, фильтруемые адресаты;

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

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

10.4.2 Контроль конфигурации

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

Обсуждение

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

Если производитель обеспечивает своим заказчикам возможность удаленного изменения конфигурации маршрутизатора (например, через сессии Telnet), такую возможность следует делать настраиваемой и по умолчанию ее следует отключать. Маршрутизатору следует выполнять аутентификацию пользователя перед тем, как разрешить удаленное изменение конфигурации. При проверке подлинности пользователей не следует передавать секретные сведения (параметры аутентификации) через сеть. Например, при поддержке сессий telnet производителю следует реализовать процедуры аутентификации типа Kerberos, S-Key и т. п..

Обсуждение

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

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

Обсуждение

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

11. Литература

Разработчикам следует принимать во внимание, что стандарты для протоколов Internet время от времени изменяются. Приведенные здесь ссылки были актуальны на момент создания этого документа, но внимательные разработчики всегда будут проверять наличие более новых версий RFC или их отмены другими, более новыми RFC11. В документе [INTRO:6] указаны различные способы получения текущего списка RFC.

APPL:1. Croft, B., and J. Gilmore, “Bootstrap Protocol (BOOTP)”, RFC 95112, Stanford University, Sun Microsystems, September 1985.

APPL:2. Alexander, S., and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 153313, Lachman Technology, Inc., Bucknell University, October 1993.

APPL:3. Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol”, RFC 1542, Carnegie Mellon University, October 1993.

ARCH:1. DDN Protocol Handbook, NIC-50004, NIC-50005, NIC-50006 (three volumes14), DDN Network Information Center, SRI International, Menlo Park, California, USA, December 1985.

ARCH:2. V. Cerf and R. Kahn, “A Protocol for Packet Network Intercommunication”15, IEEE Transactions on Communication, May 1974. Включена в [ARCH:1].

ARCH:3. J. Postel, C. Sunshine, and D. Cohen, “The ARPA Internet Protocol”, Computer Networks, volume 5, number 4, July 1981. Включена в [ARCH:1].

ARCH:4. B. Leiner, J. Postel, R. Cole, and D. Mills, :The DARPA Internet Protocol Suite”, Proceedings of INFOCOM ’85, IEEE, Washington, DC, March 1985. Also in: IEEE Communications Magazine, March 1985. Also available from the Information Sciences Institute, University of Southern California as Technical Report ISI-RS-85-153.

ARCH:5. D. Comer, “Internetworking With TCP/IP Volume 1: Principles, Protocols, and Architecture”16, Prentice Hall, Englewood Cliffs, NJ, 1991.

ARCH:6. W. Stallings, “Handbook of Computer-Communications Standards Volume 3: The TCP/IP Protocol Suite”, Macmillan, New York, NY, 1990.

ARCH:7. Postel, J., “Internet Official Protocol Standards”, STD 1, RFC 178017, Internet Architecture Board, March 1995.

ARCH:8. Information processing systems – Open Systems Interconnection – Basic Reference Model18, ISO 749819, International Standards Organization, 1984.

ARCH:9 R. Braden, J. Postel, Y. Rekhter, “Internet Architecture Extensions for Shared Media”, RFC 162020, 05/20/1994

FORWARD:1. IETF CIP Working Group (C. Topolcic, Editor), “Experimental Internet Stream Protocol”, Version 2 (ST-II), RFC 119021, October 1990.

FORWARD:2. Mankin, A., and K. Ramakrishnan, Editors, “Gateway Congestion Control Survey”, RFC 1254, MITRE, Digital Equipment Corporation, August 1991.

FORWARD:3. J. Nagle, “On Packet Switches with Infinite Storage”, IEEE Transactions on Communications, volume COM-35, number 4, April 198722.

FORWARD:4. R. Jain, K. Ramakrishnan, and D. Chiu, “Congestion Avoidance in Computer Networks With a Connectionless Network Layer”, Technical Report DEC-TR-50623, Digital Equipment Corporation.

FORWARD:5. V. Jacobson, “Congestion Avoidance and Control”, Proceedings of SIGCOMM ’88, Association for Computing Machinery24, August 1988.

FORWARD:6. W. Barns, “Precedence and Priority Access Implementation for Department of Defense Data Networks”, Technical Report MTR-91W00029, The Mitre Corporation, McLean, Virginia, USA, July 1991.

FORWARD:7 Fang, Chen, Hutchins, “Simulation Results of TCP Performance over ATM with and without Flow Control”, presentation to the ATM Forum, November 15, 1993.

FORWARD:8 V. Paxson, S. Floyd “Wide Area Traffic: the Failure of Poisson Modeling”25, сокращенная версия опубликована в SIGCOMM ’94.

FORWARD:9 Leland, Taqqu, Willinger and Wilson, “On the Self-Similar Nature of Ethernet Traffic”, Proceedings of SIGCOMM ’9326, September, 1993.

FORWARD:10 S. Keshav “A Control Theoretic Approach to Flow Control”, SIGCOMM 9127, pages 3-16

FORWARD:11 K.K. Ramakrishnan and R. Jain, “A Binary Feedback Scheme for Congestion Avoidance in Computer Networks”, ACM Transactions of Computer Systems, volume 8, number 228, 1980.

FORWARD:12 H. Kanakia, P. Mishara, and A. Reibman]. “An adaptive congestion control scheme for real-time packet video transport”, In Proceedings of ACM SIGCOMM 1994, pages 20-31, San Francisco, California, September 1993.

FORWARD:13 A. Demers, S. Keshav, S. Shenker, “Analysis and Simulation of a Fair Queuing Algorithm”, 93 pages 1-1229

FORWARD:14 Clark, D., Shenker, S., and L. Zhang, “Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanism”, 92 pages 14-2630

INTERNET:1. Postel, J., “Internet Protocol”, STD 5, RFC 791, USC/Information Sciences Institute, September 1981.

INTERNET:2. Mogul, J., and J. Postel, “Internet Standard Subnetting Procedure”, STD 5, RFC 950, Stanford, USC/Information Sciences Institute, August 1985.

INTERNET:3. Mogul, J., “Broadcasting Internet Datagrams in the Presence of Subnets”, STD 5, RFC 922, Stanford University, October 1984.

INTERNET:4. Deering, S., “Host Extensions for IP Multicasting”, STD 5, RFC 111231, Stanford University, August 1989.

INTERNET:5. Kent, S., “U.S. Department of Defense Security Options for the Internet Protocol”, RFC 1108, BBN Communications, November 1991.

INTERNET:6. Braden, R., Borman, D., and C. Partridge, “Computing the Internet Checksum”, RFC 1071, USC/Information Sciences Institute, Cray Research, BBN Communications, September 1988.

INTERNET:7. Mallory T., and A. Kullberg, “Incremental Updating of the Internet Checksum”, RFC 114132, BBN Communications, January 1990.

INTERNET:8. Postel, J., “Internet Control Message Protocol”, STD 5, RFC 79233, USC/Information Sciences Institute, September 1981.

INTERNET:9. A. Mankin, G. Hollingsworth, G. Reichlen, K. Thompson, R. Wilder, and R. Zahavi, “Evaluation of Internet Performance – FY89”, Technical Report MTR-89W00216, MITRE Corporation, February, 1990.

INTERNET:10. G. Finn, A “Connectionless Congestion Control Algorithm”, Computer Communications Review, volume 19, number 5, Association for Computing Machinery, October 1989.

INTERNET:11. Prue, W., and J. Postel, “The Source Quench Introduced Delay (SQuID)”, RFC 1016, USC/Information Sciences Institute, August 1987.

INTERNET:12. McKenzie, A., “Some comments on SQuID”, RFC 1018, BBN Labs, August 1987.

INTERNET:13. Deering, S., “ICMP Router Discovery Messages”, RFC 1256, Xerox PARC, September 1991.

INTERNET:14. Mogul J., and S. Deering, “Path MTU Discovery”, RFC 1191, DECWRL, Stanford University, November 1990.

INTERNET:15 Fuller, V., Li, T., Yu, J., and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy” RFC 151934, BARRNet, cisco, Merit, OARnet, September 1993.

INTERNET:16 St. Johns, M., “Draft Revised IP Security Option”, RFC 103835, IETF, January 1988.

INTERNET:17 Prue, W., and J. Postel, “Queuing Algorithm to Provide Type- of-service For IP Links”, RFC 1046, USC/Information Sciences Institute, February 1988.

INTERNET:18 Postel, J., “Address Mappings”, RFC 796, USC/Information Sciences Institute, September 1981.

INTRO:1. Braden, R., and J. Postel, “Requirements for Internet Gateways”, STD 4, RFC 100936, USC/Information Sciences Institute, June 1987.

INTRO:2. Internet Engineering Task Force (R. Braden, Editor), “Requirements for Internet Hosts – Communication Layers”, STD 3, RFC 1122, USC/Information Sciences Institute, October 1989.

INTRO:3. Internet Engineering Task Force (R. Braden, Editor), “Requirements for Internet Hosts – Application and Support”, STD 3, RFC 1123, USC/Information Sciences Institute, October 1989.

INTRO:4. Clark, D., “Modularity and Efficiency in Protocol Implementations”, RFC 817, MIT Laboratory for Computer Science, July 1982.

INTRO:5. Clark, D., “The Structuring of Systems Using Upcalls”, Proceedings of 10th ACM SOSP, December 1985.

INTRO:6. Jacobsen, O., and J. Postel, “Protocol Document Order Information”, RFC 980, SRI, USC/Information Sciences Institute, March 1986.

INTRO:7. Reynolds, J., and J. Postel, “Assigned Numbers”, STD 2, RFC 170037, USC/Information Sciences Institute, October 1994.

INTRO:8. DoD Trusted Computer System Evaluation Criteria38, DoD publication 5200.28-STD, U.S. Department of Defense, December 1985.

INTRO:9 Malkin, G., and T. LaQuey Parker, Editors, “Internet Users’ Glossary”, FYI 18, RFC 139239, Xylogics, Inc., UTexas, January 1993.

LINK:1. Leffler, S., and M. Karels, “Trailer Encapsulations”, RFC 893, University of California at Berkeley, April 1984.

LINK:2 Simpson, W., “The Point-to-Point Protocol (PPP)”, STD 51, RFC 166140, Daydreamer July 1994.

LINK:3 McGregor, G., “The PPP Internet Protocol Control Protocol (IPCP)”, RFC 133241, Merit May 1992.

LINK:4 Lloyd, B., and W. Simpson, “PPP Authentication Protocols”, RFC 133442, L&A, Daydreamer, May 1992.

LINK:5 Simpson, W., “PPP Link Quality Monitoring”, RFC 133343, Daydreamer, May 1992.

MGT:1. Rose, M., and K. McCloghrie, “Structure and Identification of Management Information of TCP/IP-based Internets”, STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.

MGT:2. McCloghrie, K., and M. Rose (Editors), “Management Information Base of TCP/IP-Based Internets: MIB-II”, STD 16, RFC 121344, Hughes LAN Systems, Inc., Performance Systems International, March 1991.

MGT:3. Case, J., Fedor, M., Schoffstall, M., and J. Davin, “Simple Network Management Protocol”, STD 15, RFC 1157, SNMP Research, Performance Systems International, MIT Laboratory for Computer Science, May 1990.

MGT:4. Rose, M., and K. McCloghrie (Editors), “Towards Concise MIB Definitions”, STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991.

MGT:5. Steinberg, L., “Techniques for Managing Asynchronously Generated Alerts”, RFC 1224, IBM Corporation, May 1991.

MGT:6. Kastenholz, F., “Definitions of Managed Objects for the Ethernet-like Interface Types”, RFC 139845, FTP Software, Inc., January 1993.

MGT:7. McCloghrie, K., and R. Fox “IEEE 802.4 Token Bus MIB”, RFC 123046, Hughes LAN Systems, Inc., Synoptics, Inc., May 1991.

MGT:8. McCloghrie, K., Fox R., and E. Decker, “IEEE 802.5 Token Ring MIB”, RFC 123147, Hughes LAN Systems, Inc., Synoptics, Inc., Cisco Systems, Inc., February 1993.

MGT:9. Case, J., and A. Rijsinghani, “FDDI Management Information Base”, RFC 1512, The University of Tennesse and SNMP Research, Digital Equipment Corporation, September 1993.

MGT:10. Stewart, B., Editor “Definitions of Managed Objects for RS-232-like Hardware Devices”, RFC 131748, Xyplex, Inc., April 1992.

MGT:11. Kastenholz, F., “Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol”, RFC 1471, FTP Software, Inc., June 1992.

MGT:12. Kastenholz, F., “The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol”, RFC 1472, FTP Software, Inc., June 1992.

MGT:13. Kastenholz, F., “The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol”, RFC 1473, FTP Software, Inc., June 1992.

MGT:14. Baker, F., and R. Coltun, “OSPF Version 2 Management Information Base”, RFC 125349, ACC, Computer Science Center, August 1991.

MGT:15. Willis, S., and J. Burruss, “Definitions of Managed Objects for the Border Gateway Protocol (Version 3)”, RFC 126950, Wellfleet Communications Inc., October 1991.

MGT:16. Baker, F., and J. Watt, “Definitions of Managed Objects for the DS1 and E1 Interface Types”, RFC 140651, Advanced Computer Communications, Newbridge Networks Corporation, January 1993.

MGT:17. Cox, T., and K. Tesink, Editors “Definitions of Managed Objects for the DS3/E3 Interface Types”, RFC 140752, Bell Communications Research, January 1993.

MGT:18. McCloghrie, K., “Extensions to the Generic-Interface MIB”, RFC 122953, Hughes LAN Systems, August 1992.

MGT:19. Cox, T., and K. Tesink, “Definitions of Managed Objects for the SIP Interface Type”, RFC 130454, Bell Communications Research, February 1992.

MGT:20 Baker, F., “IP Forwarding Table MIB”, RFC 135455, ACC, July 1992.

MGT:21. Malkin, G., and F. Baker, “RIP Version 2 MIB Extension”, RFC 1724, Xylogics, Inc., Cisco Systems, November 1994

MGT:22. Throop, D., “SNMP MIB Extension for the X.25 Packet Layer”, RFC 1382, Data General Corporation, November 1992.

MGT:23. Throop, D., and F. Baker, “SNMP MIB Extension for X.25 LAPB”, RFC 1381, Data General Corporation, ACC, November 1992.

MGT:24. Throop, D., and F. Baker, “SNMP MIB Extension for MultiProtocol Interconnect over X.25”, RFC 1461, Data General Corporation, May 1993.

MGT:25. Rose, M., “SNMP over OSI”, RFC 1418, Dover Beach Consulting, Inc., March 1993.

MGT:26. Minshall, G., and M. Ritter, “SNMP over AppleTalk”, RFC 1419, Novell, Inc., Apple Computer, Inc., March 1993.

MGT:27. Bostock, S., “SNMP over IPX”, RFC 1420, Novell, Inc., March 1993.

MGT:28. Schoffstall, M., Davin, C., Fedor, M., and J. Case, “SNMP over Ethernet”, RFC 108956, Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, NYSERNet, Inc., University of Tennessee at Knoxville, February 1989.

MGT:29. Case, J., “FDDI Management Information Base”, RFC 128557, SNMP Research, Incorporated, January 1992.

OPER:1. Nagle, J., “Congestion Control in IP/TCP Internetworks”, RFC 896, FACC, January 1984.

OPER:2. Sollins, K., “TFTP Protocol (revision 2)”, RFC 135058, MIT, July 1992.

ROUTE:1. Moy, J., “OSPF Version 2”, RFC 158359, Proteon, March 1994.

ROUTE:2. Callon, R., “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments”, RFC 119560, DEC, December 1990.

ROUTE:3. Hedrick, C., “Routing Information Protocol”, RFC 105861, Rutgers University, June 1988.

ROUTE:4. Lougheed, K., and Y. Rekhter, “A Border Gateway Protocol 3 (BGP-3)”, RFC 126762, cisco, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:5. Gross, P, and Y. Rekhter, “Application of the Border Gateway Protocol in the Internet”, RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.

ROUTE:6. Mills, D., “Exterior Gateway Protocol Formal Specification”, RFC 904, UDEL, April 1984.

ROUTE:7. Rosen, E., “Exterior Gateway Protocol (EGP)”, RFC 82763, BBN, October 1982.

ROUTE:8. Seamonson, L, and E. Rosen, “STUB” “Exterior Gateway Protocol”, RFC 88812, BBN, January 1984.

ROUTE:9. Waitzman, D., Partridge, C., and S. Deering, “Distance Vector Multicast Routing Protocol”, RFC 1075, BBN, Stanford, November 1988.

ROUTE:10. Deering, S., Multicast Routing in Internetworks and Extended LANs, Proceedings of ’88, Association for Computing Machinery64, August 1988.

ROUTE:11. Almquist, P., “Type of Service in the Internet Protocol Suite”, RFC 134965, Consultant, July 1992.

ROUTE:12. Rekhter, Y., “Experience with the BGP Protocol”, RFC 1266, T.J. Watson Research Center, IBM Corp., October 1991.

ROUTE:13. Rekhter, Y., “BGP Protocol Analysis”, RFC 1265, T.J. Watson Research Center, IBM Corp., October 1991.

TRANS:1. Postel, J., “User Datagram Protocol”, STD 6, RFC 768, USC/Information Sciences Institute, August 1980.

TRANS:2. Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, USC/Information Sciences Institute, September 1981.

Приложение A. Требования к хостам SOURCE-ROUTING

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

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

  1. TTL

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

  2. ICMP Destination Unreachable

    Хост должен быть способен генерировать сообщения Destination Unreachable с кодами:

  1. Fragmentation Required but DF Set, когда дейтаграмма с заданным отправителем маршрутом не может быть фрагментирована в соответствии с требованиями сети, куда ее нужно переслать;

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

  1. IP-адрес отправителя

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

  2. Опция Record Route

    Хост, пересылающий дейтаграмму с заданной отправителем маршрутизацией и опцией Record Route, должен сделать свою запись в эту опцию, если в последней имеется свободное место.

  3. Опция Timestamp

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

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

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

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

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

Если хост получает дейтаграмму с незавершенным маршрутом source route и не пересылает ее по какой-либо причине, ему следует вернуть отправителю сообщение ICMP Destination Unreachable с кодом 5 (Source Route Failed), если сама дейтаграмма не была сообщением ICMP об ошибке.

Приложение B. Глоссарий

В этом приложении даны определения терминов, использованных в документе, а также некоторых терминов общего назначения, которые могут представлять интерес. Более полный список терминологических определений общего назначения представлен в документе [INTRO:9].

Autonomous System (AS) автономная система

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

Connected Network подключенная сеть

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

Connected (Sub)Network подключенная (под)сеть

Подключенная (под)сеть представляет собой подсеть IP, в которую маршрутизатор имеет интерфейс. См. также Connected Network.

Datagram – дейтаграмма

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

Default Route маршрут по умолчанию

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

Dense Mode режим Dense

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

EGP

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

EGP-2

Протокол EGP версии 2. Это протокол внешней маршрутизации, разработанный для обмена маршрутными данными между автономными системами в сети Internet.

Forwarder модуль пересылки

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

Forwarding – пересылка

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

Forwarding Information Base (FIB) база данных о пересылке

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

Fragment фрагмент

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

General Purpose Serial Interface последовательный интерфейс общего назначения

Физическая среда, обеспечивающая возможность организации соединения между парой систем и настраиваемая на работу в режиме «точка-точка», но поддерживающая также канальный уровень на базе протоколов типа X.25 или Frame Relay. Канальный уровень позволяет подключать другие системы к коммутаторам и вышележащие уровни мультиплексируют виртуальные устройства для соединений. См. также Point to Point Line.

IGP

Протокол внутреннего шлюза (Interior Gateway Protocol). Протокол, распространяющий маршрутные данные внутри автономной системы. См. также EGP.

Interface IP Address IP-адрес интерфейса

Адрес IP и размер сетевого префикса, присвоенные определенному интерфейсу маршрутизатора.

Internet Address адрес Internet

Специальное значение, позволяющее идентифицировать хост в internet. Адрес состоит из 2 частей – IP-адреса и длины префикса. Длина префикса показывает, какая часть старших битов адреса относится к префиксу сети.

IP

Internet Protocol. Протокол сетевого уровня в Internet, описанный в RFC 791. Протокол IP не гарантирует доставку пакетов (т. е., не поддерживает сквозного или поэтапного подтверждения доставки).

IP Datagram дейтаграмма IP

Дейтаграмма IP представляет собой единицу информационного обмена для протокола IP. Дейтаграмма IP состоит из заголовка IP, за которым следуют данные – сообщение протокола вышележащего уровня (TCP, UDP, ICMP и пр.).

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

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

IP Fragment фрагмент IP

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

Один или несколько фрагментов IP образуют дейтаграмму IP.

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

IP Packet пакет IP

Дейтаграмма IP или фрагмент IP.

В данном документе термин «пакет», приведенный без дополнительных уточнений, означает пакет IP.

Logical [network] interface логический [сетевой] интерфейс

Логический [сетевой] интерфейс представляет собой путь соединения с сетью, указанный уникальным адресом IP66.

Martian Filtering фильтрация пакетов с недопустимыми адресами67

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

MTU (Maximum Transmission Unit) максимальный размер передаваемого блока

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

Multicast групповой пакет

Пакет, адресованный множеству хостов. См. также broadcast.

Multicast Address групповой адрес

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

Для таких адресов используются также термины Functional Address и Group Address.

Network Prefix префикс сети

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

Originate – происхождение

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

Packet – пакет

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

Path – путь

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

Physical Network физическая сеть

Физическая сеть представляет собой сеть (или часть internet), которая непрерывна на канальном уровне. Внутренняя структура такой сети (если она имеется) прозрачна для уровня Internet.

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

Physical Network Interface физический сетевой интерфейс

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

Point to Point Line линия «точка-точка»

Физическая среда, способная соединять между собой пару систем. В данном документе этот термин используется только для обозначения линий, соединяющих между собой объекты IP. См. также General Purpose Serial Interface.

Router – маршрутизатор

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

RPF (Reverse Path Forwarding) пересылка по обратному пути

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

Silently Discard отбрасывание без уведомления

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

Silently Ignore игнорирование без уведомления

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

Sparse Mode

При групповой пересылке возможны два варианта – в режиме Sparse групповые дейтаграммы сетевого уровня пересылаются, как групповые кадры канального уровня маршрутизаторам и хостам, которые запросили такую пересылку. В исходном состоянии пересылка находится в инверсном режиме Dense, т. е. предполагается, что никто не хочет получать групповые пакеты. См. также Dense Mode.

Specific-destination address адрес конкретного получателя

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

Subnet – подсеть

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

Subnet number номер подсети

Часть IP-адреса, идентифицирующая данную подсеть. Номер подсети игнорируется в процессах internet-маршрутизации, но принимается во внимание при маршрутизации внутри intranet.

TOS (Type Of Service) тип обслуживания

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

TTL (Time To Live) время жизни

Поле в заголовке IP определяющее срок существования пакета в сети. Значение поля представляет собой комбинацию таймера и счетчика интервалов в сети.

Приложение C. Перспективы развития документа

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

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

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

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

  1. SNMP версии 2.

  2. Дополнительные SNMP MIB.

  1. Более детальные требования для передачи маршрутов между разными протоколами маршрутизации.

  2. Безопасность маршрутизаторов.

  3. Безопасность протоколов маршрутизации.

  4. Безопасность протоколов межсетевого взаимодействия (Internetwork Protocol layer). Следует включить в документ результаты многочисленных работ по безопасности IP.

  1. Расщепление нагрузки (Load Splitting).

  2. Передача фрагментов по разным путям.

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

  1. Контроль насыщения и управление ресурсами. По совету экспертов IETF (Mankin и Ramakrishnan) внесено возражение против использования (не следует) Source Quench и приведены некоторые конкретные соображения на эту тему (параграф 5.3.6).

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

  3. Разработка алгоритма общего назначения PPP LQM.

  4. Исследование другой информации (см. предыдущие пункты и главу 3.2), передаваемой между уровнями – значение MTU для физической сети, отображение предпочтений IP на приоритеты канального уровня и т. п.

  5. Решение вопроса о том, следует ли канальному уровню уведомлять IP при неудаче преобразования адреса (как это делается при уведомлении уровня IP канальным уровнем в случае возникновения проблем со значениями приоритета).

  6. Следует ли требовать от всех маршрутизаторов реализации DNS resolver?

  7. Следует ли позволять пользователям применять имя хоста вместо адреса IP при настройке конфигурации маршрутизатора или в командах ping и traceroute?

  8. Работы Алмквиста (Almquist) по поводу следующего интервала (next hop) и утечки маршрутов (route leaking) нужно заново рассмотреть, привести в соответствии с текущей ситуацией и опубликовать.

  9. Требуется проведение исследований по поводу целесообразности использования перенаправления в соответствии с запрошенным уровнем предпочтения. Если это будет признано нецелесообразным, следует ли воспринимать перенаправления по типу обслуживания?

  10. RIPv2, RIP+CIDR и сетевые префиксы переменной длины.

  11. BGP-4 CIDR становится важным и все делают ставку на BGP-4. Мы не можем оставить этот вопрос без внимания. Возможно следует описать различия между BGP-3 и BGP-4, а также рассмотреть вопросы обновления …

  12. Поддержка Loose Source Route Mobile IP и некоторых типов групповой передачи может стать более важной. Возможно для этих требований нужно поднять уровень до «следует» (как предлагает Fred Baker).

Приложение D. Протоколы групповой маршрутизации

Групповая передача (Multicasting) является сравнительно новой технологией в семействе протоколов IP. Она пока распространена недостаточно широко и не является общепринятой. Однако можно предположить рост интереса к этой технологии в будущем.

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

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

В этом приложении не содержится никаких стандартов и не задаются какие-либо требования.

D.1 Введение

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

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

D.2 Протокол DVMRP

Протокол DVMRP68, описанный в [ROUTE:9], основан на технологии Distance Vector или Bellman-Ford. Протокол предназначен для маршрутизации только групповых дейтаграмм и делает это в пределах одной автономной системы. DVMRP является реализацией алгоритма Truncated Reverse Path Broadcasting, описанного в [ROUTE:10]. Кроме того, протокол поддерживает туннелирование групповых дейтаграмм IP через домены, не поддерживающие групповую адресацию.

D.3 Групповое расширение для OSPF – MOSPF

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

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

D.4 Независимая от протокола групповая передача – PIM

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

Приложение E. Другие алгоритмы определения Next-Hop

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

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

В приложении представлены черновые материалы из неопубликованной работы Филиппа Алмквиста (Philip Almquist) Ruminations on the Next Hop72.

В этом приложении не содержится никаких стандартов и не задаются какие-либо требования.

E.1. Немного истории

Будет полезен краткий экскурс в историю вопроса, начиная с периода, который иногда называют «классической моделью» принятия маршрутизаторами решения о пересылке. Эта модель старше протокола IP. В данной модели маршрутизаторы обмениваются информацией с помощью одного протокола маршрутизации (например, RIP). Данный протокол полностью определяет для маршрутизаторов содержимое базы данных о пересылке (FIB). Алгоритм поиска маршрута тривиален – маршрутизатор просто просматривает FIB в поисках пути, атрибуты которого в точности совпадают с сетевым префиксом адреса получателя в пакете. Если такой маршрут найден, он будет использован для пересылки пакета, при отсутствии нужного маршрута адресат считается недоступным. Поскольку протокол маршрутизации сохраняет только один маршрут к каждому адресату, проблемы выбора маршрута из нескольких просто не возникает.

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

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

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

Дополнительные изменения классической модели связаны с разработкой протоколов междоменной маршрутизации. Традиционные протоколы маршрутизации стали обозначать аббревиатурой IGP (interior gateway protocol – протокол внутреннего шлюза) и на каждом сайте Internet появились странные создания, названные внешними шлюзами, которые с помощью протокола EGP обменивались информацией с несколькими центральными маршрутизаторами BBN73 и одновременно использовали протокол IGP для обмена с другими маршрутизаторами своего сайта. Оба протокола хотели иметь контроль над содержимым таблицы маршрутизации. Теоретически это могло приводить к наличию в маршрутизаторе трех путей (EGP, IGP, статический маршрут) к одному адресату. С учетом топологии Internet того времени после некоторых дебатов было принято правило, в соответствии с которым маршруты IGP считались более предпочтительными по сравнению с маршрутами EGP. Однако проблемы, связанные с длиной соответствия, остались нерешенными. Полученный от IGP маршрут по умолчанию никогда не будет более предпочтительным по сравнению с маршрутом в сеть, полученным от EGP.

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

  • Игнорируются (хотя это не обязательно) характеристики путей (такие, как тип обслуживания и MTU).

  • Не поддерживаются протоколы маршрутизации (такие, как OSPF и Integrated IS-IS), которым нужен алгоритм выбора маршрута, отличающийся от сравнения длины соответствия.

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

E.2. Дополнительные правила сокращения

В параграфе 5.2.4.3 определено несколько правил сокращения при выборе маршрутов из FIB. Ниже приведены дополнительные правила, которые можно использовать для сокращения.

  • Класс маршрута OSPF

    Протоколы маршрутизации, которые могут поддерживать области, или различают внутренние и внешние маршруты, деля их на классы по типу используемой при расчете маршрута информации. Маршрут всегда выбирается из наиболее предпочтительного класса, затем из следующего по уровню предпочтения (если ничего не найдено в первом) и т. д. В OSPF используются классы (в порядке убывания уровня предпочтений) intra-area (внутри области), inter-area (между областями), type 1 external (внешние маршруты с внутренней метрикой), type 2 external. Дополнительно можно задать для маршрутизатора набор адресов, которые будут доступны внутри области и для которых не будут использоваться маршруты между областями или внешние пути даже при недоступности маршрута внутри области.

    Говоря точнее, предполагается, что каждый маршрут имеет атрибут, называемый классом маршрута (route.class), который присваивается протоколом маршрутизации. Набор маршрутов-кандидатов проверяется на предмет наличия в нем маршрутов с route.class = intra-area. При наличии таких маршрутов все остальные кандидаты исключаются из списка. Если маршрута внутри области не найдено, маршрутизатор проверяет, не относится ли получатель пакета к диапазонам адресов, указанных для локальной области. При положительном ответе весь набор оставшихся кандидатов удаляется, а при отрицательном кандидаты проверяются на предмет наличия среди них маршрутов с route.class = inter-area. Если такие маршруты найдены, все остальные кандидаты отбрасываются. При отсутствии межобластных маршрутов проверяется наличие маршрутов с route.class = type 1 external. Если такие маршруты найдены, все прочие кандидаты исключаются из списка.

  • Класс маршрута IS-IS

    Классы маршрутов IS-IS работают аналогично классам OSPF. Однако набор классов, используемых в Integrated IS-IS, отличается, поэтому нет возможности установить взаимно-однозначное соответствие между классами маршрутов IS-IS и OSPF. К числу используемых в Integrated IS-IS классов относятся (в порядке снижения уровня предпочтений) intra-area (внутриобластные), inter-area (межобластные), external (внешние).

    Внутренние классы Integrated IS-IS эквивалентны внутренним классам OSPF. Кроме того, класс external в Integrated IS-IS эквивалентен классу type 2 external в OSPF. Однако протокол Integrated IS-IS не различает межобластные маршруты и внешние маршруты с внутренней метрикой (оба типа маршрутов относятся к классу inter-area). В результате OSPF предпочитает межобластные маршруты внешним путям с внутренней метрикой, а в Integrated IS-IS эти два типа имеют одинаковый уровень предпочтения.

  • Политика IDPR

    Рабочая группа IETF по правилам междоменной маршрутизации (Inter-domain Policy Routing) разработала протокол маршрутизации, получивший название IDPR75, для поддержки в Internet основанной на правилах маршрутизации. Пакеты с некоторой комбинацией атрибутов заголовка (конкретные комбинации адресов отправителя и получателя, специальные опции IDPR source route) должны использовать маршруты, обеспечиваемые протоколом IDPR. Таким образом, в отличие от других правил сокращения, IDPR Policy будет применяться до всех прочих правил сокращения, кроме базового соответствия (Basic Match).

    В частности, IDPR Policy проверяет пересылаемые пакеты на предмет наличия в них атрибутов, требуемых для пересылки с использованием основанных на правилах маршрутов. При позитивном ответе IDPR Policy удаляет из списка кандидатов все маршруты, не обеспечиваемые протоколом IDPR.

E.3 Некоторые алгоритмы поиска маршрутов

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

E.3.1 Пересмотренный классический алгоритм

Пересмотренный классический алгоритм представляет собой вариант традиционного алгоритма, рассмотренного в параграфе E.1. Этапы сокращения перечислены ниже.

  1. Basic match (базовое соответствие).

  2. Longest match (максимальная длина соответствия).

  3. Best metric (лучшая метрика).

  4. Policy (политика).

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

Преимущества алгоритма

  1. Наличие множества реализаций и широкое распространение.

  2. Простота для понимания и реализации (за исключением этапа Policy, который может быть достаточно сложным).

Недостатки

  1. Не обрабатываются классы маршрутов IS-IS и OSPF, поэтому не могут применяться протоколы Integrated IS-IS и OSPF.

  2. Не обрабатывается поле TOS и другие атрибуты пути.

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

  4. Фирменные механизмы политики, предлагаемые производителями, зачастую не подходят для использования в сложных участках Internet.

  5. Алгоритм не описан в каком-либо доступном документе или стандарте. По сути он является частью фольклора Internet.

E.3.2 Вариант алгоритма из спецификации Router Requirements

Часть членов рабочей группы Router Requirements предложила использовать несколько отличающийся вариант алгоритма, описанного в параграфе 5.2.4.3. В этом варианте соответствие запрошенного типа обслуживания рассматривается, как более важный аргумент, нежели наибольшая длина соответствия адреса. Например, этот алгоритм позволяет отдавать предпочтение заданному по умолчанию маршруту, если тот имеет пригодный тип обслуживания, а маршрут с максимальной длиной соответствия обеспечивает принятое по умолчанию значение TOS (0). Алгоритм, описанный в параграфе 5.2.4.3, будет давать обратный результат.

Этапы сокращения перечислены ниже.

  1. Basic match (базовое соответствие).

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

  3. Longest match (максимальная длина соответствия).

  4. Best metric (лучшая метрика).

  5. Policy (политика).

Дебаты между сторонниками описанного здесь варианта и сторонниками алгоритма, рассмотренного в параграфе 5.2.4.3, показали, что обе стороны могут показать случаи, когда предлагаемый ими алгоритм делает маршрутизацию более простой и понятной, нежели другой алгоритм. Данный вариант имеет те же преимущества и недостатки, что и алгоритм, описанный в параграфе 5.2.4.3, с той лишь разницей, что он использует правило Weak TOS до правила Longest Match и это делает его вариант менее совместимым с протоколами OSPF и Integrated IS-IS, нежели стандартный алгоритм, предложенный в Router Requirements.

E.3.3 Алгоритм OSPF

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

Этапы сокращения перечислены ниже.

  1. Basic match (базовое соответствие).

  2. Route Classes OSPF (класс маршрута OSPF).

  3. Longest match (максимальная длина соответствия).

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

  5. Best metric (лучшая метрика).

  6. Policy (политика).

Поддержка этапа сокращения по типу обслуживания присутствует не всегда. При ее отсутствии этап 4 просто не выполняется.

Данный алгоритм имеет некоторые преимущества по сравнению с пересмотренным классическим алгоритмом.

  1. Поддержка маршрутизации по типу обслуживания.

  2. Правила документированы, а не являются частью фольклора Internet.

  3. Алгоритм (очевидно) работает с протоколом OSPF.

Однако этот алгоритм сохраняет некоторые недостатки пересмотренного классического алгоритма.

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

  2. Как и пересмотренный классический алгоритм, этот алгоритм не описывает детали (и не требует наличия) этапа Policy, что делает этот шаг существенно зависимым от разработчика.

Алгоритм OSPF имеет дополнительный недостаток (отсутствующий в пересмотренном классическом алгоритме) – внутренние (intra-area или inter-area) маршруты OSPF всегда рассматриваются, как более приоритетные по сравнению с маршрутами, полученными от других протоколов маршрутизации, даже если маршрут OSPF имеет меньшую длину совпадения с адресом получателя. Такое решение на уровне политики может оказаться недопустимым в некоторых сетях.

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

E.3.4 Алгоритм Integrated IS-IS

Протокол Integrated IS-IS использует алгоритм, который почти совпадает с алгоритмом OSPF. Отличие состоит в том, что Integrated IS-IS использует другой набор классов и несколько иначе обрабатывает поле TOS. Этапы сокращения перечислены ниже.

  1. Basic match (базовое соответствие).

  2. IS-IS Route Classes (классы маршрутов IS-IS).

  3. Longest match (максимальная длина соответствия).

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

  5. Best metric (лучшая метрика).

  6. Policy (политика).

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

Поддержка сокращения по типу обслуживания не является обязательной. Если такое сокращение не используется, этап 4 просто пропускается. Как и для OSPF, спецификация не включает описания этапа Policy.

Данный алгоритм имеет некоторые преимущества по сравнению с пересмотренным классическим алгоритмом.

  1. Поддержка маршрутизации по типу обслуживания.

  2. Правила документированы, а не являются частью фольклора Internet.

  3. Алгоритм (очевидно) работает с протоколом Integrated IS-IS.

Однако этот алгоритм сохраняет некоторые недостатки пересмотренного классического алгоритма.

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

  2. Как и пересмотренный классический алгоритм, этот алгоритм не описывает детали (и не требует наличия) этапа Policy, что делает этот шаг существенно зависимым от разработчика.

  3. Алгоритм не поддерживает OSPF по причине различий между классами маршрутов в IS-IS и OSPF. Кроме того, в силу ограниченной поддержки протоколом IS-IS значений поля TOS, некоторые реализации алгоритма Integrated IS-IS не поддерживают принятую в OSPF интерпретацию TOS.

Алгоритм Integrated IS-IS имеет дополнительный недостаток (отсутствующий в пересмотренном классическом алгоритме) – внутренние (intra-area или inter-area) маршруты IS-IS всегда рассматриваются как более приоритетные по сравнению с маршрутами, полученными от других протоколов маршрутизации, даже если маршрут IS-IS имеет меньшую длину совпадения с адресом получателя. Такое решение на уровне политики может оказаться недопустимым в некоторых сетях.

Наконец, следует отметить, что поддержка TOS в алгоритме Integrated IS-IS отличается теми же недостатками, которые были указаны для алгоритма OSPF.

Вопросы безопасности

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

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

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

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

К сожалению, это характеризует современное состояние вопроса. Лишь немногие сетевые протоколы, используемые в маршрутизаторах, имеют хорошо проработанные встроенные средства обеспечения безопасности. Производители и разработчики протоколов по-прежнему уделяют достаточно мало внимания вопросам защиты. Прогресс наблюдается и в этом направлении, но идет он очень мелкими «детскими» шагами (такими, как добавление проверки подлинности партнеров для протоколов маршрутизации BGP и OSPF).

В частности, в данном документе отмечены современные исследования в направлении разработки и совершенствования средств обеспечения сетевой безопасности. Направления исследования и разработки на момент создания документа (декабрь 1993) включали IP Security, SNMP Security и технологии проверки подлинности общего назначения.

Несмотря на сказанное выше, существуют доступные как производителям, так и пользователям меры повышения уровня безопасности для маршрутизаторов. Производителям следует обзавестись копией документа Trusted Computer System Evaluation Criteria [INTRO:8]. Даже если производитель не пожелает выполнить формальности по проверке соответствия продукции требованиям указанного документа, последний обеспечит превосходное руководство по вопросам безопасности для вычислительной техники.

Приложение F: История протоколов маршрутизации

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

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

F.1 Протокол внешнего шлюза EGP

F.1.1 Введение

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

EGP определен в документе [ROUTE:6]. Разработчики скорей всего захотят прочесть также документы [ROUTE:7] и [ROUTE:8], содержащие полезные объяснения и фундаментальные материалы.

Обсуждение

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

RFC 975 не является частью спецификации EGP и этот документ следует игнорировать.

F.1.2 «Сквозной контроль» протокола

Непрямые соседи – RFC 888, стр. 26

Реализация EGP должна включать поддержку непрямых соседей (indirect neighbor).

Интервалы опроса – RFC 904, стр. 10

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

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

Доступность соседей – RFC 904, стр. 15

По умолчанию для реализации недопустимо предоставление внешнего списка маршрутизаторов в другие автономные системы – в пакеты Update Response/Indication следует включать только внутренний список маршрутизаторов вместе с сетями, доступными через них. Однако реализация может поддерживать конфигурационный параметр, разрешающий предоставление списка внешних маршрутизаторов. Для реализации протокола недопустимо включение во внешний список маршрутизаторов, полученных из внешних списков маршрутизаторов других автономных систем, т. е. должна выполняться операция «расщепления горизонта» (split-horizon) на уровне автономной системы.

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

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

Незапрошенные обновления – RFC 904, стр. 16

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

Доступность соседей – RFC 904, стр. 6, 13-15

Таблица на стр. 6, которая описывает значения j и k (пороги up и down для соседа), содержит некорректную информацию. Корректная таблица приведена ниже.

      Name    Active  Passive Description
      -----------------------------------------------
       j        3       1     neighbor-up threshold
       k        1       0     neighbor-down threshold

Значение для k в пассивном режиме также указано некорректно на стр. 14 документа RFC 904. Значения в скобках следует читать как:

(j = 1, k = 0, and T3/T1 = 4)

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

Таймер прерывания – RFC 904, стр. 6, 12, 13

Реализация EGP должна включать поддержку таймера прерывания, описанного в параграфе 4.1.4 RFC 904. Реализации следует использовать таймер прерывания в состоянии Idle для автоматической генерации события Start с целью перезапуска машины протокола. Рекомендуются значение P4 для критических ошибок (Administratively prohibited, Protocol Violation и Parameter Problem) и P5 – для прочих ошибок. Не следует запускать таймер прерывания при ручной генерации событий Stop (например, с использованием протокола управления сетью).

Получение команды Cease в состоянии Idle – RFC 904, стр. 13

Когда машина состояний EGP находится в состоянии Idle, она должна отвечать на команды Cease откликами Cease-ack.

Режим Hello Polling – RFC 904, стр. 11

Реализация EGP должна включать поддержку активного и пассивного режимов опроса.

Сообщения Neighbor Acquisition – RFC 904, стр. 18

Как отмечено, интервалы Hello и Poll следует включать только в сообщения Request и Confirm. Поэтому размер сообщений EGP Neighbor Acquisition составляет 14 байтов для Request или Confirm и 10 байтов для Refuse, Cease или Cease-ack. Для реализации протокола недопустимо передавать 14-байтовые сообщения Refuse, Cease или Cease-ack, но такие сообщения должны приниматься от других.

Порядковые номера – RFC 904, стр. 10

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

F.2 Протокол RIP

F.2.1 Введение

Спецификация протокола RIP содержится в документе [ROUTE:3]. Хотя протокол RIP играет достаточно важную роль в Internet, он будет заменяться более современными протоколами IGP (такими, как описано выше). Маршрутизаторам, реализующим протокол RIP, следует поддерживать RIP версии 2 [ROUTE:?]76, если они поддерживают маршруты CIDR. Если в сети используется коммутируемый доступ (occasional access), маршрутизаторам, реализующим RIP, следует поддерживать расширение Demand RIP [ROUTE:?]77.

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

F.2.2 Общие вопросы

Реакция на изменения топологии – [ROUTE:3], стр. 11

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

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

Обсуждение

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

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

Реализация

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

Split Horizon – [ROUTE:3], стр. 14-15

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

Реализации RIP следует поддерживать схему Split horizon with poisoned reverse78 – вариант «расщепления горизонта», который включает передачу маршрутов, полученных от какого-либо маршрутизатора, ему же с установкой бесконечного значения метрики. Поскольку эта схема увеличивает объем служебного трафика, реализация протокола может включать опцию, определяющую, когда следует возвращать «испорченный» маршрут. Реализации следует ограничивать время, когда она передает обратно маршруты с бесконечной метрикой.

Реализация

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

Задачей обоих алгоритмов является обеспечение «порчи» возвращаемого маршрута для всех маршрутов, которые были изменены в течение последнего интервала Route Lifetime (обычно 180 сек.), если нет уверенности в том, что предыдущий маршрут использует тот же выходной интерфейс. Значение Route Lifetime используется по той причине, что оно задает время, в течение которого RIP будет сохранять старый маршрут до объявления его состояния.

В этих алгоритмах используются перечисленные ниже временные интервалы.

Tu (The Update Timer – таймер обновления) – число секунд между обновлениями RIP, по умолчанию обычно составляет 30 секунд.

Rl (The Route Lifetime – время жизни маршрута) – число секунд, в течение которых маршрут предполагается пригодным без необходимости обновления, по умолчанию обычно 180 сек.

Ul (The Update Loss – число потерянных обновлений) – число последовательных обновлений, которые могут быть потеряны или не получены по причине отказа до того, как RIP удалит маршрут. Значение Ul рассчитывается, как (Rl/Tu)+1. Единица добавляется для того, чтобы учесть, что до первого уменьшения значения счетчика ifcounter проходит менее Tu секунд с момента инициализации. Обычно параметр Ul имеет значение 7 = (180/30)+1.

In – значение счетчика ifcounter в момент получения (обновления) информации о маршруте. Это значение составляет Ul-4 (4 – значение таймера сборки мусора RIP, разделенное на 30).

Первый алгоритм

    • С каждым маршрутом (destination) ассоциируется счетчик ifcounter. «Испорченный» маршрут возвращается для всех маршрутов, которые имеют положительное значение ifcounter.

    • После передачи обычного (не инициированного – triggered или вызванного запросом) обновления все отличные от 0 значения ifcounter уменьшаются на 1.

    • При создании маршрута счетчик ifcounter устанавливается с учетом следующих условий:

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

      • если новый маршрут устанавливается взамен статического и прежний маршрут использует иной (логический) выходной интерфейс, устанавливается ifcounter = MAX(0, Ul – INT(число секунд, в течение которых маршрут был в состоянии stale, деленное на Ut);

      • если такого маршрута не было совсем, устанавливается ifcounter = In;

      • во всех прочих случаях устанавливается ifcounter = 0.

    • Протокол RIP также поддерживает таймер сброса (resettimer). «испорченный» маршрут возвращается всем маршрутизаторам, для которых не истекло время resettimer (независимо от значения ifcounter).

    • При старте, перезапуске, сбросе и в других случаях очистки таблицы маршрутов RIP протокол устанавливает для таймера сброса значение Rl.

Второй алгоритм отличается от первого тем, что:

  • в тех случаях, когда для счетчика ifcounter устанавливается ненулевое значение, оно всегда равно Rl/Tu;

  • таймер сброса не используется.

Инициированные (Triggered) обновления – [ROUTE:3], стр. 15-16; стр. 29

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

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

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

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

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

  4. Флаг сбрасывается также при передаче обычного обновления.

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

Обсуждение

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

Использование UDP – [ROUTE:3], стр. 18-19.

В пакетах RIP, передаваемых по широковещательным адресам IP, следует устанавливать начальное значение TTL = 1.

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

Вопросы адресации – [ROUTE:3], стр. 22

Реализации RIP следует поддерживать маршруты к хостам (host route). При отсутствии такой поддержки маршруты к хостам, полученные в обновлениях, должны игнорироваться, как указано на стр. 27 документа [ROUTE:3]. Маршрутизатор может протоколировать отбрасывание маршрутов к хостам.

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

Обработка принимаемой информации – отклики: [ROUTE:3], стр. 26

При обработке обновлений должны выполняться следующие проверки:

  • отклики должны приходить из порта UDP с номером 520;

  • адрес отправителя должен относиться к непосредственно подключенной подсети (или сети без подсетей);

  • недопустимо принимать пакеты, в которых адрес совпадает с одним из адресов маршрутизатора.

Обсуждение

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

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

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

F.2.3 Частные вопросы

RIP Shutdown

Реализации протокола RIP следует поддерживать процедуру изящного завершения работы (graceful shutdown) с использованием перечисленных ниже этапов.

  1. Завершение обработки входящей информации.

  2. Генерация 4 обновлений со случайными интервалами от 2 до 4 секунд. Эти обновления содержат все маршруты, которые были анонсированы ранее, но с некоторыми изменениями в их метрике. Маршруты с бесконечной метрикой не изменяются, а маршруты с конечной метрикой должны быть анонсированы с метрикой 15 (бесконечность – 1).

Обсуждение

На самом деле в п. (2) должна устанавливаться метрика 16 (бесконечность). Установка значения 15 обусловлена желанием предотвратить проблемы на некоторых старых хостах, которые перехватывают протокол RIP. Такие хосты будут (ошибочно) разрывать соединения TCP при попытке передачи дейтаграммы через соединение в то время, когда нет пути к адресату (даже если период отсутствия пути составляет лишь несколько секунд, пока RIP выбирает другой путь к адресату).

RIP Split Horizon и статические маршруты

Схему Split horizon следует по умолчанию применять к статическим маршрутам. Реализации протокола следует обеспечивать для каждого статического маршрута возможность указать, следует ли для него использовать «расщепление горизонта».

F.3 Протокол обмена между шлюзами – GGP

Протокол GGP79 признан устаревшим и реализовать его не следует.

Благодарности

Если б нам

Хотя бы десять тысяч англичан

Из тех, что праздными теперь сидят

На родине!

Кто этого желает?

Кузен мой Уэстморленд? Ну нет, кузен:

Коль суждено погибнуть нам, – довольно

Потерь для родины; а будем живы, –

Чем меньше нас, тем больше будет славы.

Да будет воля божья! Не желай

И одного еще бойца нам в помощь.

Клянусь Юпитером, не алчен я!

Мне все равно: пусть на мой счет живут;

Не жаль мне: пусть мои одежды носят,

Вполне я равнодушен к внешним благам.

Но, если грех великий – жаждать славы,

Я самый грешный из людей на свете.

Нет, не желай, кузен, еще людей нам.

Клянусь создателем, я б не хотел

Делиться славой с лишним человеком.

Нет, не желай подмоги, Уэстморленд,

А лучше объяви войскам, что всякий,

Кому охоты нет сражаться, может

Уйти домой; получит он и пропуск

И на дорогу кроны в кошелек.

Я не хотел бы смерти рядом с тем,

Кто умереть боится вместе с нами.

Сегодня день святого Криспиана;

Кто невредим домой вернется, тот

Воспрянет духом, станет выше ростом

При имени святого Криспиана.

Кто, битву пережив, увидит старость,

Тот каждый год и канун, собрав друзей.

Им скажет; “Завтра праздник Криспиана”,

Рукав засучит и покажет шрамы:

“Я получил их в Криспианов день”.

Хоть старики забывчивы, но этот

Не позабудет подвиги свои

В тот день; и будут наши имена

На языке его средь слов привычных:

Король наш Гарри, Бедфорд, Эксетер,

Граф Уорик, Толбот, Солсбери и Глостер

Под звон стаканов будут поминаться.

Старик о них расскажет повесть сыну,

И Криспианов день забыт не будет

Отныне до скончания веков;

С ним сохранится память и о нас –

О нас, о горсточке счастливцев, братьев.

Тот, кто сегодня кровь со мной прольет,

Мне станет братом: как бы ни был низок,

Его облагородит этот день;

И проклянут свою судьбу дворяне,

Что в этот день не с нами, а в кровати:

Язык прикусят, лишь заговорит

Соратник наш в бою в Криспинов день.

Уильям Шекспир (перевод Е. Бируковой)

Этот документ является результатом работы группы IETF Router Requirements. Подобные документы включают в себя результаты работы многих людей, которые могут быть указаны в тексте документа. Множество производителей оборудования и программ, сетевых администраторов и других специалистов из сообщества Internet потратили свое время и силы на повышение качества этого документа. Редактор хочет выразить им всем свою искреннюю благодарность.

Нынешний редактор документа также хочет выразить свою искреннюю признательность и и высокую оценку работы первого редактора документа – Филиппа Алмквиста (Philip Almquist). Без его работы в качестве редактора и руководителя группы этот документ просто не был бы написан. Хочется также выразить глубокую и искреннюю признательность редактору предыдущей версии документа – Фрэнку Кастенхольцу (Frank Kastenholz). Фрэнк из набора разрозненной информации создал законченный документ, содержащий полезные описания технологии IP в ее состоянии на 1991 год. Остается лишь надеяться, что современное (1994 год) отражение этой технологии также окажется полезным и понятным.

Philip Almquist, Jeffrey Burgan, Frank Kastenholz и Cathy Wittbrodt написали основные части этого документа. К числу людей, которые также внесли свой вклад в написание основной части, относятся Bill Barns, Steve Deering, Kent England, Jim Forster, Martin Gross, Jeff Honig, Steve Knowles, Yoni Malachi, Michael Reilly, Walt Wimer.

В документ также включены материалы, которые подготовили Andy Malis, Paul Traina, Art Berggreen, John Cavanaugh, Ross Callon, John Lekashman, Brian Lloyd, Gary Malkin, Milo Medin, John Moy, Craig Partridge, Stephanie Price, Yakov Rekhter, Steve Senum, Richard Smith, Frank Solensky, Rich Woundy и другие, кто незаслуженно опущен в этом списке.

Некоторые фрагменты этого документа были заимствованы из более ранних документов (в основном из RFC 1122, который подготовил Bob Braden и группа Host Requirements, а также RFC 1009, который написали Bob Braden и Jon Postel). Благодарим авторов этих документов за их работу.

Jim Forster был сопредседателем рабочей группы Router Requirements на раннем этапе деятельности и внес важный вклад в успешный старт работы. Jon Postel, Bob Braden и Walt Prue также внесли свой вклад в успех, обеспечив подготовку обширной информации перед началом работы группы. На следующих этапах работы Phill Gross, Vint Cerf и Noel Chiappa обеспечивали участников группы ценной информацией и поддержкой.

Mike St. Johns координировал взаимодействие группы со специалистами по безопасности, а Frank Kastenholz – со специалистами по сетевому управлению. Allison Mankin и K. K. Ramakrishnan обеспечили экспертизу по вопросам контроля насыщения и распределения ресурсов.

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

Редактор благодарит своего работодателя – Cisco Systems – за возможность тратить время на эту работу.

Адрес редактора

Fred Baker

Cisco Systems

519 Lado Drive

Santa Barbara, California 93111

USA

Phone:+1 805-681-0115

EMail: fred@cisco.com

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

1American National Standards Institute – Национальный институт стандартов США.

2Протокол обмена маршрутной информацией между промежуточными системами.

3Border Gateway Protocol – протокол граничного шлюза.

4В оригинале ошибочно указан параграф 7.2.4. Прим. перев.

5Независимых процессов. Прим. перев.

6В имеющемся на сайте RFC 1123 эта глава носит название “Удаленное управление”. Прим. перев.

7Bootstrap Protocol – протокол загрузки.

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

9Не подключенного к сетям. Прим. перев.

10В современных маршрутизаторах изменение адреса IP на сетевом интерфейсе обычно не требует перезагрузки. Прим. перев.

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

12В RFC 1395, RFC 1497, RFC 1532, RFC 1542 и RFC 5494 содержатся изменения и дополнения. Прим. перев.

13Этот документ заменен RFC 2132. Прим. перев.

14Этот документ доступен в сети — том1, том 2, том 3. Прим. перев.

15Копия статьи доступна по ссылке http://www.cse.ucsc.edu/research/ccrg/CMPE252/Papers/1974.pdf. Прим. перев.

16Книга доступна по ссылке. Прим. перев.

17В настоящее время список стандартов Internet доступен по ссылке http://www.rfc-editor.org/rfcxx00.html. Прим. перев.

18В настоящее время этот стандарт адаптирован в Российской федерации, как ГОСТ Р ИСО 7498-2-99. Прим. перев.

19В исходном документе ошибочно указано ISO 7489. Прим. перев.

20В исходном документе по ошибке номер RFC не указан. Прим. перев.

21Этот документ заменен RFC 1819. Прим. перев.

22Эта работа опубликована также в RFC 970. Прим. перев.

23Документ доступен по ссылке http://arxiv.org/ftp/cs/papers/9809/9809095.pdf. Прим. перев.

24Документ доступен по ссылке. Прим. перев.

25Документ доступен по ссылке http://www.cs.ucsb.edu/~ravenben/classes/276/papers/pf95.pdf. Прим. перев.

26Документ доступен по ссылке http://www-net.cs.umass.edu/cs691s/leland.pdf. Прим. перев.

27Документ доступен по ссылке http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/pp_sigcomm.pdf. Прим. перев.

28Документ доступен по ссылке http://cseweb.ucsd.edu/classes/fa01/cse222/papers/jain-decbit-tocs90.pdf. Прим. перев.

29Документ доступен по ссылке. Прим. перев.

30Документ доступен по ссылке http://pages.cs.wisc.edu/~suman/courses/640/papers/clark92sigcomm.pdf. Прим. перев.

31В RFC 2236, который был заменен RFC 3376, содержатся изменения и дополнения к этому документу. Прим. перев.

32В RFC 1624 содержатся изменения и дополнения к этому документу. Прим. перев.

33В RFC 950 и RFC 4884 содержатся изменения и дополнения к этому документу. Прим. перев.

34Этот документ обновлен RFC 4632. Прим. перев.

35Этот документ заменен RFC 1108. Прим. перев.

36Этот документ утратил силу и заменен настоящим RFC 1812. Прим. перев.

37В RFC 3232 документ Assigned Numbers отменен, данные доступны на сайте www.iana.org. Прим. перев.

38Копия этого документа доступна на сайте http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html. Прим. перев.

39Этот документ заменен RFC 1983. Прим. перев.

40В RFC 2153 содержатся изменения и дополнения к этому документу. Прим. перев.

41Этот документ обновлен RFC 3241. Прим. перев.

42Этот документ заменен RFC 1994, который был обновлен RFC 2484. Прим. перев.

43Этот документ заменен RFC 1989. Прим. перев.

44В RFC 2011, RFC 2012, RFC 2013 содержатся изменения и дополнения к этому документу. Прим. перев.

45Этот документ заменен RFC 1623, который был заменен RFC 1643, а тот был отменен RFC 3638. Прим. перев.

46В RFC 1239 содержатся изменения и дополнения к этому документу. Прим. перев.

47Этот документ заменен RFC 1743, а тот, в свою очередь, – RFC 1748. Прим. перев.

48Этот документ заменен RFC 1659. Прим. перев.

49Этот документ заменен RFC 1850, а тот, в свою очередь, – RFC 4750. Прим. перев.

50Этот документ заменен RFC 4273. Прим. перев.

51Этот документ заменен RFC 2495, тот – RFC 3895, а последний – RFC 4805. Прим. перев.

52Этот документ заменен RFC 2496, а тот – RFC 3896. Прим. перев.

53Этот документ заменен RFC 1573, тот – RFC 2233, а последний – RFC 2863. Прим. перев.

54Этот документ заменен RFC 1694. Прим. перев.

55Этот документ заменен RFC 2096, а тот – RFC 4292. Прим. перев.

56Этот документ заменен RFC 4789. Прим. перев.

57В RFC 1512 содержатся изменения и дополнения к этому документу. Прим. перев.

58В RFC 1782 – RFC 1785, RFC 2347 – RFC 2349 содержатся изменения и дополнения к этому документу. Прим. перев.

59Этот документ заменен RFC 2178, а тот – RFC 2328, обновленным в RFC 5709. Прим. перев.

60В RFC 1349 (отменен RFC 2474) содержатся изменения и дополнения к этому документу. Прим. перев.

61В RFC 1388 (отменен RFC 1723, который, в свою очередь, был отменен RFC 2453, обновленным RFC 4822) содержатся изменения и дополнения к этому документу. Прим. перев.

62Спецификация современной версии протокола BGP-4 содержится в RFC 4271. Прим. перев.

63В RFC 904 содержатся изменения и дополнения к этому документу. Прим. перев.

64Копия этой статьи доступна по ссылке http://pages.cs.wisc.edu/~akella/CS740/S08/740-Papers/DC88.pdf. Прим. перев.

65Этот документ заменен RFC 2474, который был обновлен в RFC 3168 и RFC 3260. Прим. перев.

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

67В буквальном переводе – «фильтрация марсианских пакетов». Прим. перев.

68Distance Vector Multicast Routing Protocol.

69Разработка протокола завершена и его спецификация опубликована в RFC 1584. Прим. перев.

70Protocol Independent Multicast — независимая от протокола групповая адресация.

71Спецификация протокола PIM-SM (Sparse Mode) опубликована в RFC 2362. Прим. перев.

72Размышления о следующем интервале.

73BBN Core Gateway – маршрутизаторы, которые составляли опорную сеть Internet тех времен.

74Выбор маршрута при одинаковой длине соответствия. Прим. перев.

75Inter-Domain Policy Routing – междоменная маршрутизация на основе правил

76Современный вариант спецификации протокола RIPv2 содержится в RFC 1721. Прим. перев.

77Это расширение описано в RFC 1582. Прим. перев.

78«Расщепление горизонта» с возвратом «испорченного» маршрута.

79GATEWAY TO GATEWAY PROTOCOL – протокол взаимодействия шлюзов.

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

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

Or