Перевод RFC 1812

Network Working Group Request for Comments: 1812 Obsoletes: 1716, 1009 Category: Standards Track

F. Baker, Editor

Cisco Systems

June 1995

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

Requirements for IP Version 4 Routers

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

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

Предисловие

Этот документ представляет собой обновленный вариант RFC 1716 - исторического документа, описывающего требования к

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

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

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

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

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

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

документе от предшественников, за ошибки отвечает редактор.

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

автора и первого редактора документа – Филиппа Алмквиста (Philip Almquist). Большая работа проделана также редактором

предыдущей версии – Фрэнком Кастенхольцем (Frank Kastenholz). Без его работы этот документ просто бы не увидел света.

Оглавление

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

Предисловие ........................................................................................................................................................................ .............................. 1

1. Введение ................................................................................................................................................................................ ...... .................... 5

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

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

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

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

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

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

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

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

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

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

1.4 Алгоритмы .............................................................................................................................................................. .............................. 8

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

2.1 Введение .................................................................................................................................................................................... .......... 8

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

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

2.2.2 Сети .............................................................................................................................................................................. ....... ........... 9

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

2.2.4 Автономные системы ............................................................................................................................................................ ..1..0...

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

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

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

2.2.6 IP Multicasting ........................................................................................................................................................ ..... ......... 11

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

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

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

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

2.3 Характеристики маршрутизаding:0.00pt 0.00pt 0.00pt 113.28pt; text-align:left;">2.2.8.2 Прозрачные маршрутизаторы ....................................................................................................................................... 1..2...

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

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

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

3.1 Введение ............................................................................................................................................................................... ....... ......... 14

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

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

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

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

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

3.3.4 Максимальный размер блока - MTU ................................................................................................................................... ....1..5.

3.3.5 Протокол PPP ........................................................................................................................................................ ..... ................ 15

3.3.5.1 Введение .................................................................................................................................................. ......................... 15

3.3.5.2 Опции LCP ............................................................................................................................................................ .. .......... 15

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

rfc.com.ru

Перевод RFC 1812

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

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

4.1 Введение ................................................................................................................................................................................ ....... ........ 16

4.2 Протокол INTERNET - IP ..................................................................................................................................................... ........ ...... 16

4.2.1 Введение ................................................................................................................................................................................. ..1..6...

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

4.2.2.1 Опции: RFC 791, параграф 3.2 ................................................................................................................................ ...... 17

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

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

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

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

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

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

4.2.2.8 Сборка фрагментов: RFC 791, параграф 3.2 .............................................................................................................. ...1. .9

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

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

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

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

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

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

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

4.2.3.4 Подсети ................................................................................................................................................................................ ..2..1...

4.3 Протокол ICMP ................................................................................................................................................................................ .2..1....

4.3.1 Введение ................................................................................................................................................................................... 2..1 .....

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

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

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

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

4.3.2.4 ICMP Message Source Address ................................................................................................................................... ......2. 2

4.3.2.5 Поля TOS и Precedence .................................................................................................................................................. 2..2..

4.3.2.6 Source Route ........................................................................................................................................................... .... ........ 22

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

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

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

4.3.3.1 Destination Unreachable ............................................................................................................................................ ...... 23

4.3.3.2 Redirect ................................................................................................................................................... ..... .. ..................... 23

4.3.3.3 Source Quench ...................................................................................................................................................... ...... ....... 23

4.3.3.4 Time Exceeded .......................................................................................................................................... ........................ 23

4.3.3.5 Parameter Problem ......................................................................................................................................................... ..2..3..

4.3.3.6 Echo Request/Reply ......................................................................................................................................................... 24

4.3.3.7 Information Request/Reply ...................................................................................................................................... ........ 24

4.3.3.8 Timestamp и Timestamp Reply ......................................................................................................................... ............... 24

4.3.3.9 Address Mask Request/Reply ............................................................................................................................ ............... 24

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

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

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

5.1 Введение ............................................................................................................................................................................... ....... ......... 25

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

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

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

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

5.2.1.3 Группа (Multicast) .................................................................................................................................................... ........26

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

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

5.2.4 Определение адреса следующего интервала (Next Hop) .................................................................................................... 2..8..

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

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

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

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

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

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

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

5.2.7 Протокол ICMP ................................................................................................................................................... ...................... 31

5.2.7.1 Destination Unreachable .......................................................................................................................................... ........ 31

5.2.7.2 Redirect ................................................................................................................................................... ..... .. ..................... 32

5.2.7.3 Time Exceeded ........................................................................................................................................ .......................... 32

5.2.8 Протокол IGMP ................................................................................................................................................... ..... .. ......... 32

5.3 Специфические вопросы ............................................................................................................................................................... ...3. .3. .

5.3.1 Время жизни (TTL) ............................................................................................................................................................. ...... 3. 3

5.3.2 Тип обслуживания (TOS) ....................................................................................................................................... .................. 33

5.3.3 IP Precedence ............................................................................................................................................................................. 3. 4.

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

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

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

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

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

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

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

rfc.com.ru 2 rfc.com.ru

Перевод RFC 1812

Разумные сети от компании BiLiM Systems

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

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

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

5.3.7 Фильтрация некорректных адресов .......................................................................................................................... ............. 37

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

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

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

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

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

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

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

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

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

5.3.13 Опции IP ............................................................................................................................................................................. ....3..9.

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

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

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

5.3.13.4 Опции Source Route ................................................................................................................................. ..... ................... 39

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

5.3.13.6 Опция Timestamp ................................................................................................................................................. ......... 39

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

6.1 Протокол UDP ............................................................................................................................................................................... ......4. .0.

6.2 Протокол TCP ...................................................................................................................................................................... .............. 40

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

7.1 Введение ............................................................................................................................................................................... ....... ......... 40

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

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

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

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

7.2.1 Введение ................................................................................................................................................................................... 4..1 .....

7.2.2 Протокол OSPF ............................................................................................................................................................. ............ 41

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

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

7.3.1 Введение ................................................................................................................................................................................... 4..2 .....

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

7.3.2.1 Введение ..................................................................................................................................................... ........ ................ 42

7.3.2.2 Protocol Walk-through ......................................................................................................................................... ............ 42

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

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

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

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

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

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

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

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

8.1 Протокол SNMP .......................................................................................................................................................................... ...... 4. 4

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

8.2 Таблица Community .................................................................................................................................................................... ...... 4. 5

8.3 Стандартные MIB ............................................................................................................................................................................. 4..5 .....

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

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

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

9.1 BOOTP ................................................................................................................................................................. ................................ 46

9.1.1 Введение ................................................................................................................................................................................. ..4..6...

9.1.2 Агенты BOOTP Relay ............................................................................................................................................................ ....4..6..

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

10.1 Введение ........................................................................................................................................................................... ..... .... ......... 46

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

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

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

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

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

10.3.1 Введение ........................................................................................................................................................................... ..... ...4. 8

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

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

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

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

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

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

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

10.3.2.6 Минимизация “разрушений” ............................................................................................................................... .........49

10.3.2.7 Контроль – поиск неисправностей ................................................................................................................... .......... 49

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

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

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

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

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

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

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

rfc.com.ru 3 rfc.com.ru

Перевод RFC 1812

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

D.1 Введение ................................................................................................................................................................................ ...... ........ 57

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

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

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

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

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

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

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

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

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

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

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

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

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

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

F.1.1 Введение ........................................................................................................................................................................... ...... ...60

F.1.2 “Сквозной контроль” протокола ...................................................................................................................................... ...... 61

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

F.2.1 Введение ............................................................................................................................................................................. ........6. 1

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

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

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

Благодарности ................................................................................................................................................................................................ 6. .4....

Адрес редактора ............................................................................................................................................................................ ..... .. ........... 64

rfc.com.ru 4

Перевод RFC 1812

1. Введение

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

В документе определяются и обсуждаются требования к устройствам, выполняющим функции пересылки (forwarding) пакетов на

сетевом уровне стека протоколов Internet. Сообщество 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) Общие вопросы - рассматриваются спецификации протокола по разделам исходного стандарта, указываются и исправляются ошибки, обсуждаются требования, которые могли быть неточно или некорректно определены, а также приводятся дополнительные разъяснения и уточнения

¹Переводы этих RFC вы можете найти на сайте http://rfc.com.ru. Прим. перев.

rfc.com.ru 5 rfc.com.ru

Перевод RFC 1812

(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, имена

²На момент подготовки перевода текущая версия STD 1 была представлена в RFC 3700. Прим. перев.

rfc.com.ru 6 rfc.com.ru

Перевод RFC 1812

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

info@internic.net

+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 является весьма непростой задачей. Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов. При записи таких событий важно включать максимум диагностической информации. Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки. Однако следует знать меру - средства протоколирования ошибок не должны отнимать слишком много ресурсов маршрутизатора и снижать эффективность его работы.

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

³В настоящее время документ Assigned Numbers утратил силу и список выделенных значений доступен в базе данных на сайте

www.iana.org. Прим. перев.

⁴На сайте rfc.com.ru имеются переводы этих документов на русский язык. Прим. перев.

⁵ Сайт ds.internic.net в настоящее время не поддерживается, а копии документов RFC можно найти на сайте www.rfc-editor.org. Прим. перев.

⁶ В оригинале “Be conservative in what you do, be liberal in what you accept from others.” Прим. перев.

rfc.com.ru 7 rfc.com.ru

Перевод RFC 1812

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

(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¹².

⁷ Internet Protocol – протокол Internet.

⁸ Internet Control Message Protocol – протокол обмена управляющими сообщениями.

⁹ Internet Group Management Protocol – протокол управления группами.

¹⁰ Internet Engineering Steering Group.

¹¹ Transmission Control Protocol – протокол управления передачей.

¹² User Datagram Protocol – протокол пользовательских дейтаграмм.

rfc.com.ru 8 rfc.com.ru

Перевод RFC 1812

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) и передает данные в виде дейтаграмм (datagram) без гарантии доставки. Исследовательскими организациями были разработаны и другие протоколы транспортного уровня, которые могут получить статус стандартных протоколов. Более подробное описание протоколов транспортного уровня приведено в главе 6.

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

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

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

гарантии доставки. Таким образом, при доставке на хост получателя дейтаграммы 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)

rfc.com.ru

Перевод RFC 1812

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

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>. В более современных протоколах взамен понятия маски подсети используется размер префикса – значение, которое указывает число битов в расширенном префиксе. Это число совпадает с количеством старших битов адреса, выделяемых с помощью маски подсети. В данном документе предполагается, что все маски подсетей могут быть выражены с помощью дины префиксов.

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

¹³ иногда их еще называют глобальными. Прим. перев.

¹⁴ В оригинале ошибочно указано <Network-prefix>. Прим. перев.

rfc.com.ru 10 rfc.com.ru

Перевод RFC 1812

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

Взрывной рост сети 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, который в данном документе обозначается термином

¹⁵ Classless Inter Domain Routing

¹⁶ Internet Group Management Protocol

rfc.com.ru 11 rfc.com.ru

Перевод RFC 1812

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 (Канальный уровень).

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

♦ детектирование ошибок и генерация при необходимости сообщений ICMP;

¹⁷address sharing router

¹⁸transparent router

¹⁹Не используемой для транзитного трафика. Прим. перев.

²⁰Адресат “умер”.

²¹Maximum Transmission Unit – максимальный размер передаваемого блока.

rfc.com.ru 12 rfc.com.ru

Перевод RFC 1812

♦ отбрасывание дейтаграмм с нулевым значением времени жизни;

♦ фрагментация дейтаграмм при необходимости в соответствии со значением MTU в следующей по маршруту сети. Более подробная информация приведена в главах 4 (Протоколы уровня Internet) и 5 (Уровень Internet - пересылка).

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

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

(6) Поддержка функций сетевого управления, включая загрузку, отладку, отчеты о состоянии, отчеты об исключительных ситуациях и управление. Дополнительная информация приведена в главах 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 независимо от других пакетов. В результате для повышения устойчивости могут использоваться избыточные пути, используемые при возникновении сбоев в сетях или маршрутизаторах.

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

²²Internal Gateway Protocol – протокол внутреннего шлюза. ²³External Gateway Protocol – протокол внешнего шлюза. ²⁴stub network

rfc.com.ru 13 rfc.com.ru

Перевод RFC 1812

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

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

Маршрутизация является сложной задачей и выполняется она маршрутизаторами, а не хостами. Это является важной предпосылкой для изоляции используемых на хостах программ от изменений, которые могут быть вызваны неизбежной эволюцией архитектуры маршрутизации 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]. Однако маршрутизаторам не следует порождать (originate) пакетов с трейлерной инкапсуляцией. Для маршрутизаторов недопустима генерация пакетов с трейлерной инкапсуляцией без предварительной проверки с использованием механизма, описанного в [INTRO:2], возможности восприятия пакетов с трейлерной

²⁵Link Layer Requirements – требования к канальному уровню. ²⁶Requirements for Internet Link Layer ²⁷Link Layer precedence-related error

rfc.com.ru 14 rfc.com.ru

Перевод RFC 1812

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

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) используют иную спецификацию канального уровня. Маршрутизаторы, использующие линии “точка-точка” или последовательные интерфейсы общего назначения, должны поддерживать протокол 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. Обсуждение

²⁸Point-to-Point Protocol

²⁹Link Control Protocol – протокол управления каналом.

³⁰PPP Link Control Protocol

³¹Asynchronous character map

³²Maximum Receive Unit

³³Link Quality Monitoring

³⁴Password Authentication Protocol

³⁵Challenge Handshake Authentication Protocol – протокол согласования аутентификационных запросов.

³⁶Frame Check Sequence

rfc.com.ru 15 rfc.com.ru

Перевод RFC 1812

Перечисленные опции управляют представлением заголовков 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 (Password Authentication Protocol) и/или CHAP (Challenge Handshake Authentication Protocol).

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

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

Маршрутизатор может предлагать согласование адреса IP и должен воспринимать отказ (REJect) от такого согласования. Маршрутизаторам, работающим при скорости канала 19200 бит/с и ниже, следует реализовать и предлагать партнеру использование компрессии заголовков по алгоритму Van Jacobson. Маршрутизаторам, реализующим компрессию 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].

³⁷Numbered mode.

³⁸Asynchronous Control Character Map – отображение асинхронных кодов (символов) управления.

³⁹IP Control Protocol

⁴⁰Сетевой уровень модели OSI.

rfc.com.ru 16 rfc.com.ru

Перевод RFC 1812

Далее в этом документе для некоторых ситуаций в качестве действия указывается отбрасывание без уведомления⁴¹ полученной дейтаграммы. Это означает отбрасывание дейтаграммы без дальнейшей обработки и без передачи ее отправителю какого-либо сообщения об ошибке с помощью 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:

(a) Опция безопасности (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} <--- корректно

(В): {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].

⁴¹silently discard

⁴²Или значением router-id, если дейтаграмма будет передаваться через безадресный интерфейс.

⁴³Счетчик переполнений

rfc.com.ru 17

Перевод RFC 1812

Реализация

Для обеспечения максимальной пользы от временных меток в опции 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

Байт типа обслуживания (Type-of-Service) в заголовке 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].

⁴⁴Network Time Protocol – протокол сетевого времени.

rfc.com.ru 18

rfc.com.ru

Перевод RFC 1812

В некоторых реализациях стека 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 определено как время в секундах, этот параметр используется также в качестве счетчика интервалов (hop-count),

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

Когда время жизни дейтаграммы истекло (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 }, поскольку их источником может являться некорректно настроенный хост или маршрутизатор. Таким образом, если маршрутизатор знает, что делать с дейтаграммами,

⁴⁵В настоящее время значения Assigned Numbers доступны в базе данных на сайте www.iana.org. Прим. перев. ⁴⁶Перевод этой спецификации на русский язык имеется на сайте rfc.com.ru. Прим. перев. ⁴⁷Internet Assigned Number Authority

rfc.com.ru 19 rfc.com.ru

Перевод RFC 1812

содержащими адрес отправителя { 0, 0 }, он должен принимать их, в противном случае маршрутизатор должен отбрасывать

дейтаграммы.

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

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

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

(c) { -1, -1 }

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

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

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

Направленный широковещательный адрес⁴⁹ - пакеты с таким адресом в поле получателя предназначены для всех хостов сети с указанным префиксом. Недопустимо использовать такой адрес в поле отправителя. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор должен принимать пакеты Network Directed Broadcast, однако маршрутизатор может иметь конфигурационную опцию, предотвращающую восприятие таких пакетов. Данная опция по умолчанию должна разрешать прием пакетов Network Directed Broadcast⁵⁰.

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

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

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

Обсуждение

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

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

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

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

использоваться в процессе инициализации.

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

так, как будто они направлены по одному из IP-адресов маршрутизатора:

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

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

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

Обсуждение

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

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

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

(1) Маршрутизатор должен трактовать как широковещательные пакеты IP, направленные по адресу 255.255.255.255 или { <Префикс сети>, -1 }.

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

(3) Маршрутизатору следует (по умолчанию) использовать адрес ограниченного широковещания (limited broadcast address) 255.255.255.255 для широковещательных дейтаграмм IP, адресованных в подключенные (под)сети за исключением случаев передачи откликов ICMP Address Mask Reply, как показано в параграфе 4.3.3.9). Маршрутизатор должен принимать широковещательные пакеты с ограниченной областью распространения.

⁴⁸Limited broadcast ⁴⁹Directed Broadcast

⁵⁰В RFC 2644 (перевод этого документа имеется на сайте rfc.com.ru) приведены новые требования к маршрутизаторам по отношению к пакетам Network Directed Broadcast. Требования п. 4.2.2.11(d) в современной формулировке имеют вид: “Directed Broadcast – широковещательный адрес для сети с указанным префиксом. Недопустимо использование таких адресов в поле отправителя. Маршрутизатор может генерировать пакеты Network Directed Broadcast. Маршрутизатор может иметь конфигурационную опцию, разрешающую прием пакетов directed broadcast, однако эта опция должна быть отключена по умолчанию и, таким образом, для маршрутизаторов недопустимо принимать пакеты Network Directed Broadcast, пока это на задано явно конечным пользователем.” Прим. перев. ⁵¹specific-destination address

rfc.com.ru 20 rfc.com.ru

Перевод RFC 1812

(4) Для маршрутизатора недопустимо порождать пакеты, адресованные в 0.0.0.0 или {<Префикс сети>, 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)

⁵²discontiguous subnetwork support ⁵³Classless Inter Domain Routing

rfc.com.ru 21 rfc.com.ru

Перевод RFC 1812

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 об ошибке включает заголовок Internet и первые 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 Message Source Address

За исключением тех случаев, когда в данном документе явно указано иное, 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]). Однако некоторые устройства нарушают это правило.

⁵⁴Министерства обороны США.

rfc.com.ru

Перевод RFC 1812

Следовательно, для обнаружения широковещательных пакетов маршрутизаторы должны проверять наличие широковещательного адреса канального уровня и адрес 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). Если пакет пересылается хосту непосредственно подключенной к маршрутизатору сети (т. е., данный маршрутизатор является последним на пути - last-hop) и маршрутизатор знает об отсутствии других путей к этому хосту, он должен генерировать сообщение Destination Unreachable с кодом 1 (Host Unreachable – хост недоступен). Если пакет пересылается хосту подключенной к маршрутизатору сети и маршрутизатор не может переслать этот пакет по той причине, что значение TOS для подключенной сети отличается от принятого по умолчанию (0000) и от заданного в заголовке пакета, маршрутизатор должен передать отправителю пакета сообщение Destination Unreachable с кодом 12 (Host Unreachable for TOS – хост недоступен для заданного TOS).

Обсуждение

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

4.3.3.2 Redirect

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

В противоположность требованиям документа [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

rfc.com.ru

Перевод RFC 1812

Маршрутизатор должен генерировать сообщение 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 Герц)). Следовательно, значения стандартного времени допускают некоторый произвол:

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

(b) Точность стандартного времени должна приблизительно соответствовать тактовой частоте процессора. Реализация

Для выполнения второго условия маршрутизатору может потребоваться корректировка часов с использованием сервера точного времени при загрузке или перезапуске маршрутизатора. Для корректировки часов рекомендуется использовать протокол 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 и поступившие на

физический интерфейс, с которым связано множество логических интерфейсов, если маски для логических интерфейсов

различаются.

rfc.com.ru

Перевод RFC 1812

Маршрутизаторам следует проверять полученные сообщения 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 } .

Обсуждение

Возможность запрета передачи откликов 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 и используют извлеченную из него информацию для выбора маршрутизатора first-hop для того или иного адресата. Хотя такое поведение хостов не является нормальным, разработчики по-прежнему достаточно часто используют его.

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

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

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

5.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

⁵⁵Этот стандарт содержится в RFC 1122 и RFC 1123, переводы которых вы найдете на сайте rfc.com.ru, Прим. перев.

rfc.com.ru 25 rfc.com.ru

Перевод RFC 1812

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.1.3 Группа (Multicast)

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

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

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

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

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

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

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

(5a) На основе IP-адресов отправителя и получателей из заголовка дейтаграммы маршрутизатор определяет, следует ли принимать дейтаграмму через данный интерфейс для дальнейшей пересылки. При отрицательном ответе дейтаграмма отбрасывается без уведомления. Метод определение корректно входного интерфейса зависит от используемого алгоритма групповой маршрутизации. В одном из простейших алгоритмов RPF⁵⁷ корректным будет тот интерфейс, который бы использовался для отправки индивидуальных пакетов по адресу отправителя дейтаграммы.

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

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

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

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

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

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

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

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

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

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

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

⁵⁶expanding ring search

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

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

rfc.com.ru 26 rfc.com.ru

Перевод RFC 1812

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

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

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

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

Реализация

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

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

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

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

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

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

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

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

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

точки, в которой происходит отсечение части пакета. Кроме того, такая проверка сократит загрузку нисходящих потоков

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

Наконец, если адрес получателя в заголовке пакета не совпадает ни с одним из IP-адресов маршрутизатора, последнему следует

убедиться в отсутствии в заголовке пакета опций Strict Source Route и Record Route. Если такая опция присутствует,

маршрутизатору следует записать в журнальный файл сообщение об ошибке и передать отправителю сообщение ICMP Parameter

Problem с указателем на IP-адрес получателя.

Обсуждение

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

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

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

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

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

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

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

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

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

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

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

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

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

Обсуждение

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

rfc.com.ru 27 rfc.com.ru

Перевод RFC 1812

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

Реализация

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

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

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

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

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

♦ LSRR - опция IP Loose Source and Record Route;

♦ SSRR - опция IP Strict Source and Record Route;

♦ Опция Source Route - LSRR или SSRR;

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

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

♦ Адрес следующего интервала (Next Hop Address) - IP-адрес смежного хоста или маршрутизатора, которому пакет будет передан на следующем интервале;

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

♦ Непосредственный получатель⁶⁰ - узел, система, маршрутизатор или конечная система, указанная IP-адресом получателя.

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

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

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

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

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

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

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

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

♦ указатель в опции Source Route ссылается за пределы этой опции, сообщение адресовано системе, анализирующей его⁶¹.

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

route), при определении режима обработки пакета.

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

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

route.

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

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

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

Обсуждение

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

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

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

Реализация

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

⁵⁹Ultimate Destination Address

⁶⁰Immediate Destination

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

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

rfc.com.ru 28 rfc.com.ru

Перевод RFC 1812

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

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

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

(4) Если выбранный “следующий интервал” доступен через интерфейс, настроенный на использование NHRP, применимы следующие дополнительные операции:

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

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

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

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

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

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

Обсуждение

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

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

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

Обсуждение

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

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

Это правило отбрасывает все маршруты к адресату, отличающиеся от IP-адреса получателя для пакета. Например, если в

пакете указан IP-адрес получателя 10.144.2.5, на этом этапе будет отброшен маршрут в сеть 128.12.0.0/16, но останутся

любые маршруты в сети 10.0.0.0/8 и 10.144.0.0/16, а также принятые по умолчанию маршруты.

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

размер префикса (route.length) для задания количества значимых битов в route.dest. IP-адрес получателя пересылаемого

пакета – это ip.dest. Данное правило отбрасывает из набора кандидатов все маршруты, кроме тех, для которых route.length

старших битов route.dest и ip.dest совпадают.

Например, если IP-адрес получателя пакета 10.144.2.5 и имеются префиксы 10.144.1.0/24, 10.144.2.0/24 и 10.144.3.0/24,

данное правило оставит только 10.144.2.0/24 (единственный маршрут, в котором 24 старших бита совпадают 2 24

старшими битами IP-адреса получателя в пакете).

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

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

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

⁶³Next Hop Routing Protocol

⁶⁴Forwarding Information Base – база данных о пересылке. Прим. перев.

⁶⁵Pruning Rule

⁶⁶load-splitting

rfc.com.ru


На главную




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

Требования к маршрутизаторам IPv4
	Requirements for IP Version 4 Routers

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

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

Оглавление

Статус документа ....................................................................................................................................................................... ...................... 1 Предисловие ........................................................................................................................................................................ .............................. 1 1. Введение ................................................................................................................................................................................ ...... .................... 5 1.1 Работа с документом ........................................................................................................................................................................ ..5. 1.1.1 Организация документа .......................................................................................................................................................... ....5... 1.1.2 Уровни требований ............................................................................................................................................................ .. ....... 6 1.1.3 Соответствие спецификации ........................................................................................................................................ ............ 6 1.2 Отношения с другими стандартами ............................................................................................................................ ..... .. ................. 6 1.3 Общие вопросы ................................................................................................................................................................................. ..7... 1.3.1 Постоянное изменение Internet ................................................................................................................................. .... ............. 7 1.3.2 Принцип устойчивости .................................................................................................................................... .......................... 7 1.3.3 Протоколирование ошибок ...................................................................................................................................................... 7... 1.3.4 Настройка конфигурации ................................................................................................................................. ..... ...................... 8 1.4 Алгоритмы .............................................................................................................................................................. .............................. 8 2. Архитектура INTERNET ..................................................................................................................................................................... ...... 8. 2.1 Введение .................................................................................................................................................................................... .......... 8 2.2 Элементы архитектуры ........................................................................................................................................................ .... ............ 9 2.2.1 Протокольные уровни ............................................................................................................................................................. ....9... 2.2.2 Сети .............................................................................................................................................................................. ....... ........... 9 2.2.3 Маршрутизаторы .................................................................................................................................................... ..... .. ............ 10 2.2.4 Автономные системы ............................................................................................................................................................ ..1..0... 2.2.5 Архитектура адресации ....................................................................................................................................... .................... 10 2.2.5.1 Классическая архитектура адресации IP .......................................................................................................... .... ......... 10 2.2.5.2 Бесклассовая междоменная маршрутизация (CIDR) .......................................................................................... ....... 11 2.2.6 IP Multicasting ........................................................................................................................................................ ..... ......... 11 2.2.7 Безадресные линии и префиксы сетей ..................................................................................................................... ............. 11 2.2.8 Специфические варианты маршрутизаторов ................................................................................................................. ...... 12 2.2.8.1 Хосты со встроенной маршрутизацией ............................................................................................................... ........ 12 2.2.8.2 Прозрачные маршрутизаторы ....................................................................................................................................... 1..2... 2.3 Характеристики маршрутизаding:0.00pt 0.00pt 0.00pt 113.28pt; text-align:left;">2.2.8.2 Прозрачные маршрутизаторы ....................................................................................................................................... 1..2... 2.3 Характеристики маршрутизаторов .................................................................................................................................... ............. 12 2.4 Архитектурные допущения ...................................................................................................................................... ........................ 13 3. Канальный уровень ........................................................................................................................................................................... ..... .....14 3.1 Введение ............................................................................................................................................................................... ....... ......... 14 3.2 Интерфейс между канальным уровнем и IP .................................................................................................................................. 14 3.3 Частные вопросы ............................................................................................................................................................................ ..1..4... 3.3.1 Трейлерная инкапсуляция ................................................................................................................................................. ..... 14 3.3.2 Протокол преобразования адресов - ARP ................................................................................................................ ............ 15 3.3.3 Совместное использование Ethernet и 802.3 ..................................................................................................................... ....1. 5 3.3.4 Максимальный размер блока - MTU ................................................................................................................................... ....1..5. 3.3.5 Протокол PPP ........................................................................................................................................................ ..... ................ 15 3.3.5.1 Введение .................................................................................................................................................. ......................... 15 3.3.5.2 Опции LCP ............................................................................................................................................................ .. .......... 15 3.3.5.3 Опции протокола IPCP .......................................................................................................................................... ........ 16

rfc.com.ru		rfc.com.ru



	Перевод RFC 1812

	*1. Введение* Этот документ заменяет RFC 1716, "Requirements for Internet Gateways" ([INTRO: 1]). В документе определяются и обсуждаются требования к устройствам, выполняющим функции пересылки (forwarding) пакетов на сетевом уровне стека протоколов Internet. Сообщество 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) Общие вопросы - рассматриваются спецификации протокола по разделам исходного стандарта, указываются и исправляются ошибки, обсуждаются требования, которые могли быть неточно или некорректно определены, а также приводятся дополнительные разъяснения и уточнения

	¹Переводы этих RFC вы можете найти на сайте http://rfc.com.ru. Прим. перев. rfc.com.ru 5 rfc.com.ru



	Перевод RFC 1812 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 info@internic.net +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 является весьма непростой задачей. Упростить поиск проблем помогает использование хостами специальных средств протоколирования ошибок и странностей в поведении протоколов. При записи таких событий важно включать максимум диагностической информации. Часто бывает весьма полезно записывать заголовки пакетов, вызывающих ошибки. Однако следует знать меру - средства протоколирования ошибок не должны отнимать слишком много ресурсов маршрутизатора и снижать эффективность его работы. При записи информации об ошибках существует вероятность получения журнальных файлов огромного размера - таких ситуаций можно избежать, используя “циклический” журнал или включая запись только для диагностики определенных сбоев. Полезно

	³В настоящее время документ Assigned Numbers утратил силу и список выделенных значений доступен в базе данных на сайте www.iana.org. Прим. перев. ⁴На сайте rfc.com.ru имеются переводы этих документов на русский язык. Прим. перев. ⁵ Сайт ds.internic.net в настоящее время не поддерживается, а копии документов RFC можно найти на сайте www.rfc-editor.org. Прим. перев. ⁶ В оригинале “Be conservative in what you do, be liberal in what you accept from others.” Прим. перев. rfc.com.ru 7 rfc.com.ru



	Перевод RFC 1812 также фильтровать и считать повторяющиеся последовательные сообщения. Разумно также фильтровать и подсчитывать повторяющиеся события. Представляется привлекательной приведенная ниже стратегия: (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¹².

	⁷ Internet Protocol – протокол Internet. ⁸ Internet Control Message Protocol – протокол обмена управляющими сообщениями. ⁹ Internet Group Management Protocol – протокол управления группами. ¹⁰ Internet Engineering Steering Group. ¹¹ Transmission Control Protocol – протокол управления передачей. ¹² User Datagram Protocol – протокол пользовательских дейтаграмм. rfc.com.ru 8 rfc.com.ru



Перевод RFC 1812

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) и передает данные в виде дейтаграмм (datagram) без гарантии доставки. Исследовательскими организациями были разработаны и другие протоколы транспортного уровня, которые могут получить статус стандартных протоколов. Более подробное описание протоколов транспортного уровня приведено в главе 6. ♦ Уровень Internet (Internet Layer) Все транспортные протоколы используют протокол IP (Internet Protocol) для передачи данных от отправителя к получателю. IP представляет собой службу доставки дейтаграмм без организации соединений (connectionless), не обеспечивающую сквозной гарантии доставки. Таким образом, при доставке на хост получателя дейтаграммы 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)

rfc.com.ru	9	rfc.com.ru



	Перевод RFC 1812 2.2.5.2 Бесклассовая междоменная маршрутизация (CIDR¹⁵) Взрывной рост сети 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, который в данном документе обозначается термином

	¹⁵ Classless Inter Domain Routing ¹⁶ Internet Group Management Protocol

	rfc.com.ru 11 rfc.com.ru



	Перевод RFC 1812 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 (Канальный уровень). (3) Прием и пересылка дейтаграмм Internet. Важной частью этого процесса является управление буферами, контроль насыщения и беспристрастность при пересылке. ♦ детектирование ошибок и генерация при необходимости сообщений ICMP;

	¹⁷address sharing router ¹⁸transparent router ¹⁹Не используемой для транзитного трафика. Прим. перев. ²⁰Адресат “умер”. ²¹Maximum Transmission Unit – максимальный размер передаваемого блока. rfc.com.ru 12 rfc.com.ru



	Перевод RFC 1812 ♦ отбрасывание дейтаграмм с нулевым значением времени жизни; ♦ фрагментация дейтаграмм при необходимости в соответствии со значением MTU в следующей по маршруту сети. Более подробная информация приведена в главах 4 (Протоколы уровня Internet) и 5 (Уровень Internet - пересылка). (4) Выбор следующего маршрутизатора (next-hop) для каждой дейтаграммы IP на основе информации из базы данных о маршрутах. Более подробная информация содержится в главе 5 (Уровень Internet - пересылка). (5) Поддержка (в большинстве случаев) протокола внутренней маршрутизации (IGP²²) для передачи маршрутной информации и алгоритмов определения доступности другим маршрутизаторам в своей автономной системе. В дополнение к этому от некоторых маршрутизаторов требуется поддержка протокола внешней маршрутизации (EGP²³) для обмена топологической информацией с другими автономными системами. Дополнительная информация приведена в главе 7 (Прикладной уровень -протоколы маршрутизации). (6) Поддержка функций сетевого управления, включая загрузку, отладку, отчеты о состоянии, отчеты об исключительных ситуациях и управление. Дополнительная информация приведена в главах 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 независимо от других пакетов. В результате для повышения устойчивости могут использоваться избыточные пути, используемые при возникновении сбоев в сетях или маршрутизаторах. Вся информация о состоянии, требуемая для обеспечения сквозного управления потоком данных и гарантий доставки, реализуется на хостах в программах транспортного и прикладного уровня. Вся эта информация сосредоточена на паре конечных точек, участвующих в сеансе обмена информацией и будет теряться только при отказе одной из этих точек. Маршрутизаторы управляют потоком сообщений лишь опосредованно путем отбрасывания пакетов или увеличения задержки.

	²²Internal Gateway Protocol – протокол внутреннего шлюза. ²³External Gateway Protocol – протокол внешнего шлюза. ²⁴stub network rfc.com.ru 13 rfc.com.ru



	Перевод RFC 1812 Отметим, что разработчики новых протоколов могут реализовать в маршрутизаторах хранение некоторых сведений о состоянии. Это наиболее вероятно для групповой маршрутизации, резервирования ресурсов и пересылке на основе состояния потоков данных. ♦ Вопросы сложной маршрутизации должны решаться в маршрутизаторах. Маршрутизация является сложной задачей и выполняется она маршрутизаторами, а не хостами. Это является важной предпосылкой для изоляции используемых на хостах программ от изменений, которые могут быть вызваны неизбежной эволюцией архитектуры маршрутизации 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]. Однако маршрутизаторам не следует порождать (originate) пакетов с трейлерной инкапсуляцией. Для маршрутизаторов недопустима генерация пакетов с трейлерной инкапсуляцией без предварительной проверки с использованием механизма, описанного в [INTRO:2], возможности восприятия пакетов с трейлерной

	²⁵Link Layer Requirements – требования к канальному уровню. ²⁶Requirements for Internet Link Layer ²⁷Link Layer precedence-related error rfc.com.ru 14 rfc.com.ru



	Перевод RFC 1812 инкапсуляцией их получателем. Маршрутизаторам не следует соглашаться (используя указанный выше механизм) на восприятие пакетов с трейлерной инкапсуляцией. *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) используют иную спецификацию канального уровня. Маршрутизаторы, использующие линии “точка-точка” или последовательные интерфейсы общего назначения, должны поддерживать протокол 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. Обсуждение

	²⁸Point-to-Point Protocol ²⁹Link Control Protocol – протокол управления каналом. ³⁰PPP Link Control Protocol ³¹Asynchronous character map ³²Maximum Receive Unit ³³Link Quality Monitoring ³⁴Password Authentication Protocol ³⁵Challenge Handshake Authentication Protocol – протокол согласования аутентификационных запросов. ³⁶Frame Check Sequence rfc.com.ru 15 rfc.com.ru



	Перевод RFC 1812 Далее в этом документе для некоторых ситуаций в качестве действия указывается отбрасывание без уведомления⁴¹ полученной дейтаграммы. Это означает отбрасывание дейтаграммы без дальнейшей обработки и без передачи ее отправителю какого-либо сообщения об ошибке с помощью 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: (a) Опция безопасности (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} <--- корректно (В): {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].

	⁴¹silently discard ⁴²Или значением router-id, если дейтаграмма будет передаваться через безадресный интерфейс. ⁴³Счетчик переполнений

	rfc.com.ru 17



		Перевод RFC 1812
		Перевод RFC 1812
	Реализация Для обеспечения максимальной пользы от временных меток в опции 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 Байт типа обслуживания (Type-of-Service) в заголовке 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].

	⁴⁴Network Time Protocol – протокол сетевого времени. rfc.com.ru 18	rfc.com.ru



	Перевод RFC 1812

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 об ошибке включает заголовок Internet и первые 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 Message Source Address За исключением тех случаев, когда в данном документе явно указано иное, 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]). Однако некоторые устройства нарушают это правило.

⁵⁴Министерства обороны США. rfc.com.ru	22	rfc.com.ru



	Перевод RFC 1812 (1) Маршрутизатор получает пакет IP (вместе с дополнительной информацией о пакете, рассмотренной в параграфе 3.1) от канального уровня (Link Layer). (2) Маршрутизатор проверяет корректность заголовка IP, как описано в параграфе 5.2.2. Отметим, что сборка фрагментов IP не выполняется за исключением тех случаев, когда пакет адресован самому маршрутизатору (см. п. (4) в предыдущем параграфе). (3) Маршрутизатор выполняет большую часть операций по обработке опций IP. Как описано в параграфе 5.2.4, некоторые опции IP требуют дополнительной обработки после принятия решения о маршрутизации (выборе выходного интерфейса). (4) Маршрутизатор проверяет IP-адрес получателя дейтаграммы, как описано в параграфе 5.2.3, чтобы определить, как должна происходить дальнейшая обработка дейтаграммы. Здесь возможны три варианта: ♦ дейтаграмма адресована маршрутизатору и ее следует поместить в локальную очередь, выполнив при необходимости сборку фрагментов; ♦ дейтаграмма не адресована маршрутизатору и ее следует поместить в очередь для пересылки; ♦ дейтаграмму следует поместить в очередь для пересылки, но ее копия также должна быть помещена в очередь для локальной доставки. 5.2.1.2 Конкретный адресат (Unicast) Поскольку локальная доставка хорошо описана в [INTRO:2], ниже предполагается, что дейтаграмма IP предназначена для пересылки. Если пакет направлен по индивидуальному адресу IP: (5) Модуль пересылки (forwarder) определяет IP-адрес следующего маршрутизатора (next hop) обычно путем просмотра таблицы маршрутизации. Эта процедура более детально описана в параграфе 5.2.4. Данная процедура также определяет сетевой интерфейс, который должен использоваться для передачи пакета. (6) Модуль пересылки проверяет допустимость пересылки пакета. Адреса отправителя и получателя должны быть корректны в соответствии с требованиями параграфов 5.3.7 и 5.3.4. Если маршрутизатор поддерживает административные ограничения на пересылку (типа описанных в параграфе 5.3.9), эти ограничения должны быть приняты во внимание. (7) Модуль пересылки уменьшает (по крайней мере на 1) значение TTL в заголовке пакета и проверяет его, как описано в параграфе 5.3.1. (8) Модуль пересылки выполняет все операции по обработке опций IP, которые не могли быть выполнены на этапе (3). (9) Модуль пересылки при необходимости фрагментирует пакет, как описано в параграфе 4.2.2.7. Поскольку этот этап выполняется после выбора выходного интерфейса (этап 5), все фрагменты одной дейтаграммы будут передаваться через один интерфейс. (10) Модуль пересылки определяет адрес канального уровня для следующего интервала (next hop). Механизм определения адреса зависит от используемого протокола канального уровня (см. главу 3). (11) Модуль пересылки инкапсулирует дейтаграмму IP (или каждый из ее фрагментов) в соответствующий кадр канального уровня и помещает в очередь выходного интерфейса, выбранного на этапе 5. (12) Модуль пересылки при необходимости передает сообщение ICMP redirect, как описано в параграфе 4.3.3.2. 5.2.1.3 Группа (Multicast) Если адрес получателя является групповым адресом IP, выполняются перечисленные ниже этапы пересылки. Основные различие между пересылкой индивидуальных и групповых дейтаграмм IP: ♦ Групповые дейтаграммы IP обычно пересылаются на основе адресов отправителя и получателя в заголовке IP; ♦ Для групповых дейтаграмм IP используется поиск по расширяющимся кругам⁵⁶; ♦ Групповые дейтаграммы IP пересылаются с использованием групповой адресации канального уровня; ♦ Сообщения ICMP об ошибках никогда не передаются в ответ на групповые дейтаграммы IP. Отметим, что пересылка групповых дейтаграмм IP является в некоторой степени экспериментальной. Поэтому описанный ниже алгоритм не является обязательным и приведен лишь в качестве примера. (5a) На основе IP-адресов отправителя и получателей из заголовка дейтаграммы маршрутизатор определяет, следует ли принимать дейтаграмму через данный интерфейс для дальнейшей пересылки. При отрицательном ответе дейтаграмма отбрасывается без уведомления. Метод определение корректно входного интерфейса зависит от используемого алгоритма групповой маршрутизации. В одном из простейших алгоритмов RPF⁵⁷ корректным будет тот интерфейс, который бы использовался для отправки индивидуальных пакетов по адресу отправителя дейтаграммы. (6a) На основе IP-адресов отправителя и получателей из заголовка дейтаграммы маршрутизатор определяет выходные интерфейсы для пересылки дейтаграммы. Для реализации поиска по расширяющимся кругам (см. [INTERNET:4]) каждому выходному интерфейсу ставится в соответствие минимальное значение TTL. Копия multicast-дейтаграммы пересылается через каждый из выходных интерфейсов, для которого минимальное значение TTL не превышает значение TTL в заголовке дейтаграммы. Этот этап выполняется раздельно для каждого интерфейса. (7a) Маршрутизатор уменьшает на 1 значение TTL в заголовке пакета. (8a) Модуль пересылки выполняет все операции по обработке опций IP, которые не могли быть выполнены на этапе (3). (9a) Модуль пересылки при необходимости выполняет фрагментацию дейтаграммы, как описано в параграфе 4.2.2.7. (10a) Модуль пересылки определяет адрес канального уровня для использования при инкапсуляции дейтаграммы в кадр канального уровня. Механизм определения адреса зависит от протокола канального уровня. В локальных сетях используется групповой или широковещательный адрес канального уровня для передачи групповых дейтаграмм IP. Более детальную информацию вы найдете в соответствующих спецификациях IP-over-xxx. (11a) Модуль пересылки инкапсулирует дейтаграмму IP (или каждый из ее фрагментов) в соответствующий кадр канального уровня и помещает в очереди соответствующих сетевых интерфейсов. *5.2.2 Проверка корректности заголовка IP* До того, как маршрутизатор начнет обработку пакета IP, он должен выполнить перечисленные ниже операции проверки корректности заголовка IP, позволяющие убедиться в осмысленности этого заголовка. Если пакет не проходит любой из перечисленных ниже тестов, такой пакет должен быть отброшен без уведомления. Информацию об ошибке следует записать в журнальный файл маршрутизатора. (1) Размер пакета, полученный от канального уровня, должен быть достаточным для размещения дейтаграммы IP минимального размера (20 байтов). (2) Контрольная сумма в заголовке IP должны быть корректной. (3) Поле IP version должно содержать значение 4. если значение поля отличается от 4, пакет относится к другой версии протокола IP (например, IPng⁵⁸ или ST-II).

	⁵⁶expanding ring search ⁵⁷reverse path forwarding – персылка по обратному пути. Прим. перев. ⁵⁸IPv6 в современной терминологии. Прим. перев. rfc.com.ru 26 rfc.com.ru



		Перевод RFC 1812

	прибыл. Следовательно, маршрутизатор может без риска передать этот пакет с использованием широковещательного адреса канального уровня в ту же физическую сеть через тот же (физический) интерфейс, который принял пакет. Однако, если маршрутизатор не может определить, что пакет был получен как unicast-кадр канального уровня, упомянутое требование позволяет маршрутизатору считать что он выполняет безопасную, но некорректную пересылку (а не рискованную, но корректную). Реализация Как указано в параграфе 5.3.4, пакеты, полученные в широковещательных кадрах канального уровня, в общем случае не пересылаются маршрутизатором. Имеет смысл просто не передавать пакеты модулю пересылки, поскольку они все равно будут отбрасываться в соответствии с приведенными здесь правилами. В некоторых случаях канальный уровень (в силу аппаратных особенностей или программного кода драйверов) может передавать маршрутизатору копии всех передаваемых в среде широковещательных и групповых кадров канального уровня. Описанный здесь подход позволяет упростить реализацию для тех случаев, когда пакет доставляется локально и передается модулю пересылки, поскольку пересылка пакета будет автоматически приводить к получению маршрутизатором копии пакета, которую он может использовать для локальной доставки. Однако в таких случаях нужно быть внимательным, чтобы предотвратить трактовку полученных “возвратных” (loop-back) пакетов, как обычных принятых пакетов (и применения к ним правил пересылки и т. п.). Даже при отсутствии таких особенностей канального уровня необходимо сделать копию целого пакета для помещения в очереди пересылки и локальной доставки с учетом того, что дейтаграмма может быть фрагментирована и требуется собрать фрагменты для локальной доставки, не выполняя такой сборки для пересылаемых пакетов. Одним из простых способов решения этой задачи является установка для каждого пакета в выходной очереди маршрутизатора специального флага, который показывает, нужно ли поместить пакет в очередь для локальной доставки после пересылки этого пакета. *5.2.4 Определение адреса следующего интервала (Next Hop)* Когда маршрутизатор пересылает пакет, он должен определить передается этот пакет конечному адресату или следующему маршрутизатору. В последнем случае требуется также определить маршрутизатор, которому нужно передать пакет. В этой главе рассматриваются способы определения этого маршрутизатора. Ниже перечислены используемые в этой главе термины: ♦ LSRR - опция IP Loose Source and Record Route; ♦ SSRR - опция IP Strict Source and Record Route; ♦ Опция Source Route - LSRR или SSRR; ♦ Адрес окончательной доставки⁵⁹ - точка, куда пакет в конце концов должен быть передан: последний адрес в заданном отправителем маршруте доставки пакета или IP-адрес получателя в заголовке пакета без опции source-route; ♦ Смежный - доступный без прохождения через маршрутизаторы IP; ♦ Адрес следующего интервала (Next Hop Address) - IP-адрес смежного хоста или маршрутизатора, которому пакет будет передан на следующем интервале; ♦ IP-адрес получателя - адрес окончательной доставки для случаев, когда не используется заданная отправителем маршрутизация (в этом случае адресом получателя служит следующий адрес, указанный в source route); ♦ Непосредственный получатель⁶⁰ - узел, система, маршрутизатор или конечная система, указанная IP-адресом получателя. 5.2.4.1 IP-адрес получателя Если выполняются перечисленные ниже условия: ♦ адрес получателя в заголовке IP совпадает с одним из адресов маршрутизатора; ♦ пакет содержит опцию Source Route; ♦ указатель в опции Source Route не ссылается за пределы этой опции, IP-адресом получателя является адрес, на который ссылается указатель опции Source Route. Если выполняются следующие условия: ♦ адрес получателя в заголовке IP совпадает с одним из адресов маршрутизатора; ♦ пакет содержит опцию Source Route; ♦ указатель в опции Source Route ссылается за пределы этой опции, сообщение адресовано системе, анализирующей его⁶¹. Маршрутизатор должен использовать IP-адрес получателя, а не адрес окончательной доставки (последний адрес в опции source route), при определении режима обработки пакета. Наличии в пакете нескольких опций source route является ошибкой. При получении такой дейтаграммы маршрутизатору следует отбрасывать пакет, передавая его отправителю сообщение ICMP Parameter Problem с указателем на начало второй опции source route. 5.2.4.2 Выбор между локальной доставкой и пересылкой После того, как была определена необходимость пересылки пакета IP в соответствии с правилами, указанными в параграфе 5.2.3, должен использоваться описанный ниже алгоритм определения прямой доступности⁶² непосредственного получателя (см. [INTERNET:2]). (1) Для каждого сетевого интерфейса, не имеющего адрес IP (безадресные линии обсуждаются в параграфе 2.2.7), сравнивается значение router-id на другой стороне соединения с IP-адресом получателя. При совпадении адресов пакет можно передавать через данный интерфейс. Обсуждение Иными словами, маршрутизатор или хост на другой стороне соединения является адресатом пакета или следующим интервалом заданного отправителем маршрута для пакета с опцией source route. (2) Если на первом этапе сетевой интерфейс не был выбран, для каждого из IP-адресов маршрутизатора выполняются следующие операции: (a) выделяется сетевой префикс, используемый интерфейсом. Реализация Результат этой операции обычно вычисляется в процессе инициализации маршрутизатора и сохраняется для последующего использования.

	⁵⁹Ultimate Destination Address ⁶⁰Immediate Destination ⁶¹Данному маршрутизатору. Прим. перев. ⁶²Расположения непосредственного получателя в одной из подключенных к маршрутизатору сетей. Прим. перев. rfc.com.ru 28 rfc.com.ru



	Перевод RFC 1812

	(b) Выделяется соответствующий набор битов из IP-адреса получателя для пакета. (c) Сравниваются полученные сетевые префиксы и при совпадении пакет может передаваться через соответствующий интерфейс. (3) Если получателем не является ни router-id соседнего маршрутизатора на безадресном соединении, ни узел непосредственно подключенной к маршрутизатору сети, это говорит, что на пути к адресату присутствуют другие маршрутизаторы (данный маршрутизатор не является последним). Выбор маршрутизатора и адреса IP для следующего интервала (next hop) описан в параграфе 5.2.4.3. В случае хоста, не являющегося маршрутизатором, может использоваться принятый по умолчанию маршрут. В работе [ARCH:9, NRHP] рассматриваются некоторые специальные случаи (например, наличие множества (под)сетей IP в одной сети канального уровня). За исключением заданных политикой ограничений, хосты и маршрутизаторы, находящиеся в одной сети канального уровня могут взаимодействовать между собой напрямую, даже если они находятся в разных (под)сетях IP, при наличии адекватной информации. Протокол NHRP⁶³) позволяет узлам IP определять “оптимальный” адрес канального уровня для передачи пакетов через такую сеть канального уровня в направлении удаленного адресата. (4) Если выбранный “следующий интервал” доступен через интерфейс, настроенный на использование NHRP, применимы следующие дополнительные операции: (a) Сравнивается IP-адрес получателя с адресами получателей в кэше NHRP. При обнаружении искомого адреса в кэше, дейтаграмма передается по соответствующему кэшированному адресу канального уровня. (b) Если адрес не найден в кэше, создается пакет запроса NHRP, содержащий IP-адрес получателя. Это сообщение передается серверу NHRP, заданному для интерфейса. В качестве такого сервера может использоваться логически выделенный процесс или объект в самом маршрутизаторе. (c) Сервер NHRP в ответ на запрос сообщит подходящий адрес канального уровня для передачи этой (и последующих) дейтаграммы адресату. Во время ожидания отклика от сервера NHRP система может передать дейтаграмму (дейтаграммы) “традиционному” маршрутизатору next hop. 5.2.4.3 Адрес следующего интервала Комментарии Маршрутизаторы используют описанный в предыдущем параграфе алгоритм для определения присутствия IP-адреса получателя в смежной сети. При положительном ответе адрес следующего интервала совпадает с IP-адресом получателя. В противном случае пакет должен пересылаться через другой маршрутизатор для доставки непосредственному получателю. Выбор этого маршрутизатора рассматривается в данном параграфе. Если пакет содержит SSRR, маршрутизатор должен отбросить пакет и передать его отправителю сообщение об ошибке ICMP Bad Source Route. В противном случае маршрутизатор ищет IP-адрес получателя в своей таблице маршрутизации для выбора следующего интервала пересылки. Обсуждение В соответствии со спецификацией IP опция Strict Source Route должна содержать последовательность узлов, через которые должен проходить пакет (пакет передается от узла source route к следующему, проходя только через промежуточные сети). Таким образом, если маршрутизатор не является смежным со следующим узлом source route, заданный отправителем маршрут не может быть завершен. Следовательно, маршрутизатор будет отвергать такие пакеты, возвращая отправителю сообщение ICMP Bad Source Route. Целью процесса выбора следующего интервала (next-hop selection) является проверка записей в базе пересылки маршрутизатора (FIB⁶⁴) и выбор лучшего маршрута (если такой имеется) для пакета из числа путей, представленных в FIB. Концептуально любой алгоритм поиска маршрутов начинается с набора кандидатов, в качестве которого используется вся таблица FIB. Алгоритм включает последовательность этапов, на которых отбрасываются некоторые маршруты из числа кандидатов. Такие этапы называют правилами сокращения⁶⁵. Обычно при завершении работы алгоритмов из набора кандидатов остается единственный маршрут. Если после сокращения остается пустой набор (нет маршрута), пакет отбрасывается по причине недоступности адресата. Возможно также завершение работы алгоритма с несколькими оставшимися кандидатами. В этом случае маршрутизатор может произвольно выбрать один из оставшихся маршрутов или воспользоваться режимом распределения нагрузки⁶⁶ между оставшимися маршрутами, выбирая из них тот, который использовался наиболее давно. При выборе для пакета следующего интервала маршрутизатор должен использовать приведенные ниже правила сокращения, за исключением правила 3 (Weak TOS). Если маршрутизатор использует значение TOS при выборе следующего интервала, правило 3 должно использоваться с соблюдением приведенного здесь порядка. Эти правила должны быть (концептуально) применены к FIB в том порядке, как они представлены ниже. (В силу исторических причин дополнительные правила сокращения и другой алгоритм выбора следующего интервала рассматриваются в приложении E.) Обсуждение Правило 3 является необязательным и в параграфе 5.3.2 сказано, что маршрутизатору лишь следует принимать во внимание значение TOS при выборе решения о пересылке. (1) Базовое соответствие (Basic Match) Это правило отбрасывает все маршруты к адресату, отличающиеся от IP-адреса получателя для пакета. Например, если в пакете указан IP-адрес получателя 10.144.2.5, на этом этапе будет отброшен маршрут в сеть 128.12.0.0/16, но останутся любые маршруты в сети 10.0.0.0/8 и 10.144.0.0/16, а также принятые по умолчанию маршруты. Говоря более точно, мы предполагаем, что каждый маршрут имеет атрибут назначения (route.dest) и соответствующий ему размер префикса (route.length) для задания количества значимых битов в route.dest. IP-адрес получателя пересылаемого пакета – это ip.dest. Данное правило отбрасывает из набора кандидатов все маршруты, кроме тех, для которых route.length старших битов route.dest и ip.dest совпадают. Например, если IP-адрес получателя пакета 10.144.2.5 и имеются префиксы 10.144.1.0/24, 10.144.2.0/24 и 10.144.3.0/24, данное правило оставит только 10.144.2.0/24 (единственный маршрут, в котором 24 старших бита совпадают 2 24 старшими битами IP-адреса получателя в пакете). (2) Соответствие максимальной длины (Longest Match) Правило Longest Match является усовершенствованным вариантом правила Basic Match, описанного выше. После сокращения по правилу Basic Match, алгоритм проверяет оставшиеся маршруты для пути с максимальным значением route.length. Все остальные маршруты отбрасываются. Например, если в пакете задан IP-адрес получателя 10.144.2.5 и остались префиксы 10.144.2.0/24, 10.144.0.0/16 и 10.0.0.0/8, среди них будет выбран префикс 10.144.2.0/24, поскольку для него длина соответствия является наибольшей.

	⁶³Next Hop Routing Protocol ⁶⁴Forwarding Information Base – база данных о пересылке. Прим. перев. ⁶⁵Pruning Rule ⁶⁶load-splitting
	rfc.com.ru