Please enter banners and links.

Network Working Group                               F. Baker, Editor
Request for Comments: 1812                             Cisco Systems
Obsoletes: 1716, 1009                                      June 1995
Category: Standards Track

 

Требования к маршрутизаторам IPv4

Requirements for IP Version 4 Routers

PDF

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

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

Предисловие

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

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

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

1. Введение

Этот документ заменяет RFC 1716 «Requirements for Internet Gateways» ([INTRO:1]).

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

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

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

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

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

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

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

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

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

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

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

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

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

1.1 Работа с документом

1.1.1 Организация документа

В этом документе используется многоуровневая структура, как в [INTRO:2] и [INTRO:3]. Глава 2 описывает уровни архитектуры Internet. В главе 3 рассматривается канальный уровень (Link Layer), главы 4 и 5 посвящены протоколам сетевого уровня (Internet Layer) и механизмам пересылки, в главе 6 обсуждается транспортный уровень (Transport Layer). Протоколам вышележащих уровней посвящены главы 7 – 9. В главе 7 обсуждаются протоколы обмена маршрутной информацией, в главе 8 рассматриваются вопросы управления сетями, а в главе 9 обсуждаются прочие протоколы вышележащих уровней. В заключительной главе рассматриваются функции эксплуатации и обслуживания. Такая организация документа выбрана в целях простоты, ясности и соответствия структуре RFC, описывающих требования к хостам. Приложения к данному документу включают библиографию, глоссарий и некоторые прогнозы в части будущих направлений стандартизации маршрутизаторов.

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

Все основные части данного документа включают в себя несколько параграфов:

1. Введение

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

3. Частные вопросы – обсуждается устройство протокола и вопросы реализации, которые не были включены в общий раздел.

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

1.1.2 Уровни требований

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

• Обязательно (MUST)

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

• Обязательно для реализации (MUST IMPLEMENT)

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

• Недопустимо (MUST NOT)Этот уровень используется для обозначения полного запрета.
• Следует (SHOULD)

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

• Следует реализовать (SHOULD IMPLEMENT)

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

• Не следует (SHOULD NOT)

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

• Возможно (MAY)

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

1.1.3 Соответствие спецификации

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

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

Реализация считается условно совместимой с данной спецификацией, если она соответствует всем общим требованиям уровней MUST, MUST IMPLEMENT и MUST NOT. При выполнении всех общих требований уровней SHOULD, SHOULD IMPLEMENT, и SHOULD NOT реализация считается безусловно совместимой. Реализация не соответствует требованиям, если она не является условно (или безусловно) совместимой (т. е., в ней не выполняется хотя бы одно из общих требований уровня MUST, MUST IMPLEMENT или MUST NOT).

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

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

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

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

1.2 Отношения с другими стандартами

Существует несколько документов, тесно связанных с данной спецификацией:

• INTERNET OFFICIAL PROTOCOL STANDARDS

  Этот документ описывает процесс принятия стандартов Internet и содержит списки стандартов для протоколов с указанием состояния каждого стандарта. На момент подготовки документа текущая версия STD 1 была представлена в RFC 1780¹, [ARCH:7]. Этот документ периодически обновляется и следует пользоваться его последней версией.

• Assigned Numbers

  В этом документе содержится список значений, выделенных для параметров, которые используются различными протоколами. Например, коды протоколов IP, номера портов TCP, коды опций Telnet, типы оборудования ARP, имена Terminal Type. На момент подготовки спецификации текущая версия STD 2 содержалась в RFC 1700, [INTRO:7]². Данный документ периодически обновляется и следует пользоваться последней версией.

• Host Requirements

  Эта пара документов содержит спецификации требований к хостам и разъяснения неоднозначностей в спецификациях стандартов. Отметим, что указанные в этих документах требования применимы и к маршрутизаторам, если в настоящем документе явно не сказано иное. На момент подготовки этого документа текущая версия требований к хостам опубликована в RFC 1122 и RFC 1123 (STD 3), [INTRO:2] и [INTRO:3].

• Router Requirements (ранее Gateway Requirements)Настоящий документ.

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

Эти и другие протоколы Internet можно получить по адресу: The InterNIC DS.INTERNIC.NET InterNIC Directory and Database Service [email protected] +1-908-668-6587 URL: http://ds.internic.net/³

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

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

1.3.1 Постоянное изменение Internet

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

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

1.3.2 Принцип устойчивости

Для протоколов всех уровней существует общее правило, которому приложения должны следовать во избежание проблем с устойчивостью и интероперабельностью [TRANS:2]:

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

Программы должны уметь обрабатывать все мыслимые ошибки; не имеет значения вероятность возникновения той или иной ошибки – раньше или позже пакет с любой возможной комбинацией ошибок и/или атрибутов будет получен и программа должна быть готова к обработке такого пакета. Если программа не может эффективно обрабатывать ошибки, она приведет прямой дорогой к хаосу. В общем случае лучше предположить, что сеть наводнена зловредными объектами, которые постоянно передают пакеты, предназначенные для нанесения максимального вреда. Такое предположение обеспечит высокий уровень защиты. Наиболее серьезные проблемы в Internet связаны с неисследованными механизмами, включающимися с малой вероятностью; намерения обычных злоумышленников никогда не могут принести такого вреда!

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

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

1.3.3 Протоколирование ошибок

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

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

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

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

Дополнительную информацию по вопросам протоколирования работы вы найдете в [MGT:5].

1.3.4 Настройка конфигурации

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

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

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

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

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

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

1.4 Алгоритмы

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

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

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

2. Архитектура INTERNET

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

Рассмотрению основ архитектуры Internet и поддерживаемых протоколов посвящена книга DDN Protocol Handbook [ARCH:1], основы архитектуры рассмотрены также в работах [ARCH:2], [ARCH:3], [ARCH:4]. Архитектура и протоколы Internet рассматриваются также во многих книгах, включая [ARCH:5] и [ARCH:6].

2.1 Введение

Сеть Internet состоит из множества соединенных между собой пакетных сетей, которые поддерживают обмен информацией между хостами на основе стека протоколов Internet. Этот стек включает IP⁵, ICMP⁶, IGMP⁷ и различные протоколы транспортного и прикладного уровня. Как указано в параграфе 1.2, IESG⁸ периодически выпускает документ Official Protocols, содержащий список всех протоколов Internet.

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

Гарантированная доставка данных в стеке протоколов Internet обеспечивается с помощью протоколов транспортного уровня типа TCP⁹, которые поддерживают сквозное управление соединениями, повторной передачей и порядком доставки пакетов. На транспортном уровне также обеспечивается сервис без организации прямых соединений (connectionless) на основе протокола UDP¹⁰.

2.2 Элементы архитектуры

2.2.1 Протокольные уровни

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

Уровни протоколов, используемые в архитектуре Internet, описаны в работе [ARCH:7]:

• Прикладной уровень (Application Layer)

  Прикладной уровень располагается в верхней части стека протоколов Internet. В стеке Internet прикладной уровень не разделен на подуровни, хотя некоторые из протоколов прикладного уровня Internet содержат внутренние подуровни. Прикладной уровень стека Internet объединяет в себе функции двух уровней (Presentation – уровень представления и Application – прикладной) эталонной модели OSI [ARCH:8].

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

  • Telnet (удаленный вход в систему);
  • FTP (передача файлов);
  • SMTP (доставка электронной почты).

  Существует также множество стандартизованных и частных пользовательских протоколов.

  Служебные протоколы используются для преобразования имен, загрузки ОС и управления – к числу таких протоколов относятся SNMP, BOOTP, RARP, DNS (Domain Name System) и многочисленные протоколы маршрутизации.

  Относящиеся к маршрутизаторам протоколы прикладного уровня рассмотрены в главах 7 – 9.

• Транспортный уровень (Transport Layer)

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

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

  • Transmission Control Protocol (TCP) – протокол управления передачей;
  • User Datagram Protocol (UDP) – протокол пользовательских дейтаграмм.

  TCP представляет собой основанный на соединениях (connection-oriented) транспортный сервис с гарантированной доставкой пакетов, обеспечивающий надежную доставку с сохранением порядка пакетов и управлением потоком данных. Протокол UDP не использует явных соединений (connectionless) и передает данные в виде дейтаграмм без гарантии доставки. Исследовательскими организациями были разработаны и другие протоколы транспортного уровня, которые могут получить статус стандартных протоколов.

  Более подробное описание протоколов транспортного уровня приведено в главе 6.

• Уровень Internet (Internet Layer)

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

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

  Управляющий протокол ICMP является важной составной частью IP, хотя с точки зрения архитектуры он работает поверх IP (т. е., использует IP для передачи данных, подобно транспортным протоколам TCP и UDP). ICMP обеспечивает доставку сообщений об ошибках, насыщении сети и перенаправлении пакетов для первого маршрутизатора (first-hop).

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

  Протоколы уровня Internet (IP, ICMP и IGMP) более подробно рассмотрены в главе 4.

• Канальный уровень (Link Layer)

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

  В некоторых старых документах этот уровень называется сетевым (Network Layer), но это совсем не то, что сетевой уровень модели OSI.

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

  Протоколы канального уровня в общем случае не попадают в сферу стандартов Internet – в сети Internet просто используются существующие стандарты, когда это возможно. Таким образом, стандарты Internet для канального уровня отвечают только за преобразование адресов и передачу пакетов IP с использованием того или иного протокола канального уровня. Стандарты Internet для канального уровня рассмотрены в главе 3.

2.2.2 Сети

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

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

Входящие в Internet сети можно разделить на два основных класса:

• Локальные сети (ЛВС, LAN)

  ЛВС могут быть устроены по-разному. В общем случае ЛВС обычно имеет небольшие размеры в пространстве (например, одно или несколько зданий) и обеспечивает широкополосные каналы с малыми задержками. Локальные сети могут быть пассивными (например, Ethernet) или активными (например, ATM).

• Распределенные сети (WAN)

  Разнесенные на значительные расстояния хосты и ЛВС объединяются в так называемые распределенные или территориальные сети¹¹. Такие сети могут иметь сложную внутреннюю структуру каналов и пакетных коммутаторов, а могут строиться на базе простых соединений «точка-точка».

2.2.3 Маршрутизаторы

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

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

Маршрутизатор соединяет два или более логических интерфейса, представленные подсетями IP или безадресными соединениями «точка-точка» (см. параграф 2.2.7). Таким образом, каждый маршрутизатор имеет по крайней мере один физический интерфейс. Пересылка дейтаграмм IP в общем случае требует от маршрутизатора выбрать адрес и подходящий интерфейс для передачи пакета следующему маршрутизатору (next-hop) или конечному получателю. Этот выбор, называемый трансляцией (relaying) или пересылкой (forwarding), зависит от базы маршрутных данных в маршрутизаторе. Эту базу данных называют также таблицей пересылки или таблицей маршрутизации. Термин «маршрутизатор» происходит от процесса построения маршрутной базы данных; протоколы маршрутизации и параметры конфигурации взаимодействуют между собой в процессе, называемом маршрутизацией.

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

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

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

2.2.4 Автономные системы

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

Концепция автономных систем играет важную роль в маршрутизации Internet (см. параграф 7.1).

2.2.5 Архитектура адресации

Дейтаграммы IP содержат 32-битовые адреса отправителя и получателя и каждый из этих адресов делится на 2 части, называемые префиксом сети и номером хоста в данной сети:

IP-address ::= { <Network-prefix>, <Host-number> }

Для доставки дейтаграммы конечному адресату последний маршрутизатор на пути должен отобразить номер хоста (Host-number) или полный адрес IP на адрес канального уровня для этого хоста.

2.2.5.1 Классическая архитектура адресации IP

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

Простейшими вариантами префиксов в классической схеме являются префиксы сетей класса A, B, C, D и E. Эти префиксы можно идентифицировать по значениям старших битов адреса, что позволяет легко разделить адрес на префикс сети и номер хоста. Префиксы классической адресации подробно рассматриваются в [INTERNET:18], а краткое их описание приведено ниже:

0xxx – класс A – индивидуальные адреса общего назначения со стандартным 8-битовым префиксом

10xx – класс B – индивидуальные адреса общего назначения со стандартным 16-битовым префиксом

110x – класс C – индивидуальные адреса общего назначения со стандартным 24-битовым префиксом

1110 – класс D – групповые адреса (IP Multicast) с 28-битовым префиксом без возможности агрегирования

1111 – класс E – зарезервирован для экспериментов.

Эта простая нотация была расширена путем введения концепции подсетей. Подсети потребовались для того, чтобы можно было создавать сколь угодно сложные структуры ЛВС в организациях без взрывного роста числа сетевых префиксов и усложнения маршрутизации. Подсети обеспечивают многоуровневую иерархию структуры маршрутизации для Internet. Связанное с подсетями расширение, описанное в [INTERNET:2], является обязательной частью архитектуры Internet. Основная идея заключается в разделении поля <Host-number> на две части – номер подсети и номер хоста в этой подсети:

IP-address ::={ <Network-number>, <Subnet-number>, <Host-number> }

Соединенные между собой физические сети организации используют общий префикс, но различаются номерами подсетей. Эти различия между подсетями обычно невидимы за пределами сети. Таким образом при маршрутизации в остальной части Internet используется только префикс сети (поле <Network-prefix>) из IP-адреса получателя. Маршрутизаторы за пределами сети трактуют поля <Submet-number>¹² и <Host-number> как неделимую часть 32-битового адреса IP. В сети, разделенной па подсети, маршрутизаторы используют расширенный префикс сети:

{ <Network-number>, <Subnet-number> }

Биты, включенные в расширенный префикс, исторически указываются 32-битовыми масками, которые называют масками подсетей. Биты <Subnet-number> следует задавать в виде непрерывной последовательности между полями <Network-number> и <Host-number>. В более современных протоколах взамен понятия маски подсети используется размер префикса – значение, которое указывает число битов в расширенном префиксе. Это число совпадает с количеством старших битов адреса, выделяемых с помощью маски подсети. В данном документе предполагается, что все маски подсетей могут быть выражены с помощью дины префиксов.

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

2.2.5.2 Бесклассовая междоменная маршрутизация

Взрывной рост сети Internet вынудил к пересмотру политики распределения адресов. Традиционные сети общего назначения (классы A, B и C) были изменены для более эффективного использования 32-битового адресного пространства IP. Бесклассовая междоменная маршрутизация (CIDR¹³) [INTERNET:15] является методом, широко распространенным в современных магистральных сетях Internet для более эффективного использования адресов. CIDR позволяет обеспечить маршрутизацию между сетями произвольных размеров. В этой модели хосты и маршрутизаторы не делают каких-либо предположений об использовании адресных блоков. Адреса классов D (IP Multicast) и E (экспериментальные) были сохранены главным образом из-за принятой политики их выделения.

По определению, CIDR включает три элемента:

• топологически осмысленное распределение адресов;

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

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

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

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

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

IP-address ::= { <Network-prefix>, <Host-number> }

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

2.2.6 IP Multicasting

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

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

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

2.2.7 Безадресные линии и префиксы сетей

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

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

Поскольку архитектура IP традиционно предполагает наличие IP-адреса у каждого интерфейса, использование безадресных соединений может приводить к интересным дилеммам. Например, некая опция IP (скажем, Record Route) указывает, что маршрутизатор должен поместить в опцию адрес своего интерфейса, но этот интерфейс не имеет адреса IP. Более того, возможны ситуации (см. главу 5), когда маршруты содержат IP-адрес следующего маршрутизатора (next hop). Маршрутизатор ожидает, что такой адрес будет относиться к одной из (под)сетей, с которыми маршрутизатор соединен. Это предположение будет некорректным если маршрутизатор подключен к безадресной линии «точка-точка».

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

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

В виду наличия этих недостатков данная спецификация предлагает альтернативную схему, которая была «разработана» неоднократно, но исходная ее разработка принадлежит, по-видимому, Филу Кэрну (Phil Karn). В этой схеме маршрутизатор, имеющий безадресные соединения, имеет также специальный адрес IP, который в данном документе обозначается термином router-id. Значение router-id является одним из IP-адресов маршрутизатора (каждый маршрутизатор имеет по крайней мере один адрес IP). Значение router-id используется в качестве адреса IP для всех безадресных интерфейсов.

2.2.8 Специфические варианты маршрутизаторов

2.2.8.1 Хосты со встроенной маршрутизацией

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

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

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

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

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

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

2.2.8.2 Прозрачные маршрутизаторы

Существуют две модели соединения локальных и распределенных сетей в Internet. В первой модели ЛВС присваивается префикс сети и все маршрутизаторы в Internet должны знать путь к этой сети. Во второй модели ЛВС используют префикс (и адресное пространство) распределенной сети, через которую они подключены. Маршрутизаторы, которые поддерживают вторую модель, называют маршрутизаторами с разделением адресов¹⁴ или прозрачными маршрутизаторами¹⁵. Данная спецификация посвящена маршрутизаторам, использующим первую модель, но не исключает использования прозрачных маршрутизаторов.

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

Слова «за» и «перед» маршрутизатором показывают одно из ограничений этой модели – она подходит лишь для географически (или топологически) ограниченной тупиковой¹⁶ среды. Такое ограничение требует использования специфической организации адресов. IP-адреса хостов ЛВС отображаются не небольшое количество (обычно один) адресов распределенной сети. Такое отображение выполняется с обеспечением совместимости с отображением { IP address <-> network address }, используемым в распределенной сети.

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

Поведение таких хостов с точки зрения другого хоста, который кажется находящимся в той же сети, может отличаться, если прозрачный маршрутизатор не может полностью эмулировать сервис распределенной сети. Например, в сети ARPANET используется протокол канального уровня, обеспечивающий индикацию Destination Dead¹⁷ в ответ на попытку передачи пакета хосту, который был выключен. Однако при наличии прозрачного маршрутизатора между ARPANET и ЛВС Ethernet хост в ARPANET не будет получать индикацию Destination Dead для хостов Ethernet.

2.3 Характеристики маршрутизаторов

Маршрутизаторы Internet выполняют следующие функции:

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

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

• прием и передача дейтаграмм IP с размером вплоть до верхнего предела, поддерживаемого сетью; этот размер называют MTU¹⁸;

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

• реакция на сообщения системы управления трафиком и контроля ошибок.

См. главу 3 (Канальный уровень).

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

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

Более подробная информация приведена в главах 4 (Протоколы уровня Internet) и 5 (Уровень Internet – пересылка).

3. Выбор следующего маршрутизатора (next-hop) для каждой дейтаграммы IP на основе информации из базы данных о маршрутах. Более подробная информация содержится в главе 5 (Уровень Internet – пересылка).

4. Поддержка (в большинстве случаев) протокола внутренней маршрутизации (IGP¹⁹) для передачи маршрутной информации и алгоритмов определения доступности другим маршрутизаторам в своей автономной системе. В дополнение к этому от некоторых маршрутизаторов требуется поддержка протокола внешней маршрутизации (EGP²⁰) для обмена топологической информацией с другими автономными системами. Дополнительная информация приведена в главе 7 (Прикладной уровень – протоколы маршрутизации).

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

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

• Глобальная система соединений (опорная сеть) состоит из множества WAN-сетей, к которым подключены маршрутизаторы нескольких AS; незначительное количество хостов подключено напрямую к таким сетям.
• Большинство хостов подключено к ЛВС. Многие организации имеют кластеры локальных сетей, связанные между собой локальными маршрутизаторами. Каждый такой кластер соединен через один или несколько маршрутизаторов с глобальной опорной сетью. Если кластер подключен только в одной точке, такая ЛВС называется тупиковой или краевой²¹.

К маршрутизаторам опорной сети обычно предъявляются следующие требования:

• Поддержка расширенных алгоритмов маршрутизации и пересылкиДля таких маршрутизаторов требуются алгоритмы, которые являются достаточно динамичными, отличаются незначительными издержками на обработку и поддерживают маршрутизацию по типам обслуживания. Вопросы предотвращения насыщения пока решены не полностью (см. параграф 5.3.6). Ожидается улучшение ситуации в этой сфере по мере проведения исследований.
• Высокий уровень доступностиТакие маршрутизаторы должны быть весьма надежными и работать безостановочно. Отказы программ и оборудования могут оказывать широкое (иногда глобальное) воздействие. В случае отказа должна обеспечиваться возможность быстрого восстановления. В любой среде маршрутизатор должен обеспечивать устойчивую работу и возможность функционирования (возможно с ограниченными функциями) в условиях экстремального насыщения или сбоев в сетевых ресурсах.
• Расширенные эксплуатационные возможности и функции обслуживанияМаршрутизаторы Internet обычно работают без постоянного присмотра человека. Управление обычно осуществляется удаленно из сетевых центров. Для решения этих задач могут потребоваться изощренные средства мониторинга и контроля трафика и других событий, а также для диагностики при отказах.
• Высокая производительностьДля организации протяженных соединений Internet в основном используются полнодуплексные каналы 56 кбит/с, DS1 (1,544 Мбит/с) или DS3 (45 Мбит/с). В локальных сетях обычно используется полудуплексная среда Ethernet (10 Мбит/с) или (существенно реже) FDDI (100 Мбит/с). Однако технологии сетевых сред постоянно совершенствуются и в будущем станет возможным существенное расширение полосы.

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

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

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

2.4 Архитектурные допущения

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

• Internet – это сеть сетей.

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

• Маршрутизаторы не сохраняют информации о состоянии соединений.

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

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

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

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

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

• Система должна быть устойчива к изменениям сети.

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

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

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

3. Канальный уровень

В работе [INTRO:1] подробно рассматриваются стандарты канального уровня (передача IP с использованием различных протоколов канального уровня, преобразование ARP и т. п..), однако в настоящем документе предполагается, что материалы по канальному уровню будут вынесены в отдельный документ. Этот документ будет применим как к хостам, так и к маршрутизаторам и не будет отменять рассмотренные в [INTRO:1] вопросы, связанные с канальным уровнем.

3.1 Введение

К маршрутизаторам предъявляются на канальном уровне точно такие же требования, как к другим типам систем Internet. Эти требования рассмотрены в главе 3 документа Requirements for Internet Gateways [INTRO:1]. Маршрутизатор должен соответствовать всем требованиям, следует также соблюдать приведенные в документе рекомендации. Поскольку указанный документ выпущен достаточно давно, ниже приводятся некоторые дополнительные требования и разъяснения.

Обсуждение

Предполагается, что сообщество Internet подготовит стандарт требований к канальному уровню Internet, который заменит собой данную главу и главу «INTERNET LAYER PROTOCOLS» в документе [INTRO:1].

3.2 Интерфейс между канальным уровнем и IP

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

В этой главе используются следующие определения:

• Физический адрес отправителя (Source physical address)

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

• Физический адрес получателя (Destination physical address)

  Адрес канального уровня для хоста или маршрутизатора, которому передается пакет.

Информация, передаваемая от канального уровня на сетевой (Internetwork Layer) для каждого принятого пакета, включает:

1. Пакет IP [5.2.2].

2. Размер данных в кадре канального уровня (без учета заголовков канального уровня) [5.2.2].
3. Идентификацию физического интерфейса, от которого был получен пакет IP [5.2.3].
4. Классификацию физического адреса получателя пакета, как индивидуального, группового или широковещательного адреса канального уровня [4.3.2], [5.3.4].

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

5. Физический адрес отправителя.

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

1. Пакет IP [5.2.1].
2. Размер пакета IP [5.2.1].
3. Физический интерфейс получателя [5.2.1].
4. IP-адрес следующего интервала [5.2.1].

В дополнение к этому сетевому уровню также следует предоставить:

5. Значение приоритета для канального уровня [5.3.3.2]

Канальный уровень должен также уведомлять уровень Internetwork Layer, если при передаче пакета на канальном уровне возникает ошибка, связанная с предпочтениями канального уровня [5.3.3.3].

3.3 Частные вопросы

3.3.1 Трейлерная инкапсуляция

Маршрутизаторы, подключенные к сетям Ethernet 10 Мбит/с, могут принимать и пересылать пакеты, инкапсулированные с использованием трейлеров, описанных в [LINK:1]. Однако маршрутизаторам не следует самим порождать пакетов с трейлерной инкапсуляцией. Для маршрутизаторов недопустима генерация пакетов с трейлерной инкапсуляцией без предварительной проверки с использованием механизма, описанного в [INTRO:2], возможности восприятия пакетов с трейлерной инкапсуляцией их получателем. Маршрутизаторам не следует соглашаться (используя указанный выше механизм) на восприятие пакетов с трейлерной инкапсуляцией.

3.3.2 Протокол преобразования адресов – ARP

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

Для канального уровня недопустима передача сообщений Destination Unreachable²² для адресов IP по причине отсутствия для адреса записи в кэше ARP; следует собирать в очередь небольшое число дейтаграмм в течение запроса/отклика ARP и передавать сообщение Destination Unreachable для находящегося в очереди адреса лишь после неудачной попытки преобразования адреса.

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

3.3.3 Совместное использование Ethernet и 802.3

Маршрутизаторы, подключенные к сетям Ethernet 10 Мбит/с, должны соответствовать требованиям Ethernet, указанным в [INTRO:2]. Следует также добиваться безусловной совместимости с этими требованиями.

3.3.4 Максимальный размер блока – MTU

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

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

Обсуждение

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

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

3.3.5 Протокол PPP

Вопреки [INTRO:1], Internet имеет стандартный протокол для соединений «точка-точка» – протокол PPP²³, описанный в [LINK:2], [LINK:3], [LINK:4], [LINK:5].

Интерфейсом канала «точка-точка» может быть любой интерфейс, предназначенный для передачи данных через такие каналы (коммутируемая или выделенная телефонная линия, виртуальное соединение типа ISDN и т. п.). Обычно для таких линий используются стандартные модемы или битовые последовательные интерфейсы (например, RS-232, RS-449 или V.35), работающие в синхронном или асинхронном режиме. Мультиплексируемые виртуальные каналы зачастую используют специализированные физические интерфейсы.

Последовательный интерфейс общего назначения использует такую же физическую среду, как линия «точка-точка», но поддерживает использование сетей канального уровня, наряду с соединениями «точка-точка». Сети канального уровня (такие, как X.25 или Frame Relay) используют отличную от IP спецификацию канального уровня. Маршрутизаторы, использующие линии «точка-точка» или последовательные интерфейсы общего назначения, должны поддерживать протокол PPP.

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

3.3.5.1 Введение

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

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

3.3.5.2 Опции LCP

Протокол управления каналом PPP (LCP²⁴) поддерживает множество опций, которые могут согласовываться между партнерами. Эти опции включают (наряду с другими) компрессию полей адреса и управления, компрессию поля протокола, схему отображения асинхронных символов²⁵, максимальный размер принимаемого блока (MRU²⁶), мониторинг качества канала (LQM²⁷), «магическое число» для детектирования «петель» (loopback detection), протокол парольной идентификации PAP²⁸, протокол согласования аутентификационных запросов CHAP²⁹ и 32-битовую контрольную сумму кадра (FCS³⁰).

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

Обсуждение

Перечисленные опции управляют представлением заголовков PPP. Обычно заголовок PPP содержит поля адреса, управления и протокола. Для каналов «точка-точка» в качестве адреса используется значение 0xFF, указывающее «широковещательный» адрес. Поле управления содержит значение 0x03 (Unnumbered Information – безадресная информация). Идентификатор протокола представляет собой 2-байтовое значение, которое определяет тип содержимого поля данных в кадре. Если система согласует сжатие полей адреса и управления, она показывает своему партнеру, что будет принимать кадры PPP, не содержащие этих полей, равно как и кадры с такими полями в начале заголовка. Такая индикация не говорит о том, что система будет передавать кадры с удаленными из заголовка полями адреса и управления.

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

Использование компрессии полей адреса и управления несовместимо с адресуемым режимом³¹ PPP.

Реализация

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

Маршрутизатор должен согласовать используемую схему ACCM³² для асинхронных каналов PPP, но ему не следует согласовывать ACCM для синхронных каналов. Если маршрутизатор принимает попытку согласования ACCM для синхронного канала, он должен подтвердить (ACK) эту опцию и игнорировать ее.

Обсуждение

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

Маршрутизатору следует согласовать значение максимального размера принимаемых кадров (MRU). Даже если система запросила при согласовании значение MRU < 1500 байтов, она должна быть способна принимать кадры размером 1500 байтов.

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

Обсуждение

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

Маршрутизатору следует реализовать и согласовывать опцию magic number для детектирования «петель» (loopback).

Маршрутизатор может поддерживать опции аутентификации PAP и/или CHAP.

Маршрутизатор должен поддерживать 16-битовые контрольные суммы FCS и может поддерживать 32-битовые контрольные суммы.

3.3.5.3 Опции протокола IPCP³³

Маршрутизатор может предлагать согласование адреса IP и должен воспринимать отказ (REJect) от такого согласования.

Маршрутизаторам, работающим при скорости канала 19200 бит/с и ниже, следует реализовать и предлагать партнеру использование компрессии заголовков по алгоритму Van Jacobson (VJ). Маршрутизаторам, реализующим компрессию VJ, следует поддерживать возможности административного отключения сжатия.

3.3.6 Тестирование интерфейса

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

Обсуждение

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

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

4. Протоколы уровня INTERNET

4.1 Введение

В данной главе и главе 5 обсуждаются протоколы, используемые на уровне Internet³⁴ – IP, ICMP и IGMP. Поскольку пересылка пакетов является важнейшей темой для документа, посвященного маршрутизаторам, глава 5 посвящена исключительно протоколам, непосредственно связанным с пересылкой пакетов. В данной главе обсуждаются остальные вопросы, связанные с протоколами уровня Internet.

4.2 Протокол INTERNET – IP

4.2.1 Введение

Маршрутизаторы должны поддерживать протокол IP, описанный в [INTERNET:1]. Они также должны поддерживать обязательные расширения этого протокола – подсети (определены в [INTERNET:2]), широковещание IP (определено в [INTERNET:3]) и бесклассовую маршрутизацию CIDR (определена в [INTERNET:15]).

Разработчикам маршрутизаторов нет необходимости добиваться совместимости с параграфом «Internet Protocol – IP» документа [INTRO:2], поскольку информация из этого параграфа полностью продублирована или заменена в настоящем документе. Маршрутизаторы должны быть совместимыми и следует делать их безусловно совместимыми с относящимися к IP требованиями параграфа «SPECIFIC ISSUES» в документе [INTRO:2].

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

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

RFC 791 [INTERNET:1] содержит спецификацию протокола IP.

4.2.2.1 Опции – RFC 791, параграф 3.2

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

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

Обсуждение

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

Ниже приведены требования для отдельных опций IP:

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

   Некоторые среды требуют наличия опции Security в каждом передаваемом или принимаемом пакете. Маршрутизаторам следует реализовать поддержку опции безопасности в соответствии с обновленным описанием [INTERNET:5].

Обсуждение

Отметим, что опции безопасности, описанные в [INTERNET:1] и RFC 1038 ([INTERNET:16]) утратили свою силу.

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

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

c. Опция задания маршрута отправителем (Source Route)

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

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

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

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

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

Обсуждение

Предположим, что дейтаграмма source route маршрутизируется из источника S получателю D через маршрутизаторы G1, G2, Gn. Отправитель S создает дейтаграмму с IP-адресом G1, как адресом получателя, а опция source route содержит остальной путь к конечному адресату. Однако в спецификации имеется неоднозначность, которая позволяет в опции source route передаваемых S дейтаграмм установить вариант (A) или (B):

(A): {>>G2, G3, ... Gn, D}    <---- корректно
(B): {S, >>G2, G3, ... Gn, D} <---- ошибка

(знак >> представляет указатель). Если передается вариант (A), дейтаграмма, принятая D, будет содержать опцию {G1, G2, … Gn >>} с IP-адресами отправителя и получателя. При использовании варианта (B) полученная в D дейтаграмма также будет содержать в опции IP-адреса отправителя и получателя, но опция будет иметь форму {S, G1, …Gn >>} (хост-отправитель будет указан как первый интервал маршрута).

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

Маршрутизаторы могут поддерживать опцию Record Route в дейтаграммах, сгененрированных самим маршрутизатором.

e. Опция Timestamp

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

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

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

• Если маршрутизатор получает адресованную непосредственно ему дейтаграмму с опцией Timestamp, он должен поместить в опцию значение текущего времени (если в поле опции имеется для этого пространство) до передачи опции на транспортный уровень или передачи сообщения ICMP на обработку. При отсутствии пространства в поле опции маршрутизатор должен увеличить значение Overflow Count³⁷ в опции.
• Значение временной метки должно соответствовать правилам, приведенным в [INTRO:2].

Реализация

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

Опция timestamp позволяет использовать нестандартное время, но при отсутствии синхронизации часов практическая польза от этой опции исчезает. Следовательно, в маршрутизаторах полезно реализовать поддержку протокола NTP³⁸ для синхронизации часов.

4.2.2.2 Адреса в опциях – RFC 791, параграф 3.1

Маршрутизаторы включают свой адрес в опции Record Route, Strict Source и Record Route, Loose Source и Record Route или Timestamp. Когда маршрутизатор помещает свой адрес в такую опцию, он должен использовать IP-адрес того логического интерфейса, через который будет передан пакет. Если это правило невозможно выполнить по причине отсутствия IP-адреса у выходного интерфейса (безадресный интерфейс), маршрутизатор должен указать взамен значение router-id (это значение совпадает с одним из IP-адресов маршрутизатора). Значения Router ID могут задаваться для устройства в целом или для отдельных каналов. Адрес, используемый в качестве значения router-id, недопустимо менять без участия администратора (даже при перезагрузке устройства). Примером ситуации со сменой идентификатора является такое изменение конфигурации, при котором адрес, заданный в качестве router-id, перестает использоваться в данном маршрутизаторе. Маршрутизаторы с множеством безадресных интерфейсов могут использовать множество значений router-id. Каждый безадресный интерфейс должен быть связан с отдельным значением router-id. Эта связь не должна изменяться (даже при перезагрузке) без смены конфигурационных параметров маршрутизатора.

Обсуждение

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

Реализация

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

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

Заголовок IP содержит два резервных бита – один бит в поле Type of Service³⁹, а второй в поле Flags⁴⁰. Для маршрутизаторов недопустимо устанавливать в этих битах значение 1 для генерируемых самим маршрутизатором пакетов. Недопустимо также отбрасывание (отказ от приема или пересылки) пакетов на том лишь основании, что один или оба резервных бита имеют отличное от нуля значение, т. е. для маршрутизатора недопустима проверка значений этих битов.

Обсуждение

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

4.2.2.4 Тип обслуживания (ToS) – RFC 791, параграф 3.1

Байт типа обслуживания в заголовке IP делится на три части: поле предпочтений (Precedence, 3 старших бита), поле типа обслуживания (Type of Service или TOS, следующие 4 бита) и резервное поле (младший бит).

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

Более глубокое рассмотрение поля TOS вы можете найти в документе [ROUTE:11].

Описание поля Precedence приведено в параграфе 5.3.3. Спецификация RFC 795 (Service Mapping) устарела и ее не следует использовать в реализации.

4.2.2.5 Контрольная сумма заголовка – RFC 791, параграф 3.1

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

Маршрутизатор может использовать инкрементальное обновление контрольной суммы заголовка IP в тех случаях, когда единственным изменением в пакете является уменьшение поля времени жизни в заголовке. Такой подход снижает вероятность незамеченного повреждения заголовка пакета маршрутизатором. Инкрементальное обновление контрольной суммы рассматривается в документе [INTERNET:6].

Реализация

Более детальное описание контрольных сумм заголовка IP, включая советы по реализации, содержится в документах [INTERNET:6] и [INTERNET:7].

4.2.2.6 Неопознанные опции заголовка – RFC 791, параграф 3.1

Маршрутизатор должен игнорировать нераспознанные опции IP. Вследствие этого маршрутизатор должен поддерживать опции End of Option List и No Operation, поскольку эти опции не включают значения размера.

Обсуждение

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

4.2.2.7 Фрагментация – RFC 791, параграф 3.2

Маршрутизатор должен поддерживать фрагментацию пакетов в соответствии с документом [INTERNET:1].

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

Обсуждение

Существует несколько методов фрагментации, получивших распространение в Internet. Один из методов состоит в расщеплении дейтаграммы таким образом, чтобы размер первого фрагмента совпадал со значением MTU, а последующие фрагменты имели близкий к этому размер меньше MTU. Такой выбор размеров обусловлен двумя причинами. Для первого фрагмента выбирается эффективное значение MTU для текущего пути между хостами, а размер последующих фрагментов выбирается из соображений минимизации числа фрагментов дейтаграммы IP. Другой метод использует разбиение дейтаграммы IP на фрагменты размера MTU, а последний фрагмент содержит оставшуюся часть дейтаграммы [INTERNET:1].

В некоторых реализациях стека TCP/IP при прохождении через маршрутизатор дейтаграммы IP фрагментируются в пакеты, размер которых не превышает 576 байтов. Это делается для того, чтобы на оставшейся части пути полученные фрагменты не пришлось фрагментировать еще раз. Такой подход, однако, создает достаточно высокую нагрузку на принимающий хост, поскольку число фрагментов одной дейтаграммы может быть достаточно большим. Передача мелких пакетов снижает также эффективность работы сетей, где значение MTU изменяется только один раз и существенно превышает 576 байтов. Примерами могут служить сети IEEE 802.5 (MTU = 2048) или Ethernet (MTU = 1500).

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

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

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

4.2.2.8 Сборка фрагментов – RFC 791, параграф 3.2

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

4.2.2.9 Время жизни – RFC 791, параграф 3.2

Обработка значений времени жизни (TTL) для порожденных маршрутизатором или принятых им пакетов определяется [INTRO:2]; в данном документе не содержится никаких изменений. Однако, поскольку остальная часть главы «Протокол IP» документа [INTRO:2] дублируется в данном документе, продублируем и этот параграф.

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

Для маршрутизаторов недопустима генерация и пересылка пакетов с TTL = 0.

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

Для генерируемых маршрутизатором сообщений уровень IP должен принимать во внимание, что транспортный уровень устанавливает значение TTL для каждой передаваемой дейтаграммы. При использовании фиксированного значения TTL, должна обеспечиваться возможность выбора этого значения. Время жизни следует делать больше типичного диаметра Internet и в настоящее время рекомендуется выбирать значение вдвое больше диаметра с учетом будущего расширения сети. Рекомендуемые значения времени жизни обычно помещаются в документ Assigned Numbers⁴¹. Поле TTL выполняет две функции – ограничивает время жизни сегментов TCP (см. RFC 793⁴² [TCP:1], стр. 28) и предотвращает возникновение в Internet маршрутных петель. Хотя поле TTL определено, как время в секундах, этот параметр используется также в качестве счетчика интервалов, поскольку каждый маршрутизатор должен уменьшать значение этого поля по крайней мере на единицу.

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

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

Используемое по умолчанию фиксированное значение TTL должно быть не меньше «диаметра» Internet (т. е., максимально длинного из возможных путей). Разумно выбирать значение, равное удвоенному диаметру, с учетом постоянного расширения Internet. На момент создания документа сообщения, пересекающие США, зачастую проходят через 15 – 20 маршрутизаторов, следовательно, значение TTL должно быть не менее 40; общепринятым является значение TTL = 64.

4.2.2.10 Широковещательная рассылка во множество подсетей (Multi-subnet Broadcast) – RFC 922

Использование рассылки широковещательных пакетов во все подсети (All-subnets broadcast или multi-subnet broadcast в [INTERNET:3]) запрещено. См. параграф 5.3.5.3.

4.2.2.11 Адресация – RFC 791, параграф 3.2

Как было отмечено в параграфе 2.2.5.1, существует 5 классов адресов IP: от A до E. Адреса класса D используются для групповой адресации IP [INTERNET:4], а класс E зарезервирован для экспериментов. Различия между адресами классов A, B и C не столь важны – эти классы в настоящий момент представляют лишь исторический интерес.

Групповой адрес IP представляет собой 28-битовый логический адрес, который относится к группе хостов и может быть временным или постоянным. Постоянные групповые адреса распределяются агентством IANA⁴³ [INTRO:7], а временные адреса могут динамически выделяться для временных групп. Принадлежность к группам определяется динамически на основе протокола IGMP [INTERNET:4].

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

{ <Префикс сети>, <Номер хоста> }

значение -1 будет использоваться для полей, содержащих только единицы, а 0 – для полей, содержащих только нули.

(a) { 0, 0 }

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

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

Обсуждение

В некоторых протоколах определяются специфические действия в ответ на получение дейтаграмм с адресом отправителя { 0, 0 }. Примерами таких протоколов могут служить BOOTP и ICMP (Mask Request). Корректная работа таких протоколов зачастую зависит от возможности получения дейтаграмм с адресом отправителя { 0, 0 }. Однако для большинства других протоколов лучше будет игнорировать дейтаграммы с адресом отправителя { 0, 0 }, поскольку их источником может являться некорректно настроенный хост или маршрутизатор. Таким образом, если маршрутизатор знает, что делать с дейтаграммами, содержащими адрес отправителя { 0, 0 }, он должен принимать их, в противном случае маршрутизатор должен отбрасывать дейтаграммы.

См. также информацию о нестандартном использовании адреса { 0, 0 } в параграфе 4.2.3.1.

{ 0, <Номер хоста> }

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

(c) { -1, -1 }

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

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

(d) { <Префикс сети>, -1 }

Направленное широковещание⁴⁵ — широковещательные пакеты для указанного сетевого префикса. Такой адрес недопустимо использовать в качестве адреса получателя за исключением тех случаев, когда отправитель является одной из двух конечных точек соединения «точка-точка» с 31-битовой маской. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор может иметь конфигурационную опцию, позволяющую ему принимать пакеты направленного широковещания, однако по умолчанию эта опция должна быть отключена и, таким образом, маршрутизатору недопустимо принимать пакеты Network Directed Broadcast, пока это явно не задано в конфигурации.

(e) { 127, <любое значение> }

Внутренний loopback-адрес хоста. Адреса этого типа недопустимо использовать за пределами данного хоста.

(f)46 { <Номер сети>, <Номер подсети>, 0 }

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

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

Не допускается использование адресов IP со значениями 0 или -1 в полях <Номер хоста> и <Префикс сети> за исключением перечисленных выше специальных случаев. Это требование неявно указывает, что каждое из полей должно иметь размер не менее 2 битов.

Обсуждение

В предыдущей версии данного документа было указано, что номера подсетей не должны иметь значение 0 или -1 и размер этого поля должен быть не менее 2 битов. В среде CIDR номер подсети является расширением префикса сети и не может интерпретироваться без остальной части префикса. Следовательно, приведенное выше ограничение не имеет смысла при использовании CIDR и может игнорироваться без всякого риска.

Дополнительное обсуждение широковещательных адресов приведено в параграфе 4.2.3.1.

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

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

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

Термин «адрес конкретного получателя⁴⁷» означает локальный IP-адрес хоста. В заголовке IP в качестве адреса получателя должен указываться адрес конкретного хоста, если пакет не является широковещательным или групповым (в таких случаях адресом конкретного получателя является IP-адрес физического интерфейса, через который принимается дейтаграмма).

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

Обсуждение

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

4.2.3 Специальные вопросы

4.2.3.1 Широковещательные адреса IP

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

1. ⁴⁸Должны трактоваться, как широковещательные пакеты IP все пакеты, направленные по адресу 255.255.255.255 или { <Префикс сети>, -1 }.На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, -1 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.
2. ⁴⁹Следует отбрасывать без уведомления (т. е., даже без доставки даже работающим на маршрутизаторе приложениям) все пакеты, направленные по адресу 0.0.0.0 или { <Префикс сети>, 0 }. Если такие пакеты не отбрасываются, они должны трактоваться, как широковещательные пакеты IP (см. параграф 5.3.5). Может использоваться конфигурационная опция, позволяющая принимать такие пакеты. По умолчанию следует устанавливать для этой опции отбрасывание пакетов.На каналах «точка-точка» с маской размером 31 бит, пакеты, направленные по адресу { <Префикс сети>, 0 }, соответствующему одной из конечных точек этого канала, должны трактоваться, как направленные маршрутизатору, на котором установлен этот адрес.
3. Маршрутизатору следует (по умолчанию) использовать адрес ограниченного широковещания (limited broadcast address) 255.255.255.255 для широковещательных дейтаграмм IP, адресованных в подключенные (под)сети, за исключением случаев передачи откликов ICMP Address Mask Reply, как показано в параграфе 4.3.3.9. Маршрутизатор должен принимать широковещательные пакеты с ограниченной областью распространения.
4. ⁵⁰Не следует генерировать дейтаграммы, направленные по адресу 0.0.0.0 или {<Префикс сети>, 0 }. Может использоваться конфигурационная опция, позволяющая генерировать такие пакеты (вместо использования подходящего формата широковещания). По умолчанию для опции следует использовать значение, не позволяющее генерировать такие пакеты.

   На каналах «точка-точка» с маской размером 31 бит в конфигурации следует разрешать генерацию дейтаграмм, направленных по адресу { <Префикс сети>, 0 }.

Обсуждение

Для случая (2) маршрутизатор обычно не может распознавать адреса в формате { <Префикс сети>, 0 }, если у него нет интерфейса с таким сетевым префиксом. В таких случаях правила п. (2) теряют силу, поскольку с точки зрения маршрутизатора дейтаграмма не является широковещательным пакетом IP.

4.2.3.2 Групповая адресация IP

Маршрутизаторам следует выполнять требования документа Host Requirements [INTRO:2] по части групповой адресации IP. Маршрутизаторам IP следует поддерживать локальную групповую адресацию IP для всех подключенных сетей. При наличии спецификации отображения групповых адресов IP на адреса канального уровня (см. спецификации передачи IP-over-xxx) следует использовать эту спецификацию, но можно также с помощью конфигурационного параметра задавать использование взамен такого отображения широковещательной рассылки на канальном уровне. На каналах «точка-точка» и всех прочих интерфейсах пакеты с групповой адресацией инкапсулируются в широковещательные кадры канального уровня. Поддержка групповой адресации IP включает генерацию групповых дейтаграмм, присоединение к группам, получение multicast-дейтаграмм и выход из групп. Это подразумевает выполнение всех требований [INTERNET:4], включая поддержку IGMP (см. параграф 4.4).

Обсуждение

Хотя документ [INTERNET:4] называется Host Extensions for IP Multicasting (расширение программ хостов для поддержки групповой адресации IP), он применим ко всем системам IP (как хостам, так и маршрутизаторам). В частности, поскольку маршрутизаторы могут входить в multicast-группы, будет корректно выполнение связанной с хостами части IGMP и информирование о своей принадлежности к группе всех multicast-маршрутизаторов, которые могут присутствовать в подключенных сетях (независимо от того, поддерживает ли сам входящий в группу маршрутизатор multicast-маршрутизацию).

Некоторые протоколы маршрутизации могут явно требовать поддержки групповой адресации IP (например, OSPF [ROUTE:1]) или такая поддержка рекомендуется (например, ICMP Router Discovery [INTERNET:13]).

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

Для предотвращения фрагментации или минимизации ее влияния желательно знать значения MTU на пути от отправителя к получателю. Значением MTU для пути (path MTU) считается минимальное среди значений MTU на всех интервалах этого пути. В документе [INTERNET:14] описан метод динамического определения максимального размера передаваемых блоков (MTU) для произвольного пути в Internet. Для путей, проходящих через маршрутизаторы, которые не поддерживают [INTERNET:14], этот метод не позволяет корректно определить значение Path MTU, но он всегда выбирает Path MTU с максимально возможной точностью и во многих случаях точность определения Path MTU превышает точность при использовании старых методов или принятой сегодня практики.

Когда маршрутизатор порождает дейтаграмму IP, ему следует использовать описанную в [INTERNET:14] схему для ограничения размера дейтаграммы. Если маршрут к получателю дейтаграммы был получен от протокола маршрутизации, обеспечивающего информацию о значении Path MTU, можно продолжать использование схемы [INTERNET:14], но следует использовать значение Path MTU, полученное от протокола маршрутизации как стартовое приближение для Path MTU и верхнюю границу значения Path MTU.

4.2.3.4 Подсети

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

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

Реализация

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

Обсуждение

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

Технология, используемая для решения проблемы с жесткими границами классов адресов, получила название «бесклассовая междоменная маршрутизация» (CIDR) [INTERNET:15].

Адресный блок, связанный с тем или иным сетевым префиксом, может быть поделен на субблоки различных размеров и префиксы, связанные с этими субблоками, будут иметь разную длину. Например, внутри блока с 8-битовым сетевым префиксом один субблок может иметь префикс размером 16 битов, другой – 18, третий – 14 и т. д.

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

4.3 Протокол ICMP

4.3.1 Введение

ICMP представляет собой вспомогательный протокол, обеспечивающий возможности диагностики и передачу сообщений об ошибках в сетях IP. Протокол описан в документе [INTERNET:8]. Маршрутизаторы должны поддерживать протокол ICMP.

Сообщения ICMP делятся на 2 класса:

Сообщения ICMP об ошибках:

Destination Unreachable – адресат недоступен (см. параграф 4.3.3.1).

Redirect – перенаправление (см. параграф 4.3.3.2).

Source Quench – «заткнуть рот отправителю» (см. параграф 4.3.3.3).

Time Exceeded – время жизни истекло (см. параграф 4.3.3.4).

Parameter Problem – проблема с параметрами (см. параграф 4.3.3.5).

Запросы ICMP:

Echo – эхо (см. параграф 4.3.3.6).

Information – информация (см. параграф 4.3.3.7).

Timestamp – временная метка (см. параграф 4.3.3.8).

Address Mask – маска адреса (см. параграф 4.3.3.9).

Router Discovery – обнаружение маршрутизаторов (см. параграф 4.3.3.10).

Общие требования к ICMP рассматриваются в следующем параграфе.

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

4.3.2.1 Неизвестные типы сообщений

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

4.3.2.2 TTL для сообщений ICMP

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

4.3.2.3 Заголовок исходного сообщения

Исторически каждое сообщение ICMP об ошибке включает заголовок IP и первые 8 байтов данных из дейтаграммы, вызвавшей ошибку. В настоящее время такой подход утратил актуальность по причине использования туннелей IP-in-IP и других технологий. Следовательно, в дейтаграммы ICMP следует включать как можно больше данных из исходного пакета без превышения дейтаграммой ICMP размера 576 байтов. Возвращаемый заголовок IP (и данные из пакета) должен быть идентичен полученной информации за исключением того, что маршрутизатор не обязан восстанавливать данные из заголовка IP, которые были изменены в процессе пересылки дейтаграммы до возникновения ошибки (например, уменьшение TTL или смена опций). Отметим, что требования параграфа 4.3.3.5 в некоторых могут отменять приведенные здесь правила (например, для сообщений Parameter Problem маршрутизатор должен восстановить значение поля, с которым связана проблема; см. параграф 4.3.3.5).

4.3.2.4 Адрес отправителя сообщения ICMP

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

4.3.2.5 Поля TOS и Precedence

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

Сообщения об ошибке ICMP Source Quench, если они передаются, должны иметь в поле IP Precedence такое же значение, как в поле IP Precedence вызвавшего передачу ICMP Source Quench пакета. Прочие сообщения ICMP об ошибках (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem) следует передавать со значением 6 (INTERNETWORK CONTROL) или 7 (NETWORK CONTROL) в поле Precedence. Значение IP Precedence для таких сообщений можно делать настраиваемым (опция).

В откликах ICMP должно использоваться значение поля IP Precedence из заголовка соответствующего запроса ICMP.

4.3.2.6 Source Route

Если пакет, вызвавший передачу сообщения ICMP об ошибке, содержал опцию source route, в сообщение ICMP также следует включать опцию source route такого же типа (strict – строгий или loose – мягкий), создаваемую путем обращения части записанного в опции маршрута до указателя. Исключением являются случаи передачи сообщений ICMP Parameter Problem, связанных с опцией source route в исходном пакете, или ситуации, когда маршрутизатор знает, что выбранная политика не позволит доставить такое сообщение ICMP.

Обсуждение

В средах, использующих опцию безопасности U.S. Department of Defense⁵¹ (см. [INTERNET:5]), может потребоваться включение этой опции в сообщения ICMP. Информацию об использовании этой опции можно получить в Defense Communications Agency.

4.3.2.7 Когда не следует передавать сообщения ICMP об ошибках

Передача сообщений ICMP об ошибках недопустима в ответ на:

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

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

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

Обсуждение

Эти правила предназначены для предотвращения широковещательных штормов, когда маршрутизаторы или хосты начинают передавать сообщения ICMP об ошибках в ответ на широковещательные пакеты. Например, широковещательный пакет, адресованный в несуществующий порт UDP, может вызвать лавину дейтаграмм ICMP Destination Unreachable от всех устройств, которые не поддерживают указанный в пакете порт. В больших сетях Ethernet такие штормы могут выводить сеть из строя на секунды или более продолжительное время.

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

Реализация+

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

4.3.2.8 Ограничение скорости

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

Обсуждение

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

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

Реализация

Для ограничения скорости генерации сообщений ICMP об ошибках существует несколько методов:

1. Ограничение на основе счетчиков – например, передача сообщения ICMP об ошибке на каждые N отброшенных пакетов (в целом или для отдельного хоста-отправителя). Этот механизм удобен для сообщений ICMP Source Quench, но не подходит для других сообщений ICMP.
2. Ограничение по таймеру – например, передача сообщения ICMP об ошибке в данный адрес или по всем адресам не более 1 раза в течение T миллисекунд.
3. Ограничение по полосе – например, скорость, с которой сообщения ICMP передаются через тот или иной интерфейс, не должна составлять более заданной части полосы канала.

4.3.3 Специфические вопросы

4.3.3.1 Destination Unreachable

Если маршрутизатор не может переслать пакет адресату потому, что не знает маршрута (в том числе, принятого по умолчанию), он должен направить отправителю пакета сообщение ICMP Destination Unreachable с кодом 0 (Network Unreachable – сеть недоступна). Если маршрутизатор знает путь к адресату пакета, но значение TOS для этого маршрута отличается от принятого по умолчанию TOS (0000) и от значения TOS в заголовке пакета, маршрутизатор должен направить отправителю пакета сообщение ICMP Destination Unreachable с кодом 11 (Network Unreachable for TOS – сеть недоступна для заданного TOS).

Если пакет должен пересылаться хосту непосредственно подключенной к маршрутизатору сети (т. е., данный маршрутизатор является последним на пути) и маршрутизатор знает об отсутствии других путей к этому хосту, он должен генерировать сообщение Destination Unreachable с кодом 1 (Host Unreachable – хост недоступен). Если пакет пересылается хосту подключенной к маршрутизатору сети и маршрутизатор не может переслать этот пакет по той причине, что значение TOS для подключенной сети отличается от принятого по умолчанию (0000) и от заданного в заголовке пакета, маршрутизатор должен передать отправителю пакета сообщение Destination Unreachable с кодом 12 (Host Unreachable for TOS – хост недоступен для заданного TOS).

Обсуждение

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

4.3.3.2 Redirect

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

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

4.3.3.3 Source Quench

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

Обсуждение

Исследования показывают, что сообщения Source Quench увеличивают расход полосы, но не обеспечивают эффективного и корректного способа решения проблемы насыщения (см., например, [INTERNET:9] и [INTERNET:10]). В параграфе 5.3.6 обсуждаются современные методы решения проблем перегрузки и насыщения каналов.

Маршрутизатор может игнорировать получаемые сообщения ICMP Source Quench.

Обсуждение

Маршрутизатор может получать адресованные ему сообщения Source Quench от других маршрутизаторов или хостов при передаче им пакетов от данного маршрутизатора. К таким пакетам могут относиться, например, обновления EGP или адресованные хостам пакеты telnet. В документах [INTERNET:11] и [INTERNET:12] предлагается механизм реагирования уровня IP на сообщения Source Quench путем управления скоростью передачи пакетов, однако этот механизм пока является экспериментальным и не может быть рекомендован.

4.3.3.4 Time Exceeded

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

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

Когда маршрутизатор получает адресованные ему сообщения Time Exceeded, он должен выполнять требования [INTRO:2].

4.3.3.5 Parameter Problem

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

В документе [INTRO:2] определен новый вариант сообщений Parameter Problem:

Code 1 = required option is missing (требуемая опция отсутствует).

Обсуждение

Этот вариант в настоящее время используется в военных системах при отсутствии в пакетах опции безопасности.

4.3.3.6 Echo Request/Reply

Маршрутизатор должен поддерживать сервер ICMP Echo, который принимает адресованные маршрутизатору запросы Echo Request и передает в ответ соответствующие отклики Echo Reply. Маршрутизатор должен быть готов к приему и сборке, а также передаче откликов на дейтаграммы ICMP Echo Request размером не менее 576 байтов и значений MTU подключенных сетей.

Сервер Echo может не отвечать на запросы ICMP Echo, направленные по групповым и широковещательным адресам IP.

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

Обсуждение

Нейтральное отношение к групповым и широковещательным пакетам Echo Request соответствует [INTRO:2] (параграф Echo Request/Reply).

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

IP-адрес отправителя в сообщениях ICMP Echo Reply должен совпадать с конкретным адресом получателя в соответствующем сообщении ICMP Echo Request.

Данные, полученные в сообщении ICMP Echo Request, должны полностью включаться в отклик Echo Reply.

Если в полученном сообщении ICMP Echo Request имеется опция Record Route и/или Timestamp, эту опцию (опции) следует обновить с включением текущего маршрутизатора в заголовок IP сообщения Echo Reply, не отсекая опцию по размеру. Таким образом записанный маршрут будет включать весь путь кругового обхода.

Если в полученном сообщении ICMP Echo Request присутствует опция Source Route, маршрут возврата для сообщения Echo Reply должен быть обращением пути, указанного опцией Source Route, если у маршрутизатора нет уверенности, что принятая политика не позволит доставить сообщение по этому маршруту.

4.3.3.7 Information Request/Reply

Для маршрутизатора недопустима генерация сообщений такого типа и отклики на них.

Обсуждение

Пара сообщений Information Request/Reply предназначена для поддержки самонастраиваемых систем (типа бездисковых станций) и позволяет определить префикс IP в процессе загрузки. Однако, в настоящее время такой подход устарел. Более эффективные механизмы получения параметров и определения своего адреса IP обеспечивают протоколы RARP и BOOTP.

4.3.3.8 Timestamp и Timestamp Reply

Маршрутизатор может поддерживать сообщения Timestamp и Timestamp Reply. Если такая поддержка реализована в маршрутизаторе:

• Сервер ICMP Timestamp должен возвращать сообщение Timestamp Reply в ответ на каждое полученное сообщение Timestamp. Серверу следует обеспечивать минимальные вариации задержки передачи откликов на запросы.
• Запросы ICMP Timestamp, направленные по широковещательным и групповым адресам IP, могут отбрасываться без уведомления.
• IP-адрес отправителя в сообщении ICMP Timestamp Reply должен совпадать с адресом получателя, указанным в соответствующем сообщении Timestamp.
• При получении опции Source Route в сообщении ICMP Timestamp Request, маршрут возврата для сообщения Timestamp Reply должен быть инверсией пути, записанного в Source Route, если у маршрутизатора нет уверенности, что принятая политика не позволит доставить сообщение по такому маршруту.
• Если в сообщении Timestamp присутствует опция Record Route и/или Timestamp, эта опция (опции) должна быть обновлена с включением текущего маршрутизатора и помещена в заголовок сообщения Timestamp Reply.
• Если маршрутизатор обеспечивает для прикладного уровня интерфейс передачи сообщений Timestamp Request, входящие сообщения Timestamp Reply должны передавать пользовательскому интерфейсу ICMP.

Предпочтительный вариант значений timestamp (стандартное время) – выраженное в миллисекундах универсальное время (Universal Time). Однако при указании времени с разрешением 1 мсек могут возникать сложности. Например, многие системы используют внутренние часы, синхронизируемые от электросети (50 или 60 Герц). Следовательно, значения стандартного времени допускают некоторый произвол:

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

Реализация

Для выполнения второго условия маршрутизатору может потребоваться корректировка часов с использованием сервера точного времени при загрузке или перезапуске маршрутизатора. Для корректировки часов рекомендуется использовать протокол Time Server Protocol на основе UDP. Более эффективным решением является синхронизация часов по протоколу NTP (Network Time Protocol), который обеспечивает точность порядка 1 мсек, однако такая синхронизация не является обязательной.

4.3.3.9 Address Mask Request/Reply

Маршрутизаторы должны поддерживать прием запросов ICMP Address Mask Request и генерацию соответствующих откликов ICMP Address Mask Reply. Эти сообщения определены в [INTERNET:2].

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

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

Маршрутизаторам следует проверять полученные сообщения ICMP Address Mask Reply на предмет соответствия указанной в них маски имеющимся у маршрутизатора сведениям о маске. Если сообщение ICMP Address Mask Reply представляется ошибочным, маршрутизатору следует записать в журнальный файл полученное в сообщении значение маски и IP-адрес отправителя. Для маршрутизаторов недопустимо использование сообщений ICMP Address Mask Reply для определения корректной маски.

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

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

Для широковещательной передачи сообщений Address Mask Reply должна использоваться адресация в формате { <Префикс сети>, -1 } .

Широковещательный адрес 255.255.255.255 должен использоваться для широковещательных откликов Address Mask Reply на каналах «точка-точка» с маской подсети размером 31 бит⁵².

Обсуждение

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

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

4.3.3.10 Анонсирование маршрутизаторов

IP-маршрутизатор должен поддерживать связанную с маршрутизаторами часть протокола ICMP Router Discovery Protocol [INTERNET:13] на всех подключенных сетях, для которых маршрутизатор поддерживает групповую или широковещательную адресацию IP. Реализация должна включать все конфигурационные переменные, указанные для маршрутизаторов, с заданными значениями по умолчанию.

Обсуждение

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

Обсуждение

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

4.4 Протокол управления группами INTERNET – IGMP

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

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

Часть 2